Apple Has a Private Blocklist for Ad Tech (and Your Data Vendors Are Next)
Apple is preparing to block hundreds of programmatic data companies, including CDPs, DMPs, data sellers and ID graph operators, from Safari and other browsers on iOS 27, AdExchanger reported on October 2, 2026. LiveRamp, ID5, UID2, Permutive and Audigent are already blocked. Because the list updates remotely, without an iOS release, any data segment in your buy could stop matching on iPhone without warning.
Last week this looked like a Trade Desk problem. When we covered Apple's iOS 27 cutting The Trade Desk off Safari, the working theory was collateral damage: Apple aimed at identity vendors and happened to hit a DSP's ad-serving pipe along the way. I even guessed Apple might carve adsrvr.org back out within 60 days.
I'm a lot less sure about that now. A list of hundreds doesn't read like an accident. It reads like a policy.
What actually changed between Tuesday and Friday
The first story was about nine domains. Ian Meyers, a senior engineering director at The Trade Desk, filed a WebKit bug on September 21 and published the entries he could see, according to PPC Land's breakdown of the WebKit commit: uidapi.com (UID2), adsrvr.org (The Trade Desk), two ID5 sync domains, rlcdn.com and pippio.com (both LiveRamp), permutive.com, and ad.gt (Audigent). The code itself was an 11-line change merged back in February. The public version of WebKit blocks nothing. The real list lives in a private file that only ships in Apple's own builds.
The new AdExchanger report, citing two sources with direct knowledge of the WebKit updates, says the nine were basically the pilot. The broader list sits in a private GitHub repo and covers "hundreds of CDPs, ad tech and martech companies, data sellers and ID graph operators." Some are on what the piece describes as a probationary list. AdExchanger was still checking whether Google properties like ad.doubleclick.net are on it.
The part that matters most for buyers is the mechanism. The list is pulled dynamically, so Apple can add or remove a vendor on the fly. No OS update, no release notes, no beta for anyone to diff.
Your data stack now has a kill switch, and you don't hold it.
Why this shows up as a CPM problem, not an error
Nobody's dashboard turns red when a data vendor gets blocked. The pixel call just doesn't happen. The ID sync fails quietly. The segment you bought still exists in the DSP, it just matches fewer iPhone users every week.
What you end up with is a segment that looks the same in the UI, costs the same data fee, and delivers to a shrinking slice of the audience you think you're reaching. Delivery then leans harder on Android and desktop to hit pacing, and the CPMs drift up. In most cases I'd expect teams to blame seasonality first, honestly, because Q4 always gives you an excuse for rising CPMs.
And to be fair, none of this is brand new. Apple has been tightening Safari for years. PPC Land documented in July that the Safari 27 beta was already blocking Bing's UET endpoint at the IP-address level and treating the LinkedIn Insight Tag as a fingerprinting script. Stape's write-up of the same beta adds Tealium and Segment to the list of tools Advanced Fingerprinting Protection now restricts. What's different now is scope. It went from "Apple hardens the browser" to "Apple decides which companies get to exist on the browser."
The vendor audit I'd run before the next IO
This is maybe 30 minutes of work if your ops person has access to the DSP and the data marketplace invoices. Personally, I wouldn't wait for the full list to leak.
- List every third-party data provider in active line items. Not the ones in the contract, the ones actually attached to spend right now. Include contextual and identity partners, not just audience segments.
- Flag anything that touches the confirmed nine domains. Any LiveRamp RampID, UID2, ID5, Permutive or Audigent segment is already blocked on iOS 27 Safari. That part isn't speculation.
- Split delivery by OS and browser for September 1 to 13 versus September 14 onward. iOS 27 started rolling out on September 14. If iOS Safari share of impressions on a data-targeted line dropped by more than about 20% relative to an untargeted control line, the segment is probably already leaking.
- Ask every data vendor one question in writing: "Are any of your domains on Apple's WebKit block or probationary list, and what's your fallback?" A vendor who can't answer that clearly is telling you something.
- Stop paying full data CPMs on iOS-heavy campaigns until you have the answer. If a segment can't match on a big share of mobile web traffic, the data fee should reflect that.
One benchmark worth keeping in your head: if a segment's iOS match rate falls but the vendor's invoice doesn't, you're paying for reach you aren't getting. That's the whole audit, really.
Does server-side tagging get you out of this?
Partly. Maybe. It depends which problem you're solving.
For your own measurement, moving tags server-side seems to help, because the browser talks to your server instead of the blocked endpoint. PPC Land's July piece makes exactly that point about the IP-level blocks. Stape is a little more careful and says server-side setups "reduce the impact" rather than eliminate it, and that everything should be retested on the stable release. I'd take the careful version.
For third-party audience data, though, server-side doesn't help much at all. The whole value of an ID graph is that it recognizes a person across sites it doesn't own. If Apple won't let that vendor's code run in the browser, a cleaner tag on your site doesn't bring the graph back. The thing that survives this is first-party data you collected with consent, matched through a clean room or a platform's own login graph. Which, yes, mostly means the walled gardens get stronger. That part bugs me a bit, but it's where the incentives point.
How fast this hits your actual reach
The block only applies to devices on iOS 27, so right now it's a slice, not the whole iPhone base. That slice grows quickly. Apple's own numbers had iOS 26 on 79% of iPhones by June 2026, roughly nine months after launch. If iOS 27 follows a similar curve, I'd guess more than half of active iPhones are on it by early February, which is right when most Q1 plans are locked and running.
My prediction: by the end of Q1 2027, at least one of the big holding companies will publicly add an "Apple blocklist exposure" clause to data vendor contracts, with a fee reduction or exit right tied to iOS match rates. The bargaining position is too obvious for procurement to ignore once the first quarterly reconciliation shows the gap.
The analogy I keep coming back to: it's a bit like buying ad space in a mall where the landlord can lock any store's door overnight, doesn't post the list, and doesn't refund your rent. You'd still advertise there. You just wouldn't sign a 12-month lease without an exit clause.
The vendors Apple hasn't named yet
The nine domains are the easy part because they're public. The hard part is the "hundreds" nobody outside Apple can see. I don't think the right response is to panic-cut every third-party segment, since a lot of them still work fine on Chrome and in-app. It's more about knowing which line items would break if Apple flipped a switch tomorrow, and pricing that risk into what you pay. Most teams I'd bet haven't done that math yet, and the first ones to do it will probably just end up with cheaper data contracts, not a dramatic strategy pivot.
