- WebKit says trackers moved from cookies to email addresses, a method called identity resolution. Its iOS, iPadOS, macOS and visionOS 27 releases block network access to that infrastructure.
- The identifier is the address people give to log in or join a newsletter. WebKit says logging out or unsubscribing does not remove the tracking ID.
- Teams should list the outside vendors whose code runs on pages with email fields and test those flows in the 27 releases.
The cookie was only the container
For years, the privacy fight on the web centred on cookies. By WebKit's account, Safari closed the door on cross-site cookies completely six years ago. Its engineers now argue that the tracking industry did not stop there.
In a post published October 19, John Wilander, Charlie Wolfe and Matthew Finkel describe a "post-cookie" method called identity resolution. The lesson here is that blocking one storage trick does not end tracking if the thing being tracked stays available. In this method, the thing being tracked is the email address people type into forms.
How identity resolution works
WebKit describes the scheme in steps. It begins on pages where someone enters an email address to sign in or join a mailing list. A third party, not the site's owner, collects that address without the visitor seeing it.
The outside company sends the address to its own servers. There it creates an opaque tracking ID and links it permanently to that address. The ID goes back to the web page, which stores it.
From then on, the ID can serve what WebKit calls "arbitrary purposes." Examples include building a profile of someone's browsing or targeting ads at them across websites.
WebKit says logging out does not remove the ID. Unsubscribing from the newsletter does not remove it, or the address held by the third party, either.
Over time, these companies gather more data as people sign in or fill in forms. WebKit calls the resulting profile an identity graph. It adds that a phone number can work the same way, which allows tracking across devices as well as across sites.
Why the email address makes a strong key
WebKit notes that for most users, an email address is a globally unique ID they keep for years, even decades. That durability is what makes it useful to a tracker.
There is also a trust problem. Someone who signs up for a newsletter expects a newsletter. WebKit says people do not expect their details to go to a third party for other, possibly long-term, purposes. It says this breaks the expectation under which the information was given.
WebKit also draws a line around its own target. First-party personalization is, in its words, "not tracking." But it argues that a central resolver is still a third party, even if each graph uses only one company's data. WebKit says the resolver sees across sites, devices and companies. It can match and target people as a clearinghouse, a capability no single first party has alone.
What WebKit has changed
With version 27 of iOS, iPadOS, macOS and visionOS, Safari and WebKit refuse network connections to identity resolution infrastructure. WebKit says this stops those services from receiving the email address and prevents what follows from that.
The block works at the domain level. WebKit says that means a vendor cannot get around it by changing how the network request is built.
Separately, WebKit points to Hide My Email for iCloud+ subscribers. It gives each new website a unique, random address while still delivering messages to the user's inbox.
The post has limits. It does not name the blocked domains or companies, and it gives no figures on how many sites are affected. It is also a browser maker describing its own feature, so teams should test the effects themselves.
What leaders should ask
WebKit describes these third parties as "present but invisible" on many pages where people enter an email address. Because visitors cannot see this code, a page owner may not have reviewed it.
Four questions are worth putting to your web and marketing teams.
First, which outside vendors' code loads on pages with an email field, and who approved each one? Second, does any vendor receive the address and return an ID that is stored on your site? Third, do your measurement or advertising results depend on that ID for Safari visitors, and have you tested those flows on the 27 releases? Fourth, does your privacy notice describe what happens to an address when a visitor signs up?
WebKit's own distinction is useful here. A customer's address used inside your own systems is a different thing from one routed through an outside clearinghouse. The first is a relationship. The second, in WebKit's account, is a tracking capability that breaks what the customer expected when they handed over the address.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: WebKit.
