On September 14, Apple shipped iOS 27. Within days, The Trade Desk, LiveRamp, ID5, Permutive, and Audigent discovered they had been quietly blocked from collecting data or serving ads on Safari. On October 2, AdExchanger reported that the original list of five is now irrelevant. Apple replaced it with a dynamic blocklist of hundreds of CDPs, DMPs, DSPs, ID graph operators, and data sellers. The full list lives in a private GitHub repo that Apple controls. Vendors do not know they are on it, do not know when they get added, and do not know the criteria for being removed. Your programmatic stack is being scored by a system that was built to never explain itself.

The dynamic part is the part that breaks your planning

The earlier rounds of Apple privacy moves -- Intelligent Tracking Prevention in 2017, App Tracking Transparency in 2021 -- were static. They shipped in iOS releases, were documented in WebKit blog posts, and gave the ad tech ecosystem a fixed target to engineer around. The iOS 27 blocklist is not that. It is a remote list that Apple devices call on every session, populated from a private GitHub repo, and updated without a software release. A vendor that is fine today can be blocked tomorrow. A vendor that is blocked today can be unblocked next week. Nobody outside Apple knows the rules.

The technical surface, pulled from a public WebKit commit by AdExchanger, includes calls like isRequestToKnownCrossSiteTracker, !supportsFingerprintingScriptRequests, and !supportsTrackingPreventionContentRuleListRequests. Translation: Apple is fingerprinting the fingerprinters. If your tag management, identity resolution, or attribution pixel does anything that looks like cross-site tracking, fingerprinting, or content rule list evasion, the request is dropped before it reaches your server. The Trade Desk and Unified ID 2.0 were the first names, but the categories Apple is signaling are not five vendors. They are the entire ad tech, martech, and data vendor taxonomy.

What 'potentially blocked' actually means for your campaigns

AdExchanger's reporting describes a purgatorial state of 'potentially blocked' for vendors on the new list. That is not a binary. It is a third classification, somewhere between approved and blocked, where Apple reserves the right to add or remove vendors on the fly. The practical consequence is that a CDP or ID graph that worked in your last campaign may not work in the next one -- and you will not know which campaign was the one that stopped working. There is no notification. There is no appeal form. There is no public criteria document. The blocklist is the criteria.

For media buyers this is the worst possible failure mode. When an ad is not served, the auction either returns no bid or returns a bid at a 100 percent discount. Your reporting shows a delivered impression. Your pacing looks normal. Your attribution model credits Safari traffic to the channel. The actual human saw nothing. The actual click never happened. You have no signal in your stack that Apple silently downgraded the inventory you are buying, because the inventory was never delivered in the first place. This is the kind of measurement failure you do not catch until someone runs an incrementality test six months later and the Safari cohort looks like the control group.

What to do this quarter before the next iOS point release

First, audit your tag inventory on Safari. If you run any client-side pixel, identity resolution script, or third-party data collector that calls cross-site endpoints, you are a candidate for the next Apple update. The vendors you depend on may not know they are on the list either -- the original five reportedly did not get a heads up -- so the burden of detection falls on you. Run your own Safari cohort through a tagged control group and compare the reach numbers to last quarter. If Safari reach dropped more than 5 percent without a campaign or budget change, you are already inside the blocklist and your vendor does not know it yet.

Second, separate your identity resolution strategy from a single vendor. The Trade Desk, LiveRamp, ID5, and the rest of the ID graph ecosystem are now operating under a target Apple can move at any time. If your audience targeting depends on one of them, you have a single point of failure that you do not control. The organizations that survive this round are the ones that already had first-party data strategies in motion -- authenticated customer IDs, opt-in email match, and publisher-direct deals that do not require third-party identity at the open web layer. The organizations that did not start that work in 2024 are about to start it in a hurry.

Third, ask your ad tech vendors the question they cannot answer yet. What is your remediation plan with Apple if your blocklist status changes? Do you have any signal from Apple about why your category is on the list? Have you shipped a Safari-compatible path that does not rely on the endpoint Apple is now filtering? Most vendors will not have a good answer. The ones that do are the ones you keep on the plan. The ones that do not are the ones you write down as a 2026 Q4 risk on the media budget.

Apple did not announce a privacy policy change. It shipped a mechanism. The policy lives in the private GitHub repo, the mechanism lives in the device, and the consequences live in your Safari reach numbers. The publishers, the DSPs, the SSPs, the CDPs, and the brands that built their open web media plans on a system Apple can now edit on a Tuesday are going to find out the new rules by losing money first and getting answers second. The trade desks that survive the next 12 months will be the ones that figure out how to operate inside a system that was designed to be opaque to them.

Sources