- From: Rigo Wenning <rigo@w3.org>
- Date: Thu, 18 Jun 2009 21:10:56 +0200
- To: Doug Turner <doug.turner@gmail.com>
- Cc: Geolocation Working Group WG <public-geolocation@w3.org>, Thomas Roessler <tlr@w3.org>
- Message-Id: <200906182110.59660.rigo@w3.org>
On Thursday 18 June 2009, Doug Turner wrote: > I agree completely. if privacy rules are of interest, we should > figure out how to apply them globally -- and not special case > geolocation. > > For example, right now I type my address into forms when I go shopping > online. This fields should have similar privacy rules as what has > been proposed (retransmittal, retention). However, I do still feel > that these attributes will give the wrong assumptions to the user. Oh well, the formulation of the goal is really simple and everybody agrees on it. But the technical implementation isn't. That's why I do not want to bother this group with CR implementation. Working on it right now in PrimeLife. The P3P protocol was rather smart, but had flaws for large sites and scaling issues. The only thing I know NOW is that if forms could point to a policy with privacy information, we could solve your issue. Forms could probably do that using RDFa, so we wouldn't need a special thing there. But for the API that is designed to get data from sensors on the user's device, it would be very beneficial to have a "hook/attribute/element" already the API to allow a decision engine on the user side for the release of data. You can't do that by having an RDFa string on the web page requesting the location data IMHO. Because it would create an issue of scope of the semantics expressed in the URI pointing to the policy. By having it as a part of the location request, the scope is very nicely defined without any further need of expressiveness. It just comes naturally with the context of the action. The hook aligns well with scalability and granularity because it is linked to the request itself without further need to semantically define what a request is, how this request is scoped, which part it applies to (all those expressed in some metadata, scaling goes wrong). This makes it worthwhile to define the link directly in the API if there is not too much drawback for the current work of geolocation to progress as planned. Best, Rigo
Received on Thursday, 18 June 2009 19:11:33 UTC