Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques"

Eliot Lear <lear@cisco.com> Fri, 29 May 2020 08:34 UTC

Return-Path: <lear@cisco.com>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D683A0CEB for <pearg@ietfa.amsl.com>; Fri, 29 May 2020 01:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 cIHQdr5t_X8T for <pearg@ietfa.amsl.com>; Fri, 29 May 2020 01:34:19 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3D63A0CF1 for <pearg@irtf.org>; Fri, 29 May 2020 01:34:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11360; q=dns/txt; s=iport; t=1590741258; x=1591950858; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=h9UMONvrjC1VstPhblHo4ise+h57M9sCXmAJ8+bAiRg=; b=Kyk2P2gP7k3bZeSVV0hrS/n5oHsv3PHG3B7AuV/3PtOE8x4vGMXFA4Kj ubT7OOX8y5cDJvSuvv5f5VsYehcaK5G6A2ii5NtbO9OwJaOh/9+Tn6G8+ 2ahsQIkztKqepjk/Ma6A/VscKSZSlSNnYWk8KvH0+0zwiEAw0hPN1RS/6 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DjBADmx9Be/xbLJq1mHAEBAQEBAQcBARIBAQQEAQGCCoF5gXMBIBKEUYkBh2QlgQGSYIgRCwEBAQwBAS8EAQGERAKCHCU4EwIDAQELAQEFAQEBAgEGBG2FZYVzAQQBGAUGVgULCw40AgJXBoM5gl0grxZ2gTKFUYUkgTiJeYJmggCBEScMEIIYNT6HYjOCLQSPBYwMmC6CXoJ6i0eKKR6eEKsBg0kCBAYFAhWBaiKBVjMaCBsVZQGCPz0SGQ2QTBcVbgEJjRcDPwNnAgYBBwEBAwmNdAEB
X-IronPort-AV: E=Sophos; i="5.73,447,1583193600"; d="scan'208,217"; a="26559984"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 May 2020 08:34:14 +0000
Received: from ams3-vpn-dhcp2717.cisco.com (ams3-vpn-dhcp2717.cisco.com [10.61.74.157]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 04T8YD60031659 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 May 2020 08:34:14 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <5F07139C-6493-4A4B-B690-5C807C0A63A0@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2BA628C4-1F14-434B-B74B-15A6043E32FA"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 29 May 2020 10:34:13 +0200
In-Reply-To: <0dff13b6-079e-4cbb-bab7-284cd3bc81da@www.fastmail.com>
Cc: pearg@irtf.org
To: Christopher Wood <caw@heapingbits.net>
References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <F466D238-BCC9-476B-A876-1A72E5B1EEFD@cisco.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> <A05941FD-A44A-41DC-90ED-E79E6213700D@isoc.org> <79C21420-970E-46E2-9129-1886597924B1@cisco.com> <eb0f96dc-be68-3473-3a65-39b69e794b5c@cdt.org> <4A68E41D-EF4C-4675-8CFF-ECE0D708661C@cisco.com> <BY5PR06MB645197C9990FB76EA6734BFDB18E0@BY5PR06MB6451.namprd06.prod.outlook.com> <B502F2A7-0444-42D5-A33A-48007BDF8453@cisco.com> <BY5PR06MB6451A72C9AB698391B4A3340B18E0@BY5PR06MB6451.namprd06.prod.outlook.com> <0dff13b6-079e-4cbb-bab7-284cd3bc81da@www.fastmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.74.157, ams3-vpn-dhcp2717.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/f6dzSCo55xLi6yIqjEaJIWKL7ks>
Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques"
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2020 08:34:21 -0000

Hi Chris,


> To try and sharpen this point a bit: this document will certainly have gaps, and it's not a goal to fill all those gaps. This field moves quickly enough that trying to doing so would likely be futile.

I agree, and I am not suggesting that all gaps be covered.  That was a straw man put forth by the author.

> The chair decision to begin RGLC was based on the document's content and history, which was deemed sufficiently thorough with respect to relevant issues that protocol designers might consider going forward. That said, concrete suggestions to fill in those gaps are welcome! The authors and RG should certainly review them if provided, though we won't block progress waiting for additional content that doesn't substantially change the document's purpose.

I am sorry I didn’t catch this earlier, but I presumed that last call was meant to address these sorts of matters.  I would ask that it be noted that there is not a firm consensus on the document as it stands, as several of us have raised substantial issues.  Were I to explore them outside of this group in the broader IETF or research communities, I feel certain that you would not find consensus over the terminology.  You needn’t take my word for this.

To restate my concerns, there are three major points and one further down that may or may not be a major point:

The definition of censorship itself does not match common usage.
There is no definition of “censorship regime”.
The one reference I checked was clearly not appropriate in its usage, leading me to wonder about the others.

On terminology

It seems that it is being claimed that these are terms of art.  Regardless, a properly justified definition with an appropriate reference is in order.  This has not happened here.  There are two specific problems with the first sentence and its reference.  First, the text doesn’t match the reference given.  It is never appropriate to mislead the reader in this way.  Second, Wikipedia is not a primary source.  It is especially important to get the definition right in interdisciplinary work, especially when we are talking about defining a very politically charged term that the rest of the document is dedicated to ameliorating.  Beyond the academic matter, as I have previously alluded, by not setting that context, the authors risk offending many practitioners dedicated to infrastructure protection in the very first sentence of the first section.

Unless you find fault with my reasoning above, and I readily allow for such a possibility, we must agree that this is an issue.  If you place the onus on me to solve it and I refuse, the issue would remain.  Of course I am happy to be a part of solving the problem.  As it happens, Joe himself put forth a perfectly fine way to put the work into context, to which I readily agreed, but then he himself rejected, even though what he proposed is a close variant of what appears in the document’s abstract.  The substance here is the difference between “content" and “information” and perhaps motivation.  I am not suggesting a full exploration of what censorship is, but some justification for the language.  Same for “censorship regime”, given its similar negative connotations.

On references

We have previously seen sloppy use of references in at least one other RG.  By chance, I have spotted two errors, one to the WP reference and the other only because I know one of the authors of the referenced work.  I have not checked the others, but the pass rate right now is 0/2.  I would strongly suggest that the other references be checked through broader review.

Adding the additional non-technical example

On “Non-Technical [Prescription/Interference]”.  As I wrote above, I don’t expect the authors to be exhaustive, but I am told that the topic is out of scope, and yet the text remains.  I would suggest an add, perhaps around “swaying public thought”, to include something like “adding financial liability”.  The reason I think the point is important enough to raise is that from a scale perspective, the financial attack may be the most effective attack of all against profit-based platforms.  Is it major or minor?  I don’t know.  I lean toward “minor” only because the document might stand up without its mention, even though I would view it as an opportunity lost.

Eliot