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

Mallory Knodel <mknodel@cdt.org> Mon, 18 December 2023 12:13 UTC

Return-Path: <mknodel@cdt.org>
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 930F4C14F5E3 for <architecture-discuss@ietfa.amsl.com>; Mon, 18 Dec 2023 04:13:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org
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 ukSsN411I1sf for <architecture-discuss@ietfa.amsl.com>; Mon, 18 Dec 2023 04:13:35 -0800 (PST)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 6FF8DC14F60D for <architecture-discuss@ietf.org>; Mon, 18 Dec 2023 04:13:35 -0800 (PST)
Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a233828ab91so152297966b.1 for <architecture-discuss@ietf.org>; Mon, 18 Dec 2023 04:13:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; t=1702901613; x=1703506413; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=aY371fBf9dIh83414l4DGpbkgx/wbsUpDGw/ulNRWlM=; b=IeXd9fbX2/Gc+uARFAyeP5OEJlO3xYgd1ItJu3g8TG3lq4zvpDJ6OJwNqhLp3CSds/ 8iEC3+wAJJANANJWX2qNdLiIyl+vOAK8y77xwynYze3GyGV1/uXfogsHfOrtM2fD2ZKz G9pqE5Bn2MqURUHN2O+XHX5KWyKZOWuShs9VA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702901613; x=1703506413; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aY371fBf9dIh83414l4DGpbkgx/wbsUpDGw/ulNRWlM=; b=DzFExTRyotEN2tPud6FXBqEfqFqd3LKd5Ic01FAkKiZ2voOp1IvauTBHR1yUhzukkb WDB/WCAsVR9ZVwZIrBI89FHi1Zte+6LxXTGr59w3PIodbsBewdPUsn7BIqZp+RKRtfEJ MP6BdO+z6tUkQgas0AtZpmyWP9TsS6EnKqoaqSAEPIoSY2Yj0X0QoMO/F3D/W9A5v3rp MIYQVmj7wMk8y6HpcwHxVH8j/TCEVpldUGic+jAVGdd3z/vCy67suW36+Lz8zYUx62jQ 3Hx/yDxFbXklUvzw0O8LiHe/sgECp5kudRdcxIaSrxp08k3jpIZG+IL5meWsRAKOFtwo Zwcw==
X-Gm-Message-State: AOJu0YyTURYCiEhRn5Pa6OSsmO+yJBshKlhfSy24PoxvuSq+8OC63nEg WQ1edNjaPI11yyGe+kJtLjvtrQ==
X-Google-Smtp-Source: AGHT+IFeYwBfxPUddwRGNyZfjnFT7/wWACamqKAPYmg+mXXfrrvdY6eU2WnngutQyIOblZ88zAyfqg==
X-Received: by 2002:a17:906:73d0:b0:a23:482:ee6e with SMTP id n16-20020a17090673d000b00a230482ee6emr3678711ejl.20.1702901613126; Mon, 18 Dec 2023 04:13:33 -0800 (PST)
Received: from [10.56.8.194] ([193.175.6.21]) by smtp.gmail.com with ESMTPSA id hg20-20020a1709072cd400b00a235dfe6b4fsm794774ejc.204.2023.12.18.04.13.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Dec 2023 04:13:32 -0800 (PST)
Message-ID: <0ce2f14c-0247-4aec-a6ce-8e6607ef8f32@cdt.org>
Date: Mon, 18 Dec 2023 07:13:30 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Andrew Campling <andrew.campling@419.consulting>, George Michaelson <ggm@algebras.org>
Cc: "iab@iab.org" <iab@iab.org>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, S Moonesamy <sm+ietf@elandsys.com>
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>
From: Mallory Knodel <mknodel@cdt.org>
In-Reply-To: <CWXP265MB515381523714FF99524410CFC290A@CWXP265MB5153.GBRP265.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/wQGUB7Ztjjqjt-VKJ1FuKkzFX7w>
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: Mon, 18 Dec 2023 12:13:39 -0000

Hi all,

Just to reframe the discussion: In the statement there are two basic 
arguments made on whether technical solutions can achieve balance:

  * Can we narrow scope by implementation? No, not without wider impacts 
on the open source software ecosystem built upon the internet's 
architecture that enables permissionless innovation.

  * Can we narrow scope by implementation features (cryptography, 
automation, etc)? No again, not without wider impacts on all content. No 
technical way to specify good vs bad content.

Seems to me the IAB is a well placed authority to make these arguments. 
Most of the discussion on the list hasn't been about these core 
arguments, however, so I would deem most of what people have objected to 
as outside the scope of the IAB's comments.

However of course I have my individual, organisational and public 
interest views that I'd be happy to share if there are outstanding 
questions on whether and how corporates should provide exceptional 
access to States.

-Mallory

On 12/18/23 5:43 AM, Andrew Campling wrote:
>> At 03:12 AM 18-12-2023, S Moonesamy <sm+ietf@elandsys.com> wrote:
>> Andrew, are you arguing for anything in existing or future protocols which would permit third party intercept?
> George
> To answer your question directly, given that the IAB document acknowledges the societal harms caused by, or magnified by, the Internet, I would like to know whether it intends to produce a further statement or document that addresses that issue.  That is what prompted by earlier post on this topic to the list.
>
> You highlight the potential trade-offs between individual privacy and law enforcement [we should probably note that privacy is a qualified rather than absolute right in many (most?) jurisdictions].  The IAB's "Management Techniques in Encrypted Networks" (M-TEN) workshop considered some of the issues posed by encryption for network management purposes.  In particular, I note that the Red Rover position paper [1] considered the potential for privacy-preserving content filtering as did the one on zero knowledge middleboxes [2].
>
>
> 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.  If that is the case, this principle has already been largely addressed by RFC2084, albeit that document focuses on wiretapping rather than on-device scanning.  It should be quite simple for an update of the RFC to address this issue too.
>
> If however the IAB is against the concept of client-side scanning itself, rather than just the reporting of the results of that scanning to a third party without the knowledge of the user, then this needs a proper explanation.  It would be a surprising position for the IAB to take of course as it would essentially suggest that it is against, for example, the detection of malware.  Hence an updated statement would be beneficial that includes a definition of client-side scanning and clarity on the specific aspect(s) of that practice that are objectionable to the IAB.
>
>
> More generally, I hope that sufficient time will be allocated during the IETF 119 meeting for a discussion about this statement and the various technical, policy and societal issues that it raises, ideally beyond what would be possible as one of several slots within the regular IAB Open meeting.
>
>
> Andrew
>
>
> [1] https://www.ietf.org/ietf-ftp/slides/slides-mtenws-paper-red-rover-a-collaborative-approach-to-content-filtering-pauly-barnes-00.pdf
>
> [2] https://www.ietf.org/archive/id/draft-iab-m-ten-workshop-00.html#GRUBBS
>
>
> -----Original Message-----
> From: George Michaelson <ggm@algebras.org>
> Sent: Monday, December 18, 2023 3:12 AM
> To: Andrew Campling <andrew.campling@419.consulting>
> Cc: iab@iab.org; architecture-discuss@ietf.org; S Moonesamy <sm+ietf@elandsys.com>
> Subject: Re: [arch-d] IAB Statement on Encryption and Mandatory Client-side Scanning of Content
>
> 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 consequences.
>
> 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.
>
> cheers
>
> -George
>
> On Mon, Dec 18, 2023 at 10:45 AM Andrew Campling <andrew.campling@419.consulting> wrote:
>> At 8:08 PM 16-12-2023, S Moonesamy <sm+ietf@elandsys.com> 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
>> Architecture-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss

-- 
Mallory Knodel
CTO :: Center for Democracy and Technology
newsletter :: https://internet.exchangepoint.tech