Expanding Privacy Sandbox testing

Today we shared an updated plan and timeline for Privacy Sandbox for the
web
and the path towards phasing out third-party cookies. Your feedback as web
developers and site owners has been instrumental in demonstrating the
importance of spending more time to get the proposals right and ensuring there’s
enough opportunity to test, integrate, and optimize the new solutions. This post
includes more detail on testing plans, including our intent to increase the
traffic volume in the unified Privacy Sandbox Relevance and Measurement origin
trial in August, and extend the duration of the trial.

The Privacy Sandbox project represents a broad and ambitious set of changes that
aim to tackle cross-site tracking for the web as a whole. It proposes open
standards everyone can implement rather than browser-specific features while
ensuring that sites can use third-party services in a safe and private way.
While phasing out third-party cookies represents a major milestone in
overall project progress, that goal of addressing all forms of cross-site
tracking is much wider! You should still expect the individual proposals and
features to launch throughout that journey. It is likely that your site will be
impacted in some way; you will want to ensure you understand how your sites and
services are affected, and know which proposals and features you should be
following.

Let’s break down the current status and look at what you need to know to
continue to test, provide feedback, and prepare for features on the path to
launch.

# Expanding the Privacy Sandbox Relevance and Measurement origin trial

The Privacy Sandbox Relevance and Measurement origin
trial enables the ecosystem to run
unified tests for technical stability and developer experience across
Attribution Reporting,
FLEDGE,
Topics, fenced
frames, and we will be adding Shared
Storage soon. The trial is currently
enabled for 50% of Chrome Beta
users
which has helped us to actively address early developer feedback and issues
without disrupting users too much.

As the origin trial progresses, we want to give developers the opportunity to
test the utility and effectiveness of the APIs with a meaningful proportion of
real-world traffic. With the Chrome 104 Stable launch at the start of
August, we will be expanding the
trial to desktop users on Chrome Stable. We plan to extend the trial to mobile
users starting from Chrome 105
Stable on Android. The origin trial
is scheduled to conclude at the end of the 104 Stable period—we are
requesting an
extension
through to Chrome 107 (late
October) to enable further
testing. This follows the standard practice of requesting origin trial
extensions in three-milestone increments. We’re committed to supporting testing
through to launching the APIs for general availability.

You can follow the official request to extend the Intent to Experiment
(I2E).
We will also update the Privacy Sandbox documentation
with implementation and testing guides.

If you deliver any of the services these APIs provide, then your participation
and feedback in the origin trial is invaluable. As we move to larger scale
testing, this is your opportunity to validate the proposals that meet your
needs. There is no need for expertise in web standards or browser
development—just your existing experience in your own field.

Once we reach a point where core functionality is sound and complete we plan
to start shipping the APIs for general availability, likely in early to mid
2023. Over the course of the origin trial there is, by design, scope for the
APIs to evolve based on testing and feedback. Individual features may launch
while the overall origin trial is still ongoing. After launching we will
continue to refine the APIs as we proceed through initial adoption and long-term
testing.

# Updating cookie behavior

The Cookies Having Independent Partitioned State (CHIPS) and First-Party Sets
proposals provide a route to support cookies in cross-site contexts that do
not involve tracking.

# CHIPS

CHIPS allows developers to opt a cookie into «partitioned» storage, with a
separate cookie jar per top-level site. Based on developer feedback during the
current origin trial we made a number of fixes and improvements along with
extending the trial period through to the end of Chrome Stable
104 at the end of August.
Specifically, we have removed
the more restrictive requirements for a __Host- prefix and no Domain
attribute to enable easier migration for sites using cookies across subdomains,
such as shop.example.com and blog.example.com.

With this positive feedback on both the proposal and the trial, we are hoping
to ship CHIPS after the conclusion of the trial. As per the official process,
you can follow the blink-dev mailing
list for when we post
the Intent to Ship
(I2S)
message.

That’s an exciting milestone because for many use cases where you provide an
embedded, self-contained service to another site such as a widget or API, this
lets you get your updates done well in advance of the third-party cookie
phase-out!

# First-Party Sets

First-Party Sets provides a method to group affiliated sites intended to allow
organizations that have multiple sites, such as different country-level domains,
to still use their own cookies in these specific cross-site but first-party
contexts.

Based on the feedback we received during discussion and testing of the feature,
we’re proposing a number of
changes that aim to both
address those issues and still satisfy the needs of the ecosystem. Specifically,
we are proposing that sets be defined in terms of use-case-specific «subsets».
We also propose that sites use the Storage Access API along with a potential
extension to request cross-site cookie access. This replaces the proposal for
the SameParty attribute.

We will update the developer guide as work progresses. If you’ve already been
experimenting with First-Party Sets or the use-case matches your needs, then
this is a good time to follow the discussions and get involved.

# Shipping user-agent reduction

We are currently reducing the information in Chrome’s user-agent string. As of
Chrome 101 in April, 2022, the minor or build version has been replaced with
zeroes. The upcoming
phases
will also replace the OS/platform version and device model with fixed
values. This will start for desktop from Chrome
107 in October, 2022 and for mobile
from Chrome 110 in January, 2023.
This timeline remains the same and is not affected by the changes to the
phase-out schedule for third-party cookies with the fully reduced user-agent
being rolled out by early 2023.

The changes to the string are intended to be backwards-compatible, so if you
do not need those specific values then you will not be affected. However, if you
do parse the user-agent string to extract the browser minor/build version,
OS/platform version, or device model then you will need to migrate to
User-Agent Client Hints.

# Storage partitioning

Cookies are the most prominent feature used for cross-site tracking, but the
Privacy Sandbox aims to tackle cross-site tracking as a whole—and that
includes all forms of cross-site storage. In a similar way to how we already
partitioned the HTTP cache in 2020, we also
intend to partition storage APIs like IndexedDB and localStorage,
communication APIs like BroadcastChannel and SharedWorker, and features that
span both of those categories like ServiceWorker.

We have sent the Intent to Prototype (I2P) for this
work
which means we are progressing through designs and initial code for the various
APIs. Within the current Chrome 105
Canary we are planning to have a
flag available to enable local developer testing. You should expect these
changes to progress through the standard Chrome development process as work
completes which we expect to be in early 2023, in advance of the overall
third-party cookie phase-out.

# Developer documentation and support

To help you navigate Privacy Sandbox as a whole we have
privacysandbox.com which provides the concepts,
goals, and timelines for the project across web and Android. Here on
developer.chrome.com/privacy-sandbox/ you can find the
details for individual proposals, demos, testing and implementation guides,
along with links out to wider resources for involvement.

We are holding regular developer Office Hours sessions across a variety of
Privacy Sandbox topics. In each of these we bring in the engineering and product
teams, run through a demo, and then answer your questions on implementation and
testing. We publicize each session on the @ChromiumDev
Twitter and on the mailing lists for the
matching API. We’re already providing a Japanese language session along with
repeats for different timezones, but will also continue to improve the programme
to post subtitled videos of the demos and making it easier for you to submit
topics and questions in advance.

We also have our developer support repo on
GitHub. If
you’ve run into an issue or have a question and don’t know where to raise it,
then post an issue there and we will help answer it or find the right place for
you to get involved.

# Providing and sharing feedback

While the Privacy Sandbox as a project was initiated by Google, the goal is that
we are making proposals to change the web platform as a whole, not just
feature changes in Chrome. That is an open and collaborative process across a
large number of groups that includes browser vendors, site owners, and most
importantly the people who use those sites and browsers—the users. While the
resulting specifications are written in very explicit and formal language (since
they need to define the process fully enough to implement) the process of making
sure that specification does the right thing needs input from everyone.

We hear from a lot of companies who want to know who else is testing and how
those results will be shared. It’s up to you, as testers, to decide to make
your testing plans and results public—and we strongly encourage you to do so!
There are a number of public forums across the W3C, GitHub, mailing lists where
you can share directly with other stakeholders. This might be as simple as
stating that you’re actively participating in an origin trial, whether or not
you had all the material you needed to implement, or detailed analysis of the
results of your tests. You can also publish to your own sites, blogs, or social
accounts—especially where you have a specific audience you want to talk to.

Our feedback page covers each of the different
routes and the active ones for each API. You
can also provide feedback directly to us via our feedback
form.

In the end, by changing how cookies behave we’re changing technology that has
been part of the web for 28 years. The web belongs to all of us, and working
through these changes to find that ideal mix that enables a more private
environment while still enabling the rich, open ecosystem we all love will
continue to require your input and direction. We’re looking forward to the rest
of the journey together.