Live data from Hacker News

Why don’t we do email verification in reverse?

blog.yossarian.net

21–30 of 329 posts

Re: Why don’t we do email verification in reverse?

#21
>…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.

Re: Why don’t we do email verification in reverse?

#22
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?

Re: Why don’t we do email verification in reverse?

#24

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 spoof attack works for both account creation and password reset (account takeover). This attack is impossible if the website sends a verification email to the user's inbox which only the person who c…

Can you explain (3)?

Re: Why don’t we do email verification in reverse?

#25

>…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 tha…

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.

Re: Why don’t we do email verification in reverse?

#26
post #2

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…

Good summary

Using mailto: is just asking for trouble at this day and age.

Re: Why don’t we do email verification in reverse?

#27

>…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 tha…

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.

Re: Why don’t we do email verification in reverse?

#28
post #5

A general rule of thumb I've built up over the years: resist the temptation to innovate around login! 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 l…

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”…

ImprovMX does this just fine

Re: Why don’t we do email verification in reverse?

#29
post #5

A general rule of thumb I've built up over the years: resist the temptation to innovate around login! 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 l…

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

Re: Why don’t we do email verification in reverse?

#30
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.

Post reply on HN