Field Notes

I Gave It to the Store, Not the Web

2026-10-214 min readPrivacyInterfacesWeb

An email entered for a receipt, login, or newsletter can become a durable cross-site identifier. Safari's newest tracking protection follows that address past the form field.

I gave the store my email address because I wanted the receipt.

That is a small bargain. The store learns where to send one useful message. I keep a record of the purchase. If I check the newsletter box, the bargain grows a little, but it still appears to belong to the store and me.

The same address can make a second bargain somewhere I cannot see.

WebKit's latest tracking-protection update describes third-party identity-resolution services embedded on pages where people enter an email to log in, subscribe, or buy something. The service is not the shop, the newsletter provider, or the account system. It collects the address so activity from this visit can be matched with activity elsewhere.

Cookies were convenient identifiers because a browser carried them from one visit to the next. An email address is better material for the same purpose in one uncomfortable way: people carry it themselves. We type the same one into a laptop and a phone, at work and at home, across shops, publications, ticket sellers, and account screens. A cookie can be cleared. A useful email address may remain with a person for twenty years.

The tracking system does not need to leave the address in plain text. The UK Information Commissioner's Office gives a concrete example in its guidance: a retailer places an identity vendor's tag on the page, the tag accesses the email when it is collected, and a hashing process turns it into a value that can be stored and matched with information held by advertising and social-media partners.

The hash makes the address look less like an address. It does not make the person disappear. The ICO still treats the resulting identifier as personal data because its purpose is to distinguish and follow the same user.

This is the sleight of hand inside the phrase post-cookie. The jar left the table. The appetite for a stable identity did not.

Safari and WebKit now block network access to known identity-resolution infrastructure on iOS, iPadOS, macOS, and visionOS 27. The block happens at the domain level, so changing the shape of the request is not enough to route around it. WebKit also draws an important line around the intervention: a site remembering what its own customer prefers is first-party personalization. A third-party clearinghouse joining that identity to activity across sites and devices is tracking.

That distinction restores the original bargain. The store can know that I bought the blue lamp without quietly asking another company what else the same address has done.

It does not mean the tracking problem is finished. A domain list has to be maintained. New services and routes will appear. Sites can collect information server-side in ways a browser may not be able to see from one request. WebKit's post describes what its current protection blocks, not an inventory of every company that can connect a person across the web.

The intervention is still useful because it treats purpose as part of browser behavior. The browser is not only carrying packets correctly. It is refusing a transfer whose technical success would violate the reason the information was offered.

There is another way to change the bargain before the block is needed. Apple's Hide My Email creates a different relay address for each app or website and forwards the messages to a person's ordinary inbox. The shop can still send the receipt. The newsletter can still arrive. Two sites no longer receive the same key simply because their messages land in the same place.

The current Digital Credentials working draft treats this property as unlinkability. Its privacy section warns that long-lived identifiers such as email addresses and phone numbers can connect identities across services even when a credential exchange looks deliberate. Selective disclosure matters, but so does whether separate presentations can be recognized as the same person afterward.

That gives interface designers a more useful question than whether an email field is necessary. Necessary for what?

A receipt needs a destination. An account may need a recovery path. A newsletter needs permission to keep writing. None of those jobs automatically needs a universal name tag that follows the person into other rooms.

The email address became infrastructure because it is dependable, familiar, and already woven into ordinary life. Those are good reasons to keep using it. They are also why the boundary around it has to become more precise.

I still want one inbox. The stores do not all need to know it is the same one.