Hacker News Reader

Wait, it relies on email address? (quickly reads up on it.) ... and it doesn't have user identifiers other than the email address? That is not reasonable: normal people (as in, people who don't know much about what they are doing with computers) tend to have piles and piles of email addresses, none of which hold any canonical weight to them: they have email addresses from ISPs, from schools, from work, and they often have multiple email addresses from sevices like Gmail. If they lose track of one they just get another one (as email addresses aren't even important anyway), and they never remember which one they've used with any given site. I've even seen people purposely get a new email address every now and then as their way of dealing with spam and "people I don't want to talk to anymore". They don't think far ahead, so the notion that their email address from school will be retired a year after they graduate and given to someone else doesn't occur to them (and seemingly didn't occur to you either, as it undermines the argument that it is a reasonable way to do password resets): email addresses are about the worst possible (while still plausible) "unique" identifier you could have come up with. :( (And yes: this is coming from someone who has had a single canonical email address for over 15 years: I also run a popular website frequented by tens of millions of users, many of whom are non-technical customers, and I have had to realize that they are nothing like me.)

Not to mention that email is really unsecure. A password reset link will be sent as plaintext.

Is there at least a way to change the email addredd associated with an account? I can't see anything about that.

What password reset link? :)

If you're using an email provider with native support for Persona, the only password you have is with your email provider.

Ah. I hadn't realized it's using the mail server.

http://lloyd.io/how-browserid-works

without trying to add more complexity into the system, it would be nice if multiple accounts per email were possible. why not just link them together so any will work in place of another? not sure how you'd help someone find their account if they don't remember the email though.

Here's what would be great for users, being able to sign in with _any_ of their email addresses and passwords. If you could register all of your email addresses and passwords then login would become as easy as entering the first set of details you think of.

That's an interesting idea. How would you go about collecting all these emails first though?

Would you tell the user to "just enter all email addresses you ever registered" and then send confirmation emails to all of them? I'd imagine this ending with one or two confirmed email addresses and maybe 3 additional unconfirmed ones.

When the user then tries to use one of the unconfirmed addresses to sign in — what do you do? Refuse log in because the address is not confirmed? Send another confirmation email to that account and ask the user to confirm it? List those confirmed addresses in the account and ask the user if he wants to sign in with one of them?

No need to send confirmation emails. Let him login with any email address. If the authentication is successful, you let him in. At this stage, it is a new account so give him an option to link this new account with his existing account with your service. If he had already provided all his email addresses with the first account, there is no need to authenticate one more time. Otherwise, simply authenticate once more with the original email and link the accounts if successful.

"we're really, really easy to implement" "I want to see us become the de facto auth solution" "We also let you reach many, many more people" "but we're also a really nice option to put alongside your social login"

Assuming by "we" and "us" you mean Mozilla? Or do you also mean the other major browsers?

Why did you write it like that? Why not just say "Persona" instead of "we" and "us"? Surely Persona is much bigger than Mozilla or do you not think so?

Firstly, that kind of language does not inspire trust. It sounds very much "us" vs "them", instead of addressing the real problem, which is helping users by creating and managing more secure passwords.

Secondly, your marketing to users includes:

"Many sign-in systems carry your profile data with them; some even share that info with other sites and social networks. We believe you should control how your personal information is shared."

You seem to want to attract publishers and yet you show your distrust of them to users.

Also, from experience in Public Web Apps, and the fact that it's still not possible for a user to give raw and pure TCP, UDP or POSIX power to Web Apps (and WebSockets and IndexedDB are not at all the same), I don't think the issue is so much that the user has power, as it is that the browser should have power. As it is today, the user is given very little power at all by the browser. Very little trust. Most spec discussions seem to constantly worry about users shooting themselves in the foot, and are prepared to stop at that, rather than finding ways to empower users to give power to web apps.

I work for Mozilla on the Persona team, so it feels natural to say "we" to refer to us and the specific implementation we've built, but I see your point as to the feel of that language. Thanks for calling me out. Persona certainly has a scope beyond Mozilla, and its current state owes much to open collaboration.

Well done on your efforts and may Mozilla continue to develop into a force for good.

At the moment, however, and Persona is a good example of this, the browser approach to innovation is very much top-down with high-level APIs like UndoManager, WebRTC, IndexedDB rather than bottom-up with low-level APIs like UDP, TCP and POSIX which would trust the developer community to do the rest. Browsers are just not very programmable when compared to platforms like mobile and native.

For example, if the user would be allowed by the browser to empower a web app with raw POSIX, then that would unleash an explosion of databases running in the browser, orders of magnitude better and faster than IndexedDB.

Sadly, this kind of innovation is currently locked up tight inside the various spec committees. For sure, developers can contribute to the mailing lists, but innovation should not be made to go through that kind of process at all in the first place. Innovation on the web needs to be decentralized not centralized. Ideally, Mozilla needs to start making that possible, by providing just the right OS-level APIs and a simple way for users to grant these to Web Apps.

It must be 1984 that one can use a browser, but not be allowed to give raw TCP or UDP or POSIX annointing to web apps that one trusts.

See Tim Berners-Lee on the subject: http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...

I'm not a fan of the way this requires me to set a password for Persona. I'd rather just have one password, my email (gmail) password, and use that.

That's the plan. Mozilla are just waiting on Gmail to cooperate and implement Persona on their side.

In an ideal situation, both your browser (eg: Firefox) and your email provider (eg: Gmail) would support Persona. In that case, you don't have to click on any links to prove your email address, you don't have to create a new password, you don't have to trust Mozilla's servers to store a hashed version of your password correctly. The log-in dialog itself with be part of the browser chrome, training users to trust the browser and not the website, which is a good thing.

If your browser or your email provider don't support Persona, then Mozilla have provided fallbacks, which require you to click a link in an email and to create a new Persona-specific password.

In the case of gmail, they're note even waiting. There is active development on a gmail-to-persona proxy so that you can authenticate with just your gmail password:

    https://github.com/mozilla/browserid-bigtent

I've been using BrowserID/Persona on my sites and I love it. For an example, go to http://www.yourpane.com and click "BrowserID" (never mind the other fields).

It always takes me 5 minutes to integrate, doesn't require me to write any sort of "forgot password" functionality, doesn't require me to worry about storing passwords, and it's generally very easy to work with.

One problem is that users don't know if they're supposed to sign up or sign in, and that a Persona works for other sites, but I think this can be ameliorated with good copy.

That provided a pretty confusing journey. First attempt: I clicked the Browser ID button, entered my email address on Persona, got redirected back to your site with no messaging. Tried again, it asked me to give a password this time. Did so, but then didn't redirect me back to your site. I then had to manually go back to your site and hit the BrowserID button for a 3rd time, which then took me to a Persona page to log into your site.

That's odd... The first time, you probably needed to verify your email, and I'm using the old API, so it doesn't sign you in right away. The second time, I don't know why it didn't log you in, I'll have to look into it...

I'm not sure it's your issue, it seemed more like it was problem at the Persona end. Unless of course Persona was sending useful messages back to your site but your end wasn't handling them.

I'm not sure it's my issue either, the whole thing is pretty much plug and play using their library... It's rather old, however, there might be something they've fixed. I'll have a look and see if I can upgrade it.

I have to say (and this is Persona in general, not your site) the password dialogue freaks me out. I click BrowserID on your site, it opens a popup and it asks me to enter my email address, I enter one of them, and then it suddenly expects me to enter a password. Which password? My email password? On a site that isn't my email provider? Or another password? Or an existing password? Or... huh?

I think Persona really needs to sort that out, it's completely non obvious.

I agree with that, the copy needs a bit of an overhaul to make it more straightforward.