- From: Ted Hardie <ted.ietf@gmail.com>
- Date: Mon, 21 Oct 2024 12:11:49 +0100
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Cc: ietf-http-wg@w3.org
- Message-ID: <CA+9kkMA1rHyk3FL56EG=bo7anO4y14XFypTLJoZcJ_G4mUxSog@mail.gmail.com>
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 > > > > > > > >
Received on Monday, 21 October 2024 11:12:20 UTC