ShieldLabs
Back to blog

What was Google's Privacy Sandbox, and why did it end in 2025?

Privacy Sandbox timeline: Google's set of privacy APIs marked retired in October 2025, while third-party cookies and device-level identification stay in place

Last updated on July 21, 2026 · 8 min read

The Privacy Sandbox, Google's multi-year effort to replace third-party cookies with a set of privacy-preserving web APIs, is over: on October 17, 2025, Google announced it was retiring most of the technologies in its Update on Plans for Privacy Sandbox Technologies. The plan to remove third-party cookies from Chrome is also gone, so the cookies the Sandbox was built to replace are staying. For anyone who spent the past few years bracing for a cookieless web, the ground just shifted, and it is worth being precise about what actually changed. This guide explains what the Privacy Sandbox was, how it worked, why Google ended it, and what its end does, and does not, mean for identity and fraud detection.

Key takeaways

  • The Privacy Sandbox was a Google initiative, started around 2019, to replace third-party cookies and cross-site tracking with privacy-preserving web APIs like Topics and Protected Audience.
  • On October 17, 2025, Google announced it is retiring most Privacy Sandbox technologies, citing low adoption and ecosystem feedback, with deprecation beginning in Chrome 144 and removal targeted for Chrome 150.
  • Third-party cookies are staying in Chrome. Google dropped the plan to deprecate them and kept the existing user-choice controls, with no removal timeline.
  • Cookies staying does not make cookies a reliable fraud signal. What persists for recognizing a returning user is device-level identification, and it is unaffected by the whole saga.

What was the Privacy Sandbox?

The Privacy Sandbox was a set of browser technologies Google began building around 2019, with one goal: let the advertising web keep functioning, targeting ads and measuring campaigns, without third-party cookies and the cross-site tracking they enable. Third-party cookies are the small files an ad network or analytics vendor drops from a domain other than the one in the address bar, and following them from site to site is how much of the industry has profiled users for two decades. That mechanism is also what browsers, regulators, and privacy advocates spent years pushing back against.

Google's answer was to move those advertising functions inside the browser, where the raw browsing history never leaves the device. Instead of a cookie that a hundred trackers can read across a hundred sites, the browser itself would compute a coarse interest signal or run an ad auction locally and hand back only a limited, privacy-preserving result. The Privacy Sandbox was that collection of APIs, plus the plan, announced and then repeatedly delayed, to eventually turn off third-party cookies in Chrome once the replacements were ready.

It is worth being honest about the frame here: the Privacy Sandbox was mostly an advertising project. Its headline APIs were about ad targeting and ad measurement, which is a different problem from fraud detection. That distinction matters for what follows.

How the Privacy Sandbox worked

The Sandbox was not one feature but a suite, and the pieces that got the most attention were the ad-replacement APIs:

  • Topics API. The browser observed the sites a user visited, sorted them into a short list of broad interest topics, and shared only a few of those topics with sites that asked, replacing the cross-site profile a cookie used to build.
  • Protected Audience API (formerly FLEDGE). This ran remarketing and custom-audience ad auctions on the device itself, so an advertiser could reach a past visitor without a third party tracking that person across the web.
  • Attribution Reporting API. This measured which ad led to a conversion using aggregated, noised reports, instead of the click-level cookie trail advertisers traditionally relied on.

Around those sat a longer list of supporting technologies: Private Aggregation and Shared Storage, IP Protection, On-Device Personalization, Protected App Signals, Related Website Sets, SelectURL, and the SDK Runtime. Almost all of it served the advertising and measurement use case.

One piece stood apart from that ad stack, and it is the one worth remembering. Private State Tokens, evolved from the earlier Trust Tokens, were the Sandbox's privacy-preserving anti-fraud and attestation mechanism: a way for a site to carry a signal that a user was probably trustworthy from one context to another, without a cross-site identifier. It was the fraud-and-abuse tool in a toolbox otherwise built for ads.

Why Google ended it

On October 17, 2025, Google published its update saying it would retire most Privacy Sandbox technologies, citing low adoption across the ecosystem and the feedback it had gathered. The list of retired APIs is long: Topics, Protected Audience, Attribution Reporting, Private Aggregation and Shared Storage, IP Protection, On-Device Personalization, Protected App Signals, Related Website Sets, SelectURL, and the SDK Runtime. Deprecation begins in Chrome 144, in January 2026, and removal is targeted for Chrome 150, in July 2026.

The bigger reversal came alongside it. In a companion announcement on the next steps for Privacy Sandbox and tracking protections in Chrome, Google confirmed that third-party cookies are staying. The plan to deprecate them, the plan the entire Sandbox was built to enable, was dropped. Chrome keeps its existing user-choice cookie controls, and there is no removal timeline. The years of "cookies are going away" turned out to end with cookies right where they were.

Not everything was retired. A small set of non-advertising technologies survived the shutdown because they solved problems that were never really about ad targeting:

  • CHIPS (Cookies Having Independent Partitioned State), which lets a site use partitioned cookies scoped to a single top-level site.
  • FedCM (Federated Credential Management), the browser API for federated identity sign-in.
  • Private State Tokens, the privacy-preserving anti-fraud and attestation API.
  • Fenced Frames, an embedding primitive that isolates content from the page around it.

The pattern in that list is the whole story for a defender: the advertising machinery was retired, and the survivors are about sign-in, isolation, and fraud.

What the end of the Privacy Sandbox means for identity and fraud

The most useful thing to say about the Privacy Sandbox and fraud is that its end changes very little, because the Sandbox was never really the fraud story. It was an ad-tech story: targeting and measurement, not detecting a fraudster opening their tenth account. Reading the retirement as a shift in fraud fundamentals gets the two problems mixed up.

Start with the headline that sounds like good news for tracking: third-party cookies are staying. For fraud detection, that is close to a non-event, because cookie-based identity was never robust against an actual adversary. A fraudster clears cookies, opens an incognito window, or switches browsers in seconds, and the cookie is gone. A signal that resets whenever the person you are worried about wants it to reset is not a foundation for recognizing that person on their next attempt. Cookies staying does not make cookies reliable for fraud; it just leaves an unreliable signal in place.

What actually persists for recognizing a returning user is device-level identification: an identifier derived from stable device and browser characteristics rather than stored in the browser. Because it is computed from what the device is, not from a file the browser keeps, it survives cleared cookies, a fresh browser profile, and a rotated IP, which are exactly the resets abuse relies on. That approach lives entirely outside the Privacy Sandbox, so none of the retirements touch it. If your recognition already leaned on cookieless device identification rather than on cookies, October 2025 was a quiet month.

There is a smaller, telling detail in the survivor list. The one Privacy Sandbox technology that outlived the ad-stack shutdown, Private State Tokens, is the anti-fraud one. The industry spent years trying to preserve advertising without cross-site cookies and largely gave up; the fraud-and-attestation primitive is what stuck around. That is a reasonable proxy for where durable value sits when the tracking debate settles: fraud prevention outlived ad targeting. It is also consistent with a longer trend. Chrome began reducing the user-agent string back in 2022, which pushed durable identification away from a header anyone can rewrite and toward deeper device and network signals that are harder to spoof. The direction of travel has been the same for years, and the Privacy Sandbox drama does not reverse it.

How ShieldLabs identifies a device without third-party cookies

ShieldLabs recognizes a returning device without depending on a cookie or any Privacy Sandbox API. A single JavaScript snippet reads the stable device and browser characteristics a page already exposes and derives persistent identification from the whole combination, using device fingerprinting rather than a stored value. Because the identifier is computed from what the device is, it survives cleared cookies, a new browser profile, and a rotated IP, so the same machine stays recognizable across the resets abuse depends on. In 2026 we tested exactly that, clearing cookies, opening an incognito window, and rotating the IP between visits, and the device still resolved to the same identifier up to 99 percent of the time, which is the point: the recognition does not depend on the cookie the Privacy Sandbox debate was ever about. The goal is to recognize a returning device, not to identify the person behind it.

Each visit also returns a risk score from 0 to 100 with the named anonymity signals underneath it: VPN, proxy, Tor, and anti-detect browser use, the tools people reach for to make one device look like many. ShieldLabs surfaces the signal and the score; it does not decide the outcome. Your own rules act on what it surfaces, through the API and webhooks, so the verdict stays in your code. The free tier covers the first 5,000 identifications.

The honest scope: this is a detection and signal layer, not an ad-measurement or identity-resolution product, and recognition is probabilistic rather than guaranteed, accurate up to 99 percent. A genuinely new device on a new network reads as new, because there is nothing yet to recognize. ShieldLabs is web-first and does not detect bots. What it does is the narrow thing the Privacy Sandbox saga never touched: recognize a returning device after the cookies are gone.

Sources

  1. Google Privacy Sandbox: Update on Plans for Privacy Sandbox Technologies
  2. Google Privacy Sandbox: Next steps for Privacy Sandbox and tracking protections in Chrome
  3. Wikipedia: Privacy Sandbox
  4. MDN Web Docs: Privacy sandbox

Frequently asked questions

Is the Privacy Sandbox dead?
Effectively yes for its advertising technologies. On October 17, 2025, Google announced it is retiring most Privacy Sandbox APIs, including Topics, Protected Audience, and Attribution Reporting, with deprecation beginning in Chrome 144 in January 2026 and removal targeted for Chrome 150 in July 2026. A small set of non-advertising technologies survived: CHIPS, FedCM, Private State Tokens, and Fenced Frames. So the ad-replacement project ended, but a few pieces continue.
Are third-party cookies going away?
No. Google dropped the plan to deprecate third-party cookies in Chrome and is keeping the existing user-choice cookie controls, with no removal timeline announced. The Privacy Sandbox was originally meant to enable that removal, and when the Sandbox's ad APIs were retired the removal plan went with them. Third-party cookies remain in Chrome for now.
What replaced the Privacy Sandbox?
Nothing replaced its advertising APIs; Google retired them and left third-party cookies in place instead. The technologies that survived were never ad-targeting tools: CHIPS handles partitioned cookies, FedCM handles federated sign-in, Fenced Frames isolate embedded content, and Private State Tokens provide privacy-preserving anti-fraud attestation. For recognizing returning users, device-level identification continues to work independently of the Sandbox.
Does the end of the Privacy Sandbox affect fraud detection?
Very little. The Privacy Sandbox was mostly an advertising initiative, a different problem from fraud detection, and the fact that third-party cookies are staying does not make cookies a reliable fraud signal, because a fraudster clears them, opens an incognito window, or switches browsers in seconds. What persists for fraud and returning-user recognition is device-level identification derived from stable device signals, which sits outside the Sandbox and is unaffected. Notably, the one Sandbox technology that survived, Private State Tokens, is the anti-fraud one.
How does ShieldLabs recognize a device without cookies?
ShieldLabs reads stable device and browser characteristics through one JavaScript snippet and derives persistent identification from the whole combination, not from a stored cookie or a Privacy Sandbox API. Because it is computed from what the device is, it survives cleared cookies, a new browser profile, and a rotated IP. Each visit returns a risk score from 0 to 100 with named anonymity signals like VPN, proxy, Tor, and anti-detect browser use. Recognition is probabilistic, accurate up to 99 percent, your own rules decide the outcome, and the free tier covers the first 5,000 identifications.

Related articles