RE: getCurrentPosition() to getPosition()?

> -----Original Message-----
> From: public-geolocation-request@w3.org [mailto:public-geolocation-
> request@w3.org] On Behalf Of Dominique Hazael-Massieux
> Sent: Wednesday, January 21, 2009 2:14 PM
> To: Andrei Popescu
> Cc: public-geolocation@w3.org
> Subject: Re: getCurrentPosition() to getPosition()?
> 
> 
> Le mercredi 21 janvier 2009 à 12:34 +0000, Andrei Popescu a écrit :
> > > Most of the privacy issues surrounding the geolocation API seem to
> arise
> > > from the fact that the API is supposed to return the user's current
> > > location. At least, JohnM seemed to indicate that it was so during
> the
> > > workshop.
> >
> > I don't think this is accurate. There are privacy implications with
> > disclosing location regardless of the time when that location was
> > acquired.
> 
> I think the important point about my proposal is that it doesn't
> necessarily disclose the user location at all - it may be the location
> of whatever else really; maybe someone from CDT can cast some light on
> whether this helps or not privacy-wise?
> 
> > > What if, instead of making that assumption, the API would be
> designed to
> > > return *a* position, that might or might not be the user's current
> > > location? (this would probably require nothing more than changing
> the
> > > name of the function from getCurrentPosition() to getPosition() ?)
> > >
> >
> > Ok, but I don't really understand what problem it would solve.
> 
> The goal (sorry if it wasn't clear) is to solve (or least reduce) the
> perceived privacy-problems of disclosing someone's location.

OK, but what can the API then be used for, if it is not clear whether the location is the user's own position or just some location of any surrounding (or far away) object? I think this API was initially proposed to only expose the user's position (more generally, the devices position) as Andrei already mentioned, since otherwise the result would be ambiguous. However, as in the parallel thread about location providers (http://lists.w3.org/Archives/Public/public-geolocation/2009Jan/0015.html) it may be possible to integrate this kind of position provisioning, but with the explicit selection of a concrete location provider (e.g. the local device (or more specific the GPS receiver), a surrounding device, and a server-side knowledge base for PoIs or whatever). However, I think it will be hard to abstract all those very different provisioning methods within one single method call, e.g., GPS that returns ONE (current) position for the USER (requesting app) in a given TIME (timeout), the PoI server returns MULTIPLE (all PoIs) positions for an AREA (5km around a cinema) of a certain TYPE (restaurant). Maybe the so far proposed options field may help, but I think it cannot solve the problem completely.

Therefore, I suggest to stick to the current proposal of just exposing the user's position and leave the rest to the application itself, however, with multiple location providers, as proposed some time ago.

> > Furthermore, it would also break many of our existing use cases,
> would
> > it not?
> 
> I'm not sure it would - in most of them, it would broaden the use cases
> (e.g. find PoI near one of the locations provided by the user rather
> than necessarily the current location); and in the use cases that are
> current-location-specific (e.g. turn-by-turn navigation), the user
> would
> still be able to pick his current location as a location provider.
> 
> Dom

Any thoughts or comments?

Best Regards
Steffen

Received on Thursday, 22 January 2009 11:31:58 UTC