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

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