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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3