- From: Ted Hardie <ted.ietf@gmail.com>
- Date: Tue, 22 Oct 2024 09:19:07 +0100
- To: Watson Ladd <watsonbladd@gmail.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CA+9kkMDo7sGowL5RLAaffBXFaUF33MR2Y1umKiD8y+ryp+WzmQ@mail.gmail.com>
Hi Watson, I originally thought that you were arguing against geo-ip being used for personalization at all, and that you were arguing for using client-hints for relevant characteristics instead. Seeing Stephen's message, though, I wondered whether you were arguing that treating geo-data as a client hint was better than deriving it from geo-ip data. Can you clarify? I will point out that the availability of geo-data in a hint is very unlikely to stop servers from accessing geo-ip when it is not made available by the client and that they will also likely use it as an additional mechanism to detect the use. of VPNs and proxies (those IPs are pretty commonly called out in geo-ip data anyway, but this gives an additional method to identify fresh ones, like the ones that are spun up in AWS cloud services at need). regards, Ted Hardie On Tue, Oct 22, 2024 at 1:44 AM Watson Ladd <watsonbladd@gmail.com> wrote: > Is this the rehash old battles thread? > > GeoIP does lots of useful personalization and can hurt when wrong. > Clients providing a hint is much nicer akin to the way en-US vs en-UK > works for deciding what subsidiary you are most interested in. > > If the personalization issues can use a client provided signal that > avoids current state where many privacy preserving technologies > provide a worse experience because of inaccurate personalization > responses. > > 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. > > > On Sun, Oct 20, 2024 at 4:08 PM Mark Nottingham <mnot@mnot.net> wrote: > > > > Thanks. For reference: > > > > * > https://www.w3.org/mid/CA+9kkMBbzXUDTmXnp7KRXdKUTdHn5HjjDLBjwkwHYT3-yiKheg@mail.gmail.com > > * > https://www.w3.org/mid/CA+9kkMAScAXrFrxd3wCJwfw7CDJv0nph50Bf2-hbRPskypffQg@mail.gmail.com > > > > Cheers, > > > > > > > On 21 Oct 2024, at 10:00 am, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > > > > > > > > > > > > On 20/10/2024 23:58, Mark Nottingham wrote: > > >> Do you have a link for Ted's arguments, or another way we can locate > them? > > > > > > Oh sorry. I searched for geoip in the subject line of the WG > > > archive (locally in my case). That resulted in a bunch of mails > > > from 2022. > > > > > > Cheers, > > > S. > > > > > >>> On 21 Oct 2024, at 9:56 am, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > > >>> > > >>> > > >>> > > >>> On 20/10/2024 23:41, Mark Nottingham wrote: > > >>>> Hi Stephen, > > >>>> It'd be helpful if you could explain why you oppose it -- either > > >>>> directly or by reference (if you've made the argument before). It's > > >>>> hard to evaluate without more detail. > > >>> > > >>> Same as before. In that case I think I mostly +1'd Ted's arguments. > > >>> > > >>> Bottom line though is the handling of location in the web is utterly > > >>> awful today. We should make efforts to fix that before we add new > > >>> ways that can and will be used to make it even worse. > > >>> > > >>> Cheers, > > >>> S. > > >>> > > >>> > > >>>> Cheers, > > >>>>> On 20 Oct 2024, at 12:36 am, 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 > > >>>> -- Mark Nottingham https://www.mnot.net/ > > >>> > > >> -- > > >> Mark Nottingham https://www.mnot.net/ > > > > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > > > > -- > Astra mortemque praestare gradatim > >
Received on Tuesday, 22 October 2024 08:19:41 UTC