Why don’t we do email verification in reverse?(blog.yossarian.net)
blog.yossarian.net
Why don’t we do email verification in reverse?
https://blog.yossarian.net/2022/08/20/Why-dont-we-do-email-verification-in-reverse
328 comments
That’s what I used to believe. Circa 2000 the advice was ‘do what Yahoo! does’ and that was good, but when I revisited that in 2006 I found that Yahoo’s signup and login process was deformed by the need to discourage users from responding to phishing attempts —- a bank needs to be concerned about this but it will hurt the login for other sites that have higher iq users and aren’t big enough that spamming everybody is a good tactic.
I worked on one site (a chat service for Brazil) that had a 20% success rate for the login flow at first that we got up to the high 80s by tweaking this and that. Later I worked on one aimed at scientists that was in the low 80s before optimization.
Some tweaks from a long time ago are:
1. Put something like ‘we sent a message to <b>[email protected]</b>‘ on the post-registration form where they are likely to see it if they make a mistake. Today forms are likely to ask for your email twice to catch this, annoying as it is.
2. Put a form field for the registration code on that form, we found that oriented people towards looking for a registration code. We still sent a link to click on but we found that users preferred to type the code into the form which was fine with us because they succeeeded.
3. Always store the current URL that the person clicked ‘register’ on and store it in the database so they end up where they started after the process is complete.
I worked on one site (a chat service for Brazil) that had a 20% success rate for the login flow at first that we got up to the high 80s by tweaking this and that. Later I worked on one aimed at scientists that was in the low 80s before optimization.
Some tweaks from a long time ago are:
1. Put something like ‘we sent a message to <b>[email protected]</b>‘ on the post-registration form where they are likely to see it if they make a mistake. Today forms are likely to ask for your email twice to catch this, annoying as it is.
2. Put a form field for the registration code on that form, we found that oriented people towards looking for a registration code. We still sent a link to click on but we found that users preferred to type the code into the form which was fine with us because they succeeeded.
3. Always store the current URL that the person clicked ‘register’ on and store it in the database so they end up where they started after the process is complete.
When I started on my first project as a junior engineer I thought I was being clever to build an app without any passwords: every time you wanted to login you received a new email with a link to log you in. Technically, this worked great but after a while I received many complaints from frustrated users who kept looking for the “signup form”…
Oh the few websites that do this drive me absolutely crazy. It makes me immediately look for alternatives, it's unbearable
It assumes that we all have access to our email all of the time. Which is a fair assumption for 99.99% of the population.
But I deliberately keep email off my phone, so I don't look at email on my phone.
So yes, I hate 'passwordless login'. I have a password manager, I can do it myself thanks very much.
But I deliberately keep email off my phone, so I don't look at email on my phone.
So yes, I hate 'passwordless login'. I have a password manager, I can do it myself thanks very much.
You could consider setting up a separate email account just for the verification messages and have that on your phone.
Why should I have to go through all that faff when I have a perfectly good password manager?
Wasn’t suggesting that anyone should - just wanted to suggest a solution to the problem they described.
But they don't have a problem - they just don't use the passwordless sites. If anybody, it's the sites having the problem of missing users.
> But they don't have a problem - they just don't use the passwordless sites.
If nothing else, the idea of having a separate e-mail account/inbox per use case is an interesting one!
Much like those people that use aliases or something of the sort to be able to tell where who sent then a particular email, like if suddenly some [email protected] started getting random marketing mails.
> If anybody, it's the sites having the problem of missing users.
I mean, isn't that just the consequence of websites optimizing for whatever seems to work for them and forgetting about the minority of users? It might be missed profit, sure, but that depends on just what portion of the users view this as a dealbreaker.
Maybe there could be an app like Google Authenticator that would offer login to multiple websites through one's phone? We already have that in Latvia somewhat, for banking - you enter your user details in the web form and get a prompt on your phone for your PIN to log in with in the web app: https://www.smart-id.com/
If nothing else, the idea of having a separate e-mail account/inbox per use case is an interesting one!
Much like those people that use aliases or something of the sort to be able to tell where who sent then a particular email, like if suddenly some [email protected] started getting random marketing mails.
> If anybody, it's the sites having the problem of missing users.
I mean, isn't that just the consequence of websites optimizing for whatever seems to work for them and forgetting about the minority of users? It might be missed profit, sure, but that depends on just what portion of the users view this as a dealbreaker.
Maybe there could be an app like Google Authenticator that would offer login to multiple websites through one's phone? We already have that in Latvia somewhat, for banking - you enter your user details in the web form and get a prompt on your phone for your PIN to log in with in the web app: https://www.smart-id.com/
> Why should I have to go through all that faff when I have a perfectly good password manager?
If you are not using dedicated special-purpose email addresses with specific services, you're already grossly mismanaging your online safety.
Think about it for a second: how does your password manager help you if your email password gets leaked?
If you are not using dedicated special-purpose email addresses with specific services, you're already grossly mismanaging your online safety.
Think about it for a second: how does your password manager help you if your email password gets leaked?
Thats a crazy level of risk assessment for an average user.
> how does your password manager help you if your email password gets leaked?
You still need my TOTP codes in my case at least, which conveniently are stored in my password manager. Is it perfectly secure? No, of course it's not, but frankly my risk profile isn't worrying about a targeted attack on me and my password manager, it's worrying about leaked shared credentials.
Side note, I also get a push notification on my phone whenever a new device logs on, so unless the attack is _extremely_ targeted, well timed and they know what they want, Its not a risk for me.
> how does your password manager help you if your email password gets leaked?
You still need my TOTP codes in my case at least, which conveniently are stored in my password manager. Is it perfectly secure? No, of course it's not, but frankly my risk profile isn't worrying about a targeted attack on me and my password manager, it's worrying about leaked shared credentials.
Side note, I also get a push notification on my phone whenever a new device logs on, so unless the attack is _extremely_ targeted, well timed and they know what they want, Its not a risk for me.
> Thats a crazy level of risk assessment for an average user.
It really isn't. Think about it for a second: how hard is it to spot phishing attempts when they are sent to an email address you know for a fact you're not using with a service?
And how vulnerable are you to phishing if your special-purpose email address that you only use for one specific purpose receives zero spam?
To claim that the most basic and easy internet security precautions are at a "crazy level", first you need to somehow believe that no one is targeted by these schemes. But somehow there's a whole international industry that thrives on stuff like Western Union transfers. Why is that?
It really isn't. Think about it for a second: how hard is it to spot phishing attempts when they are sent to an email address you know for a fact you're not using with a service?
And how vulnerable are you to phishing if your special-purpose email address that you only use for one specific purpose receives zero spam?
To claim that the most basic and easy internet security precautions are at a "crazy level", first you need to somehow believe that no one is targeted by these schemes. But somehow there's a whole international industry that thrives on stuff like Western Union transfers. Why is that?
>>Think about it for a second
Perhaps instead of telling everyone to think on things for a second, you should think on things for longer than a second?
>And how vulnerable are you to phishing if your special-purpose email address that you only use for one specific purpose receives zero spam?
This would depend on how you setup the email address, if it truly a separate email address i.e a separate account not just an alias then phishing is not the concern but management of the accounts becomes a huge problem
I use separate alias's for every service against my own custom domain that has a single email account. This is not to prevent phishing but to detect when a breach occurred or when my info is sold, you assume that when you sign up for a service only that service will ever have access to your info, many many many companies and service sell your email address to marketers.
Perhaps instead of telling everyone to think on things for a second, you should think on things for longer than a second?
>And how vulnerable are you to phishing if your special-purpose email address that you only use for one specific purpose receives zero spam?
This would depend on how you setup the email address, if it truly a separate email address i.e a separate account not just an alias then phishing is not the concern but management of the accounts becomes a huge problem
I use separate alias's for every service against my own custom domain that has a single email account. This is not to prevent phishing but to detect when a breach occurred or when my info is sold, you assume that when you sign up for a service only that service will ever have access to your info, many many many companies and service sell your email address to marketers.
Do you think youre going to get scammed and send a fraudulent Western Union transfer? What do you think the venn diagram overlap between "uses a specific email for each service" and "gets phished" is? The people that even have the capacity to do the first aren't going to fall into the second. If someone is sending fraudelent transfers to scammers, they're not going to be smart enough to create multiple emails.
> Do you think youre going to get scammed and send a fraudulent Western Union transfer?
I know for a fact that there are targeted phishing campaigns aimed at users of specific services such as LinkedIn and GitHub and Twitter and etc, primarily because I've been targeted by them.
> What do you think the venn diagram overlap between "uses a specific email for each service" and "gets phished" is?
I know for a fact that the Venn diagram of phishing attempts sent to email accounts that are not used by those services is practically zero.
Do you understand how trivial it is to identify and filter out these attacks when they are sent to addresses that are already known beforehand that are not used for that purpose?
I know for a fact that there are targeted phishing campaigns aimed at users of specific services such as LinkedIn and GitHub and Twitter and etc, primarily because I've been targeted by them.
> What do you think the venn diagram overlap between "uses a specific email for each service" and "gets phished" is?
I know for a fact that the Venn diagram of phishing attempts sent to email accounts that are not used by those services is practically zero.
Do you understand how trivial it is to identify and filter out these attacks when they are sent to addresses that are already known beforehand that are not used for that purpose?
> To claim that the most basic and easy internet security precautions are at a "crazy level",
Basic and easy internet precautions are not "register and run a domain and host your mail yourself". Basic and easy precautions are don't reuse passwords/use a password manager, use a reputable email provider, enable 2fa with totp, and dont click links from your emails
> first you need to somehow believe that no one is targeted by these schemes.
I don't see how you come to that conclusion at all. The assumption is that _everyone_ is targeted by those schemes.
> But somehow there's a whole international industry that thrives on stuff like Western Union transfers. Why is that?
Because they're low risk high reward, easy to set up, and you only need to make one mistake.
Basic and easy internet precautions are not "register and run a domain and host your mail yourself". Basic and easy precautions are don't reuse passwords/use a password manager, use a reputable email provider, enable 2fa with totp, and dont click links from your emails
> first you need to somehow believe that no one is targeted by these schemes.
I don't see how you come to that conclusion at all. The assumption is that _everyone_ is targeted by those schemes.
> But somehow there's a whole international industry that thrives on stuff like Western Union transfers. Why is that?
Because they're low risk high reward, easy to set up, and you only need to make one mistake.
In 2022 nobody actually clicks links in emails, right?
You are right of course in one sense, but look at the comments here! If the HN crowd is still sending verification links rather than codes to be copy and pasted, that implies regular folks are still clicking the links..
The site would have to have a hell of a value proposition for that to be worth the effort.
"No way! Why should I change? He's the one who sucks."
[deleted]
can you name even one service that uses login links and allows you to configure an address that is exclusively used for login links and not any other communication?
i'm not talking about unselecting all other types of communication, but rather having the service store 2 different emails for you. one for logging in and one for communication.
i'm not talking about unselecting all other types of communication, but rather having the service store 2 different emails for you. one for logging in and one for communication.
That is a fair point, indeed this would probably make the configuration page extremely complex.
I guess my suggestion would only work for cases where you don’t really care much about other kinds of notifications.
What a pain. Nope.
You can solve this problem without a signup form.
Just give the user two links: sign up and log in. Both ask for email address first. The next screen tells them to check their email.
You can use unusual flows without confusing users as long as you give them cues about how to do what they're trying to do.
Just give the user two links: sign up and log in. Both ask for email address first. The next screen tells them to check their email.
You can use unusual flows without confusing users as long as you give them cues about how to do what they're trying to do.
That doesn’t solve the issue of passwordless login, though, which is the fact not everyone has access to their email on every device at all times.
Need to check something attached to a work email (hello Slack) but purposefully not got work email set up on your personal device? Good luck
Need to check something attached to a work email (hello Slack) but purposefully not got work email set up on your personal device? Good luck
> Need to check something attached to a work email (hello Slack) but purposefully not got work email set up on your personal device?
This isn't worse or different than SSO, which your work should be enforcing anyway.
This isn't worse or different than SSO, which your work should be enforcing anyway.
It's not only having "access to your emails", sometimes these services will send links that are supposed to open in an app and do something there.
... and it just doesn't work.
... and it just doesn't work.
Want to log in on your TV?
Ha. Good luck with that. Your email provider probably only supports Chrome.
Ha. Good luck with that. Your email provider probably only supports Chrome.
I love having my access denied while the email systems delay the email arriving in to my inbox
This is ostensibly what WebAuthn will do. It needs to happen, but retraining users is going to be the difficult bit.
Email is not a secure method of communication.
Email os how all password recovery flows work. So your accounts are generally as secure as your Email.
Nor is SMS. Nor a phone call (even a presumed "landline" can be voip, and that can be hacked too).
Here's the truth ; nothing is "secure".
Now... is email more secure than SMS, or less? What about other 2-factor auth things? Is email secure with 2-factor auth?
Here's the truth ; nothing is "secure".
Now... is email more secure than SMS, or less? What about other 2-factor auth things? Is email secure with 2-factor auth?
And yet it's surprising how many sites allow you to reset a password using nothing but an email link (single factor authentication - and there are already known cases of emails being silently redirected).
Amazon does this! Morons will ask you to "click the link in the sms" to "authorise access". I can understand doing this randomly once or twice, for security. But every single time!? Figured they were doing it for two reasons - data-mining (to figure out what mobile phone and mobile browser yo have, and to leave an Amazon cookie on your mobile browser), and to harass you into installing and using the Amazon app instead of the website. Had to call customer support multiple times before this stopped (who kept urging me to install the Amazon app).
ImprovMX does this just fine
That's crazy! I was reading the article and kept in mind what we did in ImprovMX and was surprised to see we were mentioned in the comment :D
We did, tried something "original" in the login part, by offering a "one time login link" to our users instead of the standard flow. To be honest, we believe this was a bad idea.
The flow in itself is good and works fine (supposing email delivery works), but as @simonw perfectly said it, "resist the temptation to innovate around login!".
Offering that original "one time login link" is a frequent cause of support request because some users doesn't receive it, doesn't know what to do or how. They are not used to a change on login and this causes more troubles down the road than a standard flow.
That's why we later on decided to add the standard "password" login and tried to reverse that original flow. We still have users that have accounts with no password set though (still connecting via the original "one time login link").
We did, tried something "original" in the login part, by offering a "one time login link" to our users instead of the standard flow. To be honest, we believe this was a bad idea.
The flow in itself is good and works fine (supposing email delivery works), but as @simonw perfectly said it, "resist the temptation to innovate around login!".
Offering that original "one time login link" is a frequent cause of support request because some users doesn't receive it, doesn't know what to do or how. They are not used to a change on login and this causes more troubles down the road than a standard flow.
That's why we later on decided to add the standard "password" login and tried to reverse that original flow. We still have users that have accounts with no password set though (still connecting via the original "one time login link").
Obviously a webmaster knows how a sign up form works.
I didn't know the word webmaster still existed
ImprovMX was extremely confusing to me at first.
Checking your email for the login link was confusing?
I hate the email login link stuff, and any site that has it as the only option, I move on unless absolutely forced to use it.
Especially a pain if I'm trying to login on a device without my email.
Especially a pain if I'm trying to login on a device without my email.
You don't need to have email on the device you are logging in from
Can take out phone and click link
Can take out phone and click link
> Can take out phone and click link
That assumes you have that email account on your phone. Also that you have your phone with you, that your phone has signal / wifi, there's no delays, no greylisting, no spam filtering that might catch the email, ...
There's just too many simple ways it can break down for it to be a good system.
That assumes you have that email account on your phone. Also that you have your phone with you, that your phone has signal / wifi, there's no delays, no greylisting, no spam filtering that might catch the email, ...
There's just too many simple ways it can break down for it to be a good system.
Okay, but what if you don't know your password and your password manager is offline or you don't have access to it on your phone or the phone ran out of battery or... I assure you we can find a similar amount of cases where passwords would fail. It's mostly novelty phobia.
We're used to one way of working and have our setups for that. We don't want something different but not because it's worse. It's just different.
And even more, when you have a problem with your password, what do you have to do, yes, email for the most part.
We're used to one way of working and have our setups for that. We don't want something different but not because it's worse. It's just different.
And even more, when you have a problem with your password, what do you have to do, yes, email for the most part.
On at least half of those services, that ends up with me being logged in on my phone which is decidedly not what I want.
Plus I don't know who's using that to help adtech build their cross device mappings
Plus I don't know who's using that to help adtech build their cross device mappings
Some of the ones that doesn’t work - it logs you in on your phone but not the computer you were trying to login on
Email I wanted to use as a login is a totally be a different email than what I wanted to forward to.
It's a decent idea! Slack does this, as does a few other services.
Super typical developer thinking :) two pieces of code look the same but are not doing the same things.
I usually see it when people implement add/edit for some entity, that should be separate forms but are crammed into one to be "DRY".
I usually see it when people implement add/edit for some entity, that should be separate forms but are crammed into one to be "DRY".
This is why views are so nice. You can reuse the view and controller logic and only write a new data model that updates instead of creates (tbh though those can just be two functions on some data model.)
On the contrary, CRUD forms are an ideal candidate for being schema-driven.
PUT versus POST
The standard login/sign up form is broken, though. People will just use the same password across websites or write it down. You can't win
Hopefully this should change over the next few years with both iOS and Android adding support for FIDO Passkeys.
It's not new tech, but now that two huge players have put it in the hands of millions of users, it should pick up speed.
It's not new tech, but now that two huge players have put it in the hands of millions of users, it should pick up speed.
Use a password manager. Problem solved.
I do and tell people to do the same. Unfortunately we can't force people to actually do it.
Unpopular take: users should be free to use bad and insecure passwords for services they don't care about.
That turns all users into a greater threat in the case of any bugs in the server. Makes it easier for the service to get DOS'd by authenticated users, and so on. Allowing on user to be more insecure, makes all users more insecure.
Unfortunately even privileged users (that have authority to change the permissions or possibly passwords of other users) can still use weak passwords.
A better solution would be to have your browser prevent you from reusing passwords (it only needs to keep hashes).
If the web browser is governing the passwords you can and can't have, and forcing you to have unmemorisable passwords, you're better off rethinking the whole thing. For instance, it probably makes more sense to ask the web browser to generate keypairs rather than passwords if we know the passwords cannot possibly be memorised.
I don't reuse passwords, or use a password manager. I just have a system for remembering which password to use for each website, and maintain a list of hints. And I have a pretty terrible memory. But having had the password I used to re-use across a few (non- critical) sites show up on haveibeenpwned it's what works best for me.
\popular take: they shouldn't use services that they don't care about
Firefox is great in that regard: when you fill in a signup form it will automatically suggest you a long, generated password, and will then store it for you.
This is news for me. I've been using a local password manager for ages and disabled any browser form support since maybe the last century so I missed all those new functionalities. I'll keep using my password manager anyway, it's not only for the browser and not only for one device. I sync the db across devices with Syncthing, I don't login into any browser cloud sync.
That is not really unique to Firefox, right? Safari does it as well and I am pretty sure Chrome does it too (I am not a Chrome user, so I can't check).
Password managers are a single point of huge vulnerability.
Unless password managers have a bug bounty of 3m$, then it’s less than the assets I’m protecting with it.
Also, Chrome itself is a password manager.
Unless password managers have a bug bounty of 3m$, then it’s less than the assets I’m protecting with it.
Also, Chrome itself is a password manager.
It’s still better than using the same few passwords everywhere or having a system with the site name. Because you need only on website vulnerability, which is quite common, to compromise your passwords. It’s better to have a single unlikely point of failure than many guaranteed points of failure in my opinion.
Chrome has a password manager but the key is stored for you, which is less secure because it’s not using a HSM (hardware security module) as far as I know.
Chrome has a password manager but the key is stored for you, which is less secure because it’s not using a HSM (hardware security module) as far as I know.
Your single point will be compromised. Someone gets access to your system they now have access to all of your passwords. Your password manager is hacked. Your device dies. Putting your eggs in one basket feels like a smart thing until you lose that basket.
I agree it’s not perfect but what is your better solution? My email and some passwords have been collected at least 8 times according to https://haveibeenpwned.com/
A password manager with multiple factor authentication sounds better to me.
A password manager with multiple factor authentication sounds better to me.
The different email address per service approach fixes that issue and provides additional privacy when your data is sold to bulk data resellers.
My password manager can only decrypt my passwords via my yubikey. What now?
> Also, Chrome itself is a password manager.
Until the day Google locks your Google Account.
Until the day Google locks your Google Account.
This would only break sync and not access to existing passwords at least, unlike most Google services where you'd be totally SOL
I once built exactly what the author proposed and it worked but confused users a lot because they’d have never experienced it before.
There was a lot more leak in the signup funnel as people would just leave once asked to do something besides giving their (usually auto filled) info.
So I tend to believe trying to generally match the flow they are accustomed to is the best way, even if you think it’s not the best way.
There was a lot more leak in the signup funnel as people would just leave once asked to do something besides giving their (usually auto filled) info.
So I tend to believe trying to generally match the flow they are accustomed to is the best way, even if you think it’s not the best way.
> When I've tried to innovate around login in the past I've found that any clever ideas I come up with inevitably run into road blocks pretty quickly.
Either that or you are throwing roadblocks in your user's way. Even if there is no reason for the most common UX to be the way they are, it is what users are used to, and know how to deal with.
Either that or you are throwing roadblocks in your user's way. Even if there is no reason for the most common UX to be the way they are, it is what users are used to, and know how to deal with.
Sounds like a lot of people would accidentally create new accounts.
There is a site I use that does this. I try and use [email protected] as the email for most things I sign up to. Occasionally this gets wonky like the site in question because it was originally a Patreon sub for access so the email for the site was [email protected] then they switched to their own payment system but my email for them is now locked to [email protected].
So when I log in with [email protected] it thinks it's new account and just signs you up as a new user rather than saying you don't have an account.
Now imagine having a bad day and you try and sign in with 5 different emails because you forgot wha one it was and snow you have 5 different "new account" flows with all the bullshit +12+24+48 hour onboarding/retention/marketing emails for all 5 email addresses.
My fault entirely obviously but it is a little mad.
So when I log in with [email protected] it thinks it's new account and just signs you up as a new user rather than saying you don't have an account.
Now imagine having a bad day and you try and sign in with 5 different emails because you forgot wha one it was and snow you have 5 different "new account" flows with all the bullshit +12+24+48 hour onboarding/retention/marketing emails for all 5 email addresses.
My fault entirely obviously but it is a little mad.
People do go back to the signup page a lot. Redirecting them when detecting an existing account from the email is enough in the most common cases.
Users doing "clever" stuff like a random email each time, will also probably understand the situation when they go write down which email for which domain they used and see another entry next to it.
There will be some numbers of users that can't be caught and will create many new accounts, but if thwy use your seevice that much, it will probably stop at one point.
Nothing is foolproof, but there can be many ways to mitigate the issue.
Users doing "clever" stuff like a random email each time, will also probably understand the situation when they go write down which email for which domain they used and see another entry next to it.
There will be some numbers of users that can't be caught and will create many new accounts, but if thwy use your seevice that much, it will probably stop at one point.
Nothing is foolproof, but there can be many ways to mitigate the issue.
For your example, this seems bizarre. Every "sign up" process I can think of ends with you being signed into to your new account. Every "log in" process includes a button or link that says "are you a new user, sign up here". You chose a very streamlined thing to worry about.
I'm not sure. A lot end up sending an email that you need to click on to verify.
That's a step of the signup process. AS this article points out, that link ends up with you back in your browser and logged in. In fact, that's probably the most important reason to bring you back to the browser - so you end in the logged in state and can memorize the password in your browser.
100% agree with you. I've gone through the entire journey of experimenting + building my own authentication to using a reliable open source solution.
Been using this passwordless login recipe by supertokens for my recent projects: https://supertokens.com/docs/passwordless/introduction
Re-inventing the wheel calls for a lot more than usually anticipated. Best to keep it simple - and if you do end up innovating might as well open source it or contribute to an already popular OS solution.
Been using this passwordless login recipe by supertokens for my recent projects: https://supertokens.com/docs/passwordless/introduction
Re-inventing the wheel calls for a lot more than usually anticipated. Best to keep it simple - and if you do end up innovating might as well open source it or contribute to an already popular OS solution.
At the same time, the whole idea of a shared secret instead of asymmetric crypto is source to so many leaks that I wish we would pressure services to not use password-based authentication as their default.
Haha, the mistake I've helped implement thrice. Two forms, always.
Indeed; as soon as the article stated that SPF and DMARC are required, it stopped sounding like a good idea.
Some reasons:
- Not everyone will have set email up on the phone.
- If a laptop is used it adds more complexity if the email is not set up on the device, (or e.g if Gmail is used via a web browser)
- Not everyone will use the Mail app as default and will need to pick the right app
- There may be multiple emails and additional complexity to pick the right 'from' if there are multiple emails being used.
- It is a test of the SMTP server, not the ability to receive email.
- The email needs to match exactly what is being used to sign up when sending the email. With an email inbox [email protected] can be used as an example.
- Not everyone will have set email up on the phone.
- If a laptop is used it adds more complexity if the email is not set up on the device, (or e.g if Gmail is used via a web browser)
- Not everyone will use the Mail app as default and will need to pick the right app
- There may be multiple emails and additional complexity to pick the right 'from' if there are multiple emails being used.
- It is a test of the SMTP server, not the ability to receive email.
- The email needs to match exactly what is being used to sign up when sending the email. With an email inbox [email protected] can be used as an example.
Right: this would fail for me on my laptop, because I use gmail for email and don't have anything setup such that a mailto: link would compose a new email from my gmail account.
It’s actually quite easy to set this up, if you missed doing so when it asks:
https://support.google.com/a/users/answer/9308783?hl=en
https://support.google.com/a/users/answer/9308783?hl=en
Well said. Particularly the point around people not having email set up on an “OS” level. There are a lot of people who already struggle to effectively use modern computers and smartphones, and you’ll run into all kinds of weird edge cases. For example, I previously helped a friend who had just been using the gmail website on their smartphone for years because they had forgot their password but Safaris keychain had saved it so they could auto fill the password.
I’ve encountered countless other scenarios where a user is using software in “non-ideal” way because it works for them or they don’t know any better.
I’ve encountered countless other scenarios where a user is using software in “non-ideal” way because it works for them or they don’t know any better.
I don’t remember the last time I clicked a mailto: link, and probably haven't seen one in a long time. And it’s configured to use the default Windows 10 Mail app, which I don’t use. Can I change it to Firefox and Gmail? Sure, but why would I bother?
> Not everyone will have set email up on the phone.
Exactly. And not everyone accepts HTML E-Mail, i.e. I really hate these "endless" state carrying URLs, which wrap around in my 99 chars wide terminal windows. A short SHA-xxx key should be sufficient, "dear" web form designers.
And last but not least I use greylisting, which still is a useful tool to suppress spam, but delays confirmation emails.
Exactly. And not everyone accepts HTML E-Mail, i.e. I really hate these "endless" state carrying URLs, which wrap around in my 99 chars wide terminal windows. A short SHA-xxx key should be sufficient, "dear" web form designers.
And last but not least I use greylisting, which still is a useful tool to suppress spam, but delays confirmation emails.
Text emails don't have a limited width either. If your email reader and/or terminal app is not able to deal with long URLs then that is really YOUR problem.
Good summary
Using mailto: is just asking for trouble at this day and age.
Using mailto: is just asking for trouble at this day and age.
I... don't particularly get it. He mentions spoofing, he writes a page about how spoofing works... but says a lot less about how it actually impacts his solution or how to fix it.
Besides the fact that implementing a new security scheme means you have to think through every possible path and can be sure you're still missing a few, there are two major issues:
- not everybody has SPF or DKIM, and definitely not everybody has DKIM.
- both of those authenticate the domain, not the username. Within the local org network I can probably spoof email usernames without much effort.
Plus... I don't think mailto links really work universally. I remember the last time I clicked one it opened an unconfigured Outlook, even though I use gmail.
Besides the fact that implementing a new security scheme means you have to think through every possible path and can be sure you're still missing a few, there are two major issues:
- not everybody has SPF or DKIM, and definitely not everybody has DKIM.
- both of those authenticate the domain, not the username. Within the local org network I can probably spoof email usernames without much effort.
Plus... I don't think mailto links really work universally. I remember the last time I clicked one it opened an unconfigured Outlook, even though I use gmail.
Author here. The risk with spoofing is that someone might register an email address that they can't actually send mail from.
You're right that SPF and DKIM are not universal (besides not being strictly for user authentication); this scheme would require a domain to have both in order to be secure and would require some kind of policy attestation around email local parts, which would exclude some email providers and some users. That's why it's "a random idea I had on the subway," and not something I'm doing in production :-)
You're right that SPF and DKIM are not universal (besides not being strictly for user authentication); this scheme would require a domain to have both in order to be secure and would require some kind of policy attestation around email local parts, which would exclude some email providers and some users. That's why it's "a random idea I had on the subway," and not something I'm doing in production :-)
Most sites I sign up using an email that I could, but don’t send email from. I assign per-site emails which all forward to another mailbox that I regularly send mail from.
I could change my client temporarily to send from one of those custom addresses, but I’d have to be quite a bit more interested than usual in your service to bother.
Even users who just have multiple emails in their client would end up sending mail from the default account, which may not match. I have a work account, my personal gmail, my personal domain mail, a family email account, and a side project email account on my phone.
Even if users just have work and personal, how many users are you willing to lose because they sent a mail from the wrong account?
I also think most of the value to the site owner is being able to hit the user with a site->user communication (often an ad or offer of some sort) and me proving I can send you mail from that address is, at a minimum, putting the emphasis on the wrong syllable, and in a lot of cases is telling you nothing about my ability to receive email at that address.
I could change my client temporarily to send from one of those custom addresses, but I’d have to be quite a bit more interested than usual in your service to bother.
Even users who just have multiple emails in their client would end up sending mail from the default account, which may not match. I have a work account, my personal gmail, my personal domain mail, a family email account, and a side project email account on my phone.
Even if users just have work and personal, how many users are you willing to lose because they sent a mail from the wrong account?
I also think most of the value to the site owner is being able to hit the user with a site->user communication (often an ad or offer of some sort) and me proving I can send you mail from that address is, at a minimum, putting the emphasis on the wrong syllable, and in a lot of cases is telling you nothing about my ability to receive email at that address.
This was my first thought. I just have a * rule on my domain hosting account to send all email to my gmail, but can’t actually send from any of those addresses. I’ll usually sign up with [email protected]
SPF and DKIM are universal. The proof is transactional email services. There was a time when they sent emails on behalf of clients. Now, they do it on their own account.
Yeah I don’t get it. Is this the reasoning?
Email is slow to get to me
I use neomutt (there are dozens of us, dozens!) and so links sometimes are wonky.
So let’s use SPF and DMARC, something totally outside of a regular email user’s control, to do this task. And hope that it works.
Email is slow to get to me
I use neomutt (there are dozens of us, dozens!) and so links sometimes are wonky.
So let’s use SPF and DMARC, something totally outside of a regular email user’s control, to do this task. And hope that it works.
> I use neomutt (there are dozens of us, dozens!) and so links sometimes are wonky.
I used neomutt for that one example, but the other error modes happen to me regularly on macOS with the system mail client. For example, I regularly (~1/week) run into services that expect the verification email to be opened in the same browsing session, but Chrome "helpfully" picks a different profile.
(The point about neomutt was not that services should support my particular pathological case, but that graceful degradation is important everywhere. It used to be common to send multipart emails for exactly this case, but I've seen more and more services choose not to.)
I used neomutt for that one example, but the other error modes happen to me regularly on macOS with the system mail client. For example, I regularly (~1/week) run into services that expect the verification email to be opened in the same browsing session, but Chrome "helpfully" picks a different profile.
(The point about neomutt was not that services should support my particular pathological case, but that graceful degradation is important everywhere. It used to be common to send multipart emails for exactly this case, but I've seen more and more services choose not to.)
In my experience, many developers are unaware of multipart email. Most are unaware of MIME or dismiss it as obvious, old and unnecessary.
When opening for the first time, Gmail asks to be registered as the mailto handler, but I guess people just hit "no" not knowing what's that about.
And there's probably a lot of web-based clients that didn't care to implement this, so yeah, if you want to use mailto links, you better have a big and patient customer support team at hand
And there's probably a lot of web-based clients that didn't care to implement this, so yeah, if you want to use mailto links, you better have a big and patient customer support team at hand
Even if all web clients were perfect, and all users understood what a mailto handler is perfectly, wouldn't it still break if people have multiple email addresses? If you have a gmail and a mail from one of Microsoft's mail providers, you can only have one of those webmail pages as your default mailto handler, right?
You can have it ask everytime though i doubt anyone uses it like that (or at all)
> - not everybody has SPF or DKIM, and definitely not everybody has DKIM.
A correctly configured mailserver should reject your email (or mark it as spam) if you don't use both DKIM and SPF. It's safe to assume 99.999% of users use both.
A correctly configured mailserver should reject your email (or mark it as spam) if you don't use both DKIM and SPF. It's safe to assume 99.999% of users use both.
> It's safe to assume 99.999% of users use both [SPF and DKIM].
Tell me you don't have professional experience in email without telling me you don't have professional experience in email.
Tell me you don't have professional experience in email without telling me you don't have professional experience in email.
I have plenty of emails in my inbox that don't use both. I think you're off by several orders of magnitude.
https://dmarcian.com/fortune-100-dmarc-policies/
Around between four and four and a half orders of magnitude for the Fortune 100, with five orders being the maximum possible wrongness.
Around between four and four and a half orders of magnitude for the Fortune 100, with five orders being the maximum possible wrongness.
Some potential problems:
* not everybody has an email client set up that works with mailto: links
* sending from an address and receiving emails for an address are very different, and they don't map 1:1
* If you rely on users sending mail to you, the user doesn't know if / when their email is received and processed. They send the mail, try to login, it doesn't work. They have to wait until it's processed, and then forget about your service. OTOH if they receive a mail from you, the mail in their inbox reminds them that they signed up, and as soon they receive it they can use their account.
* I doubt that DMARC/DKIM/SPF are actually deployed as widely as OP thinks, and excluding users based on some (to them) obscure/unknown feature of their email provider is bound to generate frustration. If they self-host their email, your support might end up debugging / having to help them with their email setup.
* There are some subtleties you have to get right, like verify the MAIL FROM, not the From: header, etc. Email is actually a mine field when it comes to security (it's not specified what should happen if a header is sent twice, so some attackers try to fool virus scanners by finding combinations that the scanner interprets one way, but the recipient interprets another way, etc.) Worse, if a verification fails, it's your responsibility to debug it, and you might have to explain the subtleties to a non-technical user.
* not everybody has an email client set up that works with mailto: links
* sending from an address and receiving emails for an address are very different, and they don't map 1:1
* If you rely on users sending mail to you, the user doesn't know if / when their email is received and processed. They send the mail, try to login, it doesn't work. They have to wait until it's processed, and then forget about your service. OTOH if they receive a mail from you, the mail in their inbox reminds them that they signed up, and as soon they receive it they can use their account.
* I doubt that DMARC/DKIM/SPF are actually deployed as widely as OP thinks, and excluding users based on some (to them) obscure/unknown feature of their email provider is bound to generate frustration. If they self-host their email, your support might end up debugging / having to help them with their email setup.
* There are some subtleties you have to get right, like verify the MAIL FROM, not the From: header, etc. Email is actually a mine field when it comes to security (it's not specified what should happen if a header is sent twice, so some attackers try to fool virus scanners by finding combinations that the scanner interprets one way, but the recipient interprets another way, etc.) Worse, if a verification fails, it's your responsibility to debug it, and you might have to explain the subtleties to a non-technical user.
> not everybody has an email client set up that works with mailto: links
Mostly bad chrome configs where you need to browser plugin to lauch chrome.
>I doubt that DMARC/DKIM/SPF are actually deployed as widely as OP thinks, and excluding users based on some (to them) obscure/unknown feature of their email provider is bound to generate frustration.
We're at about 30% with DMARC and SPF being deployed in about 65% of email servers. That said, a lot of the really big ones (google, MS, etc...) are in the 30% so are a lot of control panel hosts. Where the slow uptake is, as always is corporate IT departments. Doing the whole DMARC/DKIM/SPF dance isn't hard to do and really puts the clamps on spoofing.
Mostly bad chrome configs where you need to browser plugin to lauch chrome.
>I doubt that DMARC/DKIM/SPF are actually deployed as widely as OP thinks, and excluding users based on some (to them) obscure/unknown feature of their email provider is bound to generate frustration.
We're at about 30% with DMARC and SPF being deployed in about 65% of email servers. That said, a lot of the really big ones (google, MS, etc...) are in the 30% so are a lot of control panel hosts. Where the slow uptake is, as always is corporate IT departments. Doing the whole DMARC/DKIM/SPF dance isn't hard to do and really puts the clamps on spoofing.
Ignoring every other benefit and concern, verification in the way proposed is a bad idea because part of the verification process in most cases is verifying that the service can send messages to you that actually get delivered. If you do this and then send the first "log in link" email which gets held up as spam or putatively malicious since some server has the temerity to not be located inside the US, doesn't have a DKIM signature, etc, you haven't really verified everything that you need to know. Of course, those things can change at the drop of a hat anyway, but I'd rather have verified that 1 time than 0 times.
If all you do is use it for login and will never need to send a message, then fair enough, the email is just essentially a random string you can prove ownership of, and your ability to send messages that will be delivered to the corresponding mailbox is incidental. But that's not a general enough conclusion to hold for why "we" (all cases) should do it that way.
If all you do is use it for login and will never need to send a message, then fair enough, the email is just essentially a random string you can prove ownership of, and your ability to send messages that will be delivered to the corresponding mailbox is incidental. But that's not a general enough conclusion to hold for why "we" (all cases) should do it that way.
In most cases, I don’t want the service to send me emails (spam)
That's fair but in a lot of cases you verify the email for your account and there is activity associated with that account. There are many reasons other than to send unwanted marketing emails for the service to need to get in touch with you, including the many cases where you're entering the email address because you want to be notified of something.
Besides the security and usability problems others mentioned, I also highly doubt it will improve confirmation conversions.
One thing that helped us improve confirmations -- we A/B tested it and confirmation rates increased ~8%: send a 4-digit confirmation code rather than just a link.
It's easier and more familiar on mobile, especially if you see the code on the push notification, so don't even need to open the email. I suspect it's less likely to land as a promotion email in Gmail, because of the code/semantics. It's quite a fun experience as well in my opinion. It seems like more work, but entering 4 digits on the same open tab is easier and nicer experience than clicking on an email link.
There are some security considerations. A short code can be brute-forced, so you need to rate-limit the number of guesses.
One thing that helped us improve confirmations -- we A/B tested it and confirmation rates increased ~8%: send a 4-digit confirmation code rather than just a link.
It's easier and more familiar on mobile, especially if you see the code on the push notification, so don't even need to open the email. I suspect it's less likely to land as a promotion email in Gmail, because of the code/semantics. It's quite a fun experience as well in my opinion. It seems like more work, but entering 4 digits on the same open tab is easier and nicer experience than clicking on an email link.
There are some security considerations. A short code can be brute-forced, so you need to rate-limit the number of guesses.
Not having a link in email is important. I believe most of the times email from my systems go to spam because there is a link in it.
I don't have any hard data but I can imagine that if email contains link it will be checked by more rules in heuristic checks. If there are no links - most likely it is not spam.
I don't have any hard data but I can imagine that if email contains link it will be checked by more rules in heuristic checks. If there are no links - most likely it is not spam.
> email from my systems go to spam because there is a link in it.
This spam filter is broken. A personal email with a signature that contains a blog would be a false positive.
This spam filter is broken. A personal email with a signature that contains a blog would be a false positive.
Well that is not a full story.
But if you have a link in an email it will go through couple of other checks for sure, where it might be considered SPAM. If there are no links bunch of checks will be skipped.
That is my reasoning, I am not configuring any spam filters on my own.
But if you have a link in an email it will go through couple of other checks for sure, where it might be considered SPAM. If there are no links bunch of checks will be skipped.
That is my reasoning, I am not configuring any spam filters on my own.
in our case we included both a link and the code and saw an increase in confirmation rates. If I recall we reached over 90% conversion rates. For a B2C niche service, I think that’s pretty high. I somehow doubt removing the link will improve things further, but it might be interesting to test in future.
I've seen similar numbers on an ecommerce site. The theory there was the people may be on a device where their email isn't logged in. So doing that and then clicking your link is a lot of work and could run into even more hurdles like Gmail 2FA popping up because they don't use that device frequently.
While the 4 digit code is easy enough to read on their phone in a notification and then type into the other device.
While the 4 digit code is easy enough to read on their phone in a notification and then type into the other device.
Agreed. Usability on mobile is best with the short codes. Even 2 FA is fairly efficient that way as long as the messages are designed to show the code in the preview.
>send a 4-digit confirmation code rather than just a link.
The wording is unclear, so I will ask for clarification: Does the improved email contain both a 4-digit code _and_ a link (URL)?
The wording is unclear, so I will ask for clarification: Does the improved email contain both a 4-digit code _and_ a link (URL)?
Yes. both a link and the code.
This is not well reasoned. Sending emails can be easily spoofed, because sending doesn't fully check the identity of the sender as being in control of the email account. There is discussion of various technologies like SPF or DKIM, but those are not universally applied. When they are applied, there isn't universal quality in their application.
The crux of verification using an email account is that the person _controls_ the email account. That means the person can receive an email at that account. If the person cannot receive an email at a specific account, that account cannot be used as their identity at the web server.
The crux of verification using an email account is that the person _controls_ the email account. That means the person can receive an email at that account. If the person cannot receive an email at a specific account, that account cannot be used as their identity at the web server.
I'd argue the crux is about proving that Me The Service can send You The User whatever info is needed (password reset, notification of planned downtimes, pricing changes, warnings about service abuse) to this address - and you'll get it.
I don't care about you "controlling" an email address - you can easily get fake ones for free. It's about both parties having agreed _at least once_ on a way for the service to communicate important stuff to you.
I don't care about you "controlling" an email address - you can easily get fake ones for free. It's about both parties having agreed _at least once_ on a way for the service to communicate important stuff to you.
What's a "fake" email address? If you can get emails to an email address then it isn't fake and you are in control of it, at least for the time being
All the various 10-minute-mail services.
Not really fake if you can receive email is it? Maybe disposable is a better word
> It's about both parties having agreed _at least once_ on a way for the service to communicate important stuff to you.
Exactly. And the most important thing is password reset, because users forgetting passwords is the one true constant in the universe. Even if I'm not planning to spam you with newsletter crap, I'm still going to ask for your email just for this reason, otherwise I will get inf support tickets about lost accounts and worse, users who just give up.
It helps thinking of the pw reset flow as the true persistent identity/login and password is simply a shorthand. Magic links have virtually identitical security. With just marginally better end-to-end UX, the majority of users would prefer it. (For instance, note the iOS 2fa through text messages, that automatically scrapes the confirmation code and offers to insert it, without leaving the app).
Exactly. And the most important thing is password reset, because users forgetting passwords is the one true constant in the universe. Even if I'm not planning to spam you with newsletter crap, I'm still going to ask for your email just for this reason, otherwise I will get inf support tickets about lost accounts and worse, users who just give up.
It helps thinking of the pw reset flow as the true persistent identity/login and password is simply a shorthand. Magic links have virtually identitical security. With just marginally better end-to-end UX, the majority of users would prefer it. (For instance, note the iOS 2fa through text messages, that automatically scrapes the confirmation code and offers to insert it, without leaving the app).
With this method, it seems to me the entire user registration information would be in your Sent folder. So forgetting the password should be more difficult. Though you would still need to reset a password.
[deleted]
Ownership over the email shortname is exactly what is being proven. It’s your identity as far as the service is concerned. I can block emails from a service right after verifying so verifying does not guarantee that I will receive emails from the service at any point in the future.
If you do block it, your access to the account you’ve created might be in jeopardy. At least it depends on how you “block” it. If the service receives an error on future emails, the user’s account can be disabled, as usually described in the TOS.
> This is not well reasoned. Sending emails can be easily spoofed, because sending doesn't fully check the identity of the sender as being in control of the email account. There is discussion of various technologies like SPF or DKIM, but those are not universally applied. When they are applied, there isn't universal quality in their application.
I bring up both of these at the end of the post, under "potential limitations." I'm very aware that SPF/DKIM don't do identity authentication, and that they're not universally applied!
This post is best read as a random thought, not an exhortation or formal argument. It says as much in the first sentence.
I bring up both of these at the end of the post, under "potential limitations." I'm very aware that SPF/DKIM don't do identity authentication, and that they're not universally applied!
This post is best read as a random thought, not an exhortation or formal argument. It says as much in the first sentence.
Got it!
Everyone should be able to express their thoughts.
Everyone should be able to express their thoughts.
I would hate this, and probably instantly bail out of any flow that tried to force it on me.
Being able to receive mail on an address should not necessarily imply a capability to send from it. This scheme rules out many actual or potential schemes for email anonymity, especially in a world where very little email is still transactional relatively speaking.
I do not give (almost) any website an address I send normal email from, nor do I want to. And my default configured client for mailto:, if I even have one on the device I'm using, is not going to be set to the single use mail I want to sign up with.
Being able to receive mail on an address should not necessarily imply a capability to send from it. This scheme rules out many actual or potential schemes for email anonymity, especially in a world where very little email is still transactional relatively speaking.
I do not give (almost) any website an address I send normal email from, nor do I want to. And my default configured client for mailto:, if I even have one on the device I'm using, is not going to be set to the single use mail I want to sign up with.
$Work does not allow outgoing (out of domain) emails but *Requires* signup to a bunch of websites for stuff like provident fund management and stock compensation. This kind of workflow is not possible for those cases
They are exchanging inconvenience for lack of functionality
They are exchanging inconvenience for lack of functionality
>…and here it is in neomutt, which helpfully “renders” the HTML with lynx:
>…
>But that’s a solution born from practice: the fact remains that HTML email doesn’t generally degrade gracefully in clients that don’t support images or CSS.
I hope that companies don’t waste their time at such edge cases that are irrelevant for 99.9% of users such as Lynx graceful degradation. It reminds me of the stories about clients that want their website to look nice in IE6.
>…
>But that’s a solution born from practice: the fact remains that HTML email doesn’t generally degrade gracefully in clients that don’t support images or CSS.
I hope that companies don’t waste their time at such edge cases that are irrelevant for 99.9% of users such as Lynx graceful degradation. It reminds me of the stories about clients that want their website to look nice in IE6.
Multi-part MIME emails with both plain text and HTML content used to be a standard[1] or at least a good and common practice. Not including plain text version or making it "can't see newsletter? click here for web article" is an ongoing process of moving users from unsnoopable email to invigilated web. It's invisible to dumbed-down users, possibly saves corpos some money: devs can learn something that benefits business more and, depending on email volume, business may decrease spending a bit by removing few kilobytes of text from each message sent.
Imo a standard of sorts, being removed due to lack of knowledge or for money (savings on data transfer or profit from data gained from users reading "web version of email" and email clients loading remote content) doesn't make it an "edge case". The edge case here (necessity to parse and read HTML in pure email client) is an effect of businesses and developers not following standards in the first place.
Also, IE6 overstayed its welcome not due to edge user cases but due to corporate savings as well.
[1] https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1
Imo a standard of sorts, being removed due to lack of knowledge or for money (savings on data transfer or profit from data gained from users reading "web version of email" and email clients loading remote content) doesn't make it an "edge case". The edge case here (necessity to parse and read HTML in pure email client) is an effect of businesses and developers not following standards in the first place.
Also, IE6 overstayed its welcome not due to edge user cases but due to corporate savings as well.
[1] https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1
Yep. I read this and thought PEBKAC. Optimise for the base case, be inclusive of those using screen readers, ignore the masochists who insist on making life difficult for themselves by refusing to use technologies that have been around for decades. The author's other issue - multiple browser sessions open and logged in to different accounts and tabs opening in the last active one - this is a more common annoyance. But easily solved by the user making sure they are in the right browser session by focussing it. So PEBKAC again.
I'll say as the PEBKAC'd author: I try to remember to focus the right browser session! But I still load the wrong one about once a week, and whether it works with a particular site is a crapshoot.
Without weighing in on this, I think this entire section is a distraction in this post. The author's point in this article would be better served by moving the HTML rant to its own blog post.
If company can't be bothered to learn how to send email properly, their email will just go to trash, thank you. :)
Things like:
- sending empty plaintext part or differnt content in plaintext part and html parts within multipart/alternative subparts (https://www.freesoft.org/CIE/RFC/1521/18.htm) - pretty much only some automated/marketing email is guilty of this. normal senders always get it right
- sending 5 line uncopiable tracking link in plain text (links should be shorter than 80 chars, to not annoy anyone trying to copy paste them)
- sending broken html just because it maybe renders some insane table layout in outlook 97 from 50 years ago more "nicely"
Things like:
- sending empty plaintext part or differnt content in plaintext part and html parts within multipart/alternative subparts (https://www.freesoft.org/CIE/RFC/1521/18.htm) - pretty much only some automated/marketing email is guilty of this. normal senders always get it right
- sending 5 line uncopiable tracking link in plain text (links should be shorter than 80 chars, to not annoy anyone trying to copy paste them)
- sending broken html just because it maybe renders some insane table layout in outlook 97 from 50 years ago more "nicely"
Well there was a time when IE6 compatibility did matter
The whole point of email verification is to verify that the user is able to receive email at the given address. Aside from the other issues mentioned here, the proposed solution does not achieve this.
I can't think of anything I've signed up for that would care about the distinction personally, any examples?
I use email aliases that I can't send email from. It's also possible that email from your domain is blocked by mine, and I would never receive that invoice or password reset link. In reverse, there are addresses on my company's domain I can send from but not receive at, and I shouldn't be allowed to sign up with those.
I have *@kayode.co forwarded to [email protected].
I can only send from [email protected] and only if I configured my mail client properly because my account is actually a fastmail.com address. Unconfigured, the mail client will send as the fastmail account.
I can only send from [email protected] and only if I configured my mail client properly because my account is actually a fastmail.com address. Unconfigured, the mail client will send as the fastmail account.
The ‘mailto:’ thing is a dealbreaker.
A _significant_ amount of users, especially non-technical ones, won’t have a properly configured email client. They’ll click signup, it’ll open Outlook or Apple Mail, and then they’ll give up on your app in frustration because they can’t register.
There’s very limited room for shifting the signup paradigm in a way that won’t leave N% of your potential users unable to sign up.
A _significant_ amount of users, especially non-technical ones, won’t have a properly configured email client. They’ll click signup, it’ll open Outlook or Apple Mail, and then they’ll give up on your app in frustration because they can’t register.
There’s very limited room for shifting the signup paradigm in a way that won’t leave N% of your potential users unable to sign up.
I think this is the big one. On iOS, I don’t think most non-technical users know how to switch their default mobile Mail client if they use another alternative like Gmail or Outlook.
> In both cases, the proof is the same: “email verification” means “the user controls an email address.”
No. In one case the proof is "the user receives E-Mails under this address" and in the other it is "the user can send E-Mails under this address".
The service is generally interested in proving the first. For recovery, service-related notifications and for unsolicited marketing. So all the things mentioned in making the "normal" flow undesirable, are actually exactly what the service owner wants to protect against. If their E-Mails don't get to you because they end up in spam or just get dropped by a misconfigured Mailserver, they can't spam you and you won't be able to use this account for recovery.
I agree that the reverse flow is easier (though TBF, mailto links also require the user to have set them up to work, which not all users have on all their devices). But I don't think that's where the incentives align.
No. In one case the proof is "the user receives E-Mails under this address" and in the other it is "the user can send E-Mails under this address".
The service is generally interested in proving the first. For recovery, service-related notifications and for unsolicited marketing. So all the things mentioned in making the "normal" flow undesirable, are actually exactly what the service owner wants to protect against. If their E-Mails don't get to you because they end up in spam or just get dropped by a misconfigured Mailserver, they can't spam you and you won't be able to use this account for recovery.
I agree that the reverse flow is easier (though TBF, mailto links also require the user to have set them up to work, which not all users have on all their devices). But I don't think that's where the incentives align.
1. Attacker goes to website, initiates signup up for an account
2. Website generates mail link for attacker to send
3. Attacker uses mail link to spoof email
4. Account is opened for the attacker using email address
This attack is impossible if the website sends a verification email to the user's inbox which only the person who controls the inbox has access to.
Hence, while the proposed method is interesting, it exposes the user to an unnecessary attack vector.
The article has a section on security where they address the problem you describe and several others. Do you find their reasoning unsound?
Yes I do find them unsound. Now you need ordinary people to understand the pros and cons of DMARC (SPF + DKIM). Not every one has this configured. In fact it's shocking how many companies don't have DMARC set up given the benefits.
If major providers such as Gmail/Microsoft/etc agreed to require DMARC for all incoming email senders, then maybe 5 years later we could speak about this again because then DMARC would be universally used.
If major providers such as Gmail/Microsoft/etc agreed to require DMARC for all incoming email senders, then maybe 5 years later we could speak about this again because then DMARC would be universally used.
As an example: AWS has no DMARC on its SES domain, and its SES domain is what sends SES emails from by default. Anyone who's not using a custom domain with SES, has no way for anyone to validate where that email came from. All CloudWatch alerts come via the generic SES domain, so there is literally no way to tell if a CloudWatch alert is spoofed or not.
I'm really surprised no hackers have started sending out phishes via spoofed CloudWatch alerts yet. I guess it takes a while for them to capitalize on industrial vulnerabilities.
I'm really surprised no hackers have started sending out phishes via spoofed CloudWatch alerts yet. I guess it takes a while for them to capitalize on industrial vulnerabilities.
Yes. 1) DKIM, SPF and DMARC do not prevent spoofing, they simply make it less easy. A compromise of those methods, or an attack on DNS or BGP, or any other novel spoofing attack, gives the attacker a successful attack vector that would not exist if the website simply sent the user an email to verify. 2) The unique token and timeout is simply given to the attacker when the attacker initiates the new account/password reset form, it has no bearing whatsoever on security.
> or an attack on DNS or BGP, or any other novel spoofing attack
Even though it’s be relevant form as systems-thinking point of view, it’s pretty unfair to dismiss a solution because it will be vulnerable to very important pieces of Internet network infrastructure. I think it’s safe to say that if we get a sufficiently bad vulnerability in DNS or BGP, account confirmation emails are going to be least of our worries.
Additionally “any novel spoofing attack” is a very hand-wavy, low effort way to dismiss it as well.
Even though it’s be relevant form as systems-thinking point of view, it’s pretty unfair to dismiss a solution because it will be vulnerable to very important pieces of Internet network infrastructure. I think it’s safe to say that if we get a sufficiently bad vulnerability in DNS or BGP, account confirmation emails are going to be least of our worries.
Additionally “any novel spoofing attack” is a very hand-wavy, low effort way to dismiss it as well.
It's not unfair to point out a design as needlessly insecure. Regardless of the method, this design adds a new attack vector (email spoofing) that did not exist before. Even if it was very hard to do, it's an unnecessary added risk.
The same attacks can likely also be used to capture verification emails. E.g. for DNS if you can spoof TXT records for Gmail using some malicious server, chances are you can also spoof MX records. And I can't think of shenanigans with BGP that allow you sending spoofed emails that pass DKIM, SPF and DMARC (ultimately routing traffic to your malicious server again), but not allow capturing of mails.
I think the suggested flow is a valid idea to discuss, even though at the end of the day it's still a bad idea (others have formulated a lot of valid criticism that I agree with). But I find your criticism to be unfair, as it also applies to the traditional flow and should rather be a reason not to use email at all (begging the question: What secure alternative should be used?).
I think the suggested flow is a valid idea to discuss, even though at the end of the day it's still a bad idea (others have formulated a lot of valid criticism that I agree with). But I find your criticism to be unfair, as it also applies to the traditional flow and should rather be a reason not to use email at all (begging the question: What secure alternative should be used?).
Having to tell an ordinary user that their domain didn't configure DKIM properly so sign up didn't work and they now have to go through an alternate flow sounds like a nightmare. The article does not mention what to do with the many users who don't already have the mentioned security mechanisms, just that they are "commonly deployed".
Can you explain (3)?
The attacker just sends an email that they got from the target server's "mailto" link. They just have to use a spoofing method when they do. Such as:
1. If the target website doesn't validate DKIM/SPF/DMARC, the spoof works. 2. If the target website (or source domain) has a flaw in its DKIM/SPF/DMARC configuration, the spoof works. 3. If the attacker can use a DNS or BGP attack on A) the nameserver of the source, B) the resolver of the target, C) any intermediary, etc, then the spoof works. 4. If the attacker develops a novel spoofing attack, the spoof works.
It's less a question of "how" than "when". A defender has to be successful every time in a myriad different ways; an attacker only has to be successful once. Removing an attack vector is always better than having to defend against it.
1. If the target website doesn't validate DKIM/SPF/DMARC, the spoof works. 2. If the target website (or source domain) has a flaw in its DKIM/SPF/DMARC configuration, the spoof works. 3. If the attacker can use a DNS or BGP attack on A) the nameserver of the source, B) the resolver of the target, C) any intermediary, etc, then the spoof works. 4. If the attacker develops a novel spoofing attack, the spoof works.
It's less a question of "how" than "when". A defender has to be successful every time in a myriad different ways; an attacker only has to be successful once. Removing an attack vector is always better than having to defend against it.
This suggestion makes things worse.
If you make a service and ask for email validation, you want validation that the user has that email address. Since anyone can spoof e-mails from any address, getting an email from the address is not validation for anything.
You need to send an email to the account and get a response to validate the email address is real. Otherwise it's trivial for me to go to any web site and pose as you. All I would need to do is spoof your email address.
Edit: I agree that the current state of affairs is unsatisfactory :-)
If you make a service and ask for email validation, you want validation that the user has that email address. Since anyone can spoof e-mails from any address, getting an email from the address is not validation for anything.
You need to send an email to the account and get a response to validate the email address is real. Otherwise it's trivial for me to go to any web site and pose as you. All I would need to do is spoof your email address.
Edit: I agree that the current state of affairs is unsatisfactory :-)
So instead of an HTTP syncronous POST request, you want to trade it for a brittle implementation of a to-be-implemented-standard that requires the sending email client to be on point? And that I will wait while my outgoing email server isn't delayed?
And what if I use my ISP provided email, and move? Am I just locked out of accounts?
I appreciate the thought process of rethinking our assumptions. But this is not fruitful - the tradeoffs are trivially obvious and unacceptable failure modes.
And what if I use my ISP provided email, and move? Am I just locked out of accounts?
I appreciate the thought process of rethinking our assumptions. But this is not fruitful - the tradeoffs are trivially obvious and unacceptable failure modes.
This isn’t better. I don’t have a default mail client and a lot of people don’t. You could open up the browser page to login but by the time you’re logged in all context is lost and you won’t get the pre setup outgoing mail ready to click send.
This is quite wrong. The purpose of e-mail verification is to validate that the user creating the account controls the specified e-mail; that he or she can receive at that address.
This author has created a silly flow whereby the user proves that they are somehow able to use e-mail to reflect back some authorization cookie to the server. You can do that without even having an e-mail address; any Internet-connected host can send e-mail, using any sending identity it wishes. The fact that you can contact my server via HTTPS and via SMTP, and relay some information between the two, means absolutely fiddlesticks.
> The “reverse” flow should make intuitive sense: we’re proving that the user controls the specified email address by challenging them to send us an email from it.
Right; here is the core misconception on the part of the author: that receiving an e-mail from someone proves that they control a certain e-mail address. (Imagine the flow being used for password recovery, yikes! Anyone forging an e-mail from you gets your account?)
The second problem with this idea is that it increases the server complexity. Now it has to process e-mail. Conventional e-mail validation doesn't have to receive e-mail; all it does is send confirmation mails. Which, I repeat, any Internet-connected host can do; and it can do so without becoming a mail server.
A third problem is user experience. It complicates things for the user. The handling of mailto: URLs is tenuous. Not everyone has it set up correctly. Many users have some webmail account like Gmail, but when they click on some mailto: URL, some default application comes up that doesn't use their Gmail account. They don't use that application and are prompted to set up that application.
This author has created a silly flow whereby the user proves that they are somehow able to use e-mail to reflect back some authorization cookie to the server. You can do that without even having an e-mail address; any Internet-connected host can send e-mail, using any sending identity it wishes. The fact that you can contact my server via HTTPS and via SMTP, and relay some information between the two, means absolutely fiddlesticks.
> The “reverse” flow should make intuitive sense: we’re proving that the user controls the specified email address by challenging them to send us an email from it.
Right; here is the core misconception on the part of the author: that receiving an e-mail from someone proves that they control a certain e-mail address. (Imagine the flow being used for password recovery, yikes! Anyone forging an e-mail from you gets your account?)
The second problem with this idea is that it increases the server complexity. Now it has to process e-mail. Conventional e-mail validation doesn't have to receive e-mail; all it does is send confirmation mails. Which, I repeat, any Internet-connected host can do; and it can do so without becoming a mail server.
A third problem is user experience. It complicates things for the user. The handling of mailto: URLs is tenuous. Not everyone has it set up correctly. Many users have some webmail account like Gmail, but when they click on some mailto: URL, some default application comes up that doesn't use their Gmail account. They don't use that application and are prompted to set up that application.
I like that there's still options out there around authentication that I haven't seen before but this method is hostile towards folks without a dedicated email client. Personally I only ever login through web mail and have no client so `mailto` isn't a shortcut.
I still think magic links are a good compromise. With a user / pass you still need to verify your email as a separate step. A magic link sends you an email and you're technically verifying your email every time you use it, so it removes an extra step.
It's also really useful for being able to login from multiple devices without needing to keep your password synced with a multi-device password manager. That's especially handy on mobile because even if you're around your desktop with your password manager who the heck wants to manually type `pm'TWZS"$G39c(Es:k@v3-*IhP#DUbows:=='"Z],Ud"R8XO` as a password into your mobile phone?
Lastly, it lets you put the burden of MFA on your email account. If your email account is protected by MFA then your app using magic links is protected by MFA. It means users don't need to give out their phone number or hook up another site to their authenticator app.
I really don't understand why so many folks hate magic links. They solve a number of problems in a pretty reasonable way at the cost of having to wait 5 seconds for 1 email to verify your email at which point the site can set a cookie for a year and you don't have to deal with logging in by email for another year.
You can also protect sensitive actions by requiring folks to verify their email to replicate how a site might ask for your password to do something like change billing details or whatever makes sense for your app.
I still think magic links are a good compromise. With a user / pass you still need to verify your email as a separate step. A magic link sends you an email and you're technically verifying your email every time you use it, so it removes an extra step.
It's also really useful for being able to login from multiple devices without needing to keep your password synced with a multi-device password manager. That's especially handy on mobile because even if you're around your desktop with your password manager who the heck wants to manually type `pm'TWZS"$G39c(Es:k@v3-*IhP#DUbows:=='"Z],Ud"R8XO` as a password into your mobile phone?
Lastly, it lets you put the burden of MFA on your email account. If your email account is protected by MFA then your app using magic links is protected by MFA. It means users don't need to give out their phone number or hook up another site to their authenticator app.
I really don't understand why so many folks hate magic links. They solve a number of problems in a pretty reasonable way at the cost of having to wait 5 seconds for 1 email to verify your email at which point the site can set a cookie for a year and you don't have to deal with logging in by email for another year.
You can also protect sensitive actions by requiring folks to verify their email to replicate how a site might ask for your password to do something like change billing details or whatever makes sense for your app.
Magic Links mean that if there is any issue with any of the email servers in the chain (which there often are), my ability to log in to the website may be delayed by 10, 20, maybe even 30 minutes.
It’s unacceptable and everyone I know who uses magic link has eventually given up on them due to user unfamiliarity and a variety of issues such as this one.
It’s unacceptable and everyone I know who uses magic link has eventually given up on them due to user unfamiliarity and a variety of issues such as this one.
> Magic Links mean that if there is any issue with any of the email servers in the chain (which there often are), my ability to log in to the website may be delayed by 10, 20, maybe even 30 minutes.
This same exact thing happens with a username and password driven site because almost all sites (rightfully) require you to confirm your account after sign up by clicking a link in your email.
This same exact thing happens with a username and password driven site because almost all sites (rightfully) require you to confirm your account after sign up by clicking a link in your email.
With magic links it happens every single login. Confirmation email only needs to be done once per email. I thought this was obvious?
And most websites don’t require confirmation email to log in, they require it to unlock certain features.
And most websites don’t require confirmation email to log in, they require it to unlock certain features.
> With magic links it happens every single login. Confirmation email only needs to be done once per email. I thought this was obvious?
You don't have to do it on every single login. Check my previous reply's comment:
> I really don't understand why so many folks hate magic links. They solve a number of problems in a pretty reasonable way at the cost of having to wait 5 seconds for 1 email to verify your email at which point the site can set a cookie for a year and you don't have to deal with logging in by email for another year.
There's nothing "magic" about magic links and "remember me". You still read this information from a session and can optionally look up the details from an encrypted and signed cookie (or Redis / Memcached / whatever session back-end) with a user ID which then loads a user from your DB on the back-end. It's the same exact workflow as a user / pass strategy.
You don't have to do it on every single login. Check my previous reply's comment:
> I really don't understand why so many folks hate magic links. They solve a number of problems in a pretty reasonable way at the cost of having to wait 5 seconds for 1 email to verify your email at which point the site can set a cookie for a year and you don't have to deal with logging in by email for another year.
There's nothing "magic" about magic links and "remember me". You still read this information from a session and can optionally look up the details from an encrypted and signed cookie (or Redis / Memcached / whatever session back-end) with a user ID which then loads a user from your DB on the back-end. It's the same exact workflow as a user / pass strategy.
"Logging in" typically refers to the situation where you don't have the cookie and need to get it. Having the cookie is typically referred to as "being logged in" already.
> "Logging in" typically refers to the situation where you don't have the cookie and need to get it.
Right, and after you click the link in your email to login then your back-end will set a cookie so that when you close your browser and come back again you will be logged in without needing to receive another link your email for however long you want "remember me" to be available.
The person I was replying to said the difference with magic links is you need to check your email every time you login. Especially with his "obvious" remark, it made it seem like he didn't realize you could use magic links and only login once a year just like you could use a password and only login once a year thanks to cookies working the same with both methods.
Right, and after you click the link in your email to login then your back-end will set a cookie so that when you close your browser and come back again you will be logged in without needing to receive another link your email for however long you want "remember me" to be available.
The person I was replying to said the difference with magic links is you need to check your email every time you login. Especially with his "obvious" remark, it made it seem like he didn't realize you could use magic links and only login once a year just like you could use a password and only login once a year thanks to cookies working the same with both methods.
Dude, you're describing logging in.
If I don't have cookies, I have to receive that email again, and it introduces a large amount of failure points EVERY SINGLE TIME this login happens. Instead of just once, on account verification.
Seriously, I've built enough apps that require email verification to know how much of a failure point that email verification is, and it's a significant draw on onboarding when email guarantees are required early on. Doing it every single login (= every new device, every new incognito session, every now and then when the user clears their cache, every time they switch browser, every time they log in from a new computer, etc etc) is insanity, and again, everyone I know who uses magic link has given up on them, or made them extremely optional.
If I don't have cookies, I have to receive that email again, and it introduces a large amount of failure points EVERY SINGLE TIME this login happens. Instead of just once, on account verification.
Seriously, I've built enough apps that require email verification to know how much of a failure point that email verification is, and it's a significant draw on onboarding when email guarantees are required early on. Doing it every single login (= every new device, every new incognito session, every now and then when the user clears their cache, every time they switch browser, every time they log in from a new computer, etc etc) is insanity, and again, everyone I know who uses magic link has given up on them, or made them extremely optional.
We must use computers much differently.
I don't login from new computers often, I have my personal machine and mobile phone. It's great to be able to login from a phone without needing a password manager or manually typing a 50 character randomly generated password where I need to be sitting in front of my main computer to even login. If you really have that many computers you'd still need to sync a password manager between all of them to login with a password.
I also don't browse with incognito mode on sites where I'm expected to be logged in unless I have multiple accounts that I want to have logged in simultaneously.
I also don't routinely switch browsers and if I do I only have to login once per browser and I'm done for a year or however long the site saves it for.
That doesn't sound like insanity to me? I didn't even think about them while writing my original reply because they are such outlier events.
I don't login from new computers often, I have my personal machine and mobile phone. It's great to be able to login from a phone without needing a password manager or manually typing a 50 character randomly generated password where I need to be sitting in front of my main computer to even login. If you really have that many computers you'd still need to sync a password manager between all of them to login with a password.
I also don't browse with incognito mode on sites where I'm expected to be logged in unless I have multiple accounts that I want to have logged in simultaneously.
I also don't routinely switch browsers and if I do I only have to login once per browser and I'm done for a year or however long the site saves it for.
That doesn't sound like insanity to me? I didn't even think about them while writing my original reply because they are such outlier events.
Great, you're one user who likes magic links. It doesn't matter how you (nor I, for that matter) use magic links, the majority of users dislike them for the reasons I highlighted.
When building a site/service/ui/whatever, you take into account the needs of your users, not your own needs exclusively.
You asked: "I really don't understand why so many folks hate magic links." - I responded with an explanation.
When building a site/service/ui/whatever, you take into account the needs of your users, not your own needs exclusively.
You asked: "I really don't understand why so many folks hate magic links." - I responded with an explanation.
I actually tried something similar to this on a small social networking service about 5 years ago. There was a requirement for people to interact with their groups via email by replying to other emails or by sending a message to an email address for the group.
For both of these, I made the case that we should require the incoming emails to pass either a domain aligned SPF or domain aligned DKIM check (essentially what DMARC would do).
Since most people are going to be using a 3rd party email service, this just works by default. If they aren't, we shouldn't have any issue with forcing this requirement as it meets absolute basic email standards.
The higher ups let me do it and we ended up creating an instructional email that would bounce back to failed messages with the reason why, an explanation that we couldn't risk someone being impersonated on the platform and a suggestion that they use the app or website to interact until the issue could be resolved.
In the short time that I was there after that feature launched, we never ran into a problem.
For both of these, I made the case that we should require the incoming emails to pass either a domain aligned SPF or domain aligned DKIM check (essentially what DMARC would do).
Since most people are going to be using a 3rd party email service, this just works by default. If they aren't, we shouldn't have any issue with forcing this requirement as it meets absolute basic email standards.
The higher ups let me do it and we ended up creating an instructional email that would bounce back to failed messages with the reason why, an explanation that we couldn't risk someone being impersonated on the platform and a suggestion that they use the app or website to interact until the issue could be resolved.
In the short time that I was there after that feature launched, we never ran into a problem.
How many users will abandon at the first mailto link?
My guess: 95%
My guess: 95%
That whole article could have have been two sentences. Also the problem with it is obvious: not all users have a email client configured. Back in 98 I used to get confused when I clicked an email link and windows would spend ages trying to open up some program called Outlook up!
I see two problems with the proposal
1. Part of the reason for doing e-mail verification the old way is to ensure the user can really receive messages at the particular address, for purposes such as password reset or e-mail notifications in the future. The proposed novel verification flow only verifies that the user can *send* e-mails, not receive.
2. My phone is configured with multiple mail accounts. I don’t remember whether you can reliably hint at the mail client to use a particular mail account via a mailto link."fewer opportunities for the user to make mistakes"
Really?
Really?
Fewer users, fewer opportunities.
Yes. Please, learn from my fail.
For all my service sign-ups, I use [service-name]@[mydomain] as my email which redirects to my GMail inbox. My sending address is still my GMail.
How will this solution tackle the given situation?
How will this solution tackle the given situation?
Email verification is more than just verifying the user owns an email, it also improves the chances future emails will be received successfully.
Before smartphones in Japan, this is how mobile websites did signups. Every phone had an email address and you verified it by sending a blank email via a mailto link. Restaurants and Karaoke places had QR codes on their menus for this.
Seems like this practice died out when messaging apps (LINE) displaced mobile email. I thought it was kind of cool but managing spam filters was a pain.
Seems like this practice died out when messaging apps (LINE) displaced mobile email. I thought it was kind of cool but managing spam filters was a pain.
Why this methods was popular is because it's hard for user to input their own (and correct!) email address. Mailto link is far easier way to tell the valid email address to a service. Perhaps now is OAuth/OIDC era.
I've had family members fall prey to phishing scams. I would be concerned if legitimate sites trained their users to send odd content to odd addresses as part of normal net usage. How can an ordinary person understand the difference between sending a token to real.com and sending a threat to another user on behalf of fake.com?
The massive inconveniences others have pointed aside, it will be a technical nightmare to implement too. Incoming email takes a _lot_ of moving parts to process. What could have been a simple http get/post/redirect forms now need a process to accept and parse incoming emails, and someone inform the page about verification status. There are plenty of existing libraries and software to do it, but it's really difficult to get right.
Incoming emails in qprint, plain and html emails with boundaries, spoofed emails, separating verification emails from regular emails, etc there are so many complexities involved. In addition, it is difficult to write unit tests for them, and integration tests wouldn't be solid either.
All of these technical complexities to beat a paradigm that billions of users are used to, with no obvious improvement.
Incoming emails in qprint, plain and html emails with boundaries, spoofed emails, separating verification emails from regular emails, etc there are so many complexities involved. In addition, it is difficult to write unit tests for them, and integration tests wouldn't be solid either.
All of these technical complexities to beat a paradigm that billions of users are used to, with no obvious improvement.
> I’ve repeatedly dealt with services where the verification email [...] is marked as spam
Spam filtering in email is performed on the receiving side. You're the recipient, so if your spam filter is filtering emails you want, it's your spam filter that is defective and you are the only one who can solve that.
Spam filtering in email is performed on the receiving side. You're the recipient, so if your spam filter is filtering emails you want, it's your spam filter that is defective and you are the only one who can solve that.
This is simultaneously true and not useful: most people use an email provider, and the provider dictates the spam policy. Aggressive policies are competitive, because spam annoys users more than the occasional missed message.
> spam annoys users more than the occasional missed message.
For me it's the other way around. I don't care about occasional spam. But the possibility of missing message means that I'm forced to read ALL spam periodically.
For me it's the other way around. I don't care about occasional spam. But the possibility of missing message means that I'm forced to read ALL spam periodically.
I think there's a paradox here: I also don't care about occasional spam, and the possibility of missing messages matters much more to me. But I probably wouldn't select an email provider with no spam protections at all, and Google is optimizing for new user registrations.
That's at least debatable, I send SPF failures to spam, which obviously catches some legitimate stuff, but at very least that's the sender's problem too.
In general, you don't verify am email address to prove that the user owns it, but to verify they can receive mail on it, for password recovery purposes and account information. Reversing the process verifies the user can send from the address, which is orthogonal to the goal
A lot of email clients support multiple email accounts, or at least sending addresses. Not just desktop ones like Thunderbird, but web ones like Gmail too.
You can additionally set up email to be forwarded (or retrieved). So, for example, you can easily have your [email protected] account forwarded in to Gmail and Gmail set up to send from that address.
That works fine if the site sends a confirmation email, it'll get to Gmail where the user expects to read it. But the other way around will give the user errors about having the wrong email (even if tj user picks the right outgoing address, because you won't be able to verify it), and ultimately cause the user to give up or you're going to have to spend a lot of time supporting all kinds of weird email configs.
You can additionally set up email to be forwarded (or retrieved). So, for example, you can easily have your [email protected] account forwarded in to Gmail and Gmail set up to send from that address.
That works fine if the site sends a confirmation email, it'll get to Gmail where the user expects to read it. But the other way around will give the user errors about having the wrong email (even if tj user picks the right outgoing address, because you won't be able to verify it), and ultimately cause the user to give up or you're going to have to spend a lot of time supporting all kinds of weird email configs.
Why do we do email verification at all?
The only legit and practical reason on most web sites is to be able to restore access if you forgot the password.
So just near the password field we can have a "Restore options" section, with email, phone number, etc fields; each having a Test button.
If user have entered email address he can use the Test button and receive a confirmation email, with a link. When user clicks the link, we mark the email as confirmed in DB.
Also, as long as the user does not have a [tested] restore option, we can show him some indicator, like a small red circle on his profile symbol with a tooltip "no restore option configured".
Doing the test email in reverse for me personally would be annoying, because I do not have and do not want to have a configured email client.
The only legit and practical reason on most web sites is to be able to restore access if you forgot the password.
So just near the password field we can have a "Restore options" section, with email, phone number, etc fields; each having a Test button.
If user have entered email address he can use the Test button and receive a confirmation email, with a link. When user clicks the link, we mark the email as confirmed in DB.
Also, as long as the user does not have a [tested] restore option, we can show him some indicator, like a small red circle on his profile symbol with a tooltip "no restore option configured".
Doing the test email in reverse for me personally would be annoying, because I do not have and do not want to have a configured email client.
Most webapps have a need for transactional messaging of some sort. But even putting that aside you’re missing TOS support. Every TOS is going to have conditions that define scenarios where you need to communicate with users. Including changes to the terms of service ;-). Or for breaches of data, you’ll want/contractually need to communicate that to your users.
So yeah you could build different options for all of these things, and maybe snailmail users of these TOS occasions. But the system of doing this over email is so standardized that the possible friction of one-time setup pails in comparison to the alternatives.
So yeah you could build different options for all of these things, and maybe snailmail users of these TOS occasions. But the system of doing this over email is so standardized that the possible friction of one-time setup pails in comparison to the alternatives.
Good point about TOS, that's indeed an important use case. However usually TOS declare that it is a responsibility of the user to keep up with changes. Good service providers also say they will make a reasonable effort to inform the user about the changes. So the TOS update notifications is not a complete blocker for my approach.
What do you mean by transactional messaging? Could you give an example?
What do you mean by transactional messaging? Could you give an example?
Non-marketing emails from the company to push information to you while you’re out of the app. Think stuff like:
1. receipt / shipping notifications from an online shop 2. emails from enterprise chat apps that let you know you’ve missed messages 3. “Suspicious login” or similar notifications 4. prompts about billing if credit card is nearing expiration or a problem charging your account
1. receipt / shipping notifications from an online shop 2. emails from enterprise chat apps that let you know you’ve missed messages 3. “Suspicious login” or similar notifications 4. prompts about billing if credit card is nearing expiration or a problem charging your account
Thank you
Many sites I work with use email to communicate information to a user that would otherwise require them to remain on the site to receive such notifications. Email forms an essential part of the workflow so ensuring that process works from first contact is critical.
I’ve had similar issues of not receiving emails before and it’s annoying especially if you’re trying to do password resets.
I like the idea the author is taking about although I’m not too techie with all the details.
If I tried this “reverse” approach I would do it this way,
After the user creates their account, simply generate a unique token and tell the user to simply copy the token and send it back to a specific email address controlled by me with the token as the subject line and the body is ignored.
This way the user sends the unique code from the email address they want to use so we know it’s them cause how else would they get the unique token.
Is it 100% fool-proof? No. But most things humans touch is not secured 100% anyways but I’d like to think it’s a start.
I like the idea the author is taking about although I’m not too techie with all the details.
If I tried this “reverse” approach I would do it this way,
After the user creates their account, simply generate a unique token and tell the user to simply copy the token and send it back to a specific email address controlled by me with the token as the subject line and the body is ignored.
This way the user sends the unique code from the email address they want to use so we know it’s them cause how else would they get the unique token.
Is it 100% fool-proof? No. But most things humans touch is not secured 100% anyways but I’d like to think it’s a start.
I've had situations where some email clients (including Outlook) would visit URLs in emails, for "link protection" purposes.
Coupled with the magic-link approach (including a token in the URL that authenticates the user), this can cause a lot of problems.
Coupled with the magic-link approach (including a token in the URL that authenticates the user), this can cause a lot of problems.
Apple Mail does this by default now too.
At a high level, you have to validate what you need. If you don't need the user's email address, don't validate it. If you need an address the user can send from, validate that they can send from it. If you need an address they can receive at, validate that they can receive on it.
Beyond security problems, there can be all kinds of other failure modes. Maybe my domain is blocking email from you. Maybe the address I want to use can't send.
If you need the address because you'll be sending password resets and invoices to it, you want to validate that they can receive there. It was never about whether they "own an email account", whatever that means.
Beyond security problems, there can be all kinds of other failure modes. Maybe my domain is blocking email from you. Maybe the address I want to use can't send.
If you need the address because you'll be sending password resets and invoices to it, you want to validate that they can receive there. It was never about whether they "own an email account", whatever that means.
This is actually a very good idea. I'm gonna start implementing it on my sites. If you want your account verified, just email the site with anything or nothing at all. Thanks for the idea! Email verification is a nightmare.
It's a nice idea, and I don't think it needs DKIM either, just SPF? (If the token in the body was maliciously changed to the correct value.. they're too short? All that matters is whether it's correct or not?)
But I suppose there'd be many legitimate SPF fails - I see them on email from companies all the time, like they followed half the instructions to bring their own domain to MS/Gmail, and stopped when it 'worked'. OP sounds like the mailto link is going to somehow include SPF & DKIM configuration to solve that? I don't get that bit.
But I suppose there'd be many legitimate SPF fails - I see them on email from companies all the time, like they followed half the instructions to bring their own domain to MS/Gmail, and stopped when it 'worked'. OP sounds like the mailto link is going to somehow include SPF & DKIM configuration to solve that? I don't get that bit.
OP here. I think you're right that SPF is all that's strictly required; DKIM is technically just "nice to have," since all we need is envelope authenticity + the shared secret.
You're also right about SPF (and DKIM) fails, which is why this really isn't all that practical -- it's too easy to misconfigure both and both "fail open," meaning that any service that actually does email verification this way would either need to accept the risk of spoofing from non-major email providers or perform strict SPF/DKIM enforcement (e.g. rejecting email from domains with open IP ranges, even if the domain says it's okay). And that's very hard to do in the general case.
You're also right about SPF (and DKIM) fails, which is why this really isn't all that practical -- it's too easy to misconfigure both and both "fail open," meaning that any service that actually does email verification this way would either need to accept the risk of spoofing from non-major email providers or perform strict SPF/DKIM enforcement (e.g. rejecting email from domains with open IP ranges, even if the domain says it's okay). And that's very hard to do in the general case.
My domain's SPF says "email from sendgrid is allowed", which allows anyone with a sendgrid account to spoof me.
I didn't set up DKIM because I don't particularly care about the security of that particular domain. But the point is that you can't know how secure the domain is just because it has some security feature present like SPF.
I didn't set up DKIM because I don't particularly care about the security of that particular domain. But the point is that you can't know how secure the domain is just because it has some security feature present like SPF.
On a related note, when users want to connect with me I use a mailto link instead of a web form. This is because after someone fills out a webform, I have to email them, and my email is not-infrequently marked as spam (even though we send <1 email/year to our email list, and are not remotely spammy in general).
When the user clicks the mailto link, he starts a message chain and my reply almost always goes through appropriately.
As others have pointed out, there are some downsides to mailto links. But I find them to be outweighed by the deliverability benefit that I've seen.
When the user clicks the mailto link, he starts a message chain and my reply almost always goes through appropriately.
As others have pointed out, there are some downsides to mailto links. But I find them to be outweighed by the deliverability benefit that I've seen.
Email links also lets the person choose the client they prefer, instead of a box in a browser tab.
My e-mail client saves my message as a draft as I type, so I can finish my message slowly without fear of losing my progress.
I also know that my email client works. Many web forms are broken and only reveal that once you hit submit, if at all.
My e-mail client saves my message as a draft as I type, so I can finish my message slowly without fear of losing my progress.
I also know that my email client works. Many web forms are broken and only reveal that once you hit submit, if at all.
Because most people have aliases to signup
Either [email protected] or [email protected].
For instance, I used admin@, devops@, invoice@, etc. in the places I worked. Each of them includes multiple users (leadership chain and the team)
Either [email protected] or [email protected].
For instance, I used admin@, devops@, invoice@, etc. in the places I worked. Each of them includes multiple users (leadership chain and the team)
This doesn't work for creation because it's too easy to spoof where the email came from.
In the OP's diagram this really hinges on the Mail Transfer Agent (MTA) needs the ability to verify that Mail User Agent (MUA) is legit, and that is quite hard.
Realistically MTA would need to go to a known MUA address to verify do you actually own this account?
But not all is lost!
This does work great for 2FA. Where the contents itself is is the only requirement of trust. Just make the contents unrealistic to copy/spoof and then it doesn't matter who sent it.
In the OP's diagram this really hinges on the Mail Transfer Agent (MTA) needs the ability to verify that Mail User Agent (MUA) is legit, and that is quite hard.
Realistically MTA would need to go to a known MUA address to verify do you actually own this account?
But not all is lost!
This does work great for 2FA. Where the contents itself is is the only requirement of trust. Just make the contents unrealistic to copy/spoof and then it doesn't matter who sent it.
I don't understand why people complain about the mailto: option.
Whichever after or before, people will need to open up their mailbox to have access to their newly created account, no matter what, so it does not change anything.
The account creation page could easily provide a plain text email as an option, copy/paste the address, copy paste the code you've been given to send and off you go. Or it could provide both options. Link clicking and mailto.
Not great but else you can configure mailto:handling on any browser/OS
Whichever after or before, people will need to open up their mailbox to have access to their newly created account, no matter what, so it does not change anything.
The account creation page could easily provide a plain text email as an option, copy/paste the address, copy paste the code you've been given to send and off you go. Or it could provide both options. Link clicking and mailto.
Not great but else you can configure mailto:handling on any browser/OS
I think that complexity is the #1 problem here. This is a clever way to confirm user emails, but it's also inviting additional universes of bugs and confusion to the party.
For me the answer is a simple question:
Would the author (or anyone here) be happy to support the proposed reverse email verification process in a production environment which interfaces with the general public? For the sake of forcing the argument, assume the service being accessed is Really Important and failure is generally unacceptable.
For me the answer is a simple question:
Would the author (or anyone here) be happy to support the proposed reverse email verification process in a production environment which interfaces with the general public? For the sake of forcing the argument, assume the service being accessed is Really Important and failure is generally unacceptable.
Another way to authenticate email is to provide your email address and password.
This has the advantage that you do not need to receive or send an email.
There may be downsides as well, but I cannot think of any ;-)
This has the advantage that you do not need to receive or send an email.
There may be downsides as well, but I cannot think of any ;-)
Or use OpenID Connect.
That also has the problem of making your identity dependent on a third party, unless the site accepts Self-Issued identities, which is an interesting extension to OIDC:
https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...
https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...
[deleted]
I don't know what mailto links would open on my computer but it's not my web-based email client. I think it opens a local executable that came installed by the OS? I don't even know what email address that thing is tied to.
DKIM et. al. security concerns aside, I don't think a mailto link will be easier to use because the web server doesn't control the user's configured handler for mailto links and there's a lot of ways for that link to go unhappy.
DKIM et. al. security concerns aside, I don't think a mailto link will be easier to use because the web server doesn't control the user's configured handler for mailto links and there's a lot of ways for that link to go unhappy.
Author does not understand how many clueless people are there. Setting up an account is allreqdy a problem for a lot of people (both old and young people can be very non technical). This new system will often not work on a personal computer - those often dont have a configured mail client. All is done via web.
Also I can easily see this abused by tons of spamers, where every spam website will have a mailto: popup trying to catch inexperienced users - to reveal their emails.
Also I can easily see this abused by tons of spamers, where every spam website will have a mailto: popup trying to catch inexperienced users - to reveal their emails.
I run a product using email verification that's currently failing in all the ways on the list
I chose it because it's less complex than oauth, and (slightly, in theory) more convenient than user-password.
My wishlist version of oauth is for a slightly different protocol that 1) doesn't require the product to create an account with the id provider, 2) doesn't allow the id provider to block sites, 3) doesn't let the id provider see where the user is logging in
I chose it because it's less complex than oauth, and (slightly, in theory) more convenient than user-password.
My wishlist version of oauth is for a slightly different protocol that 1) doesn't require the product to create an account with the id provider, 2) doesn't allow the id provider to block sites, 3) doesn't let the id provider see where the user is logging in
We’re (fx.gl) using it in all our games to create a connection between game account and email. It works great. User click on mail to link. Send email with uniq token. Sever receives email and connection is created.
Some caveats:
1. not everyone has email set up on phone. We provide instructions to send email by hand.
2. We emphasize for user to choose correct email if they using work and personal email. No good solution here if user connect game account to work email. Only letter to support
Some caveats:
1. not everyone has email set up on phone. We provide instructions to send email by hand.
2. We emphasize for user to choose correct email if they using work and personal email. No good solution here if user connect game account to work email. Only letter to support
I personally like the scheme. But I think it caters to the technologically capable, in particular the “compose an email with this bit of magically secure content” skill.
However, these services have to accommodate the technologically less capable. So the degenerate reduction to basically “ok, we’re going to do this the hard/easy way. You just have to click where we tell you to. It’s kinda tedious, but just push the singular buttons we tell you to.”
However, these services have to accommodate the technologically less capable. So the degenerate reduction to basically “ok, we’re going to do this the hard/easy way. You just have to click where we tell you to. It’s kinda tedious, but just push the singular buttons we tell you to.”
The scheme supposes mailto: scheme works (by web browser starting MUA after click to mailto: scheme link). I cannot imagine that is true for majority of people. Perhaps it worked in the past where people used real MUA application, and such MUA is configured as default handled for mailto: in their OS, but today when people mostly use web-based MUA and browser/OS has no idea about it, i would expect it mostly does not work.
It does work. Gmail has been popular enough for long enough that everyone makes sure this works.
The proposed solution breaks down when you're trying to register with an alias that you can't send from. For example, I share an alias with my wife that we use for shared logins, shared notifications, etc. The burden of helping her be able to send from that address is sufficiently high that I would likely pass on any service that transitioned to this mode of operation.
[deleted]
Getting Gmail to support "verify" in the same way as it supports unsubscribe will make 99% of these problems go away
I think this is a good idea ONLY as a fallback. Email deliverability is a very real problem even if it happens to only 1% out of 99% of your users. What happens when a customer emails saying they can't verify their account because they didn't receive any email? It'd be quite seamless to offer this as a secondary option.
When you get an email without DKIM or SPF, how do you explain to them that they need to change to a supported email provider even though yes you did receive the requested sign-up email?
So having built a few services that offer a signup, it's typically simple to make the service _send_ emails and receive the token through the browser for validation. It's all synchronous with actions that the user initiates. To build something like this you'd need an email inbox, which services typically don't have.
This ignores many of the main reasons why an application does email verification - to improve chances that the user is not a robot, that the stack is setup correctly, that the user actually can receive and open email, and that the user is who they claim they are.
It's not "just" to verify that this user controls the email address.
It's not "just" to verify that this user controls the email address.
[deleted]
…because spoofing the “From:” of an email is an order of magnitude easier than intercepting who it was sent “To:”.
I like this idea of reverse email verification. I have a gmail account that I have long since abandoned due to other people signing up for accounts and using my address. If they actually had to send an email from the address to sign up then I probably wouldn't have abandoned my address as quickly.
I like the idea but instead of mailto which I find annoying why not simply ask the user to send us an email with a hello message? The email address we provide can be unique per sign up if required.
So no copy pasting of codes, or having a specific format of the email. We just need to check the sender and recipient.
So no copy pasting of codes, or having a specific format of the email. We just need to check the sender and recipient.
Without a code, there is a pretty high risk of an attacker social engineering an account holder into sending an email.
I haven't really thought this through (what an attacker would gain), just want to point out the general risk.
I haven't really thought this through (what an attacker would gain), just want to point out the general risk.
One decent argument not made: this would avoid “spam” reaching people’s inboxes from people trying to sign up with emails they don’t own.
As the owner of a very common [initial][last name]@gmail.com address, I’d take the trade off, but this might be even more niche than neomutt users.
As the owner of a very common [initial][last name]@gmail.com address, I’d take the trade off, but this might be even more niche than neomutt users.
A bit off-topic: kudos to OP for clearly explaining DKIM, SPF and DMARC. Awesome short summary!
The flow diagrams leave out the "treat the account as verified and start sending messages anyway" that lots of companies do.
Then you ask them to remove your email address from some other persons account and instead they delete the account. Fun times.
Then you ask them to remove your email address from some other persons account and instead they delete the account. Fun times.
Side question: how do you deal with authentication/registration for small projects? Doing it myself sounds like a lot of work. But alternative services are either expensive or don't give users good privacy. What do you guys use?
Huh, just like he’s had multiple browser sessions open - I have multiple email accounts and don’t want to send this reverse verification email from my client… I also don’t want my full signature shared. The reverse way is way worse for me.
What’s doing the verification of the email on the server side? How does this service associate the email with the account? Specifically, what could be put in the email header or body by the MUA that is equivalent to a single use auth token?
Ugh. For me, mailto link will open… some old forgotten mail application, that will start downloading… 5000 e-mails from my gmail account? or something? and mark them as read? maybe?
I don’t really know, honestly. I always copy-paste mailto links to Gmail.
I don’t really know, honestly. I always copy-paste mailto links to Gmail.
Seems like a bizarrely convoluted solution in search of a problem. Sending a verification email and clicking on a link in it works perfectly well for 99.99% of users. This new method increases friction by several orders of magnitude.
This argument is silly. How many people are using text-based e-mail clients who are also using etsy?
And the article also ignores the problems with the mailto:// link. cmon. The solution likely has more issues than the problem it solves.
And the article also ignores the problems with the mailto:// link. cmon. The solution likely has more issues than the problem it solves.
Why do we even need email verification?
I don't want to allow a website to link my identity to my email address or phone number.
I don't want the website to push me messages.
I am capable of storing passwords, so no need to send me password recovery emails.
Email verification should be optional.
I don't want to allow a website to link my identity to my email address or phone number.
I don't want the website to push me messages.
I am capable of storing passwords, so no need to send me password recovery emails.
Email verification should be optional.
> I am capable of storing passwords, so no need to send me password recovery emails.
Maybe you are, maybe you aren't. As the website's operator, I don't want to manually have to go back-and-forth with everyone who forgets their password to try and verify their identity through their past activity etc.
Making it optional for the people who won't forget is fine, there's no way to know who that will be though. And if your password manager fail you'll be here on HN pointing out how I made a website with not a single fallback mechanism to get back in your account. Why would anyone do that?
Maybe you are, maybe you aren't. As the website's operator, I don't want to manually have to go back-and-forth with everyone who forgets their password to try and verify their identity through their past activity etc.
Making it optional for the people who won't forget is fine, there's no way to know who that will be though. And if your password manager fail you'll be here on HN pointing out how I made a website with not a single fallback mechanism to get back in your account. Why would anyone do that?
> if your password manager fail you'll be here on HN pointing out how I made a website with not a single fallback mechanism to get back in your account.
That's why I said:
> Email verification should be optional.
That's why I said:
> Email verification should be optional.
Because services don't want to be spammed with fake accounts.
Reddit, Instagram and Twitter all require emails, and they're some of the most spamful services I have seen. HN requires nothing but a unique name and associated password, and if there's a lot of bots here then I guess they're running really sophisticated NLP.
Now of course, HN is more domain specific and niche than other socials so I know it's a bit unfair to compare spam because of course spammers would be more interested in the more populous and general purpose social media, and it's possible that spam and bots on those other services would be even higher if not for email registration, but there's simply no data to support that : email registration is cargo-culted by any remotely user-oriented service without thinking if it fits.
And there is a very good reason to think that email registration is just a dumb lazy hack to delegate problems instead of solving them : come to think of it, email fights spam! How do they do it, by delegating to another email service? Email registration all the way down? Of course not, they just run a bunch of really simple stats on the text to reject the obvious 99% trash. Are reddit and twitter too poor to pay for markov chains running on every text submitted?
Now of course, HN is more domain specific and niche than other socials so I know it's a bit unfair to compare spam because of course spammers would be more interested in the more populous and general purpose social media, and it's possible that spam and bots on those other services would be even higher if not for email registration, but there's simply no data to support that : email registration is cargo-culted by any remotely user-oriented service without thinking if it fits.
And there is a very good reason to think that email registration is just a dumb lazy hack to delegate problems instead of solving them : come to think of it, email fights spam! How do they do it, by delegating to another email service? Email registration all the way down? Of course not, they just run a bunch of really simple stats on the text to reject the obvious 99% trash. Are reddit and twitter too poor to pay for markov chains running on every text submitted?
Creating fake emails is easy. Rent VPS for $5, set up postfix and you have infinite number of emails.
Could you be more precise about what you mean by "fake" accounts?
One person making multiple accounts to abuse the service. For example by spamming it.
Professional spammers probably would know how to set up fake email addresses.
You underestimate the number of people who are bad and technically incompetent.
Such basic things can stop a lot of idiots.
I guess you still lock your house even if proffessioanal thieves can pick your locks. 99% of thieves are not proffessional.
Such basic things can stop a lot of idiots.
I guess you still lock your house even if proffessioanal thieves can pick your locks. 99% of thieves are not proffessional.
> I guess you still lock your house even if proffessioanal thieves can pick your locks.
No. I'm hoping that lock-makers work with professionals who do pentesting on locks.
No. I'm hoping that lock-makers work with professionals who do pentesting on locks.
Or, like I wrote on the Go+ community back in 2014, and what Microsoft does, you don't have to remember a password, but every time you have to log in a "password" mail is sent.
So the verification process isn't necessary anymore.
So the verification process isn't necessary anymore.
We don't do it in reverse because sender addresses are fairly trivial to spoof? What email verification proves is your ability to read email (which means password possession), which is much harder to fake.
I A/B tested this exact flow at my last employer, and it lost. I didn’t follow up with user interviews or surveys, but my guess is people were creeped out by their email client opening out of nowhere.
This is something I hadn’t considered! I could definitely see that spooking less technical users.
We send temporary passwords by email. So we reach two goals:
1. User can Login immediately
2. User email is automatically verified because if the email is invalid, he never receives the temporary password
I go to website, get mailto link for my work email and send it from my personal email. Then I sit there and wait because there are lots of indeterminate third parties on the way sending my mail on.
Oh, the "curse" got this individual too.
"Is it a good idea?
I have no idea;"
Great, why the article then?
"Is it a good idea?
I have no idea;"
Great, why the article then?
Most users have more than 1 email id, some may multiple email apps, in those cases, more work for the user, else it is a 2 click process, 1 for clicking the notification and another for the link.
Because using one mail adress per service with catch-all would not work.
For all the reasons mentioned here, and some the author wavy-hands away, this is a bad idea.
None the less, I learned more about email spoofing from this article then from any other, so it's a nice read.
None the less, I learned more about email spoofing from this article then from any other, so it's a nice read.
> Plaintext alternatives are the solution, but support is spotty.
Very few people use plaintext email clients. According to campaign monitor [1] 67% of users are using graphical email clients.
> Takeaway: Inbox delivery can be fickle, unreliable, or outright impossible.
The proposed solution to use `mailto:` is also fickle. Users may not have their email client setup or the right client configured in the browser.
Also what about users with multiple email accounts setup on the email client. Those users will need to remember to select the desired from email.
[1] https://www.campaignmonitor.com/resources/guides/most-popula...
Very few people use plaintext email clients. According to campaign monitor [1] 67% of users are using graphical email clients.
> Takeaway: Inbox delivery can be fickle, unreliable, or outright impossible.
The proposed solution to use `mailto:` is also fickle. Users may not have their email client setup or the right client configured in the browser.
Also what about users with multiple email accounts setup on the email client. Those users will need to remember to select the desired from email.
[1] https://www.campaignmonitor.com/resources/guides/most-popula...
There are probably two sampling errors here: users with accessibility requirements (such as screen readers) might not represented in the survey, and "graphical email clients" run a wide range of functionality (including very, very broken HTML and CSS rendering).
Even if 2/3rds of users run a graphical email client, that's still 1 out of every 3 who don't. That's a lot!
I agree about `mailto:` and multiple accounts having poor UX, however. It'd be nice if there was some way to specify the "intended" outgoing email identity via `mailto:`, but I don't know if that's possible.
Even if 2/3rds of users run a graphical email client, that's still 1 out of every 3 who don't. That's a lot!
I agree about `mailto:` and multiple accounts having poor UX, however. It'd be nice if there was some way to specify the "intended" outgoing email identity via `mailto:`, but I don't know if that's possible.
> According to campaign monitor [1] 67% of users are using graphical email clients.
That same site also says: "Create a plain text version of your email."
That same site also says: "Create a plain text version of your email."
Yes in the context of some people don't want html. I would like to know how big that "some people" population is. I suspect it is high in academic/hacker news populations. But from experience most people outside of IT don't know what "plain text" is. I would like to find a source (preferably from one of the big email marketing service providers) that has a detailed breakdown of the clients used.
This would cause so many issues in a time when most users use webmail. The magic link in email works, why change it for 0.001% of you users who happen to use a command based email program.
Has anyone simply tried NOT using any email verification? Sure there will be a Low % of mis-keyed or fake emails.. but it does remove a HUGE wall and reduces TimeToFirstAppExperience.
Why we do email verification ?
Is a burocratic vestige no one need or asked for.
Is a burocratic vestige no one need or asked for.
Thanks to a certain person named "Sam" in Florida I know that the following companies do not do email verification (and do not have an automated way to fix it with a "I did not sign up with this address" link):
Domino's Pizza; Tinder (they at least sent a verification email, but it was a smokescreen); Match.com; Pinterest; Judicial Watch, Inc.; Straight Talk Wireless; Wayfair; Kellogg's
and many many more.
People sign up with other people's email addresses all the time. In error, or on purpose.
Domino's Pizza; Tinder (they at least sent a verification email, but it was a smokescreen); Match.com; Pinterest; Judicial Watch, Inc.; Straight Talk Wireless; Wayfair; Kellogg's
and many many more.
People sign up with other people's email addresses all the time. In error, or on purpose.
Throwing it out there:
does anyone know where I can find a copy-pastable template for Spring Boot to integrate a classic sign-up workflow in my web app.
I hate to reinvent the wheel here...
does anyone know where I can find a copy-pastable template for Spring Boot to integrate a classic sign-up workflow in my web app.
I hate to reinvent the wheel here...
How about not requiring an email address from the user in the first place?
Give them the option to enter an email address with a "test" button next to it.
Give them the option to enter an email address with a "test" button next to it.
a common account registration pattern in Japan involves presenting a QR code containing a mailto link. The user scans it, sends an empty mail (the details for the subject are already in the mailto link) and a reply comes up with a temporary user. The user can then define a username or password. Sometimes this pattern creates the username and password randomly.
Sounds like a good idea to explore. Glad to hear some new ideas on these kind of flows that usually never get any improvement.
And hope there is a human for anything that doesn’t match. People will remember that email and use that to contact support.
I use email addresses that only forward mails to my real address, so I can't use them as a sender email address
Seems to me like a made up problem. Are there issues with transactional e-mail delivery, just change your provider.
mailto:links for most people just open up some associated email client which they never used before and which isn’t associated with their email account (which they check via a web page like gmail).
So mailto: is a non starter. A standard that just doesn’t do what a developer might think it does.
So mailto: is a non starter. A standard that just doesn’t do what a developer might think it does.
The obvious reason might be that email verification might be done on a different device.
I'm late to the party but I think we cannot let the client know the secret token
> Is it a good idea?
No, because email forwarding is a thing and many people use it
No, because email forwarding is a thing and many people use it
There are essentially no applications that require email. We should just stop doing email verification altogether. If you need to have a separate communication channel with your user just establish that separately after signup.
Password resets. People forget their passwords all the time, and you don't want to deal with support emails and explain that they should have set an email in their security settings, so now they can't get back their their Twitter/Discord/Facebook account and there's nothing you can do (or will do).
I have a catchall. Sending mails is a bit annoying...
I like not having to send a mail because I can easily avoid spam if someone misuses or sells my information because GDPR only hits small people and not the corps that deserve it. While yes, it may be slightly more annoying to create accounts, maybe that is a good thing. Because then you don't create an account at every possible site.
> opens up your email client
What the fuck?
What the fuck?
I'm very skeptical of relying on every random domain on the internet setting up SPF/DKIM properly to the point it's trustworthy in this way. I can't find stats on usage of `~all` (soft fail) but only an abysmal 6.4% of .com domains have `-all` (hardfail) [0].
Another major issue I'd personally run into is usage of catch-all addressing [1] (and same issue with plus-addressing [2]). I use a unique email address for every site I sign up to, but I don't easily have the capability to send "from" those addresses. It's not that it's hard to do, but it's enough effort that I'd not bother signing up at all.
> The user is more active: instead of waiting to receive an email in their inbox, the user is immediately presented with an email to send. They can make progress in the flow themselves [...] Even if the flows take roughly the same amount of wall time, this activity makes the “reverse” flow feel faster and more responsive.
Respectfully disagree with this assertion. Users are used to emails taking some time to arrive. I think delays in this flow will feel like your verification service is broken.
> Completing the flow is equivalent to proving that you control an email address
Not exactly. It proves the IP you send from is authorized to send mail for the domain, according to the SPF record setup by the domain owner. It doesn't prove it's your individual email address, and it doesn't prove you can ever receive mail to it.
> The user has fewer opportunities to make mistakes: Users frequently mis-copy verification links, or use clients that mangle them, &c. These mistakes can’t happen in the “reverse” flow, because there’s no verification link to click. The user only has to remember how to send an email, which is a reasonable expectation in any scheme where the user is expected to have an email address.
Except the mailto: link contains a verification code, and thus is subject to exactly the same problems?
IMHO this is better solved by just not doing bad verification URLs.
Bad: https://auth1.web04.example.org/app/1042/verify.php?action=e...
Good: https://example.org/verify/BC44-5204
> The user’s mistakes are easier to detect
If you send the verification email at the beginning of account creation you can avoid them going too far.
If that's a barrier to your sign-up flow, provide some useful options. Eg: after they still haven't verified, ask "Still haven't got the verification email? It was sent to [email protected], but you can click here to modify it".
[0] https://spf-all.com/by-tld.html
[1] https://news.ycombinator.com/item?id=19333901
[2] https://en.wikipedia.org/wiki/Email_address#Subaddressing
Another major issue I'd personally run into is usage of catch-all addressing [1] (and same issue with plus-addressing [2]). I use a unique email address for every site I sign up to, but I don't easily have the capability to send "from" those addresses. It's not that it's hard to do, but it's enough effort that I'd not bother signing up at all.
> The user is more active: instead of waiting to receive an email in their inbox, the user is immediately presented with an email to send. They can make progress in the flow themselves [...] Even if the flows take roughly the same amount of wall time, this activity makes the “reverse” flow feel faster and more responsive.
Respectfully disagree with this assertion. Users are used to emails taking some time to arrive. I think delays in this flow will feel like your verification service is broken.
> Completing the flow is equivalent to proving that you control an email address
Not exactly. It proves the IP you send from is authorized to send mail for the domain, according to the SPF record setup by the domain owner. It doesn't prove it's your individual email address, and it doesn't prove you can ever receive mail to it.
> The user has fewer opportunities to make mistakes: Users frequently mis-copy verification links, or use clients that mangle them, &c. These mistakes can’t happen in the “reverse” flow, because there’s no verification link to click. The user only has to remember how to send an email, which is a reasonable expectation in any scheme where the user is expected to have an email address.
Except the mailto: link contains a verification code, and thus is subject to exactly the same problems?
IMHO this is better solved by just not doing bad verification URLs.
Bad: https://auth1.web04.example.org/app/1042/verify.php?action=e...
Good: https://example.org/verify/BC44-5204
> The user’s mistakes are easier to detect
If you send the verification email at the beginning of account creation you can avoid them going too far.
If that's a barrier to your sign-up flow, provide some useful options. Eg: after they still haven't verified, ask "Still haven't got the verification email? It was sent to [email protected], but you can click here to modify it".
[0] https://spf-all.com/by-tld.html
[1] https://news.ycombinator.com/item?id=19333901
[2] https://en.wikipedia.org/wiki/Email_address#Subaddressing
Guys,it's 2022! You shouldn't be requires to give out your email right along for verifying anything. Please allow the old dog to die.
Site generated communication should be entirely optional, and even then why not support signal,whatsapp, slack,discord,etc... (as a library of course).
Fight spam? Use captchas.
What I found out is email registration is very difficult without a phone number which in turn requires a government ID in most places. So email verification has become a lazy way to require govenment IDs for even the most basic sites.
It is all built around user hostility. I have added items to a cart,tried to check out and then decided to cancel the whole thing because they have no guest(no-email) check out and require email registration several times this year. Why would they not just take my money? My payment itself is verficiation of anything email can verify?
It is so stupid! Imagine being asked for your phone number and then they call your phone to verify it at every store or business you went to in person.
I challenge any commercial site owner to prove that email registration improves their botrom line.
For non-commercial sites, please understand that you are being needlessly hostile to your visitors, use federated authentication and provide a no-email registration path.
Personally, I think registration itself is outdated. You want users to buy something or generate content on your site. You can still call it registration if you want but you don't need to do more than the bare minimum of authentication which when federated can mean not storing anything new or special about the user other than their login session and associate their content with the identities associated with that session. For example, if HN with github federated, this post and my submissions would be under my GH identity in HN's db, if I want to setup a HN profile, that too would be under that identity. Unless you have a specific need for it, there wouldn't be a table of users with my identity in it.
Lastly, for those that use email as part of an authentication workflow: understand that the use's email security is now your responsibility, because even though you transfered risk lack of options means you are responsible for mandating email as point of failure. So if a user gets phished and damage is done on your site, your site is liable unless you are also providing email security training. There is a reason secret questions exist (although I don't like them), you are not suppose to allow control over an email account as the only factor of authentication requires to reset login credentials. The whole 2FA setup is meaningless if you do that.
Site generated communication should be entirely optional, and even then why not support signal,whatsapp, slack,discord,etc... (as a library of course).
Fight spam? Use captchas.
What I found out is email registration is very difficult without a phone number which in turn requires a government ID in most places. So email verification has become a lazy way to require govenment IDs for even the most basic sites.
It is all built around user hostility. I have added items to a cart,tried to check out and then decided to cancel the whole thing because they have no guest(no-email) check out and require email registration several times this year. Why would they not just take my money? My payment itself is verficiation of anything email can verify?
It is so stupid! Imagine being asked for your phone number and then they call your phone to verify it at every store or business you went to in person.
I challenge any commercial site owner to prove that email registration improves their botrom line.
For non-commercial sites, please understand that you are being needlessly hostile to your visitors, use federated authentication and provide a no-email registration path.
Personally, I think registration itself is outdated. You want users to buy something or generate content on your site. You can still call it registration if you want but you don't need to do more than the bare minimum of authentication which when federated can mean not storing anything new or special about the user other than their login session and associate their content with the identities associated with that session. For example, if HN with github federated, this post and my submissions would be under my GH identity in HN's db, if I want to setup a HN profile, that too would be under that identity. Unless you have a specific need for it, there wouldn't be a table of users with my identity in it.
Lastly, for those that use email as part of an authentication workflow: understand that the use's email security is now your responsibility, because even though you transfered risk lack of options means you are responsible for mandating email as point of failure. So if a user gets phished and damage is done on your site, your site is liable unless you are also providing email security training. There is a reason secret questions exist (although I don't like them), you are not suppose to allow control over an email account as the only factor of authentication requires to reset login credentials. The whole 2FA setup is meaningless if you do that.
People forget their passwords. If you do more than sell stuff one time and the user really need to get their account back, you need a way to send them a reset link or code. No way around it.
Only if you or the user refuse to use federated auth. And even then do you not have 2FA? Then your 2FA is reduced to 1FA by email?
"There is no way around it" is such b.s., yes there is, pretend email does not exist, how would you do it? I think you skipped over parts of my post, there is a myriad of messaging applications if you insist control over some external account is the way to go. But really, the ideal way to do this would be have two sets of registration time challenges set. You can go with secret questions but also picture/emoji combinations, pins,patterns as the firsr piece and a second would either be a payment card for $0.01 charge or have them print one-time codes at registration time (second challenge skipped if second-factor auth is good).
"I refuse to change" is what you are saying, you can think about this longer than a minute and come up with more and better ways than what I just mentioned. Not only is email based password reser unneccesary, it is dangerous and lazy.
"There is no way around it" is such b.s., yes there is, pretend email does not exist, how would you do it? I think you skipped over parts of my post, there is a myriad of messaging applications if you insist control over some external account is the way to go. But really, the ideal way to do this would be have two sets of registration time challenges set. You can go with secret questions but also picture/emoji combinations, pins,patterns as the firsr piece and a second would either be a payment card for $0.01 charge or have them print one-time codes at registration time (second challenge skipped if second-factor auth is good).
"I refuse to change" is what you are saying, you can think about this longer than a minute and come up with more and better ways than what I just mentioned. Not only is email based password reser unneccesary, it is dangerous and lazy.
Email can replace only the password, leaving you with 2FA still.
Another messaging channel is fine of course. You could replace email address by a phone number for SMS/WhatsApp/Signal. Is that more secure though? Would a user rather give your random app their phone number than email address?
Secret questions are usually very much not secret (less safe than password). They are way easier to uncover about a person, and still very much subject to re-use across sites.
I am telling you that I haven't found anything as good and you reply that I must not have taken a single minute to think about it. I guess there's nothing more for us to discuss.
Another messaging channel is fine of course. You could replace email address by a phone number for SMS/WhatsApp/Signal. Is that more secure though? Would a user rather give your random app their phone number than email address?
Secret questions are usually very much not secret (less safe than password). They are way easier to uncover about a person, and still very much subject to re-use across sites.
I am telling you that I haven't found anything as good and you reply that I must not have taken a single minute to think about it. I guess there's nothing more for us to discuss.
> Another messaging channel is fine of course. You could replace email address by a phone number for SMS/WhatsApp/Signal. Is that more secure though? Would a user rather give your random app their phone number than email address?
Yes! Even insecure SMS is more secure than email. You know why? Because everybody and their mother is logging and inspecting email, I see people's reset codes and links all the time to everything from banks to porn sites! Many messaging systems including sms have no "account" to get phished either so while other attack vectors like malware infection remain (as with email), credential phishing as an attack vector is eliminated when using these messaging apps. Yes, many people in non-US countries use whatsapp,wechat,facebook or viber but don't even have an email until some retarded app forces them to get one just for the retarded registration system (in some, "internet access" even costs more with just FB,viber,whatsapp being the cheap default). Many gen-Z'ers also use messaging apps over email, it's like asking them to use aol or icq! And it is very convenient to block unwanted senders on those apps if you decide to sell their contact info or spam them with email (where with email it varies greatly with email client and provider). If you go by the numbers the majority of internet users are coerced into using email because people who design apps stuck in the 2000s.
> Secret questions are usually very much not secret (less safe than password). They are way easier to uncover about a person, and still very much subject to re-use across sites.
Depends a lot on how you implement them, again if you read my comment before replying I suggest pictures,emoji and patterns, you can ask them just about anything so long as it isn't information about them others can also learn easily. It is no different than passwords themselves being reused across sites, except here you control what easy to remember questions and answers to ask like "what are your too three emoji from this list" or "create a passphrase from a combination of these common words below", again, not a difficult problem unless in 2022 your assumption is there are many internet users incapable of remembering anything more than their mothers maiden name (who even knows that shit?) or whatever in which case there are plenty of other ways to provide challenges.
> I am telling you that I haven't found anything as good and you reply that I must not have taken a single minute to think about it. I guess there's nothing more for us to discuss.
You literally ignored the possibilities I listed, if you are disagreeing with my comment in ignorance of what I said then yes, let's not waste our time here.
Yes! Even insecure SMS is more secure than email. You know why? Because everybody and their mother is logging and inspecting email, I see people's reset codes and links all the time to everything from banks to porn sites! Many messaging systems including sms have no "account" to get phished either so while other attack vectors like malware infection remain (as with email), credential phishing as an attack vector is eliminated when using these messaging apps. Yes, many people in non-US countries use whatsapp,wechat,facebook or viber but don't even have an email until some retarded app forces them to get one just for the retarded registration system (in some, "internet access" even costs more with just FB,viber,whatsapp being the cheap default). Many gen-Z'ers also use messaging apps over email, it's like asking them to use aol or icq! And it is very convenient to block unwanted senders on those apps if you decide to sell their contact info or spam them with email (where with email it varies greatly with email client and provider). If you go by the numbers the majority of internet users are coerced into using email because people who design apps stuck in the 2000s.
> Secret questions are usually very much not secret (less safe than password). They are way easier to uncover about a person, and still very much subject to re-use across sites.
Depends a lot on how you implement them, again if you read my comment before replying I suggest pictures,emoji and patterns, you can ask them just about anything so long as it isn't information about them others can also learn easily. It is no different than passwords themselves being reused across sites, except here you control what easy to remember questions and answers to ask like "what are your too three emoji from this list" or "create a passphrase from a combination of these common words below", again, not a difficult problem unless in 2022 your assumption is there are many internet users incapable of remembering anything more than their mothers maiden name (who even knows that shit?) or whatever in which case there are plenty of other ways to provide challenges.
> I am telling you that I haven't found anything as good and you reply that I must not have taken a single minute to think about it. I guess there's nothing more for us to discuss.
You literally ignored the possibilities I listed, if you are disagreeing with my comment in ignorance of what I said then yes, let's not waste our time here.
> such b.s
> I think you skipped over parts of my post
> "I refuse to change" is what you are saying
> you can think about this longer than a minute
> if you read my comment before replying
Why are you so hostile? Why use an online forum at all if you will attack anyone engaging with you?
You do have some good points there, but is this really the only way you are capable of expressing them?
> I think you skipped over parts of my post
> "I refuse to change" is what you are saying
> you can think about this longer than a minute
> if you read my comment before replying
Why are you so hostile? Why use an online forum at all if you will attack anyone engaging with you?
You do have some good points there, but is this really the only way you are capable of expressing them?
You seem to interpret attacks against your argument as attacks against your character, that's not the case.
"Such b.s." refers to what you said, the rest of what you quoted is hostile but not to you as a person but a criticism of your thinking process and an expression of frustration when you take the time to replh but ignore the plain points I made in my comment and make generalized conclusions like how email is the only way without addressing any of the points in my comment that disagreed with what you are saying. I harbor no hostility towards you but I must criticize your argument and thinking process which might require directness and blutness which in a technical site like HN I would expect to be acceptable.
"Such b.s." refers to what you said, the rest of what you quoted is hostile but not to you as a person but a criticism of your thinking process and an expression of frustration when you take the time to replh but ignore the plain points I made in my comment and make generalized conclusions like how email is the only way without addressing any of the points in my comment that disagreed with what you are saying. I harbor no hostility towards you but I must criticize your argument and thinking process which might require directness and blutness which in a technical site like HN I would expect to be acceptable.
I give up. If you don't see any ad-hominem in the parts I quoted for your convenience, then nothing I say will change your mind. If this is the least hostility you are capable of deploying against a person, thanks for trying I guess. Go forth into the world and yell in people's faces; some might benefit from it?
I think @simonw clearly explained the problem around the login flow: "resist the temptation to innovate around login!". But I'd like to add more from this.
First, this will always depend on the product you offer. If you target highly specialized tech people, why not, they are most often open to changes. For the rest, it won't never be a good idea.
We tried implemeting a "one time login link" at ImprovMX, like a few others commented here. One drawback we saw was a surge in support requests from people having issues receiving the email, or not understanding how to connect. We could debate on this but definitely, doing something "original" was not a great idea.
But regarding the suggestions made by the original post, I can clearly see a lot (A LOT) of issues:
1. Changing the flow from what the users are used to: Clearly, once you have entered your email and password, you are expecting to receive an email. It's probable that a small percentage of users will close the window once they see the next page asking to send an email, without even reading it, loosing the "mailto:" link with the special token. They will also be lost on what to do; They'll expect an email, and won't understand the need to send one. In a more broader sense, changing the flow will require the users to think harder than usual on what to do, causing more users to leave and never finish the registration form
2. Matching the proper email If they happen to click on that mailto, they will have to remember which email they entered in the form, and will have to keep that in mind when sending the email. For me, if I click on a mailto, I'll have a GMail tab open to send that email, and I have 5 aliases registered. It will require an extra caution to select the appropriate one.
3. Having that email available If the user registers via his phone using an email not configured on that phone, he won't be able to send an email on that "mailto". This will require to copy/paste the link (and copying a mailto on a browser results in A LOT of changes on what is copied), find a way to share that copied data onto a device that has the appropriate email configured.
4. Custom emails Some users enter their email using the specialty of Gmail, such as [email protected]. When they'll send an email, they won't be able to add that "+label", causing the account creaton to fail
5. SPF/DKIM/DMARC, seriously? Wrapping your head around how these 3 standards works requires significat efforts. And yes, without them, you can not guarantee that the email is truly send by that domain. But still, many custom domains doesn't have a proper DMARC implemented and they can still spoof your account creation. In order to avoid this issue, the only best way is to keep the original flow : the services sends an email to the one the user gave.
Definitely, this is not a good idea to implement for so many reasons, but I agree on the original thought: The current flow has its own issues that needs to be resolved.
One flow I prefer, that doesn't fix everything but still remove a lot of headaches, is to send a code by email when the user has hit "Create my account". The next pages shows that the service expects the code sent by email. Once the user receives the code by email (ideally, having the code in the subject), they can enter it in order to validate their account and they are then automatically logged in a fully activated service.
This removes a few issues, such as:
Not having the email account configured on the same device Ending in a splash page right after creating an account Ending in a splash page when clicking on the link in the email Havign to connect to the service even though you did all the proper validation (I hate that)
The only issue remaining is to ensure the email arrives quite fast. But as long as we need email verification, we will have a hard time fixing this, as it is outside of both the service, and the user hand.
First, this will always depend on the product you offer. If you target highly specialized tech people, why not, they are most often open to changes. For the rest, it won't never be a good idea.
We tried implemeting a "one time login link" at ImprovMX, like a few others commented here. One drawback we saw was a surge in support requests from people having issues receiving the email, or not understanding how to connect. We could debate on this but definitely, doing something "original" was not a great idea.
But regarding the suggestions made by the original post, I can clearly see a lot (A LOT) of issues:
1. Changing the flow from what the users are used to: Clearly, once you have entered your email and password, you are expecting to receive an email. It's probable that a small percentage of users will close the window once they see the next page asking to send an email, without even reading it, loosing the "mailto:" link with the special token. They will also be lost on what to do; They'll expect an email, and won't understand the need to send one. In a more broader sense, changing the flow will require the users to think harder than usual on what to do, causing more users to leave and never finish the registration form
2. Matching the proper email If they happen to click on that mailto, they will have to remember which email they entered in the form, and will have to keep that in mind when sending the email. For me, if I click on a mailto, I'll have a GMail tab open to send that email, and I have 5 aliases registered. It will require an extra caution to select the appropriate one.
3. Having that email available If the user registers via his phone using an email not configured on that phone, he won't be able to send an email on that "mailto". This will require to copy/paste the link (and copying a mailto on a browser results in A LOT of changes on what is copied), find a way to share that copied data onto a device that has the appropriate email configured.
4. Custom emails Some users enter their email using the specialty of Gmail, such as [email protected]. When they'll send an email, they won't be able to add that "+label", causing the account creaton to fail
5. SPF/DKIM/DMARC, seriously? Wrapping your head around how these 3 standards works requires significat efforts. And yes, without them, you can not guarantee that the email is truly send by that domain. But still, many custom domains doesn't have a proper DMARC implemented and they can still spoof your account creation. In order to avoid this issue, the only best way is to keep the original flow : the services sends an email to the one the user gave.
Definitely, this is not a good idea to implement for so many reasons, but I agree on the original thought: The current flow has its own issues that needs to be resolved.
One flow I prefer, that doesn't fix everything but still remove a lot of headaches, is to send a code by email when the user has hit "Create my account". The next pages shows that the service expects the code sent by email. Once the user receives the code by email (ideally, having the code in the subject), they can enter it in order to validate their account and they are then automatically logged in a fully activated service.
This removes a few issues, such as:
Not having the email account configured on the same device Ending in a splash page right after creating an account Ending in a splash page when clicking on the link in the email Havign to connect to the service even though you did all the proper validation (I hate that)
The only issue remaining is to ensure the email arrives quite fast. But as long as we need email verification, we will have a hard time fixing this, as it is outside of both the service, and the user hand.
Spoofing?
Brilliant.
I will rant here a bit.
I say: let them experiment. Let this guy implement his clever scheme and see how spam bots population increases several folds and conversion drops 10-15%. If he knows what conversion is and have a metrics for it. And knows what metrics are, also. And if spammers are interested at all in his product. Or whatever.
Also let the legion of newbies and dilettantes vote articles like this to the moon and higher. Let it sit in top 1 HN for weeks. At the end, isn't it a creativity and smartness we should praise and encourage? This is Hacker News, home of brightest startup ideas.
After all, it is good for us, old and inert creeps. Ones who knows what metrics are, how to collect, store and analyse them, how to implement A/B test, and what "statistical significance" means. We still will have several open offers even when all the code would be written by GitHub Copilot, all the texts by GPT3 and all the art by DALL-E.
Forget about retirement, folks, there are interesting times ahead.
I say: let them experiment. Let this guy implement his clever scheme and see how spam bots population increases several folds and conversion drops 10-15%. If he knows what conversion is and have a metrics for it. And knows what metrics are, also. And if spammers are interested at all in his product. Or whatever.
Also let the legion of newbies and dilettantes vote articles like this to the moon and higher. Let it sit in top 1 HN for weeks. At the end, isn't it a creativity and smartness we should praise and encourage? This is Hacker News, home of brightest startup ideas.
After all, it is good for us, old and inert creeps. Ones who knows what metrics are, how to collect, store and analyse them, how to implement A/B test, and what "statistical significance" means. We still will have several open offers even when all the code would be written by GitHub Copilot, all the texts by GPT3 and all the art by DALL-E.
Forget about retirement, folks, there are interesting times ahead.
Look at the most commonly used flows that are not obviously terrible and try to implement as close a match to them as possible.
When I've tried to innovate around login in the past I've found that any clever ideas I come up with inevitably run into road blocks pretty quickly.
Here's one example: why have a separate login form from a signup form? They both involve asking the user for an email and password, why not have one form that can do either depending on if the user's account already exists?
I quickly learned why: if you don't understand the user's intent when they submitted that form, you can't show them error messages that match their mental model as to what is going on. This makes for an incredibly confusing experience the moment you step off the happy path.
----
That's not to say it's not interesting and valuable to think through new login mechanisms. They're very interesting design challenges! But its good to be prepared to find out that vanishingly few innovative ideas will work out as genuine improvements.