W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2009

Re: Geopriv compromise proposal

From: Rigo Wenning <rigo@w3.org>
Date: Sat, 13 Jun 2009 19:37:24 +0200
To: public-geolocation@w3.org
Cc: Thomas Roessler <tlr@w3.org>
Message-Id: <200906131937.26756.rigo@w3.org>
Hi all, 

I wanted to convey http://www.xkcd.com/596/ to this list in light of 
our privacy discussions.

It is a fun way of showing what is at stake. The comic carries most of 
the reasons why Thomas and I are bugging you.

On the topic of the <rules> proposal I find myself in agreement with 
Ian Hickson to a certain extend. Having a <rules> element where a user 
can write down his rules is like going to some megastore with your own 
general conditions and at the cashier say: "These are my conditions, I 
only buy under those conditions". The shop would just say no. And in 
our scenario, the recipient of geo-information has even no way to 
communicate his disagreement.  We had discussions over this for years 
in research projects like PRIME[1] and PrimeLife[2]. It is a common 
mistake and very hard to avoid while designing protocols and 

But I think there is some merit in Richard's proposal if one tweaks 
the orientation and timing slightly: 

1/ Importance of who is declaring and when:
An element in the location _request_ of type URI that allows the 
location requesting service to advertise a policy (P3P or XACML or 
some other) that applies to the request. This does not have any 
implications for the user agent that does not know about the policy 
conveyed. The UA who knows about it can help the user with information 
on his decision to allow/disallow things.

2/ Semantics of the element
The API specification would NOT specify any semantics attached to the 
policy. It just provides the glue (URI) to have some policy attached 
to some request for location information. If the element is not 
present in a request or not understood, it can be just ignored.

PLING suggested the same to media annotations as it is not invasive at 
all, but allows for subsequent policy development. 

I also am of the opinion that this discussion is orthogonal to the 
Group's discussion with Thomas Roessler on privacy requirements and 
the privacy guidelines the API specification will provide.




Received on Saturday, 13 June 2009 17:37:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:54 UTC