Re: Geolocation header

On Wed, Aug 2, 2017 at 9:55 PM, Walter H. <walter.h@mathemainzel.info>
wrote:

> On Wed, August 2, 2017 22:45, Guilherme Hermeto wrote:
> > 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?
>
> this admin also blocks JS, so any fallback doesn't make a sense
>

Maybe I'm not understanding correctly. Are you are referring to people
without any access to Javascript?
Because Gelolocation API is not something new:
https://dev.w3.org/geo/api/spec-source.html


>
> > How would the user give his consent?
>
> Has any user ever given his consent to be tracked?
>

Browsers ask for the user permission to use the Gelolocation API and even
though the user gives the consent once, some clients keep tracking the user
for long after. So the potential for abuse already exists in the client. It
isn't being introduced on this proposal.


> > Are there any other headers which may
> > raise similar privacy issues and how was it handle there?
>
> these aren't handled,
> I don't know of an web admin that does a correct job: or do you know a
> popular website, that doesn't interpret the user agent?
>
> it is absolutely invalid to think that a server must do a clients work ...
> (the server MUST NOT decide what to sent, the client desides what to
> render and what not and how to render)
>
>
I do agree with you that the client MUST decide what it will render.

Maybe the Geolocation-Request header name is too imperative? The client
should decide if it will send the user location (after acquiring the proper
consent).

For instance, RFC 2109 <https://www.ietf.org/rfc/rfc2109.txt> describe the
Set-Cookie header which instructs the client to store a cookie and send
this cookie back in subsequent requests with the Cookie header. The client
may disable cookies and completely ignore the Set-Cookie header. I see a
correlation here, where the client is free to ignore the instruction from
the server, but the SetCookie process is initiated by the server (which, I
guess, also requires user consent).