Hide the true number of aggregatable reports

[csharrison]

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.

[bmayd]

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

[csharrison]

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]

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]

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.