Apple Permanently Blocks ID5 in Safari, Refuses Removal

Full analysis

Apple killed ID5 on Safari. Not throttled, not rate-limited. Killed. Apple put ID5 on a private Safari blocklist that stops the requests before they ever leave your phone, and according to ADOTAT, there's no fix coming and no removal planned. ID5 sells one thing: cross-site user recognition, the ability to know that the person on site A is the same person on site B after third-party cookies went away. The endpoint Apple blocked is that product. There's nothing else to carve out.

What's actually being decided here isn't Apple's call. That's done. The decision facing every operator is whether to keep treating "universal ID" as universal when the browser that dominates US mobile browsing just proved it isn't. This is hard to undo in the sense that Apple won't reverse it. It's easy to undo in the sense that any ad-tech team can re-audit its match tables this week. The deadline is set by iOS 27 and your next round of RFPs, where somebody is going to ask what "universal coverage" actually means on Safari.

The Skeptic. The "effectively fatal" line assumes Safari is the whole game. It isn't. ID5 runs fine on Chrome and Firefox, where most European publisher traffic lives, and CTV never touches WebKit, Apple's browser engine, at all. Nobody outside ID5 knows how much of its revenue sits in Safari inventory. And ID5 has known about this block longer than ADOTAT has. If enterprise contracts were collapsing, the noise would be louder than one newsletter. In plain terms: Apple broke one vendor on one browser, and the industry is treating it like the death of identity itself. The real question is whether Apple points this same private blocklist at UID2 or RampID next. No evidence of that yet.

The Strategist. This accelerates the split that was already coming. Addressable advertising divides into two worlds. In logged-in environments where somebody actually signed in (retail media, connected TV, publisher registration), cross-site recognition still works. On the open web on Apple hardware, you target the page, and that is now the ceiling. Any independent ID vendor whose whole loop depends on the browser linking one domain to another is building on sand. LiveRamp's RampID and The Trade Desk's UID2 get a relative lift, not because Apple can't come for them too, but because they can at least argue their data comes from consent and first-party relationships. Clean-room infrastructure (InfoSum, Snowflake, Habu) widens its moat, because matching data offline never touches a browser Apple controls.

The Operator. Audit your match-rate tables now. Here's what breaks first: frequency caps on Safari collapse, so you over-serve the same user. Sequential storytelling dies. And any attribution model that counts an ID5-resolved Safari impression as "addressable" will overcount your reach and undercount your waste, which means you're reporting campaign performance that isn't real. Trafficking teams should flag Safari line items this week. Publisher yield teams will watch Safari CPMs compress as that inventory reprices from "addressable" to contextual. The 90-day effect: any RFP that cites "universal ID coverage" gets a materiality challenge from the buyers who did their homework.

The CFO. The cost here lands on everyone who oversold Safari addressability, not just on ID5. If your reach forecast assumed Safari users were recognizable and they aren't, your effective CPM was wrong and your true cost per real reached person is higher than the deck said. For publishers, Safari inventory just got cheaper to sell because it reverts to contextual pricing. For DSPs and SSPs that leaned on ID5 as a primary or fallback signal, the pitch that justified premium pricing on open-web Safari inventory needs rewriting. Nobody loses a line item. Everybody who oversold Safari addressability loses a little credibility, and some of them loses renewal leverage.

The tensions

Three real disagreements, and the decision lives inside them.

First, the Skeptic versus the Strategist on scope. Is this one mid-sized vendor's Safari headache, or the starting gun on a permanent split in how identity works? The Skeptic is right that we can't size ID5's Safari exposure from outside. The Strategist is right that the mechanism Apple used, a private blocklist that stops a request on-device with no appeal, is reusable against anyone.

Second, who actually benefits. The Strategist says UID2 and RampID get a relative lift. The Skeptic would note that their "consent and first-party" argument is exactly the argument ID5 made, and Apple's documented position is that consent does not override its fingerprinting ban. So the daylight between "defensible" and "next on the list" is thinner than the walled-gardens-win story wants it to be.

Third, the Operator versus everyone's instinct to wait. Re-architecting a stack feels expensive, so teams keep running ID5 in Safari segments. The cost of waiting is reporting reach that isn't there.

What this hinges on

Two things. One, whether Apple's private blocklist is a one-off aimed at a vendor whose technical documentation openly describes mandatory IP and user-agent inclusion (which reads like the fingerprinting Apple's WebKit policy bans), or a method Apple now applies routinely. Two, whether the "we're consent-based" defense means anything to Apple. ID5 made that argument. It didn't help.

The council leans toward the Strategist's structural read on the mechanism and the Skeptic's caution on the scope. Apple built a tool that kills an identity product silently, with no public statement and no appeal. That tool doesn't un-build. What's unproven is the appetite to point it at the bigger targets.

Before anyone rewrites strategy: verify your own Safari-resolved match rates against Apple's stated WebKit rules, and assume any identifier that depends on cross-domain browser resolution could be next.

Prediction: No major independent cross-site identity vendor (The Trade Desk's UID2, LiveRamp's RampID) will achieve or publish a verified Safari match rate above single digits by the iOS 27 adoption cycle reviewed at AdExchanger's Programmatic I/O in fall 2027.

Confidence: Medium. Apple's method is reusable and its consent stance is documented, but timing on further blocks is Apple's to set.

Why: Apple blocked ID5 with a private on-device blocklist and explicitly holds that consent does not override its fingerprinting ban, which removes the one defense every independent ID vendor was planning to use on Safari. UID2 and RampID rely on the same browser to link a user across domains, so the technical path Apple just closed is the path they also need. The opposite outcome, a healthy independent Safari match rate, requires Apple to tolerate exactly the cross-domain recognition it just killed, which it has no incentive to do while it sells its own privacy story and its own ad network. The open-web Safari surface becomes contextual, and the money that assumed addressability there reprices.

Revisit by 2027-10-15: We're right if no independent universal-ID vendor can show a verified double-digit Safari match rate at the fall 2027 iOS 27 review. We're wrong if any of them publishes or demonstrates a Safari match rate in double digits that survives Apple's WebKit policy.

Apple didn't name ID5, didn't explain itself, and won't. That silence is the product. It lets Apple apply the same block to the next vendor without ever telling the market which recognition method it considers fingerprinting and which it tolerates. Build your addressability plan assuming the open web on Apple hardware is contextual, and treat every "universal" claim as "universal except where most US mobile browsing happens."