W3C home > Mailing lists > Public > public-privacy@w3.org > October to December 2012

Re: [saag] Liking Linkability

From: Henry Story <henry.story@bblfish.net>
Date: Mon, 22 Oct 2012 16:04:17 +0200
Cc: Ben Laurie <benl@google.com>, public-identity@w3.org, "public-privacy@w3.org list" <public-privacy@w3.org>, public-webid@w3.org, saag@ietf.org
Message-Id: <5FB468E4-BDD3-4635-ACD0-A23540C08751@bblfish.net>

On 22 Oct 2012, at 14:32, Harry Halpin <hhalpin@w3.org> wrote:

> On 10/22/2012 02:03 PM, Kingsley Idehen wrote:
>> On 10/22/12 7:26 AM, Ben Laurie wrote:
>>> On 22 October 2012 11:59, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>>> On 10/22/12 5:54 AM, Ben Laurie wrote:
>>>>> Where we came in was me pointing out that if you disconnect your
>>>>> identities by using multiple WebIDs, then you have a UI problem, and
>>>>> since then the aim seems to have been to persuade us that multiple
>>>>> WebIDs are not needed.
>>>> Multiple WebIDs (or any other cryptographically verifiable identifier) are a
>>>> must.
>>>> 
>>>> The issue of UI is inherently subjective. It can't be used to objectively
>>>> validate or invalidate Web-scale verifiable identifier systems such as
>>>> WebID or any other mechanism aimed at achieving the same goals.
>>> Ultimately what matters is: do users use it correctly? This can be tested :-)
>>> 
>>> Note that it is necessary to test the cases where the website is evil,
>>> too - something that's often conveniently missed out of user testing.
>>> For example, its pretty obvious that OpenID fails horribly in this
>>> case, so it tends not to get tested.
>> 
>> Okay.
>>> 
>>>> Anyway, Henry, I,  and a few others from the WebID IG (hopefully) are going
>>>> to knock up some demonstrations to show how this perceived UI/UX
>>>> inconvenience can be addressed.
>>> Cool.
>> 
>> Okay, ball is in our court to now present a few implementations that address the UI/UX concerns.
>> 
>> Quite relieved to have finally reached this point :-)
> 
> No, its not a UI/UX concern, although the UI experience of both identity on the Web and with WebID in particular is quite terrible, I agree.

It completely depends on the browsers: 
http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection
If you are on Linux just file a bug request to your browser if you are unhappy, or even better hack up a good UI. It's easy: just make it simpler.

> 
> My earlier concern was an information flow concern that causes the issue with linkability, which WebID shares to a large extent with other server-side information-flow.

Including BrowserId. Which has 2 tokens that can be used to identify the user across sites:

  - an e-mail address ( useful for spamming )
  - a public key, which can be used to authenticate across sites


> As stated earlier, as long as you trust the browser, BrowserID does ameliorate this.

No it does not improve linkability at all. Certainly not if you think the site you are authenticating to is the one you should be worried about, because just using a public key
by itself is enough for Linkability in the strict (paranoid) sense. That is if you 
consider the site you are logging into to as the attacker, then by giving two sites
a public key where you have proven you control the private key is enough for them to know that
the same agent visited both sites. That is because the cert:key relation is inverse functional.

So in simple logical terms if you go to site1.org and identify with a public key pk,
and they create a local identifier for you <http://site1.org/u123>, and then you go site s2.net and identify with the same public key pk  and they give you an identifier <http://s2.net/lsdfs> 
(these need not be public) and then they exchange their information, then each of the sites would have the following relations ( written in http://www.w3.org/TR/Turtle )

 @prefix cert: <http://www.w3.org/ns/auth/cert#>

 <http://site1.org/u123> cert:key pk .
 <http://s2.net/lsdfs>   cert:key pk .

because cert:key is defined as an InverseFunctionalProperty 
( as you can see by going http://www.w3.org/ns/auth/cert#key )

Then it follows from simple owl reasoning that

  <http://site1.org/u123> == <http://s2.net/lsdfs> .

One cannot get much simpler logical reasoning that this, Harry.


> There is also this rather odd conflation of "linkability" of URIs with hypertext and URI-enabled Semantic Web data" and linkability as a privacy concern.

I am not conflating these.

My point from the beginning is that Linkability is both a good thing and a bad thing. 

As a defender of BrowserId you cannot consistently attack WebID for linkability concerns and find BrowserId not to have that same problem. So I hate to reveal this truth to you: but we have to fight this battle together.

And the battle is simple: the linkability issue is only an issue if you think the site you
are authenticating to is the enemy. If you believe that you are in relation with a site that
is under a legal and moral duty to be respectful of the communication you are having with it,
then you will find that the linkability of information with that site and across sites is exactly what you want in order to reduce privacy issues that arise out of centralised systems.

> 
> I do think many people agree stronger cryptographic credentials for authentication are a good thing, and BrowserID is based on this and OpenID Connect has (albeit not often used) options in this space.  I would again, please suggest that the WebID community take on board comments in a polite manner and not cc mailing lists.

All my communications have been polite, and I don't know why you select out the WebID community.
As for taking on board comments, why, just the previous e-mail you responded to was a demonstration that we are: CN=WebID,O=∅



>> 
>> 
>> 
> 

Social Web Architect
http://bblfish.net/



Received on Monday, 22 October 2012 14:04:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 October 2012 14:04:54 GMT