RE: Geolocation: Security and Privacy

Could you elaborate a little more about your bounding box 'algorithm'? Do you mean you take the current lat long and remove some number of decimal points, which effectively snaps the location to a grid?

Given the lat/long, yes, any additional information would need to be reverse geocoded. However, the address could be available if the provider handles that - someone could create a street address location provider where the user enters their data manually, and the location api reports that. You could even do reverse-reverse geocoding - look up the lat/long based on a street address. Keeping the API webservice agnostic leaves all of these possibilities open to providers.


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

Hi Alec.

One way that might be simpler is to introduce rounding errors into the
actual lat/lon.  Basically, you build a bounding box and then remove
accuracy digits.

This would 'fuzz' the data but at the same time avoid reverse-geocoding.
After thinking about it more the phrase or name of the place will
require reverse-geocoding as well, right?

Thanks.

Chris

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

I've taken a look at fireeagle's offerings, and I agree that their
"Location Hierarchy" is very nice. However, they are able to accomplish
all of that because they do not just offer an API, but rather a whole
platform and back-end.

This leads us to the question of, how much should this location api just
be a data pass-through, and how much server-side service support should
be required? We are already treading that line with reverse-geocoding.
Mandating web-service support as part of an API definition seems a
little out of scope to me...

What do other people think?
   -Alec

-----Original Message-----
From: public-geolocation-request@w3.org
[mailto:public-geolocation-request@w3.org] On Behalf Of Alec Berntson
Sent: Tuesday, June 10, 2008 10:25 AM
To: Chris Butler; public-geolocation@w3.org
Subject: RE: Geolocation: Security and Privacy


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

Thanks.

Chris

-----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
options:

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

Thoughts?

Thanks.

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

Logging
    Keep a log of what information was given out to whom

Hope that kicks off some discussion!
    -Alec

Received on Tuesday, 10 June 2008 20:08:33 UTC