Re: Geolocation header

On Thu, Aug 3, 2017 at 7:50 AM, Walter H. <Walter.H@mathemainzel.info>
wrote:

> 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 get it, but as far as I can see, the same applies to Geolocation API too.
The user agent asks permission and it is stored for that particular domain
(like a cookie), so other servers wouldn't get it.

The problem I see is that, if the Geolocation-Request indeed work like a
Set-Cookie, it would expect all following requests to contain the
Geolocation header. In that case, the user agent would be sending the geo
information even when that is unnecessary... and I don't like that either.

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 ...
>
>
> Can you elaborate on "server MUST NOT get any knowledge to let him decide
what to send to the client"? Because servers acquire such knowledge all the
time, doing authentication, authorization... but I'm assuming that isn't
what you meant.

> 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 ...
>
>
>
Ok, I see what you mean here... on the cookie case the data is generated at
the server and in this case the data is generated at the client. I guess in
this case, since the client owns the data, makes sense for the process to
be initiated by the client (instead of the Geolocation-Request coming from
the server).

All said, what really concerns me is that even though there is the
Geolocation API to recommend how user agents should acquire and treat such
information there is no recommendation AFIAK about how the information
should be transmitted to the server and how the privacy measures the server
should observe while such information.

Should we work towards that?