W3C home > Mailing lists > Public > public-geolocation@w3.org > September 2008

Re: Suggest adding proximity alarm interface

From: Eric Tune <etune@google.com>
Date: Mon, 15 Sep 2008 11:20:39 -0700
Message-ID: <5353928f0809151120x2191248ydb29c1a89df41001@mail.gmail.com>
To: "Andrei Popescu" <andreip@google.com>
Cc: "Chris Butler" <cbutler@dash.net>, public-geolocation@w3.org

The point of a proximity alarm interface is not to provide additional
convenience for developers, but to benefit users by only providing
applications with sensitive information on a need-to-know basis.
Thus, I don't think application developers will be motivated to ask
for this feature, initially, since they can just as easily implement
many types of applications based on either the existing Geolocation
API or the Proximity API.
It will be users who ask for better control over use of their
sensitive information, and they won't know to ask for it until they
are presented with a range of applications... in other words, not
until it is too late to change the API.

To respond to your comments:
1) an initial implementation of the interface would not have to
include the complicated limiting mechanisms.  What is important is
that the API be designed so that a future implementation _can_ provide
the limitations without requiring changes to the applications that use
the API.  I'd argue that it is much harder to provide useful
limitations with the Geolocation API than with a Proximity API.
An analogy is cookies.  Early browsers did not have complex policies
for managing cookies, while modern browsers do.  Fortunately, the
cookie "api" was amenable to some useful controls.

2) If I only have proximity alerts set within a 50m radius of my home
in san francisco, and I'm visiting my parents in Seattle, its pretty
safe to say that none of those alerts will need to fire in the next
hour, because you just can't get from SF to Seattle in one hour.  An
actual implementation might say to sleep for a time t = (distance from
present position to nearest alarm location in miles) / (max speed =
800 mi/hr).

On Mon, Sep 15, 2008 at 7:57 AM, Andrei Popescu <andreip@google.com> wrote:
> Hi,
>
> I also think that the proximity alerts are very interesting but, like
> Chris, I have some doubts about their suitability for this (version of
> the) API. My main concern is that this functionality is quite close to
> application-specific logic and, at this point, I think the main goal
> of the Geolocation API is to allow such applications to be
> implemented, rather than provide such rich functionality out of the
> box. Having said that, if it turns out that a lot of application
> developers will be asking for this feature, we should definitely
> reconsider.
>
> I also have some comments to your points:
>
>> 1) Sometimes a user may not trust an application to receive continuous
>> updates on his position, but may trust the application enough to give
>> it limited information.
>
> As Chris mentioned, we'd probably need some complicated limitation
> mechanisms in place if we want to prevent applications from abusing
> the API and triggering alerts very frequently.
>
>> 2) The callback interface has the potential to save power, which is
>> important for mobile devices.
>> For example, the browser can compare the current position with all set
>> alarms, and, if all are far away, it can go to sleep for a length of
>> time equal to the minimum travel time to the next location.
>
> This sounds nice in theory, but how would the implementation determine
> the "minimum travel time" in practice?
>
> Many thanks,
> Andrei
>
Received on Monday, 15 September 2008 18:21:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT