Re: Geolocation header

On 08.08.2017 14:37, Luis Barguñó Jané wrote:
> 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 <mailto: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.
with this header proposal there isn't any limitation to this on every 
request ...
> 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".
after the 3rd question you will allow it for the whole site, believe me ...
otherways the non existence of a serious use case is just proven ...
>
> 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,
in comparison to the header proposal, the JS Geolocation API is used 
only when needed, because, you have these JS at every page then ...
> and move things out of that path if they don't need location.
in times of big bigger biggest data, you won't believe this yourself 
..., that this will happen;

just think of this HTML

<IMG SRC="https://www.example.com/img75756.gif">

with the header proposal, there will be sent the location data, with the 
JS Geolocation API, it would be quite strange ...
of course, you would be asked to allow this, but in case you have 
allowed earlier for the
URL https://www.example.com/showbarsaroundmylocation/

and now think of bad boys who put this HTML Tag anywhere; then you 
wouldn't take a notice
that you have sent your location to www.example.com, even your browser shows
https://www.bigelephant.co.jp
because you have allowed this, earlier ...

>
> That said, this should be recommended but can't be technically 
> enforced, since permissions are per-origin already in the JS 
> Geolocation API.
now you see with my explanation, that there is raising the vector in a 
not acceptable way ...
and the optimization you are talking about doesn't really make any 
sense, when you are talking serious about the
problems you're raising ...

Greetings from Austria