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

Re: Geopriv compromise proposal

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:56 UTC