Is output domain files mandatory in Aggregation Service?

[k-o-ta]

In my use case, I want to receive the summary report including all keys(buckets) inputted to Aggregation Service.
Is there a way to skip using output domain files, or wildcard syntax which enable to accept all keys(buckets)?

By the way, what is a purpose of output domain files, reducing load of Aggregation Service or protecting user's privacy?

[csharrison]

Hello @k-o-ta , this is currently necessary for protecting the user's privacy. There is some discussion of an alternative privacy mechanism in #583 to support the "key discovery" use-case you describe.

Would you mind sharing the use-case where specifying the output domain is challenging to you?

[k-o-ta]

Thanks for the quick reply!
I(as a DSP) am considering using summary report as ad performance report for all customers(advertisers). In this case, all keys(buckets) are needed.
When reports are grouped by CampaignID, I think of two choices.

1. Preparing output domain files including all CampaignIDs. When a new campaign is created, add the CampaignID to output domain files.
   • This means we must maintain CampaignIDs list apart from Campaign Database.
2. When receive a triggering attribution, update the output domain file.

If I can skip filtering summary reports by keys(buckets), I can omit such as those above and reduce the maintenance cost.

I created this issue because I didn't know that output domain files is necessary for protecting the user's privacy. Is there a document which explains how output domain files protect the use's privacy?

[csharrison]

Thanks for explaining, @k-o-ta . I understand how (1) works, but for (2) how do you know the campaign at trigger time? Isn't that a function of the ad served?

With respect to the privacy, I don't know if we have a great document explaining this, but at a high level the reason we ask you to specify the output domain is to protect against an attack where the presence of a key in the output reveals something about a single user / event. For example, if you only showed a campaign to one user, receiving a key in the output (even with noise) reveals that that user later converted. By specifying this domain beforehand, we can be sure that it does not reveal anything about the user contributions.

Typically, key discovery mechanisms which do not require specifying an output domain (like those that are being discussed in #583) involve some form of thresholding to protect against that attack. You can see this document for an example algorithm:
https://github.com/google/differential-privacy/blob/main/common_docs/Delta_For_Thresholding.pdf

[k-o-ta]

Thank you for explaining!

As you say, I can't know CampaignID at trigger time (without 3rd party cookies)! I had made misunderstanding.

Let me clarify my understanding. Is specifying domains beforehand for maintaining differential privacy ? (I referred to this doc.)

[csharrison]

Let me clarify my understanding. Is specifying domains beforehand for maintaining differential privacy ?

Yes this is one purpose of specifying the domain, because differential privacy cares about preventing this attack I mentioned above. There are techniques to achieve DP without specifying the domain but they typically involve some thresholding step.

[csharrison]

Hey @k-o-ta I am going to close this issue in favor of the existing #333 which I think is touching on the exact issue you're hitting. Let's continue any other conversation there.