Deploy and manage this service to produce summary reports for the Attribution Reporting API or the Private Aggregation API.
- The Aggregation Service has now moved to general availability.
- The Aggregation Service can be tested with the Attribution Reporting API and the Private Aggegration API for Protected Audience API and Shared Storage.
The explainer outlines key terms, useful for understanding the Aggregation Service.
Secure data processing
The Aggregation Service decrypts and combines the collected data from the aggregatable reports, adds noise, and returns the final summary report. This service runs in a trusted execution environment (TEE), which is deployed on a cloud service that supports necessary security measures to protect this data.
A Trusted Execution Environment is a special configuration of computer hardware and software that allows external parties to verify the exact versions of software running on the computer. TEEs allow external parties to verify that the software does exactly what the software manufacturer claims it does—nothing more or less.
The TEE's code is the only place in the Aggregation Service which has access to raw reports—this code will be auditable by security researchers, privacy advocates, and ad techs. To confirm that the TEE is running the exact approved software and that data remains secured, a coordinator performs attestation.
Coordinator attestation of the TEE
The coordinator is an entity responsible for key management and aggregatable report accounting.
A coordinator has several responsibilities:
- Maintain a list of authorized binary images. These images are cryptographic hashes of the Aggregation Service software builds, which Google will periodically release. This will be reproducible so that any party can verify the images are identical to the Aggregation Service builds.
- Operate a key management system. Encryption keys are required for the Chrome on a user's device to encrypt aggregatable reports. Decryption keys are necessary for proving the Aggregation Service code matches the binary images.
- Track the aggregatable reports to prevent reuse in aggregation for summary reports, as reuse may reveal personal identifying information (PII).
If you are testing the Aggregation Service, see the Coordinator Service Additional Terms of Service.
"No duplicates" rule
To gain insight into the contents of a specific aggregatable report, an attacker might make multiple copies of the report and include those copies in a single or multiple batches. Because of this, the Aggregation Service enforces a "no duplicates" rule:
- In a batch: An aggregatable report can only appear once within a batch.
- Across batches: Aggregatable reports cannot appear in more than one batch or contribute to more than one summary report.
To accomplish this, the browser assigns each aggregatable report a shared ID. The browser generates the shared ID from several data points, including: API version, reporting origin, destination site, source registration time, and scheduled report time. This data comes from the
shared_info field in the report.
The Aggregation Service confirms that all aggregatable reports with the same shared ID are in the same batch and reports to the coordinator that the shared ID was processed. If multiple batches are created with the same ID, only one batch can be accepted for aggregation, and other batches are rejected.
When you perform a debug run, the "no duplicates" rule is not enforced across batches. In other words, reports from previous batches may appear in a debug run. However, the rule is still enforced within a batch. This allows you to experiment with the service and various batching strategies, without limiting future processing in a production environment.
Noise and scaling
To protect user privacy, the Aggregation Service applies an additive noise mechanism to the raw data from aggregatable reports. This means that a certain amount of statistical noise is added to each aggregate value before its release in a summary report.
While you are not in direct control of the ways noise is added, you can influence the impact of noise on its measurement data.
The noise value is randomly drawn from a Laplace probability distribution, and the distribution is the same regardless of the amount of data collected in aggregatable reports. The more data you collect, the less impact the noise will have on the summary report results. You can multiply the aggregatable report data by a scaling factor to reduce the impact of noise.
Generate summary reports
Test the Aggregation Service
We recommend reading the corresponding experiment and participate guide for the API you're testing:
To test the Aggregation Service on AWS, see these instructions.
A local testing tool is also available to process aggregatable reports for Attribution Reporting and the Private Aggregation API.
Engage and share feedback
The Aggregation Service is a key piece of the Privacy Sandbox measurement APIs. Like other Privacy Sandbox APIs, this is documented and discussed publicly on GitHub.