- From: Ben Laurie <benl@google.com>
- Date: Thu, 4 Oct 2012 13:03:51 +0100
- To: Henry Story <henry.story@bblfish.net>
- Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "public-webid@w3.org" <public-webid@w3.org>, public-identity@w3.org, "public-philoweb@w3.org" <public-philoweb@w3.org>
- Message-ID: <CABrd9SRbofnMZxWOvSmr6xEN2EP=nQW+en0-_TzKnNDCeGnJJw@mail.gmail.com>
On 4 October 2012 12:12, Henry Story <henry.story@bblfish.net> wrote: > 2) Practical applications in browser ( see misnamed > privacy-definition-final.pdf ) > > a) It is difficult to associate interesting human information with > cookie based > identity. The browser can at most tell the user that he is connected by > cookie or anonymous. > The presence of a cookie does not imply the absence of anonymity - its hard for the browser to say much beyond "cookies" or "no cookies". And having said it, it is not clear what the user would learn, at least in the "cookies" case. > > b) With Certificate based identity, more information can be placed in > the > certificate to identify the user to the site he wishes to connect to > whilst > also making it easy for the browser to show him under what identity he > is > connected as. But one has to distinguish two ways of using > certificates: > > + traditional usage of certificates > Usually this is done by placing Personal Data inside the > certificate. The > disadvantage of this is that it makes this personal data available to > any web > site the user connects to with that certificate, and it makes it > difficult to > change the _Personal_Data (since it requires changing the certificate). > So here > there is a clash between Data Minimization and user friendliness. > > + webid usage: > With WebID ( http://webid.info/spec/ ) the only extra information > placed in the > certificate is a dereferenceable URI - which can be https based or a > Tor .onion > URI,... The information available in the profile document, or linked to > from that > document can be access controlled. Resulting in increasing _User > Control_ of whome > he shares his information with. For example the browser since it has > the private key > could access all information, and use that to show the as much > information as it > can or needs. A web site the user logs into for the first time may just > be able > to deduce the pseudonymous webid of the user and his public key, that > is all. A > friend of the user authenticating to the web site could see more > information. > So User Control is enabled by WebID, though it requires more work > at the > Access control layer http://www.w3.org/wiki/WebAccessControl You continue to miss my point here, so let me spell it out. Suppose the user, using access control, decides to allow site A see all his data and site B to see none of it. Site B can, nevertheless, collude with site A to get access to all the user's data. First, when the user accesses site A, site A takes a copy of all his data and links it to his public key. Next, the user logs into site B, which tells site A the user's public key. Site A returns the user's data, and now site B also knows it. Clearly if the user uses a different certificate at site B, B and A can no longer collude in this way.
Received on Thursday, 4 October 2012 12:04:19 UTC