Private Aggregation API

[alexmturner]

こんにちは TAG-さん!

I'm requesting a TAG review of the Private Aggregation API.

This proposal introduces a generic mechanism for measuring aggregate, cross-site data in a privacy preserving manner. This general-purpose API can be called from isolated contexts that have access to cross-site data (such as a Shared Storage worklet). Within these contexts, potentially identifying data is encapsulated into "aggregatable reports". To prevent leakage, the cross-site data in these reports is encrypted to ensure it can only be processed by the aggregation service. During processing, this service adds noise and imposes limits on how many queries can be performed.

• Explainer¹ (minimally containing user needs and example code): https://github.com/patcg-individual-drafts/private-aggregation-api
• Specification URL: https://patcg-individual-drafts.github.io/private-aggregation-api/ (WIP)
• Tests: WPTs not yet available
• User research: N/A
• Security and Privacy self-review²: https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/security_and_privacy_questionnaire.md
• GitHub repo (if you prefer feedback filed there): https://github.com/patcg-individual-drafts/private-aggregation-api
• Primary contacts (and their relationship to the specification):
  • Alex Turner (@alexmturner), Google
  • John Delaney (@johnivdel), Google
• Organization(s)/project(s) driving the specification: Google Chrome, Privacy Sandbox
• Key pieces of existing multi-stakeholder review or discussion of this specification: This API has already been brought for review as part of the Shared Storage design review and the Protected Audience (then TURTLEDOVE) design review.
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5743412790689792

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines:
• The group where the work on this specification is currently being done: PATCG (Individual Drafts)
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): PATWG (assuming eventual creation)
• Major unresolved issues with or opposition to this specification: Concerns have been raised in the Shared Storage and Protected Audience design reviews (linked above). Mozilla has a Negative position on Shared Storage (link).
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

☂️ open a single issue in our GitHub repo for the entire review

[shivanigithub]

FYI, Chrome plans to start gating private aggregation reports behind the enrollment and attestation mechanism. (enrollment explainer, spec section with note on enrollment)

[alexmturner]

Fyi, there is a follow-up I2S making a few changes/extensions to this proposal: https://groups.google.com/a/chromium.org/g/blink-dev/c/cNK_uuCaNMs/

[alexmturner]

Note also this additional follow-up I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/kze4FiMsZTY

[hober]

We appreciate you bringing this to us. We see that Chromium has already shipped this API, so this comment primarily applies to your efforts to bring it to other browsers. We understand this to be a generalization of the three advertising attribution proposals that the PAT[CW]G is working to unify, and we think it'll be most productive to finish that work before refining this generalization.

We recognize that it's usually beneficial to generalize features, but when those features come with privacy risks, we think it's important to balance those risks against the value of the additional use cases. This explainer only identifies two additional use cases. One of these is Protected Audience, about which the TAG has already expressed concerns (#723). We did not find the building of market demographics across sites to be sufficiently compelling to justify this whole generalization.

Given that the short term focus should be on finishing the advertising API, we're going to decline this review. However, if more use cases turn up for the generalization, we'd be open to looking at it again.