Since iOS 27 started rolling out on 14 September, Safari has refused to connect to the domains behind UID2, ID5, LiveRamp, Permutive and Audigent. On 19 October Apple explained why in a WebKit blog post and confirmed the block also covers Safari on macOS, iPadOS and visionOS 27. The Trade Desk was caught in it too, although the fix for that part is now sitting in a release candidate.
Here’s what has been blocked, what each side has said, which IDs this touches in a typical Prebid setup and what we’d check this week.
WHAT APPLE HAS BLOCKED, AND HOW
This isn’t a cookie setting and it has nothing to do with consent. Apple has added a list of domains to WebKit (the engine under Safari) and requests to anything on that list are refused at the network level. The check runs on the registrable domain, so every subdomain is caught and a vendor can’t get round it by restructuring the request.
Apple hasn’t published the list. What’s known comes from a WebKit bug report filed on 21 September by The Trade Desk, which PPC Land picked apart. It names nine entries: uidapi.com (UID2), adsrvr.org (The Trade Desk), id5-sync.com and eu-1-id5-sync.com (ID5), rlcdn.com and pippio.com (LiveRamp), permutive.com, ad.gt (Audigent) and a placeholder test domain.
It isn’t limited to the Safari app either. Every browser on an iPhone has to run on WebKit and Digiday reports that Chrome, Firefox and the rest are caught as a result.
THE TRADE DESK WAS BLOCKED, THEN FIXED IN BETA
The Trade Desk’s ad requests and its cookie sync both live on adsrvr.org, so blocking the domain stopped TTD bidding in Safari altogether. AdExchanger reported on 29 September that the DSP couldn’t serve ads to Safari users on iOS 27 and later suggested that the intended target had been the cookie sync endpoint rather than ad delivery.
Our CTO, Mike Cherichetti, saw the same thing on his own iPhone after updating. Ads still served, but TTD’s bids weren’t getting through.
On 5 October WebKit’s John Wilander asked The Trade Desk to test an iOS 27.2 beta that removes adsrvr.org from the list. The bug was marked resolved on 9 October. Apple posted the iOS 27.2 release candidate on 19 October but, at the time of writing, hasn’t given a public release date. Until people install it, TTD is missing from Safari auctions on every iPhone and iPad running iOS 27.
The ID providers aren’t getting the same treatment. Nothing since suggests the other entries have moved. ADOTAT reported that ID5 won’t be coming off the list.
WHAT APPLE AND ID5 HAVE EACH SAID
Apple said nothing in public for five weeks. Its WebKit post now says the target is third-party “identity resolution infrastructure”, meaning companies that sit invisibly on pages where people type an email address, turn that address into a persistent ID and use it to recognise the same person across sites and devices.
Apple says the block works at the domain level, that a site personalising things for its own logged-in users isn’t what it’s aiming at and that its tracking prevention policy grants no exceptions to specific companies. The post names no vendors and publishes no list.
ID5’s chief executive, Mathieu Roche, described the change as an attack on the advertising business model of the open web rather than on individual ad tech companies. He said regulators should take a look.
There’s also disagreement over how far this goes. AdExchanger reported on 2 October that Apple can update the list remotely and has hundreds of data companies in its sights. Digiday has since reported that a test of more than 70 ad tech domains found only the original handful blocked and that the code for remote updates hasn’t shipped yet. We’ll leave the verdict on Apple’s motives to you.
A QUICK BACKGROUND ON UNIVERSAL IDS
Universal IDs exist because the third-party cookie stopped working. Safari has blocked third-party cookies by default since March 2020. The industry built identifiers that don’t depend on them.
Some are deterministic, built from a hashed email address when a reader logs in or signs up. UID2, EUID and LiveRamp’s RampID work this way. Others are probabilistic or built on first-party cookies. ID5 uses a mix of both.
On the page, an ID module in Prebid calls the provider, gets an ID back, stores it and adds it to every bid request. SSPs and DSPs that recognise the ID can match the impression to an audience, which generally means more bids and higher prices. Without one, the buyer is pricing an anonymous visit.
In Tradecore, the ID Hub has 14 ID and identity solutions pre-integrated, including UID2, EUID, ID5, RampID (via ATS), IntentIQ, Criteo ID, Panorama ID, AMX ID, Quantcast ID, PAIR, SharedID and 33Across ConnectID. Each one is a toggle in the UI rather than a contract and a code change.
Three of those are on Apple’s list (UID2, ID5 and RampID). Permutive and Audigent are audience and data platforms rather than IDs in most Prebid setups, but if you run either on your pages the same applies to them.
None of the others appears in the public reporting so far. Bear in mind that Apple’s description of what it’s blocking could fit more than three companies. Its policy also says it can add restrictions without notice.
WHAT WE’VE SEEN SO FAR
It’s early. A week in, Digiday spoke to two senior commercial execs at news publishers who hadn’t seen any impact yet. Consultants have put the muted effect down to how few people had installed iOS 27.
That matches what we’ve seen. Safari was already starving identity providers before this. With third-party cookies gone and script-set storage capped by Intelligent Tracking Prevention, ID match rates on Safari were low long before September, so cutting off the requests that produced them hasn’t moved much on its own. In our view TTD’s bidder was the bigger loss, because that’s demand leaving the auction rather than a signal that was already thin.
We’ve also reviewed a couple of publisher stacks for prospective clients this month. ID5 was running on both. In one of them it was one of only two IDs on the page.
Adoption of iOS 27 will climb through Q4, which is when Safari traffic is worth most. And because the block covers macOS 27 too, desktop Safari users drop out of ID matching as they update their Macs.
WHAT TO CHECK THIS WEEK
- Find out which ID modules still return anything on Safari 27. The quickest test is an iPhone on iOS 27 plugged into a Mac, with Safari’s Web Inspector open on a few article pages. Look for failed requests to the domains above. In Tradecore, the ID Hub shows bid rate on traffic where each ID resolved against traffic where it didn’t, so you can see what each one is earning.
- Stop loading the ones that don’t. On Safari 27 an ID5 or UID2 call adds a request and some script, then fails without giving the auction anything back. They still work in Chrome, Edge and on Android, so if your wrapper can scope modules by browser or OS, do it there rather than removing them everywhere.
- Watch Safari bid density and The Trade Desk’s share. TTD should come back as iOS 27.2 reaches people’s phones. Splitting Safari by OS version, where your analytics allow it, separates the effect of the update from normal Q4 movement.
- Take server-side workarounds slowly. IAB Tech Lab is pushing Trusted Server, which routes vendor calls through the publisher’s own servers so Safari doesn’t see them. As of Digiday’s 8 October report it wasn’t live with any publisher and needs engineering time. Apple’s policy also says it may add restrictions, without notice, against parties that try to get round its protections. That doesn’t mean a server-side setup will be targeted, but it’s worth knowing before you build one.
- Keep in-app separate. Calls made natively by an app SDK don’t go through WebKit, so this block doesn’t reach them (in-app web views are a different matter). If you monetise apps through the Tradecore SDK, your in-app ID setup isn’t affected by this change.
If you’d like someone to check which IDs your pages load on Safari 27 and what each one is earning, our technical reviews are free. We’ll tell you which ones are worth keeping.