
Persona makes signing in easy for Gmail users - callahad
http://identity.mozilla.com/post/57712756801/persona-makes-signing-in-easy-for-gmail-users
======
Amadou
The problem with persona is that it sends the same identifier to all websites
(nominally your email address). That makes it super-easy for those websites to
feed your activity to a central tracker like DoubleClick which will
consolidate all usage information from all DoubleClick affiliated websites.

Persona would be a lot more privacy-preserving if it generated a unique
identifier for each website. A "persona" for each website instead of one
persona for the entire interwebz. Since the system is mostly automated it
shouldn't be that hard to add one extra layer of indirection.

It might even be possible to shoe-horn it in to the current protocol with just
a little bit extra on the browser and identity provider sides, but no change
on the website code.

If anyone has actually done that, please post, I'd like to hear about it.
Availability of that functionality would sway me to start using Persona and
probably anyone else who is worried about spreading their email adddress far
and wide across the internet.

~~~
callahad
Persona isn't a panacea. If websites collude, and you use the same address on
each site, then they'll be able to correlate their user tables.

That's identical to the status quo, and fixing it is not one of Persona's
explicit goals.

We're very consciously trying to hit a pragmatic middle ground that moves the
web closer to user empowerment, without being so different as to hinder
adoption. Consider: if you're already collecting email addresses for your
users, you can immediately start using Persona without changing any of your
assumptions about your data model. It's portable and it dovetails into current
practices.

However, it _is_ technically possible to do what you want right now, so long
as you have your own domain and write a small browser extension. Longer term,
we're currently working with a partner on a possible extension to the provider
protocol which would make it easier to implement that sort of "directed
identity."

------
babs474
I've seen a few demos of this. The developer story is great.

Easy to integrate, no need to worry about screwing up storing passwords and
you are not abdicating authentication to some evil or possibly evil in the
future, company.

~~~
dave5104
Not trying to troll or anything, but how do we know Mozilla won't be evil in
the future? I'm sure you could find people who thought that about Google back
in the day, they seem to now be routinely called out for questionable evils.

~~~
signed0
AFAIK Right now there are two things that Mozilla controls.

1) login.persona.org that takes care of authentication

2) a JavaScript shim that developers add to their sites to get the login
button to work.

Persona is designed in such a way that reliance on Mozilla will be phased out
as email providers take care of #1 and as browsers start to implement #2. As
of now I think FireFox is the only browser that has #2 baked in.

~~~
ams6110
Not clear to me why we would trust "email providers" to do a great (i.e. well-
implemented, secure, etc.) job at providing authentication services.

~~~
vidarh
Then pick someone who does convince you, or run your own authentication. The
point is that it is designed to be decentralised.

------
gioele
I hope there will soon be a way to `apt-get install mozilla-persona` on a
personal server. That would seriously help the deployment a really
decentralized Persona.

~~~
ozten
Tell me more!

Do you want Persona authentication on your website or do you want a deamon
that is an identity provider for your personal domain?

What language or platform would be ideal?

~~~
jeena
I want to be my own identity provider, which ever web technology, php, ruby,
python, JavaScript.

~~~
ozten
This is a NodeJS personal project that I use to host my identity:
[https://github.com/ozten/hostedpersona](https://github.com/ozten/hostedpersona)

[https://ozten.com/.well-known/browserid](https://ozten.com/.well-
known/browserid) (a static website) delegates to
[https://hostedpersona.me/.well-
known/browserid](https://hostedpersona.me/.well-known/browserid) which I run
on an ec2 instance.

This clearly isn't as polished as aptitude install, but feel free to fork and
play.

~~~
StavrosK
I wrote a service so you don't have to do any of that:
[https://persowna.net/](https://persowna.net/)

Just add the .well-known file to your site, and that's it.

EDIT: Actually, I might just open-source this and keep the hosted version for
people who want convenience.

~~~
thoughtpalette
Side note, Your font differs on
[https://persowna.net/pricing/](https://persowna.net/pricing/) and
[https://persowna.net/](https://persowna.net/) for the logotype.

Awesome job on the site!

~~~
StavrosK
Oops, good catch! Thanks!

EDIT: This is really odd, it's the exact same HTML/CSS, yet a different
typeface. Weird.

EDIT 2: It would help if I had actually included the font in the header.
Thanks again :)

------
NelsonMinar
Really excited for this. Password authentication is an absolute disaster on
the Internet, and despite at least 8 years of development solutions like
OpenID are not succeeding fast enough. Mozilla Persona looks really promising.
Sure wish there were a Chrome extension for it!

~~~
callahad
There isn't a Firefox extension yet, either. :) JavaScript polyfills are fun!

(Persona works on all major browsers, save MobileIE and Chrome for iOS. Fixes
are in the works for those two.)

------
soapdog
I wish Hacker News used Persona.

~~~
dchest
It used some another (failed?) provider before (which connected accounts to
Gmail, Yahoo, etc.)

~~~
callahad
HN was using Clickpass (YC Summer 07), which was acquired and shuttered by
Janrain early last year. Amusingly enough, Stack Overflow still has a (broken)
Clickpass button on its login page.

If I recall correctly, Clickpass was a centralized OpenID proxy, whereas
Persona is trying to bootstrap a fully decentralized protocol. We don't want
to even be able to track you. :)

[Edit: Corrected YC cohort. Thanks wamatt!]

~~~
baha_man
"Amusingly enough, Stack Overflow still has a (broken) Clickpass button on its
login page."

Where? I can't see it.

~~~
callahad
The button was removed a few hours ago:
[http://meta.stackoverflow.com/questions/192501/remove-
obsole...](http://meta.stackoverflow.com/questions/192501/remove-obsolete-
clickpass-login-option)

------
Skalman
The only bad thing with this new Gmail integration is that it gets _more_
annoying if you have multiple Gmail accounts, or aren't logged in to the Gmail
account you want to use.

And some things, like using myname+website@gmail.com doesn't work at all.

~~~
callahad
myname+website@gmail.com should absolutely work -- please file a bug if not:
[https://github.com/mozilla/browserid-
sideshow/issues/new](https://github.com/mozilla/browserid-sideshow/issues/new)

~~~
Skalman
Huh - it does work, as you say. I guess I misremembered.

EDIT: Now I remember my use case.

My email is actually myname+randomstring+website@otherdomain.com, and so I
want to sign in with the same randomstring every time. Previously when signing
in to Persona with my Gmail email address it would suggest all alternatives,
and I'd choose the appropriate one. Now it logs in with Gmail directly
instead.

Of course, this is such an edge case that it's probably not worth doing
anything about. And I can simply sign into Persona with myname@otherdomain.com
for the previous functionality.

~~~
Skalman
Yet another use case that's more difficult now: I use randomstring@gmail.com
for some sites where I expect to get lots of spam, and then forward email
based on some filters.

~~~
callahad
We'll switch from proxying via OpenID to OAuth 2 in the next few months, which
will make that seamless again thanks to the `login_hint` option to Google's
OAuth endpoint.

------
clarkevans
I'm looking forward to when their LDAP adapter [1] is ready for prime-time so
that we can use it internally for our own email addresses. I'm curious if the
GMail adapter would work if you host your company email at google?

[1] [https://github.com/mozilla/vinz-
clortho/](https://github.com/mozilla/vinz-clortho/)

~~~
callahad
We're using Vinz Clortho in production right now (try to log in as
callahad@mozilla.com and you'll be prompted for my LDAP password).

It's not super generalizable, but if you're interested in rolling it out on
your end, ping our mailing list ([https://lists.mozilla.org/listinfo/dev-
identity](https://lists.mozilla.org/listinfo/dev-identity)) and we're happy to
support you while you get that going.

A generic Google Apps bridge is somewhat tricky, but we're really interested
in prototyping it over the next few months.

------
zobzu
If you just wanna try it:

[http://myfavoritebeer.org/](http://myfavoritebeer.org/)

and put your gmail in the box :)

------
herge
It doesn't work with google apps, unfortunately.

Which is completely logical when I think about it since persona would not use
the mx record to find the identity provider.

~~~
finnh
Actually, why not?

Looking for that "aspmx.l.google.com" entry in the MX record would let them
know, with a high degree of certainty, that Google is the login authority for
that particular email address.

Is there something I'm missing?

~~~
lancestout
There's the /.well-known/browserid [1] file that can be used to delegate a
domain to another identity provider.

The main thing is that while Persona talks about email verification, the
protocol doesn't require that email handling exists. Just that a server
vouches for the existence of a user@host, so using MX records wouldn't be
'correct' even if it would be a useful heuristic for google apps domains.

There has been talk of using SRV records, but it looks like the .well-
known/browserid file will be the recommended way to do things.

[1] [https://developer.mozilla.org/en-
US/docs/Mozilla/Persona/.we...](https://developer.mozilla.org/en-
US/docs/Mozilla/Persona/.well-known-browserid)

------
workhere-io
If you're interested in integrating Persona into your website, I've made a
couple of examples of how to do it:

[https://github.com/workhere-io/personaexamples](https://github.com/workhere-
io/personaexamples)

There's also a demo that shows how Persona works (doesn't save any of your
info):

[http://personaexamples.workhere.io/](http://personaexamples.workhere.io/)

------
NDizzle
This seems like it just adds another click for gmail/yahoo users? I don't
understand. Added another step to the login process and I think I'll have to
change around some of my javascript to prevent returning users from
"magically" authenticating after Persona gets around to authenticating them.

Weird. Oh well. Can't bitch much with a free service can I?

~~~
berekuk
They replaced the step where you had to enter your "Persona password" with one
click confirming your gmail credentials to Persona. You have to do it just
once.

(And not even once per website, just once in a lifetime.)

------
stephenheron
If anyone wants to hear more about Persona and lives around the Edinburgh
(Scotland) area then please feel free to pop along to a talk that one of the
Persona developers is giving.
[https://edpug2013aug.eventbrite.co.uk/?ref=ecal](https://edpug2013aug.eventbrite.co.uk/?ref=ecal)

------
pspeter3
I'm really glad they finally added this. Persona is a great way to login and
better for developers and users.

~~~
kamjam
What is the benefit of this (from a developer/website perspective) over using
OpenID? I can't really see the difference... obviously I'm missing something
fundamental...

~~~
callahad
The main things are ubiquity, ease of use, and privacy.

\- Persona works with any email address. This means you can reach anyone that
hits your site, without forcing them to sign up with a third party provider.

\- I can answer the question "what email address do you want to log in with?"
I can't answer the question "what is your OpenID?" nor can I remember which of
the 13 buttons on Stack Overflow I used last.

\- OpenID requires phoning home with every login transaction. Persona
explicitly does not. Your provider doesn't get to learn where you are logging
in.

Edit: Put another way, can you tell me what your Google OpenID URL is without
cheating? Can most people? If not, then you're only able to select a provider
from a predetermined whitelist on each website. That undermines your ability
to self-identify, self-assert, and choose who you trust. The open web deserves
better.

~~~
X-Istence
[http://profiles.google.com/xistence/](http://profiles.google.com/xistence/)

Or that was my Google OpenID at one point, not sure if it still acts like one
or not.

~~~
superuser2
While the HN community understood that, my mother was _never_ going to grasp
the idea of ownership of a URL as a login credentials. Many people don't even
understand URLs and just Google for everything they want.

Email addresses have been used as login credentials for a while, so people are
used to that. The explanation of Persona might be a little weird, but it's not
as totally disabling to a nontechnical user as being asked to sign in with
OpenID.

------
williamsharkey
1\. Why the popup window?

2\. Are developers permitted to strip the Persona branding - to make the login
process seem to flow with the current website - not a bolt on?

3\. Would you consider including tiny profile icon links next to the button
itself, to facilitate single-click profile sign-on/switch?

~~~
callahad
> _1\. Why the popup window?_

Persona follows the LIFD architecture: [http://www.open-
mike.org/entry/lifding-the-web](http://www.open-mike.org/entry/lifding-the-
web)

Popups allow us to create a nice messaging channel between the shim /
localstorage at persona.org and the website the user is trying to log into,
without losing their state on that website.

> _2\. Are developers permitted to strip the Persona branding - to make the
> login process seem to flow with the current website - not a bolt on?_

Sure. Brand it however you want. "Sign in with your email" converts best. The
popup will always follow the same basic form, but you are able to add your
logo, a human readable name, and a background color to influence its design:
[http://identity.mozilla.com/post/55796551587/persona-a-
login...](http://identity.mozilla.com/post/55796551587/persona-a-login-that-
matches-your-site)

Check out the login on
[https://see.drupalpersona.me](https://see.drupalpersona.me)
[https://webmaker.org](https://webmaker.org) and
[https://ting.com](https://ting.com) for examples.

> _3\. Would you consider including tiny profile icon links next to the button
> itself, to facilitate single-click profile sign-on /switch?_

Our UX folks are actively experimenting with this. Look for Ryan Feeley's
posts on the dev-identity mailing list for some explorations.

------
eslaught
Does this mean that Google implemented a Persona endpoint for Gmail, or that
Mozilla is now using OpenID (or whatever it is Google uses now) to piggyback
on Google's existing login mechanisms?

~~~
callahad
Croikle's right. This is using Google's public OpenID endpoint to validate
your email address, and bootstrap a Persona certificate. We did this
independently of Google, though we are in informal contact with the relevant
folks on that side of the Valley.

------
barmstrong
Can someone explain the security implications of Persona? In what ways is it
more or less secure than other authentication mechanisms (username/password,
two factor auth, etc)? Thanks!

~~~
ubernostrum
Persona is basically just public-key cryptography, but with a nice interface
on top.

What you're really doing when you sign in to your identity provider is getting
a certificate, signed by them, and containing a serialized public key (from a
keypair generated and stored in your browser).

What you're really doing when "signing in" to a Persona-enabled site is
sending them the certificate and a signed assertion, and letting them check
all the signatures (public key in the certificate verifies the signature on
the assertion, and the provider's public key is obtained to verify the
signature on the certificate).

The only entity involved in this who needs to get a password from you is the
identity provider, and password auth isn't required for that; it's just an
easy and common way to do it. Sites you log into using Persona never ask for,
see, or store a password for you.

The certificates are transient (they expire within 24 hours). The assertions
generated by your browser are transient (they expire within 5 minutes). The
keypairs generated and stored by your browser can be transient (you don't need
to use the same keypair each time you sign in to your identity provider), and
are tied to a specific email address and browser instance.

The whole thing is also designed to be decentralized. For most people, for
now, Mozilla is the identity provider, but you can run your own (relatively
easy) or use a trusted third-party provider. All that matters in a provider is
that it speaks the protocol.

This means that comparing Persona to "password authentication" or "two-factor
auth" is not really a useful question; your provider can use any mechanism you
both agree on to verify you and give you a certificate. Though the immediate
big win is, of course, that if there's a password involved, only the provider
ever handles it, so you don't have to worry about a bunch of sites' password-
storage practices, and you may not even have to worry about your provider's
(if your provider doesn't use passwords to verify you).

The provider also doesn't know what sites you're signing in to with Persona;
they don't receive the assertion from the site you sign into, they just
provide a copy of their public key so the site can complete verification.

------
lifeisstillgood
Ok, that is a big deal.

Must add that to velruse.

------
coherentpony
This worries me a little. Perhaps because I don't fully understand what's
going on under the bonnet. When I give a website my email address, some
communication must happen between that website and persona. So there's some
centralised persona server sending auth tokens back and forth between websites
that use persona api? Am I misunderstanding?

If that's not the case, then what, exactly, information does website X have
about me now that I have 'logged in using persona'?

~~~
superuser2
I had this misunderstanding also, but if I understand it correctly...

Basically a site using Persona tries to send you to your email provider to
authenticate. If your email provider is running Persona, you'll authenticate
through them, and the email provider sends a token back confirming your
identity.

Mozilla is the default identity provider for people whose email providers
don't run Persona (yet). Once the project gains widespread adoption, Mozilla
won't be processing much if any authentications because they'll be distributed
to email providers.

Also it will in theory work as a browser extension, so your email provider
sends your _browser_ the token, and your browser sends the token to the
websites you log in to. So your email provider doesn't know where you're
logging in.

~~~
coherentpony
>Also it will in theory work as a browser extension, so your email provider
sends your browser the token, and your browser sends the token to the websites
you log in to. So your email provider doesn't know where you're logging in.

I don't understand this. Presumably there's nothing stopping Website X sending
both: a) my email address; and b) Website X's URL.

Scenario: Joe Bloggs tries to log in to www.SiteThatSellsCars.com using
Persona. Joe enters his email address. SiteThatSellsCars sends Joe's email
address and "www.SiteThatSellsCars.com" to Joe's ISP. This translates to
SiteThatSellsCars saying, "Hey, Joe's ISP, Joe is looking to buy a car, you
should send him a metric shit-load of car adverts. He might not like it, but
whatever. Thanks for the $20!". Then Joe's ISP replies with, "I sent Joe a
token to his browser so he thinks he still has his privacy, but fuck him.
Every customer you tell us about, we'll give you $20."

Perhaps I am being cynical.

~~~
redalastor
The site doesn't send anything at all to the identity provider. Your browser
sends an authentication requests to the identity provider and relay it the
site it wants to log into.

The site then checks the request is really signed by the identity provider and
lets the user in.

The identity provider knows two things:

\- You asked to log in somewhere \- At least one person logged to site X
because site X asked for its public key

------
mixedbit
Congratulations to the team!

------
lnanek2
Still annoying I have to type in my email address even though I'm already
logged in to Gmail. With OpenID I just click a Google icon, some auth clicks,
and I'm done. With this I have to type in my email and do some auth clicks.

~~~
pdwetz
Isn't this more of an issue with the current browser you're using? As in, once
fully implemented in the browser you won't be prompted to enter it at all.
Also, my understanding was that your session information isn't passed along
(privacy feature), so it would have no clue you're logged in elsewhere.

------
Afforess
I like idea of Persona, but the idea of requiring emails prevents me from ever
implementing it. There are plenty of places where I need an identity system,
but don't want to force users to fork over their email address.

~~~
jlongster
You almost always want their email address so that you can email them a
password reset link in case they forget their password, which is even more
important on smaller obscure sites where that's bound to happen.

~~~
Afforess
If users don't want to provide an email (and then can't reset their password),
that should be their prerogative.

~~~
kibwen
As a user who doesn't want to provide my personal email to random services, I
have a throwaway email on a different provider with a gibberish username.
Given that signing up for 99% of services _already_ requires an email account
(or a Facebook/Twitter login, which themselves require a verified email
address), Persona is no less onerous.

------
erkose
Someone still needs to solve the "what verifier do I use problem" in a
decentralized way, or we're going to see Persona follow OAuth and be dominated
by Google, Facebook, and Twitter accounts.

~~~
callahad
I think Persona _does_ solve that, or at least, is designed to. Could you say
more about what you're thinking?

(Persona always prompts you with a _completely free-form_ email input field
and routes you to the appropriate provider based on that.)

~~~
erkose
You haven't reached the "verifier" step yet, which is step 4
[https://developer.mozilla.org/en-
US/docs/Mozilla/Persona/Qui...](https://developer.mozilla.org/en-
US/docs/Mozilla/Persona/Quick_Setup)

~~~
callahad
Oh, that. It's completely possible to do all of the verification locally, so
you don't have to talk to our hosted verifier. We're working on building
libraries to make that easier, but we still want to tweak our data formats a
little bit before recommending local verification.

In particular, we're watching the IETF's JOSE family of standards pretty
closely.

------
joyeuse6701
So...that means instead of someone knowing my password to get into xyz
website, they can easily just use persona which in a few clicks will let them
into my account?

~~~
callahad
Sure, if they're logged into your Gmail account at the same time. At which
point it's already game over. :)

~~~
joyeuse6701
Touche sir.

------
vxcvxc
I prefer Lastpass and dont see a need to centralize login solutions. In fact,
every time you centralize something, it becomes vulnerable.

~~~
vidarh
The point of Persona is decentralising logins.

------
AsymetricCom
A company build upon a work-around. I think this is a new level of epic cruft.

