
Rethinking email confirmation - rdfi
http://www.blinkingcaret.com/2016/12/07/rethinking-email-confirmation/
======
jsnneo
Adding friction to user registration should be done with caution, forcing
users to go through your registration form _and then_ refuse access to the
site until they click on an activation link _and then_ enter their
registration information again is so much friction, it's going to drive users
away and will frustrate those who do push through it... and it's completely
unnecessary.

The problem this idea proposes to solve is an edge case, and there are better
solutions. For example after registering an account a user can be immediately
logged in with a banner displayed at the top until their account has been
validated via email, with the option to change their email address if they
entered it incorrectly on registration. There's no additional friction, and
the minority of users who do make a mistake with their email are covered.

~~~
laurent123456
> For example after registering an account a user can be immediately logged in
> with a banner displayed at the top until their account has been validated
> via email

That still wouldn't solve the problem the author proposes to solve. If you
accidentally entered someone else email, that someone might click on the link
and you'll never see the banner.

~~~
madawan
A possible solution: if you click the "verify email" link you are brought to a
verification-form where you need to enter your password.

~~~
ProbabilityMoon
This is literally presented in the article. (ಠ_ಠ)

------
koliber
Most people will not encounter this problem.

\- website that use a username as the primary identifier will make it clear
that the email address has not yet been verified. They will nag the user to
confirm the email address, or at least prominently indicate that the email is
not yet verified. It will be difficult for the user to not notice an
unverified email address.

\- most websites use the email address as the identifier. If the user used the
wrong email address to create the account, they will not be able to
subsequently log in.

\- some website require you to verify the email address before you create the
account, even though they ask for all the information on a single signup form.

~~~
nodesocket
Agree with all your points, but I actually really like the idea of having the
signup form only ask for e-mail. Do the confirmation song and dance, and then
ask for the rest of the users details (name, password, etc).

~~~
koliber
Absolutely! If done right, the workflow you suggest takes a lot of friction
out of the registration process.

You can do even better! You can just let a user start using your application
without even providing an email address. Keep track of the user via a cookie
at first. Present them with opportunities to provide an email address (and
other info) if they wish to return in the future. Once they do, associate the
account with the email address. After that, continue asking for more
information on a need-to-know basis.

~~~
nodesocket
> You can do even better! You can just let a user start using your application
> without even providing an email address. Keep track of a user via a cookie.

This is not better from a business 101 perspective. You've just traded the
ability to communicate with some of your users without requiring their e-mail.

~~~
ldjb
It depends on the business/service. In some cases it's a good idea to give the
user a taster of what they can do with the service before making them sign up.

You know what I do when I come across a service that forces me to sign up
before I can see if it's any good? I hit the back button.

~~~
koliber
You are not the only one!

The taster can be in the form of a descriptive home page, landing page, or
article. It could also be in the form of a completely friction-less trial that
does not ask for any user info. The latter are rare.

It's up to the user to decide if they should invest their time in trying out
the product based on whatever taster the website offers.

------
blauditore
I ran into exactly this problem about two years ago with Google Apps for Work.
I mistyped my email address, but was able to finish registration and start
using it. When I noticed my error, there was no way to change the account's
email address without confirming that through the original one, which I
obviously couldn't. I had no other choice than letting go of the account.

It's quite silly because you'd think for a big platform like this, they would
have thought about such a case, but they obviously didn't.

------
jakub_g
There's one major problem with this idea from user point of view:

when you have just a "enter your email" field and nothing more, you already
gave someone an email and got nothing in exchange yet, then at the next step,
you click the link, and they ask you about 100 mandatory things to finish
registration, asking about everything including your shoe size. Then you might
not want to register to this kind of site out of principle, and also can not
unregister anymore usually.

(To be fair, sometimes pages have multi-step registration and do the same,
asking few innocuous things first, and more privacy-invading things later. I
hate that.)

~~~
grenoire
First of all, after clicking the mail link only a username and password is to
be set. It is your job to design it such that it is not a menial task to
register.

Secondly, if the user decides to not register after all, just give them an
unlink mail button at the registration form. This way they can stop the
registration and use the mail in the future if they change their mind.

~~~
ldjb
I wonder if it's really necessary to provide an unlink mail button. If the
user decides not to register, then an account is not created. They can simply
abandon the registration process and forget about the service.

Unless the service sends out regular email reminders or something to anyone
who has entered their email address, then I can understand the need for an
unsubscribe link.

------
kijin
A much easier, and already widespread, way to prevent the problem described in
the post is to use the email address as the login username. It is highly
unlikely that the same person will mistype the same email address every time
he tries to log in, so the mistake will be caught very quickly even if someone
else clicked the confirmation link.

If a person enters the wrong email address at signup, no damage is done. He
can just sign up again with the correct email address. The account with the
incorrect email address will either remain uncomfirmed and deleted at some
point, or belong to someone else. Doesn't matter, it's an empty account. You
should prune unconfirmed, empty accounts periodically anyway.

If you really want users to have a separate username, nickname, handle, or
whatever, that's fine. But that should be separate from the login, especially
if it's going to be visible to other users.

~~~
Theodores
I am sure you can also get autofill to get the email address correct on
popular devices for most people, therefore making the process fairly
frictionless. Plus email address is a very good primary key.

~~~
jsnell
Email addresses are awful primary keys. Sure, it's unique. But the other main
property of a good primary key is that it never changes. Email addresses
change constantly. People use their work or university address for personal
things, and then change jobs / are laid off / graduate. Or they use an email
from their ISP, and move. Or they used to use one webmail system, and switch
to one with a better UI; buy their first Apple device switch to an icloud
email instead of a gmail one.

It's fine to use an email address as the thing you enter into a login box. But
internally you really want the user records to be keyed by something else, and
just associate an arbitrary number of email addresses to that.

~~~
zAy0LfpBZLC8mAC
> Sure, it's unique.

No, it's not even unique.

~~~
wolfgang42
Indeed, the ecommerce system at my company used to use email+password as the
account identifier (because reasons) and when we tried to deduplicate we found
a lot of duplicates were things like SmithFamily@isp.example.com where one
account always shipped to "Laura Smith" and the other one always shipped to
"Harry Smith".

------
tomw1808
Why not just discard the registration after 1h when nobody clicks on the
confirmation-link? Works since the 90s!?

------
Animats
If the user name is the user's email address, the problem disappears.

~~~
nailer
And having a separate non-email username is an antipattern

~~~
minitech
How so? For a website like Twitter, for example, it’s convenient to be able
to:

\- Tell people how to get to your profile in person (and remember how to get
to someone’s profile without needing a link)

\- Mention people by name

\- Keep your e-mail address private

You might also want to associate the same e-mail address with multiple
profiles.

This seems like an overgeneralization.

~~~
nailer
While outside publishing platforms those needs are rare (and that's why I
consider it an antipattern) I agree with you in terms of a publishing
platform.

------
croon
I wish this was the only problem with signing up to services, because it can
be solved with formfills, verifying your email upon entering it, etc, etc.

As someone who got their last name at gmail in 2004, I've gotten a lot of
emails for other people over the years, and A LOT of services don't require
verifying your email for signing up.

I've gotten a Twitter, Instagram and Fiverr account without signing up (on top
of probably hundreds of smaller services, golf clubs, local news, charities,
etc), and definitely without ever clicking a link in an activation email I
didn't sign up for. The latter of which I can't delete, nor change my
username, effectively burning that email address for that service.

I'm sure those named services have since fixed that, but that it was ever an
issue in the last 15 years baffles me.

Nowadays I use my own domains for email, so it matters less, but I wish even
confirming emails at all for services was more enforced.

I'm sure this is all rooted in services wanting to grow their "user"base
rather than have real users.

------
pornel
The article says the e-mail _was_ confirmed, but by wrong person:

> the person that actually owned the jon.smith@email.com was a kid that was
> curious and clicked the email from TheService asking him to verify his email
> address.

Unfortunately, most comments to this article miss this point and argue about
unconfirmed addresses instead.

------
madmax108
HN HugOfDeath!

Cached version:
[http://webcache.googleusercontent.com/search?q=cache:Er9PEaJ...](http://webcache.googleusercontent.com/search?q=cache:Er9PEaJ8cJQJ:www.blinkingcaret.com/2016/12/07/rethinking-
email-confirmation/)

~~~
gear54rus
Perhaps there's a room for a functionality that automatically backs up the
page that is linked to HN provided it gets enough votes (actual algorithm is
up to debate) :)

------
andybak
Slack offers an optional 'magic email link' sign-in for people that can't
remember or don't want to look up their password.

I wonder if anyone has implemented a non-optional version of this on any
decent scale? i.e. is anyone using passwordless 'email link'-only login?

~~~
onli
For what it's worth, that is what Mozillas Persona was offering (and what
portier is offering now). I'm not sure which was the biggest site using that
and did not find it searching just now, but maybe you have more luck.

------
gottam
better idea:

if user doesnt verify email within a few days, that email "expires" and is
removed from the account. Add a message to nag the user to add a proper email
to their account.

this removes the edge case mentioned in the article and reduces sign up
friction.

~~~
djs070
I don't necessarily agree with the article but your proposition does not solve
the scenario described, where the owner of the email address gets the emails
and clicks confirm out of curiousity or habit

~~~
gottam
the problem that the article describes is that an incorrect email was entered
at sign up, and the user gets invested in their account, all for it to get
hijacked by original the email account owner down the road. Expiring an
unconfirmed email solves this.

There's still many other possible scenarios but I think it generally does what
the author wants in a not so annoying way.

~~~
LindenRyuujin
No, you are incorrect. What you propose wouldn't stop the situation described
at all.

From the article:

> What happened?

> Well, turns out that the person that actually owned the jon.smith@email.com
> was a kid that was curious and clicked the email from TheService asking him
> to verify his email address.

> He himself forgot about this until a couple of years later when he heard
> about TheWebsite from some friends, and decided to try it. He tried to
> create an account and got an “account already exists” error. He used the
> password reset functionality and that’s that. He now owns the original John
> Smith’s account.

------
kraftman
Or why not scrap the password and the username and just use passwordless
login.

~~~
devgutt
yep, I was thinking the same. User informs email. System sends a code. User
uses the code and log in. No password. Transparent validation.

------
kyle4211
A possible solution: a) Allow multiple registrations with the same email until
a confirmation click happens and b) require a browser session or password to
confirm.

Doesn't this solve the issue presented?

