61–70 of 188 posts
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…
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…
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.
Earlier quoted context omitted.
I agree that email address != identity, but nothing would stop a site that uses BrowserID from allowing a user to change the email address that they use on that site. It's very similar to the countless existing services that rely on email for identity... you'd just have to verify ownership of the new email address (usually through a confirmation email).
Sure, every website can implement this flow, and users could could go to every website they've ever logged into and update their email address... assuming it all works properly even though they might not have access to the old email address anymore. At the very best this technology offers considerably less value to websites and more hassle to users than Facebook or Google. And it's about 5 years too late.
And how is this different than the current situation? Nearly all web sites require an email address. With BrowserID, you at some point confirmed ownership of that email address, so you could continue to use it to login, then change when you're ready.
"At the very best this technology offers considerably less value to websites and more hassle to users than Facebook or Google. And it's about 5 years too late."
Tell that to users who a) don't have Facebook accounts or b) don't want to use Google or Facebook with their identity. Far more people have email addresses than Facebook or Google accounts.
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…
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 News) that uses BrowserID.
5. Your browser sends Hacker News an message saying "my user is whoever@gmail.com", that is signed with the private key generated in step 2.
6. Hacker News looks at the "gmail.com", grabs gmail's public key (the one that signed your public key in step 3) and verifies the signatures.
Hacker News now knows that you control whoever@gmail.com.
The process is described fairly well (diagrams and everything) at http://lloyd.io/how-browserid-works
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…
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?
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.
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…
Properly implemented, OpenID looks like this to the user: http://springpadit.com/login
And something like this for the average developer: https://github.com/omab/django-social-auth
You can try it live at http://textchannels.com/ . I like it , it's pretty simple and neat. Easier than oauth login.