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

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