Re: Liking Linkability

On 6 October 2012 15:49, Henry Story <henry.story@bblfish.net> 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.
>

It seems to me that there's 3 phases of the web

1. Unlinkability -- this was essentially web 1.0 and provided anonymity

2. Pseudo anonymitiy -- this was essentially web 2.0 and provided user
logins but also lead to walled gardens and data silos

3. Linkability -- perhaps this the great unsolved problem of web 3.0 and
will provide data portability


>
> 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/
>
>