From 1e6d62f98187a9f7594abd4ba1ec1509f6fe86d2 Mon Sep 17 00:00:00 2001 From: Alex Turner Date: Thu, 13 Jul 2023 14:40:40 -0400 Subject: [PATCH] Clarify the intended contribution bounds (#84) The current wording is a little confusing. --- README.md | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index a78053f..9792cd5 100644 --- a/README.md +++ b/README.md @@ -31,6 +31,7 @@ Author: Alex Turner (alexmt@chromium.org) - [Scaling values](#scaling-values) - [Examples](#examples-1) - [Partition choice](#partition-choice) + - [Implementation plan](#implementation-plan) - [Future Iterations](#future-iterations) - [Supporting different aggregation services](#supporting-different-aggregation-services) - [Shared contribution budget](#shared-contribution-budget) @@ -441,16 +442,14 @@ noise, aiming to have a framework that could support differential privacy. However, simply protecting each _query_ to the aggregation service or each _report_ sent from a user agent would be vulnerable to an adversary that repeats queries or issues multiple reports, and combines the results. Instead, we -propose the following. +propose the following structure. See [below](#implementation-plan) for the +specific choices we have made in our current implementation. First, each user agent will limit the contribution that it could make to the output of a query. In the case of a histogram operation, the user agent could bound the L1 norm of the _values_, i.e. the sum of all the contributions across all buckets. The user agent could consider other bounds, -e.g. the L2 norm. We initially plan to use an L1 bound of -216 = 65 536; this aligns with the [Attribution Reporting API with -Aggregatable Reports -explainer](https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md#privacy-budgeting). +e.g. the L2 norm. The user agent would also need to determine what the appropriate 'partition' is for this budgeting, see [partition choice](#partition-choice) @@ -495,8 +494,7 @@ scale. The examples below explore this in more detail. #### Examples -These examples use the L1 bound of 216 = 65 536 as -proposed above. +These examples use an L1 bound of 216 = 65 536. Let's consider a basic measurement case: a binary histogram of counts. For example, using bucket 0 to indicate a user is a member of some group and bucket @@ -543,12 +541,18 @@ from dedicated adversaries, but is essential for utility. Other options for recovering from an exhausted budget may be possible but need further exploration, e.g. allowing a site to clear its data to reset its budget. +#### Implementation plan + We plan to enforce a per-[site](https://web.dev/same-site-same-origin/#site) budget that resets every 10 minutes; that is, we will bound the contributions -that any site can make to a histogram over any 10 minute window. As a backstop -to limit worst-case leakage, we plan a separate, looser per-site bound that -resets daily, limiting the daily L1 norm to 220 -= 1 048 576. +that any site can make to a histogram over any 10 minute rolling window. We plan +to use an L1 bound of 216 = 65 536 for this bound; this +aligns with the [Attribution Reporting API with Aggregatable Reports +explainer](https://github.com/WICG/conversion-measurement-api/blob/main/AGGREGATE.md#privacy-budgeting). + +As a backstop to limit worst-case leakage, we plan a separate, looser per-site +bound that is enforced on a 24 hour rolling window, limiting the daily +L1 norm to 220 = 1 048 576. This site will match the site of the execution environment, i.e. the site of the reporting origin, no matter which top-level sites are involved. For the earlier