- From: Rigo Wenning <rigo@w3.org>
- Date: Tue, 16 Jun 2009 09:53:00 +0200
- To: Andrei Popescu <andreip@google.com>
- Cc: public-geolocation@w3.org, Thomas Roessler <tlr@w3.org>
- Message-Id: <200906160953.03762.rigo@w3.org>
On Monday 15 June 2009, Andrei Popescu wrote: > As far as I understand, this isn't related to Richard's proposal > anymore. You're suggesting another optional parameter to the API, > where the Web application would pass a URL to its privacy policy. It is in so far related as the idea of attaching policy information to the exchange is kept, but the vectorial direction of the information carried by the tag is returned by 180 degrees. > Personally, I don't think this is needed: optional privacy-related > fields in the API suffer from the drawbacks explained by Ian and > are very likely to be ignored. Whether they will be ignored or not, is a decision by the implementer. And NO, this is not at all harmful in the sense that Ian Hickson described. I have understood the remarks differently. Ian Hickson may clarify. Because this would mean that you and others would consider P3P harmful to browsers and exposing users to risks. I have heard a lot of things about P3P, but not that it exposes users to higher risks. > Furthermore, the "Privacy > considerations for recipients of location information" section says > that the privacy policies applied to the location requests must be > disclosed "clearly and conspicuously". Web sites can do this using > their own UI, no need to push this into the API. You're missing the point, as interoperability would require that the UA as a decision point has some information about the applicable policy and where to find it before sending the location data. This sort of requirement typically is part of an API. My element would tell how to bind a P3P Policy to a location data request to the UA. (Or start a negotiation process in PRIME or PrimeLife) Referring to the Website UI just means: "gimme the 25 pages of legalese per request". This isn't my goal and as such is not a desirable outcome. I think you still put me in another drawer that (as I said) is orthogonal. The requirements TLR is talking about are different and directly affecting the API. Here it is just a URI field with meaning "reserved for policy". I think I could provide a wording for the Spec.. And only because you (or your understanding of the majority of user agents) don't want to implement it, doesn't mean that others won't make a plugin/Extension using exactly that option (see e.g. Prime). My suggested tag would be the opener for the world of policy without affecting the API for those not willing to care for privacy at all. It may be nice if Richard Barnes could comment. Best, Rigo
Received on Tuesday, 16 June 2009 07:53:36 UTC