Skip to content

Conversation

bmcase
Copy link
Contributor

@bmcase bmcase commented Sep 4, 2025

With @roxanageambasu and @tholop we have put together some text for the spec that states what assumptions are used in the system model in which the formal DP analysis is done.

The referenced paper is already available, but a few claims in the PR are not yet reflected there. We will update the arXiv version to align with the PR shortly. In the meantime, we confirm that the statements are accurate and supported by analyses we already have internally.

@martinthomson martinthomson added the discuss Needs working group discussion label Sep 4, 2025
Comment on lines +2355 to +2362
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.
Copy link
Member

Choose a reason for hiding this comment

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

This is part of the assumption, but I think that the main challenge here is different. Sites might gain an understanding that a particular visitor to each site in a set is the same person (due to federated login, same email address, or anything including navigation tracking which we can't stop). AND THEN they decide to pool their per-site budgets to use the API to extract more information about that person. In that case, we have no defense from the per-site budget. Sites are only limited by their ability to link activity across sites (which is too easy, as noted) and then the global budget.

So we should acknowledge that limitation as well as the more theoretical one here.

@@ -2338,6 +2338,45 @@ 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}
Copy link
Member

Choose a reason for hiding this comment

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

I think that you want to mention both papers in the introduction to this, not just the big bird one. Point out that the first establishes the basic system that this document relies on and the second expands that to be a more comprehensive analysis of the system as a whole and the overall privacy guarantees.

This is a timely reminder that we need to implement safety limits in the spec.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, that's a good point. We should add both here and say what they each focus on.

@@ -2338,6 +2338,45 @@ 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 paper [[PPA-DP-2]] provides formal analysis of the mathematical privacy guarantees
afforded by *per-site budgets* and by *safety limits*. Per-site
Copy link
Member

Choose a reason for hiding this comment

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

@bmayd points out that we should make it clear that the site involved here is a [=conversion site=] specifically.

"Martin Thomson"
],
"href": "https://arxiv.org/abs/2506.05290",
"title": "Big Bird: Privacy Budget Management for W3C's Privacy-Preserving Attribution API",
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
"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"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Needs working group discussion
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants