W3C home > Mailing lists > Public > public-webid@w3.org > October 2012

Re: [saag] Liking Linkability

From: Henry Story <henry.story@bblfish.net>
Date: Tue, 23 Oct 2012 13:52:49 +0200
Cc: nathan@webr3.org, Ben Laurie <ben@links.org>, Halpin Harry <H.halplin@ed.ac.uk>, public-identity@w3.org, saag@ietf.org, public-webid@w3.org, "public-privacy@w3.org list" <public-privacy@w3.org>
Message-Id: <212677E1-8F0E-4005-8015-B4CD1233D67F@bblfish.net>
To: Ben Laurie <benl@google.com>

On 23 Oct 2012, at 12:50, Ben Laurie <benl@google.com> wrote:

> On 23 October 2012 10:56, Nathan <nathan@webr3.org> wrote:
>> Ben Laurie wrote:
>>> b) Linkability it not, as you say, inherently bad. The problem occurs
>>> when you have (effectively) no choice about linkability.
>> .. and when people convey or infer that there is no choice about
>> linkability, when there really is scope to be as unlinkable as one likes
>> within WebID.
> I have never disputed that - my point is that if I am as unlinkable as
> I like I then have a fairly horrific problem managing a large number
> of certificates and remembering which one I used where.

Yes, so browsers should in my view remember what selection you make when
you go to a web site, and resend the same certificate the next time you go
there. Mind you - they should also show you that they have done this and
allow you to change your previous choice - even if needed back to anonymous.
We argued this in a different thread on Transparency of Identity in the 
browser - and there I pointed to work by Aza Raskin as a good example of
what I meant

This then leaves the issue of how to do this across browsers, and I think
there are a number of synchronisation "protocols" that could be developed there.
In my view  the only protocol needed is HTTP here + an ontology for bookmarks, 
cookies, personas, etc... You give your browser your trusted home site where
you can POST, PUT, and GET all of these ids. A good protocol for this would be
the Atom protocol or better the in development linked data protocol

 You probably don't need here to even  save the  certificates for each site, you 
just need to know if you authenticated  there using a global id, a local certificate, 
or a password, and you could re-generate the identifiers. Well you have a more 
difficult  time it  is true for certificates bound to one site. And even saving cookies
is difficult because they may encode device type and screen size...

So that's a lot of work to get done right. I don't have anything against it being
done. It could even be helpful for WebID... But as my priority is building a 
RESTful distributed social web, and as I am not employed by browser vendors to work 
on  such a protocol, .... (I'll use it when its deployed)

In short these issues seem to be orthogonal, and can be developed in parallel.


Social Web Architect

Received on Tuesday, 23 October 2012 11:53:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:44 UTC