Re: Mechanism to determine whether location is currently being shared

On Wed, Mar 2, 2011 at 3:16 PM, Nick Doty <npdoty@ischool.berkeley.edu> wrote:
> 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?

Ah, sorry, I stripped down a lot of my email after I gave the spec a
closer read and found that the case was already partially addressed.

I had two use-cases presented to me.

1. The app can operate with either a ZIP code or a Geoloc position.
If a user visits the "Change Location" page, you'd like to indicate
whether they're currently sharing their location or not, so you don't
present confusing UI implying that they aren't sharing location.

2. The app can work without a position, but can offer more targeted
information with one.  The author would rather not bother the user
with an immediate prompt for location information; instead, they'd
like to just have a "Share Location" button that will make the app
request a position.  If the user has already granted permission,
though, then the app should go ahead and grab their position without
the user having to make a move.


> 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.)

>From what I can tell, the UA is only directly involved when you hit
step 4 of the algorithm at
<http://dev.w3.org/geo/api/spec-source.html#api_description>.  Steps
1-3 make no mention of the UA, nor does the section on security
considerations.

If it's intended that the UA capture permission from the user before
the algorithm even starts, this should be indicated somewhere.



On Thu, Mar 3, 2011 at 5:01 AM, Andrei Popescu <andreip@google.com> wrote:
> I see. There is this Feature Permissions spec:
>
> http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html
>
> but it hasn't been updated in a while. Do you happen to know what is
> the status with that spec? It looks like it would solve your problem?

I just emailed Johnny (he's a fellow googler), so I'll hopefully get
an update on that status of it soon enough.  It does seem to meet my
use-cases, though.


> Yeah, we had quite a lot of discussions on this topic and concluded
> that this was the cleanest way. In fact, we have examples for all
> scenarios (as far as I can tell) in the Introduction section:
>
> http://dev.w3.org/geo/api/spec-source.html#introduction
>
> Please see "Forcing the user agent to return any available cached position".

Indeed!  Sorry for the noise on that point.


>> 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.
>>
>
> Hmm, since there is already a spec that addresses this problem,
> perhaps it's best to let our spec as it is? The issue isn't specific
> to Geolocation so I think it makes sense to treat it in a generic way.

Yeah, I'll pursue this with Johnny and the Feature Permissions spec,
and find out if that's something I can actually depend on progressing.

~TJ

Received on Thursday, 3 March 2011 17:31:46 UTC