Re: Geolocation: Security and Privacy

I would argue for keeping reverse geocoding but making it an optional
feature of the API. By the time we have a Recommendation, I'm willing to bet
N beers that there will by M or more providers with reasonably wide global
coverage.

Dave

On Wed, Jun 11, 2008 at 6:55 PM, Alec Berntson <alecb@windows.microsoft.com>
wrote:

>  Reverse Geocoding does have its challenges, but I don't think we should
> remove the notion of a civic address for a few reasons.
>
> 1.) The address that the API supplies could be user entered. If I am a
> desktop owner, I could conceivably have a provider that lets me enter my
> home address. Since the machine doesn't move, it would always be accurate.
> The value of faster searches, relevant ads, etc as a result of
> location-based context all still apply to desktops.
>
> 2.) reverse geocoding is a focus of much research (At the Where 2.0
> conference many people presented on the topic), and is only going to get
> better. We should at least keep the framework in place to support it as the
> technology improves.
>
> That being said, I agree that we shouldn't place any strong requirements on
> the availability of a reverse geocoding service in the API. We certainly
> should not count on it for 'data fuzzing.'
>
> -----Original Message-----
> From: Ryan Sarver [mailto:rsarver@skyhookwireless.com<rsarver@skyhookwireless.com>]
>
> Sent: Wednesday, June 11, 2008 10:34 AM
> To: Alec Berntson
> Cc: Chris Butler; public-geolocation@w3.org
> Subject: 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<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 <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<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 <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<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
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>