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

Re: Geopriv compromise proposal

From: Andrei Popescu <andreip@google.com>
Date: Wed, 17 Jun 2009 14:39:19 +0100
Message-ID: <708552fb0906170639m1d00594et18b4c2752ff55bd3@mail.gmail.com>
To: Angel Machín <angel.machin@gmail.com>
Cc: public-geolocation@w3.org
Hi Angel,

On Wed, Jun 17, 2009 at 12:54 PM, Angel Machín<angel.machin@gmail.com> wrote:
> I would like to share my personal opinion about this,…
> I think that almost everyone sees the value in allowing users to
> express their will about how their location should be used. Probably
> the discussions revolve mainly around the idea of having this feature
> inside the Geolocation spec.
> I think that the ability of expressing user’s will about the personal
> data they send shouldn’t be specific for Geolocation or any other API,
> this should be something generic that could be bound to any Web
> request but not to the message content. The same policy format could
> be used for location, form filling, banking or any other transaction
> where sensitive information is sent. Think about it, all the privacy
> fields that are considered a must in our discussions – “allow
> retransmission”, “store duration”... – are not specifically related to
> location data.
> Maybe W3C should start thinking about a generic policy framework to do
> that. It would make the difference between location services: in the
> same way that no one accesses a banking system without using SSL,
> users would prefer to use a location service where this hypothetical
> framework would be available. Since it would be generic, policy data
> would be bound to the request (Http headers, multipart message, etc…)
> not to the information itself.
> Doesn’t this make sense?

Personally, I think it does. I'd also like to make the following
comment: if the W3C is to act on your suggestion and form a new
working group, then I really hope they will take into account the
feedback our group has provided so far. I feel that we have had
extremely good reasons to justify the problems we found with the
existing solutions in this area and it would be great if any new
solution would avoid those problems.

Many thanks,
Received on Wednesday, 17 June 2009 13:39:55 UTC

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