Re: Liking Linkability

On 15 Oct 2012, at 08:52, Christine Runnegar <runnegar@isoc.org> wrote:

> 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".

yes, you could be right. I am reading up on the subject which is 
complicated.

I am trying to capture something that would cover both public 
postings, to access limited postings. I know this covers only 
a subset of what privacy is about, but it is nevertheless I think 
an important part of the puzzle.

Henry

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

Social Web Architect
http://bblfish.net/