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

RE: Geolocation: Security and Privacy

From: Alec Berntson <alecb@windows.microsoft.com>
Date: Tue, 10 Jun 2008 10:25:11 -0700
To: Chris Butler <cbutler@dash.net>, "public-geolocation@w3.org" <public-geolocation@w3.org>
Message-ID: <D8939A2F7A8C124ABE6075E08C52CDCA03FF3255@TK5-EXMBX-W603v.wingroup.windeploy.ntdev.microsoft.com>

I am still waiting for fireeagle "to be ready" to give me an invite :(

-----Original Message-----
From: Chris Butler [mailto:cbutler@dash.net]
Sent: Monday, June 09, 2008 7:08 PM
To: Alec Berntson; public-geolocation@w3.org
Subject: RE: Geolocation: Security and Privacy

Hi Alec.

The approach to provide a randomized dance around the current location
would provide a way to potentially brute force a more approximate real
location by accessing the data multiple times and doing the average...

One example of a site that does this in a way that I think is pretty
nice is the way that FireEagle does it.

Have you checked that out?

Giving back a reverse geocoded string would work as well so that the
service doesn't need to provide that service...



-----Original Message-----
From: Alec Berntson [mailto:alecb@windows.microsoft.com]
Sent: Monday, June 09, 2008 11:16 AM
To: Chris Butler; public-geolocation@w3.org
Subject: RE: Geolocation: Security and Privacy

To accomplish "Data fuzzing," I think the easiest solution is to
randomize the lat/long values to some number of decimal places based on
what the user is willing to give. I agree that bounding boxes and center
points of cities makes a lot of sense, but that seems like an
implementation nightmare - all the central points/bounding boxes would
need to be stored in a database somewhere and accessed.

One alternative is to only perform limited reverse geocoding (i.e. only
give the city, state, country) for sites that the user does not trust
and withhold the lat/long values. Then if the user gives consent (via
UI?), the actual coordinate could be returned.

-----Original Message-----
From: Chris Butler [mailto:cbutler@dash.net]
Sent: Saturday, June 07, 2008 6:47 PM
To: Alec Berntson; public-geolocation@w3.org
Subject: RE: Geolocation: Security and Privacy

Hi Alec.

I think that you make a good point about the 'fuzzing' of user location.
I wonder what the best way to do this though is.

In the case of just giving city level information, here are some

* Lat/lon of a geocoded center of the city
* Geocode-able city name
* Bounding box of the city

The last option sounds like the best since it is non specific and
doesn't give any single point as the location...



Chris Butler | Content Platform Evangelist, Dash Navigation | Office:
408-543-2939 | Mobile: 415-577-9130 | Fax: 408-400-0939

-----Original Message-----
From: public-geolocation-request@w3.org
[mailto:public-geolocation-request@w3.org] On Behalf Of Alec Berntson
Sent: Friday, June 06, 2008 11:32 AM
To: public-geolocation@w3.org
Subject: Geolocation: Security and Privacy

One of the most important aspects of the geolocation API spec (IMO) will
be the privacy and security requirements. The user's current location is
probably the most one of the most sensitive pieces of personal
information available. The references in the draft spec point to a few
solid approaches that I would like to highlight (and build on):

Opt-out by default
    By default, no page can access the users location

UI to alert the user
    There needs to be an alert when a page requests the user's location
    There needs to be some form of status UI indicating when location
data is being accessed

Least privilege
    The user should be given the option to allow access to a page (or
domain) for
       Just this once
       Just this session
    Data 'fuzzing'
       User can control how much resolution to give to a page
       Add noise to the data if more accurate information is available
than is requested

    Keep a log of what information was given out to whom

Hope that kicks off some discussion!
Received on Tuesday, 10 June 2008 17:25:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:49 UTC