Apple's Safari Blocklist Dominates Advertising Week as Industry Scrambles to Limit Measurement Damage
Apple's iOS 27 ad tech blocklist was the defining topic at Advertising Week New York, with executives discussing its implications mostly off the record. AdExchanger reports Apple plans to expand the list to hundreds of vendors, while IAB Tech Lab pushes its Trusted Server framework as the leading countermeasure — and early data shows the revenue hit is just beginning.
Apple's iOS 27 blocklist was supposed to be a Safari story. A month later, it is an industry story. At Advertising Week New York, which wrapped October 10, the blocklist dominated hallway conversations, panel asides, and private dinners — mostly off the record. Executives from identity vendors, DSPs, and measurement companies talked about what Apple had done, what it might do next, and what it means for their businesses. Few were willing to attach their names to the discussion.
The anxiety is understandable. What started as a handful of blocked domains in September has become something larger. AdExchanger reported that according to two sources with direct knowledge of WebKit updates, Apple has scrapped the initial short list in favor of an expansive library containing hundreds of CDPs, ad tech and mar tech companies, data sellers, and identity graph operators. The full list sits in a private GitHub repository. One person with access let AdExchanger read some names but would not share the document.
Two days after Advertising Week ended, addressability surged back to the top of the agenda at the Prebid Summit on October 13. Attendees described iOS 27 as a reset — the kind of platform move that forces every vendor to re-evaluate what data they can collect, where they can collect it, and how they prove advertising works.
The Blocklist Grows
The initial iOS 27 blocks, which went live with the September 14 release, hit The Trade Desk's ad-serving domain, LiveRamp, ID5, Permutive, and Experian's Audigent. UID 2.0's domain was also cut off. But the scope was narrow enough that some vendors treated it as a targeting error rather than a policy shift.
That interpretation is getting harder to sustain. AdExchanger's reporting on the expanded blocklist suggests Apple is building a comprehensive catalog of programmatic data infrastructure it considers incompatible with its privacy model. The company can update the list through a remote endpoint that Apple devices call at regular intervals, meaning new additions no longer require an iOS software update. Apple has not publicly explained the selection criteria, the review process, or whether vendors have any mechanism to appeal.
Not everyone is blocked. Digiday's Ad Tech Briefing noted that Zeta's LiveIntent, Publicis Groupe-owned Lotame, and Yahoo's ConnectID all passed through without issue. The inconsistency has left vendors guessing at what distinguishes a blocked domain from an unblocked one — and whether today's safe list is tomorrow's blocklist.
A Partial Fix for The Trade Desk
There is one piece of good news, though it comes with caveats. Apple has asked The Trade Desk to test an iOS 27.2 build that removes adsrvr.org from the blocklist. If the fix ships, The Trade Desk's ad delivery would resume on Safari for users who update to the new version.
But the timeline is slow. iOS 27.2 is still in beta, and users on the current production version will not see the fix until late October at the earliest. That means The Trade Desk has been locked out of Safari inventory for more than a month during the crucial fourth-quarter advertising season. And even if the ad-serving domain is unblocked, the broader identity infrastructure that supports targeting and measurement on Safari — UID 2.0, LiveRamp, ID5 — remains on the list.
The partial reprieve also raises a question the industry is not asking loudly enough: if Apple can remove a domain from its blocklist this easily, it can add one back just as easily. The mechanism itself — a remotely updated blocklist that operates at the network transport layer — is the strategic threat, regardless of which specific domains it contains on any given day.
The Measurement Damage So Far
Early data suggests the revenue impact is still modest but growing. Digiday reported that ad tech firm Aditude estimates the overall revenue hit at approximately 1% so far, since only about 8% of users have upgraded to iOS 27. That number will climb as adoption increases through the fall — Apple's iOS adoption curves typically reach 50% within 60 days and 70% within 90 days of release.
For measurement teams, the direct revenue hit understates the problem. Several measurement vendors at Advertising Week pointed out that the industry's focus on The Trade Desk has obscured the broader attribution implications. When Safari blocks identity providers at the network layer, it does not just prevent targeting — it breaks the identity graph that connects an ad impression to a conversion event. The same user who sees an ad on a desktop Chrome session and converts on their iPhone becomes two unrelated data points. Attribution models that relied on cross-device identity resolution through LiveRamp, ID5, or UID 2.0 lose the thread entirely on Safari.
AdExchanger detailed how vendors are preparing for the fallout. Identity vendors like ID5 have been testing workarounds, including moving pixels server-side and reducing cookie dependence. But these are tactical patches, not structural solutions — and they are being developed against a moving target, since Apple can expand the blocklist at any time.
The Trusted Server Bet
The most substantive industry response so far comes from the IAB Tech Lab. Its Trusted Server framework, an open-source system that runs ad processing on servers the publisher controls rather than in the reader's browser, has emerged as the leading countermeasure. Digiday reported that publishers are testing Trusted Server as a way to keep ad calls functional on Safari without triggering the blocklist.
The logic is straightforward: if the browser only communicates with the publisher's own domain, there are no third-party connections for Safari to block. Ad decisioning, identity resolution, and measurement happen server-side, in an environment the publisher controls. Apple's remaining option would be to block the publisher's own domain — a step that would break the website itself.
IAB Tech Lab CEO Anthony Katsur has called Trusted Server "production ready," and the organization says it is preparing to go live with its first publisher. But the framework has no published releases on GitHub, and publishers have been slow to test it. Server-side ad processing requires infrastructure investment, engineering resources, and a willingness to take on complexity that browser-based ad tags were designed to avoid. For large publishers with engineering teams, Trusted Server is a viable path. For the long tail — the thousands of smaller publishers who depend on third-party ad tags because they lack server infrastructure — it is not an option today.
The Prebid Dimension
The Prebid Summit on October 13 added another layer to the story. Addressability — the ability to recognize and target users across the open web — is back as a headline concern, driven in large part by iOS 27. But the Summit also surfaced a related development: Prebid is proposing an architecture where ad servers bid into Prebid rather than Prebid bidding into ad servers, part of the response to the court-ordered Google ad tech remedies.
The connection to Apple's blocklist is indirect but important. If Prebid's server-side auction model gains traction — driven by the Google remedies — it creates a natural architecture for the kind of server-side ad processing that IAB Tech Lab's Trusted Server envisions. Publishers already running Prebid Server would have infrastructure they could extend for server-side identity resolution and measurement, reducing their dependence on browser-based ad tags that Safari can block.
The timeline is long. Google has 12 to 15 months to implement the court-ordered integrations with Prebid. But the architectural direction aligns with what Apple's blocklist is forcing: a migration of ad tech infrastructure from the browser to the server.
What Comes Next
The industry is in a familiar position: reacting to an Apple platform move that was not negotiated, not previewed, and not designed with ad tech input. The playbook from App Tracking Transparency — scramble, adapt, build alternatives, accept reduced signal — is repeating.
But iOS 27 is different from ATT in one critical respect. ATT created a consent layer that users could choose to accept or decline. The Safari blocklist creates no choice. There is no prompt, no opt-in, no way for a user who wants targeted advertising to allow it through Safari. The identity infrastructure is simply gone, regardless of user preference.
For measurement teams, the strategic calculus has shifted. The question is no longer whether browser-based measurement on Safari is reliable — it is not. The question is how quickly you can build a measurement stack that does not depend on it. Server-side tracking, media mix modeling, incrementality testing, and clean room-based analysis are the methods that work regardless of what Apple's blocklist contains. Every quarter spent optimizing a browser-based attribution model for Safari is a quarter spent on infrastructure with a shrinking addressable surface.
The blocklist will grow. The adoption curve will steepen. Q4 will be the first real stress test. Plan accordingly.
Sources & References
- [1]
- [2]
- [3]
- [4]
- [5]