Re: I-D Action: draft-pauly-httpbis-geoip-hint-01.txt

Hi Rory,

Our main requirement for this document is to not degrade user privacy.
Adding latitude and longitude would do just that, so we won't be adding it.
If you're interested in the exchange of precise location information on the
Web, I'd suggest taking a look at the W3C Geolocation API [1]. I think it
accomplishes what you need.

Thanks,
David

[1] https://www.w3.org/TR/geolocation/

On Thu, Oct 24, 2024 at 11:19 AM Rory Hewitt <rory.hewitt@gmail.com> wrote:

> Jumping in late to the conversation...
>
> I'm concerned that this RFC is conflating two separate issues:
>
> 1. Creating a standard way for servers to ask for (and clients to
> optionally return) information about client geolocation
> 2. Safety/security concerns about the fact that the information may be
> incorrect or may be too accurate.
>
> For #2 Specifically Section 6 Privacy Considerations:
>
> Any value provided in this hint MUST NOT be more specific than the
> information that could be obtained from the client's IP address and a
> well-maintained map of IP ranges to locations. In particular, when a
> privacy technology such as a VPN is in use, the value MUST NOT reveal
> information about the user's location that would otherwise be hidden.
>
> To prevent disclosing private information, this value cannot be based on
> other sources of geolocation data, such as GPS or physical latitude and
> longitude coordinates. Providing overly precise location information could
> expose sensitive user information especially when combined with other
> identifiable signals. Furthermore, when a client designates a location
> different from that derived from their IP address, the combination of
> designated location and IP can create a unique identifier, increasing the
> risk of cross-site tracking.
>
> The hint MUST NOT be sent by default or in an always-on manner. It should
> only be included in response to explicit server requests (e.g., via the
> Accept-CH header) and in contexts where sharing location data serves a
> clear purpose, such as for location-based services.
>
>
> <https://www.ietf.org/archive/id/draft-pauly-httpbis-geoip-hint-01.html#section-6-1>
>
>
> <https://www.ietf.org/archive/id/draft-pauly-httpbis-geoip-hint-01.html#section-6-2>
> I understand that there are real privacy considerations (leaving aside the
> VPN issue for now) with a client returning a latitude/longitude that can
> place them within inches of their actual location (obviously ignoring
> accuracy of such info).
>
> But surely the point of this RFC is really #1 - providing a STANDARD way
> for servers/clients to pass geolocation information. If clients (or their
> 'owners') CHOOSE to provide more precise information than Alpha2code,
> Region, and City, then that is their choice. Perhaps the server wants more
> info (servers ALWAYS want more info, and perhaps the client is willing to
> provide it, in order to get benefits provided by the server. But in any
> event, that possibility surely needs to be included in the specification,
> no?
>
> Therefore I would suggest that the format of the *Sec-CH-IP-Geo* header
> be changed to this (formatting may be incorrect - apologies):
>
>     Sec-CH-IP-Geo = Alpha2code,Region,City[,Lat,Long]
>
> where Lat,Long is entirely optional, and can be specified between 0
> decimal places and 5 decimal places.
>
> Thus if a server sends Accept-CH: Sec-CH-IP-Geo and the client sends only
> Sec-CH-IP-Geo: Alpha2code,Region,City in response but the server requires
> (or simply wants) more accurate information, it can let the client know
> (via a response page or similar) that it needs/wants a higher level of
> geolocation precision. It is then up to the client to provide that
> information or not.
>
> Of course, this might mean that the header name needs to be changed to
> Sec-CH-Geo, since it's providing information over and above what is
> available from an standard IP range map, but that's a separate
> consideration.
>
> Maybe all the questions have been asked and answered - if so apologies -
> I've been 'absent' for a while.
>
> Rory
>
> --
> Rory Hewitt
>
> https://www.linkedin.com/in/roryhewitt
>