-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Aggregate measurement with the Private Aggregation API #13
Comments
I would suggest to add this to this agenda for the upcoming PATCG meeting next week. I think this type of API infra is essential for many of the proposals. |
@AramZS Would it be acceptable to move this explainer to the Individual Drafts space? Thanks for the help |
@AramZS friendly ping :) |
@AramZS friendly ping on if we can move this explainer to the Individual Drafts space |
@alexmturner You should have an invite now to join that org and that will let you to open a new repo and add the document to that space. |
Thanks! Moved it over |
Problem
Browsers are now working to prevent cross-site user tracking, including by partitioning storage and removing third-party cookies. There are a range of API proposals to continue supporting legitimate use cases in a way that respects user privacy. Many of these proposals, including Shared Storage and TURTLEDOVE, plan to isolate potentially identifying cross-site data in special contexts, which ensures that the data cannot escape the user agent.
Relative to cross-site data from each user, aggregate, noisy data can leak less information about individual users, and yet would be sufficient for a wide range of use cases that rely on third-party cookies today (e.g. reach measurement).
Proposal summary
This API proposal introduces a generic mechanism for measuring aggregate, cross-site data in a privacy-preserving manner. In particular, this would be available in isolated contexts that have access to cross-site data (such as a Shared Storage worklet).
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 an aggregation service (e.g. this proposal) that will aggregate the reports, add noise and limit how many queries can be performed. This service was originally proposed for use by the Attribution Reporting API, but allowing more general aggregation would support additional use cases.
Explainer
More detail about the proposal is available in an explainer. I’d be happy to move this explainer to the PATCG Individual Drafts org (once I have the necessary permissions).
The text was updated successfully, but these errors were encountered: