#846: Private Aggregation API
Discussions
2023-07-03
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
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
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
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...
2023-10-23
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
https://github.com/mozilla/standards-positions/issues/805#issuecomment-2164513098
Punt to plenary, need help with this one.
2024-08-19
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
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
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
OpenedMay 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:
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