Live data from Hacker News

Introducing BrowserID: A better way to sign in

identity.mozilla.com

81–90 of 188 posts

Re: Introducing BrowserID: A better way to sign in

#81

Earlier quoted context omitted.

Email is a tool whose value lies primarily in my ability to communicate with other users. Many people (including me) have several email addresses that we use for different purposes. That an email address can be used as an identity is something of an afterthought, and doesn't really fit into the "have multiple email accounts for different communication purposes" paradigm. My Facebook account is an identity first and f…

"My Facebook account is an identity first and foremost." Now imagine 5 years ago you said "My Friendster account is an identity first and foremost."

I'm not saying that identity management won't be an ongoing problem, especially if large repositories of identity rise and fall with fashion.

On the other hand, email is already known to be an unstable key for identity. And the "market" for identity providers is a lot more mature than it was 5 years ago. Besides, what if Friendster had established itself as a public identity provider 5 years ago? Maybe we would be using Friendster instead of Facebook today. Who knows.

Re: Introducing BrowserID: A better way to sign in

#82

Earlier quoted context omitted.

"My Facebook account is an identity first and foremost." Now imagine 5 years ago you said "My Friendster account is an identity first and foremost."

I'm not saying that identity management won't be an ongoing problem, especially if large repositories of identity rise and fall with fashion. On the other hand, email is already known to be an unstable key for identity. And the "market" for identity providers is a lot more mature than it was 5 years ago. Besides, what if Friendster had established itself as a public identity provider 5 years ago? Maybe we would be us…

> On the other hand, email is already known to be an unstable key for identity.

Would be happier if there was only one company that provided email service and you were only allowed to have one address? That's essentially the situation with Facebook.

You're free to apply whatever constraints you like to your use of email. An email address is as unstable an identity as you make it.

Re: Introducing BrowserID: A better way to sign in

#83
post #65
post #52

They seriously need to work on their communication skills. It took me a good 15min to figure out what this thing actually does. And I'm still not sure I got it right. OpenID failed because it was too complicated for mere mortals. This, I fear, may be too confusing. At least form the way it's presented. After reading the protocol spec, I have a somewhat better understanding of this. If I got this right, this is basica…

Ignifero described what happens when your browser or email provider don't support BrowserID. When your browser and email provider both support BrowserID: 1. You log into e.g. gmail. 2. Your browser generates a keypair and sends the public key to gmail. 3. Gmail signs your public key and sends your browser a certificate saying "this key is owned by whoever@gmail.com". 4. You click "sign in" on some site (e.g. Hacker N…

Read through your link, and here's just an observation -

> BrowserID is a decentralized identity system

BrowserID effectively links identity an email service provider, and while I realize that not everyone shares their emails with Google, a vast majority of people still does. That's not that much of decentralization, is it? Practically speaking.

(edit) Added practically speaking... and ease up on that downvoting, distinguished HN comrades. Non-natural post scores hurt my feelings.

Re: Introducing BrowserID: A better way to sign in

#85
post #38
post #23

What I'd really want to see is public-key authentication for website. Let me upload my public key when I create an account on a website, and let the browser interact with my ssh-agent to authenticate.

This already exists, but the UX is terrible and there's a chicken-and-egg problem in getting it fixed in every (deployed) browser. http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-client-c...

[deleted]

Re: Introducing BrowserID: A better way to sign in

#86
post #23

What I'd really want to see is public-key authentication for website. Let me upload my public key when I create an account on a website, and let the browser interact with my ssh-agent to authenticate.

Same here. That's basically what I suggested here: http://news.ycombinator.com/item?id=2677140 Email addresses are typically controlled by a third party, so it doesn't make much sense to me that they should be equated with identity. Would you equate your identity with your IRL work address? On the other hand, private keys are held only by the person whose identity they represent. They are a better way to represent id…

They don't equate with identity but give a way of communicating with the user using a different channel. In a world of passwords this allows that password to be reset.

Re: Introducing BrowserID: A better way to sign in

#87
post #65

Earlier quoted context omitted.

Ignifero described what happens when your browser or email provider don't support BrowserID. When your browser and email provider both support BrowserID: 1. You log into e.g. gmail. 2. Your browser generates a keypair and sends the public key to gmail. 3. Gmail signs your public key and sends your browser a certificate saying "this key is owned by whoever@gmail.com". 4. You click "sign in" on some site (e.g. Hacker N…

Read through your link, and here's just an observation - > BrowserID is a decentralized identity system BrowserID effectively links identity an email service provider, and while I realize that not everyone shares their emails with Google, a vast majority of people still does. That's not that much of decentralization , is it? Practically speaking. (edit) Added practically speaking ... and ease up on that downvoting, d…

"decentralization" doesn't mean "forced decentralization". Anyone can register a domain name and have their own email at that domain, so anyone can create an identity. And ignoring the transitional bits in BrowserID, eventually that identity gets controlled entirely by the public/private keys in the user's browser.

Or, in other words: if you don't trust Google, don't use gmail; that someone else chooses to do so doesn't make this system less secure for you.

Re: Introducing BrowserID: A better way to sign in

#88
post #15

Whilst I understand and really like the non-tied in aspect of it, I'd probably implement some sort of facebook/twitter/google account authentication alongside of it. Reason being is that, it too is just another authentication service that I'd rather users not have to make the effort to sign up for.

The intention seems to be that browserid.org is temporary, just there so that this can work until it's supported by browsers and identity providers directly. Once that is achieved, there's nothing extra to sign up for.

Sorry, the video didnt make that clear - not even slightly.

Re: Introducing BrowserID: A better way to sign in

#89

Earlier quoted context omitted.

They give you a token, you do a GET request to browserid.org with it and get the user's email, that's all. The user has to register their email with browserid.org first.

Wasn't one of the benefits that you don't need to rely on a third party service?

The third-party service handles the case where the user's browser doesn't handle BrowserID natively, which makes it possible to adopt this service without waiting for user's browsers to catch up.

Re: Introducing BrowserID: A better way to sign in

#90
post #65
post #52

They seriously need to work on their communication skills. It took me a good 15min to figure out what this thing actually does. And I'm still not sure I got it right. OpenID failed because it was too complicated for mere mortals. This, I fear, may be too confusing. At least form the way it's presented. After reading the protocol spec, I have a somewhat better understanding of this. If I got this right, this is basica…

Ignifero described what happens when your browser or email provider don't support BrowserID. When your browser and email provider both support BrowserID: 1. You log into e.g. gmail. 2. Your browser generates a keypair and sends the public key to gmail. 3. Gmail signs your public key and sends your browser a certificate saying "this key is owned by whoever@gmail.com". 4. You click "sign in" on some site (e.g. Hacker N…

Why would you want your email provider to support BrowserID? I'd consider it invasive for my email provider to do anything different to interfere with the email verification process for another site.
Post reply on HN