Live data from Hacker News

Introducing BrowserID: A better way to sign in

identity.mozilla.com

121–130 of 188 posts

Re: Introducing BrowserID: A better way to sign in

#121

One huge problem: Email address != identity. I should be able to change my email address (and/or email hosting provider) without changing my identity on a bazillion sites around the internet. Facebook got this right from the beginning. Google is sort-of getting this, although the chasm between Google Accounts and Google Apps Accounts makes this really messy. Really this product should be called BrowserEmailAddress, n…

In the literal sense that you are not your e-mail, yes email != identity.

In a practical "on the internet sense," your email really is your identity (maybe SSN or name would be a better description; you can change it, but to do so is catastrophically disruptive). After all if you can't be contacted you really can't be identified, and the universal way of contacting someone online is through email.

Now, you should definitely try and provide some redundancy (store multiple email addresses, long living sessions, whatever) and make your anonymous/unauthenticated/drive-by user experience stellar. But when push comes to shove if you can't send them a "forgot your username/password/open-id/samoflange" email, you've lost that user.

(anecdote: I've had the same primary email for >7 years)

Re: Introducing BrowserID: A better way to sign in

#122
post #115
post #105

Earlier quoted context omitted.

A good way to check if does the right thing is to make sure it does not depend on the security of DNS. Is this the case? (I'm still trying to find out.)

BrowserID implements https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol From that document: "destination.com retrieves Alice's public key from mailhost.com by using a webfinger lookup over SSL." So it looks to me that the system's security depends on the attacker not having compromised DNS such that the relying party's query of mailhost.com is intercepted. Depending on the implementation doing this "over SS…

BrowserID references the verified email protocol as an inspiration, but they specifically removed the webfinger bits.

Re: Introducing BrowserID: A better way to sign in

#123
post #17

Earlier quoted context omitted.

Some people think that using URLs instead of email address in OpenID was a big mistake. Having in-browser support for this kind of thing seems like a plus, too.

To this day I still do not understand how this inane argument happened to be the single thing that killed OpenID. How is ‘cody.my-open-id-provider.com’ more confusing as a login than ‘cody@my-email-provider.com’? Hint: it’s not. I’m not one for conspiracy theories, but the whole URL-versus-email argument against OpenID seemed like the excuse various people used to put a nail in OpenID’s coffin when they didn’t like i…

I'm a reasonably competent web user.

I've implemented OpenID.

I run my own Open ID server.

I've implemented Shibboleth (and lived!).

I know that Yahoo is an open ID provider, and I think Google is too, but when I'm presented with an old-style (URL) OpenId login I don't have a clue what to enter to use either my Yahoo or Google account to login.

Yes, I know that now most login forms provide easy links to use Google or Yahoo to login. The point is that entering the URL is confusing because no one knows what their OpenID url is, and it isn't standardized in anyway.

The situation is so bad that the OpenID providers had to develop a way for users to enter their email addresses, and then the client performs a discovery request to find their URL.

Re: Introducing BrowserID: A better way to sign in

#124
post #8
post #4

How is it different from OpenID, apart from it's not decentralized?

I'm wondering if it's at all possible to integrate this with OpenID, and how this interacts with previous Mozilla Identity projects to make your identity a part of the browser chrome. It all seems rather tangential to their other efforts, rather than coherent with.

I certainly hope it isn't possible to integrate this with OpenID. If it is, sites will just continue relying on OpenID, and treat this as a weird special case, rather than a superseding technology that gives the user control without requiring a third-party provider.

Re: Introducing BrowserID: A better way to sign in

#125
post #42
post #35

Earlier quoted context omitted.

sounds like tracking to me

Ok, but only In the same way that typing in a username and password on a website allows them to track you.

To have a conversation with someone, you have to uniquely identify them, and correlate all the words they've said as coming out of their mouth and not somebody else's, then put all these words (which you've identified as being part of the same sentence) together into meaning. As you get to know someone, you correlate all these meanings into a mental model of the person, and use this to guide how you interact with them. People who can't do this are considered mentally ill.

It's one of the defining pieces of consciousness, and essential to the human experience. So, as programmers, we make a deliberate choice to enable this functionality for end-users in most internet applications (like email, IM, social networking, and discussion boards) by displaying a token belonging to you (and only you) next to what you're saying and doing. This can be a username, email address, phone number, picture, etc. This particular spec is a more convenient way of establishing your ownership of a token used to identify you.

You can choose to use sites (like 4chan) which don't reveal this information publicly. But if you sign your posts, or indicate in any way that you are the same person as a previous poster, you are establishing an identity which 4chan is tracking and revealing to the world. There is no conversation without tracking.

Whether or not the sites you use choose to identify you, however, they know you by the IP address you are coming from; they have to, in order to send information back. Tor can mitigate this (if you change exit nodes with every request) by hiding your path from A to B within a cryptographically secure mass of data, but if the random number generator determining the amount of time to wait before forwarding your packets is broken, that's blown too.

IP addresses change, so if I want to correlate you between your ISP's DHCP leases (or between your multiple internet connections - Starbucks, home, work), I'll set a cookie. This is how when you clicked "reply", Hacker News knew it was still the same person who logged in with "ukaszg/hunter2".

Tracking is essential to civilized conversation. To fight tracking itself is to ask that the entire Internet become 4chan and that nobody assume the same identity from post to post. I hope this isn't what you mean.

--

Tracking makes you nervous because

a) computers exhibiting human behavior is kind of creepy b) sometimes, companies choose to violate users' expectations of what will be done with the information they've correlated

But you can't take this information away from them while still using their services. You can refuse to use services which violate your expectations, you can demand better, and I encourage you to.

But ultimately, these services have to pay the bills and make a profit. I could be wrong, but I'm going to take a wild guess and say you wouldn't pay for Facebook; I'm going to go even further and say that you would be offended at the idea of having to pay for Facebook.

Well, Facebook's employees want to feed their children and buy cars and houses and video games and TVs just like you. And Facebook's owners and investors want to get rich. If these objectives aren't met, there won't be a Facebook.

So instead of taking your money, they take what they can guess about what you will buy, and charge advertisers for it. Advertisers, in turn, can show you products which you won't scoff at paying for, and eventually some less speculative cash enters the equation.

You cannot avoid tracking. But if you want the companies tracking you to conform to your expectation that your data not be used to sell you stuff, you're going to have to pay them. Rackspace email is $2/mailbox/month. There are no ads.

Re: Introducing BrowserID: A better way to sign in

#127

One huge problem: Email address != identity. I should be able to change my email address (and/or email hosting provider) without changing my identity on a bazillion sites around the internet. Facebook got this right from the beginning. Google is sort-of getting this, although the chasm between Google Accounts and Google Apps Accounts makes this really messy. Really this product should be called BrowserEmailAddress, n…

Filed as a bug: https://github.com/mozilla/browserid/issues/58

Re: Introducing BrowserID: A better way to sign in

#128
Thought that popped into my head. Instead of having separate passwords for different sites, now you are trusting your email provider to be absolutely secure (with that one ultra-secure password you are using, right?).

So if a BrowserID user were to ever get their email service compromised, it's keys to the kingdom.

IMO, I think this needs a rethink.

Re: Introducing BrowserID: A better way to sign in

#129
post #119

Earlier quoted context omitted.

Sure, I understand that of course. I am just saying that practically speaking this property is not going to matter much in the world where everyone and their dog is on GMail. It is certainly nice to have though.

The last numbers I saw put Gmail at under 10% of email account marketshare. Hotmail and Yahoo both had much bigger shares. It's difficult to imagine an authentication system that doesn't have some kind of centralized mechanism for making sure identities aren't duplicated. In this case, delegating that to a combination of two existing technologies (DNS for the domain, then email for the username) that are open, well u…

You can have fully decentralized identities quite trivially: just create a public/private key. No consensus algorithms required. With browsers now supporting synchronization features to connect the browsers on all systems used by a single user, such a system could actually work quite well now, without the usability issues it would once have had.

Re: Introducing BrowserID: A better way to sign in

#130
post #51

Earlier quoted context omitted.

Most of the oauth services I used allowed me to create an account with ... an e-mail and a password. Literally the same thing, here.

Isn't one of the advantages of this system is that your password doesn't get stored by the website? Just some type of token? If their database gets stolen or leaked, they shouldn't be able to hash attack your password and gain access to it since it's not there. I'm just assuming it works this way, as passing the password along would defeat the security of the system and make you more vulnerable.

You still have to enter your e-mail and a password into the BrowserID popup; and with OAuth, the sites using it didn't store your password either.

I literally don't see a major difference here, except that now we're using email instead of whatever bullshit identifier you could have used with other OAuth providers (e.g., your Livejournal username, your Facebook account, etc., etc.)

If I'm wrong, I would love to be enlightened.

Post reply on HN