Re: Liking Linkability

Hi Henry,

Re:

> "A communication between two people is private if the only people 
> who are party to the conversation are the two people in question. 
> One can easily generalise to groups: a conversation between groups 
> of people is private (to the group) if the only people who can 
> participate/read the information are members of that group"

I wonder if your working definition for "privacy" is actually closer to a definition for "confidentiality".

Regards,
Christine

On Oct 6, 2012, at 3:49 PM, Henry Story wrote:

> 
> Notions of unlinkability of identities have recently been deployed 
> in ways that I would like to argue, are often much too simplistic, 
> and in fact harmful to wider issues of privacy on the web.
> 
> I would like to show this in two stages:
> 1. That linkability of identity is essential to electronic privacy 
>    on the web
> 2. Show an example of an argument by Harry Halpin relating to 
> linkability, and by pulling it apart show how careful one has 
> to be with taking such arguments at face value
> 
> Because privacy is the context in which the linkability or non linkability
> of identities is important, I would like to start with a simple working 
> definition of what constitutes privacy with the following minimal 
> criterion [0] that I think everyone can agree on:
> 
> "A communication between two people is private if the only people 
> who are party to the conversation are the two people in question. 
> One can easily generalise to groups: a conversation between groups 
> of people is private (to the group) if the only people who can 
> participate/read the information are members of that group"
> 
> Note that this does not deal with issues of people who were privy to 
> the conversation later leaking information voluntarily. We cannot 
> technically legislate good behaviour, though we can make it possible 
> for people to express context. [1]
> 
> 
> 1. On the importance of linkability of identities to privacy 
> ============================================================
> 
> A. Issues of Centralisation
> ---------------------------
> 
> We can put this with the following thought experiment which I put
> to Ben Laurie recently [0].
> 
> First imagine that we all are on one big social network, where 
> all of our home pages are at the same URL. Nobody could link
> to our profile page in any meaningful way. The bigger the network
> the more different people that one URL could refer to. People 
> that were part of the network could log in, and once logged in
> communicate with others in their unlinkable channels. 
> 
> But this would not necessarily give users of the network privacy: 
> simply because the network owner would be party to the conversation 
> between any two people or any group of people. Conversations 
> that do not wish the network owner to be party to the conversation
> cannot work within that framework. 
> 
> At the level of our planet it is clear that there will always be a 
> huge number of agents that cannot for legal or other reasons allow one 
> global network owner to be party to all their conversations. We are 
> therefore socio-logically forced into the social web.
> 
> B. Linkability and the Social Web
> ---------------------------------
> 
> Secondly imagine that we now all have Freedom Boxes [4], where
> each of us has full control over the box, its software, and the
> data on it. (We take this extreme individualistic case to emphasise
> the contrast, not because we don't acknowledge the importance of
> many intermediate cases as useful) Now we want to create a 
> distributed social network - the social web - where each of us can 
> publish information and through access control rules limit who can 
> access each resource. We would like to limit access to groups such
> as:
> 
>  - friends 
>  - friends of friends
>  - family
>  - business colleagues
>  - ... 
> 
> Limit access means, that we need to determine when accessing a 
> resource who is accessing it. For this we need a global identifier
> so that can check with the information available to us, if the 
> referent of that identifier is indeed a member of one of those 
> groups. We can't have a local identifier, for that would require
> that the person we were dealing with had an account on our private
> box - which will be extremely unlikely. We therefore need a way 
> to identify - pseudonymously if be - agents in a global space.
> 
> Take the following example. Imagine you come to the WebID TPAC
> meeting [6] and I take a picture of everyone present. I would like
> to first restrict access to the picture to only those members who
> were present. Clearly if I only used local identifiers, I would have
> to get each one of you to first create an account on my machine. But 
> how would I then know that the accounts created on the FBox correspond
> to the people who were at the party? It is much easier if we could
> create a party members group and publish it like this
> 
>   http://www.w3.org/2005/Incubator/webid/team.n3
> 
> Then I could drag and drop this group on the access control panel
> of my FBox admin console to restrict access to only those members.
> This shows how through linkability I can restrict access and 
> increase privacy by making it possible to link identities in a distributed
> web. It would be quite possible furthermore for the above team.n3
> resource to be protected by access control.
> 
> 
> 2. Example of how Unlinkability can be used to spread FUD 
> =========================================================
> 
> 
> So here I would like to show how fears about linkability can
> then bring intelligent people like Harry Halpin to make some seemingly
> plausible arguments. Here is an example [2] of Harry arguing against
> W3C WebID CG's http://webid.info/spec/ 
> 
> [[
> Please look up "unlinkability" (which is why I kept referencing the 
> aforementioned IETF doc [sic [3] below it is a draft] which I saw 
> referenced earlier but whose main point seemed missed). Then explain 
> how WebID provides unlinkability. 
> 
> Looking at the spec - to me, WebID doesn't as it still requires 
> publishing your public key at a URI and then having the relying party go 
> to your identity provider (i.e. your personal homepage in most cases, 
> i.e. what it is that hosts your key) in order to verify your cert, which 
> must provide that URI in the SAN in the cert. Thus,  WebID does not 
> provide unlinkability. There's some waving of hands about guards and 
> access control, but that would not mediate the above point, as the HTTP 
> GET to the URI for the key is enough to provide the "link".
> 
> In comparison, BrowserID provides better privacy in terms of 
> unlinkability by having the browser in between the identity provider and 
> the relying party, so the relying party doesn't have to ping the 
> identity provider for identity-related transactions. That definitely 
> helps provide unlinkability in terms of the identity provider not 
> needing to knowing every time the user goes to a relying party.
> ]]
> 
> If I can rephrase the point seems to be the following: A WebID verification 
> requires that the site your are authenticating to ( The Relying Party ) verify
> your identity by dereferencing ( let me add: anonymously ) your profile 
> page, which might only contain as much as your public key publicly. The yellow 
> box in the picture here:
> 
>  http://www.w3.org/2005/Incubator/webid/spec/#the-webid-protocol
> 
> The leakage of information then would not be towards the Relying Party - the
> site you are logging into - because that site is the one you just wilfully 
> sent a proof of your identity to. The leakage of information is (drum roll) 
> towards your profile page server! That server might discover ( through IP address 
> sniffing  presumably ) which sites you might be visiting. 
> 
> One reasonable answer to this problem would be for the Relying Party to fetch 
> this information via Tor which would remove the ip address sniffing problem.
> 
> But let us develop the picture of who we are loosing (potentially) 
> information to. There are a number of profile server scenarios: 
> 
> A. Profile on My Freedom Box [4]
> 
>  The FreedomBox is a personal machine that I control, running
> free software that I can inspect. Here the only person who has
> access to the Freedom Box is me. So if I discover that I logged
> in somewhere that should come as no surprise to me. I might even
> be interested in this information as a way of gathering information
> about where I logged in - and perhaps also if anything had been 
> logging in somewhere AS me. (Sadly it looks like it might be
> difficult to get much good information there as things stand 
> currently with WebID.)
> 
> B. Profile on My Company/University Profile Server
> 
> As a member of a company, I am part of a larger agency, namely the 
> Company or University who is backing my identity as member of that
> institution. A profile on a University web site can mean a lot more
> than a profile on some social network, because it is in part backed
> by that institution. Of course as a member of that institution we
> are part of a larger agent hood. And so it is not clear that the institution
> and me are in that context that different. This is also why it is 
> often legally required that one not use one's company identity for
> private business.
> 
> C. A Social Network ( Google+, Facebook, ... )
> 
>  It is a bit odd that people who are part of these networks, and who
> are "liking" pretty much everything on the web in a way that is clearly
> visible and is encouraged by those networks to be visible to the 
> network, would have an issue with those sites knowing-perhaps (if the 
> RP does not use Tor or a proxy) where they are logging into. It is certainly
> not the way the OAuth, OpenID or other protocols that are in extremely 
> wide use now have been developed and are used by those sites.
> 
> If we look then at BrowserId [7] Now Mozilla Persona, the only difference 
> really with WebID ( apart from it not being decentralised until crypto in the
> browser really works ) is that the certificate is updated at short notice 
> - once a day - and that relying parties verify the signature. Neither of course
> can the relying party get much interesting attributes this way, and if it did
> then the whole of the unlinkability argument would collapse immediately.
> 
> 
> 3. Conclusion
> =============
> 
> Talking about privacy is like talking about security. It is a breeding ground 
> for paranoia, which tend to make it difficult to notice important
> solutions to the problem we actually have. Linkability or unlinkability as defined in
> draft-hansen-privacy-terminology-03 [3] come with complicated definitions,
> and are I suppose meant to be applied carefully. But the choice of "unlinkable"
> as a word tends to help create rhethorical short cuts that are apt to hide the 
> real problems of privacy. By trying too hard to make things unlinkable we are moving 
> inevitably towards a centralised world where all data is in big brother's hands. 
> 
> I want to argue that we should all *Like* Linkability. We should
> do it  aware that we can protect ourselves with access control (and TOR) 
> and realise that we don't need to reveal anything more than anyone knew 
> before hand in our linkable profiles.
> 
> To create a Social Web we need a Linkable ( and likeable ) social web.
> We may need other technologies for running Wikileaks type set ups, but
> the clearly cannot be the basic for an architecture of privacy - even
> if it is an important element in the political landscape.
> 
> Henry
> 
> [0] this is from a discussion with Ben Laurie
>     http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-def-1.pdf
> [1] Oshani's Usage Restriction paper 
>    http://dig.csail.mit.edu/2011/Papers/IEEE-Policy-httpa/paper.pdf
> [2] http://lists.w3.org/Archives/Public/public-identity/2012Oct/0036.html
> [3] https://tools.ietf.org/html/draft-hansen-privacy-terminology-03
> [4] http://www.youtube.com/watch?v=SzW25QTVWsE
> [6] http://www.w3.org/2012/10/TPAC/
> [7] A Comparison between BrowserId and WebId
>   http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid
> 
> 
> Social Web Architect
> http://bblfish.net/
>

Received on Monday, 15 October 2012 06:53:19 UTC