Intent to Ship: Private Aggregation API: filtering IDs
Alex Turner
Contact emails
ale...@chromium.orgExplainer
https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/flexible_filtering.mdSpecification
https://github.com/patcg-individual-drafts/private-aggregation-api/pull/123Summary
Modifies the Private Aggregation API to add a 'filtering ID' to the aggregatable reports' encrypted payloads. This ID allows histogram contributions with different filtering IDs to be processed separately on the aggregation service. A list of filtering IDs could be provided in an aggregation query and any contributions not matching a listed ID will be filtered out, not contributing to the result. To support the new feature, we update the report version to "1.0" (from "0.1"). By the time this is launched to Stable, all valid aggregation service releases will support the new report version, avoiding backwards compatibility concerns. (Old releases are deprecated on a regular schedule.)
Blink component
Blink>PrivateAggregationTAG review
https://github.com/w3ctag/design-reviews/issues/846 (We have not requested a signal for these changes specifically.)TAG review status
PendingRisks
Interoperability and Compatibility
The Aggregation Service (used to process the aggregatable reports) typically allows its releases to be used for up to six months. To reduce the compatibility impact of this change, we are waiting until all current Aggregation Service releases support the new version before rolling to Stable.
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/805) We have not requested a signal for this change specifically. The Gecko position on Shared Storage (one of the ways Private Aggregation is exposed) is negative.
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/189) We have not requested a signal for this change specifically.
Web developers: Positive signals for broad feature (https://github.com/patcg-individual-drafts/private-aggregation-api/issues/92)
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
No new debug capabilities beyond the existing internals page (chrome://private-aggregation-internals) and temporary debug mode. These capabilities do support the new filtering IDs.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
All but Webview
Is this feature fully tested by web-platform-tests?
YesFlag name on chrome://flags
NoneFinch feature name
PrivateAggregationApiFilteringIdsRequires code in //chrome?
FalseTracking bug
https://crbug.com/330744610Launch bug
https://launch.corp.google.com/launch/4302413Estimated milestones
| Shipping on desktop | 128 |
| Shipping on Android | 128 |
Anticipated spec changes
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4793172803977216?gate=5039125582577664
Mike Taylor
Contact emails
ale...@chromium.org
Explainer
https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/flexible_filtering.md
Specification
https://github.com/patcg-individual-drafts/private-aggregation-api/pull/123
Summary
Modifies the Private Aggregation API to add a 'filtering ID' to the aggregatable reports' encrypted payloads. This ID allows histogram contributions with different filtering IDs to be processed separately on the aggregation service. A list of filtering IDs could be provided in an aggregation query and any contributions not matching a listed ID will be filtered out, not contributing to the result. To support the new feature, we update the report version to "1.0" (from "0.1"). By the time this is launched to Stable, all valid aggregation service releases will support the new report version, avoiding backwards compatibility concerns. (Old releases are deprecated on a regular schedule.)
Blink component
Blink>PrivateAggregation
TAG review
https://github.com/w3ctag/design-reviews/issues/846 (We have not requested a signal for these changes specifically.)
TAG review status
Pending
Risks
Interoperability and Compatibility
The Aggregation Service (used to process the aggregatable reports) typically allows its releases to be used for up to six months. To reduce the compatibility impact of this change, we are waiting until all current Aggregation Service releases support the new version before rolling to Stable.
Can you say more about this? How many parties are running these services, and do we have any way of knowing what the uptake of new versions is, or said differently - can we tell if they're still on older versions?
Also, what happens if you send the filter ID to an older version?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiFk3Nz9owQQnA9XzYa43cLAoh53dXGQTEstn%2BStUuud--Q%40mail.gmail.com.
Alex Turner
On 7/8/24 4:05 PM, Alex Turner wrote:
Contact emails
ale...@chromium.org
Explainer
https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/flexible_filtering.md
Specification
https://github.com/patcg-individual-drafts/private-aggregation-api/pull/123
Summary
Modifies the Private Aggregation API to add a 'filtering ID' to the aggregatable reports' encrypted payloads. This ID allows histogram contributions with different filtering IDs to be processed separately on the aggregation service. A list of filtering IDs could be provided in an aggregation query and any contributions not matching a listed ID will be filtered out, not contributing to the result. To support the new feature, we update the report version to "1.0" (from "0.1"). By the time this is launched to Stable, all valid aggregation service releases will support the new report version, avoiding backwards compatibility concerns. (Old releases are deprecated on a regular schedule.)
Blink component
Blink>PrivateAggregation
TAG review
https://github.com/w3ctag/design-reviews/issues/846 (We have not requested a signal for these changes specifically.)
TAG review status
Pending
Risks
Interoperability and Compatibility
The Aggregation Service (used to process the aggregatable reports) typically allows its releases to be used for up to six months. To reduce the compatibility impact of this change, we are waiting until all current Aggregation Service releases support the new version before rolling to Stable.
Can you say more about this? How many parties are running these services, and do we have any way of knowing what the uptake of new versions is, or said differently - can we tell if they're still on older versions?
Also, what happens if you send the filter ID to an older version?
Release 2.3 does not support the new report format, but we have announced it will reach end-of-support on August 2nd, i.e. before M128 reaches Stable. (Note that we have already enabled the feature on Canary for testing.) Attempting to process reports with the new “1.0” report version on this release will result in the aggregation job failing with a descriptive error message. In this case, however, no budget will be consumed and the aggregation can be re-attempted (either on a newer release or after excluding the “1.0” reports).
Release 2.4 supports the new report format, but it does not allow for filtering_ids to be specified for the aggregation; the default value ([0]) is always used. On this release, existing flows that do not use the new feature will be unaffected by the report version change.
Release 2.5 supports the new report format and allows filtering_ids to be specified for the aggregation. Developers who want to use the new feature should upgrade to this release.
We don't currently have metrics on usage of each Aggregation Service release, but plan to add those. Still, we have notified partners of these considerations through the API mailing lists. We'll also remind partners of the upcoming end-of-support.
Mike Taylor
On 7/12/24 10:44 AM, Alex Turner wrote:
On Wed, Jul 10, 2024 at 11:25 AM Mike Taylor <mike...@chromium.org> wrote:
On 7/8/24 4:05 PM, Alex Turner wrote:
Interoperability and Compatibility
The Aggregation Service (used to process the aggregatable reports) typically allows its releases to be used for up to six months. To reduce the compatibility impact of this change, we are waiting until all current Aggregation Service releases support the new version before rolling to Stable.
Can you say more about this? How many parties are running these services, and do we have any way of knowing what the uptake of new versions is, or said differently - can we tell if they're still on older versions?
Also, what happens if you send the filter ID to an older version?
The Aggregation Service in general has a six-month support schedule, i.e. attempts to use a release more than six months after it was released will fail. Currently, there are three Aggregation Service releases that are available for use (2.3, 2.4, 2.5). All previous releases (2.2 and before) have already reached end-of-support and can no longer be used.
I see - thanks. Just a few more questions to help me understand:
There's mention of an image hash allowlist - presumably this is how you enforce versioning on the server side. Is that correct?
Release 2.3 does not support the new report format, but we have announced it will reach end-of-support on August 2nd, i.e. before M128 reaches Stable. (Note that we have already enabled the feature on Canary for testing.) Attempting to process reports with the new “1.0” report version on this release will result in the aggregation job failing with a descriptive error message. In this case, however, no budget will be consumed and the aggregation can be re-attempted (either on a newer release or after excluding the “1.0” reports).
Release 2.4 supports the new report format, but it does not allow for filtering_ids to be specified for the aggregation; the default value ([0]) is always used. On this release, existing flows that do not use the new feature will be unaffected by the report version change.
Release 2.5 supports the new report format and allows filtering_ids to be specified for the aggregation. Developers who want to use the new feature should upgrade to this release.
We don't currently have metrics on usage of each Aggregation Service release, but plan to add those. Still, we have notified partners of these considerations through the API mailing lists. We'll also remind partners of the upcoming end-of-support.
Thanks for the public comms - having some form of telemetry for aggregation service versions in the wild does seem useful.
thanks,
Mike
Alex Turner
On 7/12/24 10:44 AM, Alex Turner wrote:
On Wed, Jul 10, 2024 at 11:25 AM Mike Taylor <mike...@chromium.org> wrote:
On 7/8/24 4:05 PM, Alex Turner wrote:
Interoperability and Compatibility
The Aggregation Service (used to process the aggregatable reports) typically allows its releases to be used for up to six months. To reduce the compatibility impact of this change, we are waiting until all current Aggregation Service releases support the new version before rolling to Stable.
Can you say more about this? How many parties are running these services, and do we have any way of knowing what the uptake of new versions is, or said differently - can we tell if they're still on older versions?
Also, what happens if you send the filter ID to an older version?
The Aggregation Service in general has a six-month support schedule, i.e. attempts to use a release more than six months after it was released will fail. Currently, there are three Aggregation Service releases that are available for use (2.3, 2.4, 2.5). All previous releases (2.2 and before) have already reached end-of-support and can no longer be used.
I see - thanks. Just a few more questions to help me understand:
There's mention of an image hash allowlist - presumably this is how you enforce versioning on the server side. Is that correct?
Why doesn't this count as a breaking change, per your wiki page? Or the idea is you don't need to rev the major version number because it will be unsupported before this feature is usable in Chrome stable?Release 2.3 does not support the new report format, but we have announced it will reach end-of-support on August 2nd, i.e. before M128 reaches Stable. (Note that we have already enabled the feature on Canary for testing.) Attempting to process reports with the new “1.0” report version on this release will result in the aggregation job failing with a descriptive error message. In this case, however, no budget will be consumed and the aggregation can be re-attempted (either on a newer release or after excluding the “1.0” reports).
When attempting to process the new “1.0” reports, the old Aggregation Service releases (2.3 and before) error out and the new releases (2.4+) succeed. So, we consider that new support to be backwards compatible server-side.
And when attempting to additionally specify custom filtering_ids on the server, Aggregation Service release 2.4 doesn’t let you (always uses the default, discussed below in more detail), while release 2.5 does let you. So, that change should also count as backwards compatible.
Separately, there’s a question of whether the browser-side API change (to change the report version/format) is backwards compatible. While Aggregation Service release 2.3 is available, it is a breaking change. But, it will be backwards compatible once all current Aggregation Service releases support the report version (before M128 Stable).
This also feels like a breakage change to me - if I'm using a supported service version, but I can't use the updated report version because I will get unexpected/inconsistent behavior with 2.5.Release 2.4 supports the new report format, but it does not allow for filtering_ids to be specified for the aggregation; the default value ([0]) is always used. On this release, existing flows that do not use the new feature will be unaffected by the report version change.
So, any existing flows that don’t care about the new filtering ID feature will behave exactly as before – all contributions are processed as they all have the default filtering ID of 0. Additionally, 2.4 and 2.5 have consistent behavior when no IDs are specified server-side. But, if you want to process histogram contributions with other/non-default filtering IDs, you need to upgrade to 2.5 as those contributions will always be ignored in 2.4.
Mike Taylor
LGTM1
On Mon, Jul 15, 2024 at 11:03 AM Mike Taylor <mike...@chromium.org> wrote:
On 7/12/24 10:44 AM, Alex Turner wrote:
On Wed, Jul 10, 2024 at 11:25 AM Mike Taylor <mike...@chromium.org> wrote:
On 7/8/24 4:05 PM, Alex Turner wrote:
Interoperability and Compatibility
The Aggregation Service (used to process the aggregatable reports) typically allows its releases to be used for up to six months. To reduce the compatibility impact of this change, we are waiting until all current Aggregation Service releases support the new version before rolling to Stable.
Can you say more about this? How many parties are running these services, and do we have any way of knowing what the uptake of new versions is, or said differently - can we tell if they're still on older versions?
Also, what happens if you send the filter ID to an older version?
The Aggregation Service in general has a six-month support schedule, i.e. attempts to use a release more than six months after it was released will fail. Currently, there are three Aggregation Service releases that are available for use (2.3, 2.4, 2.5). All previous releases (2.2 and before) have already reached end-of-support and can no longer be used.
I see - thanks. Just a few more questions to help me understand:
There's mention of an image hash allowlist - presumably this is how you enforce versioning on the server side. Is that correct?
Yep, exactly.Why doesn't this count as a breaking change, per your wiki page? Or the idea is you don't need to rev the major version number because it will be unsupported before this feature is usable in Chrome stable?Release 2.3 does not support the new report format, but we have announced it will reach end-of-support on August 2nd, i.e. before M128 reaches Stable. (Note that we have already enabled the feature on Canary for testing.) Attempting to process reports with the new “1.0” report version on this release will result in the aggregation job failing with a descriptive error message. In this case, however, no budget will be consumed and the aggregation can be re-attempted (either on a newer release or after excluding the “1.0” reports).
The Aggregation Service versioning scheme applies to server-side changes only. That is, a breaking change is one that would require an active migration for a partner when they update their Aggregation Service release. As the processing changes on the server are backwards compatible (more detail below), we haven't updated the major version.
When attempting to process the new “1.0” reports, the old Aggregation Service releases (2.3 and before) error out and the new releases (2.4+) succeed. So, we consider that new support to be backwards compatible server-side.
