Email verification protocol
39 comments
·November 1, 2025phyzome
I don't know if this is the solution, but we desperately need one. It's to the point where "email bombing" is forcing service providers to add captchas to login and registration because those forms are being abused as mail-flooders.
yomismoaqui
"There are privacy implications as the email transmission informs the mail service the applications the user is using and when they used them."
Not really, as I can enter any email on a service login page that uses magic links for auth. The owner of that email will receive the login link but that doesn't mean they tried to login on that system.
Y_Y
Not really indeed. You're right that false positive are possible with such a system, but false negatives are not. That means that you're leaking information about when a user didn't use a service, as well as partial information about when the did (which you could combine with other data to tell you something meaningful).
stavros
This is what Mozilla Persona did, too. I loved the UX, but it wasn't very successful, unfortunately.
ErikBjare
Apparently Persona was even based on some prior work called "VerifiedEmailProtocol", eerily similar to the OP
meonkeys
Skimming that I'm thinking yes, sure, why not, but this repo is missing useful context. Who are you, authors? Why should I bother learning this protocol? Is anyone using or going to use this? If it's new, has it been shopped around at conferences? Any related research?
harvey9
On the rare occasions where I would care about this as a user, I make a throwaway account on an anonymous service. If I don't want my email service to know I have an account with you then I don't trust you to handle my main address either.
l___l
Why must apps require email? Why not only username and password?
tytho
Many applications need a way to contact a user (security breach, password reset). If one only has a username and forgets the password, there’s no way to reverify the user.
dspillett
> Many applications need a way to contact a user … password reset
At this point the password is pointless, you might as well just use the email address. Or perhaps a distinct username and email address, but then there would probably be a “forgot username” workflow making that as pointless as the separate password.
Hizonner
> If one only has a username and forgets the password, there’s no way to reverify the user.
Tough beans?
crazygringo
A good user experience does its best to avoid tough beans. That's kind of UX 101.
l___l
[dead]
zetanor
Because it's less expensive to send a few e-mails than to provide customer support to everyone who forgets their password.
hombre_fatal
Most people want a way to recover their account if they lose those creds, especially when you ask them once they’ve lost their creds.
It’s also a rudimentary PoW system against bots. And people who don’t want to share their email can use a temp email service, so it’s no skin off their back.
efilife
Weird that no one said this yet: To verify users' legitimacy. If you make effort to block 10 minute email services it works kinda well and slows down bots
ocdtrekkie
Without traceability, any app that can be used for abuse will be. (An HN reader used an anonymous mail service to send me some hate speech and tell me to kill myself within the last day. The service they used to do it obviously does not care, but also cannot do anything about it, because they don't know who used their service to do it.)
cynicalsecurity
Because emails of real people can be sold to advertisers.
jgalt212
I agree. username and password is much more robust to credential stuffing attacks.
mvid
Might want to take a look at https://github.com/zkemail
ericpauley
Hard to see how this provides substantial benefits over OIDC. Either one requires support from the email provider, but one is already standardized and has widespread support.
kogir
OIDC is usually limited to a small selection of providers.
turnsout
This is sorta interesting, but it fails on several levels. First, email verification as it exists currently is fairly simple, there are a lot of different ways to do it, and it works universally for all email addresses (as long as you don't expire codes too fast for servers that use greylisting).
This protocol solves a pretty contrived problem ("By sending the email verification code, the inbox provider knows the user is using that service!") by making email verification exponentially more complex, with only one correct flow, and will only work for domains that have opted in and configured this protocol.
Importantly, the protocol seems to rely on 1st party web cookies, which means you could no longer run a "pure" MTA that offers IMAP; you would need to have some web interface where your users can log in, even if there is no webmail functionality.
The bigger question is: why would the company who is hosting the email have any economic incentive to invest time and money in implementing and maintaining this protocol which currently has zero adoption? It's a chicken-and-egg with no upside.
binary132
why does it have to be email?
philipwhiuk
> User privacy is enhanced as the issuer does not learn which web application is making the request as the request is mediated by the browser.
This seems extremely marginal. The point of verifying an email address is to subsequently use it to send email.
* It's lowering the friction to the site identifying the user (separate from the identification done now by the more sophisticated third-party tracking by surveillance companies like Google and Meta), even for sites that previously couldn't justify the friction of trying to do that.
* It's putting surveillance companies even more in the loop, building on the recent "log in with [surveillance company]" buttons, while existing login methods are destroyed through dark pattern practices or simply removed.
* It can be a ready-made platform, waiting for the next authoritarian government directives that say, now that everyone is hooked up or can easily be hooked up, turn on oppressive feature X, Y, or Z for all targeted Web sites/people.