W3C home > Mailing lists > Public > public-geolocation@w3.org > November 2010

Re: Geolocation provide API

From: Nick Doty <npdoty@ischool.berkeley.edu>
Date: Wed, 17 Nov 2010 16:43:27 -0800
Message-ID: <AANLkTimFCC2FO7y9oy6p4Grfhi2u=b+01ze7OeJp7Kon@mail.gmail.com>
To: Doug Turner <dougt@dougt.org>
Cc: "public-geolocation@w3.org Group WG" <public-geolocation@w3.org>
On Wed, Nov 17, 2010 at 3:34 PM, Doug Turner <dougt@dougt.org> wrote:

> A while ago, I suggested that the charter include an API that allows
> content to switch the geolocation provider.  I do not strongly feel that
> there is any requirement of this group to deliver such an API.

I agree that there's no particular need for the requester to specify a
particular geolocation provider; I think that could even create
privacy/security risks.

Still, I think there might be some advantage to control of the provider. In
our report [1] we noted that there are risks of aggregation in using the
same provider for all requests, particularly if that provider logs locations
with some consistent identifier. The WG could encourage implementers to give
users' control over, or increased awareness of, which providers are
providing (and in many cases also receiving) the users' location. For
example, if I'm in a sensitive location, maybe I'd like to switch to using
only GPS so that Google or Skyhook aren't informed. Also, as many browsers
are doing a good job of already, documentation should be readily available
on what the default location provider is and their privacy policy. Since we
would want this to vary by implementation, such recommendations would be
best in the non-normative Section 4.3.

A recent (short) paper at the Security and Privacy in GIS and LBS (SPRINGL)
workshop discusses this risk in greater depth with some proposed technical
(caching on the client) and legal solutions [2].


[1] http://escholarship.org/uc/item/0rp834wf
[2] http://portal.acm.org/citation.cfm?id=1868484
Received on Thursday, 18 November 2010 00:44:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:01 UTC