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

Hi folks, and thanks for the input! I'm going to try to respond to various
comments and questions below.

> Stephen > From my POV, the situation with the web and location exposure
is currently just awful and getting worse over time. (That last isn't based
on explicit measurement.) ISTM that before adding more ways in which
people's location can be abused, we ought sit back and see if there's a
real improvement (for people, not services) to be found or not.

Today, many websites log the IP address of clients that visit them. They
use that information for many purposes, one of them is knowing where the
user is. I agree that the privacy properties of this mass collection are
pretty terrible, but no one on this thread has the power to magically make
that stop. What we're doing with this proposal (and the corresponding
privacy proxies that it is paired with) is to prevent the pervasive
collection of this information. The proxies now provide the server with an
IP address that no longer identifies the user. And now the coarse location
is an active signal as opposed to something available to pervasive
surveillance. I agree with your vision of how the world should be, but we
can't will that into existence, so we have to take pragmatic steps towards
it.

> Watson > Privacy sandbox proposals like accept hints are much more
powerful frameworks than is possible from GeoIP info which is
unconditionally given by browsers by virtue of connecting. When the
experience through a privacy preserving solution is worse, people turn it
off. We're better off with client controlled hints.

+1

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

You're correct that some of this comes down to trust that the client (in
most cases, a Web browser or similar application) doesn't abuse this. At
the end of the day, anyone using a given browser has to place some trust in
that browser. After all, the browser could be sending all the user's
passwords to the NomCom using syslog, but we all trust our browser to not
do that. A very relevant example is the W3C Geolocation API thanks to which
any website can request permission to see the user's location. If the user
consents [1], then their GPS coordinates are sent to the website. An evil
browser could skip the mandatory user consent step, but browsers don't. If
they did, I suspect the ensuing loss of market share would dwarf any
monetary benefits they might have gotten from selling such data.

[1] https://www.w3.org/TR/geolocation/#user-consent

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

The main deployment model the authors are looking into is privacy proxies
(e.g., Google's IP Protection and Apple's iCloud Private Relay). The
privacy proxy operator would provide the geoIP lookup service.

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

Our proposal makes the assumption that the privacy proxy's geoIP database
is higher quality (i.e., more up-to-date) than the one the average website
has access to. The assumption holds for the privacy proxy deployments that
are interested in this feature. For example, Google's geoIP team spends
quite a bit of resources to ensure that our database has high accuracy;
whereas we've found that it's common for website operators to get a free
copy of a geoIP database once and then never update it.

> Ben > If implemented today, this proposal would privilege vendor-provided
proxies over third-party proxies.  This seems undesirable to me.

As it stands today, no browser offers open APIs to switch out their privacy
proxy provider. In particular, you'd need to formalize exactly what kind of
blinded tokens are used, and a very high number of knobs such as token
refresh rate, proxy failure backoff timers, etc. That's something that
could happen one day, but it's a large effort no matter what. This proposal
doesn't change that: you'd just need to add the URL of the geoIP service to
the very long list of configuration parameters that would need to be
specified.

Thanks,
David

On Tue, Oct 22, 2024 at 7:31 AM Ben Schwartz <bemasc@meta.com> wrote:

> I understand this draft as a way to override the server's geo-IP database
> for cases where it is giving "wrong" answers.  However, the draft also says:
>
> > The client MUST determine geolocation using a cooperating server that
> looks up the client's IP address in a geo-IP database. ... the IP address
> used to generate this geolocation hint MUST be ... the "egress IP address"
>
> So to be precise, this draft is about allowing the client to select a
> "better" geo-IP database.  In practice, "better" means "affiliated with my
> current proxy (VPN) operator".  However, in current browsers and operating
> systems, a proxy operator has no way to inform the operating system of an
> affiliated geo-IP database server.  If the operating system or browser
> vendor chooses the geo-IP database server, then only vendor-affiliated
> proxies will benefit from improved answers under this system.
>
> If implemented today, this proposal would privilege vendor-provided
> proxies over third-party proxies.  This seems undesirable to me.
>
> This problem could be resolved by showing that these platforms will
> offer open (but proprietary) APIs to configure a geo-IP lookup server, by
> changing the geolocation rule from provenance to granularity (so that the
> platform can derive it from GPS), or by linking this proposal to a standard
> for network-based location that a proxy could override (e.g. DHCP
> GEOCONF_CIVIC, RFC 4776).
>
> --Ben
> ------------------------------
> *From:* internet-drafts@ietf.org <internet-drafts@ietf.org>
> *Sent:* Friday, October 18, 2024 11:38 PM
> *To:* i-d-announce@ietf.org <i-d-announce@ietf.org>
> *Cc:* ietf-http-wg@w3.org <ietf-http-wg@w3.org>
> *Subject:* I-D Action: draft-pauly-httpbis-geoip-hint-01.txt
>
>
>
> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-pauly-httpbis-geoip-hint/__;!!Bt8RZUm9aw!6mICNhw7bj76_cBbl-3D72eXYBcZxFGvFOI54tNs5lTdKMqdRbZpFhfeP8IJ_d5AZgN56hbXoGe7HJafNsNz1Q$
>
> There is also an HTML version available at:
>
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-pauly-httpbis-geoip-hint-01.html__;!!Bt8RZUm9aw!6mICNhw7bj76_cBbl-3D72eXYBcZxFGvFOI54tNs5lTdKMqdRbZpFhfeP8IJ_d5AZgN56hbXoGe7HJauIOfmgA$
>
> A diff from the previous version is available at:
>
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-pauly-httpbis-geoip-hint-01__;!!Bt8RZUm9aw!6mICNhw7bj76_cBbl-3D72eXYBcZxFGvFOI54tNs5lTdKMqdRbZpFhfeP8IJ_d5AZgN56hbXoGe7HJZikroa3Q$
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
>
>