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

Eric Rescorla <> Tue, 19 December 2023 17:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B81AC2395F0 for <>; Tue, 19 Dec 2023 09:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5vvrWdAJO1ss for <>; Tue, 19 Dec 2023 09:47:15 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id B29CAC2395E4 for <>; Tue, 19 Dec 2023 09:47:15 -0800 (PST)
Received: by with SMTP id 3f1490d57ef6-dbcd0928530so3140942276.1 for <>; Tue, 19 Dec 2023 09:47:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1703008035; x=1703612835;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lMTysHPSs9w5vHGHx7WFdUYE6jRDCNalZND92NfxHuU=; b=BBK8eltiIx6n2en74F88LYU0++ejBOizhK9lKFKxlGIsAn8e/yqMDyH6cCGhXd9/Aj enYuleBmFv5D88QMiRMCZWjptCXzxiChWE31+8tN8bsbkY+gUS+7qIhCWpBXB98Bi3n+ JSNL5ovm+1CYjjqb775cL8S3c2ypE2YEJ5+NQo4jQ2JKBgaRdtzjaeBlTLcOwQh44CPY HXLuuOHY706jPGEvtSGsvU4aN+5OPg4U/3Snic1FkXO6ApodwfFHaBN4Vjf/usUnGrAV hUUwMGlBCtrpoAJQWwhJLvSC4IluHBQQcdPzU02pE3xlo+d5v/sODHFxAkbk2+5uyNfd az3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1703008035; x=1703612835; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lMTysHPSs9w5vHGHx7WFdUYE6jRDCNalZND92NfxHuU=; b=lEULzY3jrLTKaX1cMimkQjthVeUxkq8lnuuUxYkoPPgHpNGJeA4u7qyieoqb+1J85l kA5jE/aEqtVVfJ4HUH30GSHb7RBbRBo3wzgJtHvxlwjr6sagIf6ScWC5eCPuqYX9kCJD WEAhZQJHtmnssu6UiYvn3t4ggGDNXhS8aidi8FHnjffZaxE5wqpWfNCoCd5FbHMH60bc PpRuXqaAnFgnOWoVS4FOLqHnWl1F88mi+izAY3lZOFHuJXqdTmag0lT1yBdGs+eknflS UE8ApVfvAmwlT4Xg4QEBgCfsytKkVT4zzELN97BN+EwDShR43oTtaSmZOvQGL0a2EvEd xG7g==
X-Gm-Message-State: AOJu0YxAYuQa1v6O6soYcUD6SFym4ZK8Gsu3G6Uv8jc7N8MRXXu6z9pk ipZ1i/MMpQQJeDt5NJ6NtueEO3etWd2azhDIv0aDaw==
X-Google-Smtp-Source: AGHT+IHzGyDDIe3TBmqOxBNvT4wKlGa/kR4+TfMgFcDF+yQODOhI1+Pue2pOkPHQ/6hDVRVqLOZwjSUecyngYs5+iy8=
X-Received: by 2002:a05:6902:2007:b0:dbd:84a:c686 with SMTP id dh7-20020a056902200700b00dbd084ac686mr3277147ybb.15.1703008034799; Tue, 19 Dec 2023 09:47:14 -0800 (PST)
MIME-Version: 1.0
References: <> <> <CWXP265MB5153610FBB98A7B06AF81040C290A@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM> <> <CWXP265MB515381523714FF99524410CFC290A@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Tue, 19 Dec 2023 09:46:38 -0800
Message-ID: <>
To: Eliot Lear <>
Cc: S Moonesamy <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000f6d4bf060ce074c3"
Archived-At: <>
Subject: Re: [arch-d] IAB Statement on Encryption and Mandatory Client-side Scanning of Content
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Dec 2023 17:47:16 -0000

On Tue, Dec 19, 2023 at 1:20 AM Eliot Lear <> wrote:

> 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.
Sure. This message was not intended to take sides on the IAB statement, but
merely to help clarify what seemed to be confusion about terminology.


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