Re: [hrpc] Censorship
Niels ten Oever <mail@nielstenoever.net> Tue, 15 March 2022 15:42 UTC
Return-Path: <mail@nielstenoever.net>
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7CF3A1584 for <hrpc@ietfa.amsl.com>; Tue, 15 Mar 2022 08:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxTWVWL4kRDH for <hrpc@ietfa.amsl.com>; Tue, 15 Mar 2022 08:42:01 -0700 (PDT)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527833A1591 for <hrpc@irtf.org>; Tue, 15 Mar 2022 08:42:00 -0700 (PDT)
Message-ID: <df014833-b237-48f5-3f19-3786ea0f8e15@nielstenoever.net>
Date: Tue, 15 Mar 2022 16:41:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: hrpc@irtf.org
References: <1779273019.188450.1647022617139@appsuite-gw2.open-xchange.com> <AF3A93BB-04A7-4E5F-B88A-CD441369874E@nohats.ca> <1bf024c5-9044-f806-9ce9-7a3377045f48@lear.ch> <25132.19040.388723.228805@gargle.gargle.HOWL> <B41A8BB3-BBF3-4D53-A14D-E1CE4BC782DF@pch.net> <20220313214033.rysyxmydzda2v3kw@crankycanuck.ca> <DgjJ0pvzPp-nRdnSldzL0wBJfaVS74YhB-k_2rln_6ucqpbfaVYynous2WNiSrd2uZ26kaBCYfL8WauDvRvD6WYVePDWrm8zpxSfgd6BRzM=@interpeer.io> <20220314151111.eird5poe2scjoywn@crankycanuck.ca>
From: Niels ten Oever <mail@nielstenoever.net>
In-Reply-To: <20220314151111.eird5poe2scjoywn@crankycanuck.ca>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Authenticated-As-Hash: f1842a279235a42f6aa2a2a81130733515c5a4ec
X-Virus-Scanned: by clamav at smarthost1.greenhost.nl
X-Scan-Signature: dd2f827d0435196b92fc1c56003c2d33
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/AMRHJg724x_7E4TQf7gjccigAIk>
Subject: Re: [hrpc] Censorship
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: hrpc discussion list <hrpc.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hrpc>, <mailto:hrpc-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hrpc/>
List-Post: <mailto:hrpc@irtf.org>
List-Help: <mailto:hrpc-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hrpc>, <mailto:hrpc-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2022 15:42:07 -0000
On 14-03-2022 16:11, Andrew Sullivan wrote: > Hi, > > [Still employed, still not speaking for them. This note is too long. > I didn't have time to write a short one.] > > On Mon, Mar 14, 2022 at 08:53:11AM +0000, Jens Finkhaeuser wrote: >> >> What this tells me is the mechanisms for "cutting off" parts of the Internet must exist, as a self-defense measure. > > There are lots of network-operational reasons for one network not to > speak to another part of the network. This is true both at the level > of particular applications and at the level of the network itself. > The IAB published a document about this some time ago (I was on the > IAB that approved it): https://www.rfc-editor.org/rfc/rfc7754.txt > > What I believe the sanctions statement is claiming is that there is a > legitimate category of blocklist that filters networks based on > political considerations related to who controls those target networks > or where they are located or something like that. It may be claiming > (or it may be motivated by a belief even if it is not claiming) that > not _every_ such filter is legitimate, but it does fundamentally > depend on granting the premise that it is sometimes legitimate to > institute such a filter. This is perhaps a subclass of RFC 7754 > section 3.2 bullet 2 or bullet 3, but I tend to think it is a category > that 7754 didn't actually consider fully. To be clear, I do not grant > the premise that it is ever legitimate to block networks on such > political grounds (I find the very premise to be a mistake) but I > want to take the argument seriously in its own terms. > > It is not reasonable in my opinion to claim such filters are > "self-defense", at least in the network sense. They are, rather, an > attempt to use one economic good (connectivity) to cause other kinds > of political change. > > I claim in my prior note to this list that such a weaponization[1] of > the Internet appears to be bad for freedom of association. I would > claim further that, to the extent such weaponization is mandatory > under some government policy, it is an abridgement of that freedom by > that government. > >> We seem to be discussing things here, however, as if those mechanisms were the exact same thing as legally mandating their use. >> > > When one uses a term that is currently widely used to denote > government-imposed restrictions on trade and other economic activities > at the risk of fine and imprisonment, one should not be surprised when > other people interpret one's intent as supporting legal mandates. > >> 3. A blocklist implemented to defend against attacks is often necessary (and we see this mechanism in firewall rules, spam filtering, etc. everywhere), and definitely not censorship; it's self-defense. >> > > This is, as I argue above, insufficiently nuanced analysis for the > purposes to which it is being put. I would suggest that the framework > in RFC 7754 section 4 offers a better mechanism for undertaking the > evaluation of any of the proposed blocklists. Here is how I'd do it: > > • Any blocklist sufficient to achieve the political goals of the > blocklist will automatically need to be large in scope (section > 4.1.1), because there are many networks that would inevitably be > affected. The sanctions statement is either naïve or disingenuous > when it proposes limiting its effects only to military or > propaganda targets: an army that invades another country, bombing > hospitals along the way, is hardly likely to cavil at the thought > of using a supposedly-civilian network for its purposes. In > addition, because of considerations of efficacy, either the > blocklist would be totally ineffective or else it would rapidly > grow and splinter the Internet very badly. > > • Any blocklist sufficient to achieve the political goals of the > blocklist would be low in granularity (section 4.1.2), largely for > the same reasons above. When cutting off networks completely, one > affects every use from within that network. > > • Any blocklist sufficient to achieve the political goals of the > blocklist would need to block not only the networks that are > directly implicated in the undesirable political operations of the > target, but also any network that provided communication to those > networks. That is the only way the blocklist could be efficacious > (section 4.1.3). This would entail serious consequences for the > very idea of the Internet. It might be politically unacceptable > to do such damage to the Internet, in which case the blocklist > would have low efficacy and would really be a symbolic gesture. A > symbolic gesture seems all but guaranteed to be useless (and > unsatisfying to those who want the desired political effect). > > • Any blocklist likely to be proposed would probably have negative > consequences for security (section 4.1.4) given the realities of > how the X.509 certificate system works. In particular, since > even the most granular blocklist would doubtless cover certain > government sites, those sites would not be able to obtain their > certificates through usual means. This will inevitably cause the > target government authorities to issue their own CAs that are to > be trusted for communication with the government. Given that the > working theory behind the blocklist is that said government is not > benevolent (otherwise it would presumably not be a target for > sanction), there are good reasons to doubt that such a CA would > secure communications in the ways one might desire. > > In sum, there are two possibilities. In one case, the blocklist will > be overbroad and have negative consequences for ordinary citizens, and > therefore fails the sanctions statement's principle, "Disconnecting > the population of a country from the Internet is a disproportionate > and inappropriate sanction." As I argued in my previous post, such a > blocklist protocol would have negative consequences for the right of > freedom of association. Alternatively, the blocklist will be too > small to be effective, and so fails the statement's principle, > "Ineffective sanctions waste effort and willpower and convey neither > unity nor conviction." Why would a small blocklist not be effective? This is unclear to me. > Such a blocklist and its associated protocol, > if required by law, would _still_ have negative effects for freedom of > association, because it would prevent some networks who might want to > connect to other networks from making those connections. As laid out in the FoA draft, there are legitimate limitations to FoAA, especially where it comes to violence. > And of > course, if the regime were totally voluntary then it would likely be > ignored For me it is also not clear why this is the case. It could be that many network operators don't have the capacity to come up with a solid and weighted reasoning. This is what the proposed body could offer. >, and the foreign policy preferences of the governments that > desired to use economic sanctions would not be implemented at all (but > that branch of the logic seems to me off-topic for this RG, so I won't > consider it further here). > > [1] What we today call sanctions were called, at the time of their > adoption as a tool of the League of Nations, "the economic weapon". > See Mulder, Nicholas, _The Ecomomic Weapon: The Rise of Sanctions as a > Tool of Modern War_. New Haven: YUP, 2022. > Sure, they were called that when they were used by states. But they don't have to be when they are deployed by network operators. Best, Niels > Best regards, > > A > -- Niels ten Oever, PhD Postdoctoral Researcher - Media Studies Department - University of Amsterdam Affiliated Faculty - Digital Democracy Institute - Simon Fraser University Non-Resident Fellow 2022-2023 - Center for Democracy & Technology Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas Research Fellow - Centre for Internet and Human Rights - European University Viadrina W: https://nielstenoever.net E: mail@nielstenoever.net T: @nielstenoever P/S/WA: +31629051853 PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 Read my latest article on Internet infrastructure governance in Globalizations here: https://www.tandfonline.com/doi/full/10.1080/14747731.2021.1953221
- [hrpc] Censorship Vittorio Bertola
- Re: [hrpc] Censorship Bill Woodcock
- Re: [hrpc] Censorship Vittorio Bertola
- Re: [hrpc] Censorship Bill Woodcock
- Re: [hrpc] Censorship Eliot Lear
- Re: [hrpc] Censorship Bill Woodcock
- Re: [hrpc] Censorship Eliot Lear
- Re: [hrpc] Censorship S Moonesamy
- Re: [hrpc] Censorship avri
- Re: [hrpc] Censorship Stephen Farrell
- Re: [hrpc] Censorship Bill Woodcock
- Re: [hrpc] Censorship Stephen Farrell
- Re: [hrpc] Censorship Bill Woodcock
- Re: [hrpc] Censorship Stephen Farrell
- Re: [hrpc] Censorship Bill Jouris
- Re: [hrpc] Censorship Jens Finkhaeuser
- Re: [hrpc] Censorship Vittorio Bertola
- Re: [hrpc] Censorship Paul Wouters
- Re: [hrpc] Censorship Eliot Lear
- Re: [hrpc] Censorship Mallory Knodel
- Re: [hrpc] Censorship Niels ten Oever
- Re: [hrpc] Censorship Niels ten Oever
- Re: [hrpc] Censorship bzs
- Re: [hrpc] Censorship Bill Woodcock
- Re: [hrpc] Censorship Bill Woodcock
- Re: [hrpc] Censorship Bill Woodcock
- Re: [hrpc] Censorship Bill Jouris
- Re: [hrpc] Censorship Bill Woodcock
- Re: [hrpc] Censorship farzaneh badii
- Re: [hrpc] Censorship Paul Wouters
- Re: [hrpc] Censorship Paul Wouters
- Re: [hrpc] Censorship Bill Woodcock
- Re: [hrpc] Censorship Andrew Sullivan
- Re: [hrpc] Censorship bzs
- Re: [hrpc] Censorship bzs
- Re: [hrpc] Censorship Jens Finkhaeuser
- Re: [hrpc] Censorship Bill Woodcock
- Re: [hrpc] Censorship S Moonesamy
- Re: [hrpc] Censorship Niels ten Oever
- Re: [hrpc] Censorship Alexandre Petrescu
- Re: [hrpc] Censorship Andrew Sullivan
- [hrpc] draft-irtf-hrpc-association (was Re: Censo… Andrew Sullivan
- Re: [hrpc] draft-irtf-hrpc-association (was Re: C… Niels ten Oever
- Re: [hrpc] Censorship Niels ten Oever
- Re: [hrpc] Censorship Andrew Sullivan
- Re: [hrpc] Censorship Jens Finkhaeuser
- Re: [hrpc] ***SPAM**** Re: Censorship Stephen Farrell
- Re: [hrpc] Censorship bzs
- Re: [hrpc] Censorship Alexandre Petrescu
- Re: [hrpc] ***SPAM**** Re: Censorship Mallory Knodel
- Re: [hrpc] Censorship Niels ten Oever
- Re: [hrpc] ***SPAM**** Re: Censorship Bill Woodcock
- Re: [hrpc] Censorship Mallory Knodel
- Re: [hrpc] ***SPAM**** Re: Censorship Mallory Knodel
- Re: [hrpc] ***SPAM**** Re: Censorship Niels ten Oever
- Re: [hrpc] Censorship farzaneh badii
- Re: [hrpc] ***SPAM**** Re: Censorship Eliot Lear
- Re: [hrpc] Censorship Andrew Sullivan
- Re: [hrpc] ***SPAM**** Re: Censorship Mallory Knodel
- Re: [hrpc] ***SPAM**** Re: Censorship Melinda Shore
- Re: [hrpc] Censorship Stephen Farrell
- Re: [hrpc] ***SPAM**** Re: Censorship Eliot Lear
- Re: [hrpc] Censorship Niels ten Oever
- Re: [hrpc] Censorship Niels ten Oever
- Re: [hrpc] Censorship farzaneh badii
- Re: [hrpc] Censorship Desiree Miloshevic
- Re: [hrpc] Censorship Alexandre Petrescu
- Re: [hrpc] Censorship Alexandre Petrescu
- Re: [hrpc] Censorship S Moonesamy
- Re: [hrpc] Censorship Desiree Miloshevic
- Re: [hrpc] Censorship Alexandre Petrescu
- Re: [hrpc] Censorship Alexandre Petrescu
- Re: [hrpc] Censorship Alexandre Petrescu
- Re: [hrpc] Censorship S Moonesamy
- Re: [hrpc] Censorship Alexandre Petrescu
- Re: [hrpc] Censorship Alexandre Petrescu
- Re: [hrpc] Censorship S Moonesamy
- Re: [hrpc] RIPE Cooperation Working Group Remote … Alexandre Petrescu