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

The issue with adding the ability to send more information is that then
that information can be sent when it shouldn't be, for example due to bugs.
Since we have no need for this extra information (due to the preexisting
W3C API), it's safest to not include it. By the way, we're not defining the
format in this document, we're reusing the format from RFC 8805. That
doesn't include latitude/longitude, again because there is just no need for
it. Deviating from that format to add data that is unnecessary and
dangerous will add risk and complexity for no benefit.

David

On Thu, Oct 24, 2024 at 1:42 PM Rory Hewitt <rory.hewitt@gmail.com> wrote:

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