* 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.
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.
"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.
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).
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?
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.
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.
> 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.
In the case of security procedures, I'd argue that there is some room for tough beans. Reducing security to cater for carelessness seems like a really bad compromise to me, one that I see far too often.
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.
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
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.)
The onus is on you here… but, I think I know where you’re going with this. In terms of number of email addresses people have and use, vs number of usernames people have and use, you might be right that some people have 1 or 2 email addresses and many usernames.
Email masking has become easier to use, and many people use `+addressing` to uniquely tie their email to the service for spam prevention / tracking, which would make stuffing harder.
In these cases, email would be much more unique and a better protection against stuffing. HOWEVER, it’s not obvious how Email verification protocol would work for these types of things.
Credential stuffing is where a user signs up on one Website B with account information matching the information they used when setting up their account on Website A.
If websites authenticate with username and password combo chosen by the user, then credential stuffing is neutralized if the user avoids re-using the same combo, effected by the user selecting at least one of a different password or the selection of a different username.
If instead of a username, an email address to register, that generally results in one less degree of freedom; rather than being able to create a username with Website B that differs from the username they created on Website A, absent the use of a wildcard/catch-all mailbox or forwarding service (which are not straightforward to set up, and almost nobody has one), the user is required to disclose an existing email address.
(It also increases the surface area for attacks, since the malicious website, now knowing the user's email address, can attempt credential stuffing with the user's email provider itself.)
You can balk at whether or not these are negligible differences, but it's non-zero. Therefore, strictly speaking, it is more robust when comparing, all other things equal, usernames in lieu of a requirement where users enters their email address.
>If instead of a username, an email address to register, that generally results in one less degree of freedom [...]
It "generally" doesn't, because the average user isn't randomly generating usernames per-site, just like they're not randomly generating passwords per-site. If they're randomly generating usernames per site, they'll need some sort of system to keep track of it, which is 90% of the way to using a password manager (and therefore randomized passwords, immune to credential stuffing). For it to practically make a difference, you'd need someone who cares about security enough to randomize usernames, but for whatever reason doesn't care enough about security to randomize passwords.
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.
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.
Ha! Thank you, I misunderstood who was behind this proposal but since it's W3C it's something that would directly be implemented by the browser itself.
* 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.
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.
"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.
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).
This is what Mozilla Persona did, too. I loved the UX, but it wasn't very successful, unfortunately.
Apparently Persona was even based on some prior work called "VerifiedEmailProtocol", eerily similar to the OP
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?
author:
https://www.w3.org/community/wicg/
https://wicg.io/
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.
Why must apps require email? Why not only username and password?
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.
> 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.
> If one only has a username and forgets the password, there’s no way to reverify the user.
Tough beans?
A good user experience does its best to avoid tough beans. That's kind of UX 101.
In the case of security procedures, I'd argue that there is some room for tough beans. Reducing security to cater for carelessness seems like a really bad compromise to me, one that I see far too often.
Because it's less expensive to send a few e-mails than to provide customer support to everyone who forgets their password.
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.
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
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.)
Because emails of real people can be sold to advertisers.
I agree. username and password is much more robust to credential stuffing attacks.
> username and password is much more robust to credential stuffing attacks.
/s?
In theory, maybe to some extent yes - unique usernames could beat reused emails.
But let's be real - nobody actually does that.
tell me how it's not.
The onus is on you here… but, I think I know where you’re going with this. In terms of number of email addresses people have and use, vs number of usernames people have and use, you might be right that some people have 1 or 2 email addresses and many usernames.
Email masking has become easier to use, and many people use `+addressing` to uniquely tie their email to the service for spam prevention / tracking, which would make stuffing harder.
In these cases, email would be much more unique and a better protection against stuffing. HOWEVER, it’s not obvious how Email verification protocol would work for these types of things.
You're the one who made the claim. So please explain how it is.
Credential stuffing is where a user signs up on one Website B with account information matching the information they used when setting up their account on Website A.
If websites authenticate with username and password combo chosen by the user, then credential stuffing is neutralized if the user avoids re-using the same combo, effected by the user selecting at least one of a different password or the selection of a different username.
If instead of a username, an email address to register, that generally results in one less degree of freedom; rather than being able to create a username with Website B that differs from the username they created on Website A, absent the use of a wildcard/catch-all mailbox or forwarding service (which are not straightforward to set up, and almost nobody has one), the user is required to disclose an existing email address.
(It also increases the surface area for attacks, since the malicious website, now knowing the user's email address, can attempt credential stuffing with the user's email provider itself.)
You can balk at whether or not these are negligible differences, but it's non-zero. Therefore, strictly speaking, it is more robust when comparing, all other things equal, usernames in lieu of a requirement where users enters their email address.
>If instead of a username, an email address to register, that generally results in one less degree of freedom [...]
It "generally" doesn't, because the average user isn't randomly generating usernames per-site, just like they're not randomly generating passwords per-site. If they're randomly generating usernames per site, they'll need some sort of system to keep track of it, which is 90% of the way to using a password manager (and therefore randomized passwords, immune to credential stuffing). For it to practically make a difference, you'd need someone who cares about security enough to randomize usernames, but for whatever reason doesn't care enough about security to randomize passwords.
Might want to take a look at https://github.com/zkemail
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.
OIDC is usually limited to a small selection of providers.
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.
why does it have to be email?
> 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.
> 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.
How can you avoid revealing the application through the `Origin` header?
The request is sent by the browser, not the webapp itself (ie. using xhr or fetch) so it doesn't have headers like "Origin" added.
Ha! Thank you, I misunderstood who was behind this proposal but since it's W3C it's something that would directly be implemented by the browser itself.
Verify email addresses automatically