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

Re: WebID-ISSUE-24: Privacy issues from WebID URI dereferencing [WebID Spec]

From: Henry Story <henry.story@bblfish.net>
Date: Tue, 1 Feb 2011 15:10:03 +0100
Message-Id: <8968E1CE-CE9E-45A4-B070-75B891AFADDB@bblfish.net>
To: WebID Incubator Group WG <public-xg-webid@w3.org>

> WebID-ISSUE-24: Privacy issues from WebID URI dereferencing [WebID Spec]
> http://www.w3.org/2005/Incubator/webid/track/issues/24
> Raised by: Nathan Rixham
> On product: WebID Spec
> Part of the WebID protocol includes dereferencing a "WebID URI" specified by the identifying agent.
> Whilst a measure of privacy and anonymity is provided by one half of the protocol (the TLS side), the act of dereferencing a "WebID URI" currently has authority/provenance issues (as outlined in ISSUE_23) and privacy issues.

Note I changed ISSUE dash 23 to ISSUE underscore 23 in order to avoid this email turning up in the issue 23 tracker. The issues may be related, but this thread is not.

> Namely, privacy is not guaranteed, an intermediary (or a "webid/profile host") can detect a request from a server (say a bank, a private site, an adult site, a gambling site) to a users WebID URI and thus know the user has attempted to identify on said site.

The WebID profile host would know nothing! All he would be able to log is an HTTP GET from some IP address on some resource.  HTTP does not requires one to know the identity of the requestor. Furthermore the GET could go through an ip anonymising proxy.

As pointed out this is an issue for OpenID which forces all calls to go through an IdP. In fact with WebID we have removed the need for the IdP. Where OpenId requires that profile page to have a link to the IdP, WebID just requires that the profile page publish the key. Done.

If you place your WebId on a host you don't own, then it could try to work out who the requesting server is. But that server need not specify its identity - and on the web it usually does not. In the case of the OpenID protocol, the IdP needs to know who the requesting server is - aka the Relying Party - so that it can redirect back to it. Furthermore an adult site intent on protecting the privacy of its users could GET the Profile document through a trusted IP anonymising proxy. 

So in fact we have a few +points here we can add to the FAQ on advantages of WebID over OpenID. :-)

> This may be something which the protocol needs to address (for instance, force TLS for dereferencing),

TLS is important for other reasons such as knowledge that the Profile has not been tampered with and that the page comes from the correct server. 

But I don't see how it helps in hiding from the Profile Page hoster who is making the request. It would allow it to find out who is making the request by asking for a client cert on the other hand, which is what the protocol you were suggesting in an earlier mail to this list "The other side of WebID / four party auth" seemed to be about

Are you sure you are not in fact trying to solve the opposite problem? How to make sure the profile hoster knows who made the request?

> or may be something that is best noted and addressed by specification text (note as a security consideration and give advice).


Social Web Architect
Received on Tuesday, 1 February 2011 14:10:41 UTC

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