Privacy Sandbox logo

Progress in the Privacy Sandbox (August 2021)

Published on Updated on

In July 2021 we shared a detailed timeline for our Privacy Sandbox work. Privacy Sandbox is an effort to move towards a web that's private by default by phasing out third-party cookies and preventing covert tracking workarounds. The timeline will be updated monthly and you can use it to track all phases and milestones. We'll also be sharing accompanying articles and videos with more details.

There's a request for you in this before we start—this whole effort only succeeds if we go on this journey together. All this work happens in the open, but needs input from the ecosystem so that we end up with proposals that can work for the web platform as a whole—not just one browser.

However, there's a lot to track! "Progress in the Privacy Sandbox" aims to provide all the signposts you need to get involved with the proposals at the right time for your needs—consider this and the upcoming video as the pilot episode. We need your feedback to ensure these posts are worth your time each month!

You can share your feedback with the team on @ChromiumDev on Twitter or via an issue on GoogleChromeLabs/privacy-sandbox-dev-support on GitHub.

With that, let's take a look through the updates over the past month.

Strengthen cross-site privacy boundaries

Third-party cookies are the key mechanism that enables cross-site tracking. Being able to phase them out is a major milestone, but we also need to tackle other forms of cross-site storage or communication.


At Google I/O, we shared a flow chart covering the proposals and actions that are suitable for the different cookie use cases.

Is my cookie used cross-site? No: Use the good first-party cookie recipe. Yes: Partitioned 1:1 - check the CHIPS proposal, State sharing across domains of the same party - use First-Party Sets, State sharing across sites (different parties) - try the new APIs

As part of our Mother Language Day series, Maud shared a video overview in French that walks through improvements you can make now to your first-party cookies.

We published the Intent to Prototype (I2P) for CHIPS, or Cookies Having Independent Partitioned State. This means we're ready to start writing code for the feature. CHIPS enables use cases that require cross-site cookies where their usage is contained, or partitioned, to just one top-level context. For example, cross-site embeds or API calls where you may be using a cookie for some form of session or saving state. Publishing the I2P means you should expect to see the feature available behind a flag in a coming release. If you think CHIPS would be useful for your cookies, you should track the I2P thread or the Chrome Status entry for availability. We will also have more articles and demos ready for you to see the feature in action.

A new video overview from Sam on First-Party Sets is out as a part of our "What is the Privacy Sandbox?" series exploring individual proposals.

There is another I2P out to bring Chrome's cookie size limits in line with the HTTP standard and closer to Firefox's behaviour. This is a minor change as Chrome already rejects cookies over the 4096 character limit. If your site is regularly setting cookies close to this value you should ideally try to reduce that regardless, but also check the details of the I2P for the exact changes. DevTools already shows rejected cookies and will be updated inline with the new limits.

Additional clean up work

There is an Intent to Deprecate and Remove (I2D / I2R) the already deprecated Web SQL API in third-party contexts and another I2D for the "persistent" quota type on the already deprecated webkitRequestFileSystem API. The Chrome usage metrics are low, but if your site is still using either window.openDatabase() in an iframe or window.webkitRequestFileSystem(window.PERSISTENT, […]) then check the links for the potential impact.

Preventing covert tracking

As we reduce the options for explicit cross-site tracking, we also need to address the areas of the web platform that expose identifying information that enables fingerprinting or covert tracking of users.

User-Agent string reduction and User-Agent Client Hints

The full User-Agent string is a major source of highly identifying information about the browser and device. In May we shared plans for how Chrome will be reducing the detail in its user-agent string. As part of phase 1, Issues are already appearing in DevTools to help sites audit where they are accessing navigator.userAgent.

DevTools Issues panel showing an Improvement issue advising the developer to audit usage of navigator.userAgent, navigator.appVersion, and navigator.platform

For phase 2, we've shared the Intent to Experiment (I2E), which means we want to run an origin trial allowing sites an early opt-in for receiving a reduced user-agent string. If you process the user-agent in some way on your site—via the HTTP header or in JavaScript—consider participating for an early indication of any changes you may need to make. The origin trial is planned to start from Chrome 95 and we will announce when it is available for registration.

If you require the extended information from the User-Agent, then User-Agent Client Hints (UA-CH) provides that functionality for both HTTP headers and JavaScript. Check out the migration guide for integrating this into your site.

UA-CH is available by default in Chrome Stable and we are continuing to improve functionality with ecosystem feedback. The Microsoft Edge team is contributing an I2P to improve the platform version data provided for Windows.

Show relevant content and ads

As we move towards phasing out third-party cookies, we need to introduce APIs that enable the use cases that depended on them but without continuing to enable cross-site tracking.


FLoC is a proposal to enable interest-based advertising without the need for individual cross-site tracking. The origin trial for the first version of FLoC ended in mid-July and we are evaluating improvements for the next version of FLoC before advancing to further ecosystem testing. If you're still serving your origin trial token for FLoC or other experimental code, then now is a good time to clean up.

Shared Storage API

We published an I2P for the Shared Storage API. This is a relatively low-level storage component that's intended to support aggregate reporting and content filtering of cross-site data. The idea is that an origin can write to its storage across multiple embedded contexts and then only read back through a very limited interface. For example, providing a single value for a consistent A/B test or reach/frequency capping across multiple contexts but without allowing direct access to that identifier.

It is an active area of discussion currently, so if you are interested in the design phase then raise issues in the repo, but further testing and origin trials are still to come.

Measure digital ads

As the companion to displaying ads without cross-site tracking, we need privacy-preserving mechanisms to enable measuring the effectiveness of those ads.

Attribution Reporting

The core Attribution Reporting API has been in origin trial since the end of 2020, under the name Event-Level Conversion Measurement API.

There were a number of API changes from Chrome 92—we've published a guide for migrating from Conversion Measurement API to Attribution Reporting API—and we're also extending the trial period through to Chrome 93 stable. We have also extended the "Discussion" phase on the timeline to reflect the ongoing work on aspects such as aggregate and cross-device reporting.

Event-level reports are generated as follows: the browser matches clicks or views (attribution source events) with conversion data (attribution trigger data) defined by an adtech. Later, the browser sends the resulting reports to a predefined endpoint, with some delay and noise.

We've published an introduction to Attribution Reporting and video overview to cover how the API works, the main use cases, API implementation status, and how it compares with third-party cookies.

Fight spam and fraud on the web

The other challenge as we reduce the surfaces available for cross-site tracking is that these same fingerprint techniques are often used for spam and fraud protection. We need privacy-preserving alternatives here as well.

Trust Tokens

Trust Tokens is a proposal that allows one site to share a claim about a user—such as "I think they're human"—and enable other sites to verify that claim, but in a way that doesn't allow linking the user across those sites.

As part of the "What is the Privacy Sandbox?" series, Sam has a short video overview of the Trust Tokens API.

The origin trial for Trust Tokens has been open since Chrome 84 and is planned to run through to Chrome 94, so there is still time to experiment on your sites.

We also published an I2E on Android Platform-Provided Trust Tokens exploring the potential to issue tokens from a wider range of sources than just other websites. This is intended as a very limited initial experiment to work through the server-side implementation and aim for wider experimentation based on the lessons learned here.


Look for the pilot video coming soon and another edition of this series next month. The goal is to make this round-up useful and actionable for you, so remember to let us know anything we can improve!

Last updated: Improve article

We serve cookies on this site to analyze traffic, remember your preferences, and optimize your experience.