Apple's WebKit team has explained why Safari 27 blocks identity resolution services. The ad tech fallout got the headlines. For B2B marketers the more consequential part is how Apple now defines "first party": by who resolves the visitor, not by who collected the email.
On 19 October, five weeks after iOS 27 began reaching iPhones, Apple's WebKit engineers published a post titled "Blocking Identity Resolution Infrastructure." It confirmed what advertisers had been piecing together from bug reports since September: Safari and WebKit in the 27 releases of iOS, iPadOS, macOS and visionOS refuse network connections to third parties that take an email address entered at login or newsletter sign-up and turn it into a persistent tracking ID. "The blocking is done on the domain level," the post says, so the email never reaches the resolver and no ID is created.
The trade press read it, reasonably, as a programmatic story. LiveRamp, ID5, Permutive, Audigent and The Trade Desk's Unified ID 2.0 have all been reported as affected, and the argument since has been about Apple's growing ads business and its unpublished blocklist. B2B marketing teams that do little open-web programmatic buying could be forgiven for filing it under someone else's problem.
That would be a mistake, because of one sentence and the paragraph around it.
The sentence that matters for B2B
"First party personalization is not tracking, and is not what our technologies seek to prevent," the WebKit authors write. On its own that sounds like reassurance. The qualification that follows is the part to read twice: a central identity resolver remains a third party, the post argues, even when its work is scoped to one company's data, because it is in a position to match people across sites and devices.
Most B2B organisations define first-party data by provenance. The visitor filled in our form, consented on our site, registered for our webinar, so the record is ours. Apple has applied a different test, and it is architectural. The question is whose server the browser talks to at the moment a person becomes known. If the answer is a vendor's domain, the contract that calls the data yours does not change what Safari sees.
That matters because a good deal of what B2B teams call personalisation runs through someone else's resolver. A prospect downloads a report or registers for an event, a tag in the browser passes the address to an identity or visitor-recognition service, and the service returns a profile or an account match that drives the next page, the next email and the retargeting audience. The marketer experiences this as first-party. The network request says otherwise.
Apple has not stopped you knowing who your visitor is. It has stopped you learning it from someone else, inside the browser.
Nobody outside Apple can tell you if your stack is affected
The list of blocked domains is not published, and WebKit's post names no companies and gives no criteria for inclusion. The only public list is the nine domains The Trade Desk's Ian Meyers cited when he filed WebKit bug 324771 on 21 September. AdExchanger has reported, citing sources, that the list runs to hundreds of companies; Apple has not confirmed that. Digiday's own testing found most ad tech addresses it checked were still loading.
The list also moves. The Trade Desk's ad-serving domain appeared to be restored in an iOS 27.2 test build 13 days after Apple's first reply on the bug thread, while ID5, according to the ADOTAT newsletter's unnamed source, stays blocked. IAB Tech Lab's Rowena Lam wrote on 13 October that an unreleased WebKit update would let Apple add vendor domains without a software update; that code had not shipped as of Digiday's reporting. Earlier, in July, analytics engineer Mariusz Brucki's review of Safari 27 beta source code found Microsoft's Bing ad endpoint blocked by IP range, LinkedIn's Insight Tag placed under fingerprinting restrictions, and Tealium and Segment added to a fingerprinting classification list. That is one analyst's reading of beta code, not anything Apple has announced, but it shows how much of B2B's measurement and customer-data plumbing sits near the line.
Even ordinary first-party plumbing has been caught. WebKit's notes for Safari 27.2, published on 26 October, include a fix for cookies set by a site's own page response being capped at seven days when the hostname is CNAMEd to a different registrable domain, a common set-up for sites served through a CDN or a hosted platform. Nothing in the original change was announced as aimed at those sites.
Figure 1
How a visitor becomes known | Who resolves the identity | Position under Apple's stated line | What to check |
|---|---|---|---|
Login or account on your own domain | You | First-party personalisation, which WebKit says it does not target | Session and consent cookies if the site is CNAMEd to a host or CDN (fixed in 27.2) |
Email from a form, webinar registration or newsletter, passed by a browser tag to a vendor | The vendor, on its domain | The pattern the 19 October post describes | Which outside domains the page calls at the moment of capture, tested on a Safari 27 device |
Cross-site or cross-device identity graph | The vendor | Named in the post as the concern, even when scoped to one company's data | Whether personalisation or audiences depend on matches made outside your own records |
Ad-platform tags feeding retargeting and conversions | The platform | Not covered by the post; some restricted in Safari 27 beta, per one code review | Server-side conversion routes the platforms already offer |
Account-level matching from network or firmographic signals | The vendor | Not addressed in the 19 October post | Ask the vendor in writing which Safari protections it has tested against |
Where B2B visitor recognition sits relative to Safari 27's identity resolution block. Editorial assessment, not testing. Apple publishes neither the domain list nor its criteria; beta findings are from a single analyst's review of WebKit source.
A failure that looks like a result
A blocked request produces no error in a marketing dashboard. The visitor is simply not recognised, gets the default page, and drops out of the known-visitor count. Nothing tells the team why.
What it does next depends on how the programme is measured, and this is where the damage compounds. Personalisation tests that assign visitors after recognition will quietly lose Apple-device traffic from the treated group, so the arms stop being comparable. Uplift that looked solid in the summer appears to fade in the autumn. The likely internal diagnosis is creative fatigue or a weaker segment, and the likely remedy is new content, when the cause is a browser release that went out on 14 September and has been revised since.
Point releases make this harder. Safari's behaviour has changed between 27.0 and 27.2 in ways that touch identity and cookies, and some of those changes were found by outsiders reading source code before Apple described them. A personalisation report that does not split results by browser and version can no longer tell a programme problem from a platform one.
What this means for marketing leaders
The obvious response, already being sold, is to move identity work server-side. IAB Tech Lab's Lam argues advertising's future is there. For first-party recognition that is broadly right: an identity resolved in your own systems, from a login or a record you hold, falls on the side of the line Apple says it is not policing. But a server-side pipe that reproduces the same cross-site matching is not a loophole. WebKit's tracking prevention policy reserves the right to restrict parties that circumvent its protections, without prior notice and without exceptions for named companies. Moving the request without changing the practice invites the next restriction.
The post also points readers to Hide My Email, Apple's service for iCloud+ subscribers that generates a different random address for each site. A relay address on a form fill gives an identity graph nothing to match, which makes it another reason to treat matching against outside data as a declining asset.
Six checks before the 2027 personalisation plan is signed off
Map every point where a visitor becomes known (forms, event registration, newsletter, login) and record which domain receives the email at that moment.
Load those pages on a device running Safari 27 and confirm which outside requests succeed. Repeat after each point release.
Split known-visitor rates and personalisation results by browser and version, starting from the 14 September release.
Re-read recent test results for Apple-device traffic missing from treated groups before concluding that a tactic stopped working.
Ask identity, visitor-recognition and CDP vendors in writing how their service behaves under Safari 27, and what changes if their domain is listed.
Give buyers a reason to identify themselves on your own domain: an account, a saved workspace, a benchmark they return to.
The last item is the one most plans will skip, because it is product and content work, not configuration. It is also the only part of the stack Apple's post explicitly leaves alone. B2B buyers log in to things they come back for. Teams that have spent five years borrowing recognition from vendors will find that the visitors they can still personalise for are the ones who chose to tell them who they are.
Sources and notes. John Wilander, Charlie Wolfe and Matthew Finkel, "Blocking Identity Resolution Infrastructure," WebKit blog, 19 October 2026 (scope across iOS, iPadOS, macOS and visionOS 27; domain-level blocking; definition of identity resolution; first-party personalisation statement; central resolver as third party; Hide My Email). Seb Joseph and Krystal Scanlon, Digiday, 20 October 2026 (affected companies as reported; testing that found most ad tech addresses still loading). Luís Rijo, PPC Land: 18 July 2026 (Mariusz Brucki's review of Safari 27 beta source on Bing, LinkedIn Insight Tag, Tealium and Segment); 14 October 2026, two articles (Rowena Lam, IAB Tech Lab, 13 October; WebKit bug 324771 timeline; iOS 27 rollout from 14 September; AdExchanger's unconfirmed report of a list of hundreds; ADOTAT on ID5); 19 October 2026 (WebKit tracking prevention policy); 27 October 2026, on WebKit's Safari 27.2 notes of 26 October (CNAME seven-day cookie cap fix). Apple has made no public statement beyond the WebKit post and bug-thread replies. Figure 1 is editorial assessment, not testing. MarketingHubMedia has no commercial relationship with any firm named. Journalism, not procurement or legal advice. Corrections welcome.
