Proposal lifecycle in the Privacy Sandbox

The Privacy Sandbox proposals are the first of many steps necessary in the creation of web standards.

Web standards are technical documents—known as specifications or specs—which detail exactly how web technology should work. These specs are for developers to implement the technologies. For example, the Accessible Rich Internet Applications (WAI-ARIA) standard (commonly known as just "ARIA") defines technical ways to make the web more accessible to those with disabilities. These specs are developed for and by the World Wide Web Consortium (W3C), an international community with full-time staff, member organizations, and feedback from the general public.

After discussion, testing, and scaled adoption, some proposals will become specs. It's critical we receive feedback from developers and industry leaders (with and without web technology knowledge) to ensure we create durable web features with broad utility and robust privacy protections for users.

Chromium (the open source platform behind many modern browsers) has written about the feature development process for all technologies which aim to become a web standard. Because of the critical nature of privacy and security on the web, we expect and encourage large amounts of discussion and feedback before testing begins.

# From proposal to web standard

There is a large amount of ecosystem input shaping this work, at every stage of development. This process may be familiar to web developers, but may be new to other industry stakeholders who will use these purpose-built APIs—and whose expertise is critical to this initiative.

# Start with discussion

There have been dozens of privacy-preserving proposals offered by Chrome and others over the last couple of years. You can read these proposals, ask questions, offer ideas to improve them and see what others are saying.

To find conversations where the proposed solutions are being discussed and debated together, there are a number of W3C groups you can join or monitor, depending on the use cases you're interested in:

• Improving Web Advertising Business Group
• Private Advertising Technology Community Group
• Privacy Community Group
• Web Platform Incubator Community Group
• Federated Identity Community Group

The discussion stage can be highly involved.

For example, FLEDGE is a proposal to support interest-based advertising without cross-site tracking. With input from privacy advocates and many industry stakeholders, FLEDGE has evolved from two previous proposals (PIGIN and TURTLEDOVE). More than one hundred organizations have joined W3C meetings to help refine the current version, plus over 200 online discussion threads.

There have also been more than half a dozen other proposals offered by other companies, in the same solution space. Through continued collaboration, we hope to define a path forward.

At the same time, testing for FLEDGE was made available behind a Chrome flag so developers can access it early.

Not every proposal will go through such an intense incubation period as FLEDGE—some will move much more quickly—but there is a lot of innovation happening. These are new ideas and it can take a lot of work to get them right.

# Developers test and share feedback

Testing is critical because it provides an early opportunity to provide feedback on improvements or issues that require more work. A growing number of Privacy Sandbox proposals are available for testing now with a variety of options available to you.

Testing in Chrome usually starts with a feature behind a flag for developers to test locally, without that feature being live. This means developers need to turn it on in the browser to try it out. This code is often very fresh, so you can expect to find issues.

We also run origin trials, each of which run for a limited time with a limited population of Chrome users. Origin trials are public and open to all developers—you just need to register to opt in your site or service. This is your opportunity to try the feature on production traffic and provide feedback on real-world experience.

When a feature is initially made available for testing, the focus is generally on functional or technical testing. With new code, there is an expectation that contributors will discover and report bugs, as well as provide fixes for those bugs. This means the stability and shape of a feature may change quickly in this period. Receiving feedback on the integration and developer experience is critical to ensure that debugging and tooling support can be created alongside the feature.

As development progresses and the features become more stable, the focus shifts to wider scale effectiveness or utility testing. The aim of utility testing is to understand the performance of the feature against its intended use cases, at scale. At this stage, the population of Chrome users included in the experiment is increased in order to obtain a larger, more representative sample. During this phase, we hope to see sites running longer term tests over a larger portion of their own traffic to validate the feature against their business needs.

Success throughout this process depends both on developers doing hands-on testing and being willing to share what they learn. We will also be carrying out our own testing through these phases and sharing the results with you through the various individual project channels with regular summaries across the project in our Progress in the Privacy Sandbox blog series and quarterly feedback reports as part of our commitments agreed with the CMA.

Whether you share your testing in public places like the W3C, feedback forms, or through direct partnership channels, we hope to hear from you.

Testing in the browser, either through feature flags or origin trials, isn't the only way to explore how new technologies might work. Some companies are also building simulations based on Privacy Sandbox concepts.

# Launch for scaled adoption

Once an API is tested and ready for general use in Chrome, we announce the launch and make sure public documentation is ready for scaled ecosystem adoption.

User-Agent Client Hints (UA-CH) launched in Chrome in 2021. It's part of the Privacy Sandbox work stream to reduce covert tracking such as browser fingerprinting.

Like cookies, the User-Agent (UA) string is an early web feature. By default, it provides a lot of information about the user's browser and device, making it a readily available surface for fingerprinting. It also has a format that can be a headache to parse.

The reduced User-Agent includes the browser's brand and a significant version, where the request came from (desktop or mobile), and the platform. In the future, you’ll need to use UA-CH if you need to access more data in the future, such as specific information about the user's device or conditions.

In other words, the User-Agent data is moving from an "available by default" model to an "on request" model. This is a good privacy practice today, and the pattern we want to set for the future.

In April 2022, gradual UA string reduction will begin in Chrome. UA-CH launched and was ready for scaled adoption starting in March of 2021—you can begin testing and migrating to it now. Participate in an origin trial to opt-in to the reduced UA string so you can see what the future state looks like.

It's important that developers have ample time to transition their websites to adopt new standards. If it turns out your site needs extra time, you'll be able to opt-in to keep using the User-Agent string as-is through March 2023.

# Wrap up and feedback

We'll continue to explain what's happening, provide as much forward visibility as we can, encourage your involvement, and hear your input.

• Learn about the many ways in which you can provide feedback.
• Read the technical details and implementation guidelines.
• Share your feedback with @ChromiumDev on Twitter.
• Submit Issues to the developer support repo.

Much of this content was originally shared as a part of the 2021 Chrome Developer Summit recap.