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

Hey david,

Appreciate the firm response :)

I would point out that surely the 'main' requirement is to provide a
"standard format" for the exchange of user geolocation via HTTP header.
Obviously adding lat/long would move this from being
deliberately non-precise geolocation info into potentially very precise
geolocation info, but if that extra lat/long information is entirely
optional and is the choice of the client, then you gain the ability to add
it in a standardized, formatted way and lose nothing in the way of user
privacy UNLESS the client chooses to return that information. I guess I am
confused by the concept of defining a header that is specifically designed
to be non-precise.

Thanks,

Rory


On Thu, Oct 24, 2024 at 1:14 PM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

> 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
>>
>

-- 
Rory Hewitt

https://www.linkedin.com/in/roryhewitt