Re: unlinkability

On 10/6/12 6:45 AM, Nathan wrote:
> Nathan wrote:
>> Henry Story wrote:
>>> On 6 Oct 2012, at 11:39, Melvin Carvalho <melvincarvalho@gmail.com> 
>>> wrote:
>>>
>>>>
>>>> On 6 October 2012 11:25, Henry Story <henry.story@bblfish.net> wrote:
>>>>>> (1) I think solves the unlinkability problem
>>>>> Can you explain what the unlinkeability problem is? Or for who it 
>>>>> is a problem?
>>>>>
>>>>> 4.  Unlinkability
>>>>>
>>>>>    Definition:  Unlinkability 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
>>>>>       cannot distinguish whether these IOIs are related or not 
>>>>> (with a
>>>>>       high enough degree of probability to be useful).
>>>>>
>>>>> This is something Harry brought up.
>>>> Can you explain why it is problematic. It is not because he brought 
>>>> it up
>>>> that it is problematic right? Or is he someone who sets the standards
>>>> of what is or is not problematic? Through what authority?
>>>>
>>>> Harry stressed that this was a key consideration to him.  As an 
>>>> influential member of the social web (he was chair of the W3C 
>>>> Social Web XG), I would consider his opinions important.  His 
>>>> complain was that he raised this before, and that the webid group 
>>>> did not look at it.
>>>
>>> But you have not summarised in your own words what his complaint is. 
>>> So how do you know we did not answer it?
>>
>> The quote in context may help:
>> http://tools.ietf.org/html/draft-hansen-privacy-terminology-03#section-4
>>
>
> and framed within the more specific context of 
> http://www.w2spconf.com/2012/papers/w2sp12-final6.pdf
>
>
>
For some context re. BrowserID (aka. Persona) flow, bearing in mind, 
according to Harry and others this is supposed to have a lower entropy 
factor than WebID:

1) The user attempts to identify themselves by giving an e-mail address, 
and wants to bind that address to a particular set of key material (for 
which the user then provide a proof of possession) by having the 
identity provider attest to that binding.

2) The browser checks to see if a private key is present in the browser 
associated with that email address.

3) If no key exists for the email address locally in browser, the 
browser generates key material and registers the public key with the 
identity provider.

4) The browser sends a signed authentication credential to the relying 
party.

5) The relying party checks authentication credentials with their 
locally stored database of identity provider public keys, authenticates 
the user if verification suc- ceeds (not shown in diagram as this step 
does not happen with every transaction).

6) The user sends signed attributes to the relying party from browser.

So this all ends up in a locally stored database of the identity 
provider. Enough said, since BrowserID doesn't cut it at all re. IFP 
semantics in a world in which our email addresses are the "super keys" 
of the underground personal information market. That anyone that claims 
to know anything about privacy and networking would make such claims 
about BrowserID boggles my mind.

*Comments:*

1. Where is "user" control in this flow?
2. On what basis is the so-called IdP database secure?
3. How does any of this negate the explicit or implicit IFP semantics of 
an email address.

We should simply take this FUD, and every item in the ietf spec, and use 
it to make a much better presentation of what WebID is all about.

Points to cover:

*Unlinkability*

       Unlinkability 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
       cannot distinguish whether these IOIs are related or not (with a
       high enough degree of probability to be useful).

       Example: As it states, given a piece of information (for instance 
a triple) can I construct a bigger profile or massive zeitgeist?

  *Undetectability*

       Undetectability of an item of interest (IOI) from an
       attacker's perspective means that the attacker cannot sufficiently
       distinguish whether it exists or not.

       Example: is <SomeURIDenotingAnEntity> a Person, Organization, or 
Machine?


All of these matters play into the strengths that arise from combining 
de-referencable URIs, Entity Relationship Semantics (e.g. as explicitly 
delivered via RDFS and OWL), hyperlink based structured data 
representation (as delivered by Linked Data & RDF data model), and 
first-order logic (what underlies RDFS and OWL).

WebID doesn't solve these matters alone. The solution is a combination of:

1. WebID -- cryptographically verifiable identifiers for entities of 
type: foaf:Agent
2. WebID authentication protocol -- what actually defines how 
authentication is performed
3. ACL and Data Access policies -- driven by the combination of ACL 
oriented ontologies, WebID authentication protoocol, and WebID.

We get into trouble when we try to refer to WebID as the solution. That 
kind of conflation inadvertently means 1/3 of the items outlined above.

ACL protection of resource based on logic is the key. Logic is as 
dexterous enough to evolve with human social network dynamics.

Let's take this opportunity to accentuate the power of socially aware 
ACLs and Data Access policies that leverage WebID and its Authentication 
Protocol.

Henry: WebID on its own is just a piece of the puzzle. We have to push 
the synergy of WebID and ACLs much harder via actual demonstrations. 
This is what I do at every turn and I encourage everyone to emulate. At 
this juncture, I am still waiting for folks to come get on board by 
doing the following:

1. sign all emails -- if you don't sign your emails you deprive yourself 
of the powerful entry point into the realms of user controlled 
verifiable identity and privacy
2. start using ACLs to protect Web documents that you publish -- this is 
basically what I've put forth as RWW-0.

Do that and you will find really simple ways to refute all of this FUD. 
Nothing beats an demonstration of reality.

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen