Re: [hrpc] Censorship

Niels ten Oever <mail@nielstenoever.net> Mon, 14 March 2022 18:41 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 BF8453A111F for <hrpc@ietfa.amsl.com>; Mon, 14 Mar 2022 11:41:56 -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 LXgltJ2YOBg9 for <hrpc@ietfa.amsl.com>; Mon, 14 Mar 2022 11:41:52 -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 D4E703A1112 for <hrpc@irtf.org>; Mon, 14 Mar 2022 11:41:50 -0700 (PDT)
Message-ID: <fa9562f7-415e-a335-be05-2b137c0a3a21@nielstenoever.net>
Date: Mon, 14 Mar 2022 19:41:43 +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: 00ca572c58d2a72aaa1283be2358df10
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/81A-9iBCX9Fch-llcG3ikTMRFLk>
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: Mon, 14 Mar 2022 18:41:57 -0000

Deaar Andrew,

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.

A-ha! Here we might have found a root of some miscommunication. You see connectivity as economic good. I through we were talking about connectivity as the ability of people to exercise article 19 of the UDHR and the ICCPR, in other words, to communicate.

If this is the case, that provides a lot of frames around previous discussions about this. Then I also understand why you don't see it as 'political' that BGP does take into account economic considerations, but not other political considerations. Because you see connectivity as an inherent economic good.

My question would then be, is connectivity for you _only_ an economic good?


> 
> 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.
> 

It might be bad from the freedom of association of some actors, but again, human rights are indivisible, unalienable, and interrelated. And any limitation on human rights should be proportionate. So here we would need to take into account the whole impact of the actions within scope.

Best,

Niels

>> 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."  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. And of
> course, if the regime were totally voluntary then it would likely be
> ignored, 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.
> 
> 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