W3C home > Mailing lists > Public > public-webid@w3.org > October 2012

Re: Browser UI & privacy - a discussion with Ben Laurie

From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Date: Thu, 4 Oct 2012 15:55:55 +0300
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>, Ben Laurie <benl@google.com>
Message-Id: <804583FE-F53E-4D03-B13A-5E142723F2C0@gmx.net>
To: Henry Story <henry.story@bblfish.net>
Hi Henry, 

The problem in your discussion is that you use terms very loosely and focus far too much on your WebID proposal only. 

I am not sure what you are trying to solve. Are you trying to argue that one solution proposal is better than the other? 

> 
> 1) Basic Principle:

... basic principle of what?

>   The _Identity_ used by the _Individual_ _Initiator_ of a web transaction should at
>   all times be transparent to him, whether the _Identity_ be _Anonymous_ (level 0),
>   Cookie based, _Pseudonymous_, or other.  It should also be within the 
>   _User's control_ to change it. This should be put together with Dr Ian Walden's 
>   remarks on EU law [3]. ( see misnamed privacy-definitions-1Oct.pdf )

If you look at http://tools.ietf.org/html/draft-iab-privacy-considerations-03 then you see terms for 

* identity
* individual

I believe you confuse identity with identifier. 

The concept of a cookie does not fit in the above description.

So, I believe you are saying that you would like to let the user (?) know what information is exchange when using the Web (or even HTTP protocols). While this sounds nice it is practically impossible for an ordinary user to understand any of the stuff that is exchanged. 


> 
> 2) Practical applications in browser ( see misnamed privacy-definition-final.pdf )
> 
This entire paragraph is completely confusing because you mix specific technology with some assumed properties. 
You can use cookies, certificates, etc. in many ways and consequently they would be providing very different properties. 

>   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. 

> 
>   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
> 
> 3) The importance of Linekability to privacy.
> 

Have a look what we call linkability in 
http://tools.ietf.org/html/draft-iab-privacy-considerations-03

   $ Unlinkability:   Within a particular set of information, the
      inability of an observer or attacker to distinguish whether two
      items of interest are related or not (with a high enough degree of
      probability to be useful to the observer or attacker).



>   This is what is unintuitive. and which I develop in 
>   http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-def-1.pdf
> 
>   The ability to have global identifiers is what allows me to put information on my
> web server and share it with only a limited number of people. This is not the same
> useage of unlinkeability as you defined it. So one has to be careful.  I think one
> needs linkeable identities to create a social web that is not centralised. One just
> does not want them to be KNOWN by people who have no business knowning them.
> 
>   So I'd suggest thinking more carefully about the linkeable vocabulary. It 
> can be used to hide some very important ideas, that we really need if we want
> privacy to succeed.
> 
Let me provide a suggestion. In general it helps if you start with a high level idea of what you want to accomplish before going too far into the details. That would at least help me to follow your arguments. 

Ciao
Hannes

> 	Henry
> 
> 
>> 
>> On 10/04/2012 12:54 PM, Henry Story wrote:
>>> The identity groups are currently split up between public-webid, public-xg-webid
>>> (which will now receive all mails from public-webid) and the public-identity
>>> mailing list.
>>> 
>>> On the public-webid mailing lists we recently had a very lengthy
>>> and detailed discussion with Ben Laurie [1], which I think is of interest
>>> to members of these other groups. The archives are quite difficult to read [2]
>>> so I am sending here a resume of some of the highlights. I also attached
>>> the pdf as printed from my e-mail client as it gives color syntax highlighting,
>>> making it much easier to follow.
>>> 
>>> First we spent quite a lot of time I think beating around the bush of
>>> misunderstandings. The first e-mail where things started clearing up
>>> was when I proposed a simple working definition of privacy after a
>>> philosopher friend of mine suggested that our misunderstandings might be
>>> related to an ambiguous and vague use of the terms. The working definition
>>> I proposed was:
>>> 
>>> "A communication between two people is private if  the only people who
>>> have access to the communication are the two people in question. One
>>> can easily generalise to groups: a conversation between groups of people
>>> is private (to the group) if the only people who can participate/read the
>>> information are members of that group..."
>>> 
>>> 
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-def-1.pdf
>> 
>>> 
>>> 
>>> 
>>> We then made big strides by working out where we agreed. We agree that
>>> transparency of identity is important at all times (which seems
>>> to be a potentially EU legal requirement [3]) I discover some new information
>>> about how Google Chrome works, and argue that it still does not satisfy the
>>> original transparency principles we agreed to.
>>> 
>>> 
>>> 
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-definitions-1Oct.pdf
>> 
>>> 
>>> 
>>> After a few more exchanges I show using WebID certificates could
>>> lead to enhanced transparency in identity usage for browsers in the future
>>> 
>>> 
>>> 
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-definition-final.pdf
>> 
>>> 
>>> 
>>> I hope this helps. Btw. The WebID Incubator group will be meeting at TPAC [4],
>>> so see you there for further detailed discussions.
>>> 
>>> 	Henry
>>> 
>>> 
>>> [1] http://en.wikipedia.org/wiki/Ben_Laurie
>>> [2] http://lists.w3.org/Archives/Public/public-webid/2012Sep/thread.html
>>> [3] http://lists.w3.org/Archives/Public/public-webid/2012Oct/0021.html
>>> [4] http://www.w3.org/2012/10/TPAC/
>>> [5] 
>>> 
>> 
> 
> Social Web Architect
> http://bblfish.net/
> 
Received on Thursday, 4 October 2012 12:56:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:37 UTC