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

Rafal Pietrak <cookie.rp@ztk-rp.eu> Tue, 06 September 2022 19:19 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21294C1522BE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 6 Sep 2022 12:19:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.663
X-Spam-Level:
X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8P7rzmURo98A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 6 Sep 2022 12:19:45 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A048C1522A7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 6 Sep 2022 12:19:44 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1oVe3n-00HJwx-8c for ietf-http-wg-dist@listhub.w3.org; Tue, 06 Sep 2022 19:16:35 +0000
Resent-Date: Tue, 06 Sep 2022 19:16:35 +0000
Resent-Message-Id: <E1oVe3n-00HJwx-8c@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <cookie.rp@ztk-rp.eu>) id 1oVe3l-00HJw0-UQ for ietf-http-wg@listhub.w3.org; Tue, 06 Sep 2022 19:16:33 +0000
Received: from sm.strop.com.pl ([83.17.179.219]) by titan.w3.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <cookie.rp@ztk-rp.eu>) id 1oVe3j-00BnyX-W3 for ietf-http-wg@w3.org; Tue, 06 Sep 2022 19:16:33 +0000
Received: from zorro.ztk-rp.eu ([::ffff:193.239.82.149]) (TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by sm.strop.com.pl with ESMTPS; Tue, 06 Sep 2022 21:16:12 +0200 id 00000000000200FA.0000000063179C7C.0000109A
Received: from [192.168.1.77] (port=37314) by zorro.ztk-rp.eu with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <cookie.rp@ztk-rp.eu>) id 1oVe3N-000ibo-8F for ietf-http-wg@w3.org; Tue, 06 Sep 2022 21:16:12 +0200
Message-ID: <63abfec0-5c1e-9831-df9a-f4a55664dd98@ztk-rp.eu>
Date: Tue, 06 Sep 2022 21:16:08 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0
Content-Language: en-US
To: ietf-http-wg@w3.org
References: <694DD6A2-5191-488C-8A93-FE670992204D@mnot.net> <202209060934.2869Y0hg066081@critter.freebsd.dk>
From: Rafal Pietrak <cookie.rp@ztk-rp.eu>
In-Reply-To: <202209060934.2869Y0hg066081@critter.freebsd.dk>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 192.168.1.77
X-SA-Exim-Mail-From: cookie.rp@ztk-rp.eu
X-SA-Exim-Version: 4.2.1 (built Sat, 13 Feb 2021 17:57:42 +0000)
X-SA-Exim-Scanned: Yes (on zorro.ztk-rp.eu)
Received-SPF: unknown (IP address lookup failed.) SPF=FROM; sender=cookie.rp@ztk-rp.eu; remoteip=::ffff:193.239.82.149; remotehost=; helo=zorro.ztk-rp.eu; receiver=sm.strop.com.pl;
Received-SPF: pass client-ip=83.17.179.219; envelope-from=cookie.rp@ztk-rp.eu; helo=sm.strop.com.pl
X-W3C-Hub-Spam-Status: No, score=-5.7
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, NICE_REPLY_A=-1.752, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1oVe3j-00BnyX-W3 1020507b84180f1311333d7f010e41f4
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Call for Adoption: draft-pauly-httpbis-geoip-hint
Archived-At: <https://www.w3.org/mid/63abfec0-5c1e-9831-df9a-f4a55664dd98@ztk-rp.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40378
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Dear experts.

Political concerns raised below made me risk being ridiculed, but those 
points are valid, yet IMHO in quite the opposite way.

As people stretch their "freedom" and push laws letting them pretend be 
of a different sex then they actually are (and I'm not judging, just 
taking that same freedom); I'd say that I (as an internet user) should 
have the right to select (tell server) any geolocation I'd like no 
matter where I'm actually accessing the network from. It should be 
illegal and actually penalised to ignore user-Agent declared geolocation 
in favor of some IP databases/location-provider.

User agent should be allowed to FORCE geolocation much like (or 
stronger) it is allowed to declare "accepted language".

I'm quite shocked with the hole discussion taking place on this topic.

With best regards.

Rafał

W dniu 06.09.2022 o 11:34, Poul-Henning Kamp pisze:
> --------
> Mark Nottingham writes:
> 
>> 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.
> 
> There are two different scopes to this topic:
> 
> * "Jurisdictional" - is the client subject to this or that law, jurisdiction or regulation.
> 
> * "Informational" - pretty much everything else.
> 
> There are all sorts of unholy regulation bubbling under the surface
> with respect to the first one, because politicians, justifiably,
> have become really keen on being able to tell genuine citizens apart
> from (foreign-controlled) bots and sock-puppets, and in parallel,
> protecting children from content which violate "community standards".
> 
> The main argument for exchanging such information at our level in the
> stack is that it will reduce the need for actual, and much more
> privacy-leaking, user authentication.
> 
> Despite that, it is still a minefield, political, cryptographically
> and technically, which I think we should stay very clear from.
> 
> Mark writes "certain circumstances" and "doesn't compromise privacy",
> but to increase chances of success, I think we need to be much more
> clear about our intentions.
> 
> I propose that we make it 100% clear up front, even before adopting
> this or any other proposal, that any information provided via the
> mechanism we (might) come up with, does not, and can not, carry any
> legal weight or message, because it SHALL be 100% up to the users
> whims and discretion, and that it SHALL be opt-out by default.
> 

-- 
Rafał Pietrak