Re: [saag] Liking Linkability

Nathan <nathan@webr3.org> Mon, 22 October 2012 09:43 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 57B8921F8546 for <saag@ietfa.amsl.com>; Mon, 22 Oct 2012 02:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.879
X-Spam-Level:
X-Spam-Status: No, score=-3.879 tagged_above=-999 required=5 tests=[AWL=-0.880, 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 3vVE8ydySemU for <saag@ietfa.amsl.com>; Mon, 22 Oct 2012 02:43:12 -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 0124721F8524 for <saag@ietf.org>; Mon, 22 Oct 2012 02:43:11 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hr7so1837862wib.13 for <saag@ietf.org>; Mon, 22 Oct 2012 02:43:10 -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=nq7wiPI+nL1fQX27xBQN5v+iG0zukpCgf9N4NKGTZAs=; b=Nw/UD3zSKuIUYgK/IYInhDkgnbJ9jULszBvqiGQzEWCbh+EwIaDgaR2mFLInVg6oAc XsqwuAxW1MXlTXBplKheVueFc2lA+kWIhOnr7Z+ZBkXYYbXwjPR2Z9a7LpDT4cA0iN6P SyhLY9ZnhOSvuYrX0pRqJot3hRHBcWdTsZq9t+YVwQDqJkWs2B28RBqVxfNJsCbykDTq WrgyPaIwNqCf49M3N/ci34FO/u2ngFFxdbCb9Qhhzhh7lY7iGWQda3V41EgsQucylm2L QoPNc9LxjCNFT3xkeJeG8t91j7aDnPZJfSmjvvm6JWxV0DwVth09PtUK7qpWK747KeeA d1SA==
Received: by 10.216.197.205 with SMTP id t55mr5353035wen.156.1350898990507; Mon, 22 Oct 2012 02:43:10 -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 p4sm20984069wix.0.2012.10.22.02.43.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Oct 2012 02:43:09 -0700 (PDT)
Message-ID: <50851512.9090803@webr3.org>
Date: Mon, 22 Oct 2012 10:42:42 +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> <50845268.4010509@webr3.org> <5084AC77.8030600@openlinksw.com>
In-Reply-To: <5084AC77.8030600@openlinksw.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQmIN4jCUgRX5BDNOzhqMMo2zuYcUZlcoi5nnSfc3w/23prtRHdUyCyo7fJvkzjjxTv1716+
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: Mon, 22 Oct 2012 09:43:13 -0000

Kingsley Idehen wrote:
> On 10/21/12 3:52 PM, Nathan wrote:
>> 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.
> 
> You raise a good point, Now let me clarify, I don't believe (unless in 
> utter error) that I've ever claimed that a URI definitively refers to 
> "You", "Me", or "I". Of course, I cannot claim to have not made the 
> careless utterances such as "Your Personal URI" , for instance.
> 
> A URI that serves as a WebID has always been a denotation mechanism for 
> a composite key comprised of:
> 
> 1. private key
> 2. public key
> 3. URI that resolves to a profile document that describes a subject via 
> an entity relationship graph.
> 
> The subject of an X.509 certificate is a nebulous entity. This entity is 
> associated with attribute and value pairs that comprise the profile 
> graph imprinted in said certificate. The semantics of an X.509 
> certificate don't change the nature of the certificates subject.
> 
>>
>> 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.
> 
> WebID is a part of the picture, not the picture in its entirety. I've 
> pretty much tried to encourage others to be careful about conveying the 
> misconception that WebID (solely) resolves the issues at hand. It is 
> just a critical piece of the puzzle, that's it.
> 
> You don't need to have a single WebID. Such a thing fails the most 
> mundane alter ego test re. 'Clarke Kent' and 'Superman' or 'Peter 
> Parker' and 'Spiderman'.
> 
> Privacy is about the aforementioned personas not being comprised, under 
> any circumstances. The fact that DC world entities 'Clark Kent' and 
> 'Superman' used the same Web browser shouldn't comprise the alter ego 
> relationship between these personas.
> 
> Unlinkability is about the alter ego paradox.
> 
>>
>> 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.
> 
> See my comments above. Such a system is dead on arrival re. privacy. 
> There have to be multiple WebIDs and the exploitation of logic when 
> dealing with data access policies, and all of this has to occur within 
> specific interaction contexts. For instance, if I want only you to see a 
> document, I could knock up the require security tokens and send them to 
> you via a PKCS#12 file. You open the file then go GET the document in 
> question. Being super paranoid, I would more than likely speak to you 
> via phone about the username and password combo for opening up the 
> PKCS#12 file.
>>
>> 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.
> 
> We need others (note: expert is utterly subjective to me) interested in 
> these matters to be constructive rather than dismissive. I chime in most 
> of the time because I see Henry going to immense pains to explain 
> matters only to be summarily dismissed in manners that I find 
> cognitively dissonant.
> 
> A basic RDBMS product doesn't depend on single attribute/field primary 
> keys, why would such thinking even apply to the complex matter of 
> privacy. When I use the term composite, I am pretty much referring the 
> the same concept well understood in the RDBMS world. You can have a 
> 'super key' comprised of elements that are of themselves unique 
> identifiers.
> 
> I don't believe in a single WebID neither does Henry. We just believe 
> that Web-scale verifiable identity is a critical part of the required 
> infrastructure. We also believe that a de-referencable URI (e.g., an 
> HTTP URI) is a very powerful vehicle for this endeavor, even more so 
> when combined with structured data and first-order logic.
> 
> I only know of one way to deal with context fluidity at the software 
> level, and that's via logic integrated into data which produces self 
> describing data objects .

I agree on all counts and feel/think the same, so I think I'll need to 
go and re-read this thread and see where the confusion is.

Best, Nathan