By William Weiner June 24, 2026
The earlier post – The Cookie That Never Expires – showed how hashed email addresses became the ad industry’s replacement for the tracking cookie. Companies hash your address when you hand it over, and the hash becomes the identifier that follows you across sites and devices. That practice did not stay informal for long. In 2019, The Trade Desk gave it a name, a spec, and an open-source implementation. The result is called Unified ID 2.0, UID2 for short, and it is now the infrastructure underneath a significant share of the open web’s advertising.
What UID2 actually is
The problem UID2 was designed to solve was inconsistency. Companies were already hashing email addresses, but they were doing it differently – different normalization steps, different algorithms, no shared standard. Two companies with the same user’s address might arrive at different hashes and fail to recognize they were looking at the same person. The identity graph was only as good as its ability to make that match reliably.
The Trade Desk built UID2 to fix that. One normalization pipeline, one algorithm – SHA-256 encoded in Base64 – and one token architecture. Any two UID2 participants who hold your email address will now arrive at the same underlying identity. The standard has been open-sourced and operates under an independent governance framework, but The Trade Desk created it and remains central to its operation.
The architecture has two distinct layers, and understanding which layer does what matters.
The first layer is the raw UID2 – the direct SHA-256 hash of your normalized email address. It is static and deterministic. Feed in the same email address anywhere in the world and you get the same hash. This value lives in the backend databases of every publisher, advertiser, and data platform participating in UID2. It is the backbone of the identity graph.
The second layer is the UID2 token – an encrypted, rotating string roughly 220 to 280 characters long. This is what actually travels through the advertising bidstream. Tokens refresh frequently, and one publisher’s token cannot be read by another. The token architecture addresses a real security concern: if tokens were static, stealing one would expose the underlying email address. Rotating tokens prevent that.
The distinction matters because the token’s privacy protections are often described as if they apply to the whole system. They do not. The token keeps the bidstream from leaking your address directly. The raw UID2 sitting in backend databases is a different matter entirely – and it is the foundation everything else is built on.
A note on how the hashing actually works
The normalization rules are defined in the UID2 specification and they contain one detail that surprises people who thought they had already found a workaround.
The process is: lowercase the entire address, trim any leading or trailing whitespace, then hash with SHA-256 and encode the result in Base64. For Gmail and Googlemail addresses only, there is an additional step: remove all dots from the local part and strip the local part at the first plus sign before hashing.
That last rule is the one worth pausing on. Gmail users have long used plus-sign subaddressing – appending something like “+store” or “+newsletters” to their address – as a way to tag and filter incoming mail. Some do it as a rough privacy measure, reasoning that each site gets a slightly different address. The UID2 spec explicitly strips the plus sign and everything after it before hashing. The practice offers no protection inside the UID2 ecosystem. “user+store@gmail.com” and “user@gmail.com” hash to exactly the same value.
For all other domains, dots and plus signs are left alone. But the practical consequence of the Gmail rule is that a very common privacy technique – one that many people use specifically because they are concerned about tracking – does nothing against the system designed to replace the cookie.
The phishing vulnerability nobody talks about
UID2’s token architecture protects against one specific attack: token theft leading to email address exposure. It was designed with that threat in mind, and it handles it. But there is a different attack that the token architecture does nothing about, that security researchers have documented, and that almost nobody in general coverage of UID2 discusses plainly.
The UID2 algorithm is fully public. Anyone can implement it. There is no key, no secret, and no access to any UID2 system required to generate hashes. You run the normalization pipeline and the SHA-256 function yourself. That is the point of a standard: it is reproducible.
Here is what that makes possible.
An attacker builds or purchases a list of target email addresses – this is not a high barrier; data brokers sell them openly and breach compilations containing billions of addresses are available on underground markets. The attacker runs every address through the UID2 normalization pipeline and generates the corresponding raw UID2 hash for each one. This requires a laptop and a few lines of code. Then the attacker cross-references those hashes against a breached or acquired database from a publisher, retailer, or data onboarding platform that stores raw UID2 values alongside site membership records. The result is a precise map: for each email address on the list, the attacker now knows exactly which services that person has accounts with.
Armed with that map, the attacker sends phishing email impersonating exactly the service the target actually uses. Not a generic bank phishing attempt, but a message that appears to come from the specific streaming service, the specific retailer, the specific platform the target signed up for. The phishing email is credible because the targeting is accurate.
This is not a theoretical scenario. The FTC published guidance in 2024 stating explicitly that hashing does not make data anonymous, in direct response to industry claims that hashed email programs were outside privacy regulation. Coverage from AdExchanger documented the implication for UID2 specifically. The underlying concern is structural: when the hash function is public and deterministic, the hash is not a one-way door. It is a lookup key. Anyone with a list of addresses can generate the keys.
EUID – the European fork of UID2 operated by The Trade Desk under GDPR requirements – does not fix this. The math is identical. EUID addresses consent requirements and cross-border data flows, not the attack described above. Its only structural effect on the phishing vector is a smaller participating ecosystem, which shrinks the pool of databases worth targeting but does not eliminate the vulnerability.
The EU response and what it does and does not solve
EUID emerged because European regulators reached a clear conclusion: a hashed email address is pseudonymized personal data, not anonymous data, and pseudonymized data is still regulated under GDPR. The hash cannot be reversed using only the hash – but it can be looked up by anyone who holds a list of candidate addresses. That reversibility, the European Data Protection Board found, means the protection is context-dependent and not categorical.
The Trade Desk responded by building EUID as a separate namespace with mandatory opt-in consent at every publisher touchpoint. A user must affirmatively agree to email-based identity tracking before their address enters the EUID system at that site. The token namespace is isolated from the UID2 namespace, limiting cross-border data flows in ways that satisfy the GDPR adequacy framework.
What EUID changes is the consent architecture and the scope of participation. What it does not change is the underlying algorithm or the structural fact that the algorithm is public. A database breach at a EUID participant leaks raw hashes that are just as reversible – in the attack sense – as any other UID2 hash. The consent obtained at signup does not protect against a breach occurring after that signup. The pool of participating databases is smaller than in the US, which reduces but does not eliminate exposure.
EUID is a meaningful compliance step. It is not a security fix.
What an alias actually does – and what else EMail Parrot adds
Giving a website your real email address gives them the raw material to compute your UID2. They hash it. You are now in their graph, linked to every other site that has seen the same address.
Giving a website a unique alias – an address that routes to your inbox but belongs only to that site – means the hash they compute is for the alias, not for you. It is a different local part on a different domain. The SHA-256 output is completely different. It has no mathematical relationship to your real address’s hash, and no relationship to any other alias you use at any other site.
Consider two aliases: “shop.jsmith@emparrot.com” for a retailer, and “streaming.jsmith@emparrot.com” for a subscription service. Each site hashes what it has. The two hashes share no common value. A data broker attempting to join the two profiles across a breach finds no link, because the join key never repeats.
The plus-sign workaround – “jsmith+shop@gmail.com” – does not provide this protection, as the UID2 spec makes clear. Gmail addresses are normalized before hashing, and the plus suffix is stripped. Both “jsmith+shop@gmail.com” and “jsmith+streaming@gmail.com” hash to the same value as “jsmith@gmail.com.” The variation in the address does not produce variation in the hash.
A different domain is not subject to Gmail normalization. An alias at any other domain hashes as written. But the more important point is not the dot-stripping rule – it is that an alias produces a completely different identity with no connection to the original. The graph cannot be assembled because there is no shared key to assemble it around.
Aliases handle the UID2 problem at the source. EMail Parrot adds a second layer: every message that arrives through an alias is disassembled and rebuilt before delivery. The original sender headers, MIME boundaries, and any metadata that could fingerprint the sending client are dropped and replaced with a clean reconstruction. Tracking pixels – invisible images that report when and where you opened a message – are removed. Rewritten tracking links that send your click through a redirect before reaching the destination are unwrapped back to the real URL. The message that reaches your inbox contains what the sender wrote, not the surveillance apparatus the sender’s platform attached to it.
The combination addresses two separate problems. The alias prevents your real address from entering any UID2 identity graph in the first place. The relay prevents the emails that do arrive from reporting on your reading behavior, your device, and your location. Neither protection alone is complete. An alias without relay stripping still delivers tracking-laden email to your inbox. Relay stripping without an alias still hands your real address – and its UID2 hash – to every site you give it to.
If a site you gave an alias to is later breached, the exposure is limited to that alias. The alias can be disabled. The real address behind it, and every other alias you use, is unaffected. This is the property that plus-addressing was supposed to provide and does not, at least not inside the UID2 ecosystem.
The part that holds regardless
The phishing attack described above does not require UID2 to be the mechanism. Any deterministic, public hash function applied to a stable identifier produces the same vulnerability. UID2 is the most widely deployed instance, which makes it the most relevant one to understand. But the underlying dynamic – a stable, hashable identifier linked to you across services – is the same wherever it appears.
Understanding that dynamic is worthwhile on its own terms. Your email address is not just contact information anymore. It is the key to an identity graph, and the graph does not need your permission to grow. Knowing how the hash is generated, what normalizations are applied, and what the hash enables is the first step toward treating that address as the permanent identifier it has become.
Whether you use aliases or not, the industry built a global standard around your email address. The standard is working exactly as designed.
Questions about migrating? Email us at info@emparrot.com.