Skip to content

Add text on DP formal analysis and its assumptions #271

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
bmcase wants to merge 16 commits into
base: main
Choose a base branch
from
Open

Add text on DP formal analysis and its assumptions #271

Changes from all commits
Commits
Show all changes
16 commits
Select commit Hold shift + click to select a range
5838518
add dp assumptions
bmcase Sep 3, 2025
2e27352
update DP assumptions text
bmcase Sep 4, 2025
6fe5c2a
Update DP assumptions text
bmcase Sep 4, 2025
c997c37
fix format
bmcase Sep 4, 2025
5b54331
fmt fixes
bmcase Sep 9, 2025
9c2a1ee
Merge branch 'w3c:main' into origin/dp_assumptions
bmcase Nov 3, 2025
f36fac9
add DP paper summary
bmcase Nov 3, 2025
fd4209c
fix bib
bmcase Dec 4, 2025
750176b
fix markdown
bmcase Dec 4, 2025
430c710
cross-site linking challenge to attacker
bmcase Dec 4, 2025
a6ff01c
use "attribution result" for final aggregate output
bmcase Dec 5, 2025
93aaf12
fix bikeshed links
bmcase Dec 5, 2025
68213be
fix links
bmcase Dec 5, 2025
ea2d795
Some editorial fixes
martinthomson Dec 11, 2025
ec9b250
Another one
martinthomson Dec 11, 2025
efbcda5
Line
martinthomson Dec 11, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
73 changes: 69 additions & 4 deletions api.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -386,6 +386,7 @@ Upon receiving a set of encrypted histograms from a site, the aggregation servic

3. returns the aggregate to the site.

We refer to the final output as an <dfn>attribution result</dfn>.


# API Usage # {#api}
Expand Down Expand Up @@ -815,8 +816,7 @@ The arguments to <a method for=Attribution>measureConversion()</a> are as follow
<dt><dfn>value</dfn></dt>
<dd>
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=].
</dd>
<dt><dfn>maxValue</dfn></dt>
<dd>
Expand Down Expand Up @@ -2344,6 +2344,55 @@ for a number of reasons:
Without allocating [=privacy budget=] for new data,
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
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
Comment on lines +2353 to +2354
Copy link
Member

@martinthomson martinthomson Dec 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
(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
Section 3 of [[PPA-DP-2]] addresses per-site guarantees
and Section 3.4 specifies the assumptions under which those guarantees 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.
Comment on lines +2354 to +2356
Copy link
Member

@martinthomson martinthomson Dec 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need to be more direct about the connection to the specification.

Given where we are, this might need to be:

Suggested change
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.
which they hold).
The per-site budgets include [=site=] in the [=privacy unit=]
are based on the restricted analysis in [[PPA-DP]].
The introduction of <dfn>global safety limits</dfn> exclude [=site=],
which creates a global DP guarantee.
The current version of the document does not define
the application of [=global safety limits=].


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 [=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
Copy link
Member

@martinthomson martinthomson Dec 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Assumption 1 is necessary because the system involves multiple sites that could interact
The assumption that sites cannot adapt their queries 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 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,
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
Copy link
Member

@martinthomson martinthomson Dec 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Assumption 2 is necessary when we have shared limits that span multiple sites. An example of
An assumption that sites are unable to coordinate their use of the API is necessary
when we have shared limits that span multiple sites. An example of

Copy link
Contributor Author

@bmcase bmcase Dec 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I'm trying to say here is just that if you want to have shared limits you have to make Assumption 2 for the per-site budgets to hold.

such shared limits are the global safety limits that aim to provide a global DP guarantee.
If <a method for=Attribution>measureConversion()</a> 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
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.
Comment on lines +2388 to +2390
Copy link
Member

@martinthomson martinthomson Dec 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider defining this as [=global safety limits=], per above.

Suggested change
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.
The analysis shows that [=global safety limits=] --
which do not have a [=site=]-specific [=privacy unit=] --
deliver sound individual DP guarantees
regardless without relying on either of these assumptions.

Importantly, after introducing the analyses and some context, this is the first thing I would say. It's a simple statement that is easy to understand.

Copy link
Contributor Author

@bmcase bmcase Dec 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, we can move this up top if we want to start with what holds without any assumptions.


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.
Comment on lines +2392 to +2395
Copy link
Member

@martinthomson martinthomson Dec 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
An attacker that is able to use other information to link the activity of a user across multiple sites
can use the DP budgets of those sites to overcome the constraints of the per-site budgets.
There are many features in the web platform that allow this capability,
so this is a very plausible attack on the privacy design.
The privacy analysis does not consider this attack within its threat model,
relying exclusively on [=global safety limits=].
Any implementation needs to consider this limitation when selecting DP parameters.

This is the second thing I would say, which is a major limitation of the design and something that is important to understand about the interaction between per-site and global budgets.

This is something that implementations have to consider when they set parameters.

Copy link
Contributor Author

@bmcase bmcase Dec 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't agree with this suggested text, but see me longer comment below for why.

An attacker that is able to use other information to link the activity of a user across multiple sites
can use the DP budgets of those sites to overcome the constraints of the per-site budgets.

An attacker who can cross-site identify the user across sites would be able to learn more about the user across sites because of that linkage; but not because of the API. The incremental information they learn by using the API is worst case bounded by the composition of the per-site budgets involved under the assumptions here.

Copy link
Member

@martinthomson martinthomson Dec 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An attacker who can cross-site identify the user across sites would be able to learn more about the user across sites because of that linkage; but not because of the API.

This is true, but only for those sites on which the attacker can gather information. If there is another site that the attacker has no information about, having multiple vantage points -- or multiple budgets -- to use this API from gives them greater information than they would have from a single vantage point.

So both apply.


### Browser Instances ### {#dp-instance}

Expand Down Expand Up @@ -2650,8 +2699,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.
Expand Down Expand Up @@ -3157,6 +3206,22 @@ 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": {
"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"
},
"prio": {
"authors": [
"Henry Corrigan-Gibbs",
Expand Down