Concrete epsilon values

[martinthomson]

I'm having an awfully hard time trying to work out what epsilon ($\varepsilon$) is used in Google's trials. I can't find it in the documentation here or on developers.google.com. There are old numbers for the attribution API, but those don't obviously translate across.

My poking around in the aggregation-service code only really indicate that a value is not baked into that code. I did learn that this only seems to have Laplacian noise implemented, which in turn suggests that only L1 sensitivity is being applied; that's something.

I found two mentions of a value of 10 as a default, but the explanatory material says that there are two budgets in play. Those also appear to only be for testing purposes; besides, it looks like local testing deployments can pick any value up to 64 (which is awfully large, though 10 is also quite large, depending on the refresh interval; 10 every 10 minutes provides no meaningful privacy).

Given that the privacy properties of this API depend on this value a great deal, documenting this value is essential.

[menonasha]

For the Private Aggregation API, the ε value specified in an aggregation service query corresponds to the L1 contribution budget of 2^16 that is enforced on a rolling 10 minute basis. There’s also a 'backstop' L1 contribution budget of 2^20 that is enforced on a rolling 24 hour basis. So essentially, the privacy parameter is ε on a rolling 10 minute basis, and is 16ε on a rolling 24 hour basis (rather than 144ε).

Aggregation service currently supports a range of ε for testing (up to 64) to allow for experimentation with different aggregation strategies and provide feedback on the utility of the system with different privacy parameters for Private Aggregation and other APIs. We plan to revisit the maximum allowable epsilon value over time as we get feedback from testers and add features that allow for more efficient privacy budget usage.

[martinthomson]

Thanks, that matches what I saw in the code. I was just hoping that the answer would be more concrete.

I recommend that you leave this issue open as a request to resolve on a final, maximum value. That is, unless you want to track this with another issue.