Enroll for the Privacy Sandbox

To access the Privacy Sandbox relevance and measurement APIs on Chrome and Android, developers need to enroll with the Privacy Sandbox. This includes Attribution Reporting, Protected Audience, Topics, Private Aggregation, and Shared Storage. Developer enrollment verifies the entities that call these APIs, and gathers the data needed to properly configure and use the APIs. Enrollment adds an additional layer of protections to and transparency around who is collecting data, and mitigates attempts to misuse the APIs to collect nonessential data. To provide auditable transparency, enrollment information about the company is made public. Companies should plan at least five weeks to complete the enrollment process. This includes time to address any unexpected issues with the console submission or other issues that may arise. This doesn't include any additional lead time companies may need for internal preparation prior to submitting the form.

Before you begin

Before starting enrollment, create an account using the Privacy Sandbox Console. Learn more about account creation.

How to enroll

To enroll, developers must use the Privacy Sandbox Console. You must provide the following information:

• Info about your business
  • This includes a contact email address and links to your privacy policies
• The APIs and services you plan to use
  • Some services require additional info, such as details about your Cloud provider
• The site or name of the SDKs you want to enroll
  • This is where you'll call the APIs from
• Attestations about your usage of the APIs
  • If you're enrolling a site, then you'll need to upload an attestation file to your server

Enroll your site, Android SDK, or Android app

During enrollment, you need to provide a site or SDK (or both) that you'll use to call the APIs.
How you enroll depends on how the Privacy Sandbox APIs are called:

• If you're a web developer and your site calls the Privacy Sandbox APIs directly, you should provide your site in enrollment.
• If you're an Android SDK developer, provide your SDK name in enrollment. If your SDK uses the Attribution Reporting, Protected Audience, or both APIs, provide your site in enrollment as well. Apps that use your SDK don't need to enroll separately, unless they call Privacy Sandbox APIs directly from their own code. If you're testing Attribution Reporting APIs on Android at scale immediately, you will need to provide all the origins you use.
• If you're an app developer and your app calls the Attribution Reporting, Protected Audience, or both APIs directly, you should provide your site during enrollment.
• If you're an app developer and you delegate your ads functionality entirely to an SDK, you don't need to go through the enrollment process.

Every site or SDK that calls the Privacy Sandbox APIs requires a unique enrollment and needs to attest individually. Apps that call the Privacy Sandbox APIs directly may be included in a single enrollment. If you plan to call multiple APIs, specify each one during the enrollment process. Note: The site you enroll with is the same site that will be used to retrieve the encryption keys for use of Topics on Android and the signing key for your use of Protected Audience on Android. More information on the encryption endpoint for Topics on Android and more information for signing keys for Protected Audience.

Update enrollment information

You may update your enrollment details through the console once it is completed. Your existing enrollment will remain active while your changes are under review.

If any of the following information changes, you will need to re-upload a new version of your attestation file:

• Privacy policy links
• Site information
• APIs selected

Enrollment Statuses

After submitting your enrollment, these are the stages of progress you may see:

• Review
  • We are reviewing your enrollment. No action is required.
• Set up attestation file
  • Your enrollment was approved. For sites, an attestation file must be set up within 30 days.
• Enrollment complete
  • You have successfully enrolled and set up your attestation file (if necessary). No further action is required.
• Errors with attestation files
  • The attestation file is in the wrong place
    • Within the 30 day window, we were unable to locate your attestation file for your site.
  • Enrollment suspended
    • The attestation file has not been correctly set up within the initial 30 day window or can no longer be found after a previously successful enrollment. Please contact [e-mail] for more information.

Enrollment timeline

After your enrollment has been submitted, we'll review and process your application. Once the review is complete, you will see a confirmation in the console and you will be able to access your attestation file for setup. The file must be made publicly available from the /.well-known path on the site for which it was enrolled within 30 days of enrollment approval. Android developers can provide the enrollment ID to app developers so apps can set granular access control. For more information, see Android's Configure API-specific Ad Services documentation. Note: Entering correct information on your original submission and responding to any inquiries from the Google tech support team in a timely manner helps speed up the process.

Enrollment for different development environments

Your staging, beta, QA and test environments will be automatically enrolled if they use the same site as your production environment. You can test locally without going through enrollment. For local testing, we are providing developer overrides from Chrome 116 with a Chrome flag and CLI switch:

• Flag: chrome://flags/#privacy-sandbox-enrollment-overrides
• CLI: --privacy-sandbox-enrollment-overrides=https://example.com,https://example.co.uk,...

Limitations

Note the following developer enrollment limitations when determining your organization's enrollment structure:

• One site can only be linked to one enrollment.
• One enrollment contains only one site.
• SDK specific limitations:
  1. One enrollment may contain multiple SDKs.
  2. A given SDK can only be linked to one enrollment.
• Additional enrollments are allowed, but they need to be for independent products or lines of business that are clearly established and publicly verifiable (that is, there is a corresponding public website that explains the specific product). You can't have multiple enrollments for the same product. The attestations apply to each enrollment individually.
• With site-scoped enrollment, a single enrollment can cover unlimited origins, as long as they are same-site. However, the one reporting origin per source rate limit (Chrome, Android) means that you are generally limited to one origin per publisher.

Multiple enrollments for a single entity

More complex entities that have multiple, unique products may apply for more than one enrollment. For example, if your company has an SSP and a DSP line of business you may qualify for multiple enrollments.

Note: There is no requirement from Privacy Sandbox to separate enrollment of a DSP versus an SSP owned by the same entity.

Each product must have separate sites from which to call the APIs. You will be required to provide public representation for each product you are requesting to enroll (for example, link to a public facing website that explains the product).

If you want to enroll more than one site or SDK, navigate to the 'Enrollments' tab in the console navigation. After your first enrollment is approved, you can select 'Request enrollments' to request to add more. Once submitted, the application will be reviewed and you will receive an email and see the status reflected in the console when the review process is complete.

Note: You can't request multiple enrollments for testing (for example, testing and production, pre-production and production). While Ad techs may create multiple environments to test the APIs, enrollment only allows one site to be registered per product (not one enrollment per environment per product).

Redirect with Attribution Reporting

Consider a scenario where site A is not enrolled but site B is enrolled. ARA will ping URLs for redirects even if not enrolled. As a result, the redirection from siteA.com to siteB.com will work. However, sources and triggers will only be registered from enrolled Ad techs.

Enroll for Aggregation Service

Aggregation service enrollment is part of the console enrollment process. Each Aggregation Service enrollment must include the AWS account ID or Google Cloud service account, in which the Aggregation Service will be deployed. Ad techs have the flexibility to link multiple sites to one account, or multiple accounts to one site for various testing, operational, and cost efficiency needs.

Upload your attestation file

Once you've enrolled and passed the verification process, you will be able to access your attestation file in the console. You will have a 30-day implementation period from the time you receive the attestation file, to finalize your attestation file placement. During this time you can still call the APIs for 30 days, however it is expected that you don't enroll unless you can adhere to the attestation language during the 30-day implementation period.

To complete enrollment, make the file available from the public .well-known path on the site that was enrolled. For example, if you enroll https://example.com, place the attestation file at https://example.com/.well-known/privacy-sandbox-attestations.json. You may also use HTTP redirects only to subdomains of your enrolled site to serve the attestation file.

You must abide by the attestations and keep the attestation file in place for the duration of the enrollment. Attestation files are routinely verified, and prolonged failure to keep them in place will cause API calls to fail until the file is restored.

Note that:

• Privacy Sandbox will fetch the attestation file from enrolled Ad techs. This job will fetch the file no more than once an hour. API calls won't trigger a fetch request for the attestation file.
• The intention is for the attestation file to be available publicly. The Ad tech should expect some fetch requests from external parties, including researchers, regulators, and users (outside of the fetch requests from Privacy Sandbox infra). Ad techs must serve the same file to them that they serve to Google.

For Topics on Android attestations, app and SDK developers need to agree to the attestation within the enrollment form in the console and don't need to place an attestation file on their server unless they are using other Privacy Sandbox APIs.

Update attestation to add more APIs

If you decide to include more APIs in your enrollment at a later date, you will need to update your enrollment. As part of this process, you will receive an updated attestation file that must be made available from the .well-known path on your site, before you can call the new APIs.

Update to the latest version of the attestation file

All enrolled companies need to update to the latest version of the attestation file they have received from Google.
The attestation files don't expire after a set period of time. New or updated attestation files may be provided from time to time as the attestation framework evolves (for example, new API-specific attestations are added).

Attestation validation failures

Access would be cut off only if the server checking the attestation file is repeatedly unable to validate it. A single error or serving issue wouldn't cause access to be suspended.

For more details, see the GitHub on attestations.

Android developer data

Entities that intend to use the Privacy Sandbox APIs on Android can access their enrollment ID through the console UI, which can be included in an app's AdServices configuration. This allows app developers to have fine-grained control over the Ad techs that their app or SDKs interact with.