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

Eric Rescorla <> Mon, 18 December 2023 22:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED294C14CF05 for <>; Mon, 18 Dec 2023 14:15:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.904
X-Spam-Status: No, score=-6.904 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, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Df4X_e6Cs-14 for <>; Mon, 18 Dec 2023 14:15:32 -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 D5722C14CE52 for <>; Mon, 18 Dec 2023 14:15:32 -0800 (PST)
Received: by with SMTP id 3f1490d57ef6-dbd46d1c5faso828453276.2 for <>; Mon, 18 Dec 2023 14:15:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702937731; x=1703542531;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KhHrxf5RpTdxfCgvI+kVggc+4/czvN+S2W3JQfROH/E=; b=1x+0ZYI6ydZGSrKsx6IHysYtPvlUyze+iNkFEkY7CHiOXd7ydArK82NreBZh3BLu4d 9sHlY90De71ewnHgMUlNEMdENR083OuZGJHTs8WvXKLIRLBzHdkQbHBGUea8v+pP8gBw lhUSbs0TYwfJwCvkv9irx38zAUwR5K7r5f8BhgVeh81zCDhX9iWW/edqYbqsqwumt266 jViv/Zzn+BTKzLa91TbweMYDUEfhy3x5vlGlqtOGU1DYpm7PoyDX3d+5HRmfPA4YEClr Bs0Hkz4HbjApeThWGYKsReHGIViB4reqxxjmIZkf6scvTrfEPmNnA29/yBbkk4x5RUao SdsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702937731; x=1703542531; 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=KhHrxf5RpTdxfCgvI+kVggc+4/czvN+S2W3JQfROH/E=; b=LLE93SqHOKJddPDm/eTcBCGPOX1tEY54RywT5ex6OvbxXR5f/+EilvZ/tXCfHmIx4v eR6rT96QCkvuSFT3SonqD0tMi04C1ZMRg/aw/bmO4wdhlhfeqYIgoXgeH2fq55ywsoiP O12ZB1ShiuED4+WaO7gFUL5sUsc/HxV5dexFkikix8MiJSbvqeps3jHnv6SGNuyR00g/ Bh74X0cFp4vRoZWB+Ix1NjFnrq2/yje6VaBkkf3OBzC3wfbZuvqTbpHJPY3o49N9046m kbzaUxXh7krG1vU7tUzFU5vCiImueyRlHjy0L7f3541OD2BxecC3uRl4/oPsE/u2XnR7 PUmA==
X-Gm-Message-State: AOJu0YyQoTxS+V8F9+gVB0GjmmYElYOHNbM1liGbJzQ/UCT3RP/WZvBv YlM9XZ0FBuaDGskwWMqHhIfMolSqhzTYQVk3A9c+5w==
X-Google-Smtp-Source: AGHT+IFzZXJmuA8WtOUxfGuHw2EuDKDwyWo5RRBNpOLylvLXR0D7GEdenDm+w2nCRW1QCNHbB0JNydIiNyxbgQZePwM=
X-Received: by 2002:a5b:702:0:b0:dbd:43:5d6 with SMTP id g2-20020a5b0702000000b00dbd004305d6mr3314032ybq.11.1702937731324; Mon, 18 Dec 2023 14:15:31 -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: Mon, 18 Dec 2023 14:14:54 -0800
Message-ID: <>
To: Mallory Knodel <>
Cc: Brian E Carpenter <>, Andrew Campling <>, George Michaelson <>, "" <>, "" <>, S Moonesamy <>
Content-Type: multipart/alternative; boundary="0000000000008cf0df060cd016af"
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: Mon, 18 Dec 2023 22:15:37 -0000

On Mon, Dec 18, 2023 at 12:17 PM Mallory Knodel <mknodel=> wrote:

> Hi,
> On 12/18/23 2:22 PM, Brian E Carpenter wrote:
> > Andrew,
> >
> > On 18-Dec-23 23:43, Andrew Campling wrote:
> >
> > ...
> >> Reflecting further on the IAB statement, I do believe that the lack
> >> of inclusion of a clear definition of client-side scanning within the
> >> IAB's statement is problematic. I suspect that the real issue relates
> >> to the results of that scanning being shared with a third party
> >> without the knowledge of the user rather than the scanning per se.
> >
> > The statement is about *mandatory* scanning, which clearly implies
> > that an official third party is involved.
> >
> > IMHO, it should be my choice whether my email agent is set up to
> > detect occurrences of "Scunthorpe" in incoming email. Alternatively,
> > it should be my choice whether my mail service provider performs that
> > check for me. But none of this is a protocol issue, or a protocol
> > security issue, so however bad one believes the societal harm to be,
> > I'm at a loss to see why it's an IETF issue.
> >
> I just came back here to address the scanning, too. This line that
> client-side scanning "isn't well defined" or "means too many things" is
> just utter smoke and mirrors. Quite the opposite-- because there are so
> many ways to violate a person's civil liberties by breaking into their
> agents and devices means that *all* of them are to be rejected, early
> and often, despite their inner workings.

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.



> > The IAB statement is about the effect of specific government
> > requirements that "undermine end-to-end encryption", and that *is* a
> > protocol security issue, so it's a legitimate topic for the IAB and
> > the IETF.
> >
> >     Brian
> >
> > _______________________________________________
> > Architecture-discuss mailing list
> >
> >
> --
> Mallory Knodel
> CTO :: Center for Democracy and Technology
> newsletter ::
> _______________________________________________
> Architecture-discuss mailing list