Re: [saag] Liking Linkability

Nathan <nathan@webr3.org> Sun, 21 October 2012 19:52 UTC

Return-Path: <nathan@webr3.org>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FD721F8985 for <saag@ietfa.amsl.com>; Sun, 21 Oct 2012 12:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.199
X-Spam-Level:
X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YV2BP0uKfSSH for <saag@ietfa.amsl.com>; Sun, 21 Oct 2012 12:52:34 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 426F421F84BC for <saag@ietf.org>; Sun, 21 Oct 2012 12:52:33 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so1501184wib.13 for <saag@ietf.org>; Sun, 21 Oct 2012 12:52:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=tLKYGdhwtF+21hugduwJkD9zmUImls8zRdsGLqVdA+o=; b=WfSuHIkqMfLjiF4v4eRwdONGvFhEab0NYclzSh+LTSihEuVFIzKDZ7U6qXoPIYiCFK iXoHbjnBxh+a3YyRqmkCnpRTj2YKZhoDJVMp9DoD+kGit9PWpKAmeMcArjFGgSKLNqJr qnAanTlDCRJuw3eRwf//OkuGju+76Z8zA2D+MxMgTr9oEwt1/Y9CaeinkPveLBoAFIXh U41DO1Q1TEaR1hptX0B8VXaWDLoWQB8MxfxlAc4S752hlDLtko3abN6m63cA1zfH3d8r wXTDeiG6cA1CPPXOgBnuhJ9wL93jjXDSEHaggQU8i+DA9cukQr6yTklu4RcYLjGgysXj lDcQ==
Received: by 10.180.101.230 with SMTP id fj6mr16305289wib.16.1350849153106; Sun, 21 Oct 2012 12:52:33 -0700 (PDT)
Received: from [192.168.1.69] (host86-141-252-78.range86-141.btcentralplus.com. [86.141.252.78]) by mx.google.com with ESMTPS id k20sm47593839wiv.11.2012.10.21.12.52.31 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Oct 2012 12:52:32 -0700 (PDT)
Message-ID: <50845268.4010509@webr3.org>
Date: Sun, 21 Oct 2012 20:52:08 +0100
From: Nathan <nathan@webr3.org>
Organization: webr3
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Kingsley Idehen <kidehen@openlinksw.com>
References: <CCA5E789.2083A%Josh.Howlett@ja.net> <tslzk3jsjv8.fsf@mit.edu> <201210181904.PAA07773@Sparkle.Rodents-Montreal.ORG> <FB9E461D-CA62-4806-9599-054DF24C3FD9@bblfish.net> <CAG5KPzxGz+4MywjP4knfbDr2gyvqUZc1HEBXgtaDfYT+DPg5yg@mail.gmail.com> <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net> <CABrd9SQghpi6_rVQKxYXZDtM5HwvE7Kq7SUw5zi41ZRd3y2h9A@mail.gmail.com> <4324B524-7140-49C0-8165-34830DD0F13B@bblfish.net> <CABrd9SQU1uYVaVPedokHxeYkT=759rkPFfimWK1Z8ATzo3yNFA@mail.gmail.com> <5083CCCF.2060407@webr3.org> <50842789.3080301@openlinksw.com>
In-Reply-To: <50842789.3080301@openlinksw.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQndEph5iwWBp97pIBEUlDXKsAfQbMu+5ta7RrT5n/bKQWQDmc7LSCw7wO5GgURY7Os8nHyn
X-Mailman-Approved-At: Mon, 22 Oct 2012 08:25:26 -0700
Cc: "public-philoweb@w3.org" <public-philoweb@w3.org>, Sam Hartman <hartmans-ietf@mit.edu>, "public-identity@w3.org" <public-identity@w3.org>, "saag@ietf.org" <saag@ietf.org>, Melvin Carvalho <melvincarvalho@gmail.com>, "public-privacy@w3.org" <public-privacy@w3.org>, "public-webid@w3.org" <public-webid@w3.org>
Subject: Re: [saag] Liking Linkability
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: nathan@webr3.org
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Oct 2012 19:52:35 -0000

Kingsley Idehen wrote:
> On 10/21/12 6:22 AM, Nathan wrote:
>> Ben Laurie wrote:
>>> 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.
>>
>> You're 100% correct here Ben, and I'm unsure why it's so hard to convey!?
>>
>> If you use the same identifier for more than one request, subsequent 
>> requests can be associated with the first request. An identifier here 
>> is any identifying, stable, information - key parts and URIs.
>>
>> If the issue is only unlinkability across sites, then you just have a 
>> keypair+uri per site. Or better, key-pair only, and that's associated 
>> with an identifier for the agent behind the interface.
>>
>> You're correct that ACLs won't cut it.
>>
>>
>>
>>
>>
> Nathan,
> 
> What is the subject of unlinkability ?
> 
> I am sure you know that Henry and I are fundamentally referring to 
> nebulous real-world entities such as "You" and "I". A composite key of: 
> machine name, user agent name, and a document referrer links != said 
> neboulus entity. Even further away in today world of multiple form 
> factor devices that interact with the Internet and Web.
> 
> There is no precise mechanism for electronically nailing down nebulous 
> entity "You" and "I". We aren't of the Internet or Web, so you can 
> apprehend us in person. At best you can speculate that we are the 
> subjects of tokens comprised of composite keys.
> 
> Unlinkability is subject to context fluidity and temporality once you 
> add neboulus congnitive entites (not of the Web or Internet) to the 
> equation. I believe you know this anyway :-)

We cannot say that a URI refers to "you" or "I" in one breathe, and say 
it doesn't (or may not) in another.

There is a use case which provides a technical requirement here, one 
which is simply to not use identifiable information between requests to 
different origin servers, and sometimes more granular, not using the 
same identifiable information between requests to the same server.

WebID, just like any auth protocol can be used, it just means using it 
on a one time basis, or only for a particular origin.

Personally I feel there are still questions here with WebID, as 
currently people use usernames/emails and passwords almost everywhere, 
and they can pick different usernames/emails/passwords on every 
site/origin. Suppose WebID was to gain 100% adoption overnight, we'd 
suddenly be in a position where everybody usually used the same 
identifier (rather than usernames and email addresses) and the same key 
(rather than multiple passwords) - because we've never been in a world 
like that, we don't know the consequences yet.

Thus, when security and identity experts suggest that we need to handle 
unlinkability, or consider that we may often need per origin WebIDs (or 
even have that as the default mode), then we may be wise to say "okay", 
go away and find our options, then report them back for consideration 
and review.

It by no means limits WebID, rather it just makes it applicable to a 
broader range of use cases.

Best as always,

Nathan