From nobody Tue May 5 06:39:27 2020 Return-Path: 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 DD4583A0789 for ; Tue, 5 May 2020 06:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 a4xhs5t2TGVD for ; Tue, 5 May 2020 06:39:24 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053853A074D for ; Tue, 5 May 2020 06:39:23 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 4FE1A80289; Tue, 5 May 2020 15:39:21 +0200 (CEST) To: "pearg@irtf.org" From: Fernando Gont Message-ID: Date: Tue, 5 May 2020 10:22:30 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Pearg] Predictable IPv6 Flow Labels X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 13:39:26 -0000 Folks, Just found this paper on the privacy implications of predictable IPv6 Flow Labels: https://www.computer.org/csdl/proceedings-article/sp/2020/349700b594/1j2LgrHDR2o FWIW, we are eager for reviews of our IRTF I-D entitled "On the Generation of Transient Numeric Identifiers" (https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation-01), such that issues with predictable transient numeric identifiers can be avoided for once and for all. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed May 6 05:17:56 2020 Return-Path: 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 6B2033A09ED for ; Wed, 6 May 2020 05:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=OlLJbpMs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LDbLHQGN 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 F1I4nXThgevd for ; Wed, 6 May 2020 05:17:52 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1EB3A09EC for ; Wed, 6 May 2020 05:17:52 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9DDF25C014B for ; Wed, 6 May 2020 08:17:51 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Wed, 06 May 2020 08:17:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=WCQQ7/fw62NuH/X0Veg49swC19U9h0oDF883K9XyXC0=; b=OlLJbpMs ESlVlSsBtvv2X2Qu7biD+DUJxVdpe12qE7C/k3fbjb10lwrUHONGLEKJqb0OONET SIgG52a1C4ZGMLHf7QWFXnwHN5uGQzqAqPozDUvpN/QPAWXWLPro3p85y0XZuHRE i983v6QE9YVJB3pqW28L+aszsyGj4MXDVpfPH16GxUWUxguGPw+AFN+YWvZiEVEA r2Sw8aHJDxCLy1QyzZ/Di6EIdyTeRf1fIvGKDYy9AMqKgDvTxk4XPI5a/DgkzVyR UvO3VsLvs/+4fPEWbzo8RU7ZqTG5gsokgdxOsBlEUnLHV6lVkmZncM8uS2eRszaY 2Hit6a7BFGtEpA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=WCQQ7/fw62NuH/X0Veg49swC19U9h 0oDF883K9XyXC0=; b=LDbLHQGNY2i5musAa4LJadv+PN4akE3TXIrje8IXElg6y 48rLcrP0OndeLRkF8FdwSqjSG3qSZJ8X/QJcIQqPwds5R8r09O7bYn0HNmJ77NZt od2IF8U5qnEqlbU8O27FAB4E20yA6/OhjXwtLWbLSNUD33txzQwlR4sl7DhfxrLn GqLlRiljbhYuRRZmwqMtjsm/91ItDVtLwEgiolAaLlk+910eWQPFgSzCfpsI0+oK GVuQ9PNqKTJ+gTwI4WonlM2aUME1HN3bwWMNzKJMuSn/Kc/8vEfBpIJjH3uofPuf 1TBC6lywEuzINCTR2kL1WdyfZixNChKmXopniJ5Cg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeekgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfieshhgv rghpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnheptdejtdehkeehffelle fgjeffgfdttdektdduieeuleffteffhfdtieelvdfgveevnecuffhomhgrihhnpehsuhhr vhgvhihmohhnkhgvhidrtghomhdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdr nhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5756E3C00A1; Wed, 6 May 2020 08:17:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 x-forwarded-message-id: <158857581528.28405.17372040856513106617@ietfa.amsl.com> Message-Id: <87765531-e71a-4838-86c9-6ddb548844a0@www.fastmail.com> Date: Wed, 06 May 2020 05:17:31 -0700 From: "Christopher Wood" To: pearg@irtf.org Content-Type: text/plain Archived-At: Subject: [Pearg] Fwd: Reminder: Survey on planning for possible online IETF meetings X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 12:17:55 -0000 If you've not done so already, please consider completing the survey below. Thanks, Chris ----- Original message ----- From: IETF Executive Director To: IETF Announcement List Subject: Reminder: Survey on planning for possible online IETF meetings Date: Monday, May 04, 2020 12:03 AM This is a reminder that we need the IETF community to help us plan for the possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 may not be able to go ahead in person. You can help us with this by filling out the following survey: https://www.surveymonkey.com/r/5328FFJ So far we have 114 responses and we would ideally like 500 or more. The survey contains the following pages and will take 15-20 minutes to complete: 1. Welcome 2. Online IETF 107 and the subsequent virtual interims 3. Replacing a cancelled in-person meeting 4. Online meeting format and timezone 5. Replicating humming 6. Replicating the hallway environment 7. Fees 8. Thanks and anything else We run the survey in anonymous mode which means that we only see data that you explicitly provide. Thank you in advance for your help. -- Alissa Cooper, IETF Chair Jay Daley, IETF Executive Director Colin Perkins, IRTF Chair _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Wed May 13 22:46:13 2020 Return-Path: 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 7020E3A0B8A for ; Wed, 13 May 2020 22:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=salesforce.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 kNqOXfM8MyOO for ; Wed, 13 May 2020 22:46:09 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D5F3A0B88 for ; Wed, 13 May 2020 22:46:09 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id d7so284545ioq.5 for ; Wed, 13 May 2020 22:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=2k5M/scuRy1lkVavemAyoXL8sVE5LKPEaGNHARGqPWs=; b=KqP8vrLaD7YBneI/VI864s8hNg5/ZfPAt94/1BTZ7XFNEpJT7Afjc+REu16NIoFoGW zhTkvlEWKLdXEV3cf+v7CCXJ/xvQ4Qdb4BrvhF7y8gop9cPva9DhNQR5VazNI8ogN7bE gJF8L7ZlQlLEbPtqUvjPtvz+5yQuXYru5tsjw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2k5M/scuRy1lkVavemAyoXL8sVE5LKPEaGNHARGqPWs=; b=M9lB3fw2BV4GGHXGg9792F7QJWdG3J6dBbm40j+XvA1pOJcxzGIQTuU6jd/FPRd59A 2RMtHJjDvXCqg/fFSnYBrJL6w8+aklE0nagA2YgVBjzIgLEgRr2bfVyJ52WE7TXDRL/5 9/oMRTFUGIRhVMHLmnXyUI9Lkm0ymeArZat7yGq/7genPsJ89G6ZFWksXH9ObCiRP5tS MuUgxO/W5O81rAgG33N4jRf2mLFxVm/Qom0XSFTspBBPwZB8TvKOEe62vD8Q1Vr+WavR 9c5WgPX5cvn7KR9oZWGW7bhF47AGcfFvJ1zhC8PU+wUGJsD/S4/VVzgNGigjHCz0ZtAJ ze6A== X-Gm-Message-State: AGi0PuZRFwJ5qkZTcUFY85T3+bWOj6UDz+3BfNJHAiAOUwM+Cj9Ewd52 OrhAXjCSlYfAtux75bVOP35gf5yGOzf1hUqg1Gn9F3E/m2XWPQ== X-Google-Smtp-Source: APiQypI3zSroexCVONr0Sc6SiFk1b8gDfqS4zoYSXQZJfNUywf3RUoOkRg3XwEKNpsUiSRXzgmqfodXmTXsb/rbadt4= X-Received: by 2002:a05:6638:60e:: with SMTP id g14mr3054681jar.54.1589435168479; Wed, 13 May 2020 22:46:08 -0700 (PDT) MIME-Version: 1.0 From: Shivan Sahib Date: Wed, 13 May 2020 22:45:57 -0700 Message-ID: To: Fernando Gont , pearg@irtf.org Content-Type: multipart/alternative; boundary="0000000000009c7e0105a59536ad" Archived-At: Subject: [Pearg] Review of draft-irtf-pearg-numeric-ids-generation-01 X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 05:46:12 -0000 --0000000000009c7e0105a59536ad Content-Type: text/plain; charset="UTF-8" Hi Fernando, I did a quick review of https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation-01 (with no hat on). It would be great to see more reviews though. I opened a PR addressing some of the nits I found here: https://github.com/fgont/numeric-ids/pull/1 Generally, I found the analysis comprehensive. One small comment is that there should probably be a reference for "... some popular operating systems (notably Microsoft Windows) still fail to implement transport protocol ephemeral port randomization... " in Section 4. Also I might just be missing it, but I didn't find any description (through reference or otherwise) of the negative effects of predictable DNS TxIDs in either this document or https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-history-02. Thanks for your work on this! Shivan --0000000000009c7e0105a59536ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fernando,

I did a quick review of=C2= =A0https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generat= ion-01=C2=A0(with no hat on). It would be great to see more reviews tho= ugh.=C2=A0

I opened a PR addressing some of the ni= ts I found here:=C2=A0https://github.com/fgont/numeric-ids/pull/1

Generally, I found the analysis comprehensive. One small comment is that t= here should probably be a reference for "... some popular operating sy= stems (notably Microsoft Windows) still fail to implement transport protoco= l ephemeral port randomization... " in Section 4.=C2=A0

=
Also I might just be missing it, but I didn't find any descr= iption (through reference or otherwise) of the negative effects of predicta= ble DNS TxIDs in either this document or=C2=A0https://tools.ietf.org/h= tml/draft-irtf-pearg-numeric-ids-history-02.=C2=A0

=
Thanks for your work on this!

Shivan
--0000000000009c7e0105a59536ad-- From nobody Thu May 14 18:09:17 2020 Return-Path: X-Original-To: pearg@irtf.org Delivered-To: pearg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5FD3A005D; Thu, 14 May 2020 18:09:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pearg@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pearg@irtf.org Message-ID: <158950494825.32676.4874273590052962910@ietfa.amsl.com> Date: Thu, 14 May 2020 18:09:08 -0700 Archived-At: Subject: [Pearg] I-D Action: draft-irtf-pearg-numeric-ids-generation-02.txt X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 01:09:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhancements and Assessments Research Group RG of the IRTF. Title : On the Generation of Transient Numeric Identifiers Authors : Fernando Gont Ivan Arce Filename : draft-irtf-pearg-numeric-ids-generation-02.txt Pages : 34 Date : 2020-05-14 Abstract: This document performs an analysis of the security and privacy implications of different types of "numeric identifiers" used in IETF protocols, and tries to categorize them based on their interoperability requirements and the associated failure severity when such requirements are not met. Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier category, while minimizing the security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, this describes a number of algorithms that have been employed in real implementations to generate transient numeric identifiers and analyzes their security and privacy properties. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-pearg-numeric-ids-generation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation-02 https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-generation-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-pearg-numeric-ids-generation-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 15 08:49:53 2020 Return-Path: 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 5D09E3A0BB3 for ; Fri, 15 May 2020 08:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 epxCxb1-GsRb for ; Fri, 15 May 2020 08:49:45 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36963A0BD5 for ; Fri, 15 May 2020 08:49:41 -0700 (PDT) Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id BC3BC283744; Fri, 15 May 2020 15:49:38 +0000 (UTC) To: Shivan Sahib , pearg@irtf.org References: From: Fernando Gont Message-ID: <07971a08-4d53-308e-35b8-ae5c1c7ed55b@si6networks.com> Date: Fri, 15 May 2020 00:45:48 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Pearg] Review of draft-irtf-pearg-numeric-ids-generation-01 X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 15:49:52 -0000 Hello, Shivan, On 14/5/20 02:45, Shivan Sahib wrote: > > I did a quick review of > https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation-01 (with > no hat on). It would be great to see more reviews though. > > I opened a PR addressing some of the nits I found here: > https://github.com/fgont/numeric-ids/pull/1 Thanks a lot for this! FWIW, I've merged it, and rev'ed the document. > Generally, I found the analysis comprehensive. One small comment is that > there should probably be a reference for "... some popular operating > systems (notably Microsoft Windows) still fail to implement transport > protocol ephemeral port randomization... " in Section 4. Will do. > Also I might just be missing it, but I didn't find any description > (through reference or otherwise) of the negative effects of predictable > DNS TxIDs in either this document or > https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-history-02. We had mid-way a whole section on the DNS TxID, although I wasn't sure it would add much. I'll do this, I'll give it a shot at having a similar timeline ofr the TxID. If I feel it's useful, I'll incorporate it. Otherwise, at the very least we'll provide some references/pointers for the implications of predictable TxIDs. Thanks a lot! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon May 18 05:41:59 2020 Return-Path: X-Original-To: pearg@irtf.org Delivered-To: pearg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2713A0B64; Mon, 18 May 2020 05:41:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pearg@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pearg@irtf.org Message-ID: <158980571344.1565.12748236325565177653@ietfa.amsl.com> Date: Mon, 18 May 2020 05:41:53 -0700 Archived-At: Subject: [Pearg] I-D Action: draft-irtf-pearg-safe-internet-measurement-03.txt X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 12:41:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhancements and Assessments Research Group RG of the IRTF. Title : Guidelines for Performing Safe Measurement on the Internet Author : Iain R. Learmonth Filename : draft-irtf-pearg-safe-internet-measurement-03.txt Pages : 10 Date : 2020-05-18 Abstract: Researchers from industry and academia often use Internet measurements as part of their work. While these measurements can give insight into the functioning and usage of the Internet, they can come at the cost of user privacy. This document describes guidelines for ensuring that such measurements can be carried out safely. Note Comments are solicited and should be addressed to the research group's mailing list at pearg@irtf.org and/or the author(s). The sources for this draft are at: https://github.com/irl/draft-safe-internet-measurement The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-pearg-safe-internet-measurement/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-pearg-safe-internet-measurement-03 https://datatracker.ietf.org/doc/html/draft-irtf-pearg-safe-internet-measurement-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-pearg-safe-internet-measurement-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 18 09:43:23 2020 Return-Path: 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 E49DF3A08A6 for ; Mon, 18 May 2020 09:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 V27pZkH1pV9S for ; Mon, 18 May 2020 09:43:19 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2057.outbound.protection.outlook.com [40.107.220.57]) (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 96DEE3A08D2 for ; Mon, 18 May 2020 09:43:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LkF/xT2T8ikBEmaqoXlzvsCcyxonEfIDZo6bhfpBnIQlmYx6sM3utO4YkRVDJryF8oDYA+2eZ0cTLIg8zt5YgbSy/0WRZaX/fKSlQbRHCXu98NiZgWTzJlDqnr9VU6a5sEsvuZysJSKJK5x8QH3FP3IlDPIMkJRdUxIoRw8bUaSCKJqQxHvrcABCFSsXok8RJ/7qGxgfJ4SEjGBPnzvFCPyfdZv9BHYeVaeFm1TtxNCevWd4CELerdbgquMOlIH1dHkk33Fm28XHLR6Z3Pwx/1w0vAegtO7ZxP4H0bFQZuoTBjOWpJgDi0crkwrr/lmp9bukuNNycsAfx1+H0fXyng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0iw4SjsDMtzwiBtl21dtTyQ+/4YVJMORs0tY6Dt5eHo=; b=E5vbmqf+UTuJm1ET7R86Su337+OUhDGnQ0vn4HLIGjShcDftonl4+OOwPo3jvXESqXGRfFHo3ciXkVV2PksJFsfXE5vxLshwMLolX8XY9EmYh00vnpcrcPnaeIVeO3Ku+gUZF1Aw2hAsgf4JeNDxp+8B2rCdD3K82kEEIzn5lvS3hIUEXxXev13PhKtves7d8E6fz75yA7nOII9lo8zZ4y47JDhFa3zaWATpB0rrKXAFmwqG2w2tlleHep6VPvf6g/ihd63ydk9jYOPIxZjYIkb7WveTeMOEWphgsViGZ6Z/NGzw/Uv0pTd6YBtAna+Vt5R9qNxQVXT7uoJK8Qkrrg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0iw4SjsDMtzwiBtl21dtTyQ+/4YVJMORs0tY6Dt5eHo=; b=nzWpe4oS6DEo5wExsJyza8xvZPWIKGvXnv026bzzaB529n1xMp78XFN7VYMqU4glxDMYcbzG+WYW2iK50hOQp3ak5gOe7frubfUghYMUES1S3wbRPiIFXoRsz2N7mwoT0cTnogpO7V/XIuem30rSlY8bpJgxMq3druUqeW6wpiA= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BY5PR06MB6596.namprd06.prod.outlook.com (2603:10b6:a03:236::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.20; Mon, 18 May 2020 16:43:18 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5%5]) with mapi id 15.20.3000.022; Mon, 18 May 2020 16:43:18 +0000 From: Joseph Lorenzo Hall To: Christopher Wood CC: "pearg@irtf.org" Thread-Topic: [Pearg] draft-irtf-pearg-censorship review Thread-Index: AQHWD6u84dP2BqvmUU+akQqO5soH/ah1z/vmgByW2YCAG+CwgA== Date: Mon, 18 May 2020 16:43:17 +0000 Message-ID: References: <317d061c-1fdd-4c95-a24b-b9cc56fececf@www.fastmail.com> In-Reply-To: <317d061c-1fdd-4c95-a24b-b9cc56fececf@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) authentication-results: heapingbits.net; dkim=none (message not signed) header.d=none;heapingbits.net; dmarc=none action=none header.from=isoc.org; x-originating-ip: [108.28.51.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb8245ff-cfef-4709-323b-08d7fb4a9159 x-ms-traffictypediagnostic: BY5PR06MB6596: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 04073E895A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: h82OiIq/8NI3PcFpSWlgA6OVTCOii80AaghUBc44FmexucHDmhmisQQiW/Ksz9uMQKlM9bDVrHxET8HMh1KoOfKi66BqPTCyDGQmbEryjD2xXuR3uibbWnF9Y6sQ/dqEiv3XxlNmWDg8C8W27EQA6RPMPtQFRRjcyaQqYiYwUFFhxqotT0gVeP1/stkYGntGKsibPho1ZdYJfbi/OctaJ+XX8PxapzH9+WgUlHnnTm/yzGXZ/APZYexDDmO5opxbzlExbF87kwEqZkBz/5NQce4FYR7ylVdXRQzdet7ukiy4Rk+XDRS9zcsWYUT81K9xFJ334Gtro5LABW6i8FJlEIZvN9wQMvkni8uGYiFuVyG4xhRpJ9POR3jB2l14DBu9zk2CUptMAyN4s2wEdeGDwmNAHO4jy930JOCddtBZHY3fZal8bECqarcHUynSdmVrpTmdTeKtmpkLMClY8kxPpdiWZKJxJLqW15UL9FPceAPqsxq5Y5vPBUotDAc/qHsmxaR1xq6436QigyxHn+PJsw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(346002)(39840400004)(396003)(136003)(366004)(5660300002)(4326008)(86362001)(166002)(66574014)(186003)(6916009)(6486002)(316002)(8936002)(26005)(8676002)(6512007)(6506007)(53546011)(36756003)(2616005)(71200400001)(966005)(2906002)(478600001)(64756008)(66446008)(33656002)(76116006)(66946007)(91956017)(66476007)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: VNx3AAYFAxYYzv/k3KtqW4vrK+LvJOjarYHl9rDgtdl5ZC4OEZ7T/5fFWjCJbgznhyDXSDMPZ4rVWaosKNb5EHaaaFPv7GsC+0VJYTfOKh0/Nem5ji9SqD6kcPUekMFYUhoDv8yEG2d/4TnQfwwWAB+u2U8hLEU8SJzkoAokwwA8PlU2pEcbMuUQT0yBdm/XjkB/057fx83zdY69Yfer++SdhvqNEiJ2dI4fN4fKifDG4Yrn3/lZ2oBSSv96Kcrhx8ZqGoSEuzj0Veyllnn8BVUfAvHdja63XjDBDOtHG72WW9/h/ggsJnPeIfqPqlnFC5PndGNo887czxCrfCdULpFMy2RUaKbMi959+sKfakfTfsEVwFQHQz2VppIEh0IBYQE2P8cV4eTHGHbzaEBttGcGM3UcVmq00n5fTCEtVs6W+iq+e/wkR6nJc0WwXdY3WMw8q+FXip78zDbljE93JcpxldX8jCGYqYrflhuBbDI= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_C8A4EE3C34F44F93BA148F7920BA7F31isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: eb8245ff-cfef-4709-323b-08d7fb4a9159 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2020 16:43:17.9932 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GzIRqyy/1Tm0FD+IoP/uRgUNEiafCNliDhTUMpy186M7NgvBbOP78F6MgsIFb65z X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6596 Archived-At: Subject: Re: [Pearg] draft-irtf-pearg-censorship review X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 16:43:22 -0000 --_000_C8A4EE3C34F44F93BA148F7920BA7F31isocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBDaHJpcyEg4oCmIG9uZSBsYXN0IHRoaW5nIGFuZCBJ4oCZbGwgcGVlbCBvZmYgYSBu ZXcgdmVyc2lvbiBzaG9ydGx5Og0KDQpPbiBBcHIgMzAsIDIwMjAsIGF0IDc6MDAgUE0sIENocmlz dG9waGVyIFdvb2QgPGNhd0BoZWFwaW5nYml0cy5uZXQ8bWFpbHRvOmNhd0BoZWFwaW5nYml0cy5u ZXQ+PiB3cm90ZToNCg0KKiBTZWN0aW9uIDQuMi4zOiBJdCdzIHByb2JhYmx5IHdvcnRoIG1lbnRp b25pbmcgUVVJQyBoZXJlLCBlc3BlY2lhbGx5IGFzIGl0IGNvbXBsaWNhdGVzIHRoaXMgdHlwZSBv ZiBhdHRhY2suIEl0IG1pZ2h0IGFsc28gYmUgd29ydGggY2l0aW5nIHJlY2VudCByZXNlYXJjaCBb M10gb24gb2ZmLXBhdGggVENQIGF0dGFja3MsIG5vdGluZyB0aGF0IHRoZSBjZW5zb3IgbmVlZCBu b3QgYmUgb24tcGF0aCB0byBpbnRlcmZlcmUgd2l0aCBzZXJ2aWNlLg0KDQooVGhhdCBvZmYtcGF0 aCBwYXBlciBpcyBhd2Vzb21lISBIYWQgbm90IHNlZW4gdGhhdC4pDQoNCkNvb2wsIHRoYXQgbWFr ZXMgc2Vuc2UgYWJvdXQgUVVJQy4gSSBkb24ndCBoYXZlIGEgZ29vZCBmZWVsIGZvciB3aGF0IHRv DQp3cml0ZSBoZXJlLiBIb3cgZG9lcyB0aGlzIGZlZWwsICJOb3RlLCB0aGUgaW5jcmVhc2luZ2x5 IHBvcHVsYXIgUVVJQw0KcHJvdG9jb2wgaXMgYmFzZWQgb24gVURQLCBhIGNvbm5lY3Rpb24tbGVz cyB0cmFuc3BvcnQgcHJvdG9jb2wsIHNvDQpjYW5ub3QgYmUgYXR0YWNrZWQgdXNpbmcgVENQIFJT VCBwYWNrZXQgaW5qZWN0aW9uLiINCg0KVGhhdCBzZWVtcyBhIGJpdCB3ZWlyZC4uLiBidXQgaXQg c291bmRzIGxpa2UgdGhlcmUgbWF5IGJlIG1vcmUgdW5kZXINCnRoZSBzdXJmYWNlIHRvIHlvdXIg Y29tbWVudCBzbyBwbGVhc2Ugc3VnZ2VzdCBob3cgdGhhdCB0ZXh0IGFib3ZlIGNvdWxkDQpiZSBi ZXR0ZXIgY2xlYW5lZCB1cD8NCg0KSSdkIHByb2JhYmx5IGp1c3Qgc2F5IHNvbWV0aGluZyBsaWtl LCAiUVVJQyBpcyBub3QgdnVsbmVyYWJsZSB0byB0aGVzZSB0eXBlcyBvZiBpbmplY3Rpb24gYXR0 YWNrcy4gU2VlIHt7cXVpYy1kcmFmdH19IGZvciBtb3JlIGRldGFpbHMuIg0KDQoNCkRvbmUuDQoN Cg0KKiBTZWN0aW9uIDMuMi4xOiBUaGUgW1ZlcmthbXAtMjAxMl0gcmVmZXJlbmNlIHNlZW1zIGJy b2tlbi4NCg0KSG1tbSwgSSBkb24ndCBzZWUgdGhpcy4gVGhlIGxpbmsgd29ya3MgKA0KaHR0cHM6 Ly93d3cudXNlbml4Lm9yZy9zeXN0ZW0vZmlsZXMvY29uZmVyZW5jZS9mb2NpMTIvZm9jaTEyLWZp bmFsMS5wZGYNCikgYW5kIHRoZSByZWZlcmVuY2UgaXMgcmVuZGVyaW5nIGNvcnJlY3RseS4NCg0K T2gsIHNvcnJ5LCB0aGUgbGluayBpcyB3b3JraW5nLCBpdCdzIHRoZSByZWZlcmVuY2UgaW4gdGhl IGRvY3VtZW50ICh0aGUgZm9yd2FyZCBwb2ludGVyIHRvIHRoZSByZWZlcmVuY2VzIHNlY3Rpb24p IHRoYXQncyBicm9rZW4gKG5vdCBjbGlja2FibGUpOg0KDQogIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pcnRmLXBlYXJnLWNlbnNvcnNoaXAtMDIjc2VjdGlvbi0zLjIuMQ0KDQpJ IGNhbuKAmXQgcmVwcm9kdWNlIHRoaXMgbG9jYWxseS4gVGhlIEhUTUwgb3V0cHV0IG9uIG15IHNp ZGUgaGFzIHRoZSBjb3JyZWN0IGFuY2hvciwgZXRjLiBJ4oCZbGwgdXBsb2FkIGEgbmV3IHZlcnNp b24gdG8gdGhlIGRhdGF0cmFja2VyIGFuZCBzZWUgaWYgdGhhdCBmaXhlcyBpdOKApiBpZiBub3Qs IEnigJlsbCBkaWcgZGVlcGVyIGFuZCBzZWUgaWYgaXTigJlzIE1U4oCZcyBtYXJrZG93biB0b29s IG9yIGRhdGF0cmFja2VyLCBldGMuDQoNCmJlc3QsIEpvZQ0KDQotLQ0KSm9zZXBoIExvcmVuem8g SGFsbCwgU2VuaW9yIFZpY2UgUHJlc2lkZW50LCBTdHJvbmcgSW50ZXJuZXQNCmhhbGxAaXNvYy5v cmc8bWFpbHRvOmhhbGxAaXNvYy5vcmc+IHwgKzEtNzAzLTQ4My05NTA0DQppbnRlcm5ldHNvY2ll dHkub3JnPGh0dHA6Ly9pbnRlcm5ldHNvY2lldHkub3JnPiB8IEBpbnRlcm5ldHNvY2lldHkNCnBn cDogaHR0cHM6Ly9qb3NlcGhoYWxsLm9yZy9ncGcta2V5DQozQ0EyOEQ3QjlGNkREQkQzNEIxMDE2 MDc1Rjg2Njk4NzQwQTlBODcxDQoNCg== --_000_C8A4EE3C34F44F93BA148F7920BA7F31isocorg_ Content-Type: text/html; charset="utf-8" Content-ID: <05D8564773A3F045BA3AA7AE0AA10262@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoYW5rcywgQ2hyaXMhIOKApiBvbmUgbGFzdCB0 aGluZyBhbmQgSeKAmWxsIHBlZWwgb2ZmIGEgbmV3IHZlcnNpb24gc2hvcnRseTo8YnIgY2xhc3M9 IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIgMzAsIDIwMjAsIGF0IDc6MDAgUE0sIENocmlzdG9waGVy IFdvb2QgJmx0OzxhIGhyZWY9Im1haWx0bzpjYXdAaGVhcGluZ2JpdHMubmV0IiBjbGFzcz0iIj5j YXdAaGVhcGluZ2JpdHMubmV0PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IE1lbmxvLVJl Z3VsYXI7IGZvbnQtc2l6ZTogMTZweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBm b250LXNpemU6IDE2cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPiogU2VjdGlvbiA0LjIuMzogSXQncyBwcm9iYWJseSB3b3J0aCBtZW50aW9uaW5nIFFVSUMg aGVyZSwgZXNwZWNpYWxseSBhcyBpdCBjb21wbGljYXRlcyB0aGlzIHR5cGUgb2YgYXR0YWNrLiBJ dCBtaWdodCBhbHNvIGJlIHdvcnRoIGNpdGluZyByZWNlbnQgcmVzZWFyY2ggWzNdIG9uIG9mZi1w YXRoIFRDUCBhdHRhY2tzLCBub3RpbmcgdGhhdCB0aGUgY2Vuc29yIG5lZWQgbm90IGJlIG9uLXBh dGgNCiB0byBpbnRlcmZlcmUgd2l0aCBzZXJ2aWNlLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCihUaGF0IG9mZi1wYXRoIHBhcGVyIGlz IGF3ZXNvbWUhIEhhZCBub3Qgc2VlbiB0aGF0Lik8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpDb29sLCB0aGF0IG1ha2VzIHNlbnNlIGFib3V0IFFVSUMuIEkgZG9uJ3QgaGF2ZSBhIGdvb2Qg ZmVlbCBmb3Igd2hhdCB0bzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQp3cml0ZSBoZXJlLiBIb3cgZG9lcyB0aGlzIGZlZWwsICZx dW90O05vdGUsIHRoZSBpbmNyZWFzaW5nbHkgcG9wdWxhciBRVUlDPHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCnByb3RvY29sIGlz IGJhc2VkIG9uIFVEUCwgYSBjb25uZWN0aW9uLWxlc3MgdHJhbnNwb3J0IHByb3RvY29sLCBzbzxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9 IiI+DQpjYW5ub3QgYmUgYXR0YWNrZWQgdXNpbmcgVENQIFJTVCBwYWNrZXQgaW5qZWN0aW9uLiZx dW90OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoYXQgc2VlbXMgYSBiaXQgd2VpcmQu Li4gYnV0IGl0IHNvdW5kcyBsaWtlIHRoZXJlIG1heSBiZSBtb3JlIHVuZGVyPHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCnRoZSBz dXJmYWNlIHRvIHlvdXIgY29tbWVudCBzbyBwbGVhc2Ugc3VnZ2VzdCBob3cgdGhhdCB0ZXh0IGFi b3ZlIGNvdWxkPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxiciBjbGFzcz0iIj4NCmJlIGJldHRlciBjbGVhbmVkIHVwPzxiciBjbGFzcz0iIj4NCjwvYmxv Y2txdW90ZT4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTZweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDE2cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZs b2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkknZA0KIHBy b2JhYmx5IGp1c3Qgc2F5IHNvbWV0aGluZyBsaWtlLCAmcXVvdDtRVUlDIGlzIG5vdCB2dWxuZXJh YmxlIHRvIHRoZXNlIHR5cGVzIG9mIGluamVjdGlvbiBhdHRhY2tzLiBTZWUge3txdWljLWRyYWZ0 fX0gZm9yIG1vcmUgZGV0YWlscy4mcXVvdDs8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogTWVubG8tUmVndWxhcjsgZm9udC1zaXplOiAxNnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDE2cHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+RG9uZS48L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogTWVu bG8tUmVndWxhcjsgZm9udC1zaXplOiAxNnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj48L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IE1lbmxvLVJl Z3VsYXI7IGZvbnQtc2l6ZTogMTZweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+KiBTZWN0aW9uIDMuMi4xOiBUaGUgW1ZlcmthbXAtMjAxMl0gcmVmZXJlbmNl IHNlZW1zIGJyb2tlbi48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YnIgY2xhc3M9IiI+DQpIbW1tLCBJIGRvbid0IHNlZSB0aGlzLiBUaGUgbGluayB3b3JrcyAo PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFz cz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LnVzZW5peC5vcmcvc3lzdGVtL2ZpbGVzL2NvbmZl cmVuY2UvZm9jaTEyL2ZvY2kxMi1maW5hbDEucGRmIiBjbGFzcz0iIj5odHRwczovL3d3dy51c2Vu aXgub3JnL3N5c3RlbS9maWxlcy9jb25mZXJlbmNlL2ZvY2kxMi9mb2NpMTItZmluYWwxLnBkZjwv YT48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNs YXNzPSIiPg0KKSBhbmQgdGhlIHJlZmVyZW5jZSBpcyByZW5kZXJpbmcgY29ycmVjdGx5LjxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+ DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDE2cHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogTWVubG8tUmVndWxhcjsgZm9udC1zaXplOiAxNnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5P aCwNCiBzb3JyeSwgdGhlIGxpbmsgaXMgd29ya2luZywgaXQncyB0aGUgcmVmZXJlbmNlIGluIHRo ZSBkb2N1bWVudCAodGhlIGZvcndhcmQgcG9pbnRlciB0byB0aGUgcmVmZXJlbmNlcyBzZWN0aW9u KSB0aGF0J3MgYnJva2VuIChub3QgY2xpY2thYmxlKTo8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogTWVubG8tUmVndWxhcjsgZm9udC1zaXpl OiAxNnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6 IDE2cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogTWVubG8tUmVndWxhcjsgZm9udC1zaXpl OiAxNnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlydGYtcGVhcmctY2Vuc29yc2hpcC0wMiNzZWN0aW9u LTMuMi4xIiBzdHlsZT0iZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTZw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlydGYtcGVhcmct Y2Vuc29yc2hpcC0wMiNzZWN0aW9uLTMuMi4xPC9hPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTZweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkg Y2Fu4oCZdCByZXByb2R1Y2UgdGhpcyBsb2NhbGx5LiBUaGUgSFRNTCBvdXRwdXQgb24gbXkgc2lk ZSBoYXMgdGhlIGNvcnJlY3QgYW5jaG9yLCBldGMuIEnigJlsbCB1cGxvYWQgYSBuZXcgdmVyc2lv biB0byB0aGUgZGF0YXRyYWNrZXIgYW5kIHNlZSBpZiB0aGF0IGZpeGVzIGl04oCmIGlmIG5vdCwg SeKAmWxsIGRpZyBkZWVwZXIgYW5kIHNlZSBpZiBpdOKAmXMgTVTigJlzIG1hcmtkb3duIHRvb2wg b3IgZGF0YXRyYWNrZXIsIGV0Yy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmJlc3QsIEpvZTwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBk aXI9ImF1dG8iIHN0eWxlPSJ0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgd29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9InRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBk aXI9ImF1dG8iIHN0eWxlPSJ0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgd29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2Pi0tJm5ic3A7PGJyIGNsYXNzPSIi Pg0KSm9zZXBoIExvcmVuem8gSGFsbCwmbmJzcDtTZW5pb3IgVmljZSBQcmVzaWRlbnQsJm5ic3A7 U3Ryb25nIEludGVybmV0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOmhhbGxAaXNvYy5v cmciIGNsYXNzPSIiPmhhbGxAaXNvYy5vcmc8L2E+IHwgJiM0MzsxLTcwMy00ODMtOTUwNDxiciBj bGFzcz0iIj4NCjxhIGhyZWY9Imh0dHA6Ly9pbnRlcm5ldHNvY2lldHkub3JnIiBjbGFzcz0iIj5p bnRlcm5ldHNvY2lldHkub3JnPC9hPiB8Jm5ic3A7QGludGVybmV0c29jaWV0eTxiciBjbGFzcz0i Ij4NCnBncDombmJzcDs8YSBocmVmPSJodHRwczovL2pvc2VwaGhhbGwub3JnL2dwZy1rZXkiIGNs YXNzPSIiPmh0dHBzOi8vam9zZXBoaGFsbC5vcmcvZ3BnLWtleTwvYT48YnIgY2xhc3M9IiI+DQoz Q0EyOEQ3QjlGNkREQkQzNEIxMDE2MDc1Rjg2Njk4NzQwQTlBODcxPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_C8A4EE3C34F44F93BA148F7920BA7F31isocorg_-- From nobody Mon May 18 09:48:01 2020 Return-Path: X-Original-To: pearg@irtf.org Delivered-To: pearg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A10D83A089C; Mon, 18 May 2020 09:47:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pearg@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pearg@irtf.org Message-ID: <158982047856.2483.208828851774778869@ietfa.amsl.com> Date: Mon, 18 May 2020 09:47:58 -0700 Archived-At: Subject: [Pearg] I-D Action: draft-irtf-pearg-censorship-03.txt X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 16:47:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhancements and Assessments Research Group RG of the IRTF. Title : A Survey of Worldwide Censorship Techniques Authors : Joseph Lorenzo Hall Michael D. Aaron Stan Adams Amelia Andersdotter Ben Jones Nick Feamster Filename : draft-irtf-pearg-censorship-03.txt Pages : 36 Date : 2020-05-18 Abstract: This document describes technical mechanisms censorship regimes around the world use for blocking or impairing Internet traffic. It aims to make designers, implementers, and users of Internet protocols aware of the properties exploited and mechanisms used for censoring end-user access to information. This document makes no suggestions on individual protocol considerations, and is purely informational, intended as a reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-pearg-censorship/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-irtf-pearg-censorship-03 https://datatracker.ietf.org/doc/html/draft-irtf-pearg-censorship-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-irtf-pearg-censorship-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 18 09:52:14 2020 Return-Path: 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 0790E3A08A9 for ; Mon, 18 May 2020 09:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 ODftR3G0dMIJ for ; Mon, 18 May 2020 09:52:07 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2089.outbound.protection.outlook.com [40.107.94.89]) (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 D179C3A08CF for ; Mon, 18 May 2020 09:52:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WzWk/3WMQNL1fZqcPD/WQ7icVOAjFVr96p1IwNIpsuUO11hl/HIVI2rDUQy3s+3P7qVYVuz7tUamXysF8UCmpJCMjrgNYYWXGy3iZ4uj88KNKYz5ABZMC4RaBWakrEzL56aOAt4M0Djn6FfkRsMFtdnWixLB7oftB4NvO17mrd+nsD6IPEPhuJxZudd6+JnyOv4UYM0K4G4zQR4YhWwXkHLuRl+/8MdlpOi2VD/XOXyhPKdli87XgAln4FjqknWh9psItzktVcTvhwd9dKb+DEF6OTltCAsxe1BqtIXpRgXTsYanVYasuA6wfq/V636BUBvgDiQw88CaPHqOnVi3OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+HAEudE7rs3cu3od221TeCxtnUj3ospuEbM1JheR/qc=; b=kGFo7gGW8L7uuQKvO+LY2kHR5QZAXumWaOgYrhShE0LozsBGQYn3ZmAX7I+/oWum/HNdekbzHnVrVYp2l5zkcml6jDCmtthk64WGV+g/xeNIMI7yQLJ+3Zn0EVOczdjtUxxTKrO0MWqSyTetVF+frSdHtQoC1slvcAMypDZWp1UfQ0+FcPuY1uCK2JEmlZzQiCrniewcawd7/aczayTd2RKrm7mIAyP4h58jcpP9489DgXaUftBhAdQhKTdzOPWpRyO1blTIEAek+xsfrkc5MECwKDNLXJDfy6vLDUh6LqFW4yD2IGzUO5dxoG79UgrjAblWUyzE5RA7+a47eSHN2g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+HAEudE7rs3cu3od221TeCxtnUj3ospuEbM1JheR/qc=; b=DxIDnG/7cU/dI9zOTP2jlMj4VTcCeKnfaxT9zhT6jaAavmcoedOD1Hj+G36gzUiEln8rYT/k/RPGEfja/3j951Njyo6UgvrowB4oPjD+GR71xUWTEN4mttrBFC8lOoAygtWX2dca4C4JrXZ9ctSncv6RyeYDwRHHl+v7aXslw+E= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BY5PR06MB6530.namprd06.prod.outlook.com (2603:10b6:a03:232::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.24; Mon, 18 May 2020 16:52:00 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5%5]) with mapi id 15.20.3000.022; Mon, 18 May 2020 16:52:00 +0000 From: Joseph Lorenzo Hall To: Christopher Wood CC: "pearg@irtf.org" Thread-Topic: [Pearg] draft-irtf-pearg-censorship review Thread-Index: AQHWD6u84dP2BqvmUU+akQqO5soH/ah1z/vmgByW2YCAG+CwgIAAAnAA Date: Mon, 18 May 2020 16:52:00 +0000 Message-ID: <896201CB-8BDE-4B3C-A525-7B4F61CAB300@isoc.org> References: <317d061c-1fdd-4c95-a24b-b9cc56fececf@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) authentication-results: heapingbits.net; dkim=none (message not signed) header.d=none;heapingbits.net; dmarc=none action=none header.from=isoc.org; x-originating-ip: [108.28.51.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 43b1c0c6-b18a-43d5-567b-08d7fb4bc8f9 x-ms-traffictypediagnostic: BY5PR06MB6530: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 04073E895A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nW0m7khTqxw+ANrEJp6uxWAEQbP7ewRFjrF2QiICWwB0Pm5T6VNvObO4VDtr0xlD5dqxXfgb689TnlhhKjPFF2FbYXKrbyAXL9NUFOC0eKWqh+yFRR2ZqEXk5xLx0+6B9EoRZ2t/QMZipkkAlbRFM5whxUEraYw5o+5KZXP2VZr7W4uzkhF002qEmJaXk0YDjkPJE6QTnBZN84u2wnfoVgBcDG3UqL6FmOAt9SRIammolrbMeqidepXRZwnHrot0GlnQv5nCFnPNZ8ZmGEd217euc9Kl6/+mvXGHh5ncFNn2Q9BquEKwcALBgRmcIXQrQkb8I+bPEvYR7or06CJJRZLgN343GgqrDStYd3YbrSynH8XvfI/cDjrfMLo23sFX4Hw7l9fE0a3nXhUrS7xGrj3nZJmRIsaYkvkvwKRpDVvAc3nFODyCIjYgjYmrUTf2OJidcOa4EVq8nrstTyN8Ba3sUa9RFWI7zaOwNUTIIK6fWVarxNnY07o037newQUNaT8DLvo5T+/bQfGoTgdNng== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(39840400004)(346002)(136003)(376002)(366004)(396003)(66574014)(26005)(166002)(36756003)(33656002)(316002)(71200400001)(966005)(478600001)(2906002)(86362001)(2616005)(6916009)(8936002)(186003)(4326008)(6486002)(66476007)(6512007)(64756008)(8676002)(66946007)(53546011)(6506007)(66446008)(76116006)(66556008)(5660300002)(91956017); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 9eKGqMHHHLE8hyOHkeiUbXVBkZwEYjw96lsCg+Je68KqRc7ZgvA1xqFgVFTyDljA2M0m/F0oinCQgXPfG2psKnqt++L99Xv0J9Cw80QVUNK/Abb3mS3MsqGRHjKs5NyyZ6opbcrOPD6OFcUdiF/QmJUb186T6PS25tHjL6a6iYBxzUVgmc5tupDL70gDW6VssGo0q1fV26Olv5cgDFYpbBo7W0/67pBHm17NJ+9yh+7mnaAaBnX3pPDse6ioqPCE4n2OOTC1hkp5lcGrAv93RhCZ/d+u8AGw/7eujaP5vU8KfXxBztxQ2IfXfbnxN0GPBzyGQl3vojevt0GWEchnq6MFVi9Vj7/wW/u++64XmdgJnjrtotXuhF8I5Pr+OQVeOZ1QAhPBFr/+WFUjkuaaJSvN6QMXJIz7NTdNiQZncXl34CiTE+52E5/rjdrZJmiydrc5G9DdIYWbBE42hGQYLG/3bFpFvnlId9eAogUoXgc= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_896201CB8BDE4B3CA5257B4F61CAB300isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 43b1c0c6-b18a-43d5-567b-08d7fb4bc8f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2020 16:52:00.8350 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: prKD8wen2mB0Hpu++KLlKiLkii3CpZXLZYHd+UXKWIl5gYXtfzeCENc76tOoHCtR X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6530 Archived-At: Subject: Re: [Pearg] draft-irtf-pearg-censorship review X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 16:52:12 -0000 --_000_896201CB8BDE4B3CA5257B4F61CAB300isocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIE1heSAxOCwgMjAyMCwgYXQgMTI6NDMgUE0sIEpvc2VwaCBMb3JlbnpvIEhhbGwgPGhh bGxAaXNvYy5vcmc8bWFpbHRvOmhhbGxAaXNvYy5vcmc+PiB3cm90ZToNCiogU2VjdGlvbiAzLjIu MTogVGhlIFtWZXJrYW1wLTIwMTJdIHJlZmVyZW5jZSBzZWVtcyBicm9rZW4uDQoNCkhtbW0sIEkg ZG9uJ3Qgc2VlIHRoaXMuIFRoZSBsaW5rIHdvcmtzICgNCmh0dHBzOi8vd3d3LnVzZW5peC5vcmcv c3lzdGVtL2ZpbGVzL2NvbmZlcmVuY2UvZm9jaTEyL2ZvY2kxMi1maW5hbDEucGRmDQopIGFuZCB0 aGUgcmVmZXJlbmNlIGlzIHJlbmRlcmluZyBjb3JyZWN0bHkuDQoNCk9oLCBzb3JyeSwgdGhlIGxp bmsgaXMgd29ya2luZywgaXQncyB0aGUgcmVmZXJlbmNlIGluIHRoZSBkb2N1bWVudCAodGhlIGZv cndhcmQgcG9pbnRlciB0byB0aGUgcmVmZXJlbmNlcyBzZWN0aW9uKSB0aGF0J3MgYnJva2VuIChu b3QgY2xpY2thYmxlKToNCg0KICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaXJ0 Zi1wZWFyZy1jZW5zb3JzaGlwLTAyI3NlY3Rpb24tMy4yLjENCg0KSSBjYW7igJl0IHJlcHJvZHVj ZSB0aGlzIGxvY2FsbHkuIFRoZSBIVE1MIG91dHB1dCBvbiBteSBzaWRlIGhhcyB0aGUgY29ycmVj dCBhbmNob3IsIGV0Yy4gSeKAmWxsIHVwbG9hZCBhIG5ldyB2ZXJzaW9uIHRvIHRoZSBkYXRhdHJh Y2tlciBhbmQgc2VlIGlmIHRoYXQgZml4ZXMgaXTigKYgaWYgbm90LCBJ4oCZbGwgZGlnIGRlZXBl ciBhbmQgc2VlIGlmIGl04oCZcyBNVOKAmXMgbWFya2Rvd24gdG9vbCBvciBkYXRhdHJhY2tlciwg ZXRjLg0KDQpPaywgd2hhdGV2ZXIgd2FzIGRvaW5nIHRoaXMgaXMgbm8gbG9uZ2VyIGRvaW5nIHRo aXMuIFRoZSBWZXJrYW1wIGNpdGUgaXMgbm93IGNsaWNrYWJsZSBpbiBib3RoIHRoZSBkYXRhdHJh Y2tlciBhbmQgdG9vbHMgSFRNTCB2ZXJzaW9uczoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1pcnRmLXBlYXJnLWNlbnNvcnNoaXAtMDMjc2VjdGlvbi0zLjIu MQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlydGYtcGVhcmctY2Vuc29yc2hp cC0wMyNzZWN0aW9uLTMuMi4xDQoNCmJlc3QsIEpvZQ0KDQotLQ0KSm9zZXBoIExvcmVuem8gSGFs bCwgU2VuaW9yIFZpY2UgUHJlc2lkZW50LCBTdHJvbmcgSW50ZXJuZXQNCmhhbGxAaXNvYy5vcmc8 bWFpbHRvOmhhbGxAaXNvYy5vcmc+IHwgKzEtNzAzLTQ4My05NTA0DQppbnRlcm5ldHNvY2lldHku b3JnPGh0dHA6Ly9pbnRlcm5ldHNvY2lldHkub3JnPiB8IEBpbnRlcm5ldHNvY2lldHkNCnBncDog aHR0cHM6Ly9qb3NlcGhoYWxsLm9yZy9ncGcta2V5DQozQ0EyOEQ3QjlGNkREQkQzNEIxMDE2MDc1 Rjg2Njk4NzQwQTlBODcxDQoNCg== --_000_896201CB8BDE4B3CA5257B4F61CAB300isocorg_ Content-Type: text/html; charset="utf-8" Content-ID: <6B71C934A08C2D44860E320437C300B8@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IE1heSAxOCwgMjAyMCwgYXQgMTI6NDMgUE0sIEpvc2VwaCBMb3JlbnpvIEhhbGwgJmx0OzxhIGhy ZWY9Im1haWx0bzpoYWxsQGlzb2Mub3JnIiBjbGFzcz0iIj5oYWxsQGlzb2Mub3JnPC9hPiZndDsg d3JvdGU6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5 bGU9ImZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDE2cHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6 ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPiogU2VjdGlvbiAzLjIuMTogVGhl IFtWZXJrYW1wLTIwMTJdIHJlZmVyZW5jZSBzZWVtcyBicm9rZW4uPGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSG1tbSwgSSBkb24ndCBz ZWUgdGhpcy4gVGhlIGxpbmsgd29ya3MgKDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy51c2Vu aXgub3JnL3N5c3RlbS9maWxlcy9jb25mZXJlbmNlL2ZvY2kxMi9mb2NpMTItZmluYWwxLnBkZiIg Y2xhc3M9IiI+aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zeXN0ZW0vZmlsZXMvY29uZmVyZW5jZS9m b2NpMTIvZm9jaTEyLWZpbmFsMS5wZGY8L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCikgYW5kIHRoZSByZWZlcmVuY2UgaXMg cmVuZGVyaW5nIGNvcnJlY3RseS48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJjYXJl dC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogTWVubG8tUmVndWxhcjsgZm9udC1z aXplOiAxNnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IE1lbmxvLVJlZ3VsYXI7IGZvbnQt c2l6ZTogMTZweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+T2gsDQogc29ycnksIHRoZSBsaW5rIGlzIHdvcmtpbmcs IGl0J3MgdGhlIHJlZmVyZW5jZSBpbiB0aGUgZG9jdW1lbnQgKHRoZSBmb3J3YXJkIHBvaW50ZXIg dG8gdGhlIHJlZmVyZW5jZXMgc2VjdGlvbikgdGhhdCdzIGJyb2tlbiAobm90IGNsaWNrYWJsZSk6 PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTZweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNz PSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog TWVubG8tUmVndWxhcjsgZm9udC1zaXplOiAxNnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IE1lbmxvLVJlZ3VsYXI7IGZvbnQtc2l6ZTogMTZweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6 IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pcnRmLXBl YXJnLWNlbnNvcnNoaXAtMDIjc2VjdGlvbi0zLjIuMSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBNZW5s by1SZWd1bGFyOyBmb250LXNpemU6IDE2cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pcnRmLXBlYXJnLWNlbnNvcnNoaXAtMDIjc2VjdGlvbi0zLjIuMTwvYT48 YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBNZW5sby1S ZWd1bGFyOyBmb250LXNpemU6IDE2cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGNhbuKAmXQgcmVwcm9kdWNlIHRoaXMgbG9jYWxseS4g VGhlIEhUTUwgb3V0cHV0IG9uIG15IHNpZGUgaGFzIHRoZSBjb3JyZWN0IGFuY2hvciwgZXRjLiBJ 4oCZbGwgdXBsb2FkIGEgbmV3IHZlcnNpb24gdG8gdGhlIGRhdGF0cmFja2VyIGFuZCBzZWUgaWYg dGhhdCBmaXhlcyBpdOKApiBpZiBub3QsIEnigJlsbCBkaWcgZGVlcGVyIGFuZCBzZWUgaWYgaXTi gJlzIE1U4oCZcyBtYXJrZG93biB0b29sIG9yIGRhdGF0cmFja2VyLCBldGMuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+T2ssIHdoYXRldmVyIHdhcyBkb2luZyB0 aGlzIGlzIG5vIGxvbmdlciBkb2luZyB0aGlzLiBUaGUgVmVya2FtcCBjaXRlIGlzIG5vdyBjbGlj a2FibGUgaW4gYm90aCB0aGUgZGF0YXRyYWNrZXIgYW5kIHRvb2xzIEhUTUwgdmVyc2lvbnM6PC9k aXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlydGYtcGVhcmctY2Vuc29yc2hpcC0w MyNzZWN0aW9uLTMuMi4xIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LWlydGYtcGVhcmctY2Vuc29yc2hpcC0wMyNzZWN0aW9uLTMuMi4xPC9hPjwv ZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaXJ0 Zi1wZWFyZy1jZW5zb3JzaGlwLTAzI3NlY3Rpb24tMy4yLjEiIGNsYXNzPSIiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pcnRmLXBlYXJnLWNlbnNvcnNoaXAtMDMjc2VjdGlvbi0z LjIuMTwvYT48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PmJlc3QsIEpv ZTwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBz dHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHdvcmQtd3JhcDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJ0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i c3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+ DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBz dHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHdvcmQtd3JhcDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJ0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i c3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+ DQo8ZGl2Pi0tJm5ic3A7PGJyIGNsYXNzPSIiPg0KSm9zZXBoIExvcmVuem8gSGFsbCwmbmJzcDtT ZW5pb3IgVmljZSBQcmVzaWRlbnQsJm5ic3A7U3Ryb25nIEludGVybmV0PGJyIGNsYXNzPSIiPg0K PGEgaHJlZj0ibWFpbHRvOmhhbGxAaXNvYy5vcmciIGNsYXNzPSIiPmhhbGxAaXNvYy5vcmc8L2E+ IHwgJiM0MzsxLTcwMy00ODMtOTUwNDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHA6Ly9pbnRl cm5ldHNvY2lldHkub3JnIiBjbGFzcz0iIj5pbnRlcm5ldHNvY2lldHkub3JnPC9hPiB8Jm5ic3A7 QGludGVybmV0c29jaWV0eTxiciBjbGFzcz0iIj4NCnBncDombmJzcDs8YSBocmVmPSJodHRwczov L2pvc2VwaGhhbGwub3JnL2dwZy1rZXkiIGNsYXNzPSIiPmh0dHBzOi8vam9zZXBoaGFsbC5vcmcv Z3BnLWtleTwvYT48YnIgY2xhc3M9IiI+DQozQ0EyOEQ3QjlGNkREQkQzNEIxMDE2MDc1Rjg2Njk4 NzQwQTlBODcxPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_896201CB8BDE4B3CA5257B4F61CAB300isocorg_-- From nobody Tue May 19 20:05:00 2020 Return-Path: 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 63A593A094A for ; Tue, 19 May 2020 20:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=iWsohBdX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dxcwrzPF 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 2Owu_3jxMGqX for ; Tue, 19 May 2020 20:04:54 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2590F3A0949 for ; Tue, 19 May 2020 20:04:54 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1FD135C01FA for ; Tue, 19 May 2020 23:04:53 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Tue, 19 May 2020 23:04:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=cJm2Jvh/MhSyzqPYCosl2j9KD3RvrpX eltI1vWXKM8U=; b=iWsohBdX4fsnd6Bcy2rtzzoEW39+DpVg1T5loxhXKjcv0VJ zhI7DyRJKU3EIBKBqhOZuGI+bSKJChr+25qMJ9wrog9A2/PlN8KpyE8VEEaJ0KuI 1rO5lasaVj1D9BL/8bOpgKi1cep/iPQAt620SGh8mAt8bj1nNmwRMtz3GTSxO//W QGJoLKtjlXz77TqLkTvI/1LO5w4o6CjzjRVbWnjQI7cf+Ij6YZfeV23q74iqs3SL BGu/UGJTpVP8H4TDwD00qMrRWppzN47aGSf8QZxuoxFiJpUc8FXS6hbqf4p4QbPZ b6y+JFAIAJAX5yvyX8S2PhL7rUu0oBhDAEFJulA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=cJm2Jv h/MhSyzqPYCosl2j9KD3RvrpXeltI1vWXKM8U=; b=dxcwrzPFav1vIPtQZulUT7 vLacYzwzegtuVp8v2AGpYzUssRHpb2a4XhYgNfXG3zN1AtTrTlSZS+PG701ixoiK iDlKu2KOe0MqLmCunFl7rbokqvWJDTKawB8hxCe6Eo2/vaR8ltGd258/SAkQ33QD 20ykBqJjYkfKQ4DTY6iTmBZWPijpL96fPvdobKYv7D3NF2xAt7Gj28UJdqdRIz0S +jjNDmTc2OkzS5QMXqhZQ3/siyXbrsglAyxYepRaVLOW9G/tYeqQ7POvCLcs8wmn PHg98ZUMyQFH+TCoOuTGh0l7L6ff7+pgoUwqFGgWLoxf8dLKMrf+cu0w3uyQNQuA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtkedgieegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeefgffgjeeghe evieegtdekudetuedvueelvedtueelveehtedvvedvheefvdelveenucffohhmrghinhep ihgvthhfrdhorhhgpdhirhhtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B12D13C00A1; Tue, 19 May 2020 23:04:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-464-g810d66a-fmstable-20200518v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <158950494825.32676.4874273590052962910@ietfa.amsl.com> References: <158950494825.32676.4874273590052962910@ietfa.amsl.com> Date: Tue, 19 May 2020 20:04:17 -0700 From: "Christopher Wood" To: pearg@irtf.org Content-Type: text/plain Archived-At: Subject: Re: [Pearg] =?utf-8?q?I-D_Action=3A_draft-irtf-pearg-numeric-ids-gen?= =?utf-8?q?eration-02=2Etxt?= X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2020 03:04:58 -0000 I reviewed this document with no hats on. My feedback is below (I hope it's useful)! In general, this is a nicely written document with clear structure and guidance. I think there are some issues with the details, and perhaps a bit too much redundancy, but overall it's heading in the right direction. I especially like the appendix, which captures our lessons learned the hard way. Before progressing this draft further, is it possible to get feedback from folks in the transport area? We might also try and request an additional review from secdir, if they're willing. Best, Chris ~~~ Document: https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-generation-02 Summary: Has Issues Comments: - Section 1. I'd suggest rephrasing this text: Recent history indicates that when new protocols are standardized or new protocol implementations are produced, the security and privacy properties of the associated identifiers tend to be overlooked, and inappropriate algorithms to generate transient numeric identifiers are either suggested in the specification or selected by implementers. to something that emphasizes these problems in the past. Certainly, modern protocols such as QUIC paid very close attention to these details. - Section 2. The terminology is duplicated in the ids-history draft. Perhaps we can note this? - Section 3. Can the attacker generate traffic at will, or modify existing traffic? I would reference RFC3552 for the threat model here. (The same should probably go for the ids-history draft.) - Section 4. This seems largely redundant with the history draft, no? Can we remove this section entirely? - Section 7. I would drop either 7.1.1 or 7.1.2. We don't need two algorithms for generating random identifiers, do we? (7.1.2 seems simpler to reason about, given that it calls random during each loop iteration.) Can we also clarify the failure probability of this algorithm? - Section 7.3. Is "F() must be a cryptographically-secure hash function" correct? What we really want, I think, is for F to be a PRF keyed on "secret_key". RFC6528 uses a PRF here, for example (https://tools.ietf.org/html/rfc6528). Similar to the comment above, can we clarify the failure probability? - Section 7.3. The "check_suitable_id" function is described inline here, yet is referenced in prior sections. Can we lift the utility functions used in these algorithms to a prior section to simplify the text that goes along with each function? - Section 7.4.1. Code nit (inconsistent whitespace between comments and the next expression, and inconsistent spacing around braces /* Initialization code */ id_inc = 1; /* Numeric ID selection function */ //----> count = max_id - min_id + 1; ... if(lookup_counter(CONTEXT) == ERROR){ <--- insert spaces between "if" and "(", for example This should also apply to other code blocks, too. :-) - Section 7.4.1. id_inc seems like it should be a parameter, rather than baked into the algorithm. - Section 7.4.2. Again, I think we need a PRF here for F(). - Section 7.4.3. I would remove this section. Do any implementations use this particular algorithm? - Section 8/9. I wonder if these sections in their entirety should be moved to the ids-sec-considerations draft, if only because they help motivate the need for these considerations. (In contrast, I see this document focusing on the *mechanisms* by which these considerations can be addressed.) What do you think? On Thu, May 14, 2020, at 6:09 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Privacy Enhancements and Assessments > Research Group RG of the IRTF. > > Title : On the Generation of Transient Numeric Identifiers > Authors : Fernando Gont > Ivan Arce > Filename : draft-irtf-pearg-numeric-ids-generation-02.txt > Pages : 34 > Date : 2020-05-14 > > Abstract: > This document performs an analysis of the security and privacy > implications of different types of "numeric identifiers" used in IETF > protocols, and tries to categorize them based on their > interoperability requirements and the associated failure severity > when such requirements are not met. Subsequently, it provides advice > on possible algorithms that could be employed to satisfy the > interoperability requirements of each identifier category, while > minimizing the security and privacy implications, thus providing > guidance to protocol designers and protocol implementers. Finally, > this describes a number of algorithms that have been employed in real > implementations to generate transient numeric identifiers and > analyzes their security and privacy properties. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-irtf-pearg-numeric-ids-generation/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation-02 > https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-generation-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-irtf-pearg-numeric-ids-generation-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > From nobody Wed May 20 10:00:23 2020 Return-Path: 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 648D73A0A9A for ; Wed, 20 May 2020 10:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=OoAXQw+f; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XjjW8D1i 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 sf2F6jqfgPIq for ; Wed, 20 May 2020 10:00:20 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282EF3A09E9 for ; Wed, 20 May 2020 10:00:20 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id AB1FAEAF for ; Wed, 20 May 2020 13:00:19 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Wed, 20 May 2020 13:00:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=J9rQKnLU9Bq87GJMuRSu1jHypmw96htroqYVZ647aZs=; b=OoAXQw+f 8Y1uIS6USvgibIcuDMn9i0WCoHP+R0Fxzlq6rTgl/LGio6ZtQtW63MTcMyqxNQ+o DW/0iLr/gWzIZAANqEZfAA9h2bw3YyYC4x1X2A3h0mmm4wfd4gEdR9BvlBPWKsVb FKSX1DFKw+HdrFNUWPnr7M8JceR3V7E5Do69OWdVHjSwUFS+WRChZHJUztBuWIMB RmLJwqEdi/RVD8Sj1NyRFcQF7tk0p27vA2kP54F5uSw1L2/8og4xxsFbgPhloSDs A+Nh/zygrjl7KVhyfnBADQhZg6G38zv3fuZH+btNiJnI6NZoJd43CZFmJxkVl92e G0cHciRYgajN8g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=J9rQKnLU9Bq87GJMuRSu1jHypmw96 htroqYVZ647aZs=; b=XjjW8D1ienCtGIjCVCarXXs0MW+HL8IcmO2T0EU3j706V BVIx+f6Uvwj0kbVyas1xidHXVaBWUagoGi6w7FOg1+6O3cbovArIJe5zZj0CTzaE iTrylywlq2Rz3Y1pmqn0TN1KFfFfr6uQG5Ul2oN4310qxuAldt4Vb5KCmjIN6W7N BM0rrLQebhO16TTz34GSXi+M1FDUUKf1AXRnSz44MLguoSCTA+IcFqJ+E7r3KGkj SpgLykW9PGrR5GaN3Xgyod5DW4fl2aFKvOSa6YLavT8cNspTh6SPuvSkucBJ2W7d 7kWoROWdr/k2TwkPNZ705Qx77nDS9omwGmmTERScQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtledguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtre dtreerjeenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnhepffeghedvgeffhe ffleefffdtvdfgjeehkeejjeekgeefhfelueefgfdtudekleetnecuffhomhgrihhnpehi vghtfhdrohhrghdpghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B9C473C00A1; Wed, 20 May 2020 13:00:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-464-g810d66a-fmstable-20200518v1 Mime-Version: 1.0 Message-Id: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> Date: Wed, 20 May 2020 09:59:41 -0700 From: "Christopher Wood" To: pearg@irtf.org Content-Type: text/plain Archived-At: Subject: [Pearg] =?utf-8?q?Research_Group_Last_Call_for_=22A_Survey_of_Wo?= =?utf-8?q?rldwide_Censorship_Techniques=22?= X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2020 17:00:22 -0000 This is the research group last call for the "A Survey of Worldwide Censorship Techniques" (draft-irtf-pearg-censorship) draft available here: https://datatracker.ietf.org/doc/draft-irtf-pearg-censorship/ Please review the document and send your comments to the list by June 5, 2020. Feedback may also be sent to the GitHub repository located here: https://github.com/IRTF-PEARG/rfc-censorship-tech Thanks, Chris, on behalf of the chairs From nobody Fri May 22 03:13:24 2020 Return-Path: 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 514133A0A53 for ; Fri, 22 May 2020 03:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 hzlyWZNUQrSd for ; Fri, 22 May 2020 03:11:31 -0700 (PDT) Received: from tools.si6networks.com (v6toolkit.go6lab.si [IPv6:2001:67c:27e4::57]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C9B3A0A4F for ; Fri, 22 May 2020 03:11:30 -0700 (PDT) Received: from [IPv6:2800:810:464:11f:f597:cad2:df35:f6c5] (unknown [IPv6:2800:810:464:11f:f597:cad2:df35:f6c5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tools.si6networks.com (Postfix) with ESMTPSA id 5D4F03FFE8; Fri, 22 May 2020 12:11:26 +0200 (CEST) To: Christopher Wood , pearg@irtf.org References: <158950494825.32676.4874273590052962910@ietfa.amsl.com> From: Fernando Gont Message-ID: <9ce30cf2-0c89-95a5-89a9-23ee5e818a41@gont.com.ar> Date: Fri, 22 May 2020 07:10:58 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Pearg] I-D Action: draft-irtf-pearg-numeric-ids-generation-02.txt X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 10:11:36 -0000 Hello, Chris, Thanks a lot for your feedback! In-line..... On 20/5/20 00:04, Christopher Wood wrote: > I reviewed this document with no hats on. My feedback is below (I > hope it's useful)! > > In general, this is a nicely written document with clear structure > and guidance. I think there are some issues with the details, and > perhaps a bit too much redundancy, but overall it's heading in the > right direction. I especially like the appendix, which captures our > lessons learned the hard way. > > Before progressing this draft further, is it possible to get feedback > from folks in the transport area? We might also try and request an > additional review from secdir, if they're willing. Is there some sort of procedure/guideline for this? Should we authors e.g. request comments on the tsv-area list? Contact the ADs? Something else? > Document: > https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-generation-02 > > Summary: Has Issues > > Comments: > > - Section 1. I'd suggest rephrasing this text: > > Recent history indicates that when new protocols are standardized or > new protocol implementations are produced, the security and privacy > properties of the associated identifiers tend to be overlooked, and > inappropriate algorithms to generate transient numeric identifiers > are either suggested in the specification or selected by > implementers. > > to something that emphasizes these problems in the past. Certainly, > modern protocols such as QUIC paid very close attention to these > details. I haven't looked at QUIC myself yet -- hence I cannot speak for quic. But it would seem to me that the statement is generally true for both protocols and even more when it comes to implementations. For example, I just skimmed through Section "5.1. Connection ID" of "draft-ietf-quic-transport-28", and they don't seem to spell out the interoperability requirements of the connection IDs. -- I'd assume "uniqueness, hard failure", but I'm just guessing. This text also seems to fail to suggest a recommended algorithm: " Each endpoint selects connection IDs using an implementation-specific (and perhaps deployment-specific) method which will allow packets with that connection ID to be routed back to the endpoint and identified by the endpoint upon receipt." Thoughts? > - Section 2. The terminology is duplicated in the ids-history draft. > Perhaps we can note this? ids-history has removed everything by the definition of "transient numeric identifier". As such, maybe it's better to clarify this in the ids-history draft instead? i.e., add something (to the ids-history draft) like: "This document employs terminology defined in [draft-irtf-pearg-numeric-ids-generation], which is reproduced here for convenience:" Or, if you prefer, just eliminate all definitions from the ids-history draft, and say: "This document employs the term "transient numeric identifiers" as defined in [draft-irtf-pearg-numeric-ids-generation]" Any preference? > - Section 3. Can the attacker generate traffic at will, Yes. > or modify existing traffic? No -- although, thinking out loud, I'm not sure this would be relevant. (Should we clarify this?) > I would reference RFC3552 for the threat model > here. (The same should probably go for the ids-history draft.) Could you please elaborate? > - Section 4. This seems largely redundant with the history draft, no? > Can we remove this section entirely? Not really. Section 1 of ids-history essentially doesn't delve into e.g. why protocol specifications have led to vulnerable implementations. In a way, Section 4 of this document kind of explains what Section 1 provides as anecdotal evidence. > - Section 7. I would drop either 7.1.1 or 7.1.2. We don't need two > algorithms for generating random identifiers, do we? (7.1.2 seems > simpler to reason about, given that it calls random during each loop > iteration.) Can we also clarify the failure probability of this > algorithm? While presented as two different randomization algorithms, strictly speaking they are really two different ways of dealing with the collisions. In one case (I), success becomes ore deterministic, at the expense of decreased randomization. So maybe one might want to describe these two as such? > - Section 7.3. Is "F() must be a cryptographically-secure hash > function" correct? What we really want, I think, is for F to be a PRF > keyed on "secret_key". RFC6528 uses a PRF here, for example > (https://tools.ietf.org/html/rfc6528). I'm not a mathematician, but, what I seem to remember is that strictly speaking a hash function is one of the possible "implementations" of a PRF. So PRF would be a more correct (general) term, at the expense of a possible "What the heck is a PRF?" moment for the reader. :-) I will update this as suggested. > Similar to the comment above, can we clarify the failure probability? Failure as in probability of collisions, or what? > - Section 7.3. The "check_suitable_id" function is described inline > here, yet is referenced in prior sections. Can we lift the utility > functions used in these algorithms to a prior section to simplify the > text that goes along with each function? Maybe explain these in the Section 7 parent section? > > - Section 7.4.1. Code nit (inconsistent whitespace between comments > and the next expression, and inconsistent spacing around braces > > /* Initialization code */ id_inc = 1; > > /* Numeric ID selection function */ //----> count = max_id - min_id + > 1; > > ... > > if(lookup_counter(CONTEXT) == ERROR){ <--- insert spaces between "if" > and "(", for example > > This should also apply to other code blocks, too. :-) Will fix. Thanks! > - Section 7.4.1. id_inc seems like it should be a parameter, rather > than baked into the algorithm. Yep. Maybe move it and explain it to (parent) Section 7? > - Section 7.4.2. Again, I think we need a PRF here for F(). Will fix this. > - Section 7.4.3. I would remove this section. Do any implementations > use this particular algorithm? IIRC Microsoft uses it for their IP ID generator > - Section 8/9. I wonder if these sections in their entirety should be > moved to the ids-sec-considerations draft, if only because they help > motivate the need for these considerations. (In contrast, I see this > document focusing on the *mechanisms* by which these considerations > can be addressed.) What do you think? You raise a very good and valid point, indeed! These are my only two concerns: 1) We're still waiting for progress on ids-sec-considerations. If feasible, I think it would be perfectly okay to move Sections 8 and 9 to ids-sec-considerations. However, I'd prefer not to move these to Sections to that document before there is a concrete plan to progress ids-sec-considerations. Otherwise we run the risk of completely loosing the text. 2) Since the analysis in Section 9 refers to the different categories, I guess we should at least possibly reproduce Table 1 and its footnotes into ids-sec-considerations? Thanks a lot! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Fri May 22 17:43:38 2020 Return-Path: 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 BA56A3A0E63 for ; Fri, 22 May 2020 17:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 MVE4wPciKe0K for ; Fri, 22 May 2020 17:43:34 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 15C6E3A0E61 for ; Fri, 22 May 2020 17:43:33 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04N0hObd024636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 May 2020 20:43:27 -0400 Date: Fri, 22 May 2020 17:43:24 -0700 From: Benjamin Kaduk To: Fernando Gont Cc: Christopher Wood , pearg@irtf.org Message-ID: <20200523004324.GV58497@kduck.mit.edu> References: <158950494825.32676.4874273590052962910@ietfa.amsl.com> <9ce30cf2-0c89-95a5-89a9-23ee5e818a41@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ce30cf2-0c89-95a5-89a9-23ee5e818a41@gont.com.ar> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Pearg] I-D Action: draft-irtf-pearg-numeric-ids-generation-02.txt X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2020 00:43:37 -0000 On Fri, May 22, 2020 at 07:10:58AM -0300, Fernando Gont wrote: > Hello, Chris, > > Thanks a lot for your feedback! In-line..... > > > On 20/5/20 00:04, Christopher Wood wrote: > > I reviewed this document with no hats on. My feedback is below (I > > hope it's useful)! > > > > In general, this is a nicely written document with clear structure > > and guidance. I think there are some issues with the details, and > > perhaps a bit too much redundancy, but overall it's heading in the > > right direction. I especially like the appendix, which captures our > > lessons learned the hard way. > > > > Before progressing this draft further, is it possible to get feedback > > from folks in the transport area? We might also try and request an > > additional review from secdir, if they're willing. > > Is there some sort of procedure/guideline for this? Should we authors > e.g. request comments on the tsv-area list? Contact the ADs? Something else? It's probably easiest to ask the directorate secretary directly (linked from https://datatracker.ietf.org/dir/). For "normal" IETF directorate reviews the WG chair/shepherd is supposed to have a button to push to request a review, but I don't expect that to work for additional reviews, and I don't know if it's wired up for RGs or not. -Ben From nobody Mon May 25 22:04:25 2020 Return-Path: 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 30C663A09E1 for ; Mon, 25 May 2020 22:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 j6ZSTWebamqq for ; Mon, 25 May 2020 22:04:19 -0700 (PDT) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56453A0A01 for ; Mon, 25 May 2020 22:04:19 -0700 (PDT) Received: by mail-qv1-xf34.google.com with SMTP id er16so8945042qvb.0 for ; Mon, 25 May 2020 22:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=mMT95O1QO/dvac2WuJbg/DYaCPKybKpz3wVv8TKWT5U=; b=QzpxK5Eui+BV4sKQYEn4CSK0+TDCzZ2vtYsadRLv1yzFqDDezXc0+tdGNEKyr51+HK MXtabu997D0SoAfzoqDkpREPTkx6yyo5L6wTxx4unXW+zyq6D5mOkz7vpOwSb9VwH9V3 O8O7ze2Daz4V+iN/RO3X8xJPQMWPyJs473RJsOl/1EBmaRR6n3eXUm1u69IEQt1lvxe6 KIOVHacl+MdKr00OccGV1ZyW9Pp2dlTZm+XHvXi75kW/H9jeYzhHF74zHXDeTevveW0b N/7r4ArSPIETeE1YJgZKJgww3CEsJYE5U9haSt218kvKcnsn6VWa7uBl6OqZorQ5hj9d CQcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mMT95O1QO/dvac2WuJbg/DYaCPKybKpz3wVv8TKWT5U=; b=YUZHgOhwsP1W5Rz015dGUbLpXBr2yJYXRb9iwEuwgg01Xwm1Fg/6eNo9SGqlVODESF SX9/CQDOg5a6CPt3Ji9/minKtuVJE6Vpmv9Gf8v8SoZ6szSkyknWdoSxgPu7EPlHeQbj 5Ir+PsLn4xpuFVzyhCtbYhLBoTV6MrScxPlIJmgfsLIEPLxHXoHFePQyavX/2EqwUyxc Z4UJgYV0FVz7uQ8ewMUx8LXqadoSQReLqGZAzxu0eipqBKf6UwuS0Y3ZK3eXNYwKknAY xvjMM9Sl+IT570yR7QPeg+VVwakFNEkTmhxFUaIJH6R3no3BL2xuLyJEYacPJ+7ySUkt tzqg== X-Gm-Message-State: AOAM533aw1Z6QbCOTzUXqxvTrrU4KQmfsDE+6sN4sy0/8zAevrgMaIeU SQUH9WqPxKwGh/dbULjmOiiJFQSQIzgjAKi59+YnJACj0Gw= X-Google-Smtp-Source: ABdhPJy3u4HlrvOVQpbYqatGK1OIePPxpsb6LMwiZFVrPII5C539+cWpMWM680iKeMZkyEDpmWPfmwj1e6VUE5bSd30= X-Received: by 2002:ad4:43cc:: with SMTP id o12mr2765512qvs.62.1590469458004; Mon, 25 May 2020 22:04:18 -0700 (PDT) MIME-Version: 1.0 From: Joseph Salowey Date: Mon, 25 May 2020 22:04:07 -0700 Message-ID: To: pearg@irtf.org Content-Type: multipart/alternative; boundary="00000000000012253405a6860737" Archived-At: Subject: [Pearg] Comments on draft-rao-pitfol-01 X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 05:04:23 -0000 --00000000000012253405a6860737 Content-Type: text/plain; charset="UTF-8" I had a chance to review draft-rao-pitfol-01. Sensitive information in logs is a constant problem for many security and privacy organizations so I am very happy to see this draft. Below are some thoughts on the draft. 1. While PII information is super important, the problem extends to all types of sensitive information in logs. One common example is service credentials written to logs or data that is confidential to an organization and not an individual. I don't see anything that would limit this approach to just PII, but it may extend the use cases a bit. 2. Log data is incredibly useful for troubleshooting, analytics and other purposes. To meet these use cases the log data may be propagated, extracted, transformed and stored in multiple places. This creates some challenges: A. The data may be transformed into other data models and formats may not preserve any privacy marking B. If the privacy marking changes on a field it's unclear what should be done to historical data. 3. Often when a sensitive value is written to a log it has gone undetected for a period of time. The values have now propagated to multiple systems and the task of the team responding to the incident is to: - stop the logging or mis-identification of the data - determine where the sensitive data has propagated to - purge (or other action) the sensitive date from where it now lives - perform remedial actions and notifications (for example to rotate credentials) I would like a system that helps to automate this. I think the draft provides part of the solution, but it seems there should be more to the solution: 1. Information and data models for sensitivity/privacy tagging of data 2. Ways of attaching that sensitivity/privacy tagging to the data itself (similar to current draft) 3. Interface to systems to control - actions based on tagging - changes to tagging/classification - communication of tagging/classification "out-of-band" I'm not really up on the state of the art here. I know there exists proprietary protocols that do similar, but I'm not aware of any standards work in this area. As an illustration a JSON message could contain a field descriptor to match on a field and an action to take when you match on the field. { "dataFieldDescriptor": { "LogStream": "AuthenticationService", "eventType": "Login", "jsonField": "sessionID", "startDate": "None", "endDate": "Now" }, "action": { "SensitivityLevelTag": "4", "NotificationType": "SummaryReport", "Action": "FullAnonymization", } } This message would be sent to one or more systems. It may result in the inline tagging described in the draft, but the message could be propagated in other ways. ETL systems that transform the data could transform the request for the systems that consume their data. The actions can be optional and derived from the default for the sensitivity level. Notification and reporting is an essential piece of the puzzle. The interface could be provided by log aggregators, endpoints, and ETL systems. This provides a standard interface to different places that store data derived from logs to remediate problems in their existing data. It could potentially be used to service deletion requests and maybe information requests. This obviously needs refinement. A higher level abstraction could decouple the request from the logging format and allow the request go through stages. For example the request says "delete user x@y.com" and then intermediate systems fill out how to fulfil the request. Cheers, Joe --00000000000012253405a6860737 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I had a chance to review=C2=A0draft-rao-pitfol-01.=C2=A0 S= ensitive=C2=A0information in logs is a constant problem for many security a= nd privacy organizations so I am very happy to see this draft.=C2=A0 Below = are some thoughts on the draft.

1.=C2=A0 While PII = information is super important, the problem=C2=A0extends=C2=A0to all types = of sensitive information in logs.=C2=A0 One common example is service crede= ntials written to logs or data that is confidential to an organization and = not an individual.=C2=A0 I don't see anything that would limit this app= roach to just PII, but it may extend the use cases a bit.=C2=A0=C2=A0
=

2.=C2=A0 Log data is incredibly=C2=A0useful for trouble= shooting,=C2=A0 analytics and other purposes.=C2=A0 =C2=A0To meet these use= cases the log data may be propagated, extracted, transformed and stored in= multiple places.=C2=A0 This creates some challenges:

<= div>A. The data may be transformed into other data models=C2=A0and formats = may not preserve any privacy marking
B.=C2=A0 If the privacy mark= ing changes on a field it's unclear what should be done to historical d= ata.=C2=A0

3.=C2=A0 Often when a sensitive value i= s written to a log it has gone undetected for a period of time.=C2=A0 The v= alues have now propagated to multiple systems and the task of the team resp= onding to the incident is to:
  • = stop the logging or mis-identification of the data
  • determine where the sensitive data has propagated to
  • purge (or other action) the sensitive date from whe= re it now lives
  • perform remedial actions= and notifications (for example to rotate credentials)
I woul= d like a system that helps to automate this.=C2=A0 I think the draft provid= es part of the solution, but it seems there should be more to the solution:=
  1. Information and data models for sensitivity/privacy tagg= ing of data
  2. Ways of attaching that sensitivity/privacy tagging to t= he data itself (similar to current draft)
  3. Interface to systems to c= ontrol
    • actions based on tagging
    • changes to tagging/clas= sification
    • communication of tagging/classification "out-of-ban= d"
I'm not really up on the state of the = art here.=C2=A0 I know there exists proprietary protocols that do similar, = but I'm not aware of any standards work in this area.=C2=A0=C2=A0

As an illustration a JSON message could contain a f= ield descriptor to match on a field and an action to take when you match on= the field.=C2=A0

{=C2=A0=C2=A0
=C2=A0 = =C2=A0"dataFieldDescriptor": {=C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0"LogStream": "AuthenticationService",<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"eventType": "Lo= gin",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"jsonField": &quo= t;sessionID",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "startDate&qu= ot;: "None",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "endDate&= quot;: "Now"
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 &= quot;action": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"SensitivityLevelTag": "4",
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"NotificationType": "S= ummaryReport",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0"Action": "FullAnonymization",
=C2=A0 =C2= =A0 }
}

This message would be sent to on= e or more systems.=C2=A0 It may result in the inline tagging described in t= he draft, but the message could be propagated in other ways.=C2=A0 =C2=A0ET= L systems that transform the data could transform the request for the syste= ms that consume their data.=C2=A0 The actions can be optional=C2=A0and deri= ved from the=C2=A0default for the sensitivity level.=C2=A0 =C2=A0Notificati= on and reporting is an essential piece of the puzzle.=C2=A0 The interface c= ould be provided by log aggregators, endpoints, and ETL systems.=C2=A0=C2= =A0

This provides a standard interface to differen= t places that store data derived from logs to remediate problems in their e= xisting data.=C2=A0 It could potentially be used to service deletion reques= ts and maybe information requests.=C2=A0 This obviously needs refinement.= =C2=A0 A higher level abstraction could decouple the request from the loggi= ng format and allow the request go through stages.=C2=A0 For example the re= quest says "delete user=C2=A0x@y.com" and then intermediate systems fill out how to fulfil= =C2=A0the request.=C2=A0

Cheers,

Joe


--00000000000012253405a6860737-- From nobody Tue May 26 03:02:35 2020 Return-Path: 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 F0E2C3A0DA0 for ; Tue, 26 May 2020 03:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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, 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 EXhK6tLdpsOX for ; Tue, 26 May 2020 03:02:29 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1613A0D99 for ; Tue, 26 May 2020 03:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1744; q=dns/txt; s=iport; t=1590487349; x=1591696949; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=LUnqAFQ4hAHWpA6EBs2ZZvKMNCMArzUVZs3o0Lj2ovI=; b=XQ9Lto+jMVXM/x8IkEDcjczTA5IK/Pb3mTo8vbKjNE3whO1HEHtSVyuu ErTsFSz8SjBKIwJRnHR9qw76grtBV7KfmCqZcgJhCZX2mE4INc3puJyQ1 3N2Px7++rab+nj+JIZyw0p91I3bephzpKXfy2TXyiW+AUVT9o3N0/DMwa U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAABL6Mxe/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTMHAQELAYNuASAShFGIIWChcoF8CwEBAQwBAS8EAQGERAK?= =?us-ascii?q?CMjQJDgIDAQELAQEFAQEBAgEFBG2FYoVzBhgFBjYgEAsODAImAgJXBoM5gn2?= =?us-ascii?q?ranaBMoVRhQyBDioBiXeCZoIAgREnHIFPUC4+hE6DFDOCLQSYK4pakCCCXoJ?= =?us-ascii?q?0i0OEZIVBHYMXjS+NPKpng0kCBAYFAhWBUjmBVjMaCBsVZQGCPz0SGA2QTBc?= =?us-ascii?q?VjhI/A2cCBgEHAQEDCY1VAQE?= X-IronPort-AV: E=Sophos;i="5.73,436,1583193600"; d="scan'208";a="26520543" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 May 2020 10:02:25 +0000 Received: from [10.61.225.84] ([10.61.225.84]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 04QA2OmI009321 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 May 2020 10:02:24 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> Date: Tue, 26 May 2020 12:02:24 +0200 Cc: pearg@irtf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> To: Christopher Wood X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.225.84, [10.61.225.84] X-Outbound-Node: aer-core-2.cisco.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 10:02:33 -0000 Hi Chris, Several points. I have a concern about the use of the term =E2=80=9Ccensorship=E2=80=9D. = Is removal of fraudulent material censorship? How about taking down a = system that part of a DOS attack? Is taking down a system that is = attacking critical infrastructure censorship? Is botnet disruption = censorship? Are FCC frequency rules against harmful interference = censorship? By the sweeping definition given, they are. This = immediately diminishes the credibility of the work because it flies in = the face of what normal people think censorship is. I would propose a narrower definition, and at least some discussion to = make clear that we are all handling double-edged swords. I don=E2=80=99t = think doing this invalidates the content that follows. Even better = would be for you to find a more value-neutral term that acknowledges the = nature of the problem, although I would concede that I have no great = suggestion. =20 Also, it seems to me that a reference check is in order. If we look at = Sections 6.2 and 6.3 the authors are discussing various forms of = takedowns, and a reference is made to [Anderson-2011]. To begin with, = as a nit, the first person on that work is Murdoch, not Anderson. = Second, the chapter referenced doesn=E2=80=99t go into any detail about = take downs. There are better more specific references such as Moore and = Clayton, and specifically =E2=80=9CThe Impact of Incentives on Notice = and Take-down=E2=80=9D, WEIS 2008, although I would imagine that there = is even later work available. Finally, did I miss the part where one discusses domain name takedowns = by registry, or has that not been used as a form of censorship? Eliot From nobody Tue May 26 10:04:48 2020 Return-Path: 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 384943A0B79 for ; Tue, 26 May 2020 10:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 HzHbXFuHs30R for ; Tue, 26 May 2020 10:04:39 -0700 (PDT) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9504A3A0B52 for ; Tue, 26 May 2020 10:04:30 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id er16so9805842qvb.0 for ; Tue, 26 May 2020 10:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=GiykULt6dtWWt5gM9rNg4JfZMItV/Z/F/ye45la+dew=; b=Jx/fxW7/URJs1iF1nyXhsZfY+LSIWlnOhFsSebezBvGvO16L9DMWVGXbH8IiewCiS0 Y4v42lYXv5iVy+WXxeGzh1oMQHWiHayMPaQA8PpThXGkeTihvG2Y403t4l+/EfGCA3IY CZKC5SdsMRA4tE0mc4WLul4cGC9Zcb6vrQn7s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=GiykULt6dtWWt5gM9rNg4JfZMItV/Z/F/ye45la+dew=; b=BzTHybWnK+v0sRQ1LvkpjnKqoCMhXD0B759VtzwzG9I3YyhLT3JO1ZP2zVseTzssk/ OeMf8Z61EJsTLAFCWTTS417eoqf/KENzSd1CCCbOSaptyPP+BjnsDEIHa/eFQkdjDivT Zd0wzrD8irvW5cGNb6W1OCFg8Ky0MahQyyN4N5WbfJPC5BQuX8ds5T1A9lD3O7bA09OE m2L1gCr0NLD07wByzX+X5L5MBbPpO/4CHEjt2LOi6uu4HYF5TVwiqy+E8hjTS2BRpph2 ryiGc52eIMg04zoW2RWAtfd2Gq06xXotBvzyLDBwBuKkbTwCHuOGpdq7UdqO68DY5h8D dpjw== X-Gm-Message-State: AOAM532/wXLwvVADqWRja4aDsXo+guQTqL70qHQejeKYeWELG95RuKMP JxEoejm04mixlztIr7pJEwRiUPefUmU= X-Google-Smtp-Source: ABdhPJyNImPXS8LRHwpuF/dytkCAEihntRJiB46aH2LLzKGWzBqwGUSB2DCOnQr/7NrKTY58vjf5vg== X-Received: by 2002:a0c:a8cf:: with SMTP id h15mr3935460qvc.104.1590512668471; Tue, 26 May 2020 10:04:28 -0700 (PDT) Received: from Mallorys-MacBook-Air.local (c-73-163-188-207.hsd1.dc.comcast.net. [73.163.188.207]) by smtp.gmail.com with ESMTPSA id q34sm187401qtd.89.2020.05.26.10.04.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 10:04:27 -0700 (PDT) To: Eliot Lear , Christopher Wood Cc: pearg@irtf.org References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> From: Mallory Knodel Message-ID: Date: Tue, 26 May 2020 13:04:27 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Thunderbird/77.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 17:04:47 -0000 Hi Eliot, On 5/26/20 6:02 AM, Eliot Lear wrote: > I have a concern about the use of the term “censorship”. Is removal of fraudulent material censorship? How about taking down a system that part of a DOS attack? Is taking down a system that is attacking critical infrastructure censorship? Is botnet disruption censorship? Are FCC frequency rules against harmful interference censorship? By the sweeping definition given, they are. This immediately diminishes the credibility of the work because it flies in the face of what normal people think censorship is. It's important to remember two things: Not all governments and decision makers operate in good faith, or with the same legal and moral frameworks, so the legality of censorship can't be relied upon to define what is censorship. Second it is strategic to define censorship as any restriction on content so as to raise the cost. Because while there are indeed recognized legal, legitimate and proportional reasons why the rights to free expression and to access information should be violated, censorship measures should not be taken without careful consideration as it is a human rights matter. This is roughly what anyone working on free expression and censorship would say and I'm happy to have backup from those folks on this list. > I would propose a narrower definition, and at least some discussion to make clear that we are all handling double-edged swords. I don’t think doing this invalidates the content that follows. Even better would be for you to find a more value-neutral term that acknowledges the nature of the problem, although I would concede that I have no great suggestion. Before responding a re-read the introduction to this draft and I think it does an excellent job of framing and narrowing the draft to exactly what it does and not more. Well done, Joe! -Mallory From nobody Tue May 26 12:46:49 2020 Return-Path: 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 7F0B73A0F8E for ; Tue, 26 May 2020 12:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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, 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 vixhN9MqcndW for ; Tue, 26 May 2020 12:46:47 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F405B3A0F8D for ; Tue, 26 May 2020 12:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1758; q=dns/txt; s=iport; t=1590522407; x=1591732007; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=P+wxw1RewxLXaaOmC/y9XROaiEtE4Eiewv1yI/H9Ak8=; b=dEUD/jOMfpvO4MSvL/2T3gU1s+Fx7n6XtQVODG8kXQhrXLWn/Mwh+Wvx IKjrRbTQnbVc7NFEvtX2C1VlI1W/Dmnk7GxgNM8+D3HjdNly0vPxsr/ix 0EuBxcyA65qeNirZh6NACg/KjCqsgT1Mej235m7CUVvKmDQCjF4+1Gm8x I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAADncc1e/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTQGAQELAYNuASASLIQliQGHZiWZaoF8CwEBAQwBAS8EAQG?= =?us-ascii?q?ERAKCMzUIDgIDAQELAQEFAQEBAgEFBG2FYoVyAQEBAQIBGAUGNiAFCwsOCgI?= =?us-ascii?q?CJgICVwYTgyaCXSCtMXaBMoVRhRqBDioBiXeCZoIAgTgMEIIfLj6EToMUM4I?= =?us-ascii?q?tBKMFjzRsgl6CdIp0inQWB5BGjTyqZ4NJAgQGBQIVgVMBN4FWMxoIGxVlAYI?= =?us-ascii?q?+PhIYDZB4jhI/AzA3AgYBBwEBAwmNVQEB?= X-IronPort-AV: E=Sophos;i="5.73,437,1583193600"; d="scan'208";a="26531344" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 May 2020 19:46:38 +0000 Received: from [10.61.225.84] ([10.61.225.84]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 04QJkcYO001526 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 May 2020 19:46:38 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: Date: Tue, 26 May 2020 21:46:37 +0200 Cc: pearg@irtf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> To: Mallory Knodel X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.225.84, [10.61.225.84] X-Outbound-Node: aer-core-3.cisco.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 19:46:49 -0000 Hi Mallory > On 26 May 2020, at 19:04, Mallory Knodel wrote: >=20 > Hi Eliot, >=20 > On 5/26/20 6:02 AM, Eliot Lear wrote: >> I have a concern about the use of the term =E2=80=9Ccensorship=E2=80=9D= . Is removal of fraudulent material censorship? How about taking down = a system that part of a DOS attack? Is taking down a system that is = attacking critical infrastructure censorship? Is botnet disruption = censorship? Are FCC frequency rules against harmful interference = censorship? By the sweeping definition given, they are. This = immediately diminishes the credibility of the work because it flies in = the face of what normal people think censorship is. >=20 > It's important to remember two things: Not all governments and = decision makers operate in good faith, or with the same legal and moral = frameworks, so the legality of censorship can't be relied upon to define = what is censorship. I agree. > Second it is strategic to define censorship as any restriction on = content so as to raise the cost. Because while there are indeed = recognized legal, legitimate and proportional reasons why the rights to = free expression and to access information should be violated, censorship = measures should not be taken without careful consideration as it is a = human rights matter. But the definition in the doc is so broad as to vary substantially from = its commonly understood pejorative meaning without any foundation or = qualification. That gives governments license to say, =E2=80=9CIt=E2=80=99= s okay to censor sometimes: it=E2=80=99s necessary for our national = defense!=E2=80=9D That is where the definition leads when it includes = BOTNET/DOS mitigation. Eliot From nobody Tue May 26 13:37:32 2020 Return-Path: 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 38CB63A0764 for ; Tue, 26 May 2020 13:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 v3jhcXIDvBfl for ; Tue, 26 May 2020 13:37:30 -0700 (PDT) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040F43A0602 for ; Tue, 26 May 2020 13:37:29 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id g20so10123717qvb.9 for ; Tue, 26 May 2020 13:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=FPtOQCYgZhivW7wBAaJYOarBifZO5zmmRa8aAmjN4CQ=; b=hAxxtRyK7ash7GJLFA2lnZVK0pjCWpn1zD+PIyXI2dg84E82tU3N3IFBgrXOmPctQ9 V1vgNsQ4S6hGL1YwnIYo/rsZ86XLPUeljD6zfYljGZSE5OSOyDnPGyRAVYeCvirNI/Pp 79acLhbzK5UmbO9IjbAta18Iygb4OcdEqRiRc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FPtOQCYgZhivW7wBAaJYOarBifZO5zmmRa8aAmjN4CQ=; b=ArH1ydQCeIYViSaGHBh+U6/hBqijDkqrVa7/FzZ0NE+jabpcRb5ag7DL6gXBESMPw8 VVKc4oByGcC65fI2ks/7WgXQdFhTJ4Cc8TmnMWPZx0oNpbxUvYfvV+ewnSAFkybba1GQ i9G3oLVY5BgEbzE7uo/cTGo6/YmXnOQ80JxRtb2WIJI1Zv30J2mWWmec74larjW69ocf +gmQU5zKA/LhwjCfMXXAD8A8fqAMJ3a27Ka942Z6A6pOOmgT+CaqQYPI6rfjF5AV0w/q FXfgQ8yhYPnrUXOf9NL39DTaPnLl7Zw+9Qpenw3pWYYMjcMO/8gyHU0QhS28LthUJ+Yc inew== X-Gm-Message-State: AOAM530o/Wl8T8/8gWI1+X8eLD5S/ShXPQoG5DKeVmwNefm0Soe2hBvx laRyt9KtIT/9UeuV5Z650ADwjcHFxRQ= X-Google-Smtp-Source: ABdhPJw3fbBl/EbCc9IniC0SBF8ivjah2m+Z/YFECVk3pSUxzA81J2jsMVLBT7rxYKL4tN8LuwS3eA== X-Received: by 2002:ad4:4f87:: with SMTP id em7mr20697395qvb.192.1590525447500; Tue, 26 May 2020 13:37:27 -0700 (PDT) Received: from Mallorys-MacBook-Air.local (c-73-163-188-207.hsd1.dc.comcast.net. [73.163.188.207]) by smtp.gmail.com with ESMTPSA id m126sm592792qke.99.2020.05.26.13.37.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 13:37:26 -0700 (PDT) To: Eliot Lear Cc: pearg@irtf.org References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> From: Mallory Knodel Message-ID: <695aca5d-e855-b7a0-e22c-b2aa927941a2@cdt.org> Date: Tue, 26 May 2020 16:37:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Thunderbird/77.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 20:37:31 -0000 On 5/26/20 3:46 PM, Eliot Lear wrote: >> On 26 May 2020, at 19:04, Mallory Knodel wrote: >> >> >> On 5/26/20 6:02 AM, Eliot Lear wrote: >>> I have a concern about the use of the term “censorship”. Is removal of fraudulent material censorship? How about taking down a system that part of a DOS attack? Is taking down a system that is attacking critical infrastructure censorship? Is botnet disruption censorship? Are FCC frequency rules against harmful interference censorship? By the sweeping definition given, they are. This immediately diminishes the credibility of the work because it flies in the face of what normal people think censorship is. >> Second it is strategic to define censorship as any restriction on content so as to raise the cost. Because while there are indeed recognized legal, legitimate and proportional reasons why the rights to free expression and to access information should be violated, censorship measures should not be taken without careful consideration as it is a human rights matter. > But the definition in the doc is so broad as to vary substantially from its commonly understood pejorative meaning without any foundation or qualification. That gives governments license to say, “It’s okay to censor sometimes: it’s necessary for our national defense!” That is where the definition leads when it includes BOTNET/DOS mitigation. > I prefer this to a government saying, "It's okay because what we're doing isn't even considered censorship," which is what happens when we get too scared to call some forms of content control what they are: censorship. -Mallory From nobody Tue May 26 16:57:07 2020 Return-Path: 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 641463A0C3C for ; Tue, 26 May 2020 16:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 c9BoBud6hVQP for ; Tue, 26 May 2020 16:56:56 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680061.outbound.protection.outlook.com [40.107.68.61]) (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 AE9483A0BF3 for ; Tue, 26 May 2020 16:56:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cqphg/l/e7/Tjm+bADzJTTteaOocjBiF/8qRLl1/18XViOzJKoB9IjID0z8DMgGAh0k/+3yzcj4sGH9pLwU8uSM4XsRV6fKAbJl9JdqJgkMIOkjfEzaE/6pBHmsFbRbzYjpuqKXIA3qZBu93vq0LPltEEEpPn+S4iB5GADaxfDR+lHSdjsxoLnKLS+Q64td0qGODHOLL7Y9vIznhn7whIrFiGLzDuW+yGvnczcplTMnQSHYq5auXz0ZZ+Pg9/lfQz/zcmgzQpW5n1F13qaBL5PGOagOHafuA89kT0J0xBkdaEFo2rsh7kjcwTXFHoGs7gBFLNq1K9xRMsiRkOmcONg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ru+aHDxijl8euom+hm18jtv1Wp7kUd+9vrs5pg2Dbb8=; b=KyLSd/TBQRYWO4nxcJyFy8Ub6qUncZGWK/tuGfSlyBk2HJIpttDOMrwbvYgvSlrFw4tXfcuXggD7CQdT5ctAF5/lS1jWRaltTHQXaAwPqA58Z5gybvy4HZwQVHmlZAZ3mJv/XKkoS9PwLGr0RhWNTUqevaOlX8lbKAvUZtPWHWheHOTn5qmHaKLF+5vdna4MOImxv5FhuUKN/7esLcYFQZaOQj1oyZliHWppaighPbHXKOmc9k3tS8VPWLKMDCif6ape4el2mWBxA1zkmz9mLk0ykdIXNV3usI1c70ZhdE0N8Ji0ktzvOLVk84YbvVydaHHwAfOK9NaLIuW69jbWMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ru+aHDxijl8euom+hm18jtv1Wp7kUd+9vrs5pg2Dbb8=; b=SX5DwJGXsuoW+VCJfPJOIc/o8AHBXXzUqRGWhb1BnXmQaW+f7ypDeKqSYuwAnK6EjLuyO5KEGZHQP2GNSH8eMLcSyVwGwRLCr3ylmGpoOWp+tvDYd+0pEg5vEOq8hAEQTsP4owVst+a4b6CxzAPSdpyb7x+CAEbBLKGRIurlHY8= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BY5PR06MB6689.namprd06.prod.outlook.com (2603:10b6:a03:23a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Tue, 26 May 2020 23:56:53 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5%5]) with mapi id 15.20.3045.016; Tue, 26 May 2020 23:56:53 +0000 From: Joseph Lorenzo Hall To: Eliot Lear CC: Christopher Wood , "pearg@irtf.org" Thread-Topic: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" Thread-Index: AQHWLsgqnBPhO5w6N0yNNHBtsaHVYqi6K/EAgADpJgA= Date: Tue, 26 May 2020 23:56:53 +0000 Message-ID: <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=isoc.org; x-originating-ip: [108.28.51.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0917a294-b18d-4aa0-1ec1-08d801d076ed x-ms-traffictypediagnostic: BY5PR06MB6689: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 041517DFAB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kC0trUrq3dL02JVlfm7MtlNSKDpKTlVr2ugmT1nEv9IeoXa8jDL2i9/KVcIP18/lSmYPjUD56eEdpEetEzQ2QOq8xuAK0PvGz4Hd6mspxzNDGQD+tiahsjOBhkKmH+lXT23PN6S9nGiO3iVbPu6KmVmxRo+/cPFrX/3HQyL0v336sFe0dA0WoOKGCk6ILt5gULUM9hu1jjN41pjeR2qG3PgWIjwYb+eQr0vgmYGALcXiXezmaxo4wHd1tGW783BPlMIgTQLLD1H05bv0MmgfcpT6OF/mmFEXAn0usjAUTHtlfRZo/1wOTN752blRFtLZlPJdJyZViCzRvY6/nZMlBQc+bL/V41ylDj0mYyCdXFTdg23C80ZKh4y5VwTMGzhJvvZPTmKWVb0NiIc/vbFTlA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(376002)(366004)(39830400003)(396003)(346002)(33656002)(26005)(66556008)(186003)(83080400001)(71200400001)(64756008)(91956017)(76116006)(66446008)(66476007)(2616005)(66946007)(5660300002)(166002)(6506007)(478600001)(316002)(36756003)(8676002)(6486002)(86362001)(966005)(4326008)(54906003)(2906002)(6512007)(66574014)(53546011)(8936002)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: AKlKwk9LYS+fKc8lS4bzxEX9vxUA57YXX8v3JkvnWBil/6BugfRFxdL+qoRFPufMM9ROzDcOlmwWf/zm+oNuivAit7gD5cP65FwYy9RPKHADoZ5avMjFhUPAGJ/u1RmfEjDX9CPrOeDJyiqxC28XZ0tjAp+/DY0xCE91ZWAaOcw47sE9Ki9h7pxahcvmbl0FxjSLYzSAfeZZVgz6vafMy3yb18rTpe8YgtkHL1h6uoDovCDt1icLynieM9giG6BynptGgqpFSW9TIq7b5O42JG/89mRiXAo9qU5GSdNA55gWcTHu/SS5bzi5ZwWEkvV+sWzwX0N3MFeZxg+dd+F5S+PV2VV+KlsLvzvEoCmfqCJbF5crDq1vEP/8tEiFZX049j6aAItdcaz+K96SaGL21/KLdiXq4yZnfgWMVjjqpkl/UZgoux19DBWYJX+KKwrXnTSQ57eZ4claGDMEK1/3sCA9zOLzRQZt2kkIL43J0KKI+b3KAX54Y8FfqvuayP3f x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_434A7CA0DCE142A189B0E9B8959B9343isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 0917a294-b18d-4aa0-1ec1-08d801d076ed X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2020 23:56:53.1179 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /3pZK8Mb5GniRVQk+uWswEHRycGQeazpw5YbwCJ5EIShIb78vvBub96enfoQmxSX X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6689 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 23:57:05 -0000 --_000_434A7CA0DCE142A189B0E9B8959B9343isocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KEkgd29yayBmb3IgdGhlIEludGVybmV0IFNvY2lldHkgYnV0IGhlcmUgcmVwcmVzZW50IG9ubHkg bXlzZWxmLikNCg0KT24gTWF5IDI2LCAyMDIwLCBhdCA2OjAyIEFNLCBFbGlvdCBMZWFyIDxsZWFy PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpsZWFyPTQwY2lzY28uY29tQGRtYXJj LmlldGYub3JnPj4gd3JvdGU6DQoNCkhpIENocmlzLA0KDQpTZXZlcmFsIHBvaW50cy4NCg0KDQpU aGFua3MsIEVsaW90LCBJIGFwcHJlY2lhdGUgeW91ciByZXZpZXcgYW5kIGZlZWRiYWNrLg0KDQpJ IGhhdmUgYSBjb25jZXJuIGFib3V0IHRoZSB1c2Ugb2YgdGhlIHRlcm0g4oCcY2Vuc29yc2hpcOKA nS4gIElzIHJlbW92YWwgb2YgZnJhdWR1bGVudCBtYXRlcmlhbCBjZW5zb3JzaGlwPyAgSG93IGFi b3V0IHRha2luZyBkb3duIGEgc3lzdGVtIHRoYXQgcGFydCBvZiBhIERPUyBhdHRhY2s/ICBJcyB0 YWtpbmcgZG93biBhIHN5c3RlbSB0aGF0IGlzIGF0dGFja2luZyBjcml0aWNhbCBpbmZyYXN0cnVj dHVyZSBjZW5zb3JzaGlwPyAgSXMgYm90bmV0IGRpc3J1cHRpb24gY2Vuc29yc2hpcD8gIEFyZSBG Q0MgZnJlcXVlbmN5IHJ1bGVzIGFnYWluc3QgaGFybWZ1bCBpbnRlcmZlcmVuY2UgY2Vuc29yc2hp cD8gIEJ5IHRoZSBzd2VlcGluZyBkZWZpbml0aW9uIGdpdmVuLCB0aGV5IGFyZS4gIFRoaXMgIGlt bWVkaWF0ZWx5IGRpbWluaXNoZXMgdGhlIGNyZWRpYmlsaXR5IG9mIHRoZSB3b3JrIGJlY2F1c2Ug aXQgZmxpZXMgaW4gdGhlIGZhY2Ugb2Ygd2hhdCBub3JtYWwgcGVvcGxlIHRoaW5rIGNlbnNvcnNo aXAgaXMuDQoNCkkgd291bGQgcHJvcG9zZSBhIG5hcnJvd2VyIGRlZmluaXRpb24sIGFuZCBhdCBs ZWFzdCBzb21lIGRpc2N1c3Npb24gdG8gbWFrZSBjbGVhciB0aGF0IHdlIGFyZSBhbGwgaGFuZGxp bmcgZG91YmxlLWVkZ2VkIHN3b3Jkcy4gIEkgZG9u4oCZdCB0aGluayBkb2luZyB0aGlzIGludmFs aWRhdGVzIHRoZSBjb250ZW50IHRoYXQgZm9sbG93cy4gIEV2ZW4gYmV0dGVyIHdvdWxkIGJlIGZv ciB5b3UgdG8gZmluZCBhIG1vcmUgdmFsdWUtbmV1dHJhbCB0ZXJtIHRoYXQgYWNrbm93bGVkZ2Vz IHRoZSBuYXR1cmUgb2YgdGhlIHByb2JsZW0sIGFsdGhvdWdoIEkgd291bGQgY29uY2VkZSB0aGF0 IEkgaGF2ZSBubyBncmVhdCBzdWdnZXN0aW9uLg0KDQpUaGlzIGRyYWZ0IGhhcyBiZWVuIHRocm91 Z2ggdGhpcyBkaXNjdXNzaW9uIGEgZmV3IHRpbWVzIG5vdy4gVGhpcyBpcyBhIHJlZmVyZW5jZSBk b2N1bWVudCBtZWFudCB0byBoZWxwIHByb3RvY29sIGRlc2lnbmVycyBhbmQgaW1wbGVtZW50ZXJz IHVuZGVyc3RhbmQgaG93IGZlYXR1cmVzIG9mIG90aGVyIHByb3RvY29scyBoYXZlIGJlZW4gdXNl ZCB0byBibG9jayBvciBpbXBhaXIgdHJhZmZpYyBieSBlbnRpdGllcyBpbiBwb3NpdGlvbnMgb2Yg cG93ZXIg4oCUIHJlZ2FyZGxlc3Mgb2Ygd2hhdCB0aGUgZW50aXR5IGlzIG9yIHdoYXQgdGhlIHRy YWZmaWMgaXMg4oCUIHNvIHRoYXQgdGhlc2UgZGVzaWduZXJzIGFuZCBpbXBsZW1lbnRlcnMgY2Fu IGF0IGxlYXN0IGRlc2lnbi9pbXBsZW1lbnQgYSBwcm90b2NvbCBrbm93aW5nIHdoYXQgdGhleSBj YW4gZXhwZWN0IGluIHRoZSB3aWxkLiBUaGUgZGVmaW5pdGlvbiBvZiBjZW5zb3JzaGlwIGhlcmUg aXMgcHJldHR5IGdlbmVyaWMgYW5kIEkgaGF2ZW7igJl0IHNlZW4gbXVjaCBvZiBhbiBhcHBldGl0 ZSB0byBhZG9wdCBzb21ldGhpbmcgZGlmZmVyZW50LiBJIHdhbnQgdG8gZW1waGFzaXplIHdoYXQg TWFsbG9yeSBqdXN0IHNhaWQgaW4gYSBtZXNzYWdlIHRvIHRoaXMgdGhyZWFkOiBlbnRpdGllcyBh ZHZlcnNhcmlhbGx5IG1lc3Npbmcgd2l0aCBpbmZvcm1hdGlvbiBmbG93cyBpcyBjZW5zb3JzaGlw ICh0aGF0IGlzIHBlcmhhcHMgdG9vIHBpdGh5IGZvciBvdXIgcHVycG9zZXMhKS4NCg0KQWxzbywg aXQgc2VlbXMgdG8gbWUgdGhhdCBhIHJlZmVyZW5jZSBjaGVjayBpcyBpbiBvcmRlci4gIElmIHdl IGxvb2sgYXQgU2VjdGlvbnMgNi4yIGFuZCA2LjMgdGhlIGF1dGhvcnMgYXJlIGRpc2N1c3Npbmcg dmFyaW91cyBmb3JtcyBvZiB0YWtlZG93bnMsIGFuZCBhIHJlZmVyZW5jZSBpcyBtYWRlIHRvIFtB bmRlcnNvbi0yMDExXS4gIFRvIGJlZ2luIHdpdGgsIGFzIGEgbml0LCB0aGUgZmlyc3QgcGVyc29u IG9uIHRoYXQgd29yayBpcyBNdXJkb2NoLCBub3QgQW5kZXJzb24uICBTZWNvbmQsIHRoZSBjaGFw dGVyIHJlZmVyZW5jZWQgZG9lc27igJl0IGdvIGludG8gYW55IGRldGFpbCBhYm91dCB0YWtlIGRv d25zLiAgVGhlcmUgYXJlIGJldHRlciBtb3JlIHNwZWNpZmljIHJlZmVyZW5jZXMgc3VjaCBhcyBN b29yZSBhbmQgQ2xheXRvbiwgYW5kIHNwZWNpZmljYWxseSDigJxUaGUgSW1wYWN0IG9mIEluY2Vu dGl2ZXMgb24gTm90aWNlIGFuZCBUYWtlLWRvd27igJ0sIFdFSVMgMjAwOCwgYWx0aG91Z2ggSSB3 b3VsZCBpbWFnaW5lIHRoYXQgdGhlcmUgaXMgZXZlbiBsYXRlciB3b3JrIGF2YWlsYWJsZS4NCg0K QWgsIHdpbGwgZml4IHRvIGdldCB0aGUgb3JkZXIgb2YgYXV0aG9ycyByaWdodCBhbmQgeW914oCZ cmUgcmlnaHQgdGhhdCBpdCBkb2VzbuKAmXQgZ28gaW50byBhbnkgZGV0YWlsLiBIZXJlIHdlIHdl cmUgbG9va2luZyBmb3Igc29tZXRoaW5nIHRoYXQgYWN0dWFsbHkgd2VudCBpbnRvIHBoeXNpY2Fs IHNlaXp1cmUgb2Ygc2VydmVyIGhhcmR3YXJlIG9yIHNlaXp1cmUgb2YgZW50aXJlIGxvZ2ljYWwg ZW50aXRpZXMgKGluc3RlYWQgb2Ygbm90aWNlIGFuZCB0YWtlZG93biwgdGhlIG5leHQgc2VjdGlv biwgd2hpY2ggaXMgb2Z0ZW4gZGlyZWN0ZWQgYXQgaW5kaXZpZHVhbCBwaWVjZXMgb2YgY29udGVu dCBvciBhIHNpbmdsZSBkb21haW4gb24gYSB3ZWJzZXJ2ZXIpLiBJ4oCZbGwgY2hlY2sgb3V0IHRo ZSBjaXRhdGlvbiBhYm92ZSBhbmQgY2l0YXRpb25zIHNpbmNlIGFuZCBzZWUgaWYgd2UgY2Fu4oCZ dCBnZXQgYmV0dGVyIHBvaW50ZXJzIGluIHRoZXJlICh0aGlzIHNlY3Rpb24gaXMgb2J2aW91c2x5 IHRvIGJlIGNvbXBsZXRlIGFuZCBxdWl0ZSBzdmVsdGUpLg0KDQpGaW5hbGx5LCBkaWQgSSBtaXNz IHRoZSBwYXJ0IHdoZXJlIG9uZSBkaXNjdXNzZXMgZG9tYWluIG5hbWUgdGFrZWRvd25zIGJ5IHJl Z2lzdHJ5LCBvciBoYXMgdGhhdCBub3QgYmVlbiB1c2VkIGFzIGEgZm9ybSBvZiBjZW5zb3JzaGlw Pw0KDQoNCldlIGNhbiBhZGQgaXQgaWYgeW91IGhhdmUgY2l0YXRpb25zLiBXb3VsZCBsb3ZlIGEg UFIgb2YgY291cnNlIG9yIHN1Z2dlc3RlZCB0ZXh0Lg0KDQpFbGlvdA0KDQotLQ0KUGVhcmcgbWFp bGluZyBsaXN0DQpQZWFyZ0BpcnRmLm9yZzxtYWlsdG86UGVhcmdAaXJ0Zi5vcmc+DQpodHRwczov L3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BlYXJnDQoNCi0tDQpKb3NlcGggTG9yZW56 byBIYWxsLCBTZW5pb3IgVmljZSBQcmVzaWRlbnQsIFN0cm9uZyBJbnRlcm5ldA0KaGFsbEBpc29j Lm9yZzxtYWlsdG86aGFsbEBpc29jLm9yZz4gfCArMS03MDMtNDgzLTk1MDQNCmludGVybmV0c29j aWV0eS5vcmc8aHR0cDovL2ludGVybmV0c29jaWV0eS5vcmc+IHwgQGludGVybmV0c29jaWV0eQ0K cGdwOiBodHRwczovL2pvc2VwaGhhbGwub3JnL2dwZy1rZXkNCjNDQTI4RDdCOUY2RERCRDM0QjEw MTYwNzVGODY2OTg3NDBBOUE4NzENCg0K --_000_434A7CA0DCE142A189B0E9B8959B9343isocorg_ Content-Type: text/html; charset="utf-8" Content-ID: <6131E9BB4AD0AB43907DD4E88C1594CF@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCihJIHdvcmsgZm9yIHRoZSBJbnRlcm5ldCBTb2Np ZXR5IGJ1dCBoZXJlIHJlcHJlc2VudCBvbmx5IG15c2VsZi4pPGJyIGNsYXNzPSIiPg0KPGRpdj48 YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+T24gTWF5IDI2LCAyMDIwLCBhdCA2OjAyIEFNLCBFbGlvdCBMZWFyICZsdDs8YSBocmVm PSJtYWlsdG86bGVhcj00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyIgY2xhc3M9IiI+bGVhcj00 MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNz PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPkhpIENocmlzLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNldmVyYWwgcG9pbnRz LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsIEVsaW90LCBJIGFw cHJlY2lhdGUgeW91ciByZXZpZXcgYW5kIGZlZWRiYWNrLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj5JIGhhdmUgYSBjb25jZXJuIGFib3V0IHRoZSB1c2Ugb2YgdGhlIHRlcm0g4oCcY2Vu c29yc2hpcOKAnS4gJm5ic3A7SXMgcmVtb3ZhbCBvZiBmcmF1ZHVsZW50IG1hdGVyaWFsIGNlbnNv cnNoaXA/ICZuYnNwO0hvdyBhYm91dCB0YWtpbmcgZG93biBhIHN5c3RlbSB0aGF0IHBhcnQgb2Yg YSBET1MgYXR0YWNrPyAmbmJzcDtJcyB0YWtpbmcgZG93biBhIHN5c3RlbSB0aGF0IGlzIGF0dGFj a2luZyBjcml0aWNhbCBpbmZyYXN0cnVjdHVyZSBjZW5zb3JzaGlwPyAmbmJzcDtJcw0KIGJvdG5l dCBkaXNydXB0aW9uIGNlbnNvcnNoaXA/ICZuYnNwO0FyZSBGQ0MgZnJlcXVlbmN5IHJ1bGVzIGFn YWluc3QgaGFybWZ1bCBpbnRlcmZlcmVuY2UgY2Vuc29yc2hpcD8gJm5ic3A7QnkgdGhlIHN3ZWVw aW5nIGRlZmluaXRpb24gZ2l2ZW4sIHRoZXkgYXJlLiAmbmJzcDtUaGlzICZuYnNwO2ltbWVkaWF0 ZWx5IGRpbWluaXNoZXMgdGhlIGNyZWRpYmlsaXR5IG9mIHRoZSB3b3JrIGJlY2F1c2UgaXQgZmxp ZXMgaW4gdGhlIGZhY2Ugb2Ygd2hhdCBub3JtYWwgcGVvcGxlIHRoaW5rDQogY2Vuc29yc2hpcCBp cy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHdvdWxkIHByb3Bvc2UgYSBuYXJyb3dl ciBkZWZpbml0aW9uLCBhbmQgYXQgbGVhc3Qgc29tZSBkaXNjdXNzaW9uIHRvIG1ha2UgY2xlYXIg dGhhdCB3ZSBhcmUgYWxsIGhhbmRsaW5nIGRvdWJsZS1lZGdlZCBzd29yZHMuICZuYnNwO0kgZG9u 4oCZdCB0aGluayBkb2luZyB0aGlzIGludmFsaWRhdGVzIHRoZSBjb250ZW50IHRoYXQgZm9sbG93 cy4gJm5ic3A7RXZlbiBiZXR0ZXIgd291bGQgYmUgZm9yIHlvdSB0byBmaW5kIGEgbW9yZSB2YWx1 ZS1uZXV0cmFsIHRlcm0gdGhhdA0KIGFja25vd2xlZGdlcyB0aGUgbmF0dXJlIG9mIHRoZSBwcm9i bGVtLCBhbHRob3VnaCBJIHdvdWxkIGNvbmNlZGUgdGhhdCBJIGhhdmUgbm8gZ3JlYXQgc3VnZ2Vz dGlvbi4gJm5ic3A7PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpUaGlzIGRyYWZ0IGhhcyBiZWVuIHRocm91Z2gg dGhpcyBkaXNjdXNzaW9uIGEgZmV3IHRpbWVzIG5vdy4gVGhpcyBpcyBhIHJlZmVyZW5jZSBkb2N1 bWVudCBtZWFudCB0byBoZWxwIHByb3RvY29sIGRlc2lnbmVycyBhbmQgaW1wbGVtZW50ZXJzIHVu ZGVyc3RhbmQgaG93IGZlYXR1cmVzIG9mIG90aGVyIHByb3RvY29scyBoYXZlIGJlZW4gdXNlZCB0 byBibG9jayBvciBpbXBhaXIgdHJhZmZpYyBieSBlbnRpdGllcyBpbiBwb3NpdGlvbnMgb2YgcG93 ZXINCiDigJQgcmVnYXJkbGVzcyBvZiB3aGF0IHRoZSBlbnRpdHkgaXMgb3Igd2hhdCB0aGUgdHJh ZmZpYyBpcyDigJQgc28gdGhhdCB0aGVzZSBkZXNpZ25lcnMgYW5kIGltcGxlbWVudGVycyBjYW4g YXQgbGVhc3QgZGVzaWduL2ltcGxlbWVudCBhIHByb3RvY29sIGtub3dpbmcgd2hhdCB0aGV5IGNh biBleHBlY3QgaW4gdGhlIHdpbGQuIFRoZSBkZWZpbml0aW9uIG9mIGNlbnNvcnNoaXAgaGVyZSBp cyBwcmV0dHkgZ2VuZXJpYyBhbmQgSSBoYXZlbuKAmXQgc2VlbiBtdWNoDQogb2YgYW4gYXBwZXRp dGUgdG8gYWRvcHQgc29tZXRoaW5nIGRpZmZlcmVudC4gSSB3YW50IHRvIGVtcGhhc2l6ZSB3aGF0 IE1hbGxvcnkganVzdCBzYWlkIGluIGEgbWVzc2FnZSB0byB0aGlzIHRocmVhZDombmJzcDs8c3Bh biBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsi IGNsYXNzPSIiPmVudGl0aWVzIGFkdmVyc2FyaWFsbHkgbWVzc2luZyB3aXRoIGluZm9ybWF0aW9u IGZsb3dzIGlzIGNlbnNvcnNoaXANCiAodGhhdCBpcyBwZXJoYXBzIHRvbyBwaXRoeSBmb3Igb3Vy IHB1cnBvc2VzISkuPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ QWxzbywgaXQgc2VlbXMgdG8gbWUgdGhhdCBhIHJlZmVyZW5jZSBjaGVjayBpcyBpbiBvcmRlci4g Jm5ic3A7SWYgd2UgbG9vayBhdCBTZWN0aW9ucyA2LjIgYW5kIDYuMyB0aGUgYXV0aG9ycyBhcmUg ZGlzY3Vzc2luZyB2YXJpb3VzIGZvcm1zIG9mIHRha2Vkb3ducywgYW5kIGEgcmVmZXJlbmNlIGlz IG1hZGUgdG8gW0FuZGVyc29uLTIwMTFdLiAmbmJzcDtUbyBiZWdpbiB3aXRoLCBhcyBhIG5pdCwg dGhlIGZpcnN0IHBlcnNvbiBvbiB0aGF0DQogd29yayBpcyBNdXJkb2NoLCBub3QgQW5kZXJzb24u ICZuYnNwO1NlY29uZCwgdGhlIGNoYXB0ZXIgcmVmZXJlbmNlZCBkb2VzbuKAmXQgZ28gaW50byBh bnkgZGV0YWlsIGFib3V0IHRha2UgZG93bnMuICZuYnNwO1RoZXJlIGFyZSBiZXR0ZXIgbW9yZSBz cGVjaWZpYyByZWZlcmVuY2VzIHN1Y2ggYXMgTW9vcmUgYW5kIENsYXl0b24sIGFuZCBzcGVjaWZp Y2FsbHkg4oCcVGhlIEltcGFjdCBvZiBJbmNlbnRpdmVzIG9uIE5vdGljZSBhbmQgVGFrZS1kb3du 4oCdLCBXRUlTIDIwMDgsDQogYWx0aG91Z2ggSSB3b3VsZCBpbWFnaW5lIHRoYXQgdGhlcmUgaXMg ZXZlbiBsYXRlciB3b3JrIGF2YWlsYWJsZS48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCkFoLCB3aWxsIGZpeCB0 byBnZXQgdGhlIG9yZGVyIG9mIGF1dGhvcnMgcmlnaHQgYW5kIHlvdeKAmXJlIHJpZ2h0IHRoYXQg aXQgZG9lc27igJl0IGdvIGludG8gYW55IGRldGFpbC4gSGVyZSB3ZSB3ZXJlIGxvb2tpbmcgZm9y IHNvbWV0aGluZyB0aGF0IGFjdHVhbGx5IHdlbnQgaW50byBwaHlzaWNhbCBzZWl6dXJlIG9mIHNl cnZlciBoYXJkd2FyZSBvciBzZWl6dXJlIG9mIGVudGlyZSBsb2dpY2FsIGVudGl0aWVzIChpbnN0 ZWFkIG9mIG5vdGljZSBhbmQgdGFrZWRvd24sDQogdGhlIG5leHQgc2VjdGlvbiwgd2hpY2ggaXMg b2Z0ZW4gZGlyZWN0ZWQgYXQgaW5kaXZpZHVhbCBwaWVjZXMgb2YgY29udGVudCBvciBhIHNpbmds ZSBkb21haW4gb24gYSB3ZWJzZXJ2ZXIpLiBJ4oCZbGwgY2hlY2sgb3V0IHRoZSBjaXRhdGlvbiBh Ym92ZSBhbmQgY2l0YXRpb25zIHNpbmNlIGFuZCBzZWUgaWYgd2UgY2Fu4oCZdCBnZXQgYmV0dGVy IHBvaW50ZXJzIGluIHRoZXJlICh0aGlzIHNlY3Rpb24gaXMgb2J2aW91c2x5IHRvIGJlIGNvbXBs ZXRlIGFuZA0KIHF1aXRlIHN2ZWx0ZSkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj5GaW5hbGx5LCBkaWQgSSBtaXNzIHRoZSBwYXJ0IHdoZXJlIG9uZSBkaXNjdXNzZXMgZG9t YWluIG5hbWUgdGFrZWRvd25zIGJ5IHJlZ2lzdHJ5LCBvciBoYXMgdGhhdCBub3QgYmVlbiB1c2Vk IGFzIGEgZm9ybSBvZiBjZW5zb3JzaGlwPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdj5XZSBjYW4gYWRkIGl0IGlmIHlvdSBoYXZlIGNpdGF0aW9ucy4gV291bGQgbG92ZSBhIFBS IG9mIGNvdXJzZSBvciBzdWdnZXN0ZWQgdGV4dC48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+RWxpb3Q8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLSA8YnIgY2xhc3M9IiI+DQpQ ZWFyZyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86UGVhcmdAaXJ0 Zi5vcmciIGNsYXNzPSIiPlBlYXJnQGlydGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8v d3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vcGVhcmc8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJ0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0 byIgc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0idGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtp dC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNz PSIiPg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJ0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0 byIgc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXY+LS0mbmJzcDs8YnIgY2xhc3M9IiI+DQpKb3Nl cGggTG9yZW56byBIYWxsLCZuYnNwO1NlbmlvciBWaWNlIFByZXNpZGVudCwmbmJzcDtTdHJvbmcg SW50ZXJuZXQ8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86aGFsbEBpc29jLm9yZyIgY2xh c3M9IiI+aGFsbEBpc29jLm9yZzwvYT4gfCAmIzQzOzEtNzAzLTQ4My05NTA0PGJyIGNsYXNzPSIi Pg0KPGEgaHJlZj0iaHR0cDovL2ludGVybmV0c29jaWV0eS5vcmciIGNsYXNzPSIiPmludGVybmV0 c29jaWV0eS5vcmc8L2E+IHwmbmJzcDtAaW50ZXJuZXRzb2NpZXR5PGJyIGNsYXNzPSIiPg0KcGdw OiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vam9zZXBoaGFsbC5vcmcvZ3BnLWtleSIgY2xhc3M9IiI+ aHR0cHM6Ly9qb3NlcGhoYWxsLm9yZy9ncGcta2V5PC9hPjxiciBjbGFzcz0iIj4NCjNDQTI4RDdC OUY2RERCRDM0QjEwMTYwNzVGODY2OTg3NDBBOUE4NzE8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_434A7CA0DCE142A189B0E9B8959B9343isocorg_-- From nobody Wed May 27 02:47:27 2020 Return-Path: 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 7653C3A0C3D for ; Wed, 27 May 2020 02:47:25 -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 WnhEWEIL_WB3 for ; Wed, 27 May 2020 02:47:24 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D383A0C3C for ; Wed, 27 May 2020 02:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10617; q=dns/txt; s=iport; t=1590572843; x=1591782443; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=XeNhtmaUrBPUN65EKLMg/sd5YQIjoDxgBMXhXwTjWRg=; b=YPgGG6fhpnkLZur/q43Gun4kTzqbEY9kVACAHKVTqQM6PLWsDMsM1JKr eO6ZdtCVMwNjnosq5pbzHhepTgRZIzT3xVPbg5VbhralPkdXls99HDUw6 Xgwmvy5YvcEwXhZ00BX5UsN7ynkEUcZG7ieDWDy4WBH7xroUzh4AwFSS1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAAA9Ns5e/xbLJq1jAxwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBgXkEAQELAYEggXdUASASLIQliQGIBYMQkEuIEQsBAQEMAQE?= =?us-ascii?q?YAQwKBAEBhEQCghMlNwYOAgMBAQsBAQUBAQECAQYEbYVWDIVzAQEBAQEBAQE?= =?us-ascii?q?WBQZLCwULCz8DAgInHxEGE4MmAYJcIA+tHXaBMoRPQEKFFYE4AYYVgjOBL4J?= =?us-ascii?q?mggCBESccgh8uPoJnAQKBTDkmgk0zgi0EmC2bAoJegnWFNYYPhGWFQh2DGF6?= =?us-ascii?q?MVI0+mkKQMINJAgQGBQIVgWkjgVYzGggbFTsqAYI+CTUSGA2QTBcViE6FRD8?= =?us-ascii?q?DMAI1AgYBBwEBAwmNQAEB?= X-IronPort-AV: E=Sophos; i="5.73,440,1583193600"; d="scan'208,217"; a="26554464" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 May 2020 09:47:19 +0000 Received: from [10.61.225.84] ([10.61.225.84]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04R9lH52029115 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 May 2020 09:47:19 GMT From: Eliot Lear Message-Id: <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BBF114DE-63B2-4C07-A354-42E4FDED2053" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 27 May 2020 11:47:17 +0200 In-Reply-To: <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> Cc: Christopher Wood , "pearg@irtf.org" To: Joseph Lorenzo Hall References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.225.84, [10.61.225.84] X-Outbound-Node: aer-core-1.cisco.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 09:47:25 -0000 --Apple-Mail=_BBF114DE-63B2-4C07-A354-42E4FDED2053 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Joe, > I want to emphasize what Mallory just said in a message to this = thread: entities adversarially messing with information flows is = censorship (that is perhaps too pithy for our purposes!). To me at least, =E2=80=9Cinformation flows=E2=80=9D immediately improves = the situation. No one can claim that a DOS attack, or a cyberattack of = any kind, is an information flow. One can reasonably argue that spam is = not an information flow. Moreover, the term seems to fit your draft = well. >=20 >> Also, it seems to me that a reference check is in order. If we look = at Sections 6.2 and 6.3 the authors are discussing various forms of = takedowns, and a reference is made to [Anderson-2011]. To begin with, = as a nit, the first person on that work is Murdoch, not Anderson. = Second, the chapter referenced doesn=E2=80=99t go into any detail about = take downs. There are better more specific references such as Moore and = Clayton, and specifically =E2=80=9CThe Impact of Incentives on Notice = and Take-down=E2=80=9D, WEIS 2008, although I would imagine that there = is even later work available. >=20 > Ah, will fix to get the order of authors right and you=E2=80=99re = right that it doesn=E2=80=99t go into any detail. Here we were looking = for something that actually went into physical seizure of server = hardware or seizure of entire logical entities (instead of notice and = takedown, the next section, which is often directed at individual pieces = of content or a single domain on a webserver). I=E2=80=99ll check out = the citation above and citations since and see if we can=E2=80=99t get = better pointers in there (this section is obviously to be complete and = quite svelte). Ok. That sounds like a classic asset seizure. It may be worth = expanding on how and when physical asset seizure is effective, = especially in a cloud-based world. >=20 >> Finally, did I miss the part where one discusses domain name = takedowns by registry, or has that not been used as a form of = censorship? >>=20 >=20 > We can add it if you have citations. Would love a PR of course or = suggested text. I guess I would suggest starting with the references in = guidance-domain-seizures-07mar12-en.pdf = . Eliot >=20 >> Eliot >>=20 >> --=20 >> Pearg mailing list >> Pearg@irtf.org >> https://www.irtf.org/mailman/listinfo/pearg = >=20 > --=20 > Joseph Lorenzo Hall, Senior Vice President, Strong Internet > hall@isoc.org | +1-703-483-9504 > internetsociety.org | @internetsociety > pgp: https://josephhall.org/gpg-key > 3CA28D7B9F6DDBD34B1016075F86698740A9A871 --Apple-Mail=_BBF114DE-63B2-4C07-A354-42E4FDED2053 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Joe,

I want to emphasize what Mallory just said in = a message to this thread: entities adversarially = messing with information flows is censorship (that is perhaps too pithy = for our purposes!).

To me at least, =E2=80=9Cinformation flows=E2=80=9D = immediately improves the situation.  No one can claim that a DOS = attack, or a cyberattack of any kind, is an information flow.  One = can reasonably argue that spam is not an information flow. =  Moreover, the term seems to fit your draft = well.


Also, it seems = to me that a reference check is in order.  If we look at Sections = 6.2 and 6.3 the authors are discussing various forms of takedowns, and a = reference is made to [Anderson-2011].  To begin with, as a nit, the = first person on that work is Murdoch, not Anderson.  Second, the = chapter referenced doesn=E2=80=99t go into any detail about take downs. =  There are better more specific references such as Moore and = Clayton, and specifically =E2=80=9CThe Impact of Incentives on Notice = and Take-down=E2=80=9D, WEIS 2008, although I would imagine that there = is even later work available.

Ah, will fix to get the order of authors = right and you=E2=80=99re right that it doesn=E2=80=99t go into any = detail. Here we were looking for something that actually went into = physical seizure of server hardware or seizure of entire logical = entities (instead of notice and takedown, the next section, which is = often directed at individual pieces of content or a single domain on a = webserver). I=E2=80=99ll check out the citation above and citations = since and see if we can=E2=80=99t get better pointers in there (this = section is obviously to be complete and quite svelte).


Ok.  That sounds like a classic asset seizure. =  It may be worth expanding on how and when physical asset seizure = is effective, especially in a cloud-based world.


Finally, did I miss the part where one discusses domain name = takedowns by registry, or has that not been used as a form of = censorship?


We can add it if you = have citations. Would love a PR of course or suggested = text.

I guess I = would suggest starting with the references in guidance-domain-seizures-07mar12-en.pdf.

Eliot


Eliot

-- 
Pearg = mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg

-- 
Joseph Lorenzo Hall, Senior Vice President, Strong = Internet
hall@isoc.org | +1-703-483-9504
internetsociety.org | @internetsociety
pgp: https://josephhall.org/gpg-key
3CA28D7B9F6DDBD34B1016075F86698740A9A871

= --Apple-Mail=_BBF114DE-63B2-4C07-A354-42E4FDED2053-- From nobody Wed May 27 04:07:15 2020 Return-Path: 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 123B13A0D87 for ; Wed, 27 May 2020 04:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 hCFua_GNhvpj for ; Wed, 27 May 2020 04:07:11 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2050.outbound.protection.outlook.com [40.107.93.50]) (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 B3E783A0D8C for ; Wed, 27 May 2020 04:07:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zdl9d/bi1VV4t9wymH8j0k05ZDjxGH7p8doPlgOnRmqd0wovNAjTuJq1HpO05mFjfFF+XOZWdi3SVLJGuEr+tBMPJYJjFS85x6NbPiI28Qpwr7NqpsRxtBFsMFIqkKpwvdIeLVLMNsp8WmBr3s7m0j+wA1R4VS7jKRrhipOrIUPsZF2WnJT+/bKGBjzx9wnCSM6f5koD6YpRQS7Mrd6xeV8TduZzzop5YbUxqARve2M4IZCAX3UugMpT1OeIFzXYp0E8cjDwpe03BpyyUxUETuSWYgKrr9apn7HzNdp6fWWlw7sWBhIfc3t3VTZx33PJs3+CwZsdCPgKbCh7Vuw+RQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K53us3HsTwhlhJjU4g1C2kcHqyIs3LIvyBM337HrFQI=; b=g9kf/EaQtfpUzNWyl5iS8pe9TQckX9ArCqFYUya+9KWnsMhEgrdCU44JOqeYnb7dfqgBijdR6yZAU4ZIJ/9DdFld5TjTY41sPMqJ025SKQLWErCzBtZGBgmHGLjJpFCX0kVKVmv2o36foJuX8p4aYdRcLW4X7Rtpxa2Pgm8L6k+SP44K2VnpkGOilrHlqoOnW/BxJHmNoSXcy8eWW0IIeVwfc5/EYVBaRS3xdv8S/TC47esUoc9kNNOVUmQyvQ7esqkexGN5hcSvfoMlghenH2w7F+Ati0KdVkoPfKK3cgeQLhKHUwcmkgu+d+h8zMdCyvwpIVsP6SfPj1PgHDXrsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K53us3HsTwhlhJjU4g1C2kcHqyIs3LIvyBM337HrFQI=; b=2Gf8GRY2Rf2DlF5lBEV4WGxkWtjCkpJqAX1KJD4kAe1Fhdh/UF4/fveOVhp6nUZkVfac45OL5TzknNZHOF+62u5IPmT0MogRjFtS7ZSeQb/dk6XiEYBbCPwlgqCWV72LAlGKbU+voweYnFbcNmg1UZbQJ8aMsbZ6yFR51TuQwdg= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BY5PR06MB6692.namprd06.prod.outlook.com (2603:10b6:a03:238::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Wed, 27 May 2020 11:07:03 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5%5]) with mapi id 15.20.3045.018; Wed, 27 May 2020 11:07:03 +0000 From: Joseph Lorenzo Hall To: Eliot Lear CC: Christopher Wood , "pearg@irtf.org" Thread-Topic: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" Thread-Index: AQHWLsgqnBPhO5w6N0yNNHBtsaHVYqi6K/EAgADpJgCAAKT1gIAAFciO Date: Wed, 27 May 2020 11:07:03 +0000 Message-ID: References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org>, <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> In-Reply-To: <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=isoc.org; x-originating-ip: [108.28.51.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e5634880-2aff-4b66-c949-08d8022e1628 x-ms-traffictypediagnostic: BY5PR06MB6692: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04163EF38A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xqaS6iTB/ZEteTf7z3sc6dlhWByVX0bz7ZzPoMZhBDQqhreWgn1kfmtNlxtFjPLAP9n7m6t6Bbd90cECrVpb7cheDt9aKpJmF1mPowYTDQwxvdQJ/T0mgwEB8Dgk5rZuh1JSl61WJmdu4cet1efj/N33sTubFWnubHLmH9wB2I0mB4W9MaXHTkpc9p+Q/WnhOIvPk8tA+62VrizaI+rhs0JJsfDygLcTdf6u+J3mbGYATbuDC5go50FT+Jm6h7n98dtUyCC0WM9Q29jC3ffewNbVk5SU9f89Hmy+GCj267BtYYVkBarKJ2AZ0DUrlhOvdVeFaizPFPtSWEx1BC4SZshkNeu0CxVLPnRPsxforQGf+NN1cu7V+em+Fh47WZPD3+LsNhwMKg49tRyyKGay9A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(346002)(39840400004)(136003)(396003)(366004)(66476007)(166002)(71200400001)(66574014)(966005)(6916009)(316002)(66446008)(33656002)(9686003)(5660300002)(64756008)(54906003)(52536014)(55016002)(478600001)(2906002)(66556008)(86362001)(83080400001)(8676002)(66946007)(76116006)(7696005)(4326008)(6506007)(8936002)(53546011)(26005)(186003)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: JiswLOSwcQ7atQsp3NUNdXJGbe+11IoU6cbejOq4bTQ1sI7c47NujNK7MRn8srxqFRLvq9tA6HUY8hz6aIhbXIFg6yagPSml6hFw9eHdTuR845Ij/w6qZ0uGCFtuIbm0kUsOh0ce7i53YzqABTTtZ4AWw5/lLqmVNbbpd/aQmVKZAXJnnlgRobsCFf+JNK29+4UcIk5HfMRcxi6OeqDQeGE2i+yn+xz3HbXcY22q3W6NolDpHgcrJ8EgFmSkqCXFj4+OagWhBPLtNpHSDQ1yu1LspM/Ri1adkXMSc9kDRavm89w+CC0z0Gt8hI+faVkwtmK1ItLIAFNj8/SWBc4GIUoa/v8+mdTz/3PibHet2OF8VG7j0kG7GDGayJqjPoA856jkHKEQCZ29A/ox6YjW0HZ/5xaSDvrMbM2AD8eP6YT/0bd7l7tb5nQFk84VVzq3/gRxmM0vRM1JWMMVGflh37Tx7safhBBqIMHcdnlJACccZgOUnhK2wJ+vy03FqCK8 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR06MB645135B492365576B0C3E2C8B1B10BY5PR06MB6451namp_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: e5634880-2aff-4b66-c949-08d8022e1628 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2020 11:07:03.5751 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: F0UpQ12HRNKS/1D+Tld6vbETQZDgf4K40fM/JOxoMRtJQKftSHLb2Z6OcjN1yyhn X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6692 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 11:07:14 -0000 --_000_BY5PR06MB645135B492365576B0C3E2C8B1B10BY5PR06MB6451namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry, I didn't mean anything prescriptive by "information flows"... "traff= ic flows" is better. Sorry for any confusion. ________________________________ From: Eliot Lear Sent: Wednesday, May 27, 2020 5:47:17 AM To: Joseph Lorenzo Hall Cc: Christopher Wood ; pearg@irtf.org Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Ce= nsorship Techniques" Hi Joe, I want to emphasize what Mallory just said in a message to this thread: ent= ities adversarially messing with information flows is censorship (that is p= erhaps too pithy for our purposes!). To me at least, =93information flows=94 immediately improves the situation.= No one can claim that a DOS attack, or a cyberattack of any kind, is an i= nformation flow. One can reasonably argue that spam is not an information = flow. Moreover, the term seems to fit your draft well. Also, it seems to me that a reference check is in order. If we look at Sec= tions 6.2 and 6.3 the authors are discussing various forms of takedowns, an= d a reference is made to [Anderson-2011]. To begin with, as a nit, the fir= st person on that work is Murdoch, not Anderson. Second, the chapter refer= enced doesn=92t go into any detail about take downs. There are better more= specific references such as Moore and Clayton, and specifically =93The Imp= act of Incentives on Notice and Take-down=94, WEIS 2008, although I would i= magine that there is even later work available. Ah, will fix to get the order of authors right and you=92re right that it d= oesn=92t go into any detail. Here we were looking for something that actual= ly went into physical seizure of server hardware or seizure of entire logic= al entities (instead of notice and takedown, the next section, which is oft= en directed at individual pieces of content or a single domain on a webserv= er). I=92ll check out the citation above and citations since and see if we = can=92t get better pointers in there (this section is obviously to be compl= ete and quite svelte). Ok. That sounds like a classic asset seizure. It may be worth expanding o= n how and when physical asset seizure is effective, especially in a cloud-b= ased world. Finally, did I miss the part where one discusses domain name takedowns by r= egistry, or has that not been used as a form of censorship? We can add it if you have citations. Would love a PR of course or suggested= text. I guess I would suggest starting with the references in guidance-domain-sei= zures-07mar12-en.pdf. Eliot Eliot -- Pearg mailing list Pearg@irtf.org https://www.irtf.org/mailman/listinfo/pearg -- Joseph Lorenzo Hall, Senior Vice President, Strong Internet hall@isoc.org | +1-703-483-9504 internetsociety.org | @internetsociety pgp: https://josephhall.org/gpg-key 3CA28D7B9F6DDBD34B1016075F86698740A9A871 --_000_BY5PR06MB645135B492365576B0C3E2C8B1B10BY5PR06MB6451namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Sorry, I didn't mean anything prescriptive by "inform= ation flows"... "traffic flows" is better. Sorry for any con= fusion.
From: Eliot Lear <lear@c= isco.com>
Sent: Wednesday, May 27, 2020 5:47:17 AM
To: Joseph Lorenzo Hall <hall@isoc.org>
Cc: Christopher Wood <caw@heapingbits.net>; pearg@irtf.org <= ;pearg@irtf.org>
Subject: Re: [Pearg] Research Group Last Call for "A Survey of = Worldwide Censorship Techniques"
 

I want to emphasize what Mallory just said in a message to = this thread: entities adversarially messing with info= rmation flows is censorship (that is perhaps too pithy for our purposes!).<= /span>

To me at least, =93information flows=94 immediately improves the situa= tion.  No one can claim that a DOS attack, or a cyberattack of any kin= d, is an information flow.  One can reasonably argue that spam is not = an information flow.  Moreover, the term seems to fit your draft well.


Also, it seems to me that a reference check is in order. &n= bsp;If we look at Sections 6.2 and 6.3 the authors are discussing various f= orms of takedowns, and a reference is made to [Anderson-2011].  To beg= in with, as a nit, the first person on that work is Murdoch, not Anderson.  Second, the chapter referenced doesn= =92t go into any detail about take downs.  There are better more speci= fic references such as Moore and Clayton, and specifically =93The Impact of= Incentives on Notice and Take-down=94, WEIS 2008, although I would imagine that there is even later work available.

Ah, will fix to get the order of authors right and you=92re right that it d= oesn=92t go into any detail. Here we were looking for something that actual= ly went into physical seizure of server hardware or seizure of entire logic= al entities (instead of notice and takedown, the next section, which is often directed at individual pieces of content = or a single domain on a webserver). I=92ll check out the citation above and= citations since and see if we can=92t get better pointers in there (this s= ection is obviously to be complete and quite svelte).


Ok.  That sounds like a classic asset seizure.  It may be worth e= xpanding on how and when physical asset seizure is effective, especially in= a cloud-based world.


Finally, did I miss the part where one discusses domain nam= e takedowns by registry, or has that not been used as a form of censorship?=


We can add it if you have citations. Would love a PR of cou= rse or suggested text.

I guess I would suggest starting with the references in guidance-domain-seizures-07mar12-en.pdf.

Eliot


Eliot

-- 
Pearg mailing list
Pearg@irtf.org
https://= www.irtf.org/mailman/listinfo/pearg

-- 
Joseph Lorenzo Hall, Senior Vice President, Strong Internet
hall@isoc.org | +1-703-483-9504
internetsociety.org<= span class=3D"x_Apple-converted-space"> | @internetsociety=
pgp: https://jos= ephhall.org/gpg-key
3CA28D7B9F6DDBD34B1016075F86698740A9A871

--_000_BY5PR06MB645135B492365576B0C3E2C8B1B10BY5PR06MB6451namp_-- From nobody Wed May 27 07:53:27 2020 Return-Path: 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 6C4403A0E80 for ; Wed, 27 May 2020 07:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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, 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 ePXTymTHVlHw for ; Wed, 27 May 2020 07:53:22 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E539A3A0C19 for ; Wed, 27 May 2020 07:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=302; q=dns/txt; s=iport; t=1590591202; x=1591800802; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=116rXcEvH+elgBUFHT9N5CrfrH56S1C+1L07DCU2VHk=; b=Hq90c+se3+tw+OeA/vuzyYSHmyc7ynJiMeasyfBvIdLtt0SZbJZj0rjb tY+uKvNz7V6DOv+UselzlSbIF9uKxWnZJ7HidLkt7QNP8sDHIrEJO8KPq 2pXlutYIrVZC2eahK+M5TlR7A9m96G0cRAK78yb283ZZklfv5xBBAkQVX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVAwAOfs5e/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqDbAEgEiyNJogHm2wLAQEBDAEBLwQBAYREAoIVJTgTAgM?= =?us-ascii?q?BAQsBAQUBAQECAQYEbYVjhXIBAQEBAgEYBR0/BQsLGC5XBhODJoJdIK1QdIE?= =?us-ascii?q?0hVGFI4E4iXiCZoIAgTgcgh8uPoROhXQEsy+CXoJ1lWsdglMBjXaNPqpyg0k?= =?us-ascii?q?CBAYFAhWBaiKBVjMaCBsVZQGCPj4SGA2QeI4SPwMwNwIGCAEBAwmNNwEB?= X-IronPort-AV: E=Sophos;i="5.73,441,1583193600"; d="scan'208";a="26560145" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 May 2020 14:53:17 +0000 Received: from [10.61.225.84] ([10.61.225.84]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04RErGrk011342 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 May 2020 14:53:17 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: Date: Wed, 27 May 2020 16:53:15 +0200 Cc: Christopher Wood , "pearg@irtf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4D492A3A-E8E1-4E6E-8BCC-1022979037AC@cisco.com> References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> To: Joseph Lorenzo Hall X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.225.84, [10.61.225.84] X-Outbound-Node: aer-core-1.cisco.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 14:53:26 -0000 > On 27 May 2020, at 13:07, Joseph Lorenzo Hall wrote: >=20 > Sorry, I didn't mean anything prescriptive by "information flows"... = "traffic flows" is better. Sorry for any confusion. Then I have to ask my question again: is stopping a DOS attack = censorship? Eliot= From nobody Wed May 27 08:10:50 2020 Return-Path: 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 B0A683A0F07 for ; Wed, 27 May 2020 08:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 VxkmQIVcI-Xs for ; Wed, 27 May 2020 08:10:47 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2075.outbound.protection.outlook.com [40.107.220.75]) (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 485173A0EF5 for ; Wed, 27 May 2020 08:10:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P23o/COEyj7e+cGe2mA/GC1r4qEjOhwhBAxa7G9FeY7bCHu6LZL5jnaY35rZu+h08gsBcR7Y8DoTAaaGpDV4ZZtQ1FBB1RrTmwoV/gn1r/FkPDvOM/ZvFLq92nxYw6o8rKyF7PicMe1zg3vIke7vHYN31mCmgfW9xVxFl/7bzDqyGUo/E0qZJp25OXmKeZocRXbdVJs2wikZVVgbPZxAs/H+2z9oZjpzZ6uDHpjsMySKInGA8A22wnyk+PzxDwTM6zIoMxB6qQO5CyFVylpxsvm1hajTiRGnDsqr7p7aYJ0LaWDRhetOWclzKPyGIlXlcOoOCxhEXQmDalIMFeAf6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r8X5kk76D0j8WFosdH7S9HLgZwnAEJE3gWxgFkFIgYw=; b=UOMa0pQJQ+odg87MlGQ5HSb0Ml8arACJxOEOb7FWsiA3sfbmqvshaI5hKoxqfQFE+y50CHA2iIG8jHb7kT0mCPqiuWL3VWew+7MFSB7Wc6nORNCx4jQjKNcHfBPeXNq4mV224aMqHMp8RR56Frk4spPrX0aWDrkRkIzMGmsdCcLsWKalASaCJGBi32LKLmu5vRNeO2gtg7sfbmzgjBvK0mFGww8KcwfSJzuG3IyCq7NV6EJaycPGyLxtNz41c0FGTe9yjlV3I6tzAncoQclYbmus+tEpGIrd8gjmPNSqQMFinpjUjlSN++M2rLI6AqjuRyzLpsUIkUrgGYbaA3BejQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r8X5kk76D0j8WFosdH7S9HLgZwnAEJE3gWxgFkFIgYw=; b=D4X9aCXDfl+8OY9B9PSfCEJSzZh5E5tcT+Q/268ioj3IaFTgWLi0xuqTjzt47b/HM160cukGvXIcAfz+ik1I3g7J03l/OC1SRbEN9V6peEnS8F/0TqnwB5k9VS2/NLMObmPLKJG8VJRRw4o4YPHHdHMNZDnysj4hWr6CSNahLKc= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BY5PR06MB6690.namprd06.prod.outlook.com (2603:10b6:a03:23b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Wed, 27 May 2020 15:10:46 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5%5]) with mapi id 15.20.3045.018; Wed, 27 May 2020 15:10:46 +0000 From: Joseph Lorenzo Hall To: Eliot Lear CC: Christopher Wood , "pearg@irtf.org" Thread-Topic: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" Thread-Index: AQHWLsgqnBPhO5w6N0yNNHBtsaHVYqi6K/EAgADpJgCAAKT1gIAAFciOgAA/tYCAAATiAA== Date: Wed, 27 May 2020 15:10:45 +0000 Message-ID: <1953AD7E-48A8-4593-B890-E87573A35859@isoc.org> References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> <4D492A3A-E8E1-4E6E-8BCC-1022979037AC@cisco.com> In-Reply-To: <4D492A3A-E8E1-4E6E-8BCC-1022979037AC@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=isoc.org; x-originating-ip: [108.28.51.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ddc5acaf-5fec-45fe-adc8-08d8025021c4 x-ms-traffictypediagnostic: BY5PR06MB6690: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3826; x-forefront-prvs: 04163EF38A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Gwcb7k+9wj11JOyUlD/uaWKb4o50Fc0gUSsdQDg/INSAeVacNdxCDf50zow5Qdtbs3Zm/r8pMIqwLIFCkDa5k8jsEatK7YhOxwd22IvkwXcuSDKSvYIxxPxNmHOuziNBLon7rXw3Qo1oqvmWCcoksbmY+6sb/J4K/m/D9sWXuZaqnzl6e7dQrtqGMfxSBm1jS1hRv7s7DhF/2CCzziCL9vCxK4110uzFIk47SQmw6t4FB4rcIyxg0mpMXReSbhX2Z0EWP8QUVDv4kTmmXG/XdHDi0L7E/DaKKAGDUbqkws/HbLt/oiWEbviGAfgOHbQKq5eE3AYun/O/B5T1udAMT5JYs3+gLi2AXg8AAsgtx9jL0ujWBLiyyAFyS1fWusZtC2r6Aqy5fUhOXdrzwkO5PQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(39840400004)(376002)(346002)(366004)(396003)(26005)(966005)(2616005)(5660300002)(478600001)(6512007)(8676002)(186003)(4744005)(6486002)(316002)(8936002)(2906002)(86362001)(54906003)(83080400001)(71200400001)(66574014)(166002)(36756003)(66556008)(66476007)(6506007)(53546011)(6916009)(76116006)(33656002)(64756008)(91956017)(66946007)(4326008)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: t11gGfQLjEXp5ybLhIBSs/iB86BiOEhGKp7ndulBDRAPFWml3Dr7hKExE+5+nFAxOQhzO8shUt98Ph7p2ZUo6IgFMRVpbaD80ilwMdLzjJaXb8CIb/I5/kEHK/ljkfhlvlgKVQ4cuAKskiwrTZkCfGVInHWiqHTUEAbFKPVNaEAxHJphYyjo37/e6+SufwQMkUyMbIwuMsyGoZdQMVqIxpUOJF6brHPcB76t3sSN/U8hRser/POhipWsDYnf7vcCboyvBoLW8QEagAVgyQtuXFMPr9Bw2y5ICyC/Bh++6RbRV1VkrG3zbNBKzZvLbDv5TdYCdA0z6Sdg6HqdnBWYirp7obpW/jc6RUD4bGgh45qH0dBvKhKFOzxvPe2vu7jp6mqhwUuD4p2baeu5eZ4qs0GVv67BEBB3ZouygP6s9PuUxMUe0Q8/4mO1Egq10buVHZuH9QffECNgVzIdKWsny0BmfYBie1LkbAsZ9Le2bFMxhPOWrUudHOQ5HfvYCQjo x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_1953AD7E48A84593B890E87573A35859isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: ddc5acaf-5fec-45fe-adc8-08d8025021c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2020 15:10:45.8548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SQfH0WaQYU7fzozOhxYzHuSoHv2dqxu+eMkKBluh3FD8igTnqLp/pRDiJYVZZ6x5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6690 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 15:10:49 -0000 --_000_1953AD7E48A84593B890E87573A35859isocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIE1heSAyNywgMjAyMCwgYXQgMTA6NTMgQU0sIEVsaW90IExlYXIgPGxlYXJAY2lzY28u Y29tPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNCg0KT24gMjcgTWF5IDIwMjAs IGF0IDEzOjA3LCBKb3NlcGggTG9yZW56byBIYWxsIDxoYWxsQGlzb2Mub3JnPG1haWx0bzpoYWxs QGlzb2Mub3JnPj4gd3JvdGU6DQoNClNvcnJ5LCBJIGRpZG4ndCBtZWFuIGFueXRoaW5nIHByZXNj cmlwdGl2ZSBieSAiaW5mb3JtYXRpb24gZmxvd3MiLi4uICJ0cmFmZmljIGZsb3dzIiBpcyBiZXR0 ZXIuIFNvcnJ5IGZvciBhbnkgY29uZnVzaW9uLg0KDQoNClRoZW4gSSBoYXZlIHRvIGFzayBteSBx dWVzdGlvbiBhZ2FpbjogaXMgc3RvcHBpbmcgYSBET1MgYXR0YWNrIGNlbnNvcnNoaXA/DQoNClN1 cmUsIEkgZG9u4oCZdCBzZWUgd2h5IGl0IGNvdWxkbuKAmXQgYmUuIEhhdmUgeW91IHNlZW4gTW9s bHkgU2F1dGVy4oCZcyBib29rIG9uIHRoaXM/IEl04oCZcyB3b3J0aCBjaGVja2luZyBvdXQ6IGh0 dHBzOi8vd3d3LmFtYXpvbi5jb20vQ29taW5nLVN3YXJtLUhhY2t0aXZpc20tRGlzb2JlZGllbmNl LUludGVybmV0L2RwLzE2MjM1NjQ1NjUNCg0KSSBkb27igJl0IHRoaW5rIHRoYXTigJlzIGFuIGlt cG9ydGFudCBxdWVzdGlvbiBmb3IgdGhpcyBkb2N1bWVudCwgaG93ZXZlci4gYmVzdCwgSm9lDQoN Ci0tDQpKb3NlcGggTG9yZW56byBIYWxsLCBTZW5pb3IgVmljZSBQcmVzaWRlbnQsIFN0cm9uZyBJ bnRlcm5ldA0KaGFsbEBpc29jLm9yZzxtYWlsdG86aGFsbEBpc29jLm9yZz4gfCArMS03MDMtNDgz LTk1MDQNCmludGVybmV0c29jaWV0eS5vcmc8aHR0cDovL2ludGVybmV0c29jaWV0eS5vcmc+IHwg QGludGVybmV0c29jaWV0eQ0KcGdwOiBodHRwczovL2pvc2VwaGhhbGwub3JnL2dwZy1rZXkNCjND QTI4RDdCOUY2RERCRDM0QjEwMTYwNzVGODY2OTg3NDBBOUE4NzENCg0K --_000_1953AD7E48A84593B890E87573A35859isocorg_ Content-Type: text/html; charset="utf-8" Content-ID: <7C13FCF4CEC4F14E86F22DE04F59B404@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IE1heSAyNywgMjAyMCwgYXQgMTA6NTMgQU0sIEVsaW90IExlYXIgJmx0OzxhIGhyZWY9Im1haWx0 bzpsZWFyQGNpc2NvLmNvbSIgY2xhc3M9IiI+bGVhckBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiAyNyBNYXkgMjAyMCwgYXQgMTM6MDcsIEpvc2Vw aCBMb3JlbnpvIEhhbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpoYWxsQGlzb2Mub3JnIiBjbGFzcz0i Ij5oYWxsQGlzb2Mub3JnPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KU29ycnksIEkgZGlkbid0IG1lYW4gYW55dGhpbmcgcHJlc2NyaXB0aXZlIGJ5ICZxdW90O2lu Zm9ybWF0aW9uIGZsb3dzJnF1b3Q7Li4uICZxdW90O3RyYWZmaWMgZmxvd3MmcXVvdDsgaXMgYmV0 dGVyLiBTb3JyeSBmb3IgYW55IGNvbmZ1c2lvbi48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGVuIEkgaGF2ZSB0byBhc2sgbXkgcXVl c3Rpb24gYWdhaW46IGlzIHN0b3BwaW5nIGEgRE9TIGF0dGFjayBjZW5zb3JzaGlwPzxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlN1cmUsIEkgZG9u4oCZdCBz ZWUgd2h5IGl0IGNvdWxkbuKAmXQgYmUuIEhhdmUgeW91IHNlZW4gTW9sbHkgU2F1dGVy4oCZcyBi b29rIG9uIHRoaXM/IEl04oCZcyB3b3J0aCBjaGVja2luZyBvdXQ6Jm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly93d3cuYW1hem9uLmNvbS9Db21pbmctU3dhcm0tSGFja3RpdmlzbS1EaXNvYmVkaWVuY2Ut SW50ZXJuZXQvZHAvMTYyMzU2NDU2NSIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuYW1hem9uLmNvbS9D b21pbmctU3dhcm0tSGFja3RpdmlzbS1EaXNvYmVkaWVuY2UtSW50ZXJuZXQvZHAvMTYyMzU2NDU2 NTwvYT4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkkgZG9u4oCZdCB0aGluayB0aGF04oCZcyBhbiBpbXBvcnRhbnQgcXVlc3Rp b24gZm9yIHRoaXMgZG9jdW1lbnQsIGhvd2V2ZXIuIGJlc3QsIEpvZTwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0 byIgc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0idGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtp dC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNz PSIiPg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJ0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0 byIgc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0idGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtp dC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNz PSIiPg0KPGRpdj4tLSZuYnNwOzxiciBjbGFzcz0iIj4NCkpvc2VwaCBMb3JlbnpvIEhhbGwsJm5i c3A7U2VuaW9yIFZpY2UgUHJlc2lkZW50LCZuYnNwO1N0cm9uZyBJbnRlcm5ldDxiciBjbGFzcz0i Ij4NCjxhIGhyZWY9Im1haWx0bzpoYWxsQGlzb2Mub3JnIiBjbGFzcz0iIj5oYWxsQGlzb2Mub3Jn PC9hPiB8ICYjNDM7MS03MDMtNDgzLTk1MDQ8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwOi8v aW50ZXJuZXRzb2NpZXR5Lm9yZyIgY2xhc3M9IiI+aW50ZXJuZXRzb2NpZXR5Lm9yZzwvYT4gfCZu YnNwO0BpbnRlcm5ldHNvY2lldHk8YnIgY2xhc3M9IiI+DQpwZ3A6Jm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly9qb3NlcGhoYWxsLm9yZy9ncGcta2V5IiBjbGFzcz0iIj5odHRwczovL2pvc2VwaGhhbGwu b3JnL2dwZy1rZXk8L2E+PGJyIGNsYXNzPSIiPg0KM0NBMjhEN0I5RjZEREJEMzRCMTAxNjA3NUY4 NjY5ODc0MEE5QTg3MTwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1953AD7E48A84593B890E87573A35859isocorg_-- From nobody Wed May 27 16:46:19 2020 Return-Path: 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 620093A0DAE for ; Wed, 27 May 2020 16:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cis-india.org 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 2zsSXAB_LVa6 for ; Wed, 27 May 2020 16:46:16 -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 61EFA3A0DB0 for ; Wed, 27 May 2020 16:46:15 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1je5kR-0006C8-3s; Thu, 28 May 2020 01:46:12 +0200 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cis-india.org C5B4458310005 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cis-india.org; s=6F901CFA-19A8-11E9-98F1-CB07954443DB; t=1590623170; bh=qqasDi2T7HKU24Jk5O53k+uIRHEpADOqsvMAwfM/gHs=; h=To:From:Message-ID:Date:MIME-Version; b=BbrXjtrDExmJZCvqT6hU0jFikBOfo7mognilzfah4maQVATlqdtLOa9BfaXPQ7+ZD FPOHo0DtWXmnWKsiqRDAELs+1WtBZrSHtSP7FPoLQxUBW7j6gQzuF/HiM+bvTEMQyA qdBXS7Ux7D6rz4fdGBY6qsmZ12vj0kOzyCCmdmSo6ffnE2HxlzX2Ilm4cqvjcOEEK1 GwbWaEjSotQkhRgX1srLLFvRzB5tPNwC1tHT6i0FcShx882OmeBaU1qI5n5neWgOO/ gOFGqgDogXSOTODk0ZER1Sluk/jKnSbp547E3Rpi7dNkBckS4c+3IG0GAY8q5grxPX Exwe/PeSxNRTA== To: Mallory Knodel , Eliot Lear Cc: pearg@irtf.org References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <695aca5d-e855-b7a0-e22c-b2aa927941a2@cdt.org> From: Gurshabad Grover Autocrypt: addr=gurshabad@cis-india.org; keydata= xsFNBFriroIBEADfyDpCD8eborMUMXKtZzjo4t2KzrAlUVYgE/TFtrwUP+4Xw4dzakDIzST8 sVYmlXIWhM5NBBTZSQ190vsxrkbi0xxLcXYM2olZEtqkJ8zONZeZLBeGvcfMymtHqD4jHwYb Zm7OXnS45fWDL+HOoMP/VCwEn098rYfnllIkYQD1Gc28Ig+ywjGg8y5p0qMmmmhm2ckgLjnG MJX8t273MSc8wsn/UYH922yif3MQXmrzqgnRl9hRzf90SKqAw38bw7wccb55pIItloKYsi0r zYBKJSOPXn91Z21TpOSTy21M0MZYEAlDn1zeea+q8TggfHNWxOXoKrIm1pqZFRz0k+8i2siJ AHf8bRm/fhukA6szZ6b2nNPxjkAmOv9zvGu6RZGbmeLvQYVBSSnZ67ayZrkKwn7KIyAV6hQM /bVnD8eEZ2tZ0S8lxoZFYSNeMGt2b6WelFZO97/LbjxaJUHd9K8g5H0MwqN1NXoBxRwllVRC 3sVHVoWTBqnKo8qplzvQEAto69PpvuxxKTOFEJeQqmn1b/fo3sLRb4YiIg8Ax+Np7Huzzjk6 vKKgpIwIN7yEUj/ReWi/UA/W4wSg3XkcqTf7h73crnN/1At0PdgozbDV2UbcApaldStP4DfG UiQl0/7MiYLKapDDuSahmoeH3xrNnrzS9BAfuGHezzDbMyPLXQARAQABzSpHdXJzaGFiYWQg R3JvdmVyIDxndXJzaGFiYWRAY2lzLWluZGlhLm9yZz7CwX0EEwEIACcFAlriroICGyMFCQlm AYAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQrbl/X+ubfC7/bQ//YQv7zqQE433xxsN/ 3GYKoOFccBy3WvV4DxrTskJ3n3k5lfcZolbc8TQksQOTzyerNt2ZA7fsGZa7eFSW+xR4Yq3/ C9o+5FOoHGhyZhb+x17MILhmyvyUNSj7SdKrRISgurMbV2Vv8LxmTcdrK6CdFF6JLH+opzU1 NlRKwZqROPgbYZEB2QFIUbGfgh2I5AXNyV2XbT7fagfkHk+v9AUV7POP2H1+AZ1xq6iFTm2o 9ufNZsp2bInsDohcVBKC3aH2cnFMjvIXpNoUOx8vb5A2xW0aBUTTJDB/uZw53WOg3kehrCNb ZkML3FnDZLRuu1e8DSWmwk5YIoDzt5bMCgfUwb0C6Q+JuM8lC+8CEEa9qamLc+fhvFAzcrWp VWuSaVeLdhe5NxmtlRYNZdGuKy6sRHjwsEWlwzRylhm74fiDR3aA1eIFsfmYLd4z+i1Fp23Y dHJf7/Gor2CmOxphog9DEA9WCuORXfx4De7hoMKwW4gWKw1A8B12Cv4EOkXmCsWsOnfDEarr 2Yl6elxkhQRfKjAesXb0cezRzZgwsWIsbeYsuWFF7Xi6IzUJ27lxU3p5PcyY8O8aDYOn+pu0 YFJ7s3u2VRRgptVZJmkcN3WTApXSHY8fGl5xAakM/bqFJj9uj5zlMnFN2EplC6/mQkfYfy2f siaGTP/GQV4OSuOeuMLOwU0EWuKuggEQAJ4lAzB72gHw4+rbyxmQNNVmvgYVZPjFtO/MQdYi x1QwRP/gxxqPqTd/ZwQvmPGzXRKw10B7uKSRk6YP12+IG0mXJwHGp9q5CWJE0XNGqX3UWbAc KIzxqPNpsf8e6Bv7jdW0YwLBxJ+RW0NNL6uAxz0sr2frbnS+EZB3cU+zOZzp/9YfTUZO2lxF NzgJoErKe/HLp7aBeJXBBcwO0LQlIT80rTZx2KihBa/Ww/y9E9gV/HacJu/Ncb6E/G3e4xGj 9w9L+UW43q01wy+FSUKy9FLc7D40WqQsj8SXZEpl84SyLcJRoX3mtj59bX2SAN2VB2BAksTu qCh00IcIUGfyHziu5PwUWYM96gOhDSocP4wSeiQ8TwLzaffllz2qhdI296a9lCIYIeWVytEd NU9jJ3RbzXAgE0pnDauNXDaQv1FS5jYi8rlslJUxKnrS69BFNjM5RqQ16Cm0C4rKL7/a8wHC r4VjcjSCM8Lzv8YOOitJ9Yt4Y8SVfO5s3YvxcdSr56nX0W3B1kGbG1GpqWTzOgXzGF5bIsbV 7SPecwUs9ShvmLmZzDUxIQ68n4zj3lMZn5I+pP+Ew6nAAiuSmKdr5cygnCH/NVJzil07t+X4 uR6oKHBhuMFYF1c6Wxk36m+EZz5ZHFaT4rN0WDIJdAEqRzD0Z56V6ansDF8y+ksh0SHlABEB AAHCwWUEGAEIAA8FAlriroICGwwFCQlmAYAACgkQrbl/X+ubfC50rhAAloTaq/fZC1gtiVtU wOB+00gEkjgmzt+rLkW+l2EySTST7tje57W83UZwzCX746B2O//Bqardxz9R1Vr0VFiwHA8g 3qeBqPqiv1WoQch/iZ5d/1MxK4A9xDag1uyqLR8RuGlZ8lATmcP3IabKiuiBV4MlFZ7V2Ib6 5ToPf28xxSyjMzTjQObIG0e009uHlu2z+iQVshLyoyVVAOWWa88D6iuBDC/EtBRjlpjLAjuR YhWVYX6KHdVUijKMHN2RqjpX5O2wPL7NcMY/wsTq7EteUeI75hxFvargRXkEt1XR8t52LC0u IE2OjpzY5re/ROUbfsqL8trjAOrSJ+Fx5H8AYl9JaoVxohhxDZgNtgNtPbh/8Nnlf9daj/bh lZcTBO98XLQwMnyHGPdyhIodpWPq2C09Ys3TkQsbcdMMB1pqnEK5Vz1zIKkEEX7QVsLdrz7C 2CFsauc/9PHj+4njCHslXtzBOiVu5FXTnbCwPrLJs5iEUkUCb6qtE/2mSCTrAanzOTTOmqiM cnNTI1Tj0ht462S9VypppQnKCv8shGxXG7BadZTv+pNCA/WfB2kk1sS3ZwB0wBWX4p41fxs+ ArM9ew2SzQ/vBrEfO7ljPfZZmBqH4t/vgAZBnOtTxCGlPEIJqiMqtGHRqIqpiR20QfxEUuXI MfMfa9QJpisdNmqoUyc= Message-ID: Date: Thu, 28 May 2020 05:16:03 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <695aca5d-e855-b7a0-e22c-b2aa927941a2@cdt.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 8b3222cd26cce149ddb9ffa05c4da76e Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 23:46:18 -0000 On 5/27/20 2:07 AM, Mallory Knodel wrote: > On 5/26/20 3:46 PM, Eliot Lear wrote: >>> On 26 May 2020, at 19:04, Mallory Knodel wrote: >>> On 5/26/20 6:02 AM, Eliot Lear wrote: >>>> I have a concern about the use of the term =E2=80=9Ccensorship=E2=80= =9D.=C2=A0 Is removal >>>> of fraudulent material censorship?=C2=A0 How about taking down a sys= tem >>>> that part of a DOS attack?=C2=A0 Is taking down a system that is >>>> attacking critical infrastructure censorship?=C2=A0 Is botnet disrup= tion >>>> censorship?=C2=A0 Are FCC frequency rules against harmful interferen= ce >>>> censorship?=C2=A0 By the sweeping definition given, they are.=C2=A0 = This=C2=A0 >>>> immediately diminishes the credibility of the work because it flies >>>> in the face of what normal people think censorship is. >>> Second it is strategic to define censorship as any restriction on >>> content so as to raise the cost. Because while there are indeed >>> recognized legal, legitimate and proportional reasons why the rights >>> to free expression and to access information should be violated, >>> censorship measures should not be taken without careful consideration >>> as it is a human rights matter. >> But the definition in the doc is so broad as to vary substantially >> from its commonly understood pejorative meaning without any foundation >> or qualification.=C2=A0 That gives governments license to say, =E2=80=9C= It=E2=80=99s okay >> to censor sometimes: it=E2=80=99s necessary for our national defense!=E2= =80=9D=C2=A0 That >> is where the definition leads when it includes BOTNET/DOS mitigation. >> > I prefer this to a government saying, "It's okay because what we're > doing isn't even considered censorship," which is what happens when we > get too scared to call some forms of content control what they are: > censorship. >=20 Agree with everything Mallory has said on this thread. From nobody Wed May 27 23:38:55 2020 Return-Path: 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 3447D3A0B33 for ; Wed, 27 May 2020 23:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 JYZBGdutX1D7 for ; Wed, 27 May 2020 23:38:51 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEA83A0B32 for ; Wed, 27 May 2020 23:38:49 -0700 (PDT) X-Originating-IP: 212.76.239.56 Received: from [192.168.0.233] (cable-212.76.239.56.coditel.net [212.76.239.56]) (Authenticated sender: amelia@andersdotter.cc) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 109DAE0006 for ; Thu, 28 May 2020 06:38:46 +0000 (UTC) To: pearg@irtf.org References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> <4D492A3A-E8E1-4E6E-8BCC-1022979037AC@cisco.com> <1953AD7E-48A8-4593-B890-E87573A35859@isoc.org> Reply-To: amelia.ietf@andersdotter.cc From: Amelia Andersdotter Message-ID: <1373bd2f-e739-2e8b-59a2-569a28e2c28b@andersdotter.cc> Date: Thu, 28 May 2020 08:37:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <1953AD7E-48A8-4593-B890-E87573A35859@isoc.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 06:38:53 -0000 On 2020-05-27 17:10, Joseph Lorenzo Hall wrote: > > >> On May 27, 2020, at 10:53 AM, Eliot Lear > > wrote: >> >> >> >>> On 27 May 2020, at 13:07, Joseph Lorenzo Hall >> > wrote: >>> >>> Sorry, I didn't mean anything prescriptive by "information flows"... >>> "traffic flows" is better. Sorry for any confusion. >> >> >> Then I have to ask my question again: is stopping a DOS attack >> censorship? > > Sure, I don’t see why it couldn’t be. Have you seen Molly Sauter’s > book on this? It’s worth checking > out: https://www.amazon.com/Coming-Swarm-Hacktivism-Disobedience-Internet/dp/1623564565  > > I don’t think that’s an important question for this document, +1 best regards, Amelia > however. best, Joe > > --  > Joseph Lorenzo Hall, Senior Vice President, Strong Internet > hall@isoc.org | +1-703-483-9504 > internetsociety.org | @internetsociety > pgp: https://josephhall.org/gpg-key > 3CA28D7B9F6DDBD34B1016075F86698740A9A871 > > From nobody Thu May 28 02:29:39 2020 Return-Path: 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 BB5AD3A0CE7 for ; Thu, 28 May 2020 02:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.957 X-Spam-Level: X-Spam-Status: No, score=0.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_PHARMACY=1, ONLINE_PHARMACY=0.65, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_VISIT_PHARMA=1.406, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 EhSTaFSlOmrV for ; Thu, 28 May 2020 02:29:36 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 157783A0CEB for ; Thu, 28 May 2020 02:29:36 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id DB65B6A305; Thu, 28 May 2020 11:29:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1590658172; bh=0uKF9ZtVbcoXsHtAFMoAUNrE9TRlJKI88rDWouI2vM4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=dyAaht1bna/dvIw5hV12Y7m62v/I/UdDt3pE42DM8Jdove0jB+7kk4SeeDpyPxwvz dchrUP+lwxM73+urV0xFhKsR/WPUp9qa92KCkZQKirQppaY9MZSYFtemPEUauNXzmJ pFw/nmCOp76hA0Kt1I9lEZpJ08mXXSCe+FYtG78X6cAd0RAGpcMlG24jcPfBjZ7Jkv V8wkX0MQVHHZIW1h/xNnUxGWVBbW8PUEbpMWZhZWHQayCSJDmdQtx2YBya4+2dH3Xv r/9IQU6YcdHOQAA3uP7fK5X6GyjepiasNnvM3y9z4cXmb7kpwM3rm1sk4COpiTvEH6 MBMgTE+uN5suA== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id CD5C73C01B9; Thu, 28 May 2020 11:29:32 +0200 (CEST) Date: Thu, 28 May 2020 11:29:32 +0200 (CEST) From: Vittorio Bertola To: Eliot Lear Cc: pearg@irtf.org Message-ID: <455744305.5725.1590658172742@appsuite-gw2.open-xchange.com> In-Reply-To: References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 09:29:38 -0000 > Il 26/05/2020 12:02 Eliot Lear ha scr= itto: >=20 > I have a concern about the use of the term =E2=80=9Ccensorship=E2=80=9D. = Is removal of fraudulent material censorship? How about taking down a sys= tem that part of a DOS attack? Is taking down a system that is attacking c= ritical infrastructure censorship? Is botnet disruption censorship? Are F= CC frequency rules against harmful interference censorship? By the sweepin= g definition given, they are. This immediately diminishes the credibility= of the work because it flies in the face of what normal people think censo= rship is. Sorry for missing this thread in the last couple of days. I made this same = objection a year ago or so. This pretty maximalist definition of censorship= (by the way, sourced from Wikipedia) is IMHO still a big problem with this= document.=20 Almost no one outside of digital rights activism circles would say that blo= cking a DDoS attack or taking down a botnet-infected server is censorship. = Many would also not say that removing an unlicensed online pharmacy or an i= llegal gambling website is censorship. Censorship is when communication is = blocked based on the opinions it carries - and even in that case, many peop= le actually find some instances of censorship justified, such as blocking t= errorist or Nazi propaganda, even in democratic countries.=20 I think that the document conflates two things: one is a technical analysis= of communication-blocking mechanisms, which can be used for "censorship in= the narrow sense" or for other purposes that require interference with com= munications. Another one is an ethical stance on the fact that these mechan= isms are always bad and are to be considered "censorship" in any case.=20 The first thing is fine, but the second is not, as then values come into pl= ay and there are different views on the subject; and I'm not even sure that= deciding whether censorship is good or bad, or what censorship is or is no= t, fits the charter of this group. So, I think that the document should use other terms than "censorship" and = "censors" everywhere, and add an initial discussion on the fact that there = are different purposes for which these techniques are used, and while some = people think that they are always bad, and some people (i.e. authoritarian = regimes) think that they are always good, the broad majority of the planet = would say that they are sometimes bad and sometimes good, requiring a more = specific assessment before taking a decision on whether a protocol should s= upport, circumvent or ignore them. --=20 Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com=20 Office @ Via Treviso 12, 10144 Torino, Italy From nobody Thu May 28 02:56:31 2020 Return-Path: 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 8E4BF3A0D18 for ; Thu, 28 May 2020 02:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.158 X-Spam-Level: * X-Spam-Status: No, score=1.158 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_PHARMACY=1, ONLINE_PHARMACY=0.65, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, TVD_VISIT_PHARMA=1.406, URIBL_BLOCKED=0.001] autolearn=no 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 7vS7-9Nop-T8 for ; Thu, 28 May 2020 02:56:27 -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 6FF9A3A0D16 for ; Thu, 28 May 2020 02:56:27 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jeFGv-0001kp-VL for pearg@irtf.org; Thu, 28 May 2020 11:56:22 +0200 To: pearg@irtf.org References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <455744305.5725.1590658172742@appsuite-gw2.open-xchange.com> From: Niels ten Oever Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <75c0bcb0-d4ae-4d5c-2aac-0c16962841a9@digitaldissidents.org> Date: Thu, 28 May 2020 11:56:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <455744305.5725.1590658172742@appsuite-gw2.open-xchange.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: e462de357cb394d64966911c06262bc8 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 09:56:31 -0000 On 5/28/20 11:29 AM, Vittorio Bertola wrote: > >> Il 26/05/2020 12:02 Eliot Lear ha scritto: >> >> I have a concern about the use of the term “censorship”. Is removal of fraudulent material censorship? How about taking down a system that part of a DOS attack? Is taking down a system that is attacking critical infrastructure censorship? Is botnet disruption censorship? Are FCC frequency rules against harmful interference censorship? By the sweeping definition given, they are. This immediately diminishes the credibility of the work because it flies in the face of what normal people think censorship is. > > Sorry for missing this thread in the last couple of days. I made this same objection a year ago or so. This pretty maximalist definition of censorship (by the way, sourced from Wikipedia) is IMHO still a big problem with this document. > > Almost no one outside of digital rights activism circles would say that blocking a DDoS attack or taking down a botnet-infected server is censorship. Many would also not say that removing an unlicensed online pharmacy or an illegal gambling website is censorship. Censorship is when communication is blocked based on the opinions it carries - and even in that case, many people actually find some instances of censorship justified, such as blocking terrorist or Nazi propaganda, even in democratic countries. > > I think that the document conflates two things: one is a technical analysis of communication-blocking mechanisms, which can be used for "censorship in the narrow sense" or for other purposes that require interference with communications. Another one is an ethical stance on the fact that these mechanisms are always bad and are to be considered "censorship" in any case. > > The first thing is fine, but the second is not, as then values come into play and there are different views on the subject; and I'm not even sure that deciding whether censorship is good or bad, or what censorship is or is not, fits the charter of this group. > > So, I think that the document should use other terms than "censorship" and "censors" everywhere, and add an initial discussion on the fact that there are different purposes for which these techniques are used, and while some people think that they are always bad, and some people (i.e. authoritarian regimes) think that they are always good, the broad majority of the planet would say that they are sometimes bad and sometimes good, requiring a more specific assessment before taking a decision on whether a protocol should support, circumvent or ignore them. > The draft is not a discussion of what is censorship and what is not, it is an overview of censorship techniques. The document clearly defines what definition is uses for censorship, and then uses it to provide an overviews of techniques that are used for it. Seems like a flawless research design. I don't think this draft is the place for a literature review for different defintions and conceptions of censorship. The draft makes no statements about when or where censorship is appropriate, legitimate, or proportionate. And I don't think it should. We have had the discussion about DDoS etc many times in hrpc, so if people enjoy that discussion, perhaps they can read those archives. This draft gives an excellent overview of techniques that are used for censorship, which it tremendously helpful. That does not mean that every time an actor engages in censorship these techniques are used, nor that when these techniques are used, it is automatically censorship. I am tempted to repreat everything Mallory said before, but I for now I will refrain and just say that I agree with her :) Cheers, Niels -- Niels ten Oever Researcher and PhD Candidate Datactive Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Thu May 28 03:15:49 2020 Return-Path: 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 BB7C43A0D26 for ; Thu, 28 May 2020 03:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 pTiqnHeQ3MbW for ; Thu, 28 May 2020 03:15:37 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 548463A0D1E for ; Thu, 28 May 2020 03:15:37 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 1BE096A305; Thu, 28 May 2020 12:15:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1590660935; bh=CVvuiT9ax0hQY2fJ9mYT8p15X9jtbWDNhtdZYvwJmq8=; h=Date:From:To:In-Reply-To:References:Subject:From; b=Et7fDfS1Hx2q1/qntIKcevOOcrylv6DlqdIg7+C/UfBPunbcnWyEUnprWqJ552uJ6 zNyvoOd8zO7S4kW7sK+KrYc7q7w6FVsh5/co+2oq8D3d2no19/cK0BlTsocsH5i9Z4 DEXWgaT9tmuSVsRJhW4Nk2jzmfuYUdxaIjfAXrtpNNHQNgvPXzs1l+JQnaItCrikp7 QGao/CzzX4YEVbUzLJLCQ0Sur4nCV1f2zjdRCFsSLQ3xX/QT4SO3ZzpnV1kDfuz2HZ QifHz+cZTHTq7SAgXqJem87wCz83KbZMAe3L8jPoBqCEOPtjOvmk8X28g2JMh9s2Yl IFQpllnEvnEEQ== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 0D10E3C0382; Thu, 28 May 2020 12:15:35 +0200 (CEST) Date: Thu, 28 May 2020 12:15:34 +0200 (CEST) From: Vittorio Bertola To: Niels ten Oever , pearg@irtf.org Message-ID: <1579895595.5892.1590660934957@appsuite-gw2.open-xchange.com> In-Reply-To: <75c0bcb0-d4ae-4d5c-2aac-0c16962841a9@digitaldissidents.org> References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <455744305.5725.1590658172742@appsuite-gw2.open-xchange.com> <75c0bcb0-d4ae-4d5c-2aac-0c16962841a9@digitaldissidents.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 10:15:48 -0000 > Il 28/05/2020 11:56 Niels ten Oever ha scritto: > > The draft makes no statements about when or where censorship is appropriate, legitimate, or proportionate. And I don't think it should. Except that it calls "censorship" - which is a strongly pejorative term - things that according to many are not, and by doing so, implicitly and without discussion takes a stance that these practices are inappropriate, which is even worse than stating it explicitly with proper supporting arguments. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Thu May 28 03:23:20 2020 Return-Path: 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 F31573A0C7E for ; Thu, 28 May 2020 03:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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 Up7e5cwiLJ6l for ; Thu, 28 May 2020 03:23:17 -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 EA4FF3A0C30 for ; Thu, 28 May 2020 03:23:16 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jeFgt-0008Gf-NC; Thu, 28 May 2020 12:23:12 +0200 To: Vittorio Bertola , pearg@irtf.org References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <455744305.5725.1590658172742@appsuite-gw2.open-xchange.com> <75c0bcb0-d4ae-4d5c-2aac-0c16962841a9@digitaldissidents.org> <1579895595.5892.1590660934957@appsuite-gw2.open-xchange.com> From: Niels ten Oever Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <353091b8-c84c-e02d-c7e0-c524070135b1@digitaldissidents.org> Date: Thu, 28 May 2020 12:23:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <1579895595.5892.1590660934957@appsuite-gw2.open-xchange.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 739ba1b2be5fabc1cc6069058737919f Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 10:23:19 -0000 On 5/28/20 12:15 PM, Vittorio Bertola wrote: > > >> Il 28/05/2020 11:56 Niels ten Oever ha scritto: >> >> The draft makes no statements about when or where censorship is appropriate, legitimate, or proportionate. And I don't think it should. > > Except that it calls "censorship" - which is a strongly pejorative term - things that according to many are not, and by doing so, implicitly and without discussion takes a stance that these practices are inappropriate, which is even worse than stating it explicitly with proper supporting arguments. > I don't think it is, it is a descriptive term. The study of censorship regimes is a whole field in political science and communication. With 'censorship regimes' one does not mean authoritarian regimes, but every authority that sets rules, cultural or social norms on the limitation of the dissemination of information. 'Good taste', for example, is also a censorship regime. -- Niels ten Oever Researcher and PhD Candidate Datactive Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Thu May 28 09:12:02 2020 Return-Path: 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 B57F23A0EEC for ; Thu, 28 May 2020 09:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 MKyzLSA_QovD for ; Thu, 28 May 2020 09:11:58 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2085.outbound.protection.outlook.com [40.107.220.85]) (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 AFAF03A0EEB for ; Thu, 28 May 2020 09:11:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fSSvki/5/tjZqR0wOblL4O2RkCsMEghfX/PvBTeaw3lNAbv+xSZCpi637U/bYHaUs/Lt5bk6TKhPhmR7gVA40vX5uoza4I5aEKxAPzOqzyHGXj4nncf6WU1blCO+BfgwVxiAS6jd8wRL00k3tW+oyCIvCJ7eqbYO2xRPyUJ1bhF3ZoIAuyLYTVrxZAXoYLqb4uXbJzXsq2SPGMQyDa/fS5SpZhJG38IGd9sd7v59mF8ZVh8alf17agEw/r8L+oZYyIE2aNA+wsA52zBhrJXobT3oPDRZe3u7NXnXjqhGamj+4kZBKwLO6DB8VeT54P2WphCLkt7EKgKxZhw/YTmc/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PqGy+rmVb1j6e66HDvQh3EDlZRIa2J2XjwWV/DIORXA=; b=LJcexM1nZyvjtgAYlx9zpBOTyQoUEQf0/GX+2WxeB0CoNaTOzeojoUFQrTrFRCABZ541nJk2kSXcETRQ2FSF2gYtPGzrxCvcXgJOPt9gFpNtzS1R2L50om3WAftA/racm5bLwyqYlqw4SBNTiR7Y3kiDHPO+llgM3gQ5cl/d/DZc16f+4hWiqSyJ6fRUN91tibBzGOv6dA4f0LAyk6DfaKZhqxqsupmpY526QK9cuFjI4HeojKKfCc/qXZ5pWrMt/Ue2qs9ystXVHBzrZ/lkYyqBzzcQLMG63e1173nejdBpTUZCH/yMW1ETMfVAKqOzdJJRH73FjRKIrAHgfcaJjw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PqGy+rmVb1j6e66HDvQh3EDlZRIa2J2XjwWV/DIORXA=; b=NZINMIKvyu46SVS/mWORaZXT0qFrNie5sXTjsjjpYYLyXEVbohnZ7ErZau24lRiIqIzv9X8x/77DlQn0jIY0cVXm5ybdu2d8qorhhl35vHQkCcbwNoAj3wD8Xyb6TkbthT9Nn4LbAR1L8GLZqshDaKLK2pU2WOKSHMae4pUBFmI= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BY5PR06MB6514.namprd06.prod.outlook.com (2603:10b6:a03:235::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19; Thu, 28 May 2020 16:11:57 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5%5]) with mapi id 15.20.3045.018; Thu, 28 May 2020 16:11:56 +0000 From: Joseph Lorenzo Hall To: Eliot Lear CC: Christopher Wood , "pearg@irtf.org" Thread-Topic: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" Thread-Index: AQHWLsgqnBPhO5w6N0yNNHBtsaHVYqi6K/EAgADpJgCAAKT1gIAB/c4A Date: Thu, 28 May 2020 16:11:56 +0000 Message-ID: References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> In-Reply-To: <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=isoc.org; x-originating-ip: [108.28.51.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 734711b5-171f-4946-6f1a-08d80321d832 x-ms-traffictypediagnostic: BY5PR06MB6514: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0417A3FFD2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7WrPo9Uaap8UFoDv8Yp1yPgErEtrl9U1yO/FYxoi9/UPfy+coAicCmLh2WUA8J2/Am3ZgwlJzp9Gh6PoonaR0HWqAFemXHLhodJhc8Ez3X6mfDhuzoPcGIhhHkqbi+4nt179KdV4XObALG4vyS7yOAVhTrCHmjCmrH2Bb9b+rbpjpIueq5els341dpGMLoxvYMPgTWj9iPzxSm+B843MQj3XT3sUPbd+PZW6n+ekscWedw0nO15wFbNdZim0fkUH0qAjjS4w+QFrVnhwWP4gld+L650xitwleQwkYH5O06zgdLwvt1LrjUBUPPAPgJ1s6mKEC0IjX8pjVxWbkEdGo5o07mTpexTrR69++zY1/pkC3uke6KPlRMH6/d3+bdIhlDeo9+8nDNapEwe1OV382+UjAdWcH9tzbYkBTjv1/hhLyoyI5TXYbDx0Rx0ZxWsbfjjn6evSynk+HoFZHO9npF1qHHy+drziXxZylzC5mqQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(39850400004)(136003)(396003)(376002)(366004)(346002)(186003)(83380400001)(33656002)(66574014)(53546011)(166002)(6506007)(8676002)(8936002)(86362001)(6486002)(316002)(6512007)(2906002)(6916009)(4326008)(966005)(478600001)(71200400001)(26005)(54906003)(5660300002)(36756003)(66946007)(66446008)(66476007)(66556008)(2616005)(91956017)(76116006)(64756008)(486264002)(2614002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: MqdRa9iSFI9kS1qYtCkNh4UU3lD5+G54ku7zY93hISjwF9D2QL++2x09Mx2vlvfMsHnLnyv6KyF7CrOEsKT1jDM92V1sMymm9+7rxsuQ/Sh4GG2vHZaSh7o7lvzw81tDOKqsBvC6Fx+cIdxuj8VNA1szyz0kZVjyJ4qmg+DfSg803oxEENLBzOu1yg/Jd/MG3zuTW4gCTBxa8cYQUuJ6FeWsAoQEeuAE3yECeojGeCwB9CO4ofi4w1sxTLQkaMfhb6rTGVVffn9uZSY1ksIsUj873qhLqdc1f+aQiRsaNcPj5wgbrJ/eeWW1zoFDrTc5IXrRoPSDZO6YXmMy/y02D/+p8txzwmXjq4Ig8ciFoYWhReusXLVtb8XQlDtn3PPG+SfQM6uoF/ig+vTpnR5wW+PonHDp+uQaaOUcj9r89Ih1rVWPisUxaLWi3KYs7U8ZOVZ1fLO/SuuToJlrBC0a/6AnsF1YbIJUR2xhvDu4uqS0anel6/JDwn2orRi6yUwK x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_A05941FDA44A41DC90EDE79E6213700Disocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 734711b5-171f-4946-6f1a-08d80321d832 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 16:11:56.7021 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /DmTMlbKUKpVW6W1SfeQheu5lxW84Yncggx069QLXxEKRJSNs/1Bs6wL/C/5Z/Bj X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6514 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 16:12:01 -0000 --_000_A05941FDA44A41DC90EDE79E6213700Disocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIE1heSAyNywgMjAyMCwgYXQgNTo0NyBBTSwgRWxpb3QgTGVhciA8bGVhckBjaXNjby5j b208bWFpbHRvOmxlYXJAY2lzY28uY29tPj4gd3JvdGU6DQpBbHNvLCBpdCBzZWVtcyB0byBtZSB0 aGF0IGEgcmVmZXJlbmNlIGNoZWNrIGlzIGluIG9yZGVyLiAgSWYgd2UgbG9vayBhdCBTZWN0aW9u cyA2LjIgYW5kIDYuMyB0aGUgYXV0aG9ycyBhcmUgZGlzY3Vzc2luZyB2YXJpb3VzIGZvcm1zIG9m IHRha2Vkb3ducywgYW5kIGEgcmVmZXJlbmNlIGlzIG1hZGUgdG8gW0FuZGVyc29uLTIwMTFdLiAg VG8gYmVnaW4gd2l0aCwgYXMgYSBuaXQsIHRoZSBmaXJzdCBwZXJzb24gb24gdGhhdCB3b3JrIGlz IE11cmRvY2gsIG5vdCBBbmRlcnNvbi4gIFNlY29uZCwgdGhlIGNoYXB0ZXIgcmVmZXJlbmNlZCBk b2VzbuKAmXQgZ28gaW50byBhbnkgZGV0YWlsIGFib3V0IHRha2UgZG93bnMuICBUaGVyZSBhcmUg YmV0dGVyIG1vcmUgc3BlY2lmaWMgcmVmZXJlbmNlcyBzdWNoIGFzIE1vb3JlIGFuZCBDbGF5dG9u LCBhbmQgc3BlY2lmaWNhbGx5IOKAnFRoZSBJbXBhY3Qgb2YgSW5jZW50aXZlcyBvbiBOb3RpY2Ug YW5kIFRha2UtZG93buKAnSwgV0VJUyAyMDA4LCBhbHRob3VnaCBJIHdvdWxkIGltYWdpbmUgdGhh dCB0aGVyZSBpcyBldmVuIGxhdGVyIHdvcmsgYXZhaWxhYmxlLg0KDQpBaCwgd2lsbCBmaXggdG8g Z2V0IHRoZSBvcmRlciBvZiBhdXRob3JzIHJpZ2h0IGFuZCB5b3XigJlyZSByaWdodCB0aGF0IGl0 IGRvZXNu4oCZdCBnbyBpbnRvIGFueSBkZXRhaWwuIEhlcmUgd2Ugd2VyZSBsb29raW5nIGZvciBz b21ldGhpbmcgdGhhdCBhY3R1YWxseSB3ZW50IGludG8gcGh5c2ljYWwgc2VpenVyZSBvZiBzZXJ2 ZXIgaGFyZHdhcmUgb3Igc2VpenVyZSBvZiBlbnRpcmUgbG9naWNhbCBlbnRpdGllcyAoaW5zdGVh ZCBvZiBub3RpY2UgYW5kIHRha2Vkb3duLCB0aGUgbmV4dCBzZWN0aW9uLCB3aGljaCBpcyBvZnRl biBkaXJlY3RlZCBhdCBpbmRpdmlkdWFsIHBpZWNlcyBvZiBjb250ZW50IG9yIGEgc2luZ2xlIGRv bWFpbiBvbiBhIHdlYnNlcnZlcikuIEnigJlsbCBjaGVjayBvdXQgdGhlIGNpdGF0aW9uIGFib3Zl IGFuZCBjaXRhdGlvbnMgc2luY2UgYW5kIHNlZSBpZiB3ZSBjYW7igJl0IGdldCBiZXR0ZXIgcG9p bnRlcnMgaW4gdGhlcmUgKHRoaXMgc2VjdGlvbiBpcyBvYnZpb3VzbHkgdG8gYmUgY29tcGxldGUg YW5kIHF1aXRlIHN2ZWx0ZSkuDQoNCg0KT2suICBUaGF0IHNvdW5kcyBsaWtlIGEgY2xhc3NpYyBh c3NldCBzZWl6dXJlLiAgSXQgbWF5IGJlIHdvcnRoIGV4cGFuZGluZyBvbiBob3cgYW5kIHdoZW4g cGh5c2ljYWwgYXNzZXQgc2VpenVyZSBpcyBlZmZlY3RpdmUsIGVzcGVjaWFsbHkgaW4gYSBjbG91 ZC1iYXNlZCB3b3JsZC4NCg0KDQpJ4oCZdmUgZml4ZWQgdGhlIHJlZmVyZW5jZSBhbmQgbWFkZSBz dXJlIHRoZSB0ZXh0IGFja25vd2xlZGdlcyBpdOKAmXMgYW4gaW4tcGFzc2luZyBtZW50aW9uIGFu ZCBpdCBub3cgY2FsbHMgb3V0IGNsb3VkLWxpa2Ugc2l0dWF0aW9ucy4gU2VlIGlmIHRoaXMgd29y a3Mgb3Igc2VuZCBlZGl0cz8NCg0KaHR0cHM6Ly9naXRodWIuY29tL0lSVEYtUEVBUkcvcmZjLWNl bnNvcnNoaXAtdGVjaC9jb21taXQvNjEyMDJmOTM0Njg3NmJhOGQzMTFjMTc4ZTYzMmQ5MzMzYjcw Y2UzYw0KDQoNCkZpbmFsbHksIGRpZCBJIG1pc3MgdGhlIHBhcnQgd2hlcmUgb25lIGRpc2N1c3Nl cyBkb21haW4gbmFtZSB0YWtlZG93bnMgYnkgcmVnaXN0cnksIG9yIGhhcyB0aGF0IG5vdCBiZWVu IHVzZWQgYXMgYSBmb3JtIG9mIGNlbnNvcnNoaXA/DQoNCg0KV2UgY2FuIGFkZCBpdCBpZiB5b3Ug aGF2ZSBjaXRhdGlvbnMuIFdvdWxkIGxvdmUgYSBQUiBvZiBjb3Vyc2Ugb3Igc3VnZ2VzdGVkIHRl eHQuDQoNCkkgZ3Vlc3MgSSB3b3VsZCBzdWdnZXN0IHN0YXJ0aW5nIHdpdGggdGhlIHJlZmVyZW5j ZXMgaW4gZ3VpZGFuY2UtZG9tYWluLXNlaXp1cmVzLTA3bWFyMTItZW4ucGRmPGh0dHBzOi8vd3d3 LmljYW5uLm9yZy9lbi9zeXN0ZW0vZmlsZXMvZmlsZXMvZ3VpZGFuY2UtZG9tYWluLXNlaXp1cmVz LTA3bWFyMTItZW4ucGRmPi4NCg0KT2ssIHRoYXQgd2FzIHF1aXRlIGEgcmFiYml0IGhvbGUuIEni gJl2ZSBiZWVuIGZhc2NpbmF0aW5nIGJ5IGRvbWFpbiBzZWl6dXJlcyBmb3IgYSB3aGlsZSBub3cg KGV2ZXIgc2luY2UgYSBsZWdhbCBjYXNlIGNhbGxlZCwg4oCcVGhlIFN0YXRlIG9mIEtlbnR1Y2t5 IHZzLiAxNDEgZG9tYWluIG5hbWVz4oCdIHdoZXJlIHRoZSBVUyBzdGF0ZSBvZiBLZW50dWNreSB1 c2VkIGl0cyBvd24gYW50aS1nYW1ibGluZyBsYXdzIHRvIHNlaXplIHRoZSBkb21haW5zIG9mIDE0 MSBvbmxpbmUgZ2FtYmxpbmcgd2Vic2l0ZXMpLg0KDQpJIGFncmVlIHRoYXQgdGhlIGRyYWZ0IHNo b3VsZCBtZW50aW9uIHRoaXMuIEhlcmUgaXMgbXkgcHJvcG9zYWwgYW5kIEnigJltIGludGVyZXN0 ZWQgaW4geW91ciAoYW5kIG90aGVyc+KAmSkgZmVlZGJhY2s6DQoNCiogSeKAmWxsIGFkZCBkb21h aW4gcmVnaXN0cmllcyBhbmQgcmVnaXN0cmFycyBhcyBhIOKAnHBvaW50IG9mIGNvbnRyb2zigJ0g aW4gU2VjdGlvbiAzLjEuDQoqIEnigJlsbCBhZGQgYSBwYXJhZ3JhcGggdG8gU2VjdGlvbiA0LjEu MSAob24gRE5TIEludGVyZmVyZW5jZSkgcG9pbnRpbmcgdG8gZG9tYWluIHNlaXp1cmVzIGluIG1h bHdhcmUvYm90bmV0L3NwYW0sIGFudGktZnJhdWQsIGFuZCBpbnRlbGxlY3R1YWwgcHJvcGVydHkg Y2FzZXMuDQoNCkkgd2FudGVkIHRvIHN1bW1hcml6ZSB0aGF0IGJlZm9yZSBhY3R1YWxseSBjaGFu Z2luZyB0aGUgdGV4dCBhbmQgc2VlIHdoYXQgZm9sa3MgdGhpbmsuDQoNCmJlc3QsIEpvZQ0KDQot LQ0KSm9zZXBoIExvcmVuem8gSGFsbCwgU2VuaW9yIFZpY2UgUHJlc2lkZW50LCBTdHJvbmcgSW50 ZXJuZXQNCmhhbGxAaXNvYy5vcmc8bWFpbHRvOmhhbGxAaXNvYy5vcmc+IHwgKzEtNzAzLTQ4My05 NTA0DQppbnRlcm5ldHNvY2lldHkub3JnPGh0dHA6Ly9pbnRlcm5ldHNvY2lldHkub3JnPiB8IEBp bnRlcm5ldHNvY2lldHkNCnBncDogaHR0cHM6Ly9qb3NlcGhoYWxsLm9yZy9ncGcta2V5DQozQ0Ey OEQ3QjlGNkREQkQzNEIxMDE2MDc1Rjg2Njk4NzQwQTlBODcxDQoNCg== --_000_A05941FDA44A41DC90EDE79E6213700Disocorg_ Content-Type: text/html; charset="utf-8" Content-ID: <201BD317B6ADF24DA0B9D27040734ABB@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IE1heSAyNywgMjAyMCwgYXQgNTo0NyBBTSwgRWxpb3QgTGVhciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmxlYXJAY2lzY28uY29tIiBjbGFzcz0iIj5sZWFyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTZweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxNnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPkFsc28sIGl0IHNlZW1zIHRvIG1lIHRoYXQgYSByZWZlcmVuY2UgY2hl Y2sgaXMgaW4gb3JkZXIuICZuYnNwO0lmIHdlIGxvb2sgYXQgU2VjdGlvbnMgNi4yIGFuZCA2LjMg dGhlIGF1dGhvcnMgYXJlIGRpc2N1c3NpbmcgdmFyaW91cyBmb3JtcyBvZiB0YWtlZG93bnMsIGFu ZCBhIHJlZmVyZW5jZSBpcyBtYWRlIHRvIFtBbmRlcnNvbi0yMDExXS4gJm5ic3A7VG8gYmVnaW4g d2l0aCwgYXMgYSBuaXQsIHRoZSBmaXJzdCBwZXJzb24gb24gdGhhdA0KIHdvcmsgaXMgTXVyZG9j aCwgbm90IEFuZGVyc29uLiAmbmJzcDtTZWNvbmQsIHRoZSBjaGFwdGVyIHJlZmVyZW5jZWQgZG9l c27igJl0IGdvIGludG8gYW55IGRldGFpbCBhYm91dCB0YWtlIGRvd25zLiAmbmJzcDtUaGVyZSBh cmUgYmV0dGVyIG1vcmUgc3BlY2lmaWMgcmVmZXJlbmNlcyBzdWNoIGFzIE1vb3JlIGFuZCBDbGF5 dG9uLCBhbmQgc3BlY2lmaWNhbGx5IOKAnFRoZSBJbXBhY3Qgb2YgSW5jZW50aXZlcyBvbiBOb3Rp Y2UgYW5kIFRha2UtZG93buKAnSwgV0VJUyAyMDA4LA0KIGFsdGhvdWdoIEkgd291bGQgaW1hZ2lu ZSB0aGF0IHRoZXJlIGlzIGV2ZW4gbGF0ZXIgd29yayBhdmFpbGFibGUuPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQpBaCwgd2lsbCBmaXggdG8gZ2V0IHRoZSBvcmRlciBvZiBhdXRob3JzIHJpZ2h0 IGFuZCB5b3XigJlyZSByaWdodCB0aGF0IGl0IGRvZXNu4oCZdCBnbyBpbnRvIGFueSBkZXRhaWwu IEhlcmUgd2Ugd2VyZSBsb29raW5nIGZvciBzb21ldGhpbmcgdGhhdCBhY3R1YWxseSB3ZW50IGlu dG8gcGh5c2ljYWwgc2VpenVyZSBvZiBzZXJ2ZXIgaGFyZHdhcmUgb3Igc2VpenVyZSBvZiBlbnRp cmUgbG9naWNhbCBlbnRpdGllcyAoaW5zdGVhZCBvZiBub3RpY2UgYW5kIHRha2Vkb3duLA0KIHRo ZSBuZXh0IHNlY3Rpb24sIHdoaWNoIGlzIG9mdGVuIGRpcmVjdGVkIGF0IGluZGl2aWR1YWwgcGll Y2VzIG9mIGNvbnRlbnQgb3IgYSBzaW5nbGUgZG9tYWluIG9uIGEgd2Vic2VydmVyKS4gSeKAmWxs IGNoZWNrIG91dCB0aGUgY2l0YXRpb24gYWJvdmUgYW5kIGNpdGF0aW9ucyBzaW5jZSBhbmQgc2Vl IGlmIHdlIGNhbuKAmXQgZ2V0IGJldHRlciBwb2ludGVycyBpbiB0aGVyZSAodGhpcyBzZWN0aW9u IGlzIG9idmlvdXNseSB0byBiZSBjb21wbGV0ZSBhbmQNCiBxdWl0ZSBzdmVsdGUpLjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCk9r LiAmbmJzcDtUaGF0IHNvdW5kcyBsaWtlIGEgY2xhc3NpYyBhc3NldCBzZWl6dXJlLiAmbmJzcDtJ dCBtYXkgYmUgd29ydGggZXhwYW5kaW5nIG9uIGhvdyBhbmQgd2hlbiBwaHlzaWNhbCBhc3NldCBz ZWl6dXJlIGlzIGVmZmVjdGl2ZSwgZXNwZWNpYWxseSBpbiBhIGNsb3VkLWJhc2VkIHdvcmxkLjwv ZGl2Pg0KPGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxNnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SeKAmXZlIGZpeGVkIHRoZSByZWZlcmVuY2UgYW5kIG1h ZGUgc3VyZSB0aGUgdGV4dCBhY2tub3dsZWRnZXMgaXTigJlzIGFuIGluLXBhc3NpbmcgbWVudGlv biBhbmQgaXQgbm93IGNhbGxzIG91dCBjbG91ZC1saWtlIHNpdHVhdGlvbnMuIFNlZSBpZiB0aGlz IHdvcmtzIG9yIHNlbmQgZWRpdHM/Jm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vSVJURi1QRUFSRy9yZmMtY2Vu c29yc2hpcC10ZWNoL2NvbW1pdC82MTIwMmY5MzQ2ODc2YmE4ZDMxMWMxNzhlNjMyZDkzMzNiNzBj ZTNjIiBjbGFzcz0iIj5odHRwczovL2dpdGh1Yi5jb20vSVJURi1QRUFSRy9yZmMtY2Vuc29yc2hp cC10ZWNoL2NvbW1pdC82MTIwMmY5MzQ2ODc2YmE4ZDMxMWMxNzhlNjMyZDkzMzNiNzBjZTNjPC9h PjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxNnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l OyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE2cHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 Ij4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+RmluYWxseSwgZGlkIEkgbWlzcyB0aGUgcGFydCB3 aGVyZSBvbmUgZGlzY3Vzc2VzIGRvbWFpbiBuYW1lIHRha2Vkb3ducyBieSByZWdpc3RyeSwgb3Ig aGFzIHRoYXQgbm90IGJlZW4gdXNlZCBhcyBhIGZvcm0gb2YgY2Vuc29yc2hpcD88YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2UgY2FuIGFkZCBp dCBpZiB5b3UgaGF2ZSBjaXRhdGlvbnMuIFdvdWxkIGxvdmUgYSBQUiBvZiBjb3Vyc2Ugb3Igc3Vn Z2VzdGVkIHRleHQuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCkkgZ3Vlc3MgSSB3b3VsZCBzdWdnZXN0IHN0 YXJ0aW5nIHdpdGggdGhlIHJlZmVyZW5jZXMgaW4mbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5p Y2Fubi5vcmcvZW4vc3lzdGVtL2ZpbGVzL2ZpbGVzL2d1aWRhbmNlLWRvbWFpbi1zZWl6dXJlcy0w N21hcjEyLWVuLnBkZiIgY2xhc3M9IiI+Z3VpZGFuY2UtZG9tYWluLXNlaXp1cmVzLTA3bWFyMTIt ZW4ucGRmPC9hPi48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2Pk9rLCB0aGF0IHdhcyBxdWl0ZSBhIHJhYmJpdCBob2xlLiBJ4oCZdmUgYmVl biBmYXNjaW5hdGluZyBieSBkb21haW4gc2VpenVyZXMgZm9yIGEgd2hpbGUgbm93IChldmVyIHNp bmNlIGEgbGVnYWwgY2FzZSBjYWxsZWQsIOKAnFRoZSBTdGF0ZSBvZiBLZW50dWNreSB2cy4gMTQx IGRvbWFpbiBuYW1lc+KAnSB3aGVyZSB0aGUgVVMgc3RhdGUgb2YgS2VudHVja3kgdXNlZCBpdHMg b3duIGFudGktZ2FtYmxpbmcgbGF3cyB0byBzZWl6ZSB0aGUgZG9tYWlucw0KIG9mIDE0MSBvbmxp bmUgZ2FtYmxpbmcgd2Vic2l0ZXMpLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+SSBhZ3JlZSB0aGF0IHRoZSBkcmFmdCBzaG91bGQgbWVudGlvbiB0aGlzLiBIZXJlIGlz IG15IHByb3Bvc2FsIGFuZCBJ4oCZbSBpbnRlcmVzdGVkIGluIHlvdXIgKGFuZCBvdGhlcnPigJkp IGZlZWRiYWNrOjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+KiBJ4oCZ bGwgYWRkIGRvbWFpbiByZWdpc3RyaWVzIGFuZCByZWdpc3RyYXJzIGFzIGEg4oCccG9pbnQgb2Yg Y29udHJvbOKAnSBpbiBTZWN0aW9uIDMuMS48L2Rpdj4NCjxkaXY+KiBJ4oCZbGwgYWRkIGEgcGFy YWdyYXBoIHRvIFNlY3Rpb24gNC4xLjEgKG9uIEROUyBJbnRlcmZlcmVuY2UpIHBvaW50aW5nIHRv IGRvbWFpbiBzZWl6dXJlcyBpbiBtYWx3YXJlL2JvdG5ldC9zcGFtLCBhbnRpLWZyYXVkLCBhbmQg aW50ZWxsZWN0dWFsIHByb3BlcnR5IGNhc2VzLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXY+SSB3YW50ZWQgdG8gc3VtbWFyaXplIHRoYXQgYmVmb3JlIGFjdHVhbGx5IGNo YW5naW5nIHRoZSB0ZXh0IGFuZCBzZWUgd2hhdCBmb2xrcyB0aGluay48L2Rpdj4NCjxkaXY+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PmJlc3QsIEpvZTwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRp diBkaXI9ImF1dG8iIHN0eWxlPSJ0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9 InRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0idGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRp diBkaXI9ImF1dG8iIHN0eWxlPSJ0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2Pi0tJm5ic3A7PGJyIGNsYXNz PSIiPg0KSm9zZXBoIExvcmVuem8gSGFsbCwmbmJzcDtTZW5pb3IgVmljZSBQcmVzaWRlbnQsJm5i c3A7U3Ryb25nIEludGVybmV0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOmhhbGxAaXNv Yy5vcmciIGNsYXNzPSIiPmhhbGxAaXNvYy5vcmc8L2E+IHwgJiM0MzsxLTcwMy00ODMtOTUwNDxi ciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHA6Ly9pbnRlcm5ldHNvY2lldHkub3JnIiBjbGFzcz0i Ij5pbnRlcm5ldHNvY2lldHkub3JnPC9hPiB8Jm5ic3A7QGludGVybmV0c29jaWV0eTxiciBjbGFz cz0iIj4NCnBncDombmJzcDs8YSBocmVmPSJodHRwczovL2pvc2VwaGhhbGwub3JnL2dwZy1rZXki IGNsYXNzPSIiPmh0dHBzOi8vam9zZXBoaGFsbC5vcmcvZ3BnLWtleTwvYT48YnIgY2xhc3M9IiI+ DQozQ0EyOEQ3QjlGNkREQkQzNEIxMDE2MDc1Rjg2Njk4NzQwQTlBODcxPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_A05941FDA44A41DC90EDE79E6213700Disocorg_-- From nobody Thu May 28 09:27:18 2020 Return-Path: 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 008213A0EAD for ; Thu, 28 May 2020 09:27:16 -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 49c20faY0D8F for ; Thu, 28 May 2020 09:27:14 -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 E772D3A0F69 for ; Thu, 28 May 2020 09:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9108; q=dns/txt; s=iport; t=1590683234; x=1591892834; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=92clFJnFzmO3iDuO08SVOOMKwMiZx0U57XYCU2U5xz4=; b=MRTpsaQgGajtHz4syyQoh6BZq3/0sB1QYs0JCgvBeE88TMtWOWZ2Xdbo q8Dg/Zw9eaxuU64ywpnEmc3GZ3rkYFpuPoZNOpSo9plsa5HwMjL4fYYsZ LajvngkKCKQbAqFa14oKk/18H6o3v2ttwoHHKWc01N6OS6aw/OdnLPTFE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEAADt5c9e/xbLJq1cChwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBgXgFAQELAYEggXdUASASLIQliQGHY5QGhhWBfAsBAQEMAQE?= =?us-ascii?q?lCgQBAYREAoIcJTYHDgIDAQELAQEFAQEBAgEGBG2FWQyFcwQCGAUGNiAQC0I?= =?us-ascii?q?CAlcGgzkBgnwPryd2gTKEOgEUQEKFIQaBOAGMXYIAgREnDBCCHy4+gmcBAQG?= =?us-ascii?q?BN4NBM4ItBJgymwiCXoJ2hTWQOB6CZI4QjRmaR5Axg0kCBAYFAhWBWgQugVY?= =?us-ascii?q?zGggbFWUBgj4+EhkNVY93FxWDOoUUhUQ/AzACCSwCBgEHAQEDCY1dAQE?= X-IronPort-AV: E=Sophos; i="5.73,445,1583193600"; d="scan'208,217"; a="26538746" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 May 2020 16:26:50 +0000 Received: from ams3-vpn-dhcp2844.cisco.com (ams3-vpn-dhcp2844.cisco.com [10.61.75.28]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 04SGQn1N015139 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 May 2020 16:26:50 GMT From: Eliot Lear Message-Id: <79C21420-970E-46E2-9129-1886597924B1@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_06F0E006-23A1-460C-B776-1B03C5B7D8F7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 28 May 2020 18:26:49 +0200 In-Reply-To: Cc: Christopher Wood , "pearg@irtf.org" To: Joseph Lorenzo Hall References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.75.28, ams3-vpn-dhcp2844.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 16:27:16 -0000 --Apple-Mail=_06F0E006-23A1-460C-B776-1B03C5B7D8F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Joe, >>=20 >> Ok. That sounds like a classic asset seizure. It may be worth = expanding on how and when physical asset seizure is effective, = especially in a cloud-based world. >>=20 >=20 > I=E2=80=99ve fixed the reference and made sure the text acknowledges = it=E2=80=99s an in-passing mention and it now calls out cloud-like = situations. See if this works or send edits?=20 >=20 > = https://github.com/IRTF-PEARG/rfc-censorship-tech/commit/61202f9346876ba8d= 311c178e632d9333b70ce3c = I think that=E2=80=99s fine. I think there=E2=80=99s a bigger threat that you should probably mention = from a non-technical perspective: liability laws. I don=E2=80=99t know = where I came up with that idea!!! ;-) >>>=20 >>>> Finally, did I miss the part where one discusses domain name = takedowns by registry, or has that not been used as a form of = censorship? >>>>=20 >>>=20 >>> We can add it if you have citations. Would love a PR of course or = suggested text. >>=20 >> I guess I would suggest starting with the references in = guidance-domain-seizures-07mar12-en.pdf = . >=20 > Ok, that was quite a rabbit hole. I=E2=80=99ve been fascinating by = domain seizures for a while now (ever since a legal case called, =E2=80=9C= The State of Kentucky vs. 141 domain names=E2=80=9D where the US state = of Kentucky used its own anti-gambling laws to seize the domains of 141 = online gambling websites). >=20 > I agree that the draft should mention this. Here is my proposal and = I=E2=80=99m interested in your (and others=E2=80=99) feedback: >=20 > * I=E2=80=99ll add domain registries and registrars as a =E2=80=9Cpoint = of control=E2=80=9D in Section 3.1. > * I=E2=80=99ll add a paragraph to Section 4.1.1 (on DNS Interference) = pointing to domain seizures in malware/botnet/spam, anti-fraud, and = intellectual property cases. >=20 > I wanted to summarize that before actually changing the text and see = what folks think. It would strengthen your case if you can identify a domain name seizure = that is based on what we commonly view as censorship. Otherwise skip = the purpose. And I would add that we are not quite done with the definition of = =E2=80=9Ccensorship=E2=80=9D. I=E2=80=99ve asked for an independent = opinion about whether I really am off, but I don=E2=80=99t see a need to = continue arguing until I get that view (and I=E2=80=99m sure you don=E2=80= =99t see a need to read such an argument!). Eliot= --Apple-Mail=_06F0E006-23A1-460C-B776-1B03C5B7D8F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Joe,


Ok.  That sounds like a classic asset seizure.  It may be = worth expanding on how and when physical asset seizure is effective, = especially in a cloud-based world.


I=E2=80=99ve fixed the reference and made sure the text = acknowledges it=E2=80=99s an in-passing mention and it now calls out = cloud-like situations. See if this works or send edits? 

https://github.com/IRTF-PEARG/rfc-censorship-tech/commit/61202f= 9346876ba8d311c178e632d9333b70ce3c


I = think that=E2=80=99s fine.

I think = there=E2=80=99s a bigger threat that you should probably mention from a = non-technical perspective: liability laws.  I don=E2=80=99t know = where I came up with that idea!!!

;-)




Finally, did I miss the part where one discusses domain = name takedowns by registry, or has that not been used as a form of = censorship?


We can add it if you have citations. Would love a PR of = course or suggested text.

I guess I would suggest starting with the references in guidance-domain-seizures-07mar12-en.pdf.

Ok, that was quite a rabbit hole. I=E2=80=99ve been = fascinating by domain seizures for a while now (ever since a legal case = called, =E2=80=9CThe State of Kentucky vs. 141 domain names=E2=80=9D = where the US state of Kentucky used its own anti-gambling laws to seize = the domains of 141 online gambling websites).

I agree that the draft should mention this. Here is my = proposal and I=E2=80=99m interested in your (and others=E2=80=99) = feedback:

* I=E2=80=99ll add domain registries and registrars as a = =E2=80=9Cpoint of control=E2=80=9D in Section 3.1.
* I=E2=80=99ll add a paragraph to Section 4.1.1 (on DNS = Interference) pointing to domain seizures in malware/botnet/spam, = anti-fraud, and intellectual property cases.

I wanted to summarize that before actually changing the = text and see what folks think.


It would strengthen your case = if you can identify a domain name seizure that is based on what we = commonly view as censorship.  Otherwise skip the = purpose.

And I would add that we are = not quite done with the definition of =E2=80=9Ccensorship=E2=80=9D. =  I=E2=80=99ve asked for an independent opinion about whether I = really am off, but I don=E2=80=99t see a need to continue arguing until = I get that view (and I=E2=80=99m sure you don=E2=80=99t see a need to = read such an argument!).

Eliot
= --Apple-Mail=_06F0E006-23A1-460C-B776-1B03C5B7D8F7-- From nobody Thu May 28 10:48:37 2020 Return-Path: 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 72E633A0ABC for ; Thu, 28 May 2020 10:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 gQ78S7M0kKUy for ; Thu, 28 May 2020 10:48:35 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1D6D3A0B5C for ; Thu, 28 May 2020 10:48:26 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id v79so3900022qkb.10 for ; Thu, 28 May 2020 10:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Fo/Ox/ayAEjQ2FGOl3kInUewehSWWVtErdRswxIAYKk=; b=j91iOtNeXXXT/a2rY07+pC7e8Rg0eAkw6abk4lBIQdk96BVPGJzT7kDHiOYcJiQH9y sS6CMjFiv/p4w2R+YCMYRWZFcADalZEtIe1mt4P6Z/RSo3A5OiPotZ6yXsTOt33qTVDt ydK18T2P057uaGHJ4LC6GP+KJQVIC7+X/vtSI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Fo/Ox/ayAEjQ2FGOl3kInUewehSWWVtErdRswxIAYKk=; b=AwTrD6eRV1S/3Gyd+Tkg52BIrJJcPda/s90nNa8fiF3mJyow2gH7tRfJNJVS5NkO7E WlCojAuWEdLs4Xwp7tyGPtfcUDhHuQQp+RAcUYarlctzuKn04FGnWEj17jwP4MloEO6V PlMk/lIXyIIfAEJ7smkvlVpiRXJHxyZogt7JY9GHzxZvc5xPrQJqvG6DZtoZ6ARd87lM 2oWkVE0+4QSs7UCJ5bRF8QFHDEuw8O7JOW8WQcsMlgs/YtNLSnxZR/mwcPi8WhNWJc98 gGWuAk3dCNCWJgQLZC/59+Ih2SiJ7oyaVtphDs4bbH9Exvqj1I9nn66Aj99YuKqb+oz4 cIfg== X-Gm-Message-State: AOAM533F2pJ57RNVDsPD15o7FacN5LhAcDBJ29DkrU1kJN9wkmSggLSf BBYiXMoCqhoiRPI5x+xnlNj5xm5cGlU= X-Google-Smtp-Source: ABdhPJz60QLzyp/IO1SkyhAlp3ouY5pM1KrW6QvE6Jfx+bQPsA2fUF0JaoPmml2a6tBIx9ZLnYiPNA== X-Received: by 2002:a37:4e03:: with SMTP id c3mr2877211qkb.169.1590688105735; Thu, 28 May 2020 10:48:25 -0700 (PDT) Received: from Mallorys-MacBook-Air.local (c-73-163-188-207.hsd1.dc.comcast.net. [73.163.188.207]) by smtp.gmail.com with ESMTPSA id g9sm1520965qtq.66.2020.05.28.10.48.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 May 2020 10:48:25 -0700 (PDT) To: Eliot Lear , Joseph Lorenzo Hall Cc: "pearg@irtf.org" , Christopher Wood References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> <79C21420-970E-46E2-9129-1886597924B1@cisco.com> From: Mallory Knodel Message-ID: Date: Thu, 28 May 2020 13:48:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Thunderbird/77.0 MIME-Version: 1.0 In-Reply-To: <79C21420-970E-46E2-9129-1886597924B1@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 17:48:37 -0000 On 5/28/20 12:26 PM, Eliot Lear wrote: > I think there’s a bigger threat that you should probably mention from > a non-technical perspective: liability laws.  I don’t know where I > came up with that idea!!! Out of scope for this doc, but yes holy shit. -M From nobody Thu May 28 10:50:07 2020 Return-Path: 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 8287F3A09A3 for ; Thu, 28 May 2020 10:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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, 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 PPqRhxap4HM1 for ; Thu, 28 May 2020 10:50:04 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A08A3A07CE for ; Thu, 28 May 2020 10:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=459; q=dns/txt; s=iport; t=1590688204; x=1591897804; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ZPkG4UQSPs1qaKdDHe8oQTrsguDS+NzOYr04G6LbqrY=; b=ZEAZJITM3AP/em2lvEK9RtzlU+9l/RcX3BiEGedNxbI5VKUFgBNNN9Fj C9v3CVEnHwPabn/Si5+7I8A+9kf3Lq/K6Gw8suy1ZD3Bo2a3po86phzYG 01PTDVS6TtyKmI+VmpTm5iB4lmQMMXFkJUqefXzMqO5oNJf2SeZGA2tWg c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2BACx+M9e/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqDbAEgEiyEJYkBh2Mlm3ILAQEBDAEBLwQBAYREAoIcJTg?= =?us-ascii?q?TAgMBAQsBAQUBAQECAQYEbYVlhXIBAQEBAgEYBQZWBQsLDgoCAiYCAlcGE4M?= =?us-ascii?q?mgl0gr1h2gTKKe4EOKoxeggCBOAwQgh8uPoROgxQzgi0EszqCXoJ2lW0eglM?= =?us-ascii?q?BmzmqeINJAgQGBQIVgWoigVYzGggbFRpLAYI+PhIZDZB4jhI/AzA3AgYBBwE?= =?us-ascii?q?BAwmNXQEB?= X-IronPort-AV: E=Sophos;i="5.73,445,1583193600"; d="scan'208";a="26602136" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 May 2020 17:50:00 +0000 Received: from ams3-vpn-dhcp2844.cisco.com (ams3-vpn-dhcp2844.cisco.com [10.61.75.28]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 04SHnxqd030173 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 May 2020 17:50:00 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: Date: Thu, 28 May 2020 19:49:57 +0200 Cc: Joseph Lorenzo Hall , "pearg@irtf.org" , Christopher Wood Content-Transfer-Encoding: quoted-printable Message-Id: <4A68E41D-EF4C-4675-8CFF-ECE0D708661C@cisco.com> References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> <79C21420-970E-46E2-9129-1886597924B1@cisco.com> To: Mallory Knodel X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.75.28, ams3-vpn-dhcp2844.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 17:50:06 -0000 Ah- ok. Then probably a section title change in Section 6 to clarify. > On 28 May 2020, at 19:48, Mallory Knodel wrote: >=20 > On 5/28/20 12:26 PM, Eliot Lear wrote: >=20 >> I think there=E2=80=99s a bigger threat that you should probably = mention from a non-technical perspective: liability laws. I don=E2=80=99t= know where I came up with that idea!!! >=20 > Out of scope for this doc, but yes holy shit. >=20 > -M >=20 From nobody Thu May 28 11:34:31 2020 Return-Path: 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 9414F3A0602 for ; Thu, 28 May 2020 11:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 L6pj_9nHZVYJ for ; Thu, 28 May 2020 11:34:29 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2051.outbound.protection.outlook.com [40.107.243.51]) (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 EFF953A073D for ; Thu, 28 May 2020 11:34:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FLnmIwxMhHPYwZCbUBWzX0YJ2p8L8pjYMOxbmlklrJNFvR4yfdPwFCtEy2gMf2aCSUWqtIjUAaj4VNl6p1251i1RAkO+r2rXT2zn/xRIvk9sj8xqfgO5uBCVehmc+OqziWkwf/j8RE25fl2IYivkSyBEYF1QcJVx+KWpNbtjWLhHke1Pvzybqm6A/bAm4FRW7Y0iRLwpTWR0bP6P26JfCEHl69TlMdqHiW8PStXTPKIysPEoWR0ydTCrqsq4Y61K8wPM6/Xm20LFV+RRFokhhQWvU6ZKIxcWNg46hN5uLs99sHcVuiMk+tqhiVNBZNX67+0fLf63KAk3JiCKgPY/6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vwh3sVNT2BZx3kAgIMryJQw8Iz3QIzg+yj1OkBg582Y=; b=GYY8LoeC9e6gr05EeHaijr9FZg+xUssvdoGSPA+3uLPHOeYQCuVEG/agw51IfW5L96VY4nY636j9stPFX6+3ZFKdoAlLkl6AnLPd/kAlbNghESu95grdLsTj/EXL56OxIoucgoNVssCLpyKpxl0V2uI7LpecuQLEh3CIFeNKhEutvPcVldqvPvVZBHITfTkV7fFdNnVnanu95Y0YFoM36z8BhfpX0S7PuO1bRvWcLmTMRLR20PiGhPMy0jacL2L01S6ezNfwOfH4eiAXmuSwcsM/5mefydzannUj5Pwjpv+ohF2QI9jKSkPiT/BeLECRoeC2jDMPIZVY0GM5ntqROA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vwh3sVNT2BZx3kAgIMryJQw8Iz3QIzg+yj1OkBg582Y=; b=DG3QeTxjxgbkJsr+Erc5qIIKtZchUapWdb9Lhyc7nCU/0YIhA3Tq17PktP2P1qf104rOqVEQRRvzw+PdJgq3VEPT3CuPJaNsHbZ5gWGWmedGX0YYKwxvhwd+bfEefPX4CmCSRmDUUoieBuvDJYjtC9KHf/unIx3hpz9EtWkxrdY= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BY5PR06MB6689.namprd06.prod.outlook.com (2603:10b6:a03:23a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Thu, 28 May 2020 18:34:27 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5%5]) with mapi id 15.20.3045.018; Thu, 28 May 2020 18:34:27 +0000 From: Joseph Lorenzo Hall To: Eliot Lear , Mallory Knodel CC: "pearg@irtf.org" , Christopher Wood Thread-Topic: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" Thread-Index: AQHWLsgqnBPhO5w6N0yNNHBtsaHVYqi6K/EAgADpJgCAAKT1gIAB/c4AgAAEKICAABbKgIAAAHCAgAAMWvk= Date: Thu, 28 May 2020 18:34:27 +0000 Message-ID: References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> <79C21420-970E-46E2-9129-1886597924B1@cisco.com> , <4A68E41D-EF4C-4675-8CFF-ECE0D708661C@cisco.com> In-Reply-To: <4A68E41D-EF4C-4675-8CFF-ECE0D708661C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=isoc.org; x-originating-ip: [161.35.138.160] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b61b9d2b-0e32-4335-d9ee-08d80335c0a0 x-ms-traffictypediagnostic: BY5PR06MB6689: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:79; x-forefront-prvs: 0417A3FFD2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: axrDB2SdNG/opxwfInklDW40OxkJLQja5Fc5tF79nbo59hxB+ZOzUGyrMd81VN+hlo5Qwcrc1DTIustVkcyZS1dgrvraPM8okrOq9xwzXJS7NI3uk+ykOhb1F9pO6WGPHcd0Fmnhi8QEhQ9MV+qsvPCCRUsXO+LAsDOv2TzTW6fwOrnEbmY7PYWN0wSj6KB9vh83wEH6YUluav2LduXpM2kKRZv3miBoUs0Duv79wYzQq7CPveJ8mkyZBQ6W+Lmf5X6yb7n1rYoglTSD4HxtBY61vsGBdnyWR8sPiOsWKF+mXlZ6k0HgBMQNmKC3iEVPF5p79Ins8lPjnrOLPc8VlUVaMP0z4i50W10ZM7OtVHsUReR5o52VHmrZKrS0ofaoxm7NXYQGqhzjuzIkkFkZig== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(376002)(366004)(396003)(346002)(39840400004)(33656002)(86362001)(66556008)(186003)(71200400001)(4744005)(64756008)(52536014)(66946007)(66476007)(5660300002)(76116006)(66446008)(478600001)(316002)(6506007)(966005)(8676002)(4326008)(8936002)(2906002)(110136005)(26005)(55016002)(9686003)(66574014)(53546011)(7696005)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: bUa0E4+ESHHOe5r+pz2gxpqLWpO7EIVAkuSuqtIrvDwn/KDnh9E+OdLhY+dr+T+/0FNqkOqlUBVQEdIvOOzCIF59WgtS9AU3mACGJNTEqnZzgJKUxk8RO4xIGCqscAVrpFsY+vV1eA1iQa+bKMdOnWfjJWdxyOWOSnJQgih6IYoAV0+GvQ3CNpkKZYTJfo1VZcJ0kasn9NBqJV0nhYBX4RYuyHBTnxi3G4IYMxgF/pAcTexgjHtLW2hI9dH46lr2F77hR5YV1Q0IKZ65RoqJBxyqDeOHnSkrrRPLT6/SdKp/UF/OZ/Bmq1Lh7E/KSfb2PU0GyK07eGFftGM6bIgteMVuZrOaNJnHwav7m7awXrJEzee7j0jJyW1SfX0YOlUEKSEv92tpudDEoGdICh90bQAqz4p/EM7AxdzBfJ2A1BoK3nhA7ZJc+mehPX+tNdhdL+GCx6WBLqHWKHUSG3lvRuQQYRafi1LhneLApN/L0M0JmTBPC4lPa9FUQrwPrN7T x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR06MB645197C9990FB76EA6734BFDB18E0BY5PR06MB6451namp_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: b61b9d2b-0e32-4335-d9ee-08d80335c0a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 18:34:27.0402 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ll+Fdkm2WqlQPH+QewnEr6y/UTSDSqgMgmZ6s6toR/ki7qFs12oLW8GTZ4NWUNWc X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6689 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 18:34:31 -0000 --_000_BY5PR06MB645197C9990FB76EA6734BFDB18E0BY5PR06MB6451namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Nope. -- Joseph Lorenzo Hall, Senior Vice President, Strong Internet hall@isoc.org | +1-703-483-9504 internetsociety.org | @internetsociety pgp: https://josephhall.org/gpg-key 3CA28D7B9F6DDBD34B1016075F86698740A9A871 ________________________________ From: Eliot Lear Sent: Thursday, May 28, 2020 1:49:57 PM To: Mallory Knodel Cc: Joseph Lorenzo Hall ; pearg@irtf.org ; C= hristopher Wood Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Ce= nsorship Techniques" Ah- ok. Then probably a section title change in Section 6 to clarify. > On 28 May 2020, at 19:48, Mallory Knodel wrote: > > On 5/28/20 12:26 PM, Eliot Lear wrote: > >> I think there=92s a bigger threat that you should probably mention from = a non-technical perspective: liability laws. I don=92t know where I came u= p with that idea!!! > > Out of scope for this doc, but yes holy shit. > > -M > --_000_BY5PR06MB645197C9990FB76EA6734BFDB18E0BY5PR06MB6451namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Nope.

--
Joseph Lorenzo Hall, Senior Vice President, = Strong Internet
hall@isoc.org | +1-703-483-9504
internetsociety.org | @internetsociety
pgp: https://josephhall.org/gpg-key
3CA28D7B9F6DDBD34B1016075F86698740A9A871
From: Eliot Lear <lear@c= isco.com>
Sent: Thursday, May 28, 2020 1:49:57 PM
To: Mallory Knodel <mknodel@cdt.org>
Cc: Joseph Lorenzo Hall <hall@isoc.org>; pearg@irtf.org <pe= arg@irtf.org>; Christopher Wood <caw@heapingbits.net>
Subject: Re: [Pearg] Research Group Last Call for "A Survey of = Worldwide Censorship Techniques"
 
Ah- ok.  Then probably a section title change= in Section 6 to clarify.

> On 28 May 2020, at 19:48, Mallory Knodel <mknodel@cdt.org> wrote= :
>
> On 5/28/20 12:26 PM, Eliot Lear wrote:
>
>> I think there=92s a bigger threat that you should probably mention= from a non-technical perspective: liability laws.  I don=92t know whe= re I came up with that idea!!!
>
> Out of scope for this doc, but yes holy shit.
>
> -M
>

--_000_BY5PR06MB645197C9990FB76EA6734BFDB18E0BY5PR06MB6451namp_-- From nobody Thu May 28 12:32:28 2020 Return-Path: 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 B520D3A0AAC for ; Thu, 28 May 2020 12:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 Tmr3HWw2z7lv for ; Thu, 28 May 2020 12:32:24 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2063.outbound.protection.outlook.com [40.107.93.63]) (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 6F8953A0AAB for ; Thu, 28 May 2020 12:32:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y1KY92dAIoKSmk89PXz3ppVYU140CnKsdA4kseEu+vm5LFSASU1mMBFXNq666IqX4w6+7YMdGwuz6jk3Y3Jf51nIOlk3GUMRRApn2FLAvs8cHI28cWv8kmgb488RWmQatRfHJKHo9YDKBHa4Ci0NIg/jpu6bWZaSz++ff2gxRbDbS/R2auqEKHXJHoImNn8dSAfy2JpgNoNfPSfpBBDUGokTvdQ4uJIXtLxHE+AXrzgedX88hI3qezDn+7TXOLmD318SKrxYiOEDhUt1f3ZRMNAifXudc6GKCBYKdgO/ygnVXvBzJELTZTIDSuUVrBW/pQx3hC+OQhmq2Ti8DGUcZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TRuAXym2q9GIA9Iau2YfnPes4MUWfCij8FgKJ75154Y=; b=eNzY2aZ4jPsIRrAd4L6ofH9MwviVwfEHkZv9tCGjHFhjs8G1cHnSMqfnm7YmRRX3RBsWTi0BpRdj6MKSzmMMKH39flSKfBMi7zBKVhq4ut7RG69vph01gtbO2VQAQVkt5va2CrMcfJj+Y1as/58ldAMH1s523fsXFeF/W+edaW4YjajTNuO3kaehZvEP6X4es8DviVE4F33l0KAGvw9q2CawkVONlelRLGP7ik4Q+XSKwmdgDZ1HdUVYoN6+qXexeELw+BZkxQcNkf8/U7mXgkYfi86FYT4KAybXCLIrfBEwtHngukWPpL9h0qCNER+QfLgOsQWdZtO6SQavRCPd2Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TRuAXym2q9GIA9Iau2YfnPes4MUWfCij8FgKJ75154Y=; b=m2ubR0A5TgwdShuvpLlE8Su7JkX+caYyl+6rCM5j04Ww2QxmBUW5y32hN++wInYh0LISTBo6Fd00ibU3bV/NbVNZmoIvLD0VJDSeX6U0SyHVeDbzFMa06aKqZE2kqIMyUg8KC6/yx7xm8BIVzYJu89T+XdSRlrTEl7pC/VJfYL4= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BY5PR06MB6659.namprd06.prod.outlook.com (2603:10b6:a03:232::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17; Thu, 28 May 2020 19:32:16 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5%5]) with mapi id 15.20.3045.018; Thu, 28 May 2020 19:32:16 +0000 From: Joseph Lorenzo Hall To: "Eliot Lear (elear)" CC: Eliot Lear , Mallory Knodel , "pearg@irtf.org" , Christopher Wood Thread-Topic: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" Thread-Index: AQHWLsgqnBPhO5w6N0yNNHBtsaHVYqi6K/EAgADpJgCAAKT1gIAB/c4AgAAEKICAABbKgIAAAHCAgAAMWvmAAA9OAIAAADhq Date: Thu, 28 May 2020 19:32:16 +0000 Message-ID: References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> <79C21420-970E-46E2-9129-1886597924B1@cisco.com> , <4A68E41D-EF4C-4675-8CFF-ECE0D708661C@cisco.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=isoc.org; x-originating-ip: [161.35.138.160] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1d62c7d5-b389-44b2-8800-08d8033dd458 x-ms-traffictypediagnostic: BY5PR06MB6659: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 0417A3FFD2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KqPwYdbjFjvGNupKHeNiUAWhoao36l0QbnrlP7qBf6LjbR6WxOlgsxVKnh5IiJa8d2cGhgGjOSElpQXypHvWm29pyp/5k9pcCvRHqSoD371VnHgevIhAmRjAw3lqXpEpBDaPjmLVthXvsIU3kp4jMqDxznmG56qTTPeV28bMIeYHcWh3nkV2VIq1Mgfr5rcYaU6smu9o3dj53Nt492Xsp1ievWYzIzEZflFD0OjCE/wb9vHZLU+9iK+7PA8S6WIudAEICNhPGbVsoGDKeBKwRYzVshib5q0KPpAECa7Av5E2OzPGaiqBkqxhr/OYRFlcIsp4OdEDrzzX69U5PqRHMH4PIqk6q3Z+4u9J/6qKLNv68XoOJ0DKDJ/SeLgW2LK7B41H1ZnnW1JLNfcq5LWnjg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(39840400004)(396003)(366004)(136003)(346002)(376002)(66574014)(8936002)(966005)(53546011)(4326008)(54906003)(6506007)(7696005)(33656002)(186003)(2906002)(26005)(316002)(478600001)(71200400001)(9686003)(8676002)(55016002)(64756008)(66476007)(86362001)(76116006)(91956017)(6916009)(66946007)(5660300002)(52536014)(66446008)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: tdMcVccD/Tj9Wl8ETmDjy1ELwa+Owda9OAGT7GZRR9REI+EHJtNT7zexaK9qdmLEAgY33XZMBEx226ce/Gf65DaAVOHP73WjUVVbdxou+PiJVIZEPEEeJg5XOf3E+akF8q6s4BRole5luNTfG2J+rjBhw47XrT6kAMRHsZS0WDY6LKPuk+KZZkNHrYT+bDaEev4JX3HgSHJ15s51n49KkN1XnOhOMrQqzXXbXwWgRe//pHV9dRaIbDw0W4WVTjSyicRtpBOWD3rSuWarI3v2fiJejRK7cKpG/IPijk6Nqcs3t82T+alhztMmnxaaKnsgG+xhBeSWgGbIqkgJ1zsKy8kQpEWQn9kISTbpDka9SmQSikH5B0XaFJh8Lva4S01CZ6zKEd80ggWtMJ5APkezj2W9TXvSjqyws8c8ZeVx1oNnLihAEX7deLBx017jZ4+3cIbPUEeDCJH/ubobDN0/iNqkOaCvgwIHzguAHqOsNtIj/uOZX+W0IAM8xqGcBwLz x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR06MB6451A72C9AB698391B4A3340B18E0BY5PR06MB6451namp_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 1d62c7d5-b389-44b2-8800-08d8033dd458 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 19:32:16.2957 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +GoL+OQCS8ULrAQ3M8thmrbx+jAaGAp+3b5hrrHgQUBhAXsiy+S3OOJnGilhmBOK X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6659 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 19:32:27 -0000 --_000_BY5PR06MB6451A72C9AB698391B4A3340B18E0BY5PR06MB6451namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UncmUgbm90IGdvaW5nIHRvIGRlc2NyaWJlIGFsbCB0aGUgbm9uLXRlY2huaWNhbCBtZXRob2Rz IG9mIHN1cHByZXNzaW5nIGZsb3dzIG9mIGRhdGEgYW5kIGluZm9ybWF0aW9uLiBFdmVuIGEgY29t bWEtc2VwYXJhdGVkIGxpc3Qgd291bGQgbm90IGJlIHRlcnJpYmx5IHVzZWZ1bC4gSSBjYW4gZmlu ZCBzb21lIHNvcnQgb2YgcmV2aWV3IGFydGljbGUgYnV0IGl0J3MgYm91bmQgdG8gYmUgaW5jb21w bGV0ZSBvciBoYXZlIHNvbWUgb3RoZXIgZGVmYXVsdC4gV2UgZmVsdCB0aGUgbmVlZCB0byBwb2lu dCBvdXQgdGhhdCB0aGVyZSBpcyBvdGhlciBudWFuY2UgYW5kIHByZXNzdXJlIHBvaW50cyBidXQg YXMgdGhlIGRvY3VtZW50IHNheXMgaXQncyBwcmltYXJpbHkgZm9jdXNlZCBvbiB0ZWNobmljYWwg bmV0d29yayBjZW5zb3JzaGlwLg0KDQpJZiB5b3UgYnJvdWdodCB0ZXh0LCB3ZSB3b3VsZCBpcyBj b3Vyc2UgY29uc2lkZXIgaXQuDQoNCi0tDQpKb3NlcGggTG9yZW56byBIYWxsLCBTZW5pb3IgVmlj ZSBQcmVzaWRlbnQsIFN0cm9uZyBJbnRlcm5ldA0KaGFsbEBpc29jLm9yZyB8ICsxLTcwMy00ODMt OTUwNA0KaW50ZXJuZXRzb2NpZXR5Lm9yZyB8IEBpbnRlcm5ldHNvY2lldHkNCnBncDogaHR0cHM6 Ly9qb3NlcGhoYWxsLm9yZy9ncGcta2V5DQozQ0EyOEQ3QjlGNkREQkQzNEIxMDE2MDc1Rjg2Njk4 NzQwQTlBODcxDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogRWxpb3Qg TGVhciAoZWxlYXIpIDxlbGVhckBjaXNjby5jb20+DQpTZW50OiBUaHVyc2RheSwgTWF5IDI4LCAy MDIwIDM6Mjg6NTYgUE0NClRvOiBKb3NlcGggTG9yZW56byBIYWxsIDxoYWxsQGlzb2Mub3JnPg0K Q2M6IEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPjsgTWFsbG9yeSBLbm9kZWwgPG1rbm9kZWxA Y2R0Lm9yZz47IHBlYXJnQGlydGYub3JnIDxwZWFyZ0BpcnRmLm9yZz47IENocmlzdG9waGVyIFdv b2QgPGNhd0BoZWFwaW5nYml0cy5uZXQ+DQpTdWJqZWN0OiBSZTogW1BlYXJnXSBSZXNlYXJjaCBH cm91cCBMYXN0IENhbGwgZm9yICJBIFN1cnZleSBvZiBXb3JsZHdpZGUgQ2Vuc29yc2hpcCBUZWNo bmlxdWVzIg0KDQpPayBzbyBub3cgdGhlIHVzZSBvZiB0aGUgdGVybSDigJ1ub24tdGVjaG5pY2Fs 4oCcIGlzIGNvbmZ1c2luZy4gIElmIHBoeXNpY2FsIHNlaXp1cmVzIGFyZSBpbiBzY29wZSBidXQg TGVnYWwvZWNvbm9taWMgamVvcGFyZHkgaXNu4oCZdC4uLg0KDQpFbGlvdA0KDQpPbiBNYXkgMjgs IDIwMjAsIGF0IDIwOjM0LCBKb3NlcGggTG9yZW56byBIYWxsIDxoYWxsQGlzb2Mub3JnPiB3cm90 ZToNCg0K77u/DQpOb3BlLg0KDQotLQ0KSm9zZXBoIExvcmVuem8gSGFsbCwgU2VuaW9yIFZpY2Ug UHJlc2lkZW50LCBTdHJvbmcgSW50ZXJuZXQNCmhhbGxAaXNvYy5vcmcgfCArMS03MDMtNDgzLTk1 MDQNCmludGVybmV0c29jaWV0eS5vcmcgfCBAaW50ZXJuZXRzb2NpZXR5DQpwZ3A6IGh0dHBzOi8v am9zZXBoaGFsbC5vcmcvZ3BnLWtleQ0KM0NBMjhEN0I5RjZEREJEMzRCMTAxNjA3NUY4NjY5ODc0 MEE5QTg3MQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEVsaW90IExl YXIgPGxlYXJAY2lzY28uY29tPg0KU2VudDogVGh1cnNkYXksIE1heSAyOCwgMjAyMCAxOjQ5OjU3 IFBNDQpUbzogTWFsbG9yeSBLbm9kZWwgPG1rbm9kZWxAY2R0Lm9yZz4NCkNjOiBKb3NlcGggTG9y ZW56byBIYWxsIDxoYWxsQGlzb2Mub3JnPjsgcGVhcmdAaXJ0Zi5vcmcgPHBlYXJnQGlydGYub3Jn PjsgQ2hyaXN0b3BoZXIgV29vZCA8Y2F3QGhlYXBpbmdiaXRzLm5ldD4NClN1YmplY3Q6IFJlOiBb UGVhcmddIFJlc2VhcmNoIEdyb3VwIExhc3QgQ2FsbCBmb3IgIkEgU3VydmV5IG9mIFdvcmxkd2lk ZSBDZW5zb3JzaGlwIFRlY2huaXF1ZXMiDQoNCkFoLSBvay4gIFRoZW4gcHJvYmFibHkgYSBzZWN0 aW9uIHRpdGxlIGNoYW5nZSBpbiBTZWN0aW9uIDYgdG8gY2xhcmlmeS4NCg0KPiBPbiAyOCBNYXkg MjAyMCwgYXQgMTk6NDgsIE1hbGxvcnkgS25vZGVsIDxta25vZGVsQGNkdC5vcmc+IHdyb3RlOg0K Pg0KPiBPbiA1LzI4LzIwIDEyOjI2IFBNLCBFbGlvdCBMZWFyIHdyb3RlOg0KPg0KPj4gSSB0aGlu ayB0aGVyZeKAmXMgYSBiaWdnZXIgdGhyZWF0IHRoYXQgeW91IHNob3VsZCBwcm9iYWJseSBtZW50 aW9uIGZyb20gYSBub24tdGVjaG5pY2FsIHBlcnNwZWN0aXZlOiBsaWFiaWxpdHkgbGF3cy4gIEkg ZG9u4oCZdCBrbm93IHdoZXJlIEkgY2FtZSB1cCB3aXRoIHRoYXQgaWRlYSEhIQ0KPg0KPiBPdXQg b2Ygc2NvcGUgZm9yIHRoaXMgZG9jLCBidXQgeWVzIGhvbHkgc2hpdC4NCj4NCj4gLU0NCj4NCg0K --_000_BY5PR06MB6451A72C9AB698391B4A3340B18E0BY5PR06MB6451namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246IGx0cjsiPldlJ3JlIG5vdCBnb2luZyB0byBkZXNjcmli ZSBhbGwgdGhlIG5vbi10ZWNobmljYWwgbWV0aG9kcyBvZiBzdXBwcmVzc2luZyBmbG93cyBvZiBk YXRhIGFuZCBpbmZvcm1hdGlvbi4gRXZlbiBhIGNvbW1hLXNlcGFyYXRlZCBsaXN0IHdvdWxkIG5v dCBiZSB0ZXJyaWJseSB1c2VmdWwuIEkgY2FuIGZpbmQgc29tZSBzb3J0IG9mIHJldmlldyBhcnRp Y2xlIGJ1dCBpdCdzIGJvdW5kIHRvIGJlIGluY29tcGxldGUNCiBvciBoYXZlIHNvbWUgb3RoZXIg ZGVmYXVsdC4gV2UgZmVsdCB0aGUgbmVlZCB0byBwb2ludCBvdXQgdGhhdCB0aGVyZSBpcyBvdGhl ciBudWFuY2UgYW5kIHByZXNzdXJlIHBvaW50cyBidXQgYXMgdGhlIGRvY3VtZW50IHNheXMgaXQn cyBwcmltYXJpbHkgZm9jdXNlZCBvbiB0ZWNobmljYWwgbmV0d29yayBjZW5zb3JzaGlwLjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjogbHRyOyI+SWYgeW91 IGJyb3VnaHQgdGV4dCwgd2Ugd291bGQgaXMgY291cnNlIGNvbnNpZGVyIGl0LjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibXMtb3V0bG9vay1pb3Mtc2lnbmF0 dXJlIj4NCjxkaXYgc3R5bGU9ImRpcmVjdGlvbjogbHRyOyI+LS0gPC9kaXY+DQo8ZGl2IHN0eWxl PSJkaXJlY3Rpb246IGx0cjsiPkpvc2VwaCBMb3JlbnpvIEhhbGwsIFNlbmlvciBWaWNlIFByZXNp ZGVudCwgU3Ryb25nIEludGVybmV0PC9kaXY+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246IGx0cjsi PmhhbGxAaXNvYy5vcmcgfCAmIzQzOzEtNzAzLTQ4My05NTA0PC9kaXY+DQo8ZGl2IHN0eWxlPSJk aXJlY3Rpb246IGx0cjsiPmludGVybmV0c29jaWV0eS5vcmcgfCBAaW50ZXJuZXRzb2NpZXR5PC9k aXY+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246IGx0cjsiPnBncDogaHR0cHM6Ly9qb3NlcGhoYWxs Lm9yZy9ncGcta2V5PC9kaXY+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246IGx0cjsiPjNDQTI4RDdC OUY2RERCRDM0QjEwMTYwNzVGODY2OTg3NDBBOUE4NzE8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 aHIgc3R5bGU9ImRpc3BsYXk6aW5saW5lLWJsb2NrO3dpZHRoOjk4JSIgdGFiaW5kZXg9Ii0xIj4N CjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9udCBmYWNlPSJDYWxpYnJpLCBz YW5zLXNlcmlmIiBzdHlsZT0iZm9udC1zaXplOjExcHQiIGNvbG9yPSIjMDAwMDAwIj48Yj5Gcm9t OjwvYj4gRWxpb3QgTGVhciAoZWxlYXIpICZsdDtlbGVhckBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+ U2VudDo8L2I+IFRodXJzZGF5LCBNYXkgMjgsIDIwMjAgMzoyODo1NiBQTTxicj4NCjxiPlRvOjwv Yj4gSm9zZXBoIExvcmVuem8gSGFsbCAmbHQ7aGFsbEBpc29jLm9yZyZndDs8YnI+DQo8Yj5DYzo8 L2I+IEVsaW90IExlYXIgJmx0O2xlYXJAY2lzY28uY29tJmd0OzsgTWFsbG9yeSBLbm9kZWwgJmx0 O21rbm9kZWxAY2R0Lm9yZyZndDs7IHBlYXJnQGlydGYub3JnICZsdDtwZWFyZ0BpcnRmLm9yZyZn dDs7IENocmlzdG9waGVyIFdvb2QgJmx0O2Nhd0BoZWFwaW5nYml0cy5uZXQmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbUGVhcmddIFJlc2VhcmNoIEdyb3VwIExhc3QgQ2FsbCBmb3IgJnF1 b3Q7QSBTdXJ2ZXkgb2YgV29ybGR3aWRlIENlbnNvcnNoaXAgVGVjaG5pcXVlcyZxdW90OzwvZm9u dD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5PayBzbyBub3cg dGhlIHVzZSBvZiB0aGUgdGVybSDigJ1ub24tdGVjaG5pY2Fs4oCcIGlzIGNvbmZ1c2luZy4gJm5i c3A7SWYgcGh5c2ljYWwgc2VpenVyZXMgYXJlIGluIHNjb3BlIGJ1dCBMZWdhbC9lY29ub21pYyBq ZW9wYXJkeSBpc27igJl0Li4uPGJyPg0KPGJyPg0KPGRpdiBkaXI9Imx0ciI+RWxpb3Q8L2Rpdj4N CjxkaXYgZGlyPSJsdHIiPjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk9uIE1heSAyOCwg MjAyMCwgYXQgMjA6MzQsIEpvc2VwaCBMb3JlbnpvIEhhbGwgJmx0O2hhbGxAaXNvYy5vcmcmZ3Q7 IHdyb3RlOjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj7vu78NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i ZGlyZWN0aW9uOmx0ciI+Tm9wZS48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9InhfbXMtb3V0bG9vay1pb3Mtc2lnbmF0dXJlIj4NCjxkaXYgc3R5bGU9ImRpcmVj dGlvbjpsdHIiPi0tIDwvZGl2Pg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9uOmx0ciI+Sm9zZXBoIExv cmVuem8gSGFsbCwgU2VuaW9yIFZpY2UgUHJlc2lkZW50LCBTdHJvbmcgSW50ZXJuZXQ8L2Rpdj4N CjxkaXYgc3R5bGU9ImRpcmVjdGlvbjpsdHIiPmhhbGxAaXNvYy5vcmcgfCAmIzQzOzEtNzAzLTQ4 My05NTA0PC9kaXY+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246bHRyIj5pbnRlcm5ldHNvY2lldHku b3JnIHwgQGludGVybmV0c29jaWV0eTwvZGl2Pg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9uOmx0ciI+ cGdwOiBodHRwczovL2pvc2VwaGhhbGwub3JnL2dwZy1rZXk8L2Rpdj4NCjxkaXYgc3R5bGU9ImRp cmVjdGlvbjpsdHIiPjNDQTI4RDdCOUY2RERCRDM0QjEwMTYwNzVGODY2OTg3NDBBOUE4NzE8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8aHIgdGFiaW5kZXg9Ii0xIiBzdHlsZT0iZGlzcGxheTppbmxp bmUtYmxvY2s7IHdpZHRoOjk4JSI+DQo8ZGl2IGlkPSJ4X2RpdlJwbHlGd2RNc2ciIGRpcj0ibHRy Ij48Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBjb2xvcj0iIzAwMDAwMCIgc3R5bGU9 ImZvbnQtc2l6ZToxMXB0Ij48Yj5Gcm9tOjwvYj4gRWxpb3QgTGVhciAmbHQ7bGVhckBjaXNjby5j b20mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXkgMjgsIDIwMjAgMTo0OTo1NyBQ TTxicj4NCjxiPlRvOjwvYj4gTWFsbG9yeSBLbm9kZWwgJmx0O21rbm9kZWxAY2R0Lm9yZyZndDs8 YnI+DQo8Yj5DYzo8L2I+IEpvc2VwaCBMb3JlbnpvIEhhbGwgJmx0O2hhbGxAaXNvYy5vcmcmZ3Q7 OyBwZWFyZ0BpcnRmLm9yZyAmbHQ7cGVhcmdAaXJ0Zi5vcmcmZ3Q7OyBDaHJpc3RvcGhlciBXb29k ICZsdDtjYXdAaGVhcGluZ2JpdHMubmV0Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1Bl YXJnXSBSZXNlYXJjaCBHcm91cCBMYXN0IENhbGwgZm9yICZxdW90O0EgU3VydmV5IG9mIFdvcmxk d2lkZSBDZW5zb3JzaGlwIFRlY2huaXF1ZXMmcXVvdDs8L2ZvbnQ+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X0JvZHlGcmFnbWVudCI+PGZvbnQgc2l6ZT0iMiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij5BaC0g b2suJm5ic3A7IFRoZW4gcHJvYmFibHkgYSBzZWN0aW9uIHRpdGxlIGNoYW5nZSBpbiBTZWN0aW9u IDYgdG8gY2xhcmlmeS48YnI+DQo8YnI+DQomZ3Q7IE9uIDI4IE1heSAyMDIwLCBhdCAxOTo0OCwg TWFsbG9yeSBLbm9kZWwgJmx0O21rbm9kZWxAY2R0Lm9yZyZndDsgd3JvdGU6PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IE9uIDUvMjgvMjAgMTI6MjYgUE0sIEVsaW90IExlYXIgd3JvdGU6PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7Jmd0OyBJIHRoaW5rIHRoZXJl4oCZcyBhIGJpZ2dlciB0aHJlYXQgdGhhdCB5 b3Ugc2hvdWxkIHByb2JhYmx5IG1lbnRpb24gZnJvbSBhIG5vbi10ZWNobmljYWwgcGVyc3BlY3Rp dmU6IGxpYWJpbGl0eSBsYXdzLiZuYnNwOyBJIGRvbuKAmXQga25vdyB3aGVyZSBJIGNhbWUgdXAg d2l0aCB0aGF0IGlkZWEhISE8YnI+DQomZ3Q7IDxicj4NCiZndDsgT3V0IG9mIHNjb3BlIGZvciB0 aGlzIGRvYywgYnV0IHllcyBob2x5IHNoaXQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC1NPGJyPg0K Jmd0OyA8YnI+DQo8YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY5PR06MB6451A72C9AB698391B4A3340B18E0BY5PR06MB6451namp_-- From nobody Thu May 28 13:22:13 2020 Return-Path: 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 947273A0CB8 for ; Thu, 28 May 2020 13:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=LhUHkys5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=blM65BfX 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 oCllRIJ6xj01 for ; Thu, 28 May 2020 13:22:09 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350F73A0CB2 for ; Thu, 28 May 2020 13:22:09 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3ACA25C00CB for ; Thu, 28 May 2020 16:22:08 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Thu, 28 May 2020 16:22:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=nv8BOZkQIARk++z3q/pRrbp4W4XSD/2 PKa+4bzM2mVw=; b=LhUHkys56fDqNK6pDy7gPhMaU7m6zHwzJYJKQwoy/0TeMW+ YsUM3WLzzVAiHti6GczlaM5adxv90w+razPo0WKNPuKfJ5v8Ju3BLAi3GzlqhZG8 1v+je38r6T7CS1M6iXR4t5ESsqh/00qaaXtLEQVMfqLRM/Q0WVGjesgQEgg/PU2U /rmQEUAxMbfki5oPickRM3Zv5pcw/vMBY4YeIlyPCmUNmqkHcybt9mV4jotACROX P0dnfZQLM2AmID/LFr5z+3iv6DxaU8bwSDS044VL5i7Q1PWnnxMOru4n27WXG5J5 tzZQDrMcqXcvUnHDyIw2PGGVMXQxkIvU2I5AcAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=nv8BOZ kQIARk++z3q/pRrbp4W4XSD/2PKa+4bzM2mVw=; b=blM65BfXTewUyoYEGjlXyg JFobiOEv5wCNMhPzt4zZulR/w/jLi/yXyHKEg1xzWyubor8iX+f2L1f6dlbBf+yi i0IYzCF6o6K/n71Wu047jXdV3IHb8qqf2WtkOupkf/n9iDsUHcGBejKh3dG1UHyL ADCi3IklW3/2XjqdCnioUEuIzNI8y+pGthMNaQhVdsSUTBLh8/Qrb8KXOJYPu355 K5qwZliuSa+qKMMil1QB94JFtQyv8iAmd11oi5TlewI4YOBgieh094sUAUxYFyV4 V+bEg00kmR/w4w2wONxW1pCuBuGf+QzT8TE8FEsjo72DayjQq8uCGaW5TWHexk9w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddviedgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpedugeffkeekle fgjeetffehieeglefgleduffekudethfehieehjeejueeiieeljeenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsg hithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DD0F13C00A1; Thu, 28 May 2020 16:22:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-504-g204cd6f-fm-20200527.002-g204cd6f2 Mime-Version: 1.0 Message-Id: <0dff13b6-079e-4cbb-bab7-284cd3bc81da@www.fastmail.com> In-Reply-To: References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> <79C21420-970E-46E2-9129-1886597924B1@cisco.com> <4A68E41D-EF4C-4675-8CFF-ECE0D708661C@cisco.com> Date: Thu, 28 May 2020 13:21:19 -0700 From: "Christopher Wood" To: pearg@irtf.org Content-Type: text/plain Archived-At: Subject: Re: [Pearg] =?utf-8?q?Research_Group_Last_Call_for_=22A_Survey_of_Wo?= =?utf-8?q?rldwide_Censorship_Techniques=22?= X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 20:22:11 -0000 On Thu, May 28, 2020, at 12:32 PM, Joseph Lorenzo Hall wrote: > > We're not going to describe all the non-technical methods of > suppressing flows of data and information. Even a comma-separated list > would not be terribly useful. I can find some sort of review article > but it's bound to be incomplete or have some other default. We felt the > need to point out that there is other nuance and pressure points but as > the document says it's primarily focused on technical network > censorship. > > If you brought text, we would is course consider it. 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. 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. Best, Chris (chair hat on) From nobody Fri May 29 01:34:25 2020 Return-Path: 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 ; 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 ; 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 ; 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: =?us-ascii?q?A0DjBADmx9Be/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCCoF5gXMBIBKEUYkBh2QlgQGSYIgRCwEBAQwBAS8EAQGERAK?= =?us-ascii?q?CHCU4EwIDAQELAQEFAQEBAgEGBG2FZYVzAQQBGAUGVgULCw40AgJXBoM5gl0?= =?us-ascii?q?grxZ2gTKFUYUkgTiJeYJmggCBEScMEIIYNT6HYjOCLQSPBYwMmC6CXoJ6i0e?= =?us-ascii?q?KKR6eEKsBg0kCBAYFAhWBaiKBVjMaCBsVZQGCPz0SGQ2QTBcVbgEJjRcDPwN?= =?us-ascii?q?nAgYBBwEBAwmNdAEB?= 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 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 References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> <79C21420-970E-46E2-9129-1886597924B1@cisco.com> <4A68E41D-EF4C-4675-8CFF-ECE0D708661C@cisco.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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 08:34:21 -0000 --Apple-Mail=_2BA628C4-1F14-434B-B74B-15A6043E32FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99t 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=E2=80=99t 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 =E2=80=9Ccensorship regime=E2=80=9D. 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=E2=80=99t 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=E2=80=99= s abstract. The substance here is the difference between =E2=80=9Ccontent= " and =E2=80=9Cinformation=E2=80=9D and perhaps motivation. I am not = suggesting a full exploration of what censorship is, but some = justification for the language. Same for =E2=80=9Ccensorship regime=E2=80= =9D, 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 =E2=80=9CNon-Technical [Prescription/Interference]=E2=80=9D. As I = wrote above, I don=E2=80=99t 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 =E2=80=9Cswaying public thought=E2=80= =9D, to include something like =E2=80=9Cadding financial liability=E2=80=9D= . 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=E2=80=99t know. I lean toward =E2=80=9Cminor=E2=80=9D only because = the document might stand up without its mention, even though I would = view it as an opportunity lost. Eliot --Apple-Mail=_2BA628C4-1F14-434B-B74B-15A6043E32FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80=99t 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=E2=80=99t 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 =E2=80=9Ccensorship regime=E2=80=9D.
  • 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=E2=80=99t 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=E2=80=99s abstract. =  The substance here is the difference between =E2=80=9Ccontent" and = =E2=80=9Cinformation=E2=80=9D and perhaps motivation.  I am not = suggesting a full exploration of what censorship is, but some = justification for the language.  Same for =E2=80=9Ccensorship = regime=E2=80=9D, 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 =E2=80=9CNon-Technical = [Prescription/Interference]=E2=80=9D.  As I wrote above, I don=E2=80=99= 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 =E2=80=9Cswaying public thought=E2=80=9D, to include = something like =E2=80=9Cadding financial liability=E2=80=9D.  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=E2=80=99t know.  I lean toward =E2=80=9Cminor=E2=80=9D = only because the document might stand up without its mention, even = though I would view it as an opportunity lost.

Eliot

= --Apple-Mail=_2BA628C4-1F14-434B-B74B-15A6043E32FA-- From nobody Fri May 29 02:01:44 2020 Return-Path: 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 F1C9F3A0D2E for ; Fri, 29 May 2020 02:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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 96ZX35b5zFfT for ; Fri, 29 May 2020 02:01:40 -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 E0E943A0D29 for ; Fri, 29 May 2020 02:01:39 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jeatU-0001tp-K1 for pearg@irtf.org; Fri, 29 May 2020 11:01:37 +0200 To: pearg@irtf.org References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> <79C21420-970E-46E2-9129-1886597924B1@cisco.com> <4A68E41D-EF4C-4675-8CFF-ECE0D708661C@cisco.com> <0dff13b6-079e-4cbb-bab7-284cd3bc81da@www.fastmail.com> <5F07139C-6493-4A4B-B690-5C807C0A63A0@cisco.com> From: Niels ten Oever Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <23b27699-312c-5147-5c41-2355f533cb3a@digitaldissidents.org> Date: Fri, 29 May 2020 11:01:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <5F07139C-6493-4A4B-B690-5C807C0A63A0@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 897836312160ed0141c32cdc6ac56212 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 09:01:43 -0000 On 5/29/20 10:34 AM, Eliot Lear wrote: > 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. I disagree. Saying something doesn't match common usage, or common sense, it easy to say but very hard to show. To define what censorship is, is not what the authors set out to do, and I don't think we can reasonably ask it of them. > * There is no definition of “censorship regime”. I don't think that is needed because this is not a literature review on censorship. The study provides a definition and implements it. Very typical for a survey study. Else you will have a chicken and egg situation: should the definition depend on empirical evidence, but how to do case selection without a definition? > * The one reference I checked was clearly not appropriate in its usage, leading me to wonder about the others. We should not depend on it, but this is also fully checked in the RFC editor process. Best, Niels > > > 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 > > -- Niels ten Oever Researcher and PhD Candidate Datactive Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Fri May 29 03:15:05 2020 Return-Path: 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 268BF3A0CAE for ; Fri, 29 May 2020 03:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 VMphIaDHUYBN for ; Fri, 29 May 2020 03:15:02 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBE23A0BFE for ; Fri, 29 May 2020 03:15:02 -0700 (PDT) Received: from [IPv6:2a00:ac00:0:35:b474:b0c2:1757:69bd] (unknown [IPv6:2a00:ac00:0:35:b474:b0c2:1757:69bd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id AB8BE611665; Fri, 29 May 2020 13:14:52 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1590747292; bh=KVEPRwUofWTT3GDjP8yB10uCgUx322eSIri6H6U0yDU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Qh0rFymCnvCnDNUUYXrAbf2TwRgRVz8Z9N6xTuGDLs++ahGo/1MIMunyjcKBtKMCO q4PSB3eTqa7SYyBDE196WhGBjL/Dm1cx7mjl63Fe9pe1SePeAJdTzoqj5Yi20CNysT WGcOFRylBhY2ipkQrI+AkcrfAWwgUJ4/Yg3uU9c8= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_427566B3-2782-45AD-B093-96C124363DC1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 29 May 2020 13:14:52 +0300 In-Reply-To: <79C21420-970E-46E2-9129-1886597924B1@cisco.com> Cc: Joseph Lorenzo Hall , "pearg@irtf.org" , Christopher Wood To: Eliot Lear References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> <79C21420-970E-46E2-9129-1886597924B1@cisco.com> X-MailScanner-ID: AB8BE611665.A41AB X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 10:15:04 -0000 --Apple-Mail=_427566B3-2782-45AD-B093-96C124363DC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2020-5-28, at 19:26, Eliot Lear = wrote: > It would strengthen your case if you can identify a domain name = seizure that is based on what we commonly view as censorship. Otherwise = skip the purpose. I don't know who "we" here is, but there are certainly many cases where = domain names have been seized that *some* consider censorship. For = example: = https://www.eff.org/deeplinks/2017/09/cat-domain-casualty-catalonian-indep= endence-crackdown Lars --Apple-Mail=_427566B3-2782-45AD-B093-96C124363DC1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl7Q4JwACgkQVLXDCb9w wVeJnw/6A1aGOHML2F8E2eYW9FqQ/NMpq+fwgHqimfVpeGcYP7fW7W35o95AqXKr 3l6As7D8cgEOYHB54Cy+4aY5V2iJ510SyXxdTuXhZejp47/VAPqlEoM6dmDneshn vAhEbCErtjTDIHEWVrY0srZm5XoBjd5rno71bPhjsRLmM97U+MXTdJPbiIzSWnyT +PXHK6fBkZnJMZ9obJqADFARTrFbiORFVNhd52UTNDrKVbM3fp2hlVcQMtT4joKQ QBFq+R62b8++u6NuBPd0DZvCuyi1M8pLBKn0BzdoB5hSkOY3jWLZQPFDLIHEh2kh f7aFIcdhXb2wDVtVia596SjUR5u9a7pN75W1VYcDDT9WNh4XeCka1BCVSbHdqrYD GvoqO5mRKwxFJrF+8WQVF3DZi3tJ/1TXeu7I4dA4fwEQrJ17YeKdfZIJiSdQ0HiB kCaWrbNhAkPeHW3b6ZrgyKN21iKLNdhIrs2jDzsIEsrLcadetjiU2ncw+14bsd3R InEkZ1NHseIjlfZuTnV2oWLL94NCYq0H4zVVgNjb/TQME3raOpKHoB+/gjrNGspr 95M7yz8dY1HxVpPyZDtwrcbYt3CXBnqz683qWTFzHdsDvUAyfW1Fj7rMwlYmxCkX D9tLm7ogxuLvRdvBH2DbJ1tyNsErjK4caL/pguIVfXB/ETE46mY= =YnMI -----END PGP SIGNATURE----- --Apple-Mail=_427566B3-2782-45AD-B093-96C124363DC1-- From nobody Fri May 29 03:48:28 2020 Return-Path: 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 BC9F33A0DF0 for ; Fri, 29 May 2020 03:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 IDg2am-Ph2Yr for ; Fri, 29 May 2020 03:48:25 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 C1E2F3A0DEC for ; Fri, 29 May 2020 03:48:24 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id E7FD56A305 for ; Fri, 29 May 2020 12:48:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1590749300; bh=VE6753jAVDwo183T34brsMwS3UG+OOP8ddsQ9PsYcjM=; h=Date:From:To:In-Reply-To:References:Subject:From; b=EO0p5zsP27SLZi7cI+9Gzu9vlaIunr6lg/e8YV+IG5w6nkumD0VnfVNrWYWnrIjib o6WL69YK2T0uETWIwKJJwCMvsfw9Jxe45dPap5ACE0Ujx3y+Ck3pmlOdvMMplOYVIJ GZOV9np696IVFgjQgEvlAyPJtPuyRkcifzQHS6twUknBageNR+YmdIsPycDX6Xk78H JG5D1MHBB/apCFIT0k8lW5rQG+JqOvzffaNdjBuk0y05cZ3WikMTc2Qlm2ONJ2S2uk m8fzxiKEgSoWGiqbB0jJs4oOoauxKn3p4upy8jgg3pfOlSQlpGl39QTZvFmX2IIele QLG1z2Hz920jw== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id D898A3C02D9 for ; Fri, 29 May 2020 12:48:20 +0200 (CEST) Date: Fri, 29 May 2020 12:48:20 +0200 (CEST) From: Vittorio Bertola To: pearg@irtf.org Message-ID: <1066566227.7990.1590749300790@appsuite-gw1.open-xchange.com> In-Reply-To: <353091b8-c84c-e02d-c7e0-c524070135b1@digitaldissidents.org> References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <455744305.5725.1590658172742@appsuite-gw2.open-xchange.com> <75c0bcb0-d4ae-4d5c-2aac-0c16962841a9@digitaldissidents.org> <1579895595.5892.1590660934957@appsuite-gw2.open-xchange.com> <353091b8-c84c-e02d-c7e0-c524070135b1@digitaldissidents.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev13 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 10:48:27 -0000 > Il 28/05/2020 12:23 Niels ten Oever ha scritto: > > I don't think it is, it is a descriptive term. The study of censorship regimes is a whole field in political science and communication. With 'censorship regimes' one does not mean authoritarian regimes, but every authority that sets rules, cultural or social norms on the limitation of the dissemination of information. 'Good taste', for example, is also a censorship regime. Unfortunately, this is not how the word "censorship" is used outside of that small circle, and it is not how it will be perceived by people in the broader Internet governance environment when reading this document. There seems to be a clear disconnect in the perception of these terms between different audiences. So, to avoid misunderstandings, the document could rather just focus on describing techniques for content access control and removal without calling them names. > Il 29/05/2020 12:14 Lars Eggert ha scritto: > > I don't know who "we" here is, but there are certainly many cases where domain names have been seized that *some* consider censorship. For example: https://www.eff.org/deeplinks/2017/09/cat-domain-casualty-catalonian-independence-crackdown That's exactly the problem: mention that in this document as "censorship", and the document will (or, at least, will appear to) be a declaration of support for those that think that that behaviour is censorship, against those that think that it is not censorship (which include the national Spanish government and the European Union). We can try to tell the Spanish government that we are using "censorship" in the strictly academic sense of "enforcement of court rulings on online content", but I don't know how well this would fly. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Fri May 29 04:08:25 2020 Return-Path: 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 626AD3A0E02 for ; Fri, 29 May 2020 04:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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 quNPvmaehFPl for ; Fri, 29 May 2020 04:08:19 -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 4E3843A0DBB for ; Fri, 29 May 2020 04:08:18 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jecs2-0006Mx-Ph for pearg@irtf.org; Fri, 29 May 2020 13:08:16 +0200 To: pearg@irtf.org References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <455744305.5725.1590658172742@appsuite-gw2.open-xchange.com> <75c0bcb0-d4ae-4d5c-2aac-0c16962841a9@digitaldissidents.org> <1579895595.5892.1590660934957@appsuite-gw2.open-xchange.com> <353091b8-c84c-e02d-c7e0-c524070135b1@digitaldissidents.org> <1066566227.7990.1590749300790@appsuite-gw1.open-xchange.com> From: Niels ten Oever Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: Date: Fri, 29 May 2020 13:08:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <1066566227.7990.1590749300790@appsuite-gw1.open-xchange.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 2ecd0b53b7de9511489f92806276a3d7 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 11:08:23 -0000 On 5/29/20 12:48 PM, Vittorio Bertola wrote: > > >> Il 28/05/2020 12:23 Niels ten Oever ha scritto: >> >> I don't think it is, it is a descriptive term. The study of censorship regimes is a whole field in political science and communication. With 'censorship regimes' one does not mean authoritarian regimes, but every authority that sets rules, cultural or social norms on the limitation of the dissemination of information. 'Good taste', for example, is also a censorship regime. > > Unfortunately, this is not how the word "censorship" is used outside of that small circle, and it is not how it will be perceived by people in the broader Internet governance environment when reading this document. What is you method of knowing how the term is understood in 'the Internet governance environment'? Are the authors not part of that as well? Seem quite a big claim to make. There seems to be a clear disconnect in the perception of these terms between different audiences. So, to avoid misunderstandings, the document could rather just focus on describing techniques for content access control and removal without calling them names. > >> Il 29/05/2020 12:14 Lars Eggert ha scritto: >> >> I don't know who "we" here is, but there are certainly many cases where domain names have been seized that *some* consider censorship. For example: https://www.eff.org/deeplinks/2017/09/cat-domain-casualty-catalonian-independence-crackdown > > That's exactly the problem: mention that in this document as "censorship", and the document will (or, at least, will appear to) be a declaration of support for those that think that that behaviour is censorship, against those that think that it is not censorship (which include the national Spanish government and the European Union). We can try to tell the Spanish government that we are using "censorship" in the strictly academic sense of "enforcement of court rulings on online content", but I don't know how well this would fly. > This document does not say that every time such a technique is used, it is called censorship. It also does not say whether it is right or wrong. -- Niels ten Oever Researcher and PhD Candidate Datactive Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Fri May 29 06:23:54 2020 Return-Path: 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 AA60E3A0864 for ; Fri, 29 May 2020 06:23:52 -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 oMLdCOc_gOqy for ; Fri, 29 May 2020 06:23:51 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC153A0AD4 for ; Fri, 29 May 2020 06:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3973; q=dns/txt; s=iport; t=1590758614; x=1591968214; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=JVRjcUZa4yEahrPkgk5OCTos1wIv7jy3sqXDeA22Trw=; b=IONFrXq79DSY9XKHAtDPaHoisU/dxENpTI1Lpg5IH6Ro+0yfI5Kh3i3Y HVcnu6oD/1lhPkpCKKBW7RZx+1lelOHZrLTaOcCW7dMRPK7UONpS+aM+e Iprol72vS9vb8pOOI3Tvomn7TWA7IVtgXg7HMQoaHLmC/wysmaD97MS/a k=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzAADWC9Fe/xbLJq1cChoBAQEBAQE?= =?us-ascii?q?BAQEBAwEBAQESAQEBAQICAQEBAYIKgxhUASASLIQliQGHZSWTYogRBAcBAQE?= =?us-ascii?q?JAwEBJQoEAQGERAKCIyU4EwIDAQELAQEFAQEBAgEGBG2FWQyFcgEBAQECARg?= =?us-ascii?q?FBlYFCwsEFCoCAlcGE4MmAYJcIA+vCnaBMoQ6AYEWhQkKBoE4gVOLDIIAgTg?= =?us-ascii?q?MEIIfLj6CZwEDgTaDQTOCLQSYN4ELiVqPKH+CXoJ6gSaUSx6QUo1CqwSDSQI?= =?us-ascii?q?EBgUCFYFqIoFWMxoIGxVlAYI+PhIZDZB4iE6FRD8DMAI1AgYBBwEBAwmNWAE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.73,448,1583193600"; d="asc'?scan'208,217";a="26626592" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 May 2020 13:23:30 +0000 Received: from [10.61.239.124] ([10.61.239.124]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 04TDNTMp001607 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 May 2020 13:23:30 GMT From: Eliot Lear Message-Id: <6309FE45-F0AE-4F82-8454-9361A0439A26@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7368866F-1E33-4827-A57E-7B1BF8F54AA0"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 29 May 2020 15:23:27 +0200 In-Reply-To: Cc: Joseph Lorenzo Hall , "pearg@irtf.org" , Christopher Wood To: Lars Eggert References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> <79C21420-970E-46E2-9129-1886597924B1@cisco.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.239.124, [10.61.239.124] X-Outbound-Node: aer-core-3.cisco.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 13:23:53 -0000 --Apple-Mail=_7368866F-1E33-4827-A57E-7B1BF8F54AA0 Content-Type: multipart/alternative; boundary="Apple-Mail=_021A0348-7083-4F75-B456-0FA9307CC687" --Apple-Mail=_021A0348-7083-4F75-B456-0FA9307CC687 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Lars, > On 2020-5-28, at 19:26, Eliot Lear = wrote: >> It would strengthen your case if you can identify a domain name = seizure that is based on what we commonly view as censorship. Otherwise = skip the purpose. >=20 > I don't know who "we" here is, but there are certainly many cases = where domain names have been seized that *some* consider censorship. For = example: = https://www.eff.org/deeplinks/2017/09/cat-domain-casualty-catalonian-indep= endence-crackdown That, to me, is a far better reference for several reasons: It=E2=80=99s a clear attempt to interfere with information exchange by a = government (that really ticks all the boxes for all the definitions = I=E2=80=99ve seen). It demonstrates both a physical seizure and a domain seizure. Nice one! Eliot --Apple-Mail=_021A0348-7083-4F75-B456-0FA9307CC687 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Lars,

On 2020-5-28, at 19:26, Eliot = Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:
It would strengthen your = case if you can identify a domain name seizure that is based on what we = commonly view as censorship.  Otherwise skip the purpose.

I don't know who "we" here is, = but there are certainly many cases where domain names have been seized = that *some* consider censorship. For example: https://www.eff.org/deeplinks/2017/09/cat-domain-casualty-catal= onian-independence-crackdown

That, to me, is a far better reference = for several reasons:

  • It=E2=80=99s a clear = attempt to interfere with information exchange by a government (that = really ticks all the boxes for all the definitions I=E2=80=99ve = seen).
  • It demonstrates both a physical seizure and a = domain seizure.

Nice one!

Eliot
= --Apple-Mail=_021A0348-7083-4F75-B456-0FA9307CC687-- --Apple-Mail=_7368866F-1E33-4827-A57E-7B1BF8F54AA0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl7RDM8ACgkQh7ZrRtnS ejNjgQgAtHUrj9zQTPWujFlyyxhdAaIQoTB83jwSR3glXisqqN+Q4Q35lYTRRD5U UBMMmZjtZK/HhaSh8kEkOwU1Um5B2wz9psCXfojwD2u9heIL+GRP20J1MtKcyGIh AJp3KpSnyeJpatwjC0gsvxYvHyKOUSEtkq0bwypw5i2wp4WfR7BQEZBnMi7i3h0l jIIbKm9ZT3OxWivLx8mh1kTmV32jmEXxgs3GH7IJIkt5n/HgXGtlI2M3aSkmqnjJ 5TEZslCLAHYw9K25X1avjkh4j5xIWsyUI0y3MShQHaJOWXEOoWZEYDOOGwBc7rzl QVbD/gFLer92izc79eq3oUpAOTPnVw== =d05Q -----END PGP SIGNATURE----- --Apple-Mail=_7368866F-1E33-4827-A57E-7B1BF8F54AA0-- From nobody Fri May 29 07:31:03 2020 Return-Path: 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 9CAD53A091C for ; Fri, 29 May 2020 07:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=JxmPi6cr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q7Qc5/br 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 LCkXPjECrZr5 for ; Fri, 29 May 2020 07:31:01 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBFE03A0912 for ; Fri, 29 May 2020 07:30:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 5471617FF; Fri, 29 May 2020 10:30:52 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Fri, 29 May 2020 10:30:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm1; bh=33 X9cyJsTO3AojAHeITXi3ak3qo8Sj+eiMXYdyd0alM=; b=JxmPi6crv143HlM8Vh WRAvUlWdgQ7pTeNp2yewsQZgxQzvdHZIvLvsyMgOz5wfJnBiGvCXN8t0zBsF8iH5 7CzTbdDKT+f4tqQzToVUa1nsaUAbMf/2bFDtWowhkoJs6/gElAVgvs+zA/X739ac jwpLWkOgtXrJ2WiHGESSUcAtanCdwsGL/xLGq7NUyFRZuPCDUHrmWz4SHDj6k6ss 6UtYzgcImgGUtTtGZVXm4y8MTAYtedaOtS2jpYT14pzirU+V1UMnMolJh+AD358q HrCVE9UgdQUnT58oUBZSPc6kZigtBBw7Ipw0gdVK8NzaR4A8KbE0hEPn3sN1txw+ yIqw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=33X9cyJsTO3AojAHeITXi3ak3qo8Sj+eiMXYdyd0a lM=; b=q7Qc5/bruR+s6mqcq59kBxG+0hoX+0i/XCJXN25+pKwjAadwXEheBYWtw MS46kzZ9TiDfqFJiifNXYSWwOvPAruYyyvAMVKSjVb5yFbEFuywEsukhi3SCa0TV PkFHTd6psGe4XV1wYU8u/dqdjk4LGVYcHN8hiwwhhM+JRD19w4s49ez19qa1mNsc ua9qSkaLYiw7HDfBkiOpJ57gv8edIVXZHlzUA7UjePqwnKG0WhJyjJW/UfNCGf/3 iIhRPyeAMu79LnyOPKIaATc3oLDz/KFpkzriBLxlCwNEzCqXcugYTSWLrcp4qNyZ cKRLMIkKRVFYQLz+CXFBDpz8GedYw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvkedgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfvehh rhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvg htqeenucggtffrrghtthgvrhhnpeekffekveeghffgtdffieevudfgledthefhfedvvdeh leeivdegveegleefteejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 586733C00A1; Fri, 29 May 2020 10:30:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-504-g204cd6f-fm-20200527.002-g204cd6f2 Mime-Version: 1.0 Message-Id: In-Reply-To: <5F07139C-6493-4A4B-B690-5C807C0A63A0@cisco.com> References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> <79C21420-970E-46E2-9129-1886597924B1@cisco.com> <4A68E41D-EF4C-4675-8CFF-ECE0D708661C@cisco.com> <0dff13b6-079e-4cbb-bab7-284cd3bc81da@www.fastmail.com> <5F07139C-6493-4A4B-B690-5C807C0A63A0@cisco.com> Date: Fri, 29 May 2020 07:30:03 -0700 From: "Christopher Wood" To: "Eliot Lear" Cc: pearg@irtf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Pearg] =?utf-8?q?Research_Group_Last_Call_for_=22A_Survey_of_Wo?= =?utf-8?q?rldwide_Censorship_Techniques=22?= X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 14:31:03 -0000 Hi Eliot, Please see inline below. On Fri, May 29, 2020, at 1:34 AM, Eliot Lear wrote: >=20 > > To try and sharpen this point a bit: this document will certainly ha= ve gaps, and it's not a goal to fill all those gaps. This field moves qu= ickly enough that trying to doing so would likely be futile.=20 >=20 > I agree, and I am not suggesting that all gaps be covered. That was a=20= > straw man put forth by the author. Great! > > The chair decision to begin RGLC was based on the document's content= and history, which was deemed sufficiently thorough with respect to rel= evant issues that protocol designers might consider going forward. That = said, concrete suggestions to fill in those gaps are welcome! The author= s and RG should certainly review them if provided, though we won't block= progress waiting for additional content that doesn't substantially chan= ge the document's purpose. >=20 > I am sorry I didn=E2=80=99t catch this earlier, but I presumed that la= st call=20 > was meant to address these sorts of matters.=20 Indeed it is! I didn't mean to imply that other comments raised were not= up for discussion. On the contrary, I think they're helpful contributio= ns that can help improve the document.=20 > I would ask that it be=20 > noted that there is not a firm consensus on the document as it stands,= =20 > as several of us have raised substantial issues. Were I to explore the= m=20 > outside of this group in the broader IETF or research communities, I=20= > feel certain that you would not find consensus over the terminology.=20= > You needn=E2=80=99t take my word for this. >=20 > To restate my concerns, there are three major points and one further=20= > down that may or may not be a major point: >=20 > * The definition of censorship itself does not match common usage. > * There is no definition of =E2=80=9Ccensorship regime=E2=80=9D. > * The one reference I checked was clearly not appropriate in its=20 > usage, leading me to wonder about the others. >=20 > On terminology >=20 > It seems that it is being claimed that these are terms of art.=20 > Regardless, a properly justified definition with an appropriate=20 > reference is in order. This has not happened here. There are two=20 > specific problems with the first sentence and its reference. First, th= e=20 > text doesn=E2=80=99t match the reference given. It is never appropriat= e to=20 > mislead the reader in this way. Second, Wikipedia is not a primary=20 > source. It is especially important to get the definition right in=20 > interdisciplinary work, especially when we are talking about defining = a=20 > very politically charged term that the rest of the document is=20 > dedicated to ameliorating. Beyond the academic matter, as I have=20 > previously alluded, by not setting that context, the authors risk=20 > offending many practitioners dedicated to infrastructure protection in= =20 > the very first sentence of the first section. >=20 > Unless you find fault with my reasoning above, and I readily allow for= =20 > such a possibility, we must agree that this is an issue. If you place= =20 > the onus on me to solve it and I refuse, the issue would remain. Of=20= > course I am happy to be a part of solving the problem. As it happens,=20= > Joe himself put forth a perfectly fine way to put the work into=20 > context, to which I readily agreed, but then he himself rejected, even= =20 > though what he proposed is a close variant of what appears in the=20 > document=E2=80=99s abstract. The substance here is the difference betw= een=20 > =E2=80=9Ccontent" and =E2=80=9Cinformation=E2=80=9D and perhaps motiva= tion. I am not suggesting=20 > a full exploration of what censorship is, but some justification for=20= > the language. Same for =E2=80=9Ccensorship regime=E2=80=9D, given its = similar negative=20 > connotations. With no hat on, I mostly agree. I'll take a stab at addressing this in a= PR and share it on the list. We can iterate on the details there. :-) > On references >=20 > We have previously seen sloppy use of references in at least one other= =20 > RG. By chance, I have spotted two errors, one to the WP reference and=20= > the other only because I know one of the authors of the referenced=20 > work. I have not checked the others, but the pass rate right now is=20= > 0/2. I would strongly suggest that the other references be checked=20 > through broader review. Yep, these too are good issues to raise now. I'll file an issue to revie= w all references carefully before progressing.=20 > Adding the additional non-technical example >=20 > On =E2=80=9CNon-Technical [Prescription/Interference]=E2=80=9D. As I w= rote above, I=20 > don=E2=80=99t expect the authors to be exhaustive, but I am told that = the topic=20 > is out of scope, and yet the text remains. I would suggest an add,=20 > perhaps around =E2=80=9Cswaying public thought=E2=80=9D, to include so= mething like=20 > =E2=80=9Cadding financial liability=E2=80=9D. The reason I think the p= oint is important=20 > enough to raise is that from a scale perspective, the financial attack= =20 > may be the most effective attack of all against profit-based platforms= .=20 > Is it major or minor? I don=E2=80=99t know. I lean toward =E2=80=9Cmin= or=E2=80=9D only because=20 > the document might stand up without its mention, even though I would=20= > view it as an opportunity lost. If you have time, could you please suggest concrete text (ideally in the= form of a PR)? I think that'll make this discussion easier.=20 Thanks again for your review, feedback, and help improving the document!= Best, Chris From nobody Fri May 29 07:52:42 2020 Return-Path: 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 861073A0AB6 for ; Fri, 29 May 2020 07:52:34 -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 wEdniPe5tvEj for ; Fri, 29 May 2020 07:52:33 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3013A0ADE for ; Fri, 29 May 2020 07:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2296; q=dns/txt; s=iport; t=1590763953; x=1591973553; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=+ifng1bjVANoN8mi/ZKeqKULYnz7ObFV6Hgyyk08Vww=; b=ZktNl4bvxbr+3c1NklnJRay0We31lNGExCVa+o24slQsOVAWb8gfqf+R 5OwgFOhSaBdi670ZqnuULvgH8T72ptS4IbAl2BkQFnGNBPI/Luta9e+lO C2pv7lxF8Jy5el/AbI5WHoGuFS0WkT5O8m4Re51217AzLiun0gWDr6l1C s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BdCAAPIdFe/xbLJq1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCCgKBH4JLASASLIQliQGHZSWTYogRCAMBAQEMAQEvBAEBhEQ?= =?us-ascii?q?CgiMlOQUNAgMBAQsBAQUBAQECAQYEbYVlhXIBAQEBAgEYBQZWBQsLBAEJCio?= =?us-ascii?q?CAlcGE4Mmgl0grnoBS3aBMoVRhRs3gQGMX4IAgTgMEIJNPodiM4ItBLNDgl6?= =?us-ascii?q?CepVxHoJmiQaEZo1CqwRwglkCBAYFAhWBayGBVjMaCBsVZQGCPj4SGQ2QTBc?= =?us-ascii?q?VjhI/AzA3AgYBBwEBAwmNWAEB?= X-IronPort-AV: E=Sophos; i="5.73,448,1583193600"; d="scan'208,217"; a="26628547" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 May 2020 14:52:28 +0000 Received: from [10.61.239.124] ([10.61.239.124]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04TEqSdW000576 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 May 2020 14:52:28 GMT From: Eliot Lear Message-Id: <757CECF8-AE9B-40F9-8562-C7534F8536CA@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1D32EFC1-F9C6-40F9-9A4C-CEA99A620007" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 29 May 2020 16:52:27 +0200 In-Reply-To: Cc: pearg@irtf.org To: Christopher Wood References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <434A7CA0-DCE1-42A1-89B0-E9B8959B9343@isoc.org> <35B3B2B9-B1E7-41EF-B082-5F5EEF101B0D@cisco.com> <79C21420-970E-46E2-9129-1886597924B1@cisco.com> <4A68E41D-EF4C-4675-8CFF-ECE0D708661C@cisco.com> <0dff13b6-079e-4cbb-bab7-284cd3bc81da@www.fastmail.com> <5F07139C-6493-4A4B-B690-5C807C0A63A0@cisco.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.239.124, [10.61.239.124] X-Outbound-Node: aer-core-1.cisco.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 14:52:41 -0000 --Apple-Mail=_1D32EFC1-F9C6-40F9-9A4C-CEA99A620007 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Chris, Thanks for your response. I appreciate it. With regard to this: > On 29 May 2020, at 16:30, Christopher Wood = wrote: >=20 > If you have time, could you please suggest concrete text (ideally in = the form of a PR)? I think that'll make this discussion easier.=20 I will try to do this by mid-next week (it=E2=80=99s a holiday weekend = here in Switzerland). Eliot= --Apple-Mail=_1D32EFC1-F9C6-40F9-9A4C-CEA99A620007 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Chris,

Thanks for your response.  I appreciate it.  With = regard to this:


On 29 May 2020, at 16:30, Christopher Wood <caw@heapingbits.net>= wrote:

If you have time, could you = please suggest concrete text (ideally in the form of a PR)? I think = that'll make this discussion easier. 

I will try to do this by = mid-next week (it=E2=80=99s a holiday weekend here in = Switzerland).

Eliot
= --Apple-Mail=_1D32EFC1-F9C6-40F9-9A4C-CEA99A620007-- From nobody Fri May 29 08:39:24 2020 Return-Path: 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 D4FC13A0CA8 for ; Fri, 29 May 2020 08:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 NX_UZbJbA2AE for ; Fri, 29 May 2020 08:39:18 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199E53A0C9E for ; Fri, 29 May 2020 08:39:18 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id z13so3137329ljn.7 for ; Fri, 29 May 2020 08:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QA4KTiR0pxvY3O+7J3ur6Ow/JESgC/m6Nz8dBidjUyU=; b=uUEpSjtJF8lO866uRgayeIJdediFNeGEGCydXlYppW/uRRT97AT4elAguyFoakfw6A JPMDqEUEa5uNOMMQ5RVAbnI0EuIvei/AcFBD608EUZrTqot0ueIoiPUG8fcQXZ9h+dtM 9DJ0UToY7QsdQCExyWIGHnzCzTiokLo0BCh6L0vKnFKuXZFMUOLirtetm7igGuGQEtIh Wt/sXbPbcpc8CQ/wWs9gQdEsip/bQ6wSBcfs29GspFxv8l1VewcBOh6AEeRPlSTvZueX T3U4ZrQwBnq2ROx7sEQfOOnai3c2Snag9RhzaK/qZQ8Jcpi433Mrng9TaX1ZqabNBViQ 7Y4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QA4KTiR0pxvY3O+7J3ur6Ow/JESgC/m6Nz8dBidjUyU=; b=bAwCEgJmZiUmQ1XmGhRemN1csxgBVro4rW7Wau8G5t/cXUQ+Cbnsqglsibu7psIkpf GuZ0APiHT8rQegIUz8kkrGdmQOLW4EwwSae3tIKUr5IomBxzcByXtnjhHVEsnR9D58Oq byG9nFwDGF+6rDB5lnNSl0UI3wIIMU1VtBw+g/xcckrm9A6++y7BtpnurJUuzVW3yGdM vVtHGEJbQpigV+MoX5l0ASbnzEM/dzJp6G9FfIqk1K3KbVapu2CsKqi8ESwa9PQLPt6+ eWUTMQhIOmJ8LMy/GLiteTgXr29nOgSbjyj3OfPrHLcsP40KTXkgGbdTvSYDBQGLUiED x5Wg== X-Gm-Message-State: AOAM532a5zm+CqqRZ18auu/lBzRmE/p1Vjl8GF27MQZ0hoGUe7lGHYqi swPX0ximTEzNnM56Jvw7e1uN+ZC7wgBfpdT6d8qgwnqm5no= X-Google-Smtp-Source: ABdhPJz23ZkyeiLbs/16O5/VE0t2fAap7rQ7FtkuCEAPFbAYu14DAt3FdZCx+T8yivo3tpg76+oR7mM4/QN71i4Qtcw= X-Received: by 2002:a2e:3201:: with SMTP id y1mr4828434ljy.13.1590766756362; Fri, 29 May 2020 08:39:16 -0700 (PDT) MIME-Version: 1.0 References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Fri, 29 May 2020 08:38:40 -0700 Message-ID: To: Eliot Lear Cc: Christopher Wood , pearg@irtf.org Content-Type: multipart/alternative; boundary="0000000000006f17ca05a6cb3f48" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 15:39:20 -0000 --0000000000006f17ca05a6cb3f48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 26, 2020 at 3:02 AM Eliot Lear wrote: > Hi Chris, > > Several points. > > I have a concern about the use of the term =E2=80=9Ccensorship=E2=80=9D. = Is removal of > fraudulent material censorship? How about taking down a system that part > of a DOS attack? Is taking down a system that is attacking critical > infrastructure censorship? Is botnet disruption censorship? Are FCC > frequency rules against harmful interference censorship? By the sweeping > definition given, they are. This immediately diminishes the credibility > of the work because it flies in the face of what normal people think > censorship is. > Ignoring the term "censorship" for a moment, it seems to me that there are two broad content-neutral categories: - Preventing two (or more entities) who want to communicate from doing so - Preventing an entity who wants to communicate with an unwilling peer or peers A number of the examples you cite (DoS, attacks) fall into the second category and I don't think that they should be swept in here, not only because they are different from a political economy perspective but because they often, though not always, involve different technical mechanisms. You cite two other examples which seem like they might be more difficult: (1) fraudulent material and (2) frequency regulations. In both cases, whether they are censorship actually depends on how they are executed. To take the frequency regulations example first, if the government sets up frequency regulations that prevent people from communicating *at all* then potentially that is censorship. In the US this often gets framed as "time place and manner" versus "content" restrictions. However, I don't think this definition would necessarily sweep that in. Fraudulent material (and malware downloads, etc.) seem like more interesting cases, but i think there's a way to think of them as the receiver of the communication not really wanting to receive them if they were fully informed. And I think there's a pretty strong argument that if it is made impossible to access this data (as opposed to preventing it from being automatically processed) than that is in fact an example of censorship. -Ekr --0000000000006f17ca05a6cb3f48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 26, 2020 at 3:02 AM Eliot= Lear <lear=3D40cisco.com@= dmarc.ietf.org> wrote:
Hi Chris,

Several points.

I have a concern about the use of the term =E2=80=9Ccensorship=E2=80=9D.=C2= =A0 Is removal of fraudulent material censorship?=C2=A0 How about taking do= wn a system that part of a DOS attack?=C2=A0 Is taking down a system that i= s attacking critical infrastructure censorship?=C2=A0 Is botnet disruption = censorship?=C2=A0 Are FCC frequency rules against harmful interference cens= orship?=C2=A0 By the sweeping definition given, they are.=C2=A0 This=C2=A0 = immediately diminishes the credibility of the work because it flies in the = face of what normal people think censorship is.

Ignoring the term "censorship" for a moment, it seems to= me that there are two broad content-neutral categories:

=
- Preventing two (or more entities) who want to communicate from= doing so
- Preventing an entity who wants to communicate with an= unwilling peer or peers

A number of the examples = you cite (DoS, attacks) fall into the second category and I don't think= that they should be swept in here, not only because they are different fro= m a political economy perspective but because they often, though not always= , involve different technical mechanisms.

You= cite two other examples which seem like they might be more difficult:
<= /div>
(1) fraudulent material and (2) frequency regulations. In both c= ases, whether they are censorship actually depends on how they are executed= . To take the frequency regulations example first, if the government sets u= p frequency regulations that prevent people from communicating *at all* the= n potentially that is censorship. In the US this often gets framed as "= ;time place and manner" versus "content" restrictions. Howev= er, I don't think this definition would necessarily sweep that in.
=

Fraudulent material (and malware downloads, etc.)= seem like more interesting cases, but i think there's a way to think o= f them as the receiver of the communication not really wanting to receive t= hem if they were fully informed. And I think there's a pretty strong ar= gument that if it is made impossible to access this data (as opposed to pre= venting it from being automatically processed) than that is in fact an exam= ple of censorship.

-Ekr

--0000000000006f17ca05a6cb3f48-- From nobody Fri May 29 10:29:44 2020 Return-Path: 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 839923A0877 for ; Fri, 29 May 2020 10:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 yz6bsj0AKums for ; Fri, 29 May 2020 10:29:39 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CEC13A08EB for ; Fri, 29 May 2020 10:29:39 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id k5so159180lji.11 for ; Fri, 29 May 2020 10:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xE38JNbc/vE1Ht+H1uwquuQGbjqI1hXQTNXXxh48X1s=; b=RxTE+x890qBCLwRhzV9f4UplthhkzJ9rqTCq7u22StSv7E+DD0ufYeEuWfaXsb+EKJ b5bAl8DYnvN/FaG3O6karcGuFLTpLdgO9tYIvSpGFsFDWIcqqDNra5LiryW+GX40wvna z2K6bH5n4oWUC+4YkhYSuOoEhq96acYVJ1hOY9SCEry8C6cqRznLX7GKV/YN1pWzUqnR 5VO/i6tIm6CeOlj44leqaVTsztTVTBNI/+PNijpdfOUwzU2YzwdDSODYSzhXTHHYyLQ7 g0dZ8D0pacOaslLZkNTxAFhFJr9fjygocxpspL6xyb4llfFK3lKrVz9ArK3hxKFIxyrb LfwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xE38JNbc/vE1Ht+H1uwquuQGbjqI1hXQTNXXxh48X1s=; b=sTG2GwC3twNUwaFXkPEkNJiX08YCz7/mMWJmz6Gq7pGeJzK5Ljyg994TTMzygUsqGN IUVnNATfcEYqawqtFIn8cbfV6GxLbjYmcr40mOBMXxpa+OPs0AifEzX2EGgffM56gpk7 soZKNrgy7RxL+jc8EmLs+BFQBssZVza57EWuz6yj3pZqpUOKMoZDHnjqDExs5YnSf1N6 TWreGjIYpQA6pZ16aDbLwbFEGg+i8Q9ABNznxLSimc0HEOdSCtgrDCg0yIJqXHk7NmuL i6f06J3viinkue4NF8BC5GbmvL47pdTqLfVWT6vgr0TwSKGDelOLmpcA4C15dRI0jmCv St3Q== X-Gm-Message-State: AOAM532Lw+LueBlbKsFZW5/8FDSK6zPGe5qu+CkaUA8W6xhvS0A2QL6P oDPj0iSKl7P5GOmXMFGGWd66ayvAbqrmjUr2SChhWQ== X-Google-Smtp-Source: ABdhPJwI1NUvffR3fxz6Ey+ylhcJBnQxAGHZpZQV2R+La3iunmT8wn1WKR9Ww/Gq/2Ufwx/wDxWjB+yzeQhj8fTHmJ0= X-Received: by 2002:a2e:3201:: with SMTP id y1mr5059188ljy.13.1590773376610; Fri, 29 May 2020 10:29:36 -0700 (PDT) MIME-Version: 1.0 References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> In-Reply-To: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> From: Eric Rescorla Date: Fri, 29 May 2020 10:28:59 -0700 Message-ID: To: Christopher Wood Cc: pearg@irtf.org Content-Type: multipart/alternative; boundary="000000000000080e5505a6ccca68" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 17:29:43 -0000 --000000000000080e5505a6ccca68 Content-Type: text/plain; charset="UTF-8" Document: draft-irtf-pearg-censorship-03.txt S 2. We describe three elements of Internet censorship: prescription, identification, and interference. The document contains three major sections, each corresponding to one of these elements. Prescription is the process by which censors determine what types of material they should block, i.e., deciding to block a list of pornographic websites. Identification is the process by which censors classify specific traffic to be blocked or impaired, i.e., blocking or impairing all webpages containing "sex" in the title or traffic to www.sex.example. Interference is the process by which censors I'm not finding this distinction super clear. It seems to me like deciding to block www.sex.example and "impairing...traffic to www.sex.example" are pretty similar. Not trying to force a new model on you, but I tend to think of this process as: 1. Decide what kind of material you want to block (e.g., material about sex). [This is what I expected prescription to be] 2. Determine what the conceptual indicia of that material are (this might be "contains the string sex" or "is one of these websites A, B, C") 3. Determine precisely how you identify the indicia on the network (DNS, SNI, etc.) 4. Determine how to block the communications once identified. S 3.1. Internet censorship necessarily takes place over a network. Network You say this but then later you give an example of endpoint censorship. I feel like this section might be better if it tried to impose some hierarchy here. From my perspective, there are four main categories of control points: - The network itself [ISPs, Backbone, Institutional ISPs] - The services side of communications [hosting providers, cloud providers, CDNs, etc.] - Services which are necessary to communicate but not really part of it [CAs, DNS, etc.] - The client endpoint side That might make this easier to read o Certificate Authorities for Public-Key Infrastructures (PKIs): Authorities that issue cryptographically secured resources can be a significant point of control. Certificate Authorities that issue certificates to domain holders for TLS/HTTPS (the Web PKI) or Regional/Local Internet Registries (RIRs) that issue Route Origination Authorizations (ROAs) to BGP operators can be forced to issue rogue certificates that may allow compromise, i.e., by allowing censorship software to engage in identification and interference where not possible before. This may allow, for example, adversarial traffic routing or TLS interception. This is true, though CT is intended to make this much harder. I would add that CAs can be forced to revoke certificates, which is a threat that CT does not attempt to prevent. o Services: Application service providers can be pressured, coerced, or legally required to censor specific content or data flows. Service providers naturally face incentives to maximize their potential customer base and potential service shutdowns or legal liability due to censorship efforts may seem much less attractive than potentially excluding content, users, or uses of their service. Services have increasingly become focal points of censorship discussions, as well as the focus of discussions of moral imperatives to use censorship tools. It's a little hard to know if this text is talking about Facebook or AWS. Maybe split? At all levels of the network hierarchy, the filtration mechanisms used to detect undesirable traffic are essentially the same: a censor either directly sniffs transmitting packets and identifies undesirable content, and then uses a blocking or shaping mechanism to prevent or impair access, or requests that an actor ancillary to the censor, such as a private entity, perform these functions. I don't think this claim is right. For instance where do registry takedowns or DNS blacklists fit in. Neither of them "directly sniffs transmitting packets" (a weird phrase as-is). S 3.2.1. Tradeoffs: Request Identification is a technically straight-forward identification method that can be easily implemented at the Backbone or ISP level. The hardware needed for this sort of identification is cheap and easy-to-acquire, making it desirable when budget and scope are a concern. HTTPS will encrypt the relevant request and response fields, so pairing with transport identification (see Section 3.3.1) is necessary for HTTPS filtering. However, some countermeasures such I think you just want to remove "such" can trivially defeat simple forms of HTTP Request Header Identification. For example, two cooperating endpoints - an instrumented web server and client - could encrypt or otherwise obfuscate the "host" header in a request, potentially thwarting techniques that match against "host" header values. This is true, but seems kinda limited. 3.2.4.1. In encrypted connections using Transport Layer Security (TLS), there may be servers that host multiple "virtual servers" at a given network address, and the client will need to specify in the (unencrypted) Client Hello message which domain name it seeks to connect to (so that the server can respond with the appropriate TLS certificate) using the Server Name Indication (SNI) TLS extension [RFC6066]. Since SNI is often sent in the clear, censors and I understand that the cert field is also used for blocking. Domain fronting has been one popular way to avoid identification by censors [Fifield-2015]. To avoid identification by censors, applications using domain fronting put a different domain name in the SNI extension than the one encrypted by HTTPS. The visible SNI would indicate an unblocked domain, while the blocked domain remains hidden I would say "than in the Host: header, which is protected by HTTPS" S 3.3.1. Of the various shallow packet inspection methods, Transport Header Identification is the most pervasive, reliable, and predictable type of identification. Transport headers in TCP/IP or QUIC contain a few invaluable pieces of information that must be transparent for traffic to be successfully routed: destination and source IP address and port. Destination and Source IP are doubly useful, as not only does it allow a censor to block undesirable content via IP blocklisting, Saying "TCP/IP or QUIC" is weird as QUIC runs over UDP. And of course UDP has its own headers, as does RTP. I would just say "Transport headers" Header identification is trivial to implement, but is difficult to implement in backbone or ISP routers at scale, and is therefore typically implemented with DPI. Blocklisting an IP is equivalent to Does this mean "using DPI" or "along with DPI" Header identification is trivial to implement, but is difficult to implement in backbone or ISP routers at scale, and is therefore typically implemented with DPI. Blocklisting an IP is equivalent to installing a /32 route on a router. However, due to limited flow The IPv6 people will be mad. Port-blocking is generally not useful because many types of content share the same port and it is possible for censored applications to change their port. For example, most HTTP traffic goes over port 80, so the censor cannot differentiate between restricted and allowed web content solely on the basis of port. Another example is HTTPS port 443, which in addition to handling secure web traffic now also carries DNS-over-HTTPS [RFC8484] traffic; this can frustrate techniques that rely on cleartext DNS over port 53 for censorship, parental control, and other uses [SSAC-109-2020]. Port allowlisting True, but I feel like this is actually a different category of thing, because *this* section is about shallow blocking, whereas DNS-based blocking of specific domains is definitely not shallow. conjunction with other identification mechanisms. For example, a censor could block the default HTTPS port, port 443, thereby forcing most users to fall back to HTTP. An important counter-example is that port 25 (SMTP) has long been blocked on residential ISPs' networks, ostensibly to reduce the potential for email spam, but also prohibiting residential ISP customers to run their own email servers. This "ostensibly" seems unnecessarily sarcastic. It's not clear why ISPs would care that much (price discrimination?). Anyway, if you want to make this point, I think you could say something more netural which had the same impact. S 3.3.2. I'm having trouble with your taxonomy here because a lot of the protocol identification work seems like it's more application layer than transport layer, but you have it in 3.3. S 4.1.1. There is some good text in this section, but I feel like it's not doing a good job of distinguishing three attack modalities: - Lying by the nameserver - On-path interception by an attacker - off-path cache poisoning This has been such a persistent point of confusion with DoH that I think it's worth clarifying. > than ideal censorship mechanism. Additionally, the above mechanisms > rely on DNSSEC not being deployed or DNSSEC validation not being > active on the client or recursive resolver (neither of which are hard > to imagine given limited deployment of DNSSEC and limited client > support for DNSSEC validation). This is not quite correct. If you want to redirect a user then you need to content with DNSSEC, but if you just want to block them, then you can just provide a record which won't validate and that will have the same effect. S 4.2.2. I note that packet dropping is often how you implement traffic shaping. S 4.2.3. Packet injection, generally, refers to a man-in-the-middle (MITM) network interference technique that spoofs packets in an established traffic stream. RST packets are normally used to let one side of TCP connection know the other side has stopped sending information, and thus the receiver should close the connection. RST Packet Injection is a specific type of packet injection attack that is used to interrupt an established stream by sending RST packets to both sides of a TCP connection; as each receiver thinks the other has dropped the connection, the session is terminated. QUIC is not vulnerable to these types of injection attacks (See [I-D.ietf-quic-transport] for more details). This isn't totally true. QUIC is not vulnerable to this once the connection is set up, but it *is* vulnerable during setup. The two paragraphs in Trade-offs are confusing because you don't start out with the threat model. There are three threat models here: - On-path and fast - On-path and slow - Off-path In general, the argument you seem to be making is that on-path and fast is expensive but on-path and slow is cheap. I'm not sure the Blind injection stuff is that relevant: you would need to know the host/port coordinates which are fairly expensive to obtain. Do we know if anyone uses totally blind RSTs for censorship? My impression is that it's primarily useful for long running connectons like BGP. S 4.3.2. Trade-offs: The impact to a network disconnection in a region is huge and absolute; the censor pays for absolute control over digital information with all the benefits the Internet brings; This seems backwards. You pay by losing all the benefits. this is never a long-term solution for any rational censor and is normally only used as a last resort in times of substantial unrest. This seems unnecessarily judgemental. What's rational depends on incentives. Also, this section seems weird because it doesn't talk about fake BGP announcements for *other* sites, which we know is common and doesn't have anywhere near the impact yoou discuss here. S 6. I would remove this entirely. I don't think it really belongs -Ekr On Wed, May 20, 2020 at 10:00 AM Christopher Wood wrote: > This is the research group last call for the "A Survey of Worldwide > Censorship Techniques" (draft-irtf-pearg-censorship) draft available here: > > https://datatracker.ietf.org/doc/draft-irtf-pearg-censorship/ > > Please review the document and send your comments to the list by June 5, > 2020. Feedback may also be sent to the GitHub repository located here: > > https://github.com/IRTF-PEARG/rfc-censorship-tech > > Thanks, > Chris, on behalf of the chairs > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > --000000000000080e5505a6ccca68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Document: draft-irtf-pearg-censorship-03.txt

S 2.=C2=A0 =C2=A0 We describe three elements of Internet censorship: prescrip= tion,
=C2=A0 =C2=A0 identification, and interference.=C2=A0 The document= contains three major
=C2=A0 =C2=A0 sections, each corresponding to one = of these elements.=C2=A0 Prescription
=C2=A0 =C2=A0 is the process by wh= ich censors determine what types of material they
=C2=A0 =C2=A0 should b= lock, i.e., deciding to block a list of pornographic
=C2=A0 =C2=A0 websi= tes.=C2=A0 Identification is the process by which censors classify
=C2= =A0 =C2=A0 specific traffic to be blocked or impaired, i.e., blocking or=C2=A0 =C2=A0 impairing all webpages containing "sex" in the tit= le or traffic to
=C2=A0 =C2=A0 www.sex.example.=C2=A0 Interference is th= e process by which censors

I'm not finding this distinction supe= r clear. It seems to me like
deciding to block www.sex.example and "= ;impairing...traffic to
www.sex.example" are pretty similar.
Not trying to force a new model on you, but I tend to think of this
pro= cess as:

1. Decide what kind of material you want to block (e.g., ma= terial about
=C2=A0 =C2=A0sex). [This is what I expected prescription to= be]

2. Determine what the conceptual indicia of that material are (= this might
=C2=A0 =C2=A0be "contains the string sex" or "= is one of these websites A, B, C")

3. Determine precisely how y= ou identify the indicia on the network
=C2=A0 =C2=A0(DNS, SNI, etc.)
=
4. Determine how to block the communications once identified.

S 3.1.
=C2=A0 =C2=A0Internet censorship necessarily takes place over a= network.=C2=A0 Network

You say this but then later you give an exam= ple of endpoint censorship.


I feel like this section might be be= tter if it tried to impose some
hierarchy here. From my perspective, the= re are four main categories
of control points:

- The network itse= lf [ISPs, Backbone, Institutional ISPs]
- The services side of communica= tions [hosting providers, cloud
=C2=A0 providers, CDNs, etc.]
- Servi= ces which are necessary to communicate but not really
=C2=A0 part of it = [CAs, DNS, etc.]
- The client endpoint side

That might make this = easier to read


=C2=A0 =C2=A0 o =C2=A0Certificate Authorities for= Public-Key Infrastructures (PKIs):
=C2=A0 =C2=A0 =C2=A0 =C2=A0Authoriti= es that issue cryptographically secured resources can be
=C2=A0 =C2=A0 = =C2=A0 =C2=A0a significant point of control.=C2=A0 Certificate Authorities = that
=C2=A0 =C2=A0 =C2=A0 =C2=A0issue certificates to domain holders for= TLS/HTTPS (the Web PKI)
=C2=A0 =C2=A0 =C2=A0 =C2=A0or Regional/Local In= ternet Registries (RIRs) that issue Route
=C2=A0 =C2=A0 =C2=A0 =C2=A0Ori= gination Authorizations (ROAs) to BGP operators can be forced
=C2=A0 =C2= =A0 =C2=A0 =C2=A0to issue rogue certificates that may allow compromise, i.e= ., by
=C2=A0 =C2=A0 =C2=A0 =C2=A0allowing censorship software to engage = in identification and
=C2=A0 =C2=A0 =C2=A0 =C2=A0interference where not = possible before.=C2=A0 This may allow, for
=C2=A0 =C2=A0 =C2=A0 =C2=A0ex= ample, adversarial traffic routing or TLS interception.

This is true= , though CT is intended to make this much harder. I would
add that CAs c= an be forced to revoke certificates, which is a threat
that CT does not = attempt to prevent.

=C2=A0 =C2=A0 o =C2=A0Services: Application serv= ice providers can be pressured, coerced,
=C2=A0 =C2=A0 =C2=A0 =C2=A0or l= egally required to censor specific content or data flows.
=C2=A0 =C2=A0 = =C2=A0 =C2=A0Service providers naturally face incentives to maximize their<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0potential customer base and potential service= shutdowns or legal
=C2=A0 =C2=A0 =C2=A0 =C2=A0liability due to censorsh= ip efforts may seem much less attractive
=C2=A0 =C2=A0 =C2=A0 =C2=A0than= potentially excluding content, users, or uses of their
=C2=A0 =C2=A0 = =C2=A0 =C2=A0service.=C2=A0 Services have increasingly become focal points = of
=C2=A0 =C2=A0 =C2=A0 =C2=A0censorship discussions, as well as the foc= us of discussions of
=C2=A0 =C2=A0 =C2=A0 =C2=A0moral imperatives to use= censorship tools.

It's a little hard to know if this text is ta= lking about Facebook
or AWS. Maybe split?


=C2=A0 =C2=A0 =C2= =A0 At all levels of the network hierarchy, the filtration mechanisms
= =C2=A0 =C2=A0 =C2=A0 used to detect undesirable traffic are essentially the= same: a censor
=C2=A0 =C2=A0 =C2=A0 either directly sniffs transmitting= packets and identifies
=C2=A0 =C2=A0 =C2=A0 undesirable content, and th= en uses a blocking or shaping mechanism to
=C2=A0 =C2=A0 =C2=A0 prevent = or impair access, or requests that an actor ancillary to the
=C2=A0 =C2= =A0 =C2=A0 censor, such as a private entity, perform these functions.
I don't think this claim is right. For instance where do registry
= takedowns or DNS blacklists fit in. Neither of them "directly sniffstransmitting packets" (a weird phrase as-is).


S 3.2.1.=C2=A0 =C2=A0Tradeoffs: Request Identification is a technically straight-f= orward
=C2=A0 =C2=A0identification method that can be easily implemented= at the Backbone
=C2=A0 =C2=A0or ISP level.=C2=A0 The hardware needed fo= r this sort of identification is
=C2=A0 =C2=A0cheap and easy-to-acquire,= making it desirable when budget and scope
=C2=A0 =C2=A0are a concern.= =C2=A0 HTTPS will encrypt the relevant request and response
=C2=A0 =C2= =A0fields, so pairing with transport identification (see Section 3.3.1)
= =C2=A0 =C2=A0is necessary for HTTPS filtering.=C2=A0 However, some counterm= easures such

I think you just want to remove "such"

=C2=A0 =C2=A0can trivially defeat simple forms of HTTP Request Header<= br>=C2=A0 =C2=A0Identification.=C2=A0 For example, two cooperating endpoint= s - an
=C2=A0 =C2=A0instrumented web server and client - could encrypt o= r otherwise
=C2=A0 =C2=A0obfuscate the "host" header in a requ= est, potentially thwarting
=C2=A0 =C2=A0techniques that match against &q= uot;host" header values.

This is true, but seems kinda limited.=


3.2.4.1.

=C2=A0 =C2=A0In encrypted connections using Tra= nsport Layer Security (TLS), there
=C2=A0 =C2=A0may be servers that host= multiple "virtual servers" at a given
=C2=A0 =C2=A0network ad= dress, and the client will need to specify in the
=C2=A0 =C2=A0(unencryp= ted) Client Hello message which domain name it seeks to
=C2=A0 =C2=A0con= nect to (so that the server can respond with the appropriate TLS
=C2=A0 = =C2=A0certificate) using the Server Name Indication (SNI) TLS extension
= =C2=A0 =C2=A0[RFC6066].=C2=A0 Since SNI is often sent in the clear, censors= and

I understand that the cert field is also used for blocking.
=
=C2=A0 =C2=A0Domain fronting has been one popular way to avoid identifi= cation by
=C2=A0 =C2=A0censors [Fifield-2015].=C2=A0 To avoid identifica= tion by censors,
=C2=A0 =C2=A0applications using domain fronting put a d= ifferent domain name in the
=C2=A0 =C2=A0SNI extension than the one encr= ypted by HTTPS.=C2=A0 The visible SNI would
=C2=A0 =C2=A0indicate an unb= locked domain, while the blocked domain remains hidden

I would say &= quot;than in the Host: header, which is protected by HTTPS"

S 3.3.1.

=C2=A0 =C2=A0Of the various shallow packet inspection meth= ods, Transport Header
=C2=A0 =C2=A0Identification is the most pervasive,= reliable, and predictable type
=C2=A0 =C2=A0of identification.=C2=A0 Tr= ansport headers in TCP/IP or QUIC contain a few
=C2=A0 =C2=A0invaluable = pieces of information that must be transparent for traffic
=C2=A0 =C2=A0= to be successfully routed: destination and source IP address and
=C2=A0 = =C2=A0port.=C2=A0 Destination and Source IP are doubly useful, as not only = does
=C2=A0 =C2=A0it allow a censor to block undesirable content via IP = blocklisting,

Saying "TCP/IP or QUIC" is weird as QUIC run= s over UDP. And of course
UDP has its own headers, as does RTP. I would = just say "Transport headers"


=C2=A0 =C2=A0Header ident= ification is trivial to implement, but is difficult to
=C2=A0 =C2=A0impl= ement in backbone or ISP routers at scale, and is therefore
=C2=A0 =C2= =A0typically implemented with DPI.=C2=A0 Blocklisting an IP is equivalent t= o

Does this mean "using DPI" or "along with DPI"=

=C2=A0 =C2=A0Header identification is trivial to implement, but is = difficult to
=C2=A0 =C2=A0implement in backbone or ISP routers at scale,= and is therefore
=C2=A0 =C2=A0typically implemented with DPI.=C2=A0 Blo= cklisting an IP is equivalent to
=C2=A0 =C2=A0installing a /32 route on = a router.=C2=A0 However, due to limited flow

The IPv6 people will be= mad.


=C2=A0 =C2=A0Port-blocking is generally not useful because= many types of content
=C2=A0 =C2=A0share the same port and it is possib= le for censored applications to
=C2=A0 =C2=A0change their port.=C2=A0 Fo= r example, most HTTP traffic goes over port 80,
=C2=A0 =C2=A0so the cens= or cannot differentiate between restricted and allowed web
=C2=A0 =C2=A0= content solely on the basis of port.=C2=A0 Another example is HTTPS port=C2=A0 =C2=A0443, which in addition to handling secure web traffic now als= o
=C2=A0 =C2=A0carries DNS-over-HTTPS [RFC8484] traffic; this can frustr= ate
=C2=A0 =C2=A0techniques that rely on cleartext DNS over port 53 for = censorship,
=C2=A0 =C2=A0parental control, and other uses [SSAC-109-2020= ].=C2=A0 Port allowlisting

True, but I feel like this is actually a = different category of thing,
because *this* section is about shallow blo= cking, whereas DNS-based
blocking of specific domains is definitely not = shallow.


=C2=A0 =C2=A0conjunction with other identification mech= anisms.=C2=A0 For example, a
=C2=A0 =C2=A0censor could block the default= HTTPS port, port 443, thereby forcing
=C2=A0 =C2=A0most users to fall b= ack to HTTP.=C2=A0 An important counter-example is
=C2=A0 =C2=A0that por= t 25 (SMTP) has long been blocked on residential ISPs'
=C2=A0 =C2=A0= networks, ostensibly to reduce the potential for email spam, but also
= =C2=A0 =C2=A0prohibiting residential ISP customers to run their own email s= ervers.

This "ostensibly" seems unnecessarily sarcastic. I= t's not clear
why ISPs would care that much (price discrimination?).= Anyway,
if you want to make this point, I think you could say something=
more netural which had the same impact.


S 3.3.2.
I'm = having trouble with your taxonomy here because a lot of the
protocol ide= ntification work seems like it's more application
layer than transpo= rt layer, but you have it in 3.3.


S 4.1.1.
There is some good= text in this section, but I feel like it's
not doing a good job of = distinguishing three attack modalities:

- Lying by the nameserver- On-path interception by an attacker
- off-path cache poisoning
This has been such a persistent point of confusion with DoH that
I thin= k it's worth clarifying.

> =C2=A0 than ideal censorship mecha= nism.=C2=A0 Additionally, the above mechanisms
> =C2=A0 rely on DNSSE= C not being deployed or DNSSEC validation not being
> =C2=A0 active o= n the client or recursive resolver (neither of which are hard
> =C2= =A0 to imagine given limited deployment of DNSSEC and limited client
>= ; =C2=A0 support for DNSSEC validation).

This is not quite correct. = If you want to redirect a user then you
need to content with DNSSEC, but= if you just want to block them,
then you can just provide a record whic= h won't validate and that
will have the same effect.


S 4.= 2.2.
I note that packet dropping is often how you implement traffic
s= haping.



S 4.2.3.
=C2=A0 =C2=A0Packet injection, generally= , refers to a man-in-the-middle (MITM)
=C2=A0 =C2=A0network interference= technique that spoofs packets in an established
=C2=A0 =C2=A0traffic st= ream.=C2=A0 RST packets are normally used to let one side of TCP
=C2=A0 = =C2=A0connection know the other side has stopped sending information, and=C2=A0 =C2=A0thus the receiver should close the connection.=C2=A0 RST Pac= ket Injection
=C2=A0 =C2=A0is a specific type of packet injection attack= that is used to
=C2=A0 =C2=A0interrupt an established stream by sending= RST packets to both sides
=C2=A0 =C2=A0of a TCP connection; as each rec= eiver thinks the other has dropped
=C2=A0 =C2=A0the connection, the sess= ion is terminated.=C2=A0 QUIC is not vulnerable to
=C2=A0 =C2=A0these ty= pes of injection attacks (See [I-D.ietf-quic-transport] for
=C2=A0 =C2= =A0more details).

This isn't totally true. QUIC is not vulnerabl= e to this once the
connection is set up, but it *is* vulnerable during s= etup.

The two paragraphs in Trade-offs are confusing because you don= 't
start out with the threat model. There are three threat modelshere:

- On-path and fast
- On-path and slow
- Off-path
In general, the argument you seem to be making is that on-path
and fast= is expensive but on-path and slow is cheap. I'm not
sure the Blind = injection stuff is that relevant: you would
need to know the host/port c= oordinates which are fairly expensive
to obtain. Do we know if anyone us= es totally blind RSTs
for censorship? My impression is that it's pri= marily useful
for long running connectons like BGP.


S 4.3.2.<= br>
=C2=A0 =C2=A0Trade-offs: The impact to a network disconnection in a = region is huge
=C2=A0 =C2=A0and absolute; the censor pays for absolute c= ontrol over digital
=C2=A0 =C2=A0information with all the benefits the I= nternet brings;

This seems backwards. You pay by losing all the bene= fits.

=C2=A0 =C2=A0this is never
=C2=A0 =C2=A0a long-term solutio= n for any rational censor and is normally only
=C2=A0 =C2=A0used as a la= st resort in times of substantial unrest.

This seems unnecessarily j= udgemental. What's rational depends on
incentives.

Also, this= section seems weird because it doesn't talk about
fake BGP announce= ments for *other* sites, which we know is
common and doesn't have an= ywhere near the impact yoou discuss
here.


S 6.
I would rem= ove this entirely. I don't think it really belongs

-Ekr

On We= d, May 20, 2020 at 10:00 AM Christopher Wood <caw@heapingbits.net> wrote:
This is the research group last call for t= he "A Survey of Worldwide Censorship Techniques" (draft-irtf-pear= g-censorship) draft available here:

=C2=A0 =C2=A0https://datatracker.ietf.o= rg/doc/draft-irtf-pearg-censorship/

Please review the document and send your comments to the list by June 5, 20= 20. Feedback may also be sent to the GitHub repository located here:

=C2=A0 =C2=A0https://github.com/IRTF-PEARG/rfc-cens= orship-tech

Thanks,
Chris, on behalf of the chairs

--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg
--000000000000080e5505a6ccca68-- From nobody Fri May 29 10:37:14 2020 Return-Path: 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 460FB3A0EF1 for ; Fri, 29 May 2020 10:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 DlFbz6WQFZNH for ; Fri, 29 May 2020 10:37:03 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2062.outbound.protection.outlook.com [40.107.243.62]) (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 BE1553A0EBC for ; Fri, 29 May 2020 10:37:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nLvqyDBbPaLyK5Capsumdf9ze7/qDuqNPK0weGwF3I2D38U1wNkjvv+k22myRT+clRW9HT+BA97oMc/y5DMqCFW5vb/F6ZbC/qRGz7NzB1/qGqUNY+8t/9rphjjqgCHr7RxLWzT/WmaIkIYp36HPmx8tera6/6dkZ32n9TD3BebA39knP+O3njr1j6v6HL1Xdoo3EN9UQx1tQuUj5M3TCM6Nl2xX6UziyM+O1LBhgKfdaLh998QqCkMNuxr+dq1baTk5MYisPUgfVY/78lYpsPoxTGZNGnMNoOBe6vxuSaLuA5NDBepEUASQ8pT8fksgkLZbjo3b9CIbhVPaLTXzMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3+Icodn97TIc5VXQ/SZUL+kRo8f5ZuWLNhQZVz1hNqA=; b=P8hHcW1HnlYyKrA6Y5if7JxYtRFT6nZfHZA0wz5IRsK9sjCVFAewx/vZX0+IHZwqQJW5Inhs8ksGCqQxFhYLfOvyVf2UBVHH5aZGgkYqMw2cEM72SPDLRmrnz6IIIvWbwGTij79vtXkmocMYHYm2tJ0phInin72//0mll/j7xkCoQ086duTSn+WQUaqJhNzojxG/K1wbYSdtl+U7w9q8CT+vCeHhXa0rzFbtQ6INWF55Dtejk+KzW/dyz03fEomdZm/pjOdRIWI/yc8XoHruGCimuMjJPq+z5xcW1mSqE1C5UpSCisbtsnwNueMgg4ymlsSDItWhzYD6GpZ5ED0xPA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3+Icodn97TIc5VXQ/SZUL+kRo8f5ZuWLNhQZVz1hNqA=; b=B0af6iVoGI/nL0OajmFPnAbnC859Eybnj916jAb/zBoMGN4MSF9bG1Qf/jbbzpjxmzPaJODnhrhOy7oL7ki20+QqzQk0Gjapf5HwLOhKImUJQU7CUV2gvsS+eCxhfCS+ebLLZ6GnUx9uXGZG3bmHdkxjlgdkKprbdiGMjkRTkbc= Received: from BY5PR06MB6451.namprd06.prod.outlook.com (2603:10b6:a03:21e::20) by BY5PR06MB6690.namprd06.prod.outlook.com (2603:10b6:a03:23b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.23; Fri, 29 May 2020 17:36:58 +0000 Received: from BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5]) by BY5PR06MB6451.namprd06.prod.outlook.com ([fe80::b9b7:f0a7:b076:d5d5%5]) with mapi id 15.20.3045.018; Fri, 29 May 2020 17:36:58 +0000 From: Joseph Lorenzo Hall To: Eric Rescorla , Christopher Wood CC: "pearg@irtf.org" Thread-Topic: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques" Thread-Index: AQHWLsgqnBPhO5w6N0yNNHBtsaHVYqi/X7WAgAACC+s= Date: Fri, 29 May 2020 17:36:58 +0000 Message-ID: References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=isoc.org; x-originating-ip: [108.28.51.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 385e1535-83c5-4894-16a7-08d803f6e343 x-ms-traffictypediagnostic: BY5PR06MB6690: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 04180B6720 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5ovf7BhnmoWjGDE2r0FPLWn1ueoci2CwNyDFyVOnCMC1f21jQt3IdS0SKzdxGnNYMT+pCKEj+sOCyIQuTpM2aKyQyIMVipioInswNI7uMKGgDLuXZWWaALzFdfSsSUSfUGtygezZX5FG0TjtDUD/b2KU+cxSCmamvCgOjxxne+Z8QQkIcwC4wjtCSVx71lT6GF4vFWKHfzzbQCL97COG84b4qrKfqk5yGOQ7VqaUP290IxsmgwS+sweELhdkHOZLKkkRjyYqJyvIZRbD2XpwJ3VSYIW67Oi3mxv/HRL/vRm/p9b8itxqG7TCdZOuBD9N2klUOfh7nWqrp9VQjHm01EtUtroiGpCNnMURJlLJeM5bbs8usDlqKpwING0BRu+s7F0XJmfnrq4pKpEhnggw1g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6451.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(396003)(366004)(376002)(346002)(39840400004)(136003)(55016002)(966005)(166002)(66556008)(6506007)(66476007)(33656002)(53546011)(66446008)(76116006)(66946007)(64756008)(7696005)(2906002)(4326008)(8936002)(186003)(8676002)(26005)(83080400001)(66574014)(71200400001)(86362001)(110136005)(9686003)(478600001)(5660300002)(15974865002)(52536014)(83380400001)(316002)(30864003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Bp+vf0/JuLl11IXawsAbAU53Zpevl8RJ2SATtHfoUWwWr+ZGOnX8qPmrU1HXDLvT/e1JDtLMxuVYK90cfRGrq3jBMDqmWSvUGYEtf3c/rk+I3yMaZZRYluCOGBY+EVwkYZEb8gtq0BQkq+1gPEKCwQWnLeld/UJGSnrRmtRbXu9lZF2BkdV8PFrNVtMBlWFUlNDdN/Nhoy1x0Wc+zWViEnaxBH4l9Yo8o+aUQCSkpHzly8roNSWwFIyik5eujl4N26M8plyC6tR8yf9/eHx4hVwtR6NeZJmp1jFTbBKi09bT48yLfo59HCV8vkSJjtfGh6f4RtMpwz67QYGismT7zqcDBzAbHggib+eOqFmw1tV1JVqoFHeISUzTSmg3Xgtf3LbZl4N2Mv4TiusDocv14ER6vtb71aQ3mVtk8Eo86vxOiHNQ9ZVD5n+YCQ556FNBE2bv2SgD+D7VEHmwBTB+Lgu4513UXitKb/APovGwA99Sh0fWGSpQxzX62E1oEpoA x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR06MB645145AE6485535418D4B9EFB18F0BY5PR06MB6451namp_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 385e1535-83c5-4894-16a7-08d803f6e343 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2020 17:36:58.2179 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zX8LZ3+3068OsNZfMUX47FKo7CD6X7Iqngqbj90nlrd6txlvjl8xwb9GltaxBZy1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6690 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 17:37:14 -0000 --_000_BY5PR06MB645145AE6485535418D4B9EFB18F0BY5PR06MB6451namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for the review, EKR. I'll work through these and put them in issu= es in the repo as I do, likely not until next week. -- Joseph Lorenzo Hall, Senior Vice President, Strong Internet hall@isoc.org | +1-703-483-9504 internetsociety.org | @internetsociety pgp: https://josephhall.org/gpg-key 3CA28D7B9F6DDBD34B1016075F86698740A9A871 ________________________________ From: Pearg on behalf of Eric Rescorla Sent: Friday, May 29, 2020 1:28:59 PM To: Christopher Wood Cc: pearg@irtf.org Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Ce= nsorship Techniques" Document: draft-irtf-pearg-censorship-03.txt S 2. We describe three elements of Internet censorship: prescription, identification, and interference. The document contains three major sections, each corresponding to one of these elements. Prescription is the process by which censors determine what types of material they should block, i.e., deciding to block a list of pornographic websites. Identification is the process by which censors classify specific traffic to be blocked or impaired, i.e., blocking or impairing all webpages containing "sex" in the title or traffic to www.sex.example. Interference is the process by which censors I'm not finding this distinction super clear. It seems to me like deciding to block www.sex.example and "impairing...traffic to www.sex.example" are pretty similar. Not trying to force a new model on you, but I tend to think of this process as: 1. Decide what kind of material you want to block (e.g., material about sex). [This is what I expected prescription to be] 2. Determine what the conceptual indicia of that material are (this might be "contains the string sex" or "is one of these websites A, B, C") 3. Determine precisely how you identify the indicia on the network (DNS, SNI, etc.) 4. Determine how to block the communications once identified. S 3.1. Internet censorship necessarily takes place over a network. Network You say this but then later you give an example of endpoint censorship. I feel like this section might be better if it tried to impose some hierarchy here. From my perspective, there are four main categories of control points: - The network itself [ISPs, Backbone, Institutional ISPs] - The services side of communications [hosting providers, cloud providers, CDNs, etc.] - Services which are necessary to communicate but not really part of it [CAs, DNS, etc.] - The client endpoint side That might make this easier to read o Certificate Authorities for Public-Key Infrastructures (PKIs): Authorities that issue cryptographically secured resources can be a significant point of control. Certificate Authorities that issue certificates to domain holders for TLS/HTTPS (the Web PKI) or Regional/Local Internet Registries (RIRs) that issue Route Origination Authorizations (ROAs) to BGP operators can be forced to issue rogue certificates that may allow compromise, i.e.., by allowing censorship software to engage in identification and interference where not possible before. This may allow, for example, adversarial traffic routing or TLS interception. This is true, though CT is intended to make this much harder. I would add that CAs can be forced to revoke certificates, which is a threat that CT does not attempt to prevent. o Services: Application service providers can be pressured, coerced, or legally required to censor specific content or data flows. Service providers naturally face incentives to maximize their potential customer base and potential service shutdowns or legal liability due to censorship efforts may seem much less attractive than potentially excluding content, users, or uses of their service. Services have increasingly become focal points of censorship discussions, as well as the focus of discussions of moral imperatives to use censorship tools. It's a little hard to know if this text is talking about Facebook or AWS. Maybe split? At all levels of the network hierarchy, the filtration mechanisms used to detect undesirable traffic are essentially the same: a censor either directly sniffs transmitting packets and identifies undesirable content, and then uses a blocking or shaping mechanism to prevent or impair access, or requests that an actor ancillary to the censor, such as a private entity, perform these functions. I don't think this claim is right. For instance where do registry takedowns or DNS blacklists fit in. Neither of them "directly sniffs transmitting packets" (a weird phrase as-is). S 3.2.1. Tradeoffs: Request Identification is a technically straight-forward identification method that can be easily implemented at the Backbone or ISP level. The hardware needed for this sort of identification is cheap and easy-to-acquire, making it desirable when budget and scope are a concern. HTTPS will encrypt the relevant request and response fields, so pairing with transport identification (see Section 3.3.1) is necessary for HTTPS filtering. However, some countermeasures such I think you just want to remove "such" can trivially defeat simple forms of HTTP Request Header Identification. For example, two cooperating endpoints - an instrumented web server and client - could encrypt or otherwise obfuscate the "host" header in a request, potentially thwarting techniques that match against "host" header values. This is true, but seems kinda limited. 3.2.4.1. In encrypted connections using Transport Layer Security (TLS), there may be servers that host multiple "virtual servers" at a given network address, and the client will need to specify in the (unencrypted) Client Hello message which domain name it seeks to connect to (so that the server can respond with the appropriate TLS certificate) using the Server Name Indication (SNI) TLS extension [RFC6066]. Since SNI is often sent in the clear, censors and I understand that the cert field is also used for blocking. Domain fronting has been one popular way to avoid identification by censors [Fifield-2015]. To avoid identification by censors, applications using domain fronting put a different domain name in the SNI extension than the one encrypted by HTTPS. The visible SNI would indicate an unblocked domain, while the blocked domain remains hidden I would say "than in the Host: header, which is protected by HTTPS" S 3.3.1. Of the various shallow packet inspection methods, Transport Header Identification is the most pervasive, reliable, and predictable type of identification. Transport headers in TCP/IP or QUIC contain a few invaluable pieces of information that must be transparent for traffic to be successfully routed: destination and source IP address and port. Destination and Source IP are doubly useful, as not only does it allow a censor to block undesirable content via IP blocklisting, Saying "TCP/IP or QUIC" is weird as QUIC runs over UDP. And of course UDP has its own headers, as does RTP. I would just say "Transport headers" Header identification is trivial to implement, but is difficult to implement in backbone or ISP routers at scale, and is therefore typically implemented with DPI. Blocklisting an IP is equivalent to Does this mean "using DPI" or "along with DPI" Header identification is trivial to implement, but is difficult to implement in backbone or ISP routers at scale, and is therefore typically implemented with DPI. Blocklisting an IP is equivalent to installing a /32 route on a router. However, due to limited flow The IPv6 people will be mad. Port-blocking is generally not useful because many types of content share the same port and it is possible for censored applications to change their port. For example, most HTTP traffic goes over port 80, so the censor cannot differentiate between restricted and allowed web content solely on the basis of port. Another example is HTTPS port 443, which in addition to handling secure web traffic now also carries DNS-over-HTTPS [RFC8484] traffic; this can frustrate techniques that rely on cleartext DNS over port 53 for censorship, parental control, and other uses [SSAC-109-2020]. Port allowlisting True, but I feel like this is actually a different category of thing, because *this* section is about shallow blocking, whereas DNS-based blocking of specific domains is definitely not shallow. conjunction with other identification mechanisms. For example, a censor could block the default HTTPS port, port 443, thereby forcing most users to fall back to HTTP. An important counter-example is that port 25 (SMTP) has long been blocked on residential ISPs' networks, ostensibly to reduce the potential for email spam, but also prohibiting residential ISP customers to run their own email servers. This "ostensibly" seems unnecessarily sarcastic. It's not clear why ISPs would care that much (price discrimination?). Anyway, if you want to make this point, I think you could say something more netural which had the same impact. S 3.3.2. I'm having trouble with your taxonomy here because a lot of the protocol identification work seems like it's more application layer than transport layer, but you have it in 3.3. S 4.1.1. There is some good text in this section, but I feel like it's not doing a good job of distinguishing three attack modalities: - Lying by the nameserver - On-path interception by an attacker - off-path cache poisoning This has been such a persistent point of confusion with DoH that I think it's worth clarifying. > than ideal censorship mechanism. Additionally, the above mechanisms > rely on DNSSEC not being deployed or DNSSEC validation not being > active on the client or recursive resolver (neither of which are hard > to imagine given limited deployment of DNSSEC and limited client > support for DNSSEC validation). This is not quite correct. If you want to redirect a user then you need to content with DNSSEC, but if you just want to block them, then you can just provide a record which won't validate and that will have the same effect. S 4.2.2. I note that packet dropping is often how you implement traffic shaping. S 4.2.3. Packet injection, generally, refers to a man-in-the-middle (MITM) network interference technique that spoofs packets in an established traffic stream. RST packets are normally used to let one side of TCP connection know the other side has stopped sending information, and thus the receiver should close the connection. RST Packet Injection is a specific type of packet injection attack that is used to interrupt an established stream by sending RST packets to both sides of a TCP connection; as each receiver thinks the other has dropped the connection, the session is terminated. QUIC is not vulnerable to these types of injection attacks (See [I-D.ietf-quic-transport] for more details). This isn't totally true. QUIC is not vulnerable to this once the connection is set up, but it *is* vulnerable during setup. The two paragraphs in Trade-offs are confusing because you don't start out with the threat model. There are three threat models here: - On-path and fast - On-path and slow - Off-path In general, the argument you seem to be making is that on-path and fast is expensive but on-path and slow is cheap. I'm not sure the Blind injection stuff is that relevant: you would need to know the host/port coordinates which are fairly expensive to obtain. Do we know if anyone uses totally blind RSTs for censorship? My impression is that it's primarily useful for long running connectons like BGP. S 4.3.2. Trade-offs: The impact to a network disconnection in a region is huge and absolute; the censor pays for absolute control over digital information with all the benefits the Internet brings; This seems backwards. You pay by losing all the benefits. this is never a long-term solution for any rational censor and is normally only used as a last resort in times of substantial unrest. This seems unnecessarily judgemental. What's rational depends on incentives. Also, this section seems weird because it doesn't talk about fake BGP announcements for *other* sites, which we know is common and doesn't have anywhere near the impact yoou discuss here. S 6. I would remove this entirely. I don't think it really belongs -Ekr On Wed, May 20, 2020 at 10:00 AM Christopher Wood > wrote: This is the research group last call for the "A Survey of Worldwide Censors= hip Techniques" (draft-irtf-pearg-censorship) draft available here: https://datatracker.ietf.org/doc/draft-irtf-pearg-censorship/ Please review the document and send your comments to the list by June 5, 20= 20. Feedback may also be sent to the GitHub repository located here: https://github.com/IRTF-PEARG/rfc-censorship-tech Thanks, Chris, on behalf of the chairs -- Pearg mailing list Pearg@irtf.org https://www.irtf.org/mailman/listinfo/pearg --_000_BY5PR06MB645145AE6485535418D4B9EFB18F0BY5PR06MB6451namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank you for the review, EKR. I'll work thr= ough these and put them in issues in the repo as I do, likely not until nex= t week.

--
Joseph Lorenzo Hall, Senior Vice President, = Strong Internet
hall@isoc.org | +1-703-483-9504
internetsociety.org | @internetsociety
pgp: https://josephhall.org/gpg-key
3CA28D7B9F6DDBD34B1016075F86698740A9A871
From: Pearg <pearg-bounc= es@irtf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
Sent: Friday, May 29, 2020 1:28:59 PM
To: Christopher Wood <caw@heapingbits.net>
Cc: pearg@irtf.org <pearg@irtf.org>
Subject: Re: [Pearg] Research Group Last Call for "A Survey of = Worldwide Censorship Techniques"
 
Document: draft-irtf-pearg-censorship-03.txt

S 2.
    We describe three elements of Internet censorship: prescripti= on,
    identification, and interference.  The document contains= three major
    sections, each corresponding to one of these elements.  = Prescription
    is the process by which censors determine what types of mater= ial they
    should block, i.e., deciding to block a list of pornographic<= br>     websites.  Identification is the process by which censor= s classify
    specific traffic to be blocked or impaired, i.e., blocking or=
    impairing all webpages containing "sex" in the titl= e or traffic to
    www.sex.example.  Interference is the process by which c= ensors

I'm not finding this distinction super clear. It seems to me like
deciding to block www.sex.example and "impairing...traffic to
www.sex.example" are pretty similar.

Not trying to force a new model on you, but I tend to think of this
process as:

1. Decide what kind of material you want to block (e.g., material about
   sex). [This is what I expected prescription to be]

2. Determine what the conceptual indicia of that material are (this might    be "contains the string sex" or "is one of thes= e websites A, B, C")

3. Determine precisely how you identify the indicia on the network
   (DNS, SNI, etc.)

4. Determine how to block the communications once identified.


S 3.1.
   Internet censorship necessarily takes place over a network.&nb= sp; Network

You say this but then later you give an example of endpoint censorship.


I feel like this section might be better if it tried to impose some
hierarchy here. From my perspective, there are four main categories
of control points:

- The network itself [ISPs, Backbone, Institutional ISPs]
- The services side of communications [hosting providers, cloud
  providers, CDNs, etc.]
- Services which are necessary to communicate but not really
  part of it [CAs, DNS, etc.]
- The client endpoint side

That might make this easier to read


    o  Certificate Authorities for Public-Key Infrastructure= s (PKIs):
       Authorities that issue cryptographically secured= resources can be
       a significant point of control.  Certificat= e Authorities that
       issue certificates to domain holders for TLS/HTT= PS (the Web PKI)
       or Regional/Local Internet Registries (RIRs) tha= t issue Route
       Origination Authorizations (ROAs) to BGP operato= rs can be forced
       to issue rogue certificates that may allow compr= omise, i.e.., by
       allowing censorship software to engage in identi= fication and
       interference where not possible before.  Th= is may allow, for
       example, adversarial traffic routing or TLS inte= rception.

This is true, though CT is intended to make this much harder. I would
add that CAs can be forced to revoke certificates, which is a threat
that CT does not attempt to prevent.

    o  Services: Application service providers can be pressu= red, coerced,
       or legally required to censor specific content o= r data flows.
       Service providers naturally face incentives to m= aximize their
       potential customer base and potential service sh= utdowns or legal
       liability due to censorship efforts may seem muc= h less attractive
       than potentially excluding content, users, or us= es of their
       service.  Services have increasingly become= focal points of
       censorship discussions, as well as the focus of = discussions of
       moral imperatives to use censorship tools.

It's a little hard to know if this text is talking about Facebook
or AWS. Maybe split?


      At all levels of the network hierarchy, the filtration= mechanisms
      used to detect undesirable traffic are essentially the= same: a censor
      either directly sniffs transmitting packets and identi= fies
      undesirable content, and then uses a blocking or shapi= ng mechanism to
      prevent or impair access, or requests that an actor an= cillary to the
      censor, such as a private entity, perform these functi= ons.

I don't think this claim is right. For instance where do registry
takedowns or DNS blacklists fit in. Neither of them "directly sniffs transmitting packets" (a weird phrase as-is).


S 3.2.1.
   Tradeoffs: Request Identification is a technically straight-fo= rward
   identification method that can be easily implemented at the Ba= ckbone
   or ISP level.  The hardware needed for this sort of ident= ification is
   cheap and easy-to-acquire, making it desirable when budget and= scope
   are a concern.  HTTPS will encrypt the relevant request a= nd response
   fields, so pairing with transport identification (see Section = 3.3.1)
   is necessary for HTTPS filtering.  However, some counterm= easures such

I think you just want to remove "such"


   can trivially defeat simple forms of HTTP Request Header
   Identification.  For example, two cooperating endpoints -= an
   instrumented web server and client - could encrypt or otherwis= e
   obfuscate the "host" header in a request, potentiall= y thwarting
   techniques that match against "host" header values.<= br>
This is true, but seems kinda limited.


3.2.4.1.

   In encrypted connections using Transport Layer Security (TLS),= there
   may be servers that host multiple "virtual servers" = at a given
   network address, and the client will need to specify in the    (unencrypted) Client Hello message which domain name it seeks = to
   connect to (so that the server can respond with the appropriat= e TLS
   certificate) using the Server Name Indication (SNI) TLS extens= ion
   [RFC6066].  Since SNI is often sent in the clear, censors= and

I understand that the cert field is also used for blocking.

   Domain fronting has been one popular way to avoid identificati= on by
   censors [Fifield-2015].  To avoid identification by censo= rs,
   applications using domain fronting put a different domain name= in the
   SNI extension than the one encrypted by HTTPS.  The visib= le SNI would
   indicate an unblocked domain, while the blocked domain remains= hidden

I would say "than in the Host: header, which is protected by HTTPS&quo= t;


S 3.3.1.

   Of the various shallow packet inspection methods, Transport He= ader
   Identification is the most pervasive, reliable, and predictabl= e type
   of identification.  Transport headers in TCP/IP or QUIC c= ontain a few
   invaluable pieces of information that must be transparent for = traffic
   to be successfully routed: destination and source IP address a= nd
   port.  Destination and Source IP are doubly useful, as no= t only does
   it allow a censor to block undesirable content via IP blocklis= ting,

Saying "TCP/IP or QUIC" is weird as QUIC runs over UDP. And of co= urse
UDP has its own headers, as does RTP. I would just say "Transport head= ers"


   Header identification is trivial to implement, but is difficul= t to
   implement in backbone or ISP routers at scale, and is therefor= e
   typically implemented with DPI.  Blocklisting an IP is eq= uivalent to

Does this mean "using DPI" or "along with DPI"

   Header identification is trivial to implement, but is difficul= t to
   implement in backbone or ISP routers at scale, and is therefor= e
   typically implemented with DPI.  Blocklisting an IP is eq= uivalent to
   installing a /32 route on a router.  However, due to limi= ted flow

The IPv6 people will be mad.


   Port-blocking is generally not useful because many types of co= ntent
   share the same port and it is possible for censored applicatio= ns to
   change their port.  For example, most HTTP traffic goes o= ver port 80,
   so the censor cannot differentiate between restricted and allo= wed web
   content solely on the basis of port.  Another example is = HTTPS port
   443, which in addition to handling secure web traffic now also=
   carries DNS-over-HTTPS [RFC8484] traffic; this can frustrate    techniques that rely on cleartext DNS over port 53 for censors= hip,
   parental control, and other uses [SSAC-109-2020].  Port a= llowlisting

True, but I feel like this is actually a different category of thing,
because *this* section is about shallow blocking, whereas DNS-based
blocking of specific domains is definitely not shallow.


   conjunction with other identification mechanisms.  For ex= ample, a
   censor could block the default HTTPS port, port 443, thereby f= orcing
   most users to fall back to HTTP.  An important counter-ex= ample is
   that port 25 (SMTP) has long been blocked on residential ISPs'=
   networks, ostensibly to reduce the potential for email spam, b= ut also
   prohibiting residential ISP customers to run their own email s= ervers.

This "ostensibly" seems unnecessarily sarcastic. It's not clear why ISPs would care that much (price discrimination?). Anyway,
if you want to make this point, I think you could say something
more netural which had the same impact.


S 3.3.2.
I'm having trouble with your taxonomy here because a lot of the
protocol identification work seems like it's more application
layer than transport layer, but you have it in 3.3.


S 4.1.1.
There is some good text in this section, but I feel like it's
not doing a good job of distinguishing three attack modalities:

- Lying by the nameserver
- On-path interception by an attacker
- off-path cache poisoning

This has been such a persistent point of confusion with DoH that
I think it's worth clarifying.

>   than ideal censorship mechanism.  Additionally, the above = mechanisms
>   rely on DNSSEC not being deployed or DNSSEC validation not bein= g
>   active on the client or recursive resolver (neither of which ar= e hard
>   to imagine given limited deployment of DNSSEC and limited clien= t
>   support for DNSSEC validation).

This is not quite correct. If you want to redirect a user then you
need to content with DNSSEC, but if you just want to block them,
then you can just provide a record which won't validate and that
will have the same effect.


S 4.2.2.
I note that packet dropping is often how you implement traffic
shaping.



S 4.2.3.
   Packet injection, generally, refers to a man-in-the-middle (MI= TM)
   network interference technique that spoofs packets in an estab= lished
   traffic stream.  RST packets are normally used to let one= side of TCP
   connection know the other side has stopped sending information= , and
   thus the receiver should close the connection.  RST Packe= t Injection
   is a specific type of packet injection attack that is used to<= br>    interrupt an established stream by sending RST packets to both= sides
   of a TCP connection; as each receiver thinks the other has dro= pped
   the connection, the session is terminated.  QUIC is not v= ulnerable to
   these types of injection attacks (See [I-D.ietf-quic-transport= ] for
   more details).

This isn't totally true. QUIC is not vulnerable to this once the
connection is set up, but it *is* vulnerable during setup.

The two paragraphs in Trade-offs are confusing because you don't
start out with the threat model. There are three threat models
here:

- On-path and fast
- On-path and slow
- Off-path

In general, the argument you seem to be making is that on-path
and fast is expensive but on-path and slow is cheap. I'm not
sure the Blind injection stuff is that relevant: you would
need to know the host/port coordinates which are fairly expensive
to obtain. Do we know if anyone uses totally blind RSTs
for censorship? My impression is that it's primarily useful
for long running connectons like BGP.


S 4.3.2.

   Trade-offs: The impact to a network disconnection in a region = is huge
   and absolute; the censor pays for absolute control over digita= l
   information with all the benefits the Internet brings;

This seems backwards. You pay by losing all the benefits.

   this is never
   a long-term solution for any rational censor and is normally o= nly
   used as a last resort in times of substantial unrest.

This seems unnecessarily judgemental. What's rational depends on
incentives.

Also, this section seems weird because it doesn't talk about
fake BGP announcements for *other* sites, which we know is
common and doesn't have anywhere near the impact yoou discuss
here.


S 6.
I would remove this entirely. I don't think it really belongs

-Ekr

On Wed, May 20, 2020 at 10:00 AM Ch= ristopher Wood <caw@heapingbits.n= et> wrote:
This is the research group last call for the "A Survey of Worldwide Ce= nsorship Techniques" (draft-irtf-pearg-censorship) draft available her= e:

   https://datatracker.ietf.o= rg/doc/draft-irtf-pearg-censorship/

Please review the document and send your comments to the list by June 5, 20= 20. Feedback may also be sent to the GitHub repository located here:

   https://github.com/IRTF-PEARG/rfc-cens= orship-tech

Thanks,
Chris, on behalf of the chairs

--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg
--_000_BY5PR06MB645145AE6485535418D4B9EFB18F0BY5PR06MB6451namp_-- From nobody Fri May 29 10:43:00 2020 Return-Path: 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 86FE53A0E8D for ; Fri, 29 May 2020 10:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 QtM5TY4ViW3W for ; Fri, 29 May 2020 10:42:56 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA4C73A0E8C for ; Fri, 29 May 2020 10:42:56 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id q14so2347031qtr.9 for ; Fri, 29 May 2020 10:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=6K+u4gpPZGOsd+DEViCPQoqz3GpsK9eJkOTC7OYB1Vg=; b=FoB6FKJgsQQPOqwwLr6ibRw8auncgpgVwDHGgdGwl5nVPSYOaxyGr3xfrrMgfWOv+L Mj0+DlS34iY69Yrm6GzIdueicngGn4iVmVB5IoqvEs4YPZHsUxnVKgENQxgCUy0QpGuK UlwTOUiuoGEByJzuO6Bcu8slXnebO+YLo2VY8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=6K+u4gpPZGOsd+DEViCPQoqz3GpsK9eJkOTC7OYB1Vg=; b=e5BYwZTFTzTLhjBFw2s4U7mCSZJzvVGiWsiEiLBx8+SSdA8pIiHRE0xw4CB3YfHp5M 9ZRd1CwxyFTWlcmNTYRxjQ/HYiFxVh+uQKyjMRKKfZ9MTOHkYzKFnUfUmWgReb0ac8nK M9zz3pDl2XQWIye78+hqDoX8pjdaNhYPgifjJtaBzPLOWMOcWmR4A3Q/7Fi7xM10C1He Hsm+bu9gcbuKG7yXtX0v9H2AOgmujCrCOpcJh01qp0ZqcBoOotylUwNfeUDc7vzkQyVm FtclvnjDEkAuKi1a9E3BY+mLbNqO75M08rl+keLDp2/vsx/pUCSEDOX8gXwdIdvysqai +ITA== X-Gm-Message-State: AOAM532msMxFqejUtNvyfL5/L9mD+j1ATBUKjVDozzaWwkR71QP8e2BX nBMyKHvd1iFAJrLWLnWAcZgmF8wxJL8= X-Google-Smtp-Source: ABdhPJwQB7Ila7hMeJvslbUBfUXo5jw0O0FbR+IeSRCgelxS8NKnwBBsc41uLtpF9Psjx7e9VfxgdQ== X-Received: by 2002:ac8:6bc1:: with SMTP id b1mr10071613qtt.65.1590774175485; Fri, 29 May 2020 10:42:55 -0700 (PDT) Received: from Mallorys-MacBook-Air.local (c-73-163-188-207.hsd1.dc.comcast.net. [73.163.188.207]) by smtp.gmail.com with ESMTPSA id z60sm8321276qtc.30.2020.05.29.10.42.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 May 2020 10:42:54 -0700 (PDT) To: pearg@irtf.org References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> From: Mallory Knodel Message-ID: <01492184-2607-a693-f3b3-7538b9c47f39@cdt.org> Date: Fri, 29 May 2020 13:42:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Thunderbird/77.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 17:42:59 -0000 Hi, On 5/29/20 1:28 PM, Eric Rescorla wrote: > S 6. > I would remove this entirely. I don't think it really belongs I would disagree that it should be removed. It doesn't entirely fit with everything else, but it's correctly signposted as such, and omitting the concepts treated in this section would leave gaps difficult to bear if this draft is meant to be comprehensive for the IETF/IRTF audience. -Mallory From nobody Fri May 29 10:53:26 2020 Return-Path: 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 5AFB63A0EA8 for ; Fri, 29 May 2020 10:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 YOwW76P35r7x for ; Fri, 29 May 2020 10:53:22 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7123A0EA5 for ; Fri, 29 May 2020 10:53:22 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id z6so234535ljm.13 for ; Fri, 29 May 2020 10:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AXxd+8pbB2Odzbvo5LzxBjHkmKkDPnLorF+2q44tTkY=; b=rQQKlfXRH36rBAh/XEriuRQ55xoH7q0/pMTWmY8d/O/O9DhQGzY5P8jSeN8vSBNEHz wJ+PnGrVA+YGkntY7qJWHXCfQiQOkNuJyW0H6fLNhZJACgqj4ZCkO3Dp7P2/0FAnc3F/ qfuiKywRGtoNVE0WwZHgEIu6KWejw7YgGExhzBsHBeiMJBS3jOopVvWSNosF12ZUkwRb X565MY8kEhLW9aBmJ0ZS00VwCtpDZYvW5slj0kMyA0DnmlcUw4tcpOCAsHAjwgw4ad+h lGxErLXW2YY4fWKZjnd0/Z1Mf1i6/jXfREr5CUw2zpVtdAPQMyeZ5pSEpaaf71FjmQ2F S3nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AXxd+8pbB2Odzbvo5LzxBjHkmKkDPnLorF+2q44tTkY=; b=OQk47E/k6rAm9y9D4tOmL4C9aRoP+WPQPB+KU3TLXw97LZXNPDHucWpDLlwBGLFLVo iyeuWtQFtDaQVjx+l5FdJYYh2PL811DhrdX7hJHWa38kESB0FI1r9k94vwwJ6FNdAkHk a9KcBHtVEhiAV+oK5pPHCRwMT3McorFQLF6w2OwufMgsbJBMkngAXzNWvapQp6Ndw57e F2WMSm5nQJHGapokqNEBcbKVHRBhiPNEvbksipYb8dnymN862wp/9I2kIOo5l3JrnJXI I+J4rhQboXLbbtX4vGdqZDnKkA3D6DxaZertMrJzWLGPfsgIiHuPsu1L5mdy5eabmxgj rNeg== X-Gm-Message-State: AOAM530r5ZbTOVxErNCqxvnjRgUOALNO5VUQJyUhpE8bn58BQRniIvFB Dn+jOhigAF0XSlHqMB/vo8j8hxxtePAk2QpdzFC+eUFu+fs= X-Google-Smtp-Source: ABdhPJyDv483Ed5KvryrVu/XULmkASQFirVRFVLMm2UkNChFoPSdQB4yNRA4IRWXAjcrqaHlSVfvZP+nZChwMDpAOwY= X-Received: by 2002:a2e:611a:: with SMTP id v26mr2986215ljb.265.1590774799424; Fri, 29 May 2020 10:53:19 -0700 (PDT) MIME-Version: 1.0 References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <01492184-2607-a693-f3b3-7538b9c47f39@cdt.org> In-Reply-To: <01492184-2607-a693-f3b3-7538b9c47f39@cdt.org> From: Eric Rescorla Date: Fri, 29 May 2020 10:52:42 -0700 Message-ID: To: Mallory Knodel Cc: pearg@irtf.org Content-Type: multipart/alternative; boundary="000000000000d67c1c05a6cd1e8b" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 17:53:24 -0000 --000000000000d67c1c05a6cd1e8b Content-Type: text/plain; charset="UTF-8" Sorry, I meant that we should remove 6.1. I agree that 6.2 and 6.3 continue to belong. To be clear, i agree that self-censorship is a thing, I just don't think it really makes that much sense in this doc -Ekr On Fri, May 29, 2020 at 10:43 AM Mallory Knodel wrote: > Hi, > > On 5/29/20 1:28 PM, Eric Rescorla wrote: > > S 6. > > I would remove this entirely. I don't think it really belongs > > I would disagree that it should be removed. It doesn't entirely fit with > everything else, but it's correctly signposted as such, and omitting the > concepts treated in this section would leave gaps difficult to bear if > this draft is meant to be comprehensive for the IETF/IRTF audience. > > -Mallory > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > --000000000000d67c1c05a6cd1e8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, I meant that we should remove 6.1. I agree tha= t 6.2 and 6.3 continue to belong. To be clear, i agree that self-censorship= is a thing, I just don't think it really makes that much sense in this= doc

-Ekr


On Fri, May 29, 2020= at 10:43 AM Mallory Knodel <mknodel@= cdt.org> wrote:
Hi,

On 5/29/20 1:28 PM, Eric Rescorla wrote:
> S 6.
> I would remove this entirely. I don't think it really belongs

I would disagree that it should be removed. It doesn't entirely fit wit= h
everything else, but it's correctly signposted as such, and omitting th= e
concepts treated in this section would leave gaps difficult to bear if
this draft is meant to be comprehensive for the IETF/IRTF audience.

-Mallory

--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg
--000000000000d67c1c05a6cd1e8b-- From nobody Fri May 29 11:00:34 2020 Return-Path: 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 518C43A0EB7 for ; Fri, 29 May 2020 11:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 s091Jx7cBNEq for ; Fri, 29 May 2020 11:00:32 -0700 (PDT) Received: from mail-qv1-xf43.google.com (mail-qv1-xf43.google.com [IPv6:2607:f8b0:4864:20::f43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3C33A00D9 for ; Fri, 29 May 2020 11:00:31 -0700 (PDT) Received: by mail-qv1-xf43.google.com with SMTP id r16so1480046qvm.6 for ; Fri, 29 May 2020 11:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=gTPxUTept8fGT3APTnJLaKwd8yBb/P8psg6DXebzZdA=; b=dhtESjXhfw0PpRvZj46hgHeywaKqWj3qFxURALh3uwS9da/t+ryG6/PdHk7aTSwSbE hkCze8Dq3HJbWZBhE82joxbQq2CdJ+vfSXSMiEYH212k27DAw67XbRh2JYD3qhJSH8dD MYlmZv3wwuqMd8WCA/2XfMx9GpiVE+ahuLz4o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=gTPxUTept8fGT3APTnJLaKwd8yBb/P8psg6DXebzZdA=; b=WO/iRvb3ZnzJrS/RCgb+aMLdy1EiURH3DOSXumstpO/daiK9YmU5YEq7rqchCp4oLp w6KzJvlmIgJDE8PsQujAqflNf3pk13VqKFzJDs68zTLXSVzJooorb8WxtMeIvqLD/Txa T6fauAljXj9RxAORb2NQ79hwM5Xa0YEbJBAw+s1qc1IMxa1DugoqJQHHmspNzbd/r5/K HuFh2psErsBqvQiG/nWpWUaJwqR13c8TvVR3RcHodc/9IvC0ImdLgTg3UKjHAfAHc6QD LiubyeIkDa2mVSLk6ZgsR0YzXHItqfKJYCdaSH3jsVFygr0kk0GcvikhO5LFXfR50vnd pxqA== X-Gm-Message-State: AOAM533Jdk+rK04eGrYdWWtqn9d1rsPyyCpsSqoFz1Oblya7/OENsTfe 7LxBCNetZkw1g19PL979s44bn3fBAOo= X-Google-Smtp-Source: ABdhPJzitOlIhVVmtnGkl6QN/dypaRIDTEjeyKpqibu9B2v9FcAYf6AWpJv58WjWcby5QFQ9U5jLsg== X-Received: by 2002:a0c:f445:: with SMTP id h5mr8824919qvm.151.1590775229596; Fri, 29 May 2020 11:00:29 -0700 (PDT) Received: from Mallorys-MacBook-Air.local (c-73-163-188-207.hsd1.dc.comcast.net. [73.163.188.207]) by smtp.gmail.com with ESMTPSA id p22sm1291449qtc.7.2020.05.29.11.00.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 May 2020 11:00:28 -0700 (PDT) To: Eric Rescorla Cc: pearg@irtf.org References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <01492184-2607-a693-f3b3-7538b9c47f39@cdt.org> From: Mallory Knodel Message-ID: <2126b935-f8cc-6af9-d167-efe0d81bff14@cdt.org> Date: Fri, 29 May 2020 14:00:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Thunderbird/77.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------37999E579134DA1253438A46" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 18:00:33 -0000 This is a multi-part message in MIME format. --------------37999E579134DA1253438A46 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit That's better, thanks for clarifying. I would still advocate for it to stay, simply because "self" can be broadly interpreted. In short, self-censorship is a knock-on effect of more direct forms of censorship, or a cumulative context of censorship, and relates to this community in two ways: helps understand what's called "the chilling effect," and somehow relates to the maxim of "be[ing] conservative in what you send". -Mallory On 5/29/20 1:52 PM, Eric Rescorla wrote: > Sorry, I meant that we should remove 6.1. I agree that 6.2 and 6.3 > continue to belong. To be clear, i agree that self-censorship is a > thing, I just don't think it really makes that much sense in this doc > > -Ekr > > > On Fri, May 29, 2020 at 10:43 AM Mallory Knodel > wrote: > > Hi, > > On 5/29/20 1:28 PM, Eric Rescorla wrote: > > S 6. > > I would remove this entirely. I don't think it really belongs > > I would disagree that it should be removed. It doesn't entirely > fit with > everything else, but it's correctly signposted as such, and > omitting the > concepts treated in this section would leave gaps difficult to > bear if > this draft is meant to be comprehensive for the IETF/IRTF audience. > > -Mallory > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > > --------------37999E579134DA1253438A46 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

That's better, thanks for clarifying.

I would still advocate for it to stay, simply because "self" can be broadly interpreted. In short, self-censorship is a knock-on effect of more direct forms of censorship, or a cumulative context of censorship, and relates to this community in two ways: helps understand what's called "the chilling effect," and somehow relates to the maxim of "be[ing] conservative in what you send".

-Mallory

On 5/29/20 1:52 PM, Eric Rescorla wrote:
Sorry, I meant that we should remove 6.1. I agree that 6.2 and 6.3 continue to belong. To be clear, i agree that self-censorship is a thing, I just don't think it really makes that much sense in this doc

-Ekr


On Fri, May 29, 2020 at 10:43 AM Mallory Knodel <mknodel@cdt.org> wrote:
Hi,

On 5/29/20 1:28 PM, Eric Rescorla wrote:
> S 6.
> I would remove this entirely. I don't think it really belongs

I would disagree that it should be removed. It doesn't entirely fit with
everything else, but it's correctly signposted as such, and omitting the
concepts treated in this section would leave gaps difficult to bear if
this draft is meant to be comprehensive for the IETF/IRTF audience.

-Mallory

--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg
--------------37999E579134DA1253438A46-- From nobody Fri May 29 11:06:46 2020 Return-Path: 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 791643A0EB9 for ; Fri, 29 May 2020 11:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 URIL7S2zxy3A for ; Fri, 29 May 2020 11:06:42 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0363A0EBA for ; Fri, 29 May 2020 11:06:42 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id x22so224328lfd.4 for ; Fri, 29 May 2020 11:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bFSFB5Q80+iuaJ/F09NPJkWby9Kg0Mf98tHbu0sVNeo=; b=oEUv1DNpAcw+Xa6ZCaGB0MBWfIvEF0xzcVT9dIaNgciOeUbJReX+DZDYOlkEbHbu2g BWKjAG6E0T2Jo1L7/Gb9Ccup5A9dkrZz32ZSxwiywns4jMG/blldUGFx0ppaTNJQKQgh c0frOTEs1TrQzVrrDNRnCgKh5319HuBBjobnIt1A+ryXsY6Sn+DNc/zhSTzkK104vBt7 raQ9zwN9Yfyk+gXcvMjR1qrBYpMD5MHeO7Gx97LAK+XRzqiVh849JmT11aDbSWOGsyQ/ 2Fjqweyo+QFCsiINYig7/3nvPSrOF9eTBfDsLXkRThgdF4SWiImI5zJUX212yw3B5tte MMlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bFSFB5Q80+iuaJ/F09NPJkWby9Kg0Mf98tHbu0sVNeo=; b=ozI7FOE2esvfui/hmGHPufsDRyOi/XXFurF5TuDlWFWANFPxqJ2/YeXXz9sE9AMLeJ aGOkW9/8ZWu/xohpW/zjZIsu8c2Zis8nA2vhR5RnPT6atILChLCt01qPAnKIIMvvjY1P EolNhjByJwaK5FTnYEU7rsQJ2nq1W9ESBAzf+pqYhKEfX6E1vzi4gHl5I6wJytGZ3oL5 ZV8qR/G8wk0a1XCEuSWxIDmTW9RZcFaIRvNxtd3z3vU4CF5/6db0Php18/3brwl1GC7S XyZVYwNwqPXpbWOqB9N489pS//4kaGiiKI7LBigPnoNbC9hxZEeSAX9mfruYoAgYUk/P Neaw== X-Gm-Message-State: AOAM530LqQiHkzi8UPCmGlm/0HMeEt/v9dO6eF+T+CqT4f1BMjYGNG+0 o78kWPID1rJRxsCITcKFpL7rKXF2e4Opx8CsRy3vtw== X-Google-Smtp-Source: ABdhPJyv28pXxD/LfzUuwiydbS9eA3k8OCdI/q1ojLcwhDt9fx+m+o6S65oBURyT/0fZSD9twodJe4Lao/6ruuQToLc= X-Received: by 2002:a19:be55:: with SMTP id o82mr4916318lff.168.1590775600474; Fri, 29 May 2020 11:06:40 -0700 (PDT) MIME-Version: 1.0 References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <01492184-2607-a693-f3b3-7538b9c47f39@cdt.org> <2126b935-f8cc-6af9-d167-efe0d81bff14@cdt.org> In-Reply-To: <2126b935-f8cc-6af9-d167-efe0d81bff14@cdt.org> From: Eric Rescorla Date: Fri, 29 May 2020 11:06:04 -0700 Message-ID: To: Mallory Knodel Cc: pearg@irtf.org Content-Type: multipart/alternative; boundary="000000000000957d1b05a6cd4ec0" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 18:06:45 -0000 --000000000000957d1b05a6cd4ec0 Content-Type: text/plain; charset="UTF-8" Thanks for your response. I'm not going to lie down in the road over this, but let me make one more attempt. First let me say that I strongly agree that this is a real effect and that it's a commonly used form of controlling speech. My concern about having it here is merely that it seems like there are a wide variety of social controls on behavior and thought of which this is just one. I think it would be cleaner to focus this draft on the technical side of how governments prevent people who are trying to speak from being able to, rather than to get into the myriad ways in which people are discouraged from speaking. However, if this isn't persuasive then that's fine. I leave it to the chairs and authors to manage this feedback. -Ekr On Fri, May 29, 2020 at 11:00 AM Mallory Knodel wrote: > That's better, thanks for clarifying. > > I would still advocate for it to stay, simply because "self" can be > broadly interpreted. In short, self-censorship is a knock-on effect of more > direct forms of censorship, or a cumulative context of censorship, and > relates to this community in two ways: helps understand what's called "the > chilling effect," and somehow relates to the maxim of "be[ing] conservative > in what you send". > > -Mallory > On 5/29/20 1:52 PM, Eric Rescorla wrote: > > Sorry, I meant that we should remove 6.1. I agree that 6.2 and 6.3 > continue to belong. To be clear, i agree that self-censorship is a thing, I > just don't think it really makes that much sense in this doc > > -Ekr > > > On Fri, May 29, 2020 at 10:43 AM Mallory Knodel wrote: > >> Hi, >> >> On 5/29/20 1:28 PM, Eric Rescorla wrote: >> > S 6. >> > I would remove this entirely. I don't think it really belongs >> >> I would disagree that it should be removed. It doesn't entirely fit with >> everything else, but it's correctly signposted as such, and omitting the >> concepts treated in this section would leave gaps difficult to bear if >> this draft is meant to be comprehensive for the IETF/IRTF audience. >> >> -Mallory >> >> -- >> Pearg mailing list >> Pearg@irtf.org >> https://www.irtf.org/mailman/listinfo/pearg >> > --000000000000957d1b05a6cd4ec0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your response. I'm not going to lie do= wn in the road over this, but let me make one more attempt.

<= /div>
First let me say that I strongly agree that this is a real effect= and that it's a commonly used form of controlling speech. My concern a= bout having it here is merely that it seems like there are a wide variety o= f social controls on behavior and thought of which this is just one. I thin= k it would be cleaner to focus this draft on the technical side of how gove= rnments prevent people who are trying to speak from being able to, rather t= han to get into the myriad ways in which people are discouraged from speaki= ng.

However, if this isn't persuasive then tha= t's fine. I leave it to the chairs and authors to manage this feedback.=

-Ekr


On Fri, May 29, 2020= at 11:00 AM Mallory Knodel <mknodel@cdt.org> wrote:
=20 =20 =20

That's better, thanks for clarifying.

I would still advocate for it to stay, simply because "self&quo= t; can be broadly interpreted. In short, self-censorship is a knock-on effect of more direct forms of censorship, or a cumulative context of censorship, and relates to this community in two ways: helps understand what's called "the chilling effect," and som= ehow relates to the maxim of "be[ing] conservative in what you send&q= uot;.

-Mallory

On 5/29/20 1:52 PM, Eric Rescorla wrote:
=20
Sorry, I meant that we should remove 6.1. I agree that 6.2 and 6.3 continue to belong. To be clear, i agree that self-censorship is a thing, I just don't think it really make= s that much sense in this doc

-Ekr


On Fri, May 29, 2020 at 10:43 AM Mallory Knodel <mknodel@cdt.org> wrote:
Hi,

On 5/29/20 1:28 PM, Eric Rescorla wrote:
> S 6.
> I would remove this entirely. I don't think it really belongs

I would disagree that it should be removed. It doesn't entirely fit with
everything else, but it's correctly signposted as such, and omitting the
concepts treated in this section would leave gaps difficult to bear if
this draft is meant to be comprehensive for the IETF/IRTF audience.

-Mallory

--
Pearg mailing list
Pearg@irtf.or= g
https://www.irtf.org/mailman/listinfo/pearg=
--000000000000957d1b05a6cd4ec0-- From nobody Sat May 30 00:41:25 2020 Return-Path: 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 722163A07DD for ; Sat, 30 May 2020 00:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 j5FXvoyxqvHb for ; Sat, 30 May 2020 00:41:14 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A333A07B9 for ; Sat, 30 May 2020 00:41:13 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49YtfH71RKzyvv; Sat, 30 May 2020 09:41:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Sat, 30 May 2020 09:41:11 +0200 Cc: pearg@irtf.org X-Mao-Original-Outgoing-Id: 612517271.608041-1188c16a14cadd8acb8680ee1a1f264c Content-Transfer-Encoding: quoted-printable Message-Id: <0329C9F5-DA49-479C-B277-4FF9C7E96ADD@tzi.org> References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <455744305.5725.1590658172742@appsuite-gw2.open-xchange.com> <75c0bcb0-d4ae-4d5c-2aac-0c16962841a9@digitaldissidents.org> <1579895595.5892.1590660934957@appsuite-gw2.open-xchange.com> <353091b8-c84c-e02d-c7e0-c524070135b1@digitaldissidents.org> <1066566227.7990.1590749300790@appsuite-gw1.open-xchange.com> To: Niels ten Oever X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2020 07:41:23 -0000 On 2020-05-29, at 13:08, Niels ten Oever = wrote: >=20 > This document does not say that every time such a technique is used, = it is called censorship. That=E2=80=99s not what the title suggests. =E2=80=9CCensorship techniques=E2=80=9D to me strongly suggests it is = about techniques specifically applied for censorship. Maybe that = misunderstanding is easily fixed, e.g. =E2=80=9Ctechniques employed for = censorship=E2=80=9D. > It also does not say whether it is right or wrong.=20 Outside of a small set of people who have really thought about the = problem (and probably even among those), =E2=80=9Ccensorship=E2=80=9D is = a rather pejorative term; it always applies wrongdoing in common usage. That is why it usually is reserved for state-controlled suppression of = information, and typically only for those cases where that suppression = is not necessitated by violation of other basic rights. On 2020-05-27, at 01:56, Joseph Lorenzo Hall wrote: >=20 > entities adversarially messing with information flows is censorship That is certainly not a definition that comes to mind among = intellectuals in my country, many of which would have a hard time with = categorizing, e.g., privacy laws under censorship (unless they are = actually also employed for censorship, but I don=E2=80=99t want to open = the whole can here). I=E2=80=99m writing this because I think such a document is very useful, = and I don=E2=80=99t want to see it devalued by terminology that will be = seen by many as distorted beyond recognition by mindless activism. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat May 30 08:52:33 2020 Return-Path: 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 5F4213A0921 for ; Sat, 30 May 2020 08:52:31 -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 Oq1dOMRkgHpW for ; Sat, 30 May 2020 08:52:28 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9233A0916 for ; Sat, 30 May 2020 08:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6460; q=dns/txt; s=iport; t=1590853948; x=1592063548; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=qENAPg1P+uf2lPErrrBzoj3C+19gB6ThDsDn0awWY9U=; b=G0Wi7IPJ32fBBbseh1fnnpHtNVkW24lUMz+/Ut3Lq0sTpZPrWovTAFpb BUigbDidHK2n4h31TqYcdaiZDmZ0VJAwORfR/ca6yGsI7JO1vexs8MT6t FlA3b3t4NRkY7VI5u/RqcFBq1vFkxLF9Fvt24kS0cJlkcdujxs9c+nY0K Y=; X-IPAS-Result: =?us-ascii?q?A0B3AAAwgNJe/xbLJq1mGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBggqBIYJLASASLIQliQGICpNliBELAQEBDAEBLwQBAYREAoIjJ?= =?us-ascii?q?TgTAgMBAQEDAgMBAQEBBQEBAQIBBgRthWWFcgEBAQECARgFBlYFCwsOCioCA?= =?us-ascii?q?lcGE4Mmgl0grzF2gTKFUYR9gTiMYYIAgTgcgh8uPodiM4ItBLNPgmGCepV1H?= =?us-ascii?q?pBVjUOrDR6DLgIEBgUCFYFqIoFWMxoIGxVlAYI+PhIZDZB4jhI/AzA3AgYBB?= =?us-ascii?q?wEBAwmNRwEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos; i="5.73,452,1583193600"; d="scan'208,217"; a="24319008" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 May 2020 15:52:24 +0000 Received: from [10.61.209.159] ([10.61.209.159]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 04UFqLT4022493 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 May 2020 15:52:22 GMT From: Eliot Lear Message-Id: <8D179E05-AFAC-4B93-890E-E2D8A5F4EF03@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B132DFC3-FD58-42D8-A9DC-5727BEC701CE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 30 May 2020 17:52:20 +0200 In-Reply-To: Cc: pearg@irtf.org To: Mallory Knodel References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.209.159, [10.61.209.159] X-Outbound-Node: aer-core-4.cisco.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2020 15:52:31 -0000 --Apple-Mail=_B132DFC3-FD58-42D8-A9DC-5727BEC701CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mallory, I wanted to come back to something you wrote: > On 26 May 2020, at 19:04, Mallory Knodel wrote: >=20 > Because while there are indeed recognized legal, legitimate and = proportional reasons why the rights to free expression and to access = information should be violated, censorship measures should not be taken = without careful consideration as it is a human rights matter. Regardless of the terminology, it seems to me that there is another = aspect that the document could capture that is related to the IETF. In = the introduction, the authors write: There is also a growing field of academic study of censorship circumvention (see the review article of [Tschantz-2016]), results from which we seek to make relevant here for protocol designers and implementers. I wonder if it would be good to elaborate this. Be a bit more explicit = as to what the relevancies are. Are these cautionary tales for = instance, wherein some cases the use of the technology for censorship = was not what the engineers had in mind? How would you like engineers to = evaluate technology tradeoffs? This allows us to address one additional point that I=E2=80=99d suggest = the RG to consider: the document motivation could be strengthened. Why = is this document important? Who is it relevant to? This might also = explain why there is no conclusion or desired next steps. Good that = they've enumerated various mechanisms. Would they like the IETF to = review those points with an eye toward avoiding inadvertent avenues to = additional censorship? What if anything would be good for PEARG to = follow up? I=E2=80=99m not suggesting many paragraphs, but one or two = wouldn=E2=80=99t be out of line. Eliot= --Apple-Mail=_B132DFC3-FD58-42D8-A9DC-5727BEC701CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mallory,

I = wanted to come back to something you wrote:

On 26 = May 2020, at 19:04, Mallory Knodel <mknodel@cdt.org> wrote:

Because while there are indeed = recognized legal, legitimate and proportional reasons why the rights to = free expression and to access information should be violated, censorship = measures should not be taken without careful consideration as it is a = human rights matter.

Regardless of the terminology, it seems = to me that there is another aspect that the document could capture that = is related to the IETF.  In the introduction, the authors = write:

   There is also a growing field of
   academic study of censorship circumvention (see the review article of
   [Tschantz-2016]), results from which we seek to make relevant here
   for protocol designers and implementers.
I =
wonder if it would be good to elaborate this.  Be a =
bit more explicit as to what the relevancies are.  Are these cautionary tales for instance, wherein some cases =
the use of the technology for censorship was =
not what the engineers had in mind?  How would you like engineers =
to evaluate technology tradeoffs?
This =
allows us to address one additional point that I=E2=80=99d suggest the =
RG to consider:  the =
document motivation could be strengthened.  =
Why is this document important?  Who is it relevant to? =
 This might also explain =
why there is no conclusion or desired next steps.  Good that =
they've enumerated various mechanisms.  Would they like the IETF to =
review those points with an eye toward avoiding inadvertent avenues =
to additional censorship?  What if anything would be good for PEARG =
to follow up?  I=E2=80=99m not suggesting many paragraphs, but one =
or two wouldn=E2=80=99t be out of line.
Eliot
= --Apple-Mail=_B132DFC3-FD58-42D8-A9DC-5727BEC701CE-- From nobody Sat May 30 12:11:45 2020 Return-Path: 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 314543A0D3F for ; Sat, 30 May 2020 12:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 BNhcTR_eRBwl for ; Sat, 30 May 2020 12:11:42 -0700 (PDT) Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F503A0D38 for ; Sat, 30 May 2020 12:11:42 -0700 (PDT) Received: by mail-qt1-f171.google.com with SMTP id u17so3604861qtq.1 for ; Sat, 30 May 2020 12:11:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jxpugFTWbFckKbUuItl70OPU/lJxUbGAXqGMmrtTcew=; b=fOQzIJCvDxdOgHZqhnhsM7UcYYpqIDlw2GBlm8M0iInnly0ZjXa8ElzWDyN8cewpRS ych/OQBSXmvI+8NcPG4T9x6cvJCFikjZqA2PKxtEtLx7tZbj4TxpqyIZCNs7rpd53XOJ 3i8ukp1i/s5OUC1xcK4LhsxqS0r5brTc0yWQnoblxujh0wbz/h9e/qgyEmU+X5rh9lrB vgAszpwUagu9OoNUIcpygvAD4dTBggxKKrwIBue0zSDYIhJPgqcMnUWl11GEjgUWf+Gd fAwevgzfhSdFFD6Lr6K58PE8c7bukUhM3qjUAP5Q0uSuC/srtOTISdZoIKGjuQw1uuln X5wA== X-Gm-Message-State: AOAM532i7OG0W/soPgwiNKHS3M+eBtH/yNlL+W7J0xm6uHasOjFE3H40 eCxHKELSLdYoUX3/p+C2MYH56KU5XKo8orXYbLo= X-Google-Smtp-Source: ABdhPJyPZssdTFno9fGNmgHJ6lGMwf1gFEK0TPKLkELxQM2nIMQXc9XJfd5hMqeK9uwYKycE1jCbMdnImlmqGUqbQTw= X-Received: by 2002:ac8:710f:: with SMTP id z15mr14943369qto.71.1590865901255; Sat, 30 May 2020 12:11:41 -0700 (PDT) MIME-Version: 1.0 References: <08f43a37-2b7b-418e-95a8-ed57484c66be@www.fastmail.com> <8D179E05-AFAC-4B93-890E-E2D8A5F4EF03@cisco.com> In-Reply-To: <8D179E05-AFAC-4B93-890E-E2D8A5F4EF03@cisco.com> From: David Oliver Date: Sat, 30 May 2020 15:11:30 -0400 Message-ID: To: Eliot Lear Cc: pearg@irtf.org Content-Type: multipart/alternative; boundary="000000000000edffa705a6e25453" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2020 19:11:44 -0000 --000000000000edffa705a6e25453 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Be a bit more explicit as to what the relevancies are. I was actually wondering the opposite: Why *are* circumvention methods mentioned in this document? Should I work on the assumption that "why" was hashed out in discussion of earlier drafts? David David M. Oliver | david@g uardianproject.info | http://g uardianproject.info | @davidmoliver | +1 970 368 2366 On Sat, May 30, 2020 at 11:52 AM Eliot Lear wrote: > Mallory, > > I wanted to come back to something you wrote: > > On 26 May 2020, at 19:04, Mallory Knodel wrote: > > Because while there are indeed recognized legal, legitimate and > proportional reasons why the rights to free expression and to access > information should be violated, censorship measures should not be taken > without careful consideration as it is a human rights matter. > > > Regardless of the terminology, it seems to me that there is another aspec= t > that the document could capture that is related to the IETF. In the > introduction, the authors write: > > There is also a growing field of > academic study of censorship circumvention (see the review article of > [Tschantz-2016]), results from which we seek to make relevant here > for protocol designers and implementers. > > I wonder if it would be good to elaborate this. Be a bit more explicit a= s to what the relevancies are. Are these cautionary tales for instance, wh= erein some cases the use of the technology for censorship was not what the = engineers had in mind? How would you like engineers to evaluate technology= tradeoffs? > > This allows us to address one additional point that I=E2=80=99d suggest t= he RG to consider: the document motivation could be strengthened. Why is = this document important? Who is it relevant to? This might also explain w= hy there is no conclusion or desired next steps. Good that they've enumera= ted various mechanisms. Would they like the IETF to review those points wi= th an eye toward avoiding inadvertent avenues to additional censorship? Wh= at if anything would be good for PEARG to follow up? I=E2=80=99m not sugge= sting many paragraphs, but one or two wouldn=E2=80=99t be out of line. > > Eliot > > -- > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg > --000000000000edffa705a6e25453 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Be a bit more explicit as to what the relevancies a= re.=C2=A0

I was actually wondering the opposite: Why *are* circumve= ntion methods mentioned in this document?=C2=A0 Should I work on the assump= tion=C2=A0that "why" was hashed out in discussion of earlier draf= ts?

=
David=C2=A0

David M. Oli= ver |=C2=A0david= @guardianproje= ct.info=C2=A0|=C2=A0http://guard= ianproject.info=C2=A0| @davidmoliver |=C2=A0+1 970 368 2366
=

On Sat, May 30, 2020 at 11:52 AM Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:
=
Mallory,

I wanted to come back to something= you wrote:

On 26 May 2020, at 1= 9:04, Mallory Knodel <mknodel@cdt.org> wrote:

Because while there are indeed recognized legal, legit= imate and proportional reasons why the rights to free expression and to acc= ess information should be violated, censorship measures should not be taken= without careful consideration as it is a human rights matter.
=

Regardless of the terminology, it seems t= o me that there is another aspect that the document could capture that is r= elated to the IETF.=C2=A0 In the introduction, the authors write:

   There is also a growing field of
   academic study of censorship circumvention (see the review article of
   [Tschantz-2016]), results from which we seek to make relevant here
   for protocol designers and implementers.
I wonder if it would be good to elabora=
te this. =C2=A0Be a bit more explicit as to what the relevancies are.=C2=A0=C2=A0Are these cautionary=
=C2=A0tales for instance, whe=
rein some cases the use of the technology for censorship=C2=A0was not what the engineers had in =
mind?=C2=A0 How would you like engineers to evaluate technology tradeoffs?<=
/span>
T=
his allows us to address one additional point that I=E2=80=99d suggest the =
RG to=C2=A0=
consider: =
=C2=A0the d=
ocument motivation could be strengthened.=C2=A0 Why is this document important?=C2=A0 =
Who is it relevant to? =C2=A0This might also=C2=A0explain why there is no conclusion or desire=
d next steps.=C2=A0 Good that they've enumerated various mechanisms.=C2=
=A0 Would they like the IETF to review those points with an eye toward avoi=
ding=C2=A0inadvertent avenues to additional censorship?=C2=A0 What if anyth=
ing would be good for PEARG to follow up?=C2=A0 I=E2=80=99m not suggesting =
many paragraphs, but one or two wouldn=E2=80=99t be out of line.
E=
liot
--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg
--000000000000edffa705a6e25453--