You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// Optional debugging information (also present in event-level reports),
272
-
// if the cookie `ar_debug` is present.
274
+
// if cookie-based debugging is allowed.
273
275
"source_debug_key":"[64 bit unsigned integer]",
274
276
"trigger_debug_key":"[64 bit unsigned integer]",
275
277
@@ -503,6 +505,9 @@ As the trigger context ID in the aggregatable report explicitly reveals the
503
505
association between the report and the trigger, these reports can be sent
504
506
immediately without delay.
505
507
508
+
When a trigger context ID is provided, the aggregatable report will not count
509
+
towards the limit of aggregatable reports per source, nor be limited by it.
510
+
506
511
Note: This is an [alternative](https://github.com/WICG/attribution-reporting-api/blob/main/report_verification.md#could-we-just-tag-reports-with-a-trigger_id-instead-of-using-anonymous-tokens)
507
512
considered for [report verification](https://github.com/WICG/attribution-reporting-api/blob/main/report_verification.md),
508
513
and achieves all of the higher priority [security goals](https://github.com/WICG/attribution-reporting-api/blob/main/report_verification.md#security-goals).
@@ -551,6 +556,56 @@ as when a trigger context ID is set.
551
556
552
557
See [flexible_filtering.md](https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/flexible_filtering.md) for more details.
553
558
559
+
### Optional: named budgets
560
+
561
+
Named budgets is an optional feature that gives API callers the ability
562
+
to manage `L1` contribution budget distribution across different types of
563
+
attributions, addressing common challenges such as:
564
+
565
+
- Allocating the privacy budget between different types of attributions
566
+
(e.g., biddable vs. non-biddable).
567
+
- Distributing the budget across multiple product categories to prevent any
568
+
single product category from consuming all available privacy budget.
569
+
570
+
[Source registrations](#attribution-source-registration) will accept an optional
571
+
field `named_budgets`, which is a dictionary used to set the
572
+
maximum contribution for each named budget for this source.
573
+
574
+
```jsonc
575
+
{
576
+
..., // existing fields
577
+
"named_budgets": {
578
+
"budgetName1":32768, // Max contribution budget for budgetName1.
579
+
"budgetName2":32768// Max contribution budget for budgetName2.
580
+
}
581
+
}
582
+
```
583
+
584
+
[Trigger registrations](#attribution-trigger-registration) will accept an
585
+
optional field `named_budgets`, which will be used to select the
586
+
named budget for the generated aggregatable report.
587
+
588
+
```jsonc
589
+
{
590
+
..., // existing fields
591
+
"named_budgets": [
592
+
{
593
+
"name":"budgetName1",
594
+
"filters": {"source_type": ["navigation"]}
595
+
}
596
+
]
597
+
}
598
+
```
599
+
600
+
The first named budget from the trigger that matches the source's filter data
601
+
will be selected. If there is no budget name specified or no matching filters, the
602
+
`L1` contribution budget will still be applied.
603
+
604
+
When generating an aggregatable report, in addition to performing the
605
+
current `L1` budget limit check, the contributions for the report will
606
+
be checked against the available budget with the selected budget name, if applicable.
607
+
If the budget is insufficient, the aggregatable report will not be generated.
608
+
554
609
## Data processing through a Secure Aggregation Service
555
610
556
611
The exact design of the service is not specified here. We expect to have more
Copy file name to clipboardExpand all lines: AGGREGATION_SERVICE_TEE.md
+9-8Lines changed: 9 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,10 @@
1
1
# Aggregation Service for the Attribution Reporting API
2
2
3
-
Authors:
4
-
* Carlos Cela <cjcela@google.com>
5
-
* Ruchi Lohani <rlohani@google.com>
6
-
* Martin Pál <mpal@google.com>
7
-
* Chanda Patel <chandapatel@google.com>
3
+
## Authors
4
+
* Carlos Cela (cjcela@google.com)
5
+
* Ruchi Lohani (rlohani@google.com)
6
+
* Martin Pál (mpal@google.com)
7
+
* Chanda Patel (chandapatel@google.com)
8
8
9
9
## Introduction
10
10
@@ -96,6 +96,7 @@ throughout this proposal.
96
96
*_Coordinator:_ an entity responsible for key management and aggregatable report
97
97
accounting. The coordinator maintains a list of hashes of approved aggregation
98
98
service configurations and configures access to decryption keys.
99
+
*_Shared ID:_ A unique identifier assigned to a group of reports in combination with [filtering IDs](https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/flexible_filtering.md#proposal-filtering-id-in-the-encrypted-payload) to prevent overlap between batches of reports. This eliminates the need to track individual reports and allows for efficient privacy budget management at the group level.
99
100
100
101
## Aggregation workflow
101
102
@@ -243,7 +244,7 @@ single aggregation batch (as duplicates) or in multiple batches. Because
243
244
of this, the aggregation service enforces a "no duplicates" rule:
244
245
245
246
* No aggregatable report can appear more than once within a batch.
246
-
* No aggregatable report can appear in more than one batch or contribute
247
+
* No Shared ID can appear in more than one batch or contribute
247
248
to more than one summary report.
248
249
249
250
The no-duplicates rule is enforced during aggregation. If duplicates are
@@ -254,8 +255,8 @@ found, these batches may be rejected or duplicates may be filtered out.
254
255
It is not technically practical to keep track of every single aggregatable
255
256
report submitted for aggregation to check for batch disjointness, that is,
256
257
that batches are not overlapping. Instead, each aggregatable report will
257
-
be assigned a shared ID. This ID is generated from the combined data points: API version, reporting origin, destination site, source registration time and scheduled report time.
258
-
These data points come from the report's [shared_info](https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md#aggregatable-reports) field.
258
+
be assigned a shared ID. This ID is generated from the combined data points: API version, reporting origin, destination site, source registration time, scheduled report time, and filtering ID.
259
+
These data points come from the report's [shared_info](https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATE.md#aggregatable-reports) field and from the job parameter in the request.
259
260
260
261
The aggregation service will enforce that all aggregatable reports with
261
262
the same ID must be included in the same batch. Conversely, if more than
Copy file name to clipboardExpand all lines: aggregate_key_discovery.md
+7Lines changed: 7 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,12 @@
1
1
# Summary reports with key discovery
2
2
3
+
## Authors
4
+
5
+
* Charlie Harrison (csharrison@chromium.org)
6
+
* Hidayet Aksu (aksu@google.com)
7
+
8
+
9
+
## Introduction
3
10
This document describes possible new functionality in the server-side mechanisms for the aggregation service, which allows ad techs to query the Attribution Reporting API’s and Private Aggregation API’s summary reports without [pre-declaring every aggregation bucket](https://github.com/WICG/attribution-reporting-api/blob/main/AGGREGATION_SERVICE_TEE.md#pre-declaring-aggregation-buckets).
4
11
5
12
This proposal is backward compatible; ad techs can still work with pre-declared buckets.
0 commit comments