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

Hi Stephen,

If you'll allow me to reuse your analogy, you're asking us for a full
analysis of the cause and impact of global warming before we can start
designing an umbrella. I'm exaggerating a little bit but you get the idea
:-) As we've discussed in this thread, there are abuse vectors that the
IETF can't do anything about. Requiring that we not make things worse is
absolutely fair, but we can't fix the whole world in one draft. On the
topic of designing the system to reduce the potential for abuse, I'm
absolutely supportive of research in this direction. But so far I haven't
seen the sketch of an idea that could work without trusting the HTTP client
to safeguard location information. My previous email outlined the
properties we need in order to incentivize use of IP-hiding technologies.
I'd love to brainstorm designs that meet those properties with anyone
interested. I'm also happy to think through what additional threat vectors
we can defend against, but let's not call it a full analysis of everything.

David

On Tue, Oct 29, 2024 at 2:33 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hiya,
>
> On 29/10/2024 19:11, Watson Ladd wrote:
> > Location data is only shared by user agents or obtained by
> > applications on mobile with an interactive permission.
>
> I don't believe that is always the case, see e.g. [1]. Are we
> assuming the likes of firebase/google play services (to use
> the examples from [1]) will use this kind of header and not let
> their servers see the client IP as well? If so, that'd perhaps
> be good. That's part of the analysis that seems missing to me.
>
>     [1]
> https://www.scss.tcd.ie/Doug.Leith/pubs/contact_tracing_app_traffic.pdf
>
> There's also the fact that so many apps ask for so many permissions
> and that users do not understand that their location information is
> going to be stored and/or used for advertising when they think
> they're just taking a shortcut for checking the weather. I would
> absolutely not consider that to constitute a form of real consent
> myself.
>
> > GeoIP data is
> > everywhere because IP addresses are revealed by connecting to servers.
> > These have fundamentally different privacy impacts. Preserving IP
> > across connections is a major tracking vector, so we need to enable
> > technologies to avoid it.
> >
> > Adding a header as a signaling means solves the search personalization
> > case which really does matter, especially on mobile. It's a major
> > barrier to enabling privacy enhancing technologies that break the IP
> > tracking vector as a worse user experience leads to people turning
> > things off.
>
> It might help sometimes *and* it might get abused by apps to send
> location data using this header when they don't have permission to
> access e.g. lat/long data. I don't know how we can decide this is an
> overall improvement based on just the proposal to define a new header
> field.
>
> > Yes, this doesn't solve Grindr selling location data that outs a
> > priest (
> https://www.pillarcatholic.com/p/pillar-investigates-usccb-gen-sec).
> > There really is not a technical solution I can think of to solve that
> > problem, but this work does enable solving the IP tracking vector that
> > is increasingly used as third party cookies go away.
>
> It's entirely possible there are situations that can be improved via
> a header like this, I never said otherwise. My claim is that we ought
> start from an analysis of how location information is being abused
> before deciding that this thing will be overall beneficial. I'm not
> hoping that we can solve all problems, but I do think we could better
> justify that some proposed new thing is an overall improvement and not
> just another way that things end up worse.
>
> Cheers,
> S.
>
>
>
>