- 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 languages. 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. 1.https://www.prime-project.eu/ 2.http://www.primelife.eu/ Best, Rigo
Received on Saturday, 13 June 2009 17:37:59 UTC