
The Death of the Login - rp_yogat
https://medium.com/@rameshdot0/the-death-of-the-login-b274b22e27a9
======
codingdave
"The primary use cases for requiring a login are customization, multi-device
sync and being able to reach out to the user."

No, the primary use case for a login is when you need to actually authenticate
to be authorized to access secure data.

~~~
Someone1234
That cannot be right, that explanation doesn't contain enough buzzwords and
web-2.0 nonsense. Almost sounds very 1980s...

But really, does anyone else find that quote eye-rollingly tech-hipsterish?

~~~
username223
I've been desensitized enough that it doesn't seem that bad. At least he wrote
"reach out" rather than "initiate the onboarding funnel."

~~~
warfangle
I prefer the term 'lead gavage'

------
daigoba66
Everything in the article until the topic of "Multi-device support" is really
just talking about how locally installed software has worked long before the
Internet and SaaS.

If I buy and install a piece of software like Photoshop (pre-Adobe
subscription Photoshop), I don't have to login to use it. It "remembers" my
settings and customizations simply by storing them in a file on my computer.
There's nothing stopping an app on my phone or tablet from doing the same.

When talking about "Multi-device support" we're really talking about device
synchronization. You could consider a web browser/web app as a "device" for
the purposes of this discussion. Since most devices can't do peer-to-peer
synchronization, we often rely on the software vendor to provide centralized
services. This requires identification and security which is typically
implemented with username/password credentials.

------
mbesto
> _Multi-device support is when users are using your app on multiple
> devices...For most apps, this is really an over-rated feature._

Uhh, it's not? What happens when a user upgrades their phone? Or loses it?
Since the OP has basically admitted they'll fall back on logins at some point,
I think they're going to have a much harder time explaining to users that they
need to add an email address later in the process (or worse, try to retrieve
someone's data when it's too late). On the other hand, it is interesting to
think that maybe there is a decent strategy here, where you gracefully migrate
an app user without a login (high conversion) into identifiable user (lower
conversion).

~~~
Eyas
Agreed. What the poster doesn't seem to realize in the analysis on multiple
device users is that the use case is _not_ only about using multiple devices
concurrently, but transferring from one device to another.

------
s_kilk
> The primary use cases for requiring a login are customization, multi-device
> sync and being able to reach out to the user.

And security, which is kind of a big deal if you have data the user would
prefer be kept in their own secure space.

~~~
connerbryan
Agreed. I think it's important to keep in mind the context of your application
when considering implementing a system like OP mentions. Although, it would
interesting to provide the user a choice between a password/"secure" login and
a device/"anonymous" login (with the option to later switch).

~~~
nothrabannosir
One caveat to the cookie-to-password switch: I am very good at saying,
"Tomorrow." "Yeah, yeah, I'll do that tomorrow." Tomorrow comes and goes, I or
a friend clear my history, whoops! Session lost.

At that point I am easily discouraged enough to stop using it.

E.g.: this happened to me with Khan Academy. I had watched so many videos on
that cookie-only session, by the time it disappeared I'd long forgotten which
ones I'd seen. Feeling a little discouraged, I thought, Okay, I'll get back to
Khan tomorrow. Tomorrow never came.

If more people are like that, that could be a good reason not to allow cookie-
only sessions for too long.

Or am I the only one?

------
andrewmutz
"Been a few days since you have come back to the app? You get a nice welcome
back notification."

Do any users actually like these sorts of notifications? It's clear to me why
application authors use them, but do users really like this stuff?

It is notifications like this that make it so that whenever an app asks for
permission notify these days, I say no.

~~~
mavrc
I was thinking this as well. I wonder, there must be statistics that show that
annoying your users gets results, or they wouldn't be used so frequently.

------
et1337
I'm a big fan of the "email-only" login. Type your email address, hit login,
switch to your email app, click the link, and you're logged in forever. If you
don't have a password manager, it's probably what you do most of the time
anyway via the forgotten password interface.

~~~
shillster
Passing tokens around via email isn't very secure. Its not like email is
encrypted.

~~~
username223
Right, but an expiring, single-use link that will send a second email saying
"someone from X place just logged in, so contact us if this wasn't you" is
still good enough in most cases. To see that, ask which sites will send you a
password reset mail when you forget your password. My bank certainly won't --
I have to talk to a person -- but most others do, making their passwords
useless.

------
brandonwamboldt
I'm not sure if it's just me, but I'm getting tired of the blog post formula:

> The Death of XYZ that is actually not really going anywhere for most people

The death of login, gamers, angular, react, PHP, etc, etc.

~~~
Karunamon
It's the current fad.

A few years ago, it was "Why I quit my job, and why you should too".

Then it was "Why $social_network sucks, and why you should leave".

Every now and then, you see "Why X sucks, and why you should stop using it
(alternatively: X considered harmful)".

Now it's "The death of X"

~~~
l0c0b0x
Not just that, but "The death of X" (title)... then blablabla, then
conclusion: "This really isn't the death of x".

:\

------
pionar
This piece is the least thought-out piece I've seen either on Medium or HN in
a while. Why all the upvotes?

------
ezegolub
So, in this scenario, losing the device (phone, tablet, computer) will mean
losing access to the account right? It is coupled to device ID or some cookie
right?

~~~
rp_yogat
I am going to add an addendum about this which I will do now. On the app we
are developing, the app installation has a unique id. Every once in a while,
all of the "history" is stored in a secure fashion back on the server. So a
device migration can be done. I must admit, losing a device is trickier
because you wouldnt which id to use to restore on a new device. Let me think
about this a bit

~~~
nkohari
Have you considered adding logins? :)

But seriously, this is literally the problem that logins were designed to
solve. With a login, you are defining an external concept of "user" that is
distinct from the device.

Available security factors are: something you are, something you possess,
something you know. Right now, you're using something you possess (the
device). The problem is, if I lose the device, I've lost my security
credential, and no longer "own" my account.

To fix this, you could collect an email, and when installing your app, you
could prompt the user if they want to use an existing account or create
another. But then, you probably want to add some security in the form of a
password... and then you've created a login.

------
skorecky
"Does this mean the login is dead? Of course not." Ugh.

------
aytekin
We have this on JotForm. You can use JotForm fully without creating an
account. I think it is important to give people freedom to roam your product
freely before making a decision to create an account.

------
pvsub
All my devices and apps seem to cache logins, so for the login is dead
(missing) until I need to change devices (and then there is the cloud-backup)

------
EugeneOZ
the "login" has even more lives than cat.

