Intent to Ship: Private Aggregation API

[Alex Turner]

Contact emails

ale...@chromium.org

Explainer

https://github.com/patcg-individual-drafts/private-aggregation-api

Specification

https://patcg-individual-drafts.github.io/private-aggregation-api

Summary

A generic mechanism for measuring aggregate, cross-site data in a privacy preserving manner. The potentially identifying cross-site data is encapsulated into "aggregatable reports". To prevent leakage, this data is encrypted, ensuring it can only be processed by the aggregation service. During processing, this service will add noise and impose limits on how many queries can be performed.

Blink component

Blink>PrivateAggregation

TAG review

https://github.com/w3ctag/design-reviews/issues/846

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal specific to Private Aggregation (https://github.com/mozilla/standards-positions/issues/805). However 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)

Web developers: Developers have shown interest in the API both for cross-site use cases through Shared Storage and for Protected Audience aggregate reporting and have engaged on GitHub[1]. For Shared Storage, multiple testers have publicly flagged their interest via the public Shared Storage Testers List [2].

[1] https://github.com/patcg-individual-drafts/private-aggregation-api/issues

[2] https://github.com/WICG/shared-storage/blob/main/shared-storage-tester-list.md

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?

No

Debuggability

The proposal includes a temporary debugging mechanism to facilitate testing and integration. An internals page (chrome://private-aggregation-internals) is also available to view the status of pending and sent reports.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

All but WebView

Is this feature fully tested by web-platform-tests?

Reports sent through the API are subject to large delays and require overriding a public key endpoint. Some end-to-end tests are currently internal web tests. Where possible, tests are external and we are proposing new WebDriver APIs to support testing via web-platform-tests. Tests for the integration with Protected Audience are in-progress and should land soon.

Flag name

privacy-sandbox-ads-apis

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1316659

Launch bug

https://crbug.com/1292756

Estimated milestones

We intend to start an incremental ramp towards 100% in Stable starting with M115.

Anticipated spec changes

A few changes to current behavior are expected including tying debug mode to third-party cookie eligibility (issue) and padding the encrypted payload (issue). Extensions to the API to support multiple aggregation services, enable Protected Audience report verification, and allow arrays of contributions (issue) are also expected and are purely additive. The JS interface for all of these changes will be backwards compatible with the current API.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5743412790689792

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiFkKSt4YBNUn2h42G3z%2BqjwxjFAo%3DsPnrbvvOoNaDa_aAQ%40mail.gmail.com Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiF%3DKQYXEVn%3DB4rMabH14UdYyA%2BF8qQkWyUVPB0rypS1N0Q%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Rick Byers]

Thanks for working to enable more automation here, and putting what you can in WPT today. I think it's reasonable to pursue this in parallel. Are you looking for approval for the WebDriver API addition now too (still a PR), or happy to send a separate I2S for that when you're ready to ship it? +mat...@chromium.org and team can advise on extending webdriver. 

Flag name

privacy-sandbox-ads-apis

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1316659

Launch bug

https://crbug.com/1292756

Estimated milestones

We intend to start an incremental ramp towards 100% in Stable starting with M115.

Anticipated spec changes

A few changes to current behavior are expected including tying debug mode to third-party cookie eligibility (issue) and padding the encrypted payload (issue). Extensions to the API to support multiple aggregation services, enable Protected Audience report verification, and allow arrays of contributions (issue) are also expected and are purely additive. The JS interface for all of these changes will be backwards compatible with the current API.

Thanks. Skimming the open issues I see at least one which sounds like it would be a non-trivial breaking change. Are there others? Do you want to drive such issues to resolution (one way or the other) prior to shipping or make the case for why a breaking change will be doable (eg. a practical v2 migration strategy)?

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5743412790689792

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiFkKSt4YBNUn2h42G3z%2BqjwxjFAo%3DsPnrbvvOoNaDa_aAQ%40mail.gmail.com Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiF%3DKQYXEVn%3DB4rMabH14UdYyA%2BF8qQkWyUVPB0rypS1N0Q%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

--
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%2BBiFk4cb%2Bi69Symy-KCjHbtquGSQCn5scXy_YMSSWGut2vJw%40mail.gmail.com.

[Yoav Weiss]

Thanks for catching that. That issue was effectively resolved, but spun up other (in-thread) discussions. I now closed it and suggested the discussions would be spun up to their own issues (#70 is a backwards compatible ergonomics change still remaining). 

Are there others? Do you want to drive such issues to resolution (one way or the other) prior to shipping or make the case for why a breaking change will be doable (eg. a practical v2 migration strategy)?

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5743412790689792

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiFkKSt4YBNUn2h42G3z%2BqjwxjFAo%3DsPnrbvvOoNaDa_aAQ%40mail.gmail.com Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiF%3DKQYXEVn%3DB4rMabH14UdYyA%2BF8qQkWyUVPB0rypS1N0Q%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

--
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%2BBiFk4cb%2Bi69Symy-KCjHbtquGSQCn5scXy_YMSSWGut2vJw%40mail.gmail.com.

--
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/CAFUtAY-OqR3nG8ghb0k2hGamf-76uVH%3DkYjhNGQi6mN84GjUzg%40mail.gmail.com.

[Alex Turner]

Yeah, I think it makes sense to consolidate these together unless there are concerns with that approach. Thanks!

[Yoav Weiss]

I wanted to comment on this intent with my spec mentor hat on. I reviewed this specification and provided feedback to its authors.

My main point of feedback was around its layering and how it relates to the other 2 specifications (Shared Storage and Protected Audience) that use the infrastructure that it defines. My feedback was properly addressed, and the specification was re-written such that it's unaware of its users, and its users are calling its algorithms, rather than the other way around.

There's still work to be done to move the user algorithms from monkeypatch sections in this spec to their respective specifications, but I wouldn't consider that a blocker and I trust the team to do that soon.

Beyond that, feedback around naming was addressed and I believe that ergonomics feedback can be addressed in a backwards compatible manner.

As is, I believe the specification is in good shape to be implemented interoperably. I also believe the team is committed to improve it further on the (non-blocking) points that are still outstanding. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiF%3DAHzyktAiGjp_gbpj6aEiHdukRr%3DUfS5JGqzv3q8T%2Bcw%40mail.gmail.com.

[Rick Byers]

On Mon, Jun 26, 2023 at 12:32 PM Yoav Weiss <yoav...@chromium.org> wrote:

I wanted to comment on this intent with my spec mentor hat on. I reviewed this specification and provided feedback to its authors.

My main point of feedback was around its layering and how it relates to the other 2 specifications (Shared Storage and Protected Audience) that use the infrastructure that it defines. My feedback was properly addressed, and the specification was re-written such that it's unaware of its users, and its users are calling its algorithms, rather than the other way around.

There's still work to be done to move the user algorithms from monkeypatch sections in this spec to their respective specifications, but I wouldn't consider that a blocker and I trust the team to do that soon.

Beyond that, feedback around naming was addressed and I believe that ergonomics feedback can be addressed in a backwards compatible manner.

As is, I believe the specification is in good shape to be implemented interoperably. I also believe the team is committed to improve it further on the (non-blocking) points that are still outstanding. 

Thanks Yoav for the spec mentorship summary.

Ok. Just discussed in the API owners meeting. Can you please get someone with webdriver spec experience (eg. @mat...@chromium.org) to review the PR? If the PR lands with such a review, then we can include it here. But if that ends up taking too long, then we suggest splitting it out for a follow-up - it doesn't need to block this feature overall.

Flag name

privacy-sandbox-ads-apis

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1316659

Launch bug

https://crbug.com/1292756

Estimated milestones

We intend to start an incremental ramp towards 100% in Stable starting with M115.

Anticipated spec changes

A few changes to current behavior are expected including tying debug mode to third-party cookie eligibility (issue) and padding the encrypted payload (issue). Extensions to the API to support multiple aggregation services, enable Protected Audience report verification, and allow arrays of contributions (issue) are also expected and are purely additive. The JS interface for all of these changes will be backwards compatible with the current API.

Thanks. Skimming the open issues I see at least one which sounds like it would be a non-trivial breaking change. Are there others? Do you want to drive such issues to resolution (one way or the other) prior to shipping or make the case for why a breaking change will be doable (eg. a practical v2 migration strategy)?

Can you do a quick pass over open issues looking for any others with future compat risk (i.e. potential future breaking changes) and label them as such?

[Alex Turner]

Sounds good to me! I'll start that process now.

 

Flag name

privacy-sandbox-ads-apis

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1316659

Launch bug

https://crbug.com/1292756

Estimated milestones

We intend to start an incremental ramp towards 100% in Stable starting with M115.

Anticipated spec changes

A few changes to current behavior are expected including tying debug mode to third-party cookie eligibility (issue) and padding the encrypted payload (issue). Extensions to the API to support multiple aggregation services, enable Protected Audience report verification, and allow arrays of contributions (issue) are also expected and are purely additive. The JS interface for all of these changes will be backwards compatible with the current API.

Thanks. Skimming the open issues I see at least one which sounds like it would be a non-trivial breaking change. Are there others? Do you want to drive such issues to resolution (one way or the other) prior to shipping or make the case for why a breaking change will be doable (eg. a practical v2 migration strategy)?

Can you do a quick pass over open issues looking for any others with future compat risk (i.e. potential future breaking changes) and label them as such?

 

Just did a pass and added labels. I've also added a brief comment to each issue marked "compat" with some detail on the risk/possible mitigations. Thanks!

[Rick Byers]

FWIW Mathias was on vacation this week but is back next week (but I'm out). Hopefully you two can connect and agree on the path here. Having automation support for testing usage of this feature makes sense to me generally, so hopefully the question is just around the details of the mechanics.

Flag name

privacy-sandbox-ads-apis

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1316659

Launch bug

https://crbug.com/1292756

Estimated milestones

We intend to start an incremental ramp towards 100% in Stable starting with M115.

Anticipated spec changes

A few changes to current behavior are expected including tying debug mode to third-party cookie eligibility (issue) and padding the encrypted payload (issue). Extensions to the API to support multiple aggregation services, enable Protected Audience report verification, and allow arrays of contributions (issue) are also expected and are purely additive. The JS interface for all of these changes will be backwards compatible with the current API.

Thanks. Skimming the open issues I see at least one which sounds like it would be a non-trivial breaking change. Are there others? Do you want to drive such issues to resolution (one way or the other) prior to shipping or make the case for why a breaking change will be doable (eg. a practical v2 migration strategy)?

Can you do a quick pass over open issues looking for any others with future compat risk (i.e. potential future breaking changes) and label them as such?

 

Just did a pass and added labels. I've also added a brief comment to each issue marked "compat" with some detail on the risk/possible mitigations. Thanks!

I reviewed the current state of all these and it looks pretty low-risk to me. Alex / Yoav, any decisions there you think this I2S should still be blocked on?

[عبد الله رتيبة‎]

مرحبا

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-m1k7ggckvAPCM%2Br1xbefkspOHhRf_O-a7b0LgDKOkqQ%40mail.gmail.com.

[Alex Turner]

I'll follow up with him on Monday, but I don't expect any major changes. Note also that we've aligned the Private Aggregation spec change with Attribution Reporting's section. 

 

Flag name

privacy-sandbox-ads-apis

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1316659

Launch bug

https://crbug.com/1292756

Estimated milestones

We intend to start an incremental ramp towards 100% in Stable starting with M115.

Anticipated spec changes

A few changes to current behavior are expected including tying debug mode to third-party cookie eligibility (issue) and padding the encrypted payload (issue). Extensions to the API to support multiple aggregation services, enable Protected Audience report verification, and allow arrays of contributions (issue) are also expected and are purely additive. The JS interface for all of these changes will be backwards compatible with the current API.

Thanks. Skimming the open issues I see at least one which sounds like it would be a non-trivial breaking change. Are there others? Do you want to drive such issues to resolution (one way or the other) prior to shipping or make the case for why a breaking change will be doable (eg. a practical v2 migration strategy)?

Can you do a quick pass over open issues looking for any others with future compat risk (i.e. potential future breaking changes) and label them as such?

 

Just did a pass and added labels. I've also added a brief comment to each issue marked "compat" with some detail on the risk/possible mitigations. Thanks!

I reviewed the current state of all these and it looks pretty low-risk to me. Alex / Yoav, any decisions there you think this I2S should still be blocked on?

I agree -- I think all the remaining decisions there are low enough risk to not be blocking. Yoav, does that seem right to you?

[Yoav Weiss]

I agree that any potential future changes resulting from the open issues would be backwards compatible, so shouldn't block this intent.

[Mathias Bynens]

Thank you for including a WebDriver extension for this; I’ve left some review feedback on the PR. Overall, I wanted to voice my support for pursuing the Web Platform feature (and this Intent) separately from the WebDriver extension, as long as you’re confident in the testing strategy — no need to block on it.

[Alex Turner]

As a quick update, the WebDriver extension PR has now landed. (Thanks Mathias for the review!) So, it should be safe to include that change as part of this I2S.

[Mike Taylor]

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA%2BBiFnqCQwMRYXyg844shcZ1XgFCnubyNm%2Bf4NFGJTmro0sJg%40mail.gmail.com.

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7cbbe10d-5d1b-8e81-6d3a-9958ddc40460%40chromium.org.

[Yoav Weiss]

LGTM3