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

Phillip Hallam-Baker <> Tue, 19 December 2023 17:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43243C1AE96C for <>; Tue, 19 Dec 2023 09:36:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.404
X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kJiBaOMADDcz for <>; Tue, 19 Dec 2023 09:36:07 -0800 (PST)
Received: from ( []) (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 9EB83C14F5E5 for <>; Tue, 19 Dec 2023 09:36:07 -0800 (PST)
Received: by with SMTP id 006d021491bc7-59091e4a0f9so2014400eaf.1 for <>; Tue, 19 Dec 2023 09:36:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1703007367; x=1703612167; 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=IELmO2anS0nhNAzfvZhj1qVZFV5FkFGVS7UElWcl2oI=; b=mSM9/IKUUSjl8HpZstFlTGggn86k6oHN3tqBEh8ASRORBqLd+WyMROlm61jFlbrYcK RbfzUXynr+P3pUtCdFEI1C38OgkcdPT3D3Va1Xn40ST570Wepwag6X4qX3wGUv5u62Mf 6knyeQt9sNVm0R54NcOup9Eqzd6Yy3DwAOqOqPopr+18gNBHtRd3TiPXd6TFyI3Ez8YF mbzVVV0AqEJFU4tJN8rWxsDfpB4z3Xz2twI0XC2bm9+LcTIyq/VCPkJy05gmpG4fg7pp A5SvysOLG14j/LD+hY5kmMF7aHPSsavQDejfpEXxVfm/5PtuC/L7+yHulBnWSKh55Zja fp4w==
X-Gm-Message-State: AOJu0YzQp+t+pTTVQ3rNg1Bq3Nvh/GPTNLE77nnfRdwVGSj63HfUMiTN 5e6Oxmmy0kzvJbcQ6oROpFo4V+aeH7YuWaIi2ajeAfulPiE=
X-Google-Smtp-Source: AGHT+IFXMBME6N2RWEfBxshDzWSq7bc5TQkeE8WHRo8RArNENccfuIQjkMpNQno53eJjfS0bjBhT2+LbfnQnbVMKiwk=
X-Received: by 2002:a05:6820:2293:b0:58d:6e28:853f with SMTP id ck19-20020a056820229300b0058d6e28853fmr12727483oob.9.1703007366678; Tue, 19 Dec 2023 09:36:06 -0800 (PST)
MIME-Version: 1.0
References: <> <> <CWXP265MB5153610FBB98A7B06AF81040C290A@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM> <> <CWXP265MB515381523714FF99524410CFC290A@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM> <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Tue, 19 Dec 2023 12:35:54 -0500
Message-ID: <>
To: Vittorio Bertola <>
Cc: Eric Rescorla <>, Andrew Campling <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000240e47060ce04de0"
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:36:11 -0000

Windows and OSX both tag files downloaded from the Internet. Is is quite
easy to approve executables to run, the only difficulty being that the
means of doing it tends to move the UI.

There is no 'scanning' going on. The files are simply tagged according to
how they were obtained. There is no communication with a third party.

These mechanisms are entirely different in intent because they are part of
a default deny infrastructure, The goal is to only run programs that have
explicit approval. The CSAM systems are attempting to 'look for badness' as
Marcu Ranum put it.

IETF doesn't get involved in that area very deeply because it isn't an
INTERNET concern. But there is a clear need to have an industry wide
discussion about a common approach because the current system has reached
its limits. We are training users to click the box to make the system work.
Been there, done that.

On Tue, Dec 19, 2023 at 4:13 AM Vittorio Bertola <vittorio.bertola=> wrote:

> Il 18/12/2023 23:14 CET Eric Rescorla <> ha scritto:
> 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.
> Great! So, could the IAB please tell Apple to stop preventing me from
> running on my MacBook Pro executables that didn't go through their app
> store or vetting process? A few days ago I tried to run "rar" via command
> line after getting it via Homebrew, and my laptop simply refused to do so
> because rar's developer isn't a friend of Apple, and in the end I had to go
> through a seven click process at the third level of the computer's settings
> just to be able to run rar. I never asked for this check, but apparently
> there is no way, not even a cumbersome one, to disable it permanently.
> Somehow, however, this kind of client-side scanning and blocking of
> content "imposed upon the operator of the device whether they want it or
> not" does not seem to be a problem for the IAB, but blocking CSAM is.
> --
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> Office @ Via Treviso 12, 10144 Torino, Italy
> _______________________________________________
> Architecture-discuss mailing list