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

To follow-up on one aspect of this, I would like to understand how the
authors believe the browsers will identify a cooperating geo-ip server.
Are the authors presuming that the VPN servers or proxies will provide this
service?

There are open geo-ip databases, and open APIs to some of them, but I
wonder what they would think of the query load of all Chrome browsers
suddenly turning up at their door.  The information in them is also pretty
variable; checking one service that compares them (https://iplocation.io/ip/
,which I chose at random), the IPv6 information for my home connection was
absent, and the IPv4 information ranged in accuracy quite a bit.

One of the authors' stated goals is to improve the accuracy of the day
("This approach will not only enhance geolocation accuracy").  It seems to
me that it only does that in the case that the client is using a VPN or
proxy; how can it do that in the direct connection case if it is using
either the same geolocation data the server would have or what it would get
from a different public database?

regards,

Ted Hardie


On Mon, Oct 21, 2024 at 12:11 PM Ted Hardie <ted.ietf@gmail.com> wrote:

> I also remain concerned, but I will note some significant improvements,
> for which I thank the authors.  First, the text explaining the rationale
> for the work in the abstract and introduction now match Tommy's comments on
> the list much more closely, which will help folks ground the work.  Second,
> the document now specifies how the client is to get the geolocation it will
> provide:
>
> The client MUST determine geolocation using a cooperating server that
> looks up the clients IP address in a geo-IP database.
>
>
>
>
>
> If I understand the authors' thinking, if a client adheres to this MUST
> the situation will be no worse than the current situation, as it simply
> moves the lookup to the client.  Since this MUST is not part of the wire
> protocol, I have some serious reservations that it will be honored, but
> this proposal is definitely better than the previous situation in which how
> the client got the data was out of scope for the proposal.
>
> Having noted those improvements, I remain pretty convinced that this
> document is starting at the end of process that the working group would
> need to start at the beginning:  what's the current web architecture's
> reliance on location, what are the privacy implications of that, and, given
> those, how can we improve the client experience without making the privacy
> situation even worse.  As an example of the potential issues, this proposal
> adds a completely new condition (geolocation mismatch) and the document's
> note that this might cause a refresh of the server's geolocation data is
> certainly not the only potential result, as it very obviously might also be
> used to trigger reactions to the use of a VPN or Proxy.  The privacy
> concerns of that being more detectable need serious thought.
>
> Thanks again to the authors for the improvements to the document and their
> willingness to engage on the topic.
>
> regards,
>
> Ted Hardie
> Location Privacy Enthusiast
>
>
>
>
> On Sat, Oct 19, 2024 at 2:41 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>>
>> Hiya,
>>
>> Two years on, I still strongly oppose this work.
>>
>> Wouldn't we all be better off if we instead spent more effort on
>> trying to improve the Internet (and the web) by reducing the levels
>> of commercial surveillance (as we agreed to in RFC7258) rather than
>> enabling new ways to make that problem worse?
>>
>> I'm not questioning the authors' bona-fides here, but this would
>> be going in entirely the wrong direction.
>>
>> Thanks,
>> S.
>>
>>
>> On 10/19/24 04:38, internet-drafts@ietf.org wrote:
>> > Internet-Draft draft-pauly-httpbis-geoip-hint-01.txt is now available.
>> It is a
>> > work item of the HTTP (HTTPBIS) WG of the IETF.
>> >
>> >     Title:   The IP Geolocation HTTP Client Hint
>> >     Authors: Tommy Pauly
>> >              David Schinazi
>> >              Ciara McMullin
>> >              Dustin Mitchell
>> >     Name:    draft-pauly-httpbis-geoip-hint-01.txt
>> >     Pages:   7
>> >     Dates:   2024-10-18
>> >
>> > Abstract:
>> >
>> >     Techniques that improve user privacy by hiding original client IP
>> >     addresses, such as VPNs and proxies, have faced challenges with
>> >     server that rely on IP addresses to determine client location.
>> >     Maintaining a geographically relevant user experience requires large
>> >     pools of IP addresses, which can be costly.  Additionally, users
>> >     often receive inaccurate geolocation results because servers rely on
>> >     geo-IP feeds that can be outdated.  To address these challenges, we
>> >     can allow clients to actively send their network geolocation
>> directly
>> >     to the origin server via an HTTP Client Hint.  This approach will
>> not
>> >     only enhance geolocation accuracy and reduce IP costs, but it also
>> >     gives clients more transparency regarding their perceived
>> >     geolocation.
>> >
>> > The IETF datatracker status page for this Internet-Draft is:
>> > https://datatracker.ietf.org/doc/draft-pauly-httpbis-geoip-hint/
>> >
>> > There is also an HTML version available at:
>> > https://www.ietf.org/archive/id/draft-pauly-httpbis-geoip-hint-01.html
>> >
>> > A diff from the previous version is available at:
>> >
>> https://author-tools.ietf.org/iddiff?url2=draft-pauly-httpbis-geoip-hint-01
>> >
>> > Internet-Drafts are also available by rsync at:
>> > rsync.ietf.org::internet-drafts
>> >
>> >
>> >
>>
>>