Re: Geolocation header

On 03.08.2017 08:34, Guilherme Hermeto wrote:
>
> 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
I didn't say how they block JS, NoScript plugin is a way;
>
> 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.
>
yes and the difference between the Geolocation header is just this:

no Geolocation API no geolocation info for the server,
but the geolocation header doesn't have such a border ...

once allowed by the user, sent to any server without having too
and server owners are lucky => big data ...

> I do agree with you that the client MUST decide what it will render.
AND the server MUST NOT get any knowledge to let him decide what to send 
to the client ...,
as these is somewhat similar to censorship ...
>
> Maybe the Geolocation-Request header name is too imperative?
no there is only a few real use cases, and these are limited to mobiles ...
>
> 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).
>
that is the point, Set-Cookie is initiated by the server,
and there is no need of any user consent, because an operating system 
also don't ask for permission to store data in the pagefile ...

and this Geolocation header is initiated by the client ...