Re: unlinkability

On 7 October 2012 22:21, Henry Story <henry.story@bblfish.net> wrote:

>
> On 7 Oct 2012, at 21:16, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>
>
>
> On 6 October 2012 12:03, Henry Story <henry.story@bblfish.net> wrote:
>
>>
>> On 6 Oct 2012, at 12:01, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>>
>>
>> On 6 October 2012 11:42, Henry Story <henry.story@bblfish.net> 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?
>>>
>>>
>>> If we, as a group, are able to address such concerns, or show that we
>>> have evaluated them and proven then are non issues (for example in a FAQ),
>>> it may help bring the benefits of WebID to a wider audience.
>>>
>>>
>>> That is why I ask you to express in your words what the problem is, and
>>> see if you can come up with an answer to the
>>> problem. And indeed we should add this on a list of question and answers
>>> that comes up.
>>>
>>
>> I have quoted the passage cited by Hannes, Harry and others.
>>
>>
>> yes, but you have to develop that passage and see how it applies to
>> WebID. It is not an obvious passage at all, and it is not clear it applies
>> at all to WebID.
>>
>> It's something we (as a group) have been asked to look at.  In truth,
>> it's been quite a hard conversation to follow as there were many replies
>> and points raised in a short period of time.  I dont know if unlinking the
>> public key from the URI provides more 'unlinkability', it was just a
>> suggestion.
>>
>>
>>
>> But it seems unclear to me that the concerns have been addressed.
>>
>>
>> Well I did in fact answer that mail. But I am going to send out a new
>> mail right now, to make sure it is clear.
>>
>> Certainly there was no acknowledgement of that.
>>
>>
>> By whome? By Harry? He never acknowledges mails that don't go in his
>> direction.
>>
>
> OK, I've managed to look through a lot of this now.
>
> Unlinkability seems to be useful when you want to provide anonymity or
> pseudo anonymity.
>
>
> [[
>
>       Unlinkability:  Within a particular set of information, a state in
>       which an observer or attacker cannot 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).
>
> ]]
>
> Unlinkability is with respect to an attacker or observer.  So one has to
> ask who the attacker or observer is.
> In the case of wikileaks, the attacker is the person who wishes to find
> out who posted the leak. They want to
> correlate that person to something else presumably.
>
> In the case of the social web, it is going to be quite complex who is an
> attacker. I think to be able to
> specify this one would have to look at the access control on a resource.
> If I want to make a resource
> available to a group of friends, then they cannot be the attacker.  The
> attacker would be someone
> who is not my friend being able to look at the TLS traffic and work out
> who is connecting. It would be
> interesting to see what TLS+Tor gives one there in terms of improvement.
>
> If the web site you are connecting to is the attacker, then you want to
> minimise their ability to correlate
> your buying decision for X with another buying decision for Y on another
> site.  There you'd just
> create a local account on that site, and then use some form of e-payment.
> But you'd not want to give them any
> interesting info about you or else they'd soon be able to identify you -
> and there the e-payment system
> is already problematic.
>
> So what unlinkability means depends very strongly on who is thought to be
> attacking who.
>
>
> Both valuable use cases.
>
> I am guessing the perception of those that have never tried webid may be
> that the certificate is sent *every* time.
>
>
>
>
> This can be avoided as follows:
>
> - Do not send a cert when the popup arises
>
>
>
> yes, usually there is cancel button on the cert selection box.
> Or: don't click the login button.
>
> - Use a different browser
>
>
> Or a different person in the same browser, as in Chrome's Profile options.
>
> - We create a public cert at http://webid.info/#anon
>
>
> I am not sure that would be useful. Just don't log in. But perhaps for
> sites that require certificates?
>
>
> Pseudo anonymous identifies can be provisioned by WebID
>
>
> yes, pseudonyms
>
>
> - One cert per identity
>
>
> Not sure how that helps
>
>
> Linkabiity is desirable in many cases as stated in the final paragraph of
> the IETF draft.
>
>
> Well spotted, thanks:
>
> [[
>
>    Achieving anonymity, unlinkability, and undetectability may enable
>    extreme data minimization.  Unfortunately, this would also prevent a
>    certain class of useful two-way communication scenarios.  Therefore,
>    for many applications, a certain amount of linkability and
>    detectability is usually accepted while attempting to retain
>    unlinkability between the data subject and his or her transactions.
>    This is achieved through the use of appropriate kinds of pseudonymous
>    identifiers.  These identifiers are then often used to refer to
>    established state or are used for access control purposes, see
>    [I-D.iab-identifier-comparison <http://tools.ietf.org/html/draft-iab-privacy-terminology-01#ref-I-D.iab-identifier-comparison>].
>
> ]]
>
>
> BrowserID aka persona seems not to solve this issue as the cert sends:
>
> - The user's email address.
> - The user's public key for that address on that browser.
> - The time that the certificate was issued.
> - The time that the certificate expires.
> - The IdP's domain name.
>
>
>
>
> Additionally your webmail provider and/or mozilla can impersonate you as
> they control your private key server side.
>
>
> My guess is that with web crypto in the browser that will go. But until
> then perhaps.
> But I am  not quite sure it is that: I think that they control the
> signature. And the signature
> means they can make a private key at will.
>
> That is the same problem with WebID btw.  But it's not a problem if you
> have a FBox webid, because then you control it.
> The server serving the page is a key agent in this system. It is the @
> sign of the e-mail address
>
>  - FBox: henry.story@henry.story ( you control your box)
>  - Uni:    henry.story@ic.ac.uk       ( you are part of a bigger agency )
>
> Each has its advantages.
>
> Anyway even with Web Crypto in the browser the only advantage BrowserId
> has is that the certificates
> are changed a lot so you can verify the cert just by checking the
> signature. (If you don't care to have 1 day error )
> But the value of WebID for social web is of course all the other relations
> you can access. And of course
> they will want those too.
>
> So that is why my point was from the beginning to Harry: you can't defend
> BrowserID and slam WebID
> simultaneously. It's inconsistent.
>
> Harry's only point is that your profile server might be able to track
> where you go, and even that is only very
> weakly true. And its hardly interesting in most cases anyway, since it is
> your own profile server that may possibly
> be able to know. I think you can find out who is behind this if you ask
> "who would this be problematic for?"
> Certainly not for people with FBoxes.
>

With WebID I can decouple my mail account and my identity using foaf :
mbox.  With Persona / BrwoserID this is impossible.


>
> By extension any agency that requests information from your webmail
> provider or mozilla can view your external data.
>
> Furthermore, your webmail provider and/or mozilla can sign you up for any
> services offered by a relying party *without you even knowing*.
>
>
> Why is that?
>
> This is quite scary in privacy terms and has me thinking twice whether I
> want to use BrowserID as a fallback to WebID, as was my original
> intention.  Perhaps let the user decide.
>
>
> yes, but I am not sure quite what the FAQ would be here other than
> "What is the distinction between WebID and BrowserID?"
>
> http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid
>
> But I am not sure what the question would be that Harry is asking, other
> than FUD
>
>
> Maybe we should add these points to an FAQ
>
>
> We should certainly link to that article in the FAQ, and also perhaps move
> the FAQ to our wiki,
> or at least move the FAQ to the w3c WebID/FAQ from the foaf+ssl/FAQ
>
> But yes getting back to Linkability, the answer has to be
>
>    - 1. The importance of linkability (see my previous mail)
>   -  2 Who is your enemy?
>      then one could make a table, and for each on suggest an answer
>        the site you re logging into: don't use webid
>        Otherwise I am not really sure what one can say here yet that is
> that interesting - ie not something that ends
>        up falling down to TLS level issues which might be fixed with other
> systems such as Tor.
>
>
>
>>
>> Perhaps it is the nature of mailing lists that it can be challenging to
>> know when a consensus is reached or a problem has been solved.
>>
>>
>>>
>>> Henry
>>>
>>>
>>>
>>>
>>>>
>>>> Henry
>>>>
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>>
>>>>
>>>
>>>  Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>>
>>  Social Web Architect
>> http://bblfish.net/
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
>