- From: Henry Story <henry.story@bblfish.net>
- Date: Fri, 19 Oct 2012 14:01:04 +0200
- To: Ben Laurie <ben@links.org>
- Cc: Mouse <mouse@rodents-montreal.org>, "public-philoweb@w3.org" <public-philoweb@w3.org>, "public-identity@w3.org" <public-identity@w3.org>, "saag@ietf.org" <saag@ietf.org>, "public-privacy@w3.org" <public-privacy@w3.org>, Sam Hartman <hartmans-ietf@mit.edu>, "public-webid@w3.org" <public-webid@w3.org>
- Message-Id: <8AB0C205-87AE-4F76-AA67-BC328E34AF5E@bblfish.net>
On 18 Oct 2012, at 21:29, Ben Laurie <ben@links.org> wrote: > On Thu, Oct 18, 2012 at 8:20 PM, Henry Story <henry.story@bblfish.net> wrote: >> >> On 18 Oct 2012, at 21:04, Mouse <mouse@Rodents-Montreal.ORG> wrote: >> >>>> [...] >>>> Unfortunately, I think that's too high of a price to pay for >>>> unlinkability. >>>> So I've come to the conclusion that anonymity will depend on >>>> protocols like TOR specifically designed for it. >>> >>> Is it my imagination, or is this stuff confusing anonymity with >>> pseudonymity? I feel reasonably sure I've missed some of the thread, >>> but what I have seem does seem to be confusing the two. >>> >>> This whole thing about linking, for example, seems to be based on >>> linking identities of some sort, implying that the systems in question >>> *have* identities, in which case they are (at best) pseudonymous, not >>> anonymous. >> >> With WebID ( http://webid.info/ ) you have a pseudonymous global identifier, >> that is tied to a document on the Web that need only reveal your public key. >> That WebID can then link to further information that is access controlled, >> so that only your friends would be able to see it. >> >> The first diagram in the spec shows this well >> >> http://webid.info/spec/#publishing-the-webid-profile-document >> >> If you put WebID behind TOR and only have .onion WebIDs - something that >> should be possible to do - then nobody would know WHERE the box hosting your >> profile is, so they would not be able to just find your home location >> from your ip-address. But you would still be able to link up in an access >> controlled manner to your friends ( who may or may not be serving their pages >> behind Tor ). >> >> You would then be unlinkable in the sense of >> http://tools.ietf.org/html/draft-iab-privacy-considerations-03 >> >> [[ >> Within a particular set of information, the >> inability of an observer or attacker to 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). >> ]] >> >> from any person that was not able to access the resources. But you would >> be linkable by your friends. I think you want both. Linkability by those >> authorized, unlinkability for those unauthorized. Hence linkability is not >> just a negative. > > I really feel like I am beating a dead horse at this point, but > perhaps you'll eventually admit it. Your public key links you. The question is to whom? What is the scenario you are imagining, and who is the attacker there? > Access > control on the rest of the information is irrelevant. Indeed, access > control on the public key is irrelevant, since you must reveal it when > you use the client cert. You are imagining that the server I am connecting to, and that I have decided to identify myself to, is the one that is attacking me? Right? Because otherwise I cannot understand your issue. But then I still do not understand your issue, since I deliberately did connect to that site in an identifiable manner with a global id. I could have created a locally valid ID only, had I wanted to not connect with a globally valid one. So your issue boils down to this: if I connect to a web site deliberately with a global identifier, then I am globally identified by that web site. Which is what I wanted. So perhaps it is up to you to answer: why should I not want that? > Incidentally, to observers as well as the > server you connect to. Not when you re-negotiation I think. And certainly not if you use Tor, right? Social Web Architect http://bblfish.net/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Friday, 19 October 2012 12:01:40 UTC