W3C home > Mailing lists > Public > public-geolocation@w3.org > March 2011

Re: Mechanism to determine whether location is currently being shared

From: Nick Doty <npdoty@ischool.berkeley.edu>
Date: Wed, 2 Mar 2011 18:16:47 -0500
Message-ID: <AANLkTikRQti3aNiWUfguRs6FW8jcBOCQV1nRm5J=gmuu@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: public-geolocation@w3.org, olalonde@gmail.com
Hi TJ,

Out of curiosity, what is your use case for exposing this functionality to
the web site? Why is it important for your site to know whether I gave
permission this time or whether the permission was persisted?

I agree that the current spec doesn't support this functionality: setting a
timeout of zero will not accomplish this goal. In fact, I don't think it
even works in the limited functionality that you're expecting. Permission is
supposed to be acquired by the user agent before initiating any of the steps
in evaluating cached positions or acquiring location. "The timeout attribute
must only apply to the location acquisition operation." (You could do
something if you supplied your own very small timeout to the operation and
the success callback wasn't executed before your timeout was executed, but
this sounds awkward.)

I can imagine some dangerous consequences of providing a prospective
property about whether permission has already been granted to a particular
site. An inserted script that wants to surreptitiously obtain your location
could query such a property and only request location if permission has
already been granted to the page (or to all pages) and avoid detection by
the user that it might otherwise risk. For that reason, and because this
doesn't seem to support any of the specified use cases, I'd oppose adding
this functionality. But if you have a compelling use case that should be
considered, please share with us.

Thanks,
Nick

On Wed, Mar 2, 2011 at 5:02 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> Heya, Geoloc people!
>
> (Note: I am not subscribed to this list, nor is the developer that I
> discussed this issue with (cc'd).  Please ensure that I and the cc'd
> developer stay on the cc list for this thread.)
>
> A developer recently asked me for some way to tell, in the
> getCurrentPosition callback, whether the permission grant was due to
> the user actually seeing the permissions prompt and clicking "Allow"
> (or the equivalent), or if it was an automatic grant due to the user
> previously granting the site permanent access to their location.  This
> can alternately be cast as a request to know if the user has already
> granted permission to grab their location, such that a call to
> getCurrentPosition() will return a position without prompting the
> user, or not.
>
> By carefully reading the Geolocation spec, I learned that this case
> had already thought about, and can be addressed as follows:
>
> Geolocation.getCurrentPosition(
>  function(){ /* This fires if the user has previously granted permission.*/
> },
>  function(){ /* This fires if they didn't. */ },
>  { maximumAge: 1e20, timeout: 0 }
> );
>
> However, this still misses one case - when the user has already
> granted permission to share their location, but there are no cached
> positions.  This can happen if, for example, the user instructs their
> browser to always share their location, or if the browser's position
> cache is cleaned (either automatically or at the user's instruction).
>
> As well, having to specify an arbitrary large value for maximumAge to
> ensure that you'll get a cached position if one exists is pretty
> hacky.
>
> Finally, it requires careful reading of the spec to determine that
> this is even possible.  An example or two would have helped.  ^_^
>
> I propose that Geolocation address this use-case directly, either by
> providing a boolean property on Geolocation reflecting whether the
> user has granted the site permission to grab their location, or a
> function that takes a single callback and provides the boolean value
> as an argument to the callback.
>
> ~TJ
>
>
Received on Wednesday, 2 March 2011 23:17:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:02 UTC