about BrowserId and Unhosted

6 views
Skip to first unread message

Michiel de Jong

unread,
Aug 8, 2011, 9:14:41 AM8/8/11
to unhosted
Hi!

i've been mentioning periodically that i find BrowserId really nice, and that it's a very good fit for what we're trying to do. There are three arguments against it:

- we may never get rid of browserid.org. implementing browser compatibility is doable, but we also need the big identity providers to play along. Google is investing so much in restricting their products to people who are logged in with a google account, that it's unclear to me whether they will support such an open standard as BrowserId (both as an IdP and as a browser/device manufacturer). Of explorer we know that they're always a bit behind, and mostly, their users stay behind on updates. Even if BrowserId makes it into Explorer 10, there will still be people using Explorer 6, 7, 8 and 9. Hotmail does not even provide webfinger, so it's not so likely either that they'll be among the first to become identity providers. If we don't get rid of browserid.org, then we've basically created a centralized login system. Mind you, that will still be better than Facebook Connect. but, it's not what we want.

- making identity work better will make anonymous browsing more rare. some sort of single-session account could be invented for this. this goes for unhosted accounts themselves as well, by the way.

- the current api does not provide a ttl/keepalive/timeout mechanism. this means that if you change your password, you will have to manually  log out any sessions you may have open at relying parties. relying parties should be aware that switching from password-based to browserid-based requires them to either restrict themselves to single-parallel-session, or provide a control panel where you can remotely log out sessions that are running on other devices.

the main positive points (in case they aren't obvious):
- afaics it's the only open standard that can measure up to facebook connect from the point of view of both user experience, and developer experience. you don't have to type anything, not even your webfinger user address.
- it is very, very necessary to have something like this. Google seem to be going towards building a browser that only works with a google account. Apple seem to be going towards building devices that only work with an iCloud account. They're basically reinventing the web, using devices as app browsers, App Store as a censored DNS server, iCloud as their network protocol, and Objective-C as their proprietary replacement for html5. Facebook in the meantime is winning not only the online identity war, but also the 'deep integration' war. We should make the web more remixable. i see BrowserId as part of that.

Going through the centralized browserid.org is a necessary risk, i think. at any time, say a year from now, we can decide whether to stop supporting the browserid.org shim, and tell people to update their browser. or we can review the situation. but i think it will work, and we should back it.

Restricting parallel sessions is already necessary for the end-to-end encryption that we use. We should simply be aware of it. Either allow only one tab open at the same time, or provide a 'log out everywhere' button that signs you out of all current sessions (in case you want to change your password).


Cheers!
Michiel
Reply all
Reply to author
Forward
0 new messages