Progress in the Privacy Sandbox (March - April 2022)

Welcome to the start of year edition of "Progress in the Privacy Sandbox", covering March and April 2022, as we track the milestones on the path to phasing out third-party cookies in Chrome and working towards a more private web. In each edition, we share an overview of the updates to the Privacy Sandbox timeline along with news from across the project.

# Privacy Sandbox Relevance and Measurement origin trial

Early developer feedback and the ability to evolve proposals based on that feedback continues to be a top priority for us. We have opened a combined origin trial for Attribution Reporting, FLEDGE, and Topics to allow for initial feedback on these APIs in real world environments.

We're starting with a very small proportion of users on the Chrome Beta channel, starting with Chrome 101. Our aim is to initially focus on testing the infrastructure setup, developer experience, and user interface so we can adjust and iterate before expanding the trial to a larger selection of users.

If you are thinking about integrating any of these APIs, you can sign up for the origin trial now. We have full instructions on how to join, how to test, demos to explore, and where to provide feedback for the different aspects of the trial.

As we're focusing on this early stage, you should expect to see regular changes in the code as we improve the experience and fix issues. You can follow this blog series, posts on the blink-dev mailing list, and the individual developer mailing lists for the proposals as we validate this foundation and expand the experiment for more scaled testing.

# Feedback

Feedback from a diverse set of stakeholders across the web ecosystem is critical to the Privacy Sandbox initiative as a whole. The dedicated feedback section provides an overview of the existing public channels where you can follow or contribute to discussion along with a feedback form to ensure you can always reach the Chrome team directly.

We are also starting to run a series of office hours sessions where you can ask questions directly to the teams. We ran initial sessions on the general origin trial set up and will announce future topics shortly. This is your chance to talk directly to the people building the functionality and they want to hear the issues you're encountering.

# Strengthen cross-site privacy boundaries

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

# Cookies

As the cookie-related proposals progress, you should audit your own SameSite=None or cross-site cookies and plan the action you will need to take on your site.

# CHIPS

CHIPS (Cookies Having Independent Partitioned State) allows developers to opt a cookie into "partitioned" storage, with a separate cookie jar per top-level site. The CHIPS origin trial is available now and we have developer instructions available so you can test cookies with the Partitioned attribute on your own production site.

# Additional cookie updates

We are also continuing to clean up and improve the general specification and functionality of cookies. The RFC for cookies has been updated to provide an explicit limit of 400 days on a cookie whether that's via the Expires or Max-Age attribute. We have sent the I2P and I2S with an aim to implement in Chrome 104. Existing cookies will be unaffected, but setting a new cookie with an expiry beyond the limit will cap its expiry at 400 days in the future. If you do want cookies that persist for longer than this, you should regularly re-set the cookie with an updated expiry.

# Federated Credentials Management

The Federated Credentials Management API builds on existing identity provider use cases to allow new and existing federated identity use cases to continue without third-party cookies. The first origin trial for FedCM is now available for sign-up and we have developer documentation for the trial along with a new section providing an overview and demos for the API.

# Network State Partitioning

Network State Partitioning continues the pattern implemented in HTTP Cache Partitioning by creating finer-grained containers for caches, which prevents cross-site information leakage. We have sent an I2E to better understand the performance impact of where that partition is defined: double-keying (top frame site) versus triple-keying (top frame site and frame site).

No developer action is required here and any potential impact from the experiment should be minimal as this will only run on 1% of Chrome Stable traffic.

# 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

We are incrementally reducing the information passively available in Chrome's user-agent string and providing alternative User-Agent Client Hints (UA-CH) for sites that need to actively request that information. In Chrome 101 we are starting the first phase of the reduction, by replacing the build or minor version with zeroes.

Note: We are incrementally rolling out this change as we monitor for issues, so you will not immediately see the reduced string on all 101 instances, but you should expect it to appear in a growing proportion of traffic over time.

We also sent an I2E to extend the origin trial for an early opt-in for the full user-agent string reduction if you would like to test the proposal final format against your production traffic. You can sign up on the origin trial site now. We also continue to offer the deprecation trial to retain the full user-agent string if you need more time to prepare for migration.

User-Agent Client Hints is also receiving an update with an I2S to update the GREASE behavior. This means where Chrome currently sends a brand, " Not A;Brand" which includes special characters to ensure clients correctly parse the format, you can expect that value to change between Chrome releases to continue encouraging robust parsing.

# Fenced Frames

A fenced frame (<fencedframe>) is a proposed HTML element for embedded content, similar to an iframe. Unlike iframes, a fenced frame restricts communication with its embedding context to allow the frame access to cross-site data without sharing it with the embedding context. For example, in FLEDGE the intent is for ads to be displayed within a fenced frame.

You can read the new developer overview content and we have sent an I2E to make fenced frames available as part of the wider Privacy Sandbox Relevance and Measurement origin trial starting during the Chrome 102 Beta.

# Show relevant content and ads

As we move towards phasing out third-party cookies, we are introducing APIs that enable key use cases that sites depended on to allow them to fund their content without continuing to enable cross-site tracking.

# Topics

The Topics API is a proposal to enable interest-based advertising without cross-site tracking. We sent an I2E to include Topics as part of the Privacy Sandbox Relevance and Measurement origin trial. We also have new developer guidance for the testing and providing feedback on Topics during the origin trial.

As this is early stage testing, we are actively discovering and addressing issues in the code as they come up. On Topics, we discovered a crashing bug so temporarily disabled the API within the origin trial to allow the fix to roll out without overly impacting the user experience.

# FLEDGE

FLEDGE enables remarketing and custom audience use cases, as in advertising that can make use of sites or products previously visited, without relying on an individual identifier. We sent an I2E for FLEDGE, again to enable it as part of the wider Privacy Sandbox Relevance and Measurement origin trial. And likewise, there's matching developer documentation for the experiment available.

# 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 API

The Attribution Reporting API enables functionality to measure events on one site, like clicking or viewing an ad, that lead to a conversion on another site—without enabling cross-site tracking. As you may have guessed, there was also an I2E for Attribution Reporting to continue expanding its testing as part of the Privacy Sandbox Relevance and Measurement origin trial.

During the initial stage of the origin trial we are focused on feedback around the developer experience and integration, such as debugging, and this will expand to cover end-to-end testing across event-level and summary reports.

# Article feedback

As we continue to publish these updates and progress through the Privacy Sandbox as a whole, we want to make sure that you as a developer are getting the information and support that you need. Let us know on @ChromiumDev Twitter if there's anything that we could improve in this series. We'll use your input to continue improving the format.