For five years, the whole ad-tech industry braced for a funeral that never happened.
Google announced in 2020 that Chrome would phase out third-party cookies. Then it slipped the date. Then it slipped it again. In July 2024 it pivoted to a “user choice” prompt — you’d get to decide — and in April 2025 it dropped even that. Chrome would keep third-party cookies on by default, no prompt, no deprecation. By October 2025 Google had shut down the entire Privacy Sandbox effort: Topics, Protected Audience, Attribution Reporting, all retired after six years and, by Google’s own admission, not enough adoption to justify keeping them alive.
So the cookie lived. You’d think that would be the story. It isn’t.
The interesting thing already happened, years before Google threw in the towel, and it happened one layer down from where everyone was looking. While the industry argued about a cookie deprecation that kept not arriving, trackers quietly stopped depending on third-party cookies at all. They moved the whole operation into DNS.
The trick is a CNAME
Here’s the mechanism, and it’s almost insultingly simple.
A tracking vendor tells you to create a subdomain — say metrics.yourdomain.com — and point it, with a CNAME record, at something like c.tracker-vendor.net. That’s it. That’s the whole exploit. You’ve delegated a name in your own zone to a machine you don’t own.
Now watch what the browser sees. A script on your page loads a resource from metrics.yourdomain.com. To the browser, that hostname is a subdomain of the site you’re actually visiting. It’s same-site. First-party. The browser’s third-party cookie machinery — the thing Google spent five years threatening to tighten — never engages, because as far as it can tell, nothing third-party is happening. The request goes to your own domain.
Except it doesn’t. DNS resolves that CNAME and the connection terminates on the tracker’s infrastructure. The tracker sets a cookie. Because the response came from metrics.yourdomain.com, that cookie is a first-party cookie on your domain. It doesn’t get blocked, it doesn’t get capped, it doesn’t get partitioned. It’s laundered. A third party is now reading and writing first-party cookies on your site, and the only thing that made it possible was a single DNS record you added yourself.
This is CNAME cloaking, and it’s not a theoretical attack. Researchers measured it. “The CNAME of the Game,” published in Proceedings on Privacy Enhancing Technologies in 2021, found this pattern on roughly one in ten of the top 10,000 websites, concentrated among the highest-traffic sites, and rising. It had been in production for years by then. The paper’s authors were studying it in 2020 — the same year Google announced the cookie deprecation that was supposed to make tracking harder.
What actually leaks
The part that should bother you isn’t the tracking. It’s the collateral.
When a subdomain resolves to first-party in the browser, it doesn’t just get its own cookies. It gets your cookies. The browser attaches every cookie scoped to your domain to that request — because the request is going to your domain, as far as it knows. If you set cookies at the apex (.yourdomain.com) rather than pinning them to a specific host, those cookies ride along to metrics.yourdomain.com, which means they ride along to the tracker.
Read that again. Your session cookie. Your CSRF token, if it’s stored in a cookie. Your auth state. All of it gets shipped, automatically, to a server operated by a company whose entire business is collecting data, because DNS made their server look like yours. The measurement study found exactly this: real deployments leaking cookies that had nothing to do with analytics — session identifiers, sensitive tokens — to CNAME trackers, purely as a side effect of the same-site illusion. Nobody designed that leak on purpose. It falls out of the architecture for free.
And it’s not only cookies. Any request to the cloaked subdomain carries the same-site Referer, the full Cookie header, whatever the browser thinks it owes to a first party. You built a hole in your own perimeter and pointed it at an ad network, and it renders on the page as a friendly little metrics. subdomain that looks like something you run.
The browsers that tried to stop it
Not everyone missed this. Safari did the most direct thing.
WebKit shipped a defense in Safari 14 back in November 2020: when Intelligent Tracking Prevention detects that a first-party subresource resolves through a CNAME to a different host than the site itself, it caps any cookie set in that response to seven days. The reasoning is blunt — if you’re going to disguise a third party as first-party through DNS, ITP will treat the cookies you set with the suspicion a third party deserves. Seven days, then gone. That single change quietly broke a lot of “durable” first-party analytics that were really third-party analytics wearing a subdomain.
Firefox took a different route: it doesn’t ban the technique outright, but it’s the only browser that lets an extension like uBlock Origin do a real DNS lookup on a resource’s hostname and unmask the CNAME chain, then block the request if the target is a known tracker. That’s the crucial capability — you can’t detect cloaking from the hostname alone, because the hostname is, by design, your own. You have to resolve the DNS to see where it actually goes. Chrome extensions can’t do that lookup. Firefox extensions can.
Which leaves Chrome — the browser that just decided not to touch third-party cookies at all — as the one with the weakest answer to the technique that made third-party cookies optional in the first place. That’s the irony worth sitting with. The deprecation everyone feared was aimed at a mechanism the trackers had already routed around.
Why this is a DNS problem, not a cookie problem
The reflex, for a decade, has been to think of tracking as a cookie problem. Block the cookie, stop the tracking. That framing is why Google’s cookie deprecation got five years of headlines and CNAME cloaking got a handful of academic papers.
But the cookie was never the hard part. The cookie is just storage. The hard part is identity — establishing that the browser talking to the tracker is the same browser that visited a thousand other sites. Third-party cookies were one way to carry that identity across the boundary. CNAME cloaking is another, and it works by attacking a different assumption entirely: that a subdomain of your site belongs to your site. In DNS, that assumption is a choice, and it’s a choice you can quietly hand to someone else with one record.
The uncomfortable conclusion is that you cannot audit this from the outside by looking at cookies or scripts. A cloaked tracker looks like first-party infrastructure in every surface a normal person inspects. The only place the truth is visible is the DNS — the CNAME chain, the delegation, the host the name actually points at. If you want to know whether a subdomain on your domain is really yours, you have to follow the record all the way down and see where it lands. Everything above that layer is designed to lie to you.
Google gave up on killing the third-party cookie. It turned out not to matter much, because the thing that mattered had already crawled below the cookie, into the one layer nobody was watching. If you run a domain, go read your own CNAME records. You might be surprised who you’ve been vouching for.