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

I share a lot of Ted's concerns and am opposed to adoption for roughly similar reasons.  I definitely agree regarding optics.

I have spent some time discussing the very narrow use case that Tommy and David have in mind here.  In the very specific domain they are thinking of, there might be something very narrow that could work with something approximating acceptable privacy.  However - and this is a big one - I don't see any way in which we could ensure that the mechanisms defined for that use case do not get reused outside of that domain.  The draft certainly doesn't attempt to address the abuse risk.

To my mind, having a solid strategy for managing that risk is a *prerequisite* for starting this work.  Ted suggests mapping out an architecture, which is one way to do that.  The other might be looking at what mechanisms (or otherwise) could be used to make usage meaningfully constrained.

Cheers,
Martin

On Mon, Sep 5, 2022, at 22:38, Ted Hardie wrote:
> Hi Mark, WG colleagues, and fans of Geographic Privacy, 
>
> On Mon, Sep 5, 2022 at 7:47 AM Mark Nottingham <mnot@mnot.net> 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/
>> 
>>

Received on Tuesday, 6 September 2022 00:29:36 UTC