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

Hi Ted,

While going back to the drawing board can be sad, I'm definitely open to
it. We have specific design requirements, but we're not wedded to any
particular solution. I'm not sure I understand your alternative proposal
though. In today's world, privacy proxies already publish their egress IPs
publicly along with the corresponding geos. (For example, Apple's is at
[1].) One issue is that everyone hasn't ingested that list, but that could
be solved over time. The other issue is that we'd like to reduce the
granularity of this published mapping. This has two advantages: first it
saves the proxy provider money now that IPv4 addresses are expensive, and
second it improves privacy - because now the egress IP has a more coarse
geographic mapping, and only the servers that request the client hint get
access to the more detailed location. The browser can also now choose to
refuse to send the client hint if it determines that the server shouldn't
have this information. Unless I'm misunderstanding your proposal, it
doesn't provide either of these two advantages.

David

[1] https://mask-api.icloud.com/egress-ip-ranges.csv

On Fri, Oct 25, 2024 at 6:54 AM Ted Hardie <ted.ietf@gmail.com> wrote:

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