Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Hide the true number of aggregatable reports #439

Closed
csharrison opened this issue May 23, 2022 · 4 comments · Fixed by #749
Closed

Hide the true number of aggregatable reports #439

csharrison opened this issue May 23, 2022 · 4 comments · Fixed by #749

Comments

@csharrison
Copy link
Collaborator

csharrison commented May 23, 2022 •
edited
Loading

This issue tracks the open question the aggregatable explainer:
https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md#hide-the-true-number-of-attribution-reports

To solve this, I believe we will need to have a mechanism that allows us to either randomize the true number of attribution reports, or make it a function of non-sensitive information (e.g. the # of unattributed trigger pings).

The presence or absence of an attribution report leaks some potentially sensitive cross-site data in the current design. Therefore, revealing the total count of reports to the reporting origin could leak something sensitive as well (imagine if the reporting origin only ever registered a conversion or impression for a single user).

To hide the true number of reports, we could:

- Unconditionally send a null report for every registered attribution trigger (thus making the count a function of only destination-side information)
- Add noise to the number of reports by having some clients randomly add noisy null reports. This technique would have to assume some threshold number of unattributed triggers to maintain privacy.
@csharrison csharrison mentioned this issue May 23, 2022
Merged
@alois-bissuel alois-bissuel mentioned this issue Oct 12, 2022
Open
@bmayd
Copy link

bmayd commented Oct 24, 2022

I'm having difficulty understanding the threat posed by including source site is, @csharrison could someone provide an illustrative example?

@csharrison
Copy link
Collaborator Author

Imagine you sign into shoes.com to buy shoes, so they know who you are. Now imagine shoes.com is malicious and wants to track you. They could do this in the current API by only registering triggers for you.

If they do this, then shoes.com, can learn the noiseless count of your attributed conversions by simply counting the number of encrypted reports flowing through the API.

@bmayd
Copy link

bmayd commented Oct 31, 2022

I'm still not understanding the issue. When a signed-in user does something at shoes.com, shoes.com can make a detailed recording of the activity and it isn't clear what more they learn by knowing that some of those interactions is counted as a conversion by the API.

@csharrison
Copy link
Collaborator Author

I added this to our agenda today to explain this a bit deeper if it's helpful.

it isn't clear what more they learn by knowing that some of those interactions is counted as a conversion by the API

The new information is the relative publisher-side information that is embedded in an attribution report, since currently we only send an aggregatable report if there was a pending source registration that happened prior. The set of unattributed triggers and attribution reports are not the same size.

This was referenced Mar 28, 2023
Closed
Closed
@csharrison csharrison mentioned this issue Apr 14, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
2 participants
@csharrison @bmayd