Skip to content

anti-replay requirements for level 1 #354

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 4 commits into
base: main
Choose a base branch
from
+22 −1
Open

anti-replay requirements for level 1 #354

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
c7ae28b
anti-replay requirements for level 1
bmcase Jan 5, 2026
aa8bf3a
add topLevelSite in reportMetadata
bmcase Jan 5, 2026
8261113
use `site` consistently for anti-replay
bmcase Jan 5, 2026
3ade7fe
use `conversionCaller` in anti-replay
bmcase Jan 5, 2026
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
23 changes: 22 additions & 1 deletion api.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1560,6 +1560,7 @@ and [=implicit API inputs=] |implicitInputs|:
1. Let |encryptedReport| be the result of invoking <a>construct a DAP report</a>,
given |validatedOptions|,
|implicitInputs|' [=implicit API inputs/top-level site=],
|implicitInputs|' [=implicit API inputs/intermediary site=],
|implicitInputs|' [=implicit API inputs/timestamp=], and |report|.
</dl>
1. Let |result| be a {{AttributionConversionResult}} with the following items:
Expand Down Expand Up @@ -2435,6 +2436,7 @@ To <dfn>construct a DAP report</dfn>,
producing a [=byte sequence=] |report|,
given [=validated conversion options=] |options|,
[=site=] |topLevelSite|,
[=site=] or `undefined` |intermediarySite|,
[=moment=] |now|,
and a [=list=] of [=integers=] |histogram|:

Expand Down Expand Up @@ -2497,8 +2499,11 @@ and a [=list=] of [=integers=] |histogram|:
* The extension codepoint for [[DAP-EXT#name-requester-website-identity|requester identity]],
mapped to the [=isomorphic encode|encoded=] value of |topLevelSite|[1].

1. Let |conversionCaller| be |intermediarySite| if |intermediarySite| is not `undefined`,
|topLevelSite| otherwise.

1. Let |reportMetadata| be encoded DAP [`ReportMetadata`](https://datatracker.ietf.org/doc/html/draft-ietf-ppm-dap-15#section-4.5.2)
generated from |reportID|, |time|, and |extensions|.
generated from |reportID|, |conversionCaller|, |time|, and |extensions|.

1. Let |encryptedInputShares| be an [=list/is empty|empty=] [=list=].

Expand Down Expand Up @@ -2555,6 +2560,22 @@ that was expended by the site that requested the report.
An [=aggregation service=] MUST guarantee
that it does not accept the same report more than once.

To support anti-replay verification,
each [=conversion report=] includes associated data
that is authenticated as part of the AEAD encryption.
This associated data includes:

* The [=site=] that invoked the {{Attribution/measureConversion()}} API.
This is the [=intermediary site=] if the API was called from a cross-site frame,
or the [=conversion site=] otherwise.
Comment on lines +2568 to +2570
Copy link
Member

@martinthomson martinthomson Jan 6, 2026

Choose a reason for hiding this comment

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

This relates to the changes you added to the algorithms, but I don't think that this is correct.

We charge budget to the top-level site. Therefore the aggregation service needs to attribute individual reports to the same entity. Otherwise, we create the possibility that reports from multiple sites (and therefore multiple budgets) are aggregated together and noise is not correctly applied.

Concretely, if I have reports from site A and site B, then there are two budgets. I would expect two lots of noise as well. This approach would allow an intermediary to combine reports from sites into a single aggregation that includes just one lot of noise.

Copy link
Collaborator

@csharrison csharrison Jan 6, 2026

Choose a reason for hiding this comment

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

I think we should discuss this next week. Here is my opinion:

  1. The conversion caller should be in the associated data and we should fail decryption in the helpers if the callers don't match. This prevents report-theft from being a problem.
  2. I don't think the top level site needs to be in the associated data. I don't think a single lot of noise is problematic for the guarantees (esp. if safety limits are in place), but @bmcase can correct me if I'm wrong. In fact, I think we wanted to support cross-advertiser queries right?

Copy link
Contributor Author

@bmcase bmcase Jan 8, 2026

Choose a reason for hiding this comment

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

discussed with @csharrison; we think we should include the following

  1. the caller of the API (either an intermediary (like measurement provider for the advertiser) or the advertiser themself) and for this use the full origin. This can be used to make sure only this origin can query the report to the Helpers (and prevent DOS on reports being queried by some other party).

  2. the eTLD+1 of the conversion site. This corresponds to the grain of the DP budgeting in Level 1 and prevents aggregation of reports from different advertisers which spent different budgets. (This can be handled different in Level 2 when we do support cross-advertiser aggregation and there ensure we bind to whichever budget is being deducted from).

* A timestamp, as determined by the device at the time of the API call.

The [=aggregation service=] uses this associated data
to shard its anti-replay mechanism.
This sharding enables efficient verification
that each report is processed only once,
while allowing the service to scale.


# Differential Privacy # {#dp}

Expand Down