From 58385186807c327791ef4a5f769102a4e34c340f Mon Sep 17 00:00:00 2001 From: "Benjamin M. Case" <35273659+bmcase@users.noreply.github.com> Date: Wed, 3 Sep 2025 12:16:02 -0400 Subject: [PATCH 01/15] add dp assumptions DP assumptions for formal proofs --- api.bs | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/api.bs b/api.bs index d3b170b..33345ac 100644 --- a/api.bs +++ b/api.bs @@ -2338,6 +2338,35 @@ for a number of reasons: Without allocating [=privacy budget=] for new data, sites could exhaust their budget forever. +We operate the system with [=site=] in the [=privacy unit=], but theoretically proving +DP guarantees for this privacy unit requires additional assumptions. +Since different sites are interacting with the same user over time there is not +complete independence between privacy units maintained for the same user which is necessary +for proving the formal DP guarantees. These assumptions capture what would need to be assumed +for these privacy units to be independent and under which the DP guarantees can be proven rigorously. +* Assumption 1: Siloed adaptive data generation. The data stream of the user's impressions +and conversions able to be queried by one site is generated independently from the past query +results of other sites. +* Assumption 2: No leakage through safety limits. The queries from one site do not impact +which reports get filtered for any other site. + +Both of these assumptions are technically not met by the system. By stating them here we +are saying that the API does not protect against privacy leakages that result from them. + +Assumption 1 is a consequence of multiple sites interacting with the same user over time and +changing the ads they show to users based on their use of this system. For example, one advertiser +might learn how to make one of their ads more effective which results in the user converting on +their site rather than on a different site. This impacts the data the other site has available to +query and introduces across site adaptive dependency in how data is generated. + +Assumption 2 is a consequence of having safety limits that span across multiple sites. +If the safety limits are never triggered there is no change in the data available to +be queried across all sites covered by the safety limit. But if as a result of some +sites’ queries causing the safety limit to be reached and start filtering out reports +sent to other sites, there is now a dependence introduced across the data queried under + the separate privacy units. + +See [cite paper] for more details on the formal DP proofs and in depth discussion of these assumptions. ### Browser Instances ### {#dp-instance} From 2e27352d5f6f572f9bcb35046f36f8c8308d920c Mon Sep 17 00:00:00 2001 From: "Benjamin M. Case" <35273659+bmcase@users.noreply.github.com> Date: Thu, 4 Sep 2025 11:24:39 -0400 Subject: [PATCH 02/15] update DP assumptions text --- api.bs | 86 ++++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 57 insertions(+), 29 deletions(-) diff --git a/api.bs b/api.bs index 33345ac..86e07a9 100644 --- a/api.bs +++ b/api.bs @@ -2338,35 +2338,46 @@ for a number of reasons: Without allocating [=privacy budget=] for new data, sites could exhaust their budget forever. -We operate the system with [=site=] in the [=privacy unit=], but theoretically proving -DP guarantees for this privacy unit requires additional assumptions. -Since different sites are interacting with the same user over time there is not -complete independence between privacy units maintained for the same user which is necessary -for proving the formal DP guarantees. These assumptions capture what would need to be assumed -for these privacy units to be independent and under which the DP guarantees can be proven rigorously. -* Assumption 1: Siloed adaptive data generation. The data stream of the user's impressions -and conversions able to be queried by one site is generated independently from the past query -results of other sites. -* Assumption 2: No leakage through safety limits. The queries from one site do not impact -which reports get filtered for any other site. - -Both of these assumptions are technically not met by the system. By stating them here we -are saying that the API does not protect against privacy leakages that result from them. - -Assumption 1 is a consequence of multiple sites interacting with the same user over time and -changing the ads they show to users based on their use of this system. For example, one advertiser -might learn how to make one of their ads more effective which results in the user converting on -their site rather than on a different site. This impacts the data the other site has available to -query and introduces across site adaptive dependency in how data is generated. - -Assumption 2 is a consequence of having safety limits that span across multiple sites. -If the safety limits are never triggered there is no change in the data available to -be queried across all sites covered by the safety limit. But if as a result of some -sites’ queries causing the safety limit to be reached and start filtering out reports -sent to other sites, there is now a dependence introduced across the data queried under - the separate privacy units. - -See [cite paper] for more details on the formal DP proofs and in depth discussion of these assumptions. +### Formal Analysis of Privacy Properties and Their Limitations ### {#formal-analysis} +The paper [[PPA-DP-2]] provides formal analysis of the mathematical privacy guarantees +afforded by per-site budgets and by safety limits . Per-site +budgets include [=site=] in the [=privacy unit=], whereas safety limits exclude it +thereby enforcing a global individual DP guarantee. + +The analysis shows that per-site individual DP guarantees hold under a restricted system + model that makes two assumptions, which may not always be satisfied in practice: + +1. No cross-site adaptivity in data generation. A site’s queryable data stream (impressions +and conversions) must be generated independently of past DP query results from other sites. +2. No leakage through cross-site shared limits. Queries from one site must not affect which +reports are emitted to others. + +Assumption 1 is necessary because the system involves multiple sites that could interact +with the same user over time and change the ads they show to the user, or impact the +conversions the user has, based on each other’s DP measurements. For example, if one advertiser +learns, from DP measurements, to make an ad more effective, a user may convert on their site +rather than a competitor’s. In this case, the first site’s DP outputs -- counted only against +its own per-site budget -- alter the data (or absence of data) visible to the competitor, yet +this impact is not reflected in the competitor’s per-site budget. When Assumption 1 is violated, +the analysis shows that per-site guarantees cannot be achieved. + +Assumption 2 is necessary when we have shared limits that span multiple sites. An example of +such shared limits are the global safety limits that aim to provide a global DP guarantee. +If queries from some sites cause a shared limit to be reached, reports to other sites may be +filtered, creating dependencies across separate per-site privacy units and affecting the validity +of the per-site guarantees. Thus, care must be taken when introducing any new shared limit, such +as cross-site rate limiters on privacy loss. If only Assumption 2 is violated, it is unknown whether +per-site guarantees can still be preserved, for example via special designs of the shared limits. + +These results suggest that per-site protections should be regarded as theoretically grounded approximations +of an ideal per-site individual DP guarantee that can be established only under certain assumptions. +The extent to which privacy protection from per-site budgets may be impacted in practice remains unknown. + +By contrast, the analysis shows that safety limits -- which operate at global level, +excluding [=site=] +from the [=privacy unit=] -- can be implemented to deliver sound global individual DP guarantees +regardless of whether either assumption is satisfied. + ### Browser Instances ### {#dp-instance} @@ -3167,6 +3178,23 @@ spec:structured header; type:dfn; urlPrefix: https://httpwg.org/specs/rfc9651; "href": "https://arxiv.org/abs/2405.16719", "title": "Cookie Monster: Efficient On-device Budgeting for Differentially-Private Ad-Measurement Systems", "publisher": "SOSP'24" + }, + "ppa-dp-2": { + "authors": [ + "Pierre Tholoniat", + "Alison Caulfield", + "Giorgio Cavicchioli", + "Mark Chen", + "Nikos Goutzoulias", + "Benjamin Case", + "Asaf Cidon", + "Roxana Geambasu", + "Mathias Lécuyer", + "Martin Thomson" + ], + "href": "https://arxiv.org/abs/2506.05290", + "title": "Big Bird: Privacy Budget Management for W3C's Privacy-Preserving Attribution API", + "publisher": "arXiv" }, "prio": { "authors": [ From 6fe5c2a14bf7905ebff09cdf37792124d2bd594e Mon Sep 17 00:00:00 2001 From: "Benjamin M. Case" <35273659+bmcase@users.noreply.github.com> Date: Thu, 4 Sep 2025 11:27:30 -0400 Subject: [PATCH 03/15] Update DP assumptions text --- api.bs | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/api.bs b/api.bs index 86e07a9..463124b 100644 --- a/api.bs +++ b/api.bs @@ -2374,9 +2374,8 @@ of an ideal per-site individual DP guarantee that can be established only under The extent to which privacy protection from per-site budgets may be impacted in practice remains unknown. By contrast, the analysis shows that safety limits -- which operate at global level, -excluding [=site=] -from the [=privacy unit=] -- can be implemented to deliver sound global individual DP guarantees -regardless of whether either assumption is satisfied. +excluding [=site=] from the [=privacy unit=] -- can be implemented to deliver sound global individual +DP guarantees regardless of whether either assumption is satisfied. ### Browser Instances ### {#dp-instance} From c997c37839a10eddb8bb46a59058dde35d2cbb88 Mon Sep 17 00:00:00 2001 From: "Benjamin M. Case" <35273659+bmcase@users.noreply.github.com> Date: Thu, 4 Sep 2025 11:40:21 -0400 Subject: [PATCH 04/15] fix format --- api.bs | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/api.bs b/api.bs index 463124b..9afffb1 100644 --- a/api.bs +++ b/api.bs @@ -2340,16 +2340,16 @@ for a number of reasons: ### Formal Analysis of Privacy Properties and Their Limitations ### {#formal-analysis} The paper [[PPA-DP-2]] provides formal analysis of the mathematical privacy guarantees -afforded by per-site budgets and by safety limits . Per-site +afforded by *per-site budgets* and by *safety limits*. Per-site budgets include [=site=] in the [=privacy unit=], whereas safety limits exclude it thereby enforcing a global individual DP guarantee. -The analysis shows that per-site individual DP guarantees hold under a restricted system +The analysis shows that *per-site individual DP guarantees* hold under a restricted system model that makes two assumptions, which may not always be satisfied in practice: -1. No cross-site adaptivity in data generation. A site’s queryable data stream (impressions +1. *No cross-site adaptivity in data generation.* A site’s queryable data stream (impressions and conversions) must be generated independently of past DP query results from other sites. -2. No leakage through cross-site shared limits. Queries from one site must not affect which +2. *No leakage through cross-site shared limits.* Queries from one site must not affect which reports are emitted to others. Assumption 1 is necessary because the system involves multiple sites that could interact @@ -2373,9 +2373,9 @@ These results suggest that per-site protections should be regarded as theoretica of an ideal per-site individual DP guarantee that can be established only under certain assumptions. The extent to which privacy protection from per-site budgets may be impacted in practice remains unknown. -By contrast, the analysis shows that safety limits -- which operate at global level, -excluding [=site=] from the [=privacy unit=] -- can be implemented to deliver sound global individual -DP guarantees regardless of whether either assumption is satisfied. +By contrast, the analysis shows that *safety limits* -- which operate at global level, +excluding [=site=] from the [=privacy unit=] -- can be implemented to deliver *sound global individual +DP guarantees* regardless of whether either assumption is satisfied. ### Browser Instances ### {#dp-instance} From 5b54331cddca4d9f0300b23ae7b982d5f3e4291c Mon Sep 17 00:00:00 2001 From: "Benjamin M. Case" <35273659+bmcase@users.noreply.github.com> Date: Tue, 9 Sep 2025 08:30:20 -0400 Subject: [PATCH 05/15] fmt fixes --- api.bs | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/api.bs b/api.bs index 9afffb1..29b9d8b 100644 --- a/api.bs +++ b/api.bs @@ -2345,11 +2345,11 @@ budgets include [=site=] in the [=privacy unit=], whereas safety limits exclude thereby enforcing a global individual DP guarantee. The analysis shows that *per-site individual DP guarantees* hold under a restricted system - model that makes two assumptions, which may not always be satisfied in practice: +model that makes two assumptions, which may not always be satisfied in practice: 1. *No cross-site adaptivity in data generation.* A site’s queryable data stream (impressions and conversions) must be generated independently of past DP query results from other sites. -2. *No leakage through cross-site shared limits.* Queries from one site must not affect which +1. *No leakage through cross-site shared limits.* Queries from one site must not affect which reports are emitted to others. Assumption 1 is necessary because the system involves multiple sites that could interact @@ -3178,7 +3178,7 @@ spec:structured header; type:dfn; urlPrefix: https://httpwg.org/specs/rfc9651; "title": "Cookie Monster: Efficient On-device Budgeting for Differentially-Private Ad-Measurement Systems", "publisher": "SOSP'24" }, - "ppa-dp-2": { + "ppa-dp-2": { "authors": [ "Pierre Tholoniat", "Alison Caulfield", @@ -3193,7 +3193,6 @@ spec:structured header; type:dfn; urlPrefix: https://httpwg.org/specs/rfc9651; ], "href": "https://arxiv.org/abs/2506.05290", "title": "Big Bird: Privacy Budget Management for W3C's Privacy-Preserving Attribution API", - "publisher": "arXiv" }, "prio": { "authors": [ From f36fac952a50ec18325dfa2d815894f20c381972 Mon Sep 17 00:00:00 2001 From: "Benjamin M. Case" <35273659+bmcase@users.noreply.github.com> Date: Mon, 3 Nov 2025 12:24:22 -0500 Subject: [PATCH 06/15] add DP paper summary add a short description of both DP papers --- api.bs | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/api.bs b/api.bs index 18178a5..d7ab457 100644 --- a/api.bs +++ b/api.bs @@ -2345,10 +2345,14 @@ for a number of reasons: sites could exhaust their budget forever. ### Formal Analysis of Privacy Properties and Their Limitations ### {#formal-analysis} -The paper [[PPA-DP-2]] provides formal analysis of the mathematical privacy guarantees -afforded by *per-site budgets* and by *safety limits*. Per-site -budgets include [=site=] in the [=privacy unit=], whereas safety limits exclude it -thereby enforcing a global individual DP guarantee. + The formal privacy analysis is based on two papers. The first [[PPA-DP]] establishes the theory +for on-device Individual DP accounting. The second [[PPA-DP-2]] provides formal analysis of +the mathematical privacy guarantees afforded by *per-site budgets* and by *safety limits* +(Section 3 is about per-site guarantees and Section 3.4 specifies the assumptions under +which they hold). Per-site budgets include [=site=] in the [=privacy unit=], whereas safety +limits exclude it thereby enforcing a global individual DP guarantee. In Attribution Level 1 +it is conversion sites that have per-site budgets tracked. + The analysis shows that *per-site individual DP guarantees* hold under a restricted system model that makes two assumptions, which may not always be satisfied in practice: From fd4209c2f350fc091e633b45ca768e0362c2ed23 Mon Sep 17 00:00:00 2001 From: "Benjamin M. Case" <35273659+bmcase@users.noreply.github.com> Date: Wed, 3 Dec 2025 22:32:49 -0500 Subject: [PATCH 07/15] fix bib --- api.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/api.bs b/api.bs index d7ab457..565a5ea 100644 --- a/api.bs +++ b/api.bs @@ -3214,7 +3214,7 @@ spec:structured header; type:dfn; urlPrefix: https://httpwg.org/specs/rfc9651; "Martin Thomson" ], "href": "https://arxiv.org/abs/2506.05290", - "title": "Big Bird: Privacy Budget Management for W3C's Privacy-Preserving Attribution API", + "title": "Big Bird: Privacy Budget Management for W3C's Privacy-Preserving Attribution API" }, "prio": { "authors": [ From 750176bf762cb19a2f6102f312636a776e70c40d Mon Sep 17 00:00:00 2001 From: "Benjamin M. Case" <35273659+bmcase@users.noreply.github.com> Date: Wed, 3 Dec 2025 22:36:58 -0500 Subject: [PATCH 08/15] fix markdown --- api.bs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/api.bs b/api.bs index 565a5ea..fd372b0 100644 --- a/api.bs +++ b/api.bs @@ -2357,10 +2357,10 @@ it is conversion sites that have per-site budgets tracked. The analysis shows that *per-site individual DP guarantees* hold under a restricted system model that makes two assumptions, which may not always be satisfied in practice: -1. *No cross-site adaptivity in data generation.* A site’s queryable data stream (impressions -and conversions) must be generated independently of past DP query results from other sites. +1. *No cross-site adaptivity in data generation.* A site's queryable data stream (impressions + and conversions) must be generated independently of past DP query results from other sites. 1. *No leakage through cross-site shared limits.* Queries from one site must not affect which -reports are emitted to others. + reports are emitted to others. Assumption 1 is necessary because the system involves multiple sites that could interact with the same user over time and change the ads they show to the user, or impact the From 430c710e5454137c290a25be119867342631bc82 Mon Sep 17 00:00:00 2001 From: "Benjamin M. Case" <35273659+bmcase@users.noreply.github.com> Date: Wed, 3 Dec 2025 22:52:24 -0500 Subject: [PATCH 09/15] cross-site linking challenge to attacker --- api.bs | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/api.bs b/api.bs index fd372b0..f4297f4 100644 --- a/api.bs +++ b/api.bs @@ -2387,6 +2387,10 @@ By contrast, the analysis shows that *safety limits* -- which operate at global excluding [=site=] from the [=privacy unit=] -- can be implemented to deliver *sound global individual DP guarantees* regardless of whether either assumption is satisfied. +In addition to facing safety limits discussed above, an attacker using multiple colluding sites to gain +more DP budget about users also face the practical limitation of being able to link a user across sites. +This is limitation does not itself provide a theoretical DP benefit but does impose a significant +challenge in practice to the attacker when the user agent has made such cross-site linking difficult. ### Browser Instances ### {#dp-instance} From a6ff01ce0918660add6aa79fc1b31ee16923f0de Mon Sep 17 00:00:00 2001 From: "Benjamin M. Case" <35273659+bmcase@users.noreply.github.com> Date: Fri, 5 Dec 2025 11:01:23 -0500 Subject: [PATCH 10/15] use "attribution result" for final aggregate output --- api.bs | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/api.bs b/api.bs index f4297f4..e83747f 100644 --- a/api.bs +++ b/api.bs @@ -384,7 +384,7 @@ Upon receiving a set of encrypted histograms from a site, the aggregation servic 2. adds the histograms, including sufficient [[#dp|noise]], to produce a differentially-private aggregate histogram, and -3. returns the aggregate to the site. +3. returns the aggregate to the site. We refer to this final output as an attribution result. @@ -2345,7 +2345,7 @@ for a number of reasons: sites could exhaust their budget forever. ### Formal Analysis of Privacy Properties and Their Limitations ### {#formal-analysis} - The formal privacy analysis is based on two papers. The first [[PPA-DP]] establishes the theory + The formal privacy analysis in this specification is based on two papers. The first [[PPA-DP]] establishes the theory for on-device Individual DP accounting. The second [[PPA-DP-2]] provides formal analysis of the mathematical privacy guarantees afforded by *per-site budgets* and by *safety limits* (Section 3 is about per-site guarantees and Section 3.4 specifies the assumptions under @@ -2353,19 +2353,18 @@ which they hold). Per-site budgets include [=site=] in the [=privacy unit=], whe limits exclude it thereby enforcing a global individual DP guarantee. In Attribution Level 1 it is conversion sites that have per-site budgets tracked. - -The analysis shows that *per-site individual DP guarantees* hold under a restricted system +The analysis in [[PPA-DP-2]] shows that *per-site individual DP guarantees* hold under a restricted system model that makes two assumptions, which may not always be satisfied in practice: 1. *No cross-site adaptivity in data generation.* A site's queryable data stream (impressions - and conversions) must be generated independently of past DP query results from other sites. + and conversions) must be generated independently of past DP [=attribution result|attribution results] from other sites. 1. *No leakage through cross-site shared limits.* Queries from one site must not affect which reports are emitted to others. Assumption 1 is necessary because the system involves multiple sites that could interact with the same user over time and change the ads they show to the user, or impact the conversions the user has, based on each other’s DP measurements. For example, if one advertiser -learns, from DP measurements, to make an ad more effective, a user may convert on their site +learns, from [=attribution result|attribution results], to make an ad more effective, a user may convert on their site rather than a competitor’s. In this case, the first site’s DP outputs -- counted only against its own per-site budget -- alter the data (or absence of data) visible to the competitor, yet this impact is not reflected in the competitor’s per-site budget. When Assumption 1 is violated, @@ -2373,7 +2372,7 @@ the analysis shows that per-site guarantees cannot be achieved. Assumption 2 is necessary when we have shared limits that span multiple sites. An example of such shared limits are the global safety limits that aim to provide a global DP guarantee. -If queries from some sites cause a shared limit to be reached, reports to other sites may be +If [=measure conversion=] requests from some sites cause a shared limit to be reached, reports to other sites may be filtered, creating dependencies across separate per-site privacy units and affecting the validity of the per-site guarantees. Thus, care must be taken when introducing any new shared limit, such as cross-site rate limiters on privacy loss. If only Assumption 2 is violated, it is unknown whether From 93aaf124778c8a279844bb5c29898b608d97618e Mon Sep 17 00:00:00 2001 From: "Benjamin M. Case" <35273659+bmcase@users.noreply.github.com> Date: Fri, 5 Dec 2025 11:08:09 -0500 Subject: [PATCH 11/15] fix bikeshed links --- api.bs | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/api.bs b/api.bs index e83747f..6d82ed3 100644 --- a/api.bs +++ b/api.bs @@ -815,8 +815,7 @@ The arguments to measureConversion() are as follow
value
The [=conversion value=]. If an attribution is made and [[#dp|privacy]] - restrictions are satisfied, this value will be encoded into the [=conversion - report=]. + restrictions are satisfied, this value will be encoded into the [=conversion report=].
maxValue
@@ -2372,7 +2371,8 @@ the analysis shows that per-site guarantees cannot be achieved. Assumption 2 is necessary when we have shared limits that span multiple sites. An example of such shared limits are the global safety limits that aim to provide a global DP guarantee. -If [=measure conversion=] requests from some sites cause a shared limit to be reached, reports to other sites may be +If measureConversion() requests from some sites cause a shared limit +to be reached, reports to other sites may be filtered, creating dependencies across separate per-site privacy units and affecting the validity of the per-site guarantees. Thus, care must be taken when introducing any new shared limit, such as cross-site rate limiters on privacy loss. If only Assumption 2 is violated, it is unknown whether @@ -2696,8 +2696,8 @@ is a particular concern with the Attribution API, because impressions are stored only on the device. It is not possible to apply server-side intelligence to identify fraudulent impressions and exclude them -from attribution. Conversely, even though [=conversion -reports=] are encrypted, because the reports are sent +from attribution. Conversely, even though [=conversion reports=] +are encrypted, because the reports are sent to a server, the server can make a determination that the conversion is likely fraudulent and exclude it from aggregation. From 68213bef51216466b21791899571acb23973bc55 Mon Sep 17 00:00:00 2001 From: "Benjamin M. Case" <35273659+bmcase@users.noreply.github.com> Date: Fri, 5 Dec 2025 11:15:29 -0500 Subject: [PATCH 12/15] fix links nice bikeshed handles plural links --- api.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/api.bs b/api.bs index 6d82ed3..ecc4ca6 100644 --- a/api.bs +++ b/api.bs @@ -2356,14 +2356,14 @@ The analysis in [[PPA-DP-2]] shows that *per-site individual DP guarantees* hold model that makes two assumptions, which may not always be satisfied in practice: 1. *No cross-site adaptivity in data generation.* A site's queryable data stream (impressions - and conversions) must be generated independently of past DP [=attribution result|attribution results] from other sites. + and conversions) must be generated independently of past DP [=attribution results=] from other sites. 1. *No leakage through cross-site shared limits.* Queries from one site must not affect which reports are emitted to others. Assumption 1 is necessary because the system involves multiple sites that could interact with the same user over time and change the ads they show to the user, or impact the conversions the user has, based on each other’s DP measurements. For example, if one advertiser -learns, from [=attribution result|attribution results], to make an ad more effective, a user may convert on their site +learns, from [=attribution results=], to make an ad more effective, a user may convert on their site rather than a competitor’s. In this case, the first site’s DP outputs -- counted only against its own per-site budget -- alter the data (or absence of data) visible to the competitor, yet this impact is not reflected in the competitor’s per-site budget. When Assumption 1 is violated, From ea2d795e0e730c3f8ae587b169629df6f112e978 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 12 Dec 2025 08:04:44 +1100 Subject: [PATCH 13/15] Some editorial fixes --- api.bs | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/api.bs b/api.bs index ecc4ca6..803e1f6 100644 --- a/api.bs +++ b/api.bs @@ -2344,7 +2344,9 @@ for a number of reasons: sites could exhaust their budget forever. ### Formal Analysis of Privacy Properties and Their Limitations ### {#formal-analysis} - The formal privacy analysis in this specification is based on two papers. The first [[PPA-DP]] establishes the theory + +The formal privacy analysis in this specification is based on two papers. +The first [[PPA-DP]] establishes the theory for on-device Individual DP accounting. The second [[PPA-DP-2]] provides formal analysis of the mathematical privacy guarantees afforded by *per-site budgets* and by *safety limits* (Section 3 is about per-site guarantees and Section 3.4 specifies the assumptions under From ec9b250bd688dc828434c147021f1f22865a2c04 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 12 Dec 2025 08:04:58 +1100 Subject: [PATCH 14/15] Another one --- api.bs | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/api.bs b/api.bs index 803e1f6..cfe7ffa 100644 --- a/api.bs +++ b/api.bs @@ -384,7 +384,9 @@ Upon receiving a set of encrypted histograms from a site, the aggregation servic 2. adds the histograms, including sufficient [[#dp|noise]], to produce a differentially-private aggregate histogram, and -3. returns the aggregate to the site. We refer to this final output as an attribution result. +3. returns the aggregate to the site. + +We refer to the final output as an attribution result. From efbcda5156805f82ed661f770d1f1344d4f6a481 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 12 Dec 2025 08:15:30 +1100 Subject: [PATCH 15/15] Line --- api.bs | 1 - 1 file changed, 1 deletion(-) diff --git a/api.bs b/api.bs index cfe7ffa..1355a27 100644 --- a/api.bs +++ b/api.bs @@ -389,7 +389,6 @@ Upon receiving a set of encrypted histograms from a site, the aggregation servic We refer to the final output as an attribution result. - # API Usage # {#api} A site using the Attribution API will typically register either