What is the Privacy Sandbox?

The Privacy Sandbox initiative aims to create technologies that both protect people's privacy online and give companies and developers tools to build thriving digital businesses.

The Privacy Sandbox has two core aims:

• Phase out support for third-party cookies when new solutions are in place.
• Reduce cross-site and cross-app tracking while helping to keep online content and services free for all.

The Privacy Sandbox APIs require web browsers to take on a new role. Rather than working with limited tools and protections, the APIs allow a user's browser to act on the user's behalf—locally, on their device—to protect the user's identifying information as they navigate the web. This is a shift in direction for browsers.

The Privacy Sandbox's vision of the future has browsers providing specific tools to satisfy specific use cases, while preserving user privacy.

# What are the Privacy Sandbox proposals?

Chrome and other ecosystem stakeholders have offered more than 30 proposals to date, which can be found in the public resources of W3C groups. These proposals cover a wide variety of use cases and requirements.

Proposals have a lifecycle with up to three phases before becoming web standards: discussion, testing, and scaled adoption. It's critical we receive feedback from developers and industry leaders to ensure we create durable web features with broad utility and robust privacy protections for users. Read more about the proposal lifecycle.

Several key proposals are listed below.

# Strengthen cross-site privacy boundaries

• CHIPS: Allow developers to opt-in a cookie to partitioned storage, with a separate cookie jar per top-level site.
• First-Party Sets: Allow related domain names owned by the same entity to declare themselves as belonging to the same first party.
• Shared Storage: Create a general-purpose API which allows sites to store and access unpartitioned cross-site data. This data must be read in a secure environment to prevent leakage.
• Storage Partitioning: Enable all forms of user agent state, such as localStorage or cookies, to be double-keyed: by the top-level site as well as the origin of the resource being loaded, rather than a single origin or site.
• Fenced Frames: Securely embed content onto a page without sharing cross-site data.
• Network State Partitioning: Prevent browser network resources being shared across first-party contexts, by ensuring that every request has a network partition key that must match in order for resources to be reused.
• Federated Credential Management (FedCM): Support federated identity without sharing the user's email address or other identifying information with a third-party service or website, unless the user explicitly agrees to do so.

# Show relevant content and ads

• Topics API: Enable interest-based advertising without use of third-party cookies or tracking user behavior across sites.
• FLEDGE: Ad selection to serve remarketing and custom audience use cases, designed so that it cannot be used by third parties to track user browsing behavior across sites. FLEDGE is the first experiment to be implemented in Chromium from the TURTLEDOVE family of proposals.

# Measure digital ads

• Attribution Reporting: Correlate ad clicks or ad views with conversions. Ad techs can generate event-level or summary reports.
• Private Aggregation API: Generate noisy summary reports with cross-site data.

# Prevent covert tracking

• User-Agent reduction and User-Agent Client Hints: Limit passively shared browser data to reduce the volume of sensitive information which leads to fingerprinting. Client Hints allow developers to actively request only the information they need about the user's device or conditions.
• IP Protection: Improve user privacy by protecting their IP address from being used for tracking.
• Bounce tracking mitigations: A proposal to reduce or eliminate the ability of bounce tracking to recognize people across contexts.
• Privacy Budget: Limit the amount of individual user data exposed to sites to prevent covert tracking.

# Fight spam and fraud on the web

• Private State Tokens: Allow websites to convey a limited amount of information from one browsing context to another (for example, across sites) to help combat fraud, without passive tracking.

# Who works on the Privacy Sandbox?

Chrome and other browser vendors, as well as ad companies and other stakeholders, have offered more than 30 proposals to date. These proposals can be found in the public resources of W3C groups and cover a wide variety of use cases and requirements.

400+ participants have joined W3C groups to provide input including the Improving Web Advertising Business Group and the Privacy Community Group.

# Where are the Privacy Sandbox APIs available?

Five API implementations are currently available for testing in Chrome.

The APIs are implemented in Chromium, which is the open-source browser used to make Chrome. Code for the Privacy Sandbox APIs can be accessed via Chromium Code Search.

You can download Chromium, then run it with flags to allow access to APIs that are in the process of implementation.

# When will the APIs be implemented?

The timeline has the latest implementation status for the Privacy Sandbox on the web. Each API has an implementation status in their documentation.

We publish regular announcements on the Chrome Developers blog as APIs move from proposal to experiment to scaled availability.

# How can I try Privacy Sandbox APIs that aren't yet turned on by default?

As an API progresses through development in Chrome, there are multiple ways it may be made available for testing.

• For a single user via command line flags
  Early features may often provide a specific command line flag to allow a developer to launch the browser with the new feature enabled.
• For a single user via chrome://flags
  As a feature progresses, it's often made available via an experimental flag within the more accessible chrome://flags interface. chrome://flags#enable-experimental-web-platform-features bundles together current experimental features.
• For your users, in an origin trial
  Once an iteration of a new feature is code-complete and relatively stable, an origin trial may be provided to allow individual sites to turn on the feature for Chrome users on their site. If an origin trial is available for an API you want to test with your users, register for the origin trial and provide a valid trial token with every page load.
• For users of early Chrome releases
  When a feature is approved to ship in a given release, it will progress through each Chrome release channel, including Canary and Beta, before it reaches Stable. The feature will be turned on by default for all users of those channels.

# Will SameSite become irrelevant after third-party cookies are deprecated?

• SameSite=Lax is the current default. While it does not strictly need to be included, it's good practice to specify it for cross-browser consistency.
• SameSite=Strict continues to be a more restrictive option, for cookies that must only be sent when the user is already on the site. This is and remains a good security practice for cookies that are part of managing particularly sensitive access.
• SameSite=None should continue to be sent for cross-browser consistency. However, Chrome's proposed change to phase out third-party cookies would result in those cookies no longer being sent as is in cross-site contexts.

The exception is cookies that are modified by either the CHIPS or First-Party Sets proposal. These allow for a subset of cross-site use cases. As these proposals are under active discussion, the final formats and functionality may change.

# Engage and share feedback

• GitHub: read the explainers on GitHub and raise questions or comments in the Issues tab for each.
• W3C: Use cases can be discussed and industry feedback shared in the W3C Improving Web Advertising Business Group, the Privacy Community Group, and the Web Incubator Community Group.
• Developer support: Ask questions and join discussions on the Privacy Sandbox Developer Support repo.

# Find out more

• Digging into the Privacy Sandbox
• A Potential Privacy Model for the Web sets out the core principles underlying the APIs.
• Chromium's overview of the Privacy Sandbox
• Google AI Blog: Federated Learning: Collaborative Machine Learning without Centralized Training Data
• The future of third-party cookies

# Stay up to date on the progress of the Privacy Sandbox

You can follow the monthly updates to the Progress in the Privacy Sandbox series of articles which also includes an RSS / Atom feed where you can subscribe with your preferred reader.

The article series links to the matching monthly updates to the Privacy Sandbox timeline which shows the current status and schedule for proposals.

These high-level resources will provide signposts to changes across the project, but for individual proposals where you want to follow in detail you should:

• Watch or Star proposal repos on GitHub to get notification of new issues and updates: the Privacy Sandbox status page provides a link to the repo for each proposal
• Join the associated W3C group for regular meetings discussing the proposal detail
• Star the associated entry on Chrome Platform Status for email updates on Chrome implementation changes.

# Get involved

• Participate in incubation, testing and refinement of the APIs:
  How to participate in the Privacy Sandbox initiative
• As a developer, join discussions or ask questions:
  Privacy Sandbox Developer Support

For questions about specific APIs, you can file an issue on the GitHub repo for an API Explainer.