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

Re: Geopriv compromise proposal

From: Andrei Popescu <andreip@google.com>
Date: Mon, 15 Jun 2009 11:16:48 +0100
Message-ID: <708552fb0906150316l31cdc853ndc4390f543f9178b@mail.gmail.com>
To: Rigo Wenning <rigo@w3.org>
Cc: public-geolocation@w3.org, Thomas Roessler <tlr@w3.org>
Hi Rigo,

On Sat, Jun 13, 2009 at 6:37 PM, Rigo Wenning<rigo@w3.org> wrote:
>
> 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.
>

Agreed.

> 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.
>

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.
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. 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.

Thanks,
Andrei
Received on Monday, 15 June 2009 10:17:28 UTC

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