- From: Ted Hardie <ted.ietf@gmail.com>
- Date: Fri, 25 Oct 2024 14:53:39 +0100
- To: David Schinazi <dschinazi.ietf@gmail.com>
- Cc: Ben Schwartz <bemasc@meta.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Watson Ladd <watsonbladd@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CA+9kkMDe4zG9-u5SPSS8xsKQ2uZwzyrNGD=GnPaC0+bqjWne8g@mail.gmail.com>
Thanks to Tommy for his previous comments; since this occurs later in the thread and addresses one of the points I made as well, I'm choosing to answer here, but I have read the full thread to this point. On Thu, Oct 24, 2024 at 9:54 PM David Schinazi <dschinazi.ietf@gmail.com> wrote: > Hi everyone, > > I'm realizing I've been using some terminology without defining it, > leading to some confusion. Let's create a distinction between two distinct > kinds of IP-hiding technologies. > > 1) privacy proxies. Examples of these include Google's IP Protection and > Apple's iCloud Private Relay. These are affiliated with a browser, and > integrated pretty tightly with that browser (and/or operating system). The > goal of these is to prevent websites from having access to the user's IP > address, because that represents a stable tracking identifier. However, > these privacy proxies do not try to hide the user's coarse location. They > look at the client's IP address, map that to a city (for Google, we map it > to the closest grouping of 500'000 people for example), and then the > privacy proxy picks an egress IP address that's registered to that city in > a public geofeed. While websites have lost the ability to see the client's > IP address, they can still access the client's coarse location. Note that > this coarseness is often configurable by the user. > > Combined with Tommy's answer, what we see is a problem with data known to the geo-ip database about the egress IP selected by the privacy proxy. If it is stale or wrong, the client gets a worse experience. You want to improve that experience by having the privacy proxy select the location (based on its knowledge of source IP) rather than the server select it based on its geo-ip lookup of the egress IP. This would presumably also allow the privacy proxies to use fewer egress IPs. The difficulty I have here is that your technical solution is in no way limited to that deployment. As Ben's pointed out, there are a bunch of related deployments in which a standard VPN provider might want the same thing, and I am sure that once this is standardized we will see it used in places where there is no proxy in use at all (enterprises, for example, using DHCP location on the device to populate this and then give location-appropriate responses at service portals etc.). If we step back to the key issue, a completely different approach would be for a service to indicate its willingness to get crowd-sourced geofeeds from privacy proxies or other intermediaries. Those intermediaries could test for that service and provide an up-to-date and appropriate geolocation for their egress IPs. That sorts the issue of the geolocation being stale in a database by allowing for the creation of a local database that is correct, but leaves the rest of the system as it is. That approach has its own technical issues (you'd need to manage authentication, for example by a return routability check), but the simple fact that there are completely different approaches is why I want to push us back to the architectural discussion. I'm sure that's not terribly welcome feedback given that this document has already been percolating for 2 years, but I think that there is ample evidence that folks would be willing to engage in the discussion if you wanted to set up a design-team mailing list and hash it out. Thanks again for your willingness to engage and on the improvements and comments to date. regards, Ted Hardie
Received on Friday, 25 October 2024 13:54:11 UTC