Re: [saag] Liking Linkability

Henry Story <> Fri, 19 October 2012 14:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA19E21F86A0 for <>; Fri, 19 Oct 2012 07:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gfmQGMssyR-I for <>; Fri, 19 Oct 2012 07:16:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 62AEF21F85E7 for <>; Fri, 19 Oct 2012 07:16:27 -0700 (PDT)
Received: by with SMTP id d4so265926eek.31 for <>; Fri, 19 Oct 2012 07:16:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=RQkvGOw4UUzro/pd7YbRycfT3SRM62e/GrhqjilTtA4=; b=C+KIbMye/afI50IXB7rUYJXbxwzH7uylW2g4NJPFNTG2XBlyGdYcsIpdO3BplXnPqr 0fX/j52LZXEBrxkyX7jwZ1fYA7axAeMYD2f85+ccyYScJoQDJ0Lk3DbYI84bwbyrCN8p VREHyuyilKFf2XhIlcWdP+k6EbpM4S/iDnZtT1YtR6wzg24hAmS4dFUglsvCtLcUfY52 bWUE/xBN264+JyZ7hiElBmprfyD9V5UfT2DfPs2zUQmVucosr6W3/6LdCWTYggHPw0CV umqrf0nnabIjUPA/5Ie4nzpcoxP5xj8mrSF8lqHLwW5SCmqFzVevR1wGuS7FbiuWx+T2 3eVA==
Received: by with SMTP id l48mr2155997een.9.1350656186420; Fri, 19 Oct 2012 07:16:26 -0700 (PDT)
Received: from bblfish.home ( []) by with ESMTPS id t7sm2782832eel.14.2012. (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 07:16:16 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_C2472782-3D6F-43C5-A3FE-E77CC86442EE"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Henry Story <>
In-Reply-To: <>
Date: Fri, 19 Oct 2012 16:16:13 +0200
Message-Id: <>
References: <> <> <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <> <> <> <> <> <>
To: Ben Laurie <>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQnwBsW2DjlxbSSVXCT+DoK50kpjSEXSqzDa0SycOfLhFZrTwjDAPeyPn16Oy7B7BaOY1hFT
Cc: "" <>, "" <>, "" <>, "" <>, Sam Hartman <>, "" <>
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: Fri, 19 Oct 2012 14:16:29 -0000

On 19 Oct 2012, at 15:52, Ben Laurie <> wrote:

> On 19 October 2012 14:46, Henry Story <> wrote:
>> On 19 Oct 2012, at 15:31, Ben Laurie <> wrote:
>>> On 19 October 2012 13:01, Henry Story <> wrote:
>>>> On 18 Oct 2012, at 21:29, Ben Laurie <> wrote:
>>>>> On Thu, Oct 18, 2012 at 8:20 PM, Henry Story <> wrote:
>>>>>> On 18 Oct 2012, at 21:04, Mouse <mouse@Rodents-Montreal.ORG> wrote:
>>>>>>>> [...]
>>>>>>>> Unfortunately, I think that's too high of a price to pay for
>>>>>>>> unlinkability.
>>>>>>>> So I've come to the conclusion that anonymity will depend on
>>>>>>>> protocols like TOR specifically designed for it.
>>>>>>> Is it my imagination, or is this stuff confusing anonymity with
>>>>>>> pseudonymity?  I feel reasonably sure I've missed some of the thread,
>>>>>>> but what I have seem does seem to be confusing the two.
>>>>>>> This whole thing about linking, for example, seems to be based on
>>>>>>> linking identities of some sort, implying that the systems in question
>>>>>>> *have* identities, in which case they are (at best) pseudonymous, not
>>>>>>> anonymous.
>>>>>> With WebID ( ) you have a pseudonymous global identifier,
>>>>>> that is tied to a document on the Web that need only reveal your public key.
>>>>>> That WebID can then link to further information that is access controlled,
>>>>>> so that only your friends would be able to see it.
>>>>>> The first diagram in the spec shows this well
>>>>>> If you put WebID behind TOR and only have .onion WebIDs - something that
>>>>>> should be possible to do - then nobody would know WHERE the box hosting your
>>>>>> profile is, so they would not be able to just find your home location
>>>>>> from your ip-address. But you would still be able to link up in an access
>>>>>> controlled manner to your friends ( who may or may not be serving their pages
>>>>>> behind Tor ).
>>>>>> You would then be unlinkable in the sense of
>>>>>> [[
>>>>>>    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).
>>>>>> ]]
>>>>>> from any person that was not able to access the resources. But you would
>>>>>> be linkable by your friends. I think you want both. Linkability by those
>>>>>> authorized, unlinkability for those unauthorized. Hence linkability is not
>>>>>> just a negative.
>>>>> I really feel like I am beating a dead horse at this point, but
>>>>> perhaps you'll eventually admit it. Your public key links you.
>>>> The question is to whom? What is the scenario you are imagining, and who is
>>>> the attacker there?
>>>>> Access
>>>>> control on the rest of the information is irrelevant. Indeed, access
>>>>> control on the public key is irrelevant, since you must reveal it when
>>>>> you use the client cert.
>>>> You are imagining that the server I am connecting to, and that I have
>>>> decided to identify myself to, is the one that is attacking me? Right?
>>>> Because otherwise I cannot understand your issue.
>>>> But then I still do not understand your issue, since I deliberately
>>>> did connect to that site in an identifiable manner with a global id.
>>>> I could have created a locally valid ID only, had I wanted to not
>>>> connect with a globally valid one.
>>>> So your issue boils down to this: if I connect to a web site deliberately
>>>> with a global identifier, then I am globally identified by that web site.
>>>> Which is what I wanted.
>>>> So perhaps it is up to you to answer: why should I not want that?
>>> I am not saying you should not want that, I am saying that ACLs on the
>>> resources do not achieve unlinkability.
>> Can you expand on what the dangers are?
>>>>> Incidentally, to observers as well as the
>>>>> server you connect to.
>>>> Not when you re-negotiation I think.
>>> That's true, but is not specified in WebID, right? Also, because of
>>> the renegotiation attack, this is currently insecure in many cases.
>> WebID on TLS does rely on TLS. Security is not a goal one can reach,
>> it is a way of travelling. So I do expect every security protocol to
>> have issues. These ones are being fixed, and if more people build on
>> them, the priority of the need to fix them will grow faster.
>>>> And certainly not if you use Tor, right?
>>> Tor has no impact on the visibility of the communication at the server end.
>> You really need to expand on what the danger is. Because again
>> I think you are thinking of the site I am connecting to as the attacker.
>> But I may be wrong.
> I'm getting quite tired of this: the point is, you cannot achieve
> unlinkability with WebID except by using a different WebIDs. You made
> the claim that ACLs on resources achieve unlinkability. This is
> incorrect.

The definition of unlinkability higher up is relative to the notion of
an attacker. That is why you cannot just make a statement that WebID
cannot achieve unlinkability without specifying who the attackers are.
Such a sentence is incomplete.

> So yes, the scenario is there are two sites that I connect to using
> WebID and I want each of them to not be able to link my connections to
> the other. To do this, I need two WebIDs, one for each site. ACLs do
> not assist.

Thanks for filling in the picture.

So the difference between us is that your are considering situations
where you wish to identify to a web site which you think of as an
attacker. There WebID is not the right technology, and indeed very
few technologies may be right - indeed it may be impossible for that
to be used by a large public, since most such attacking sites would 
ask a user for his e-mail address, or a few pieces of information that
together are linkable, and link him/her.

In the situations we are considering with WebID the sites we are 
connecting to are not thought of as the enemy. Now I agree we should 
add a  privacy/security section to the spec ( ISSUE-68 [1] ) that
makes this limitation clear.
  In some situations this is problematic. But for creating a distributed
SocialWeb which is what I am interested in doing, I think this is essential. 
We want to be able to allow friends of friends to work together, create
ad hoc working groups of people with distributed identities, etc... These
are the types of things people do one social networks, we just want to do
those on a global scale with no center of control.

Does that make sense? Would adding that to a privacy section be satisfactory
to you?



Social Web Architect