Re: getCurrentPosition() to getPosition()?

Hi,

On Wed, Jan 21, 2009 at 8:03 AM, Dominique Hazael-Massieux <dom@w3.org> wrote:
>
> Hello,
>
> I alluded quickly to that idea back in December in the workshop on
> securing access to device APIs, but would like to air it again to a
> larger part of the Geolocation WG.
>
> 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.

> 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.
Furthermore, it would also break many of our existing use cases, would
it not?

> There are I think many use cases where in fact the user might want to
> get information related to a position that isn't her current location:
> discovering an area where she will be later, finding again something she
> find when she was somewhere else before, getting data about someone's
> address in her addressbook, etc.
>

True, but this API is about exposing current location data to Web
applications. Exploring geographic areas on a map, remembering visited
locations or location of friends are all interesting use cases which
could be nicely implemented on top of our API.

> The story for watchPosition is probably less simple, but I could also
> imagine someone wanting to get information in a Web application based on
> someone or something else movements; this would even allow to tell your
> favorite Web app "Follow that car"! More seriously, I could see it used
> to follow the progression of a sport event (e.g. a race), of someone
> else's trip, etc.
>
> Of course, this is only useful if there are reasonable ways for browsers
> to subscribe to geolocation providers one way or another; I assume this
> is out of scope for the group in its current charter, but might be worth
> also a look.
>

That's right, you would need different infrastructure for this. I
think there are already some projects (e.g. FireEagle) that try to
deal with such usecases.

Thanks,
Andrei

Received on Wednesday, 21 January 2009 12:34:50 UTC