Ready for Builders

Together with the industry, we’ve spent the last four years developing new building blocks for a better internet—one that keeps people’s activity private and supports free experiences for everyone. We call these building blocks the Privacy Sandbox, and they’re already being incorporated by companies across the industry to develop more private solutions.

In the physical world, raw construction materials don’t become a home without a builder who assembles them using their expertise and creativity. A more private internet also requires builders—in this case, developers who choose to use the Privacy Sandbox, alongside other technologies, to evolve existing solutions and create new ones.

A necessary and achievable change

It’s imperative we work together to transition the internet to become more private. Users deserve it, and a growing set of regulations require it. Making this transition while continuing to support free access to online content and experiences is the core of Privacy Sandbox’s mission. This requires new privacy-preserving technologies that support key developer needs—including online advertising—that today rely on third-party cookies and other identifiers that can track user activity across sites.

In contrast, other web browsers have restricted third-party cookies without providing viable alternatives to support developers. This makes it harder for publishers to support their content and services, and it's bad for user privacy because it leads to more covert forms of user tracking.

But make no mistake; even with new building blocks in place, moving away from third-party cookies is a significant change. After all, the industry has optimized around cookies for nearly three decades! And change is hard, requiring time and effort to understand and adopt new approaches.

When changes are big, people often object. We’ve heard feedback that the Privacy Sandbox is insufficient or too complex to adopt. While we’re always open to constructive feedback, we want to address some common objections we’ve heard, so that everyone can make an informed decision about whether to build using the Privacy Sandbox.

Responses to common objections

Objection 1: Privacy Sandbox doesn’t provide one-to-one replacements for third-party cookie supported use cases

Privacy Sandbox APIs are not intended to be direct, one-to-one replacements for all third-party cookie based use cases or to be a standalone ad tech solution. Instead, they are designed to provide foundational elements that support core business objectives for marketers and publishers (like driving online sales and serving relevant ads), without cross-site identifiers. Developers can utilize them alongside other technologies and inputs to achieve those outcomes. Similarly, products built on third-party cookies also require layers of technology and services to address business needs.

Because these APIs, by design, don’t recreate the same functionality of third-party cookies and other cross-site identifiers, developers may need to redesign how their existing products work. For example, running an ad auction on-device means that previously server-only functionality will now interact with ad tech code running in a browser. And certain capabilities that relied on third-party cookies, like audiences based on profiles of user activity across websites, will not be possible to directly replicate using the Privacy Sandbox.

We believe the current Privacy Sandbox APIs—generally available in Chrome since September—are ready to carry the ecosystem into a more private future. And we’re committed to pushing privacy-preserving technologies forward for years to come, both in terms of privacy and utility.

Objection 2: Privacy Sandbox is too complex compared to using identifiers

Building more private online advertising solutions—ones that don't rely on cross-site identifiers—represents a paradigm shift. So it's not surprising that some industry responses to third-party cookie deprecation have been to develop new cross-site identifiers. While these are easier to retrofit into existing products and are often described as ‘privacy first’, in practice they may not represent meaningful improvement on third-party cookies because they still enable users to be re-identified across sites.

Designing systems that shield the identity of the user across sites and restrict the amount of available data, while enabling key developer outcomes, requires technology innovation and an openness to new paradigms.

Using new, privacy-preserving building blocks also requires effort, ingenuity and time. We’re encouraged by the builders we already see retooling their solutions using the Relevance and Measurement APIs as key building blocks to achieve advertiser goals, without third-party cookies and unbounded cross-site data. Companies are using these APIs to train machine learning models and even offer entirely new products. Over time we expect to continue working with developers and engaging with their feedback to maximize the opportunities they can unlock for their customers on top of Privacy Sandbox. For example, we built a Noise Lab for developers to experiment with noisy reporting and tune the configurable measurement APIs to their specific needs. And Privacy Sandbox Demos provides example code for how developers might address key use cases.

Objection 3: Future Privacy Sandbox capabilities are uncertain

We previously shared that some Privacy Sandbox technologies will be required in the future to further strengthen privacy protections. For example, for Protected Audience, we’ll require use of Fenced Frames for ad rendering, and transition away from event-level reporting, no earlier than 2026. We’ve provided “no sooner than” dates for each of these future requirements, so the industry has clarity on the intended evolution of the APIs. The additional time allows us to continue working with the industry to design and implement support for a broader range of critical use cases. For example, we will evolve Fenced Frames ahead of their requirement in 2026+ to maintain support for video and native ads with Protected Audience API. Per our commitments, the UK Competition and Markets Authority (CMA) will be consulted on such changes, and we will continue engaging with feedback from the ecosystem ahead of implementing those “no sooner than” requirements.

Some have asserted that we must have complete technical designs ready today for these future Privacy Sandbox changes, before the industry can adopt the current technologies. We disagree. Internet technologies have and will continue to evolve, but that shouldn’t block progress with the current set of building blocks. Providing transparency on the intended evolution, and time for the industry to collaborate, is the best way to ensure that these technologies will continue to advance in ways that benefit users and the ecosystem.

Objection 4: Google’s products must have some advantage in Privacy Sandbox

All businesses and developers who use Privacy Sandbox technologies—including Google—have the same access to the same Privacy Sandbox capabilities. We have committed to the CMA to ensure that the APIs do not advantage Google or give special treatment to Google products and services. Google is actively incorporating the same Privacy Sandbox building blocks that are available to everyone into its products—including Google’s ads products.

Objection 5: Building on the Privacy Sandbox is too costly

Building solutions to enable a more private web requires real investment of resources, time, and energy. But that investment is necessary to rebuild user trust and ensure the future of the free and open internet. Today, more than half the world is covered by comprehensive privacy and data protection laws, and these requirements are increasing. Additionally, other browsers are moving to restrict cross-site identifiers and limit how users can be tracked across sites and apps. Taken as a whole, the return-on-investment of building for better online privacy is significant and growing.

And innovative solutions often require new technologies to advance what’s possible. For Privacy Sandbox, this includes the use of privacy-enhancing technologies like cloud-based Trusted Execution Environments (TEEs) that protect user data while enabling sophisticated data processing. This may mean new investments for some ad tech, but over time we can expect increased adoption to drive greater efficiencies and lower costs—just as we've seen with other foundational internet technologies.

Improving privacy can also directly benefit businesses. For example, reducing cross-site tracking gives publishers better protections against costly first-party data leakage risks that exist with third-party cookies. This additional layer of data protection can create new product opportunities with first-party data, and we’re already seeing companies take steps in this direction.

Objection 6: Privacy Sandbox APIs aren’t based on real ecosystem input

The Privacy Sandbox represents the collective work of hundreds of individuals across the industry who’ve dedicated thousands of hours in various forums to discuss, debate, and provide feedback on the API designs.

Protected Audience is a great example of how the Privacy Sandbox has been shaped through this collaboration. It evolved from TURTLEDOVE, proposed in 2019, based on ideas from many companies including Criteo, RTB House, OpenX and NextRoll. For instance, Criteo proposed the addition of a service model running in a trusted execution environment (TEE); RTB House improved the anonymity model and personalization capabilities of the on-device auction; OpenX proposed the structure for multi-seller auctions to enable publisher choice in monetization; and NextRoll contributed the buyer and seller distribution of responsibilities in the current design.

And Protected Audience is just one example. In the last year, we’ve made updates—based on direct ecosystem input—to Topics (an updated taxonomy and top topics selection methodology), Attribution Reporting (flexible event-level configuration), and more. Industry input has been, and will continue to be, vital in shaping the Privacy Sandbox APIs.

Objection 7: Moving the timeline for third-party cookie deprecation will help the ecosystem prepare

We understand some people want more time, but we have heard repeatedly from the industry that moving the timeline is likely to result in less ecosystem preparedness, not more. A recent Digiday survey on industry preparedness concluded, “there is one big thing that could catalyze the industry to get ready for a post-cookie world, and that would be for Google to stick to its deadline.” While the timeline to deprecate third-party cookies is subject to addressing any remaining competition concerns from the UK CMA, we are encouraging everyone to prepare for third party cookie deprecation in 2024.

Preparing for change

A growing number of organizations are leaning into this change. They’re showing it’s possible to evolve their existing solutions, and build new ones, using Privacy Sandbox and other privacy-preserving technologies. It’s inspiring to see these innovations, and we’re excited for how they’ll advance over time.

For those ready to take the next step towards meaningful change for privacy on the web, learn more at privacysandbox.com and developer.google.com/privacy-sandbox.