#846: Private Aggregation API

Visit on Github.

Opened May 19, 2023

こんにちは 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.

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

Discussions

2023-07-03

Minutes

Yves: No activity (from us) at all. Using added noise + rate limiting to reduce the privacy issue

Yves: work done in PATCG... might surface in a coming working group...

Hadley: the mozilla position on shared storage (linked) is negative.

Dan: so this has a dependency on shared storage...

2023-07-mos-eisley

Minutes

Tess: there's 2 approaches - event level and aggregate level - in both cases there are 2 or 3 competing proposals right now. I am hoping all the event level stuff coaleces into one approach and all the aggregate level stuff coalesces into another. There is some skepticism from some PatCG participants about event level as a whole. The "event" is the conversion - you click on an ad. Does the ad provider get a report of the conversion or just an aggregate report? Mozilla's pretty convinced that it's impossible to do event level with privacy preserving... Other people attempted to demonstrate with a mathematical proof that the amount of info exposed was riskier.

Dan: where does pcm fit?

Tess: PCM is one of the proposals for an event level solution? It shares a bunch of API surface with google's thing. Possibly attribution reporting API?

Dan: yes, that is where I left the feedback a year ago about the different names of different things and asking if there is convergence.

In Feb Charlie Harrison from Google asked us to look at it again.

So this (the attribution reporting API) is Google's overall level proposal.

Private aggregation is also from Google, but we haven't commented on it yet. They are spliiting out the aggregation of the attribution reporting api and making it a new thing.

2023-08-21

Minutes

Dan: Lots of proposals in this space...

Rossen: Hard to figure out the overlapping / competing functionality

Dan: IPA has meta and mozilla working together.. private aggregation is google.. private click measurement is apple (not submitted for tag review but is implemented).. and attribution reporting (google). Some may or may not have a relationship with protected audience?

Amy: and shared storage

Dan: in attribution reporting, 3 weeks ago we asked how it relates to this one.. I'd like an explainer on how these things fit together.

Amy: ... protected audience, topics .. all use specialist language - specific to the ad tech industry - we should ask for any explainer to not use this kind of language, it's very complex and there's a lot of nuance

Hadley: e.g. difference between targeted advertising vs remarketing

Dan: we dont' need to become adtech experts in order to understand. They need to limit their use of terms of art from the adtech world to explain them from a web development perspective

Hadley: agree

Rossen: agree. To better understand are these apis useable only for adtech, or for something else? To me that's unclear.

Amy: we could ask the PATCG to put together a comparison matrix, and various stakeholders can fill it in for their specs. I'm not sure exactly what would go in the matrix, they're better placed to provide that

Dan: who is representing them?

Hadley: Aram Zucker-Scharff and Sean Turner. They have a mailing list.

Yves: was thinking of Nick Doty..

Dan: [emails Nick]

2023-09-25

Minutes

Dan: Shares doc from patcg

Tess: we asked the patcg to help us understand the difference between different proposal. In patcg we used this spreadsheet to drive some discussions in TPAC as well..

Dan: where does Privacte Aggregation API fit in?

Tess: actually there is another spreadsheet...

Dan: asks for further clarity

2023-10-23

Minutes

Hadley: they're intending to ship enhancements.. don't look like massive changes to the overall api, but we haven't given a clear response on that... I would like to talk to Tess about this

2024-06-24

Minutes

https://github.com/mozilla/standards-positions/issues/805#issuecomment-2164513098

Punt to plenary, need help with this one.

2024-08-19

Minutes

First attempt:

We appreciate you bringing this to us. The relationship with the aggregated attribution proposals is particularly difficult. The PAT[CW]G is working on the synthesis of three different proposals. We'd like to encourage you to spend time on the convergence of those proposals.

The additional value that comes from a more generic version of the same mechanism is where this is most challenging. We recognize that value of generic features, but insist that they be justified by their use cases. The TAG has already come to a conclusion about Protected Audience (#723), which is one of the identified uses of this. We find the building of market demographics across sites to be insufficiently compelling as a justification.

With that all in mind, we're going to decline this review.

Jeffrey's improved version, minus EWM:

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 attribution 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.

2024-08-19

Minutes

Hadley: following a trail of links... we encouraged them to engage with PATCG about a month ago. Does this apply here?

Peter: we declined attribution reporting and encouraged a more single consensus based approach. This might be that. This is coming from PATCG. Anyone have more context?

Yves: Mozilla standards position with a comment from Martin. Would be good to know if it's in PATCG why we are reviewing it right now. Is it still under discusison or do they plan to move to the next step?

Peter: the readme says it has not been adopted by the PATCG. We could say to come back when the PATCG adopt this

Hadley: request also says it's being driven by privacy sandbox

Amy: sounds all out of date

Peter: readme was updated wthin the last month. Strong connection to Protected Audience bothers me a lot. also seems to be all about ads.

Hadley: ...

Peter: Martin is expressing general support for tools to aggregate...

Yves: is it related to firefox doing privacy preserving ad relevance

Peter: guess there isn't any relation

Yves: ..

Peter: intent to ship, and have made changes since the review request. We closed Protected Audience unsatisfied, it's connected.

Yves: if there is a dependency...

Hadley: I think getting consensus out of the PATCG applies

Amy: we could ask Martin/Tess/Jeffrey if they know more about PATCG

Peter: revisit at plenary?

Hadley: I'll ask in core-tag

Tess appears

Tess: last I heard there was an ongoing effort to merge the three proposals and I think i'ts pretty far along but haven't checked in a while

Peter: should we wait to review until things settle down?

Tess: that's what we agreed in Seattle

Peter: there was another one...

Tess: there's three. We shouldn't review any of them.

Peter: chrome intent to ship asking for TAG sign off

Tess: can't they wait until they're combined and ship that..? If it seemed unlikely they were going to converge I'd be all for reviewing all three, but they seem to be figuring out the middle ground themselves

Hadley: and if that were the case the questions asked would be framed differently

Tess: rather hear what Martin has to say before we close

Hadley: up for declining it, but I've asked so give them a chance to reply

2024-08-26

Minutes

Jeffrey: a proposed comment in last week's minutes....

Dan: yes that's why I added it to the agenda today....

Tess: we wanted to check with Jeffrey...

Jeffrey: I checked this comment and I think it has consensus with the TAG and also checked it with the private agg people...

Comment from Slack:

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."

we agree Tess to paste comment and close the issue as decline

Tess: closed