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