Re: Mechanism to determine whether location is currently being shared

On Thu, Mar 3, 2011 at 9:30 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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.

I'm not sure I understand this one. Presumably the app knows whether
it was last given a zip code or a lat/lon pair and when it received
it. A "Change Location" page can present the user with an option to
update their location which might or might not prompt for permission,
depending on the configuration of the user agent. Permissions are
persisted in different ways by different implementations: Chrome
persists whatever your answer was by default, Mobile Safari persists
your permission only after two consecutive answers and then asks you
again after 24 hours, etc. so I'm not sure what "currently sharing"
should mean.

> 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 can see the usefulness of this (a kind of progressive enhancement),
but it does also make it easier to submit surreptitious requests. I
like that an application must be willing for the user to be prompted
about permissions when the application wants to obtain location data.
If an ad network script discovers that they can request the user's
location every 5 seconds with a guarantee that the user will never be
prompted, the script could collect a large amount of additional data
without any user realizing it.

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

The UA implementation is responsible for all of the steps in that
algorithm. Also, it's explicitly stated that permission should be
captured before initiating the algorithm. From the end of section 5.1:

"Furthermore, the implementation should always obtain the user's
permission to share location before executing any of the
getCurrentPosition or watchPosition steps described above. [...] The
time that is spent obtaining the user permission must not be included
in the period covered by the timeout attribute of the PositionOptions
parameter. The timeout attribute must only apply to the location
acquisition operation."

Hope this helps,
Nick

Received on Friday, 4 March 2011 19:15:50 UTC