Re: Geolocation: Security and Privacy

Something we have to be very cognizant of is that reverse-geocoding,  
especially to street level is really only feasible in the US and we  
don't have any reliable, distributed providers.

Just as a thought -- why not leave reverse-geocoding up to the  
implementing site or developer? I know there are a lot of benefits to  
passing that information from the browser, but it feels like there are  
too many exceptions to make it part of the spec.

Thoughts?

On Jun 10, 2008, at 2:09 PM, Alec Berntson wrote:

>
> 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 Thursday, 12 June 2008 14:34:58 UTC