Apple Blocked UID2, LiveRamp and ID5 in Safari 27 (and Named None of Them)
Apple's WebKit team confirmed on October 19 that Safari in iOS, iPadOS, macOS and visionOS 27 blocks network access to "identity resolution infrastructure," the third-party services that turn an email address entered in login or newsletter forms into a persistent tracking ID. The block works at the domain level, so the email never reaches the vendor. Targeting and measurement built on browser-side email-to-ID matching now go dark on Safari 27.
The post itself, "Blocking Identity Resolution Infrastructure" on the WebKit blog, names zero companies. That part is almost funny. Everyone in ad tech already knows the names, because the industry has spent the last month reverse-engineering the list in public, and Apple has now written roughly 750 words of justification without confirming any of it.
Who actually got blocked (according to everyone except Apple)
The names come from a WebKit bug report. On September 21, The Trade Desk's Ian Meyers filed WebKit bug 324771 listing nine domains that Safari 27 was refusing to load. Per PPC Land's breakdown of today's post, those include uidapi.com (Unified ID 2.0), id5-sync.com (ID5), rlcdn.com and pippio.com (LiveRamp), permutive.com (Permutive) and ad.gt (Audigent), plus The Trade Desk's own ad delivery domain, adsrvr.org, which an iOS 27.2 beta appears to restore.
The rest of the market didn't all get caught. Digiday tested more than 70 ad tech domains and found only that first handful blocked. Zeta's LiveIntent, Lotame and Yahoo's ConnectID all got through. At the same time, AdExchanger reported that Apple has a much longer list in mind, hundreds of CDPs, data sellers and ID graph operators, and that the list can be updated remotely without an OS release. Apple hasn't confirmed that, and today's post doesn't explain how domains are chosen at all.
So the honest summary is: a short list is definitely live, a long list might be coming, and nobody outside Cupertino knows the selection criteria.
Why "durable ID" just got a lot less durable
The pitch for email-based IDs over the last few years went something like this: cookies are dying, but people log in with the same email everywhere, so hash the email, resolve it to an ID, and you get cross-site identity back. Apple's post goes straight at that logic. "Logging out or unsubscribing from that newsletter does not remove the tracking ID," the WebKit team writes, which is a pretty pointed way of describing the product a lot of identity vendors sold.
And the mechanism matters. Safari already capped cookies and stripped click IDs, but those were things you could partly route around. This one blocks the network request to the resolver, so there's no clever request structure to try. WebKit says as much: the blocking "is done on the domain level." The closest analogy is a bridge closure. You can drive faster all you want, and you still aren't getting across.
The scale is the part I'd underline for anyone running US mobile budgets. Safari held roughly 50% of US mobile and tablet browsing in mid-2026, according to Statcounter. Not all of that is on version 27 yet. AdExchanger noted on October 8 that the iOS 27 install base was "still relatively low," which is why the revenue impact hasn't shown up loudly. I'd treat that as a timing cushion with an expiry date, since iOS adoption tends to climb fast through the holiday device cycle.
The block is already live. What's lagging is how many of your users have updated.
Where this probably shows up in your numbers
Most marketers don't touch uidapi.com directly, which is why I think a lot of teams will assume this isn't their problem. It seems to show up in three less obvious places:
- Programmatic audience match rates. If your DSP or SSP partners lean on UID2, RampID or ID5 to make Safari inventory addressable, Safari 27 impressions are likely arriving with no ID attached. ID5 and OpenX had made a whole case for Safari reach with email-based IDs, so that inventory is now a question mark.
- Publisher and DTC sites running identity tags. If your own site loads a LiveRamp, ID5 or Permutive script on login or signup, that script now fails silently for Safari 27 visitors. Nothing breaks visibly. The data just stops.
- Retargeting pools built from on-site email capture. Pools that were growing from browser-side resolution will shrink for Safari users without anyone flagging it.
Worth separating this from server-side Customer Match and conversion API uploads, by the way. Apple's post is about browser network requests to third-party resolvers, and it describes first-party personalization as explicitly not the target. Uploading consented emails from your own CRM to Google or Meta server-to-server is a different path, and nothing in today's post touches it. (Whether Apple likes that path is another matter, and I wouldn't bet the house on it staying untouched forever.)
Also, a small aside on hashing, since it keeps coming up: the FTC already warned in 2024 that hashed data is not anonymous. Apple's post never mentions hashing at all, which I read as Apple not caring whether the email is hashed. An ID is an ID.
A 20-minute Safari 27 identity audit
None of this needs a vendor call to start. Here's roughly the order I'd do it in:
- Search your tag stack for the known domains (10 minutes). Open Google Tag Manager or whatever tag manager you use, plus the page source on your login and signup pages, and search for uidapi, id5-sync, rlcdn, pippio, permutive and ad.gt. Permutive has reportedly moved to a new domain as a temporary fix, so ask your vendor which domain you're actually loading.
- Split your conversion data by Safari version (5 minutes). In GA4, build an exploration with browser and browser version as dimensions, and compare conversion rate and attributed conversions for Safari 27.x against Safari 26.x and Chrome since September 14, when iOS 27 started rolling out. My rule of thumb: if Safari 27 is converting more than 10 to 15% below Safari 26 on the same campaigns, identity loss (or the earlier click-ID stripping) is the likely suspect, not the creative.
- Ask your DSP one question (5 minutes to send). What share of your Safari impressions carried a UID2, RampID or ID5 identifier before September 14, and what share since? If they can't answer that, that's an answer too.
Then the longer fix: move email-based matching out of the browser and into consented, server-side uploads you control. If you haven't set up a server container yet, our piece on Safari's 7-day cap on subdomain sGTM cookies covers the trap to avoid there. And if you're already uploading to Google, the November 16 Data Manager change is a good moment to clean up how those uploads are formatted anyway.
The list will probably get longer, quietly
This is the third Safari 27 tracking change in about three months. Stape's July beta analysis flagged expanded click-ID stripping and IP-level blocking of ad endpoints, and then came the domain blocks we covered when The Trade Desk got caught in the net. Each one arrived with little or no announcement. Today's post is actually the most Apple has said about any of them, which is sort of telling.
My prediction: by the end of Q1 2027, the confirmed blocklist covers at least 25 identity and data domains, up from the eight or so identity domains named in the bug report, and at least two of the IDs that slipped through Digiday's test get added. If I'm wrong, it'll probably be because the industry moved resolution server-side fast enough that there was nothing left in the browser to block. Which, to be fair, is likely the outcome Apple wants either way.
I keep going back and forth on how big a deal this is for the average advertiser. For someone running mostly Meta and Google with CAPI and enhanced conversions already set up, the direct hit might be small. For anyone whose Safari reach story depended on an email-based ID, it's a lot bigger than it looks right now. I'd spend the 20 minutes finding out which one you are before the holiday iPhone upgrades decide it for you.
