[LINK] Mozilla BrowserID to kill pseudonymity?

Roger Clarke Roger.Clarke at xamax.com.au
Sat Jul 16 16:59:48 AEST 2011


[Lauren Weinstein picked this announcement up very quickly.

[Kick me if I'm being unduly sceptical, but it seems to me that:
(1)  the individual's private key is now one-to-one associated with
      the instance of the browser that the person runs
(2)  that browser is uniquely identified by fingerprinting methods
(3)  the individual's private key is also one-to-one associated with
      the individual's email-address
(4)  ergo the email-address, browser-instance and IP-address are all
      tightly and reliably correlated

[So, by using this system, a person volunteers highly reliably 
linkages among all elements of their identity.

[Possible reactions of the inveterate paranoid:
-   'I thought it was supposed to be Google that the CIA owned;
     but maybe it's Mozilla as well'
-   'I thought the open-source crowd had shown serious signs of
     becoming marketer-driven with HTML5 and all the other features
     of the recent releases of their browser;  but now they've made
     clear that their products are marketer-friendly / consumer-hostile'
-   'I don't think onions will be a sufficient antidote to this one'

[Someone please show me I've got this all wrong.


Mozilla's BrowserID aims to simplify authentication on the Web
By Ryan Paul
Published 15 July 2011 ... about 3 hours ago
http://arstechnica.com/web/news/2011/07/mozillas-browserid-aims-to-simplify-authentication-on-the-web.ars

Mozilla aims to simplify account registration and authentication on 
the Web with a new technology called BrowserID. It is a decentralized 
authentication system allows the Web browser to manage the user's 
identity.

https://browserid.org/
http://identity.mozilla.com/

The system relies on asymmetric keys and ties the user's identity to 
their e-mail address rather than conventional usernames and 
passwords. The browser handles the authentication process for the 
user, enabling relatively secure single-click logins on websites that 
support the scheme.
The login flow is relatively straightforward. The user navigates to 
the website of their identity authority provider and logs in 
conventionally. The authority provider website calls a browser 
JavaScript API that generates a key pair. The browser sends the 
public key to the identity provider and gets back a signed identity 
certificate. The browser will then store the private key and 
certificate in its secure keyring.
When a website wants a user's identity, it calls a JavaScript 
function that will cause the browser to initiate the authentication 
process. The browser will prompt the user to determine which identity 
to use and whether to log in at all. If the user agrees, the browser 
will send the requesting website an identity certificate signed with 
the user's private key. The website then obtains the user's public 
key from the identity provider and uses it verify the authenticity of 
the provided identity information.
The authentication process is largely transparent to the end user. 
All you will have to do is click a user interface element in the 
browser to approve the login. BrowserID conceptually similar to 
OpenID in a lot of ways, but without the usability problems and some 
of the other pain points.
Of course, the authentication process described above makes several 
assumptions: the user's browser implements the relevant JavaScript 
APIs, the website that the user wants to sign into supports the 
service and handles the verification step on its own, and the user's 
e-mail host serves as an identity provider. That's obviously the 
ideal scenario, but the protocol supports some other variations on 
the authentication process that will simplify a few of the challenges.
If the user's e-mail host doesn't act as an identity authority, it's 
possible to use a trusted secondary identity authority that does the 
job. In the absence of native BrowserID support in the user's Web 
browser, it's also possible to use an implementation hosted on a 
website. It's also worth noting that the actual process of verifying 
the identity can be performed by a trusted third-party, thus vastly 
reducing the amount of effort involved for Web application developers 
to support BrowserID logins.
Mozilla has set up a website called BrowserID.org that supplies these 
services. This will make it possible to start testing and 
implementing BrowserID right away without having to wait for adoption 
by e-mail providers and other browser vendors.
The concept is pretty good, but there are still some unanswered 
questions. It's unclear if major e-mail hosts and browser vendors are 
going to be interested in supporting the system. The specifications 
are still being finalized, so the effort to encourage adoption is 
obviously still at a very early stage. It's also not entirely clear 
yet what steps e-mail hosts will have to take to support BrowserID. 
It's generally understood that they will have to host public keys and 
make them accesible in a standardized way, but how exactly that will 
work hasn't been specified yet.
Another question is how BrowserID authentication will be handled in 
native desktop and mobile client applications outside of the Web 
browser. Individual applications may need to operate as BrowserID 
user agents and have their own internal implementation of the 
protocol. The application would provide an embedded browser window in 
which the user would log into their identity authority account so 
that the app can get the keys.
That will get really complicated and sort of ugly, but the problem 
could eventually be solved better by having the underlying operating 
system itself implement BrowserID and store the keys in a central 
keyring. There could be platform-level APIs for developers that allow 
a third-party client application to log into Web services with 
identities from the system keyring. The process could be mediated by 
the operating system so that the user has the opportunity to select 
an account or deny the login. The mobile platform vendors could 
probably do it without much trouble, but it will likely take more 
time for this to be supported on the desktop.
You can get more information about the protocol by visiting 
BrowserID.org or Mozilla's new identity website.

-- 
Roger Clarke                                 http://www.rogerclarke.com/
			            
Xamax Consultancy Pty Ltd      78 Sidaway St, Chapman ACT 2611 AUSTRALIA
                    Tel: +61 2 6288 1472, and 6288 6916
mailto:Roger.Clarke at xamax.com.au                http://www.xamax.com.au/

Visiting Professor in the Cyberspace Law & Policy Centre      Uni of NSW
Visiting Professor in Computer Science    Australian National University



More information about the Link mailing list