In October 2025, Google quietly retired most of the Privacy Sandbox APIs. Third-party cookies, once destined for extinction, stayed in Chrome. The ad-tech industry breathed out. Publishers celebrated. LinkedIn filled with victory laps.
Almost nobody in that room was a security engineer.
If your job is to keep fraudsters, bots, and multi-accounters off your platform, none of what happened in the last six years changed anything for you. The cookie war was an ad-tech war. Fraud prevention was not invited, did not participate, and did not benefit — regardless of who won.
This is worth saying clearly because the industry keeps confusing two very different problems that happen to share the same underlying primitive. Ad-tech uses cookies to track. Fraud teams use them to identify. Both broke a long time ago. Both were replaced by something better. And the something better has nothing to do with Privacy Sandbox, first-party consent frameworks, or anything else the last five years of headlines were about.
Let's unpack what actually happened, why it never mattered for anti-fraud, and what a modern identity layer looks like when you stop pretending cookies were ever the right tool.
What actually shipped and what didn't
A quick timeline for anyone who tuned out around 2023.
2019. Google announces Privacy Sandbox. Cookies to be deprecated in Chrome. Replacement APIs to be built.
2020–2024. Endless timeline slips. FLoC becomes Topics. FLEDGE becomes Protected Audience. Attribution Reporting, CHIPS, FedCM, Private State Tokens land in various states of completeness. The UK's CMA gets involved, then the ICO, then the EDPB. Antitrust concerns pile up. Industry adoption is thin.
July 2024. Google backs off. Instead of deprecating third-party cookies, it will let users choose.
April 2025. Google clarifies: no cookie prompt at all. The choice is buried in settings.
October 2025. Google officially retires most Privacy Sandbox APIs, citing "low levels of adoption." Protected Audience, Attribution Reporting, IP Protection, Private Aggregation — gone from the roadmap. What survives: CHIPS (partitioned cookies), FedCM (federated sign-in), and Private State Tokens.
The story you'll read in ad-tech press is that Privacy Sandbox failed. That's mostly right. The story you won't read: none of this was ever going to help you with fraud.
The category error at the core of the debate
Privacy Sandbox was designed to solve one problem: how do advertisers measure and target audiences without cross-site tracking? Every API was scoped to that problem.
- Topics API gave advertisers coarse interest signals ("cooking," "auto enthusiast") without letting them observe which specific sites a user visited.
- Protected Audience enabled retargeting through in-browser auctions where no party saw the full audience.
- Attribution Reporting let advertisers know a conversion happened, with noise added, without joining the ad impression to the user identity.
Every one of these APIs was engineered to reduce the identifiability of individual users. That is the exact opposite of what a fraud team needs.
A fraud team's job is to answer: is this the same person who tried to abuse our promo code yesterday, or a new one? Is the account being logged into right now being accessed by its legitimate owner, or someone who bought the credentials on a dark market? Are these 47 signups from the same underlying identity, all trying to farm airdrop tokens?
None of these questions can be answered with Topics buckets or noisy aggregate conversion counts. They require stable, high-confidence identification of individual devices across sessions. Privacy Sandbox was actively hostile to that. Not by accident — by design.
So when the ad-tech industry cheered "cookies are dead," and later cheered "cookies survived," the fraud team should have been shrugging in both cases. Cookies were never the load-bearing beam of a modern fraud stack. Anyone who told you otherwise was selling a 2015 product.
Why cookies were broken for fraud, long before Google noticed
If you look at a cookie the way a fraud engineer looks at it, it fails on almost every axis you'd want an identity signal to succeed on.
They can be cleared. Any user, on any device, can wipe them in two clicks. Fraudsters wipe them between every attempt.
Incognito breaks them. Every private tab is a fresh identity from the cookie's perspective. Multi-accounting via incognito is one of the oldest and cheapest fraud patterns in the book.
They don't survive browser changes. A Chrome cookie is not a Firefox cookie is not a Safari cookie. A person using two browsers looks like two people. A fraudster with an anti-detect browser looks like fifty.
They don't survive device changes. Same person, different laptop — different cookie. Any real user with a phone and a laptop already registers as two humans to a cookie-based system.
They're per-domain by design. You cannot correlate a fraudster's behavior on your marketing site with their behavior on your app. Every subdomain is a fresh start.
They're accepted or rejected by consent banners. Under GDPR, ePrivacy, CCPA, and their newer cousins, a growing share of users decline cookies at the banner. That share is not evenly distributed — cost-conscious, tech-savvy, and privacy-attentive users decline more. Some of those categories overlap with your best customers. All of them overlap with your worst fraudsters.
Even Chrome's own Incognito mode has blocked third-party cookies by default for years. Firefox has done it since 2019. Safari's Intelligent Tracking Prevention started in 2017. By any honest accounting, third-party cookies stopped being a reliable identifier for roughly a third of the browser population before Google Privacy Sandbox ever existed.
If you built a fraud system where the primary identifier is a cookie, you built a system that has been quietly failing under you for eight years. The failure mode is not visible in your metrics because the failed identifications look like new users, and new users look like growth.
The CHIPS trap
One of the surviving Privacy Sandbox pieces is CHIPS — Cookies Having Independent Partitioned State. If you skimmed the spec and thought "great, cookies are back, we can go back to normal," pause.
CHIPS lets a third-party cookie be set — but partitioned by the top-level site. In practice: your embedded widget can set a cookie on example.com, but it will be a different cookie when the same widget runs on other-site.com. There is no cross-site continuity. That's the point.
For an ad-tech vendor doing federated attribution, CHIPS is a reasonable compromise. For a fraud system that needs to know if the same device is trying to abuse promos across two of your properties, CHIPS is worse than nothing — it gives you the shape of an identifier without the substance of one.
FedCM is similarly narrow. It's a nice UX for federated sign-in, not an identity signal. And Private State Tokens are useful as a lightweight trust anchor for a limited set of anti-abuse decisions, but they explicitly cannot carry user-identifying information across sites.
Everything Google preserved from Privacy Sandbox is oriented toward reducing linkability. That's a good thing for consumer privacy. It's irrelevant to the question of whether the person applying WELCOME50 right now already applied under a different email last Tuesday.
What actually solves the fraud identity problem
You need a signal that survives cookie clearing, incognito, VPN switching, browser changes, and — ideally — device changes. That signal exists, and it has for a while. The industry name for it is device intelligence, and the technical core is device fingerprinting enhanced by behavioral and network cross-checks.
Here is what a modern anti-fraud identity layer actually looks like, stripped of marketing.
A device is identified by a composite of signals that the browser reveals to any script. Canvas rendering micro-artifacts (which vary by GPU driver combination). WebGL parameter reports. Available fonts. Audio processing characteristics (subtle differences in how the AudioContext oscillator behaves per hardware). Hardware concurrency. Screen dimensions after de-obfuscation of common spoofing tricks. Timezone consistency with declared locale. Language stack ordering. Battery status API artifacts (where still exposed). And a long tail of smaller signals.
Cross-checks reconcile inconsistencies. A device claiming to be a MacBook Pro that renders canvas like an Android tablet is not what it claims to be. A "Chrome on Windows" User-Agent connecting from a TLS fingerprint that Chrome doesn't produce is a bot with a bad disguise. A timezone reporting UTC+3 while the IP geolocates to São Paulo suggests either a traveler or a bad proxy — and the client-side clock skew will tell you which.
The signal is stabilized against noise. Browser updates change some signals. Users install fonts. GPU drivers get patched. A production-grade device intelligence system uses ML models to distinguish between "this is the same device with a Chrome update" and "this is a different device pretending to be the previous one." Simple hash-based fingerprints fail here; layered systems succeed.
Behavioral signals close the last gap. Even a perfect fingerprint can be replayed by a sophisticated bot. But replaying a fingerprint while also generating human-plausible mouse trajectories, keystroke rhythms, scroll patterns, and page dwell times — while keeping them all consistent with each other — is a materially harder problem. Not impossible, but expensive enough that the economics of most attacks fall apart.
Server-side validation prevents client-side spoof. The client sends signal data; the server independently validates it. Timing checks, replay detection, consistency verification. A fraudster who spoofs the client-side script doesn't get to spoof what your server observes about the request itself.
The output of this stack is not a cookie. It's a stable identifier — call it a visitorId — that persists across cookie clearing, private browsing, VPN switching, and browser changes. That identifier is the thing your fraud logic actually needs. That identifier is what Privacy Sandbox never promised, never delivered, and was never trying to build.
What this means for your architecture
If you're the person deciding what your fraud stack looks like in 2026, here's the practical translation.
Cookies are still fine for the things cookies were always fine for. Session management. First-party preferences. Cart persistence. Don't rip them out.
Do not build fraud logic on cookies. If your promo abuse detection reads a cookie to check "has this browser used this code before," you have a fraud logic bug. Every new incognito tab is a fresh browser to you. Every VPN switch is a fresh browser. You are counting sessions, not people.
Do not wait for Privacy Sandbox replacements. Whatever comes next in the ad-tech ecosystem — Trade Desk's UID2, LiveRamp's identity graph, whatever cohort-based scheme Google ships in 2027 — will be designed for privacy-preserving marketing. It will be the wrong tool for security, again.
Do build on device intelligence as the identity primitive. This is the layer that survives every browser change, every regulatory shift, every deprecation announcement. It is orthogonal to the ad-tech identity debate because it is orthogonal to the cross-site tracking problem that debate was about. Your first-party fingerprint of a device visiting your site does not depend on any browser vendor's permission to correlate across sites — it works within your own domain.
Design for the layered architecture. Cloudflare or Akamai at the edge for volumetric attacks. Rate limits for the crude stuff. Then a device intelligence layer inside your application: one API call on any sensitive action (signup, login, checkout, promo application, KYC step, high-value transaction) returns a stable visitorId, a bot score, a risk score, and a set of smart signals (VPN, proxy, datacenter, incognito, tampering detected). Your business logic makes decisions on that context.
Instrument the identity, not the cookie. Every fraud-relevant event in your system should be tagged with the visitorId, not the session cookie. Your queries change from "has this cookie tried this before" to "has this device tried this before." Same query shape, different noun, dramatically different accuracy.
The distraction cost
There's a hidden cost of the six-year Privacy Sandbox saga that nobody in security tallied out loud: how many engineering hours got spent on the wrong problem.
Every quarter for years, some team lead somewhere was tasked with "figuring out our cookie strategy." Consultants were hired. Vendor evaluations were run. Migration plans were drawn up. Roadmaps were written and re-written. The ad-tech industry was rearranging deck chairs; the security industry was watching, distracted, wondering if any of it applied to them.
Almost none of it did.
The teams that quietly ignored the cookie debate and instead invested in device intelligence, behavioral analytics, and cross-session identity graphs are the ones whose fraud losses shrank while everyone else's grew. Not because they picked the right consultant, but because they picked the right layer of the stack to invest in.
A closing observation
Google killed Privacy Sandbox in October 2025 because it wasn't working. The APIs had low adoption because ad-tech isn't a technology problem, it's a business problem — and the business problem (attribution, targeting, consent, competition) doesn't get solved by shipping new APIs.
Anti-fraud is a technology problem, and the technology to solve it exists, is deployed, is boring, and has been quietly working for years while the rest of the industry argued about something else.
If you take one thing away: the health of your fraud metrics has nothing to do with what happens to third-party cookies in Chrome. It has everything to do with whether your identity layer is a session identifier or a device identifier. Those are not the same thing. They have never been the same thing. The last six years of headlines never changed that.
Build accordingly.
Tracio is a device intelligence platform. We identify visitors with 99.5% accuracy across 130+ signals, in under 50ms, in one API call — regardless of cookies, incognito, or VPN state. Try it: 14-day trial, no card, three lines of code.
Top comments (0)