Let’s not pretend this is complicated.

ID5 sells one thing: knowing it’s you when the cookie can’t. That is the entire business. The browser forgets you, ID5 remembers. Publishers pour signals in, ID5 pours a persistent identifier out, and the open web gets to keep telling advertisers that addressability survived the death of the third-party cookie. It’s a lovely story. It sold a lot of decks.

Apple just tore the last page out.

ID5’s domains sit on a private Safari blocklist that kills requests before they ever leave the phone. No auction, no ID, no match. And ADOTAT has learned that ID5 is not coming off that list. Not in the next beta. Not after a polite bug report. Not after a very sincere engineering memo.

Meanwhile, The Trade Desk landed on the same list, filed a ticket, sent some documentation, and was unblocked in a test build 13 days after Apple’s first reply. Apple’s published policy says, in plain English, that it grants no exceptions to specific parties. So one company got a fix and another company got a wall, and Apple has explained neither in public.

Welcome to the new Safari. The rules are real, the enforcement is real, and the rulebook is locked in a drawer in Cupertino.

Here’s what’s actually going on, why ID5 is the one in real trouble, and why every identity vendor still reachable in Safari should stop gloating and start reading.

Apple has never said why ID5 is on the list. It doesn’t need to. ID5’s own documentation reads like the charge sheet.

ID5 says: “Signals passed in the ID5 ID request are used to inform ID5 ID connections across domains.”

It says: “‘Hard signals’, such as hashed email addresses, take priority for cross-domain linking purposes, and help to train ID5’s probabilistic algorithm.”

And it instructs partners: “Ensure IP address and user agent are always included in the PD string.”

Put those three lines side by side. Cross-domain linking. A probabilistic model trained on hashed emails. IP address and user agent as standing inputs, always.

Now read what Apple says it exists to stop. Its tracking prevention policy targets cross-site tracking, recognizing the same person across unrelated websites, and it names fingerprinting as a method. Apple’s own technical writing breaks fingerprinting down into device characteristics, network characteristics like IP address, user settings, behavioral patterns and accumulated traits.

IP address. Browser details. Cross-domain linking. You don’t need a decoder ring. ID5’s product and Apple’s prohibited behavior overlap almost perfectly on paper.

To be fair, and we will be, sending IP address and user agent does not by itself make every ID5 implementation fingerprinting. Plenty of ordinary web traffic carries both. The question is what happens next, and ID5’s own words describe what happens next: connections across domains.

ID5’s answer to all this is consent. It describes its technology as connecting consented signals into persistent identifiers. That’s a real legal posture, and nothing here says ID5’s consent framework is invalid or unlawful.

But Apple closed that door years ago. In its documentation for required-reason APIs, Apple wrote: “Regardless of whether a user gives your app permission to track, fingerprinting is not allowed.”

That’s an app rule, not a Safari rule, and it would be sloppy to call it the legal basis for this block. But it tells you exactly how Apple thinks. In Cupertino, a consent string is not a permission slip. You can be compliant with GDPR and still be the thing Apple’s browser is built to stop.

Here is the part that should keep ID5’s board up at night.

The Trade Desk got out because it could argue its blocked domain was plumbing.

adsrvr.org is where The Trade Desk serves ads. TTD’s engineers made a narrow, technical case: an ad-delivery endpoint is not an identity endpoint, and blocking it breaks ordinary advertising, which Apple’s own policy says it doesn’t intend to break. They sent documentation. Apple investigated. A beta shipped.

ID5 has no such argument available.

Its endpoint is not plumbing sitting next to an identity business. The endpoint is the identity business. There’s no ad-delivery function to carve out, no innocent pipe to separate from the guilty one. When the product is cross-domain recognition, asking Apple to narrow the rule to “just the tracking part” means asking Apple to unblock the whole company.

That is the difference between a misclassified domain and a classified company.

One gets a beta build and a thank-you note. The other gets a wall.

And that’s why this is a business story, not a browser story. A universal ID that doesn’t resolve in Safari is a universal ID with an asterisk the size of the iPhone. Every sales call now starts with a footnote. Every publisher integration now comes with a question about which browsers actually return an ID. Every buyer who paid for addressable reach is entitled to ask what fraction of it was ever addressable.

The Trade Desk’s escape is unusually well documented, because it happened in public.

WebKit bug 324771 carries a title that reads like a confession from a config file: “Inclusion of adsrvr.org in IS_REQUEST_UNCONDITIONALLY_BLOCKABLE domain list.”

Note the phrase. Unconditionally blockable. Not “blocked if it fingerprints.” Not “blocked when suspicious.” Unconditionally.

Apple’s John Wilander, on September 22: “Thanks for filing, Ian! I also got your email. We’re investigating.”

On September 28: “I will let you know if and when any changes are available for you to test.”

On October 5: “A new iOS 27.2 beta went out today. Please test with it. And thank you for the technical documentation you provided.”

The Trade Desk’s Ian Meyers, the same day: “Thanks, John! Acknowledged I see the changes in the 24B5099f build. We will test and report back if there are any issues.”

That’s it. That’s the whole public record of Apple responding to anyone about this list. Polite, quick, and completely silent on the one question that matters: why was the domain there in the first place?

One more thing about that thread, because the trade press is already getting it wrong. The description of the list as a hard block on domains that power “post-cookie” identity came from Meyers’s complaint, not from Apple. Apple didn’t say that. Apple didn’t say anything about intent. Wilander talked about remediation and nothing else.

Precision matters here, because this is exactly the kind of story where the industry will round up.

“Apple has long opposed fingerprinting” is true and documented, in the WebKit policy since 2019, in a July 2023 developer announcement, and in Apple’s Safari privacy writeups.

“Apple accused ID5 of fingerprinting” is not. No public Apple statement naming ID5 has been found. Not in the WebKit policy. Not in the 2023 developer announcement. Not in the Private Browsing 2.0 explanation. Not in the bug tracker.

So here is the accurate version of where ID5 stands: its own documentation describes behavior that closely matches what Apple prohibits, Apple has put it on a blocklist, Apple is keeping it there, and Apple has not said what conduct put it there.

Other names reported as affected include LiveRamp and Experian’s Audigent. The Trade Desk was on it until the beta. Who else is on it, nobody outside Apple can tell you.