Re: Call for Adoption: draft-pauly-httpbis-geoip-hint

[Ted Hardie <[e-mail]>]

Hi Mark, WG colleagues, and fans of Geographic Privacy,

On Mon, Sep 5, 2022 at 7:47 AM Mark Nottingham <[e-mail]> wrote:

> At IETF 114, we saw some interest in adding hints about the client's
> location to requests in certain circumstances, with the condition that it
> be done in a way that doesn't compromise privacy.
>
> My sense (as Chair) is that further discussion might result in a solution
> that's broadly acceptable, or it might conclude that we can't publish
> anything. However, we need a focal point for that discussion. One potential
> starting point would be the draft presented:
>   https://datatracker.ietf.org/doc/draft-pauly-httpbis-geoip-hint/
>
> As always, if we adopt this draft it will be a starting point; it may
> change considerably, and consensus on any remaining content will need to be
> confirmed. I'll add one more proviso: if we can't come to consensus on a
> solution with appropriate properties (especially, privacy), we won't move
> the document forward.
>
> Please indicate whether you support adopting this draft. The Call for
> Adoption will end in two weeks.
>
>
I do not support starting the discussion with this draft.  If the working
group would like to start a discussion on it, it should start with BCP
160/RFC 6280 and work out what architecture it wants to build.  The header
format is a trivial piece to that puzzle and it can come much, much later.
As many people who went through GeoPriv could tell you:

Information on location which is sent by a client can be combined with
other information in ways that many find startling and it is often
redistributed in ways that people find distressing.  Starting a new "client
sends geolocation info" project in a climate in which geolocation data is
currently being used to target soldiers, pregnant women, and members of the
LGBTQ community has to start from the recognition that turning this off and
being sure it is off is job one.  I see no evidence of that awareness in
this draft, despite my utter faith in Tommy and David's goodwill here.
Despite that faith, the optics are _terrible_ , and adopting it without
some attention to this is unconscionable.   If you think that the use of a
specific VPN and a provided GeoLocation of Alabaster, AL by the client
doesn't cause privacy concerns, I have a statue of Vulcan, currently
located in Birminghan, AL, that I'd like to sell; it's quite handsome, and
think you'll find it's good value for the money.

Once you get such an architecture, you need to recognize that information
provided by clients is often not trusted, and the use of trusted location
providers to associate location with a client is thus common in some
contexts.  You need to decide very early on whether this architecture will
ever allow third parties to provide the location and, if so, how (e.g. by
providing a signed object that the client can include).  Otherwise I can
claim to be in Alabaster to get around the GDPR restrictions that US
companies have placed on their data.  (While I see that the draft's
security considerations  touch on this, I have absolutely no faith at all
in the "use this, but not for access control decisions" language being
honored in the breach.)

Lastly, I will point out that this relies on a document that went through
the independent stream and requires adherence to its feed format and
references those feeds within this format.  Some thought as to why it had
to go to the independent stream might be worth the attention of the authors.

In short, I oppose this, and I think the working group should simply avoid
work in this area completely; it is fraught with pitfalls.  If you must do
work in the area, start from the right place, which is a privacy-preserving
architecture.  Get to the header format at the *end* of that process.

best regards,

Ted Hardie








> Cheers,
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>