Posted on

Hashed email addresses as persistent advertising identifiers

A hashed email address looks wonderfully anonymous.

It is a long string of hexadecimal garbage.

That appearance can be misleading.

If two companies start with the same email address, normalize it the same way, and run the same hashing algorithm, they can produce the same hash.

Now the ugly string becomes a matching key.

Hashing hides the readable address, not necessarily the relationship

Google’s current Customer Match documentation instructs advertisers to normalize customer emails and hash them with SHA-256 before upload. Google then compares those hashed values against hashed account information to find matches. See Google Ads Data Manager’s Customer Match formatting guidance and How Google uses Customer Match data.

That is the important property.

Google does not need to reverse the hash into the original address in order to know that two records represent the same normalized email.

It only needs both sides to generate the same result.

Suppose:

leo@example.com

is normalized and hashed into:

4c...9f

An advertiser can upload 4c...9f.

A platform can independently hash its copy of leo@example.com and get 4c...9f too.

The plaintext address never has to travel in the matching file for the records to connect.

One-way does not mean anonymous

SHA-256 is a one-way cryptographic hash function. That is useful because the hash is not intended to be decrypted back into the original input.

But anonymity is a different question.

Email addresses come from a relatively structured and often guessable input space. More importantly, a party that already possesses the email address does not need to guess anything. It can simply hash its own copy and compare results.

LiveRamp’s current identity-resolution documentation explicitly accepts hashed email addresses as inputs for resolving records to persistent person- or household-level identifiers. See LiveRamp’s RampID identity-resolution documentation.

That is pseudonymization with matching utility intact.

The readable identifier is transformed.

The ability to connect records survives.

Persistent matching can outlive a cookie

Cookies can be cleared.

Browsers can partition storage.

Mobile advertising IDs can be reset or deleted.

An email address may remain stable for years.

If that email is repeatedly transformed into the same standardized hash, the hash can provide a durable bridge between customer databases, advertising systems, measurement tools, and identity-resolution services.

That does not mean every hashed email is shared broadly or used forever. Actual use depends on the service, contracts, retention rules, platform policies, and user choices.

But the technical lesson is simple.

Replacing a name with a deterministic code does not erase identity if everyone who matters knows how to produce the same code.

The Surveillance Economy frequently works by changing what an identifier looks like without changing what it can connect.

Posted on

Verifying personhood without requiring public legal identity

A community may want to know that ten accounts represent ten different humans without needing to know the ten humans’ legal names.

Those are separate problems.

Identity verification asks who someone is. Proof of personhood can ask a narrower question: is this participant a distinct human who has not already registered another account in the same system?

That distinction matters for communities that value pseudonymity. A whistleblower, political dissident, abuse survivor, niche-community participant, or simply private person may have good reasons not to attach a government name to every public conversation.

There are several ways to prove uniqueness

Different systems solve the problem differently.

Some rely on government documents or phone numbers. Others use biometrics, in-person ceremonies, social graphs, trusted introductions, or networks of people vouching that other participants are unique humans.

The World proof-of-personhood whitepaper explicitly describes personhood verification as a spectrum of credentials with different accuracy and privacy properties. Its own approach includes biometric uniqueness verification, while lower-assurance credentials such as phone-number verification prove something weaker.

BrightID takes a different route, using social relationships and network analysis to resist people creating many identities. A 2020 review of proof-of-personhood systems examined BrightID and other subjective approaches based on vouching and social trust, while also pointing out weaknesses involving privacy, centralization, and uncertain resistance to attacks. See “Who Watches the Watchmen?”.

None of these methods proves everything.

Proving one human is not the same as proving a biography

A system might establish that an account corresponds to one unique participant while learning almost nothing else about that person.

That can be desirable.

If the goal is preventing one user from creating 500 votes, the community may not need a name, address, employer, birth date, or photograph. It needs a credible way to make creating the 499 extra identities difficult.

But uniqueness does not prove honesty. A verified human can still lie, coordinate with others, operate scripts, spread spam, or use AI to write every post.

Likewise, legal identity does not prove that one person controls only one account.

Every verification system moves the risk around

Biometrics can improve uniqueness while creating privacy and exclusion concerns. Government-ID systems depend on official documents and trusted issuers. Social-graph systems can preserve pseudonymity but may disadvantage newcomers or isolated users. In-person ceremonies are difficult to scale. Phone numbers are widely available but can be bought in multiples.

There is no magical “human” checkbox.

For Dead Internet Theory, that is worth remembering whenever somebody proposes mandatory real names as the solution to synthetic populations.

A network can seek evidence that a participant is human without turning every forum into an airport-security desk.

The harder design question is deciding what the community actually needs to prove, and collecting no more identity than that purpose requires.