Re: [arch-d] IAB Statement on Encryption and Mandatory Client-side Scanning of Content

Eliot Lear <lear@lear.ch> Tue, 19 December 2023 09:20 UTC

Return-Path: <lear@lear.ch>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127F9C14F5FF; Tue, 19 Dec 2023 01:20:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.896
X-Spam-Level:
X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7Ylqee2p77l; Tue, 19 Dec 2023 01:20:15 -0800 (PST)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [IPv6:2a00:bd80:aa::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB64C14F5F6; Tue, 19 Dec 2023 01:20:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1702977367; bh=GBOf6Dm9lhRSwQsaQySxphVE9W5SK1mc+MjjRbtM60g=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=YROPfvuFsQihOh5o955VRfTOf09PYiWJNyFOJ0we5YohPMk6u0lhOb4Xk3HuLJ75m BCy18UF8qEd4r0FQ2wmUwJyUAYMyPiR1m4E3abvlY7/DYzWvCVR5QAzijOx0D1fgC9 BXBUsuZ7/JcoDcJxzorn5F9OM44sseBQdbP9f/NU=
Received: from [IPV6:2001:420:c0c0:1002::1a0] ([IPv6:2001:420:c0c0:1002:0:0:0:1a0]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 3BJ9G5V02457577 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 19 Dec 2023 10:16:06 +0100
Content-Type: multipart/alternative; boundary="------------Af4l8ZLBEG0Fd06jy935aaTP"
Message-ID: <3e3d59f6-24c4-4449-ac08-1acfa7ebbe00@lear.ch>
Date: Tue, 19 Dec 2023 10:16:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Eric Rescorla <ekr@rtfm.com>
Cc: S Moonesamy <sm+ietf@elandsys.com>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, "iab@iab.org" <iab@iab.org>
References: <170266952162.33107.14325064798861197261@ietfa.amsl.com> <6.2.5.6.2.20231216110256.18d0acd0@elandnews.com> <CWXP265MB5153610FBB98A7B06AF81040C290A@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM> <CAKr6gn2Hf4N+DgKHKyO+i3T3OJyYRBJhH1AdQf-uXZ0xKmJ4Eg@mail.gmail.com> <CWXP265MB515381523714FF99524410CFC290A@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM> <790032a6-24f6-60d1-fb60-4b44bd447bde@gmail.com> <fadd9250-4b31-4bf5-aa76-4f37d24fd650@cdt.org> <CABcZeBNQBw6tiW4+JSB_8J=si2ewzZfOaSxX0eU=UrMhDv+O2A@mail.gmail.com>
From: Eliot Lear <lear@lear.ch>
Autocrypt: addr=lear@lear.ch; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNGUVsaW90IExlYXIgPGxlYXJAbGVhci5jaD7CwI4EEwECADgCGwMCHgECF4AWIQSY0L2Q Rh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCHtmtG2dJ6M8KI B/46pFrJX+4Ockl2fHR303ais9Lyx8jv6mXKKOr8WR0UYcJ0syQrhaaZNG1VV98tYQHHK9F5 y7hH4YCsrr3odZ6zoavnx5X1X/2xw8y732f/irVoOOkYLid9IGPxa2e2nYXCZpde5/yvv3we XVE4mG4dEAD5T8iKS4Hz/3fKGJQ15o79Jv92HgC7RpCt0WaiQ0b6acP3PuwjDJzJzLFZzb7j IiB3izxQESSWE1GNRmoAK/k0gW6kmx1/87tQENrK+3Nn4CJSFQWF6entLnY7UeVm95wbMQkJ evwddDWUO2huDbmZnmxgKXGzSSpuNq7n8ICAOlbt0HfdJAZQfy25bwvezsBNBFMe1UQBCAC0 WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Macj9le20EA5A1BH7PgLGo HOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U7bKeUNRiPFx3YdEkExdd qV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcYY/jB0JEJGyhS5aEbct5c HUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU+tIFBoe3iTp1AUfJcypu cGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5ABEBAAHCwF8EGAECAAkF AlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c62pWpBHHTgxr/32zevxHS iXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnXHXF5Zz2T04X7HnlIVJGw f2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycjPAu7xxKplBs1/IEwmDoA MjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPFOmDhJSmH55HLAky2Mlmq JYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt2mGfIyl0FVdF9hvWPjNR zGbgqoT1Di03RQ==
In-Reply-To: <CABcZeBNQBw6tiW4+JSB_8J=si2ewzZfOaSxX0eU=UrMhDv+O2A@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/9Sy-CsUr-mpJO3y8HHbJAaZ8oSM>
Subject: Re: [arch-d] IAB Statement on Encryption and Mandatory Client-side Scanning of Content
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Dec 2023 09:20:21 -0000

Hi!

On 18.12.2023 23:14, Eric Rescorla wrote:
>
> ISTM that this is an example of a setting in which we have a term of 
> art which is used in a way somewhat different from its literal meaning.
>
> Specifically, it is very common right now to have clients of various 
> kinds scan for material that the recipient doesn't want to receive, 
> such as in the case of spam filtering, virus scanning, or Apple's 
> sensitive content warning [0]. In many if not most of those cases, the 
> operator of the device opted into or at least actively wants that kind 
> of scanning. I think we can agree that this type of scanning works to 
> some extent and isn't incompatible with open source or open protocols. 
> This is, of course, scanning that happens on the client, and I believe 
> it's what Brian is referring to.
>
> What the IAB statement is referring to is something different, which 
> is to say scanning which is imposed upon the operator of the device 
> whether they want it or not, and is designed to stop the operator from 
> sending and receiving certain classes of content. As you note, it's 
> common practice to refer to this and not the type of scanning in the 
> previous paragraph as "client-side scanning" (in contract to 
> "server-side scanning"), but it's really the mandatory part of it that 
> makes it distinct from other cases in which scanning happens on the 
> client.


IAB statements are necessarily brief.  When they become lengthy, they 
have another vehicle: RFC.  With that in mind, there are clearly 
challenges in delineating in code the two cases you describe, as the 
interfaces that are used for one case could possibly be used for 
another; and that does strike me as intersecting the Internet 
Architecture.  I'm also confident that you have already blogged on this 
in detail ;-)

Also, this discussion seems to indicate that at least some people are 
unsatisfied with the statement.  I think we should view that as an 
opportunity.  What needs to be further teased out and what should the 
venue for that teasing be?  Here?  A separate mailing list?  PEARG?  
HRPC?  And how could the conversation best be facilitated?

Eliot