Available for day contractsFrom 21st September I have availability for day and half day contracts. Please contact for more information.

Contact →
mikepreston.org
~/writing/publishing-a-hash-of-someones-email.md
2026-09-22· 3 min read· #essays

Publishing a Hash of Someone's Email Is Publishing Their Email

A man at a registry desk wearing a paper mask of his own face while the clerk calmly matches it against a tray of portrait cards — 1960s gouache.

Every Gravatar avatar on a page is an email address in a thin disguise. The identifier is a hash of the address, trimmed and lowercased — SHA-256 in the current documentation, MD5 for the twenty years before it — and it sits in the HTML of every comment thread, commit view, and profile card that renders the picture.

A hash conceals a value in proportion to how hard that value is to guess. Email addresses barely qualify. Take the display name printed next to the avatar, add the five providers that carry most personal mail, generate the obvious permutations of first name, surname, and the username already on screen, hash each candidate, and compare. No requests to anyone's server, no rate limit, nothing logged. A laptop works through millions of candidates while the kettle boils. If the address has ever appeared in a breach corpus, it isn't even guesswork.

That gets you confirmation rather than recovery: the hash lets anyone test an address they already suspect. It doesn't need to do more. The question that matters is almost always "is this account that person?", and a published avatar answers it.

Moving from MD5 to SHA-256 changes the cost per guess and leaves the search space exactly as it was. Both are fast by design, and a deliberately slow hash wouldn't save this either — it would multiply an attacker's afternoon by some constant, while charging the same multiple to every avatar render on the internet. The flaw is deriving a public identifier from personal data, not the function chosen to derive it.

There's a quieter second leak. Each avatar is a request to a third party, carrying the reader's IP address and, depending on your referrer policy, the page they're reading. That's an identity and a reading log, handed to a service the reader never signed up to.

"It's hashed" doesn't settle the data-protection question either. Pseudonymised data is still personal data under the GDPR. Hashing changes the risk; it doesn't change the category.

Three options that don't leak:

  • Proxy it. Fetch and cache avatars server-side, and serve them under an opaque identifier of your own. Your readers stop talking to a third party, and the hash stops appearing in your HTML.
  • Keep identity local. An uploaded image keyed to a user ID gives away nothing about the address behind the account.
  • Generate one. Identicons are fine, as long as the seed is a per-user value you minted rather than anything derived from the address.

I initially wrote this up in 2014, when the hash was MD5 and the conclusion was the same. If the identifier can be derived from the input, you have published the input. The hash is only packaging.

Edited in 2026 to add the new hash and the GDPR implications.