Re: Geolocation header

Thanks for the feedback Martin, responding in-line.

On Fri, Aug 4, 2017 at 9:25 AM, Martin J. Dürst <duerst@it.aoyama.ac.jp>
wrote:

> On 2017/08/04 00:25, Luis Barguñó Jané wrote:
>
>> I'm not proposing a new permission or setting. The idea is consolidating
>> with the existing JS geolocation permission for a certain origin.
>> Otherwise
>> I agree this would create a new vector.
>>
>
> But it's still somewhat different. Let's say there is a restaurant search
> site. Let's say I give this site permission to get my location data. Let's
> say this site has two seach modes: Search locally, and search in a specific
> location (e.g. New York).
>
> Now if the Geolocation API is used, the site might (not saying it would,
> but essentially it should) not activate location sending when searching
> restaurants in New York, because it doesn't matter whether I'm on First
> Street or on Main Street for that. However, the Geolocation-Request header
> would be sent with every request for this site, even when checking their
> privacy policy or whatever. It would possibly also be sent for every image
> request, every stylesheet request, every JS request, and so on, although
> browsers may be able to restrict that if the spec proposes that.
>

I agree, sites should be able to ask for location only when it makes sense.
The path parameter is flexible enough so a site could ask for location on
"restaurants/local" only, but not for "restaurants/newyork" or for
"/images/XXX" or "css/YYY".

The same way sites should take care of using JS Geolocation API today only
when it makes sense, they should make sure the path parameter is used to
specify when location is actually needed, and move things out of that path
if they don't need location.

That said, this should be recommended but can't be technically enforced,
since permissions are per-origin already in the JS Geolocation API.


> On the other hand, let's assume I'm searching for the nearest bakery in
> Paris. There's virtually a bakery at every corner in Paris, so the use of
> the Geolocation API could be tailored to this and send a new location
> whenever I moved 50 meters or so, whereas it would use a completely
> different granularity e.g. for gasoline stands somewhere in the countryside
> in the Mid-West. Such on-demand granularity changes could be simulated for
> the Geolocation-Request header by somehow triggering page re-requests, but
> this would be clumsy.
>

Right, this use case is out of scope for the headers-based proposal. The
goal of headers is optimizing latency and bandwidth (reduce from two to one
roundtrip the "static use case of device location"). The dynamic situation
you describe would require many round trips to re-update results as you
move, so there's not much to optimize regarding the existing JS approach.


> I think these are some of the differences that we have to think through
> carefully before moving on (or not).
>
> BTW, I also think that the name of the header, "Geolocation-Request", is
> somewhat misleading, because it's not a request for geolocation.
>

Do you have any better name in mind? Happy to update the proposal with a
clearer name that reflects better what this means.