Re: [saag] Liking Linkability

Melvin Carvalho <> Mon, 22 October 2012 15:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D803021F8C52 for <>; Mon, 22 Oct 2012 08:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5hQQxcltTOPX for <>; Mon, 22 Oct 2012 08:25:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6F31921F8C09 for <>; Mon, 22 Oct 2012 08:25:26 -0700 (PDT)
Received: by with SMTP id o25so2573384iad.31 for <>; Mon, 22 Oct 2012 08:25:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9TBiweNlQJgatBKvXqPLl5UzsXDfQEFZ5+YReX1Kj1Q=; b=Q7OY3eemCZDEwPPG1QYnfglZQc8OYj9v+RJ2k8FvDDJdXfe5iMyDg0VzhldNYxmdKt U0+mi6e4glwGpmw02YVEkLU0MCzVVK7ZhzL6tvC7GvU2TrAmGAIzYYVuzxrcKnBH9fxl z19t3DWm71KokM4kAHeCAfE+MO6pLD6d0RZamLPrlADQpUMooiXfL0eC5kBaZ8cKXfpl k88eA3IVSekrHpB5sVMJw5rTd6niI9Ld8/+pnApF8ctyJyR6mlB3cOVYTGGwhp3kFW0D ohZIfAIMBWJ9emRlVCg4NLugKWv1ZqEGHdeBVdNUvvSzFKAdNRonysWj9YzHk7TCb7jZ ejNQ==
MIME-Version: 1.0
Received: by with SMTP id cf8mr16601802igb.20.1350919521737; Mon, 22 Oct 2012 08:25:21 -0700 (PDT)
Received: by with HTTP; Mon, 22 Oct 2012 08:25:21 -0700 (PDT)
In-Reply-To: <>
References: <> <> <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Mon, 22 Oct 2012 17:25:21 +0200
Message-ID: <>
From: Melvin Carvalho <>
To: Harry Halpin <>
Content-Type: multipart/alternative; boundary=e89a8f3b9d3d369d5f04cca7763e
X-Mailman-Approved-At: Tue, 23 Oct 2012 14:09:57 -0700
Cc:,, " list" <>,
Subject: Re: [saag] Liking Linkability
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Oct 2012 15:25:29 -0000

On 22 October 2012 17:14, Harry Halpin <> wrote:

> On 10/22/2012 04:04 PM, Henry Story wrote:
>> On 22 Oct 2012, at 14:32, Harry Halpin <> 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 <>
>>>>> 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:
>> 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 and identify with a
>> public key pk,
>> and they create a local identifier for you <>, and
>> then you go site and identify with the same public key pk  and
>> they give you an identifier <>
>> (these need not be public) and then they exchange their information, then
>> each of the sites would have the following relations ( written in
>> )
>>   @prefix cert: <**cert#<>
>> >
>>   <> cert:key pk .
>>   <>   cert:key pk .
>> because cert:key is defined as an InverseFunctionalProperty
>> ( as you can see by going**cert#key<>)
>> Then it follows from simple owl reasoning that
>>    <> == <> .
>> 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.
> To quote the IETF document I seem to have unsuccessfully suggested you
> read a while back, the linkability of two or more Items Of Interest (e.g.,
> subjects, messages, actions, ...) from an attacker's perspective  means
> that within a particular set of information, the attacker  can distinguish
> whether these IOIs are related or not (with a high enough degree of
> probability to be useful) [1]. If you "like linkability", that's great, but
> probably many use-cases aren't built around liking linkability.

Harry, this document has been discussed in detail in the WebID group.
Thank you for bringing it to our attention.

I cant help but reflect at this point, that the only reason, that this
conversation has been made possible, is due to the "linkability" property
of the e-mail protocol. :)

>  This has very little with hypertext linking of web-pages via URIs. I
> think you want to use the term "trust across different sites" rather than
> linkability, although I see how WebID wants to conflate that with trust,
> which no other identity solution does.  A link does not necessarily mean
> trust, especially if links aren't bi-directional.
> As explained earlier, Mozilla Personae/BrowserID uses digital signatures
> where an IDP signs claims but transfers that claim  to the RP via the
> browser (thus the notion of "different information flow") and thus the RP
> and IDP do not directly communicate, reducing the linkability of the data
> easily gathered by the IDP (not the RP).
> I know WebID folks believe IDP = my homepage, but for most people IDP
> would likely not be a homepage, but a major identity provider for which
> data minimization principles should apply, including ownership of the
> social network data of an individual and a history of their interactions
> with every RP. I am not defending BrowerID per se: Personae assumes you
> trust the browser, which some people don't. Also, email verification, while
> common, is not great from a security perspective, i.e. STARTLS not giving
> error messages when it degrades.
> Perhaps a more productive question would be why would someone use WebID
> rather than OpenID Connect with digital signatures?
> Although, I have ran out of time for this for the time being.
>> 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