Re: [Pearg] I-D Action: draft-irtf-pearg-censorship-04.txt

Eliot Lear <lear@cisco.com> Tue, 04 August 2020 19:47 UTC

Return-Path: <lear@cisco.com>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C544A3A1117 for <pearg@ietfa.amsl.com>; Tue, 4 Aug 2020 12:47:21 -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 JX8X7eu2ebZ8 for <pearg@ietfa.amsl.com>; Tue, 4 Aug 2020 12:47:20 -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 1E8063A10E1 for <pearg@irtf.org>; Tue, 4 Aug 2020 12:47:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3098; q=dns/txt; s=iport; t=1596570440; x=1597780040; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ToUjmBHqU1qIgpWY5gzQe5k3TYnbLh5Gk7abvlrEvNs=; b=LA2D/4ak8k9UyXrL8npG+DqzzdDFs+J05bhQDLC7Lroqw6u8AbeWQi8N S1gGQhAYyOfZUUEFx9hnau+1CIRtJ0gDUqRc6gjhW+zHyKQdQbIyoO0Ub zYTmKSgYAA/gS9dn1dC9sZScnnW8YJ03x2kBCP1eEDcTt2Y1NIwXszNLx 4=;
X-IPAS-Result: A0BDBADkuilf/xbLJq1gHAEBAQEBAQcBARIBAQQEAQFAgUqBdTWBQwEgEiyENYkBh3MlnA4LAQEBDAEBLwQBAYRMAoIlJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgRthWiFcQEBAQMBI0gOBQsLGAICJgICVwYTgyaCXSCyQnaBMophgQ4qjSiCAIERJwwQgk0+hBQpgxYzgi0EthOCbIMLlwADHp97rXWDVgIEBgUCFYFqI4FXMxoIGxU7KgGCPj4SGQ2OJgUXjiY/AzA3AgYBBwEBAwmODoJGAQE
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.75,434,1589241600"; d="scan'208";a="26044150"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Aug 2020 19:47:16 +0000
Received: from dhcp-10-61-96-199.cisco.com (dhcp-10-61-96-199.cisco.com [10.61.96.199]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 074JlEGA023664 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Aug 2020 19:47:15 GMT
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Eliot Lear <lear@cisco.com>
In-Reply-To: <F62D3E02-510C-4AAB-A06E-E21BE83A9B74@isoc.org>
Date: Tue, 04 Aug 2020 21:47:13 +0200
Cc: Eric Rescorla <ekr@rtfm.com>, Mallory Knodel <mknodel@cdt.org>, "pearg@irtf.org" <pearg@irtf.org>, Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <86B902F9-0222-4E6A-B75F-7E6E505BC572@cisco.com>
References: <159466596628.22724.642459259274073600@ietfa.amsl.com> <116747697.938.1596554741142@appsuite-gw2.open-xchange.com> <57fefee9-f3d5-cf5f-3980-2b589c0aa2e9@cdt.org> <1761878407.1099.1596560345496@appsuite-gw2.open-xchange.com> <CABcZeBO4+tVcc=TjDz44o-6SK2+e2J5E+bP_cN5UHqiKTyotzw@mail.gmail.com> <F62D3E02-510C-4AAB-A06E-E21BE83A9B74@isoc.org>
To: Joseph Lorenzo Hall <hall@isoc.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-Outbound-SMTP-Client: 10.61.96.199, dhcp-10-61-96-199.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/l6PJABT4ipQ2NBOkMopmTWoeueg>
Subject: Re: [Pearg] I-D Action: draft-irtf-pearg-censorship-04.txt
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2020 19:47:22 -0000

Hi Joe and everyone

First, I want to thank the chairs and the authors and Vittorio and others for engaging in a good discussion, and in particular, I’d like to thank you for taking the time to write out this document.

There are some interesting parallels between this discussion and the terminology flames that have taken place on the IETF list.  Who gets to define or choose terms?  Does the IETF have the experience and understanding to do so?  I think I would prefer the answer to be “no”.  We are, after all, mostly engineers, and we should stick to our knitting, as it were.  To a lesser extent, this is true of the IRTF as well.

Where I think we get to have more of a voice is how those terms apply to us and our industry, and that is something we shouldn’t duck.  Therefore, my view is that we should go with a definition that would be generally acceptable to appropriate experts, if there is one.  I will note that the Wikipedia one has changed in the time you wrote the document, which does lead to a concern about stability.   You could otherwise hedge along the lines Vittorio is suggesting or in some other way.

But then we should also at least briefly state how the term applies in our context, so as to make clear that the intent is not to label every network administrator a censor.  Keep in mind that there are a great many devices on the network that will process content that have no UI, that have very limited ability to protect themselves.  Explaining how that protection is viewed is a bit broader than the scope of the current document, but would not be out of line for this group to cover, if only for a few lines.

There is also a human element that also needs to be captured in this context that a few of us noted: there are negative connotations with the word, as there should be (IMHO).  I would encourage HR people to appreciate those connotations and not to weaken them by attempting to stretch the definition beyond what you believe is really bad for society, as you will otherwise inure people to the very thing you wish to prevent.

All of this having been said, if you do want to continue on the discussion of the definition:


> On 4 Aug 2020, at 19:19, Joseph Lorenzo Hall <hall@isoc.org> wrote:
> 
> I’m not sure consent vs. non-consent will address Vittorio or Eliot’s critiques here, I suspect not.
> 

For my part it’s pretty close, my caveat being that the it would not be censorship if the owner of the device receiving the content in particular either did or would have freely and expressly given consent to certain harmful content being blocked.  I’ll readily note that is not a testable condition in advance, although it would be in retrospect.  Look at it this way: if your neighbor sees a robber breaking into your house while you are on vacation, would you like the neighbor to wait for permission to protect your property?  Surely not.

Eliot