- From: Ben Laurie <benl@google.com>
- Date: Thu, 27 Sep 2012 12:09:00 +0100
- To: Henry Story <henry.story@bblfish.net>
- Cc: public-webid@w3.org, Andrei Sambra <andrei@fcns.eu>
On 27 September 2012 11:22, Henry Story <henry.story@bblfish.net> wrote: > > On 27 Sep 2012, at 12:13, Ben Laurie <benl@google.com> wrote: > > > > On 27 September 2012 10:59, Henry Story <henry.story@bblfish.net> wrote: >> >> >> On 27 Sep 2012, at 11:45, Ben Laurie <benl@google.com> wrote: >> >> On 27 September 2012 10:02, Henry Story <henry.story@bblfish.net> wrote: >> >> >> On 27 Sep 2012, at 10:38, Ben Laurie <benl@google.com> wrote: >> >> On 27 September 2012 09:31, Henry Story <henry.story@bblfish.net> wrote: >> >> >> On 27 Sep 2012, at 09:57, Ben Laurie <benl@google.com> wrote: >> >> On 26 September 2012 13:50, Henry Story <henry.story@bblfish.net> wrote: >> >> On 26 Sep 2012, at 13:59, Ben Laurie <benl@google.com> wrote: >> >> The easy interface works well only if you are happy with a small >> number of identities - i.e. linkability across almost everything. >> Also, note that this kind of thing was tried with Microsoft's >> InfoCards and also with OpenID. It didn't go so well. >> >> >> Microsoft's info cards was a centralised solution I believe. Here we are >> using only open web standards: HTTP, TLS, RDF, Linked Data. Which allows >> everybody - individuals as well as large institutions to participate. We are >> not excluding anyone here. >> >> >> No, infocards were decentralised. >> >> >> And they permitted a distributed web of trust? I really doubt they had the >> tools to work with that, in part because it requires open standards such as >> those behind LinkedData (HTTP+RDF) for it to make sense. >> >> But that's really not the point - >> the point was that they involved similar choices amongst a large >> number of possibilities, and it turned out to be hard to use. >> >> >> it cannot have been a similar choice among these number of possibilities. >> They did not have LinkedData ( that meme only really appeared in 2006 or so, >> and has been growing slowly and steadily since then . see for example Tim's >> 2009 Ted Talk http://www.ted.com/talks/tim_berners_lee_on_the_next_web.html >> ) >> >> Think about this: if you are from Google - a company whose life is based >> on the Web, was built on the web, and whose core algorithm is based on the >> linking of pages - but who still is largely new to LinkedData, you can >> imagine that Microsoft, a much older company with a lot more legacy, is >> going to be much slower in embracing such a change ( though huge leaps have >> been known to happen ) Also remember they were taking in by the SOAP bubble. >> >> OpenID has a similar problem (its what they call the Nascar problem). >> >> >> We can get rid of the Nascar problem easily. I think someone may already >> have implemented an initial example of that using WebID... You just write a >> server that does the following when someone clicks the 1 and only login link >> on the page. >> >> The server requests the client certificate ( asynchronously is best as in >> here https://github.com/bblfish/Play20 ) >> >> IF the user selects a certificate and returns it >> >> >> This is the point at which the Nascar problem occurs: selecting the >> certificate. >> >> >> ( Background of NASCAR problem for those new to this >> http://factoryjoe.com/blog/2009/04/06/does-openid-need-to-be-hard/ ) >> >> No, that is not the problem. Most people nowadays have 2 or 3 payment >> cards, which they can choose from when going into a shop to pay for >> something. Choosing one among a handful personas is easy when logging in >> somewhere. And most users would not have more than a handful of certificates >> to select from when going to a web site. >> >> >> You can't have it both ways: if privacy is protected by using multiple >> certificates, you cannot also restrict people to using 2 or 3. >> >> >> Having multiple identities is one aspect of protecting privacy: it allows >> you to choose which persona you use on which web site - if you want to log >> in that is: anonymity could be considered the null certificate. > > > There are shades of anonymity - I might still want to log in yet be > anonymous (i.e. not linkable to my other logins). The null certificate would > not achieve that. > > > fine. There are other technologies to address those issues. Username > password is one of them. > > >> >> >> There is no need to restrict people to using 2 or 3. There is I believe a >> limit on how many identities people wish to have. > > > The W3C does not seem to agree - > http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html claims > that some people do not want to be correlated across sites. > >> >> The rest is up to browser vendors to improve the User Experience. > > > You can punt on the problem if you want, but it doesn't stop it from being a > problem. > > > yes, the ball is in your court in part as representative of Google. Not really. > Pressure > them to improve the UI, and we will have all have a better privacy > experience. We here can help build a vocal group of people to help your > managers understand the importance of users being aware of the identity they > present to a web site. Chrome tends not to be impressed by vocal minorities - what is needed is users asking for the feature. > > >> >> >> What protects privacy is your >> 1. your browser asking you who you want to be identified when going to a >> site >> 2. your browser showing you who you are logged in - as the attached >> prototype by Aza Raskin shows >> <aza.jpg> >> >> >> >> >> >> The problem is that these selection boxes are predetermined in advance by >> the web site you go to, are confusingly presented differently on each web >> site, and don't in fact give you the freedom of running your own identity >> server. Who would put the University of Oxford identity server up there as >> an option if such existed? >> >> But I could get a University of Oxford certificate and wherever I go to on >> the web if the server asks me for a certificate, I would be given the option >> of using one of the certificates I actually have - not those most people >> usually do have. >> >> The NASCAR problem is one of in your face choice for options you don't >> want, without giving you the options you actually do have. >> >> The server on receiving the certificate. Either >> a. the certificate is CA signed and trusted. Follow usual procedure. >> (though if there is a WebID, you can get extra information that >> would >> otherwise be difficult to put in a cert) >> b. the certificate does not have a CA known to the server and no WebID >> use the public key as a temporary identifier, but suggest linking >> that public key to a number of other >> identification schemes - you're in NASCAR land - but also suggest >> to the user to get a WebID >> c. the certificate does not have a CA known to the server and a WebID >> do WebID identification. >> Else >> do the usual Nascar stuff >> >> In a, b above you have a WebID so you can replace the Nascar box by a >> linking verification process, and you can reduce the immediately visible >> options by using the information from the WebID profile using the >> foaf:holdsAccount relations found in the foaf file: e.g.: no need to suggest >> Facebook login - as a first option - if the user does not in his profile >> declare having an account there. >> >> The above is a back of the envelope sketch of how to do things. Of course >> with a team of good designers you'd develop that carefully and do usability >> tests. >> >> >> Henry >> >> >> Social Web Architect >> http://bblfish.net/ >> > > > Social Web Architect > http://bblfish.net/ >
Received on Thursday, 27 September 2012 11:09:37 UTC