Apple WebKit Blocks Third-Party ID Resolution Infrastructure on iOS and Mac

Full analysis

Apple's WebKit Team Just Named the Block List Out Loud

Apple's WebKit team just drew a line and named it out loud. With iOS 27, the browser engine that runs Safari and every browser on an iPhone (yes, including Chrome) started blocking a specific list of ad tech domains. The macOS 27 update did the same on desktop Safari. Apple called those domains "identity resolution infrastructure," which is the plumbing that stitches a user's activity across different websites into one profile. That is the whole third-party ID-resolution business. Vendors like ID5, LiveRamp's ATS, and anyone whose product is a wrapper around someone else's ID graph just got put on a public block list.

What's actually being decided: nothing, by you. Apple already decided. The real question for operators is whether your identity and yield stack leans on a middleman that now returns nothing on Safari and iOS traffic, and how fast you route around it. This is hard for Apple to undo and they have zero reason to. For publishers and ad tech vendors, the re-architecture is easy to start and painful to finish. What sets the deadline is the next time your demand partners re-tier Safari inventory, which happens in weeks, not quarters.

The Operator. Audit every tag firing in Safari and iOS Chrome today. Any bid signal that calls ID5, LiveRamp's ATS, or a similar resolver on that inventory now returns null. When the ID disappears, DSPs lose frequency capping and audience context, so they drop their bids or re-tier the traffic to remnant. Expect a CPM haircut on unresolved Safari inventory inside 60 days. The ugly part is the onboarding pipeline: if your first-party data gets matched by routing through a third-party resolver, that middleman is now a dead end, and patching a tag won't fix it. You have to rebuild the match to happen server-side or inside a clean room.

In plain terms: the piece of software that recognized a returning visitor across sites just stopped answering on iPhones, so ad buyers pay less for those visits.

The Market Analyst. ID5 is private, so the stock angle runs through the public names with resolver-dependent revenue baked into guidance. LiveRamp's ATS, its authenticated identity product, is the one to check at the next print: if Safari and iOS traffic degrades, that's a direct question for their forward numbers. The Trade Desk reads differently. TTD sells on the quality of logged-in, authenticated inventory, so a shrinking pool of resolvable Safari traffic trims the total addressable universe a bit while making its premium-authenticated pitch look stronger. Contextual vendors like GumGum and Peer39 get a quiet tailwind, because when you can't identify the user, you sell against the page. The compression lands hardest on open-web publishers with public multiples and no login wall.

In plain terms: companies that sell "we know who this person is" get squeezed; companies that sell "we know what this page is about" get a lift.

The Skeptic. Let's not write the obituary from the vendor's press release. Safari's cookie-based targeting has been dead since ITP in 2017. The industry has had six years to build around it. So the marginal damage of blocking resolver domains on inventory that was already cookie-less is smaller than the noise suggests. Mathieu Roche of ID5 calling this "an attack against the business model of the web" is a CEO defending his domain list, not a neutral read. Enterprise publishers with real login walls are mostly fine. The loud voices here are the resolver vendors; their customers haven't published a single revenue-impact number yet. High noise, unproven damage.

In plain terms: the thing Apple just blocked was already half-broken, so the shock may be louder than the actual loss.

The Customer / End User (the publisher). Anthony Katsur of IAB Tech Lab put the weight in the right place: the pressure lands hardest on publishers whose "first-party data strategy" was actually a third-party resolver doing the stitching. That was a lot of mid-tier open-web sites. They told advertisers they had first-party data; what they had was a vendor turning anonymous Safari traffic into something addressable. That trick is gone on more than half of US mobile web. The publishers with genuine logins, email registration, and real contextual signal come out ahead, because scarcity of resolvable inventory pushes budget toward whoever still has it. Everyone else has to go build the thing they claimed they already had.

In plain terms: publishers who borrowed their audience data from a vendor just lost the loan.

The CFO. The line item you're cutting is the resolver fee. The cost you're not seeing is the engineering to rebuild onboarding so your first-party data matches without touching a blocked domain, plus the revenue dip while Safari inventory re-prices during the rebuild. That's real money out before any money comes back. The payback case is only strong if you own actual first-party relationships worth onboarding. If you don't, you're spending to rebuild a pipe that carries nothing. For a mid-tier open-web publisher, the capital question is simple: is it cheaper to build a login wall and a clean room, or to accept that Safari is now low-yield contextual inventory and price it that way?

Where the council splits. The Skeptic says the damage is small because Safari was already written off, and the resolver vendors are just loud. The Strategist view in the lens notes says the opposite: this is the accelerant that finally invalidates the wrapper-around-third-party-IDs model on 55%-plus of US mobile web. Both can't be fully right. The reconciliation: the marginal damage to targeting is small, but the damage to the business model of middleman resolvers is large, because Apple naming the category publicly gives every DSP and publisher permission to stop building on it. The second disagreement is about publishers. The Skeptic says enterprise login-wall publishers are unaffected; the Customer view says the real victims are the mid-tier sites that dressed up a resolver as first-party data. Those are different publishers, and both statements are true at once.

What it hinges on. Two things. First, how much resolver-dependent revenue sits inside the forward guidance of the public names, LiveRamp's ATS above all. Second, whether publishers respond by rebuilding server-side and clean-room matching, or just let Safari slide into cheap contextual inventory. The council leans toward structural impairment of the standalone resolver model and a real tailwind for contextual and publisher-native identity. The thing to verify before acting: pull your own Safari and iOS yield reports and see how much of your addressable revenue actually depended on a now-blocked domain. Don't take the vendor's word, and don't take Apple's framing either.

Prediction: LiveRamp's full-year fiscal 2027 revenue growth rate, reported on its spring 2027 earnings call, will decelerate versus its fiscal 2026 full-year growth rate.

Confidence: Medium. ATS is directly exposed, but LiveRamp's CRM and clean-room business can mask the drag.

Why: Apple's WebKit block kills third-party identity resolution on Safari and iOS Chrome, which is more than half of US mobile web traffic, and LiveRamp's Authenticated Traffic Solution (ATS) is exactly the kind of resolver that depends on firing on that inventory. When the resolver call returns null, the authenticated inventory LiveRamp monetizes shrinks and buyers re-tier it down, so the ATS growth contribution slows through fiscal 2027. The opposite outcome (growth accelerating) would require LiveRamp's clean-room and data-collaboration business to grow fast enough to not just offset but outrun the ATS drag in the same year Apple structurally impaired it, which is the harder path right after a public block list names the category.

Revisit by 2027-07-31: We're right if LiveRamp's reported full-year fiscal 2027 revenue growth rate is lower than its fiscal 2026 full-year growth rate. We're wrong if it is equal or higher.

The contextual vendors get the easy tailwind out of this, but that's the predictable read. The interesting pressure is on the one public company that built a named, branded product on exactly the plumbing Apple just blocked, and still has to carry it in its guidance.