Re: Geolocation header

Location aware services exist either way and for mobile devices, on which
bandwidth might be limited, I do see value in this "optimization" as not
all are fortunate of having access to high speed connections.

However, I believe the a couple areas could be better explained:

How should the service proceed if a zealous admin block the headers? Is
there a requirement to fallback to the JS geolocation API?

How would the user give his consent? Are there any other headers which may
raise similar privacy issues and how was it handle there?



On Wed, Aug 2, 2017 at 12:52 PM, Walter H. <Walter.H@mathemainzel.info>
wrote:

> On 02.08.2017 20:17, Luis Barguñó Jané wrote:
>
> IP-based location can be off by up to hundreds of Km (specially on carrier
> IPs).
>
> the reason for this is just simple; today it is my IP, tomorrow the IP of
> someone having the same ISP but living 100 miles away ...
>
> This is not a solution for the use case I'm presenting. For some
> location-aware services (e.g. I want restaurants near me), you need a
> precise location.
>
> bevor thinking about neccessarity of such a header, think of how the
> system itself knows its location?
> and then if it is conformable to privacy ...
>
> Also I'm not sure I understand why a good admin would block these headers.
>
> because of privacy?
>
> Why would we have a JS geolocation API
> <https://www.w3.org/TR/geolocation-API/> to provide precise location then?
>
> I don't know this API, but can you specify how this works on a normal PC
> (Windows/Linux/Unix/MacOSX)?
> from where does it get the location?
>
> This is not changing anything regarding permissions, and having
> geolocation headers would require the same user consent we currently have
> for the JS geolocation API.
>
> when blocking JS at all ...?
>
> All this proposal is just about a technical improvement on how location is
> shared with an origin (after permissions have already been granted), so a
> single roundtrip can provide local results (instead of two roundtrips).
>
> before thinking of this "optimization", it would be nice to think of less
> waste - especially tracking, advertising, malware, ... - in websites ...
>
>