Re: Geolocation header

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.

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.

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.

Regards,   Martin.

> An alternative version of this proposal through client hints would not even
> have the ability to ask for permission, and clients would only send the
> location to a site that has already permissions granted (through the JS api
> in the past). Geolocation-Request header would go away from the proposal.
> 
> This means that if you go NoScript then you would not even be able to get a
> permission prompt ever from JS, so you'd never attach this Geolocation
> header.
> 
> This way, it is not opening a new vector for attack. This new Geolocation
> header would only be sent to a site if that site was already in a situation
> where it could get location through JS at anytime (because permission was
> already granted to that origin). And the permission for the new header is
> in sync with the JS geolocation API, which any user agent should expose in
> settings - and let the user change the decision for any site at anytime
> <https://dev.w3.org/geo/api/spec-source.html#privacy_for_uas>.
> 
> Regarding use-cases, and why this is not limited to mobiles or irrelevant
> use cases:
> - On desktop browsers can also expose precise location through JS API,
> using wifi-based location (not ip-based). All main browsers already do that.
> - Search-like services, news, media-content, social networks (a huge chunk
> of internet traffic), and the internet as a whole would certainly benefit
> from a solution that reduces 2 roundtrips to 1 roundtrip when the user is
> Ok to send location to a site in order to get a local experience.
> 
> Getting a local experience seems quite far from censorship in my opinion.

Received on Saturday, 5 August 2017 08:28:52 UTC