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

George Michaelson <> Mon, 18 December 2023 03:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1242DC14F5F8 for <>; Sun, 17 Dec 2023 19:12:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, 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
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Fewu0uYLGxc for <>; Sun, 17 Dec 2023 19:12:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32e]) (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 2C32DC14EB17 for <>; Sun, 17 Dec 2023 19:12:05 -0800 (PST)
Received: by with SMTP id 46e09a7af769-6da45aa5549so2302365a34.0 for <>; Sun, 17 Dec 2023 19:12:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702869125; x=1703473925;; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8yugYpeFuosOA5dYFNAUlPZLxrX3SCxhnHfWnzFV5mY=; b=gf4Rq0ptfmzX6+clKqI7wO/EzRfD+IFlN3UpHnRWIJlx+Bj+63cE1wgIuD4gL6GDKl 6Sm8ATJmdlYTCd5zzan7znk5cVq+i2Rs6XSq86DYgdgigHUr0dnZBxPDi5kkhGrdeS3F 3gur1rsCCunDFAcUL2tAiIZ1HUWje7oSOLYrxAuy/p7Vqg3fVS1HPo5MzVM8Ox7x82nb wkwsMtv2knsx5v/uajoM5Rbfopsk8F+6cJqcyF4/lZPwgVIOY2WtJo8ad5sJKybALdcp YdOtTJDGVo5RFTcSZZqS/MTpcL4zZOI7z8JZJLYBbkdSGz+ciG9CC2mywweTTwaPoCQU ysfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1702869125; x=1703473925; h=content-transfer-encoding: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=8yugYpeFuosOA5dYFNAUlPZLxrX3SCxhnHfWnzFV5mY=; b=wgyLmLww4p0WrO6LRkBVssQ+NiPyXwjHhToC7fP+vKuet02+d3Mx2uTsZVgmF4JJbo 41wCOzL8BIIwcv3zv9OLCh33Y+3ayT/1FfLZV973e3enbm0GMtgNiYpeNuDfm99tFC3G f+6XYK3QWBbHJ0T3plpM0vJIwOYCox08R7555FmajENpWoRZQTVc5S91Nrb2D5NN2cKO juY7lNZAs4K/4UDIFOKIGSFA3Vguk4nBvfQNSnNsNjxmeZ4fVw8BXWFzQdKttY0u0kWc ocllsCOHLQPHb9527YkvA5GlyWCKnJBdKAjOxtJDBfASzIRXKcbSSwldRB5zlF5cDJEn A/BA==
X-Gm-Message-State: AOJu0YxzWBGnwEEm3ZdefNEPMHm2iSO1f1msas/v9nNZEyGAcGeHEKAU 6ml08FT42HXLiRXApcL4Of2wfGq1H1ZhuBcl5Xx6uA==
X-Google-Smtp-Source: AGHT+IFmvkH6r9UcDiU0PsYNDpNVHfKlPU9JdKO66ymDWQAwZoi1mjJFFBJAoTJ8KJTWPb5CzhaiZU1PEYiynPs5++Q=
X-Received: by 2002:a9d:758a:0:b0:6d8:7886:4da7 with SMTP id s10-20020a9d758a000000b006d878864da7mr16300544otk.52.1702869124773; Sun, 17 Dec 2023 19:12:04 -0800 (PST)
MIME-Version: 1.0
References: <> <> <CWXP265MB5153610FBB98A7B06AF81040C290A@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM>
In-Reply-To: <CWXP265MB5153610FBB98A7B06AF81040C290A@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM>
From: George Michaelson <>
Date: Mon, 18 Dec 2023 13:11:53 +1000
Message-ID: <>
To: Andrew Campling <>
Cc: "" <>, "" <>, S Moonesamy <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 03:12:08 -0000

Andrew, are you arguing for anything in existing or future protocols
which would permit third party intercept? Because at the core, thats
the only modification which can address what I believe you are
concerned about, in this context: if end to end encryption coupled
with source and destination masking combines to make it infeasible to
understand what is said between two parties or who they really are,
there is no forseeable mechanism in protocols which is going to
protect against knowing parties using these protocols to conduct
illegal activity.

I think it becomes political to suggest we should of our own volition,
design systems which address the problem when our primary drive for
other reasons has been to design systems which deliberately create the
problem. You're arguing for a reversal of intent, if I read this
right. There is nothing wrong in advocating for this. But, I think it
should be overt, not implicit. I believe you advocate for a
significant change in both posture and technology at large. If I am
remembering correctly you are based in the UK and argue from a British
perspective with British laws which are now on the book in the UK,
similar ones emerging in the EU, and probably coming to Australia
shortly. So, there clearly is a wider political agenda to legislate in
this space.

This is not for one minute to suggest there is no problem, or that it
shouldn't be addressed. The concern here, is that to me it appears
infeasible to design systems which do what you want, and still do what
everyone else wants in their normal daily discourses and use of the
internet: You can't be both (anonymous and private) and (subject to
review of your content and who you communicate with) at the same time.
In effect, either the act of using encryption has to be contextually
criminalised, or we have to accept limits to how private we can be,
all the time.

Do you have any specific concrete suggestion of a privacy and
anonymity preserving design of systems, which is going to permit the
authorities to confirm no criminal activity is taking place? Because
nobody else does, that I can see. And most non-protocol changes would
be fundamental changes in law, such as a removal of a presumption of
innocence if parties refuse to decode communications which are
frankly, extremely concerning. Bear in mind that the IETF legally is
incorporated in one political economy but as participants we span
many. There are differing views of the laws, primacy of one law over
another law, rights and responsibilities.
Which means you are in effect beginning to argue for an end to the
right (wrong word, used loosely) to privacy, and anonymity. If I am
wrong, please can you explain what it is you seek?

Because of how I wrote previously I want to be clear I am not seeking
to objectify you, or paint you "wrong" on this. I am trying to
understand what specifically you think is going to happen. And if I
say "you are concerned about" I do not mean to imply nobody else is
concerned, or there is no concern here, or that doing nothing has no

Abhorrent crimes of all kinds are being committed. These crimes also
use the roads, electricity supply, water, sewage, the legal system at
large, digital cameras, lots of infrastructure devices and utility
functions are brought to bear indirectly in the commisioning of
crimes. The unique property we have in this, is that we designed
systems which include methods of masking identity and content, where
the others are simply volts, or pressure, or things on devices which
can be siezed and examined under warrant. In the case of encrypted
communications, you can't do that, and still have the value inherent
in their encryption. At least, thats how I understand it.



On Mon, Dec 18, 2023 at 10:45 AM Andrew Campling
<> wrote:
> At 8:08 PM 16-12-2023, S Moonesamy <> wrote:
> > I would like to commend the members of the IAB for acknowledging the concern about societal harms.
> The document states that "The IAB shares concerns about societal harms through the distribution of illegal content and criminal action on the Internet and recognizes the need to protect Internet users from such threats".  Whilst the document rules out the use of client-side scanning (a definition of which could usefully be added), it does not go on to indicate how the IAB recommends Internet users should be protected from such threats; is there a plan to produce a separate document that addresses this important issue?
> Andrew
> _______________________________________________
> Architecture-discuss mailing list