Re: [saag] Liking Linkability

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

Received on Sunday, 21 October 2012 19:53:00 UTC