W3C home > Mailing lists > Public > public-xg-webid@w3.org > July 2011

Re: Browser ID, WebID & URLs

From: Henry Story <henry.story@bblfish.net>
Date: Mon, 18 Jul 2011 19:38:06 +0200
Cc: WebID XG <public-xg-webid@w3.org>, Ben Adida <ben@adida.net>, dev-identity@lists.mozilla.org
Message-Id: <BF43D250-4E0B-4677-A0C9-A8EB09E822F7@bblfish.net>
To: Brian Smith <bsmith@mozilla.com>

On 18 Jul 2011, at 19:05, Brian Smith wrote:

> Henry Story wrote:
>> Brian Smith wrote:
>>> Long-lasting keys require a revocation mechanism. But, the
>>> revocation mechanism would likely leak information from the relying
>>> party to the identity provider about which identity is being
>>> verified.
>> Well not that much really. In the case of WebID you do an HTTP GET on
>> the URL. A service that wanted to be somewhat anonymous could go
>> through a proxy.
> The RP would have to include an identifier for the user in that GET, which means that the identity provider learns that the user is logging into the RP. The RP would have to go to great lengths to properly mask its identity in that situation--AFAICT, the RP masking its identity would be the hardest and more error-prone part of the whole thing, and most RPs wouldn't bother.

   Don't forget that the point of WebID is the creation of the Social Web. You will be owning that machine, or an agency you are part of and in whose name you are authenticating will own that machine (your work for example). So this is you discovering about where you went! or who is interested in you, or who is talking about you. 
   This is not some third party discovering where you went. If you are serious about privacy then you need to set things up that way. Otherwise it's like someone who would lock the front door but leave every other door unlocked. So given that I fail to see what the problem of them doing an HTTP get on your profile is. Looks like you'd even want that.

> With short-lived keys, avoiding the revocation mechanism, and avoiding the profile fetch, the user's interaction with the RP is hidden from the identity provider all the time, by default, and in a way that is better than failsafe

at the cost of giving out e-mail addresses you can be spammed with, and very little information that they can get about you directly, reducing the usability a lot. This means that a lot of applicatons will end up requiring WebID anyway.

>> And a WebID can be part of any kind of list in any
>> case. So there are thousands of reasons why services may be doing an
>> HTTP get on one of them. The fact that google crawls the web says
>> nothing about my activity anywhere.
> 1. Fingerprinting: the GET that Google does when it is crawling your website won't be identical to the GET it would do when the user is logging into Google.

No your WebId is meant to be long term: "Cool URLs don't change" you know. It is what people link to, it is what you put in your certificate. These are not one time URLs that change every few seconds, and which could be used to track where you went that way.

> 2. When Adult Friend Finder does a GET for a user's profile, it is pretty likely that the user is logging into Adult Friend Finder; it is safe to assume that they aren't just crawling the web to build a general-purpose search engine.

Why? Someone on that friend finder could have tagged that person, or linked to a friend of that person, or search for a name and got the wrong person, or friend finder may be crawling the social web -- which seems very likely ... But again there is no reason why FriendFinder should declare himself to be FriendFinder on those public files. And then again it's your server they are pinging, so you don't care. And if they are pinging someone you don't trust, then what are you doing putting all your data there, or giving them access to your mail!

>> In any case one could easy to have it both ways: if a particular
>> certificate is short lived, the need to verify is removed. If keys are
>> longer lived, then it depends somewhat on the Relying Party's security
>> requirements.
> If you have a revocation mechanism, then some RPs will use it with good intentions even when it isn't necessary. It would be better for the RP to tell the browser "this key is too old for me" and have the browser deal with that.

I agree here I think. Browsers should also no longer send or show out of date certificates - or put them in an expired list.

> - Brian

Social Web Architect
Received on Monday, 18 July 2011 17:38:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:46 UTC