Re: [Pearg] [hrpc] [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?

Adrian Gropper <agropper@healthurl.com> Fri, 06 January 2023 18:51 UTC

Return-Path: <agropper@gmail.com>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB479C1524B2; Fri, 6 Jan 2023 10:51:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level:
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
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 Xei1vCUysMxa; Fri, 6 Jan 2023 10:51:08 -0800 (PST)
Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) (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 C119DC1524A3; Fri, 6 Jan 2023 10:51:08 -0800 (PST)
Received: by mail-ej1-f54.google.com with SMTP id fy8so5370172ejc.13; Fri, 06 Jan 2023 10:51:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=zMkozlM3T05ZqNBosrSrkMVXpoV6Iu48w2EtdyXM7Jc=; b=yMRWt5+3hcNRTRg4e0qyM4m97ZHLKKKzwmuLJJKHcFI6BF1KIPDEzy9ayz+u1RnK6b DwRhgCsZILWaYM4aUFpWKyoEewomSBtIa/Gh9dL8ipRCFWb+/EGlNci1gxO5RnSz596W PXKT3nOZPjxOHACGtWIW5RKQWNmNtq8vk7cevwIvfkkKOjTOy+jmBIPa0c+xx1RAXDXg 6aEYkAgtFxEE7FJCbZ6Dg+qIKQ9/A+wzNOq/wBhjpv1Bd0riKoAdwRmpq/DScxZMpL1w GzohgtsNcu2V9hKrO9edgUZ3dn2TtVZX2c8aA8r+v0WOZGW0NEv8wIs2qKyT6HXpPJeS MCpg==
X-Gm-Message-State: AFqh2krfW6Qb2a/rX4JCcBWC4aPwYbY/TFJc9Fp8jfpmHp4pyzLZgAno LL/nlJmEgqYU3Ji+6YRWljQhzHKPxfRQSkxaj4A=
X-Google-Smtp-Source: AMrXdXuYiRBD/cUaWbuzX2Qc2pORZe9lDxSnTj0ZEKwfCKMnfKJJU4GK2Wn83RQ6qiuA7qukshQkgB1yPMfvuYTGHRs=
X-Received: by 2002:a17:907:c00d:b0:7ae:ef99:6fb2 with SMTP id ss13-20020a170907c00d00b007aeef996fb2mr5388471ejc.761.1673031066971; Fri, 06 Jan 2023 10:51:06 -0800 (PST)
MIME-Version: 1.0
References: <HE1PR0701MB305098F652DBC34E3C40810B89F49@HE1PR0701MB3050.eurprd07.prod.outlook.com> <764163366.39904.1672842828297@appsuite-gw2.open-xchange.com> <CABcZeBNA_nJ2waQVENUvEXro91wAYOcH0ZxWqbLH4hoKcGkosw@mail.gmail.com> <9658281.42904.1672912808774@appsuite-gw2.open-xchange.com> <CA+9kkMBLiijcAyLYn_6h8z3N00EDaxdP=f7P2-qUt4Bn1iSWEg@mail.gmail.com> <HE1PR0701MB30505DC24A725E014D60FE0189FA9@HE1PR0701MB3050.eurprd07.prod.outlook.com> <560fae4b-8624-f4ff-63a9-78e4362a5939@netmagic.com> <CAFzihuVwNEhW0trz6UP-KC6YNOFp+puvUcDkroVJkPXjSe8drQ@mail.gmail.com> <9F859ABE-6AB0-4376-9395-ACA9431AE073@mnot.net> <CAFzihuWW1V4g+fUsOu3+xE6V3E0ZW-BV+6nTnXHwwROCSDKiLA@mail.gmail.com>
In-Reply-To: <CAFzihuWW1V4g+fUsOu3+xE6V3E0ZW-BV+6nTnXHwwROCSDKiLA@mail.gmail.com>
From: Adrian Gropper <agropper@healthurl.com>
Date: Fri, 06 Jan 2023 13:50:54 -0500
Message-ID: <CANYRo8jbq8nd1hRR3xgQGH6DBR+bmvSNP9p_n9CsMREvd3Nqvg@mail.gmail.com>
To: bradchen@google.com
Cc: Mark Nottingham <mnot=40mnot.net@dmarc.ietf.org>, bradchen=40google.com@dmarc.ietf.org, vittorio.bertola=40open-xchange.com@dmarc.ietf.org, "ietf@ietf.org" <ietf@ietf.org>, "hrpc@irtf.org" <hrpc@irtf.org>, "pearg@irtf.org" <pearg@irtf.org>, saag <saag@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000071f0bc05f19ce68a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/uq9K-5EI4UMXwmzzZGATrUZj3IY>
Subject: Re: [Pearg] [hrpc] [saag] Ten years after Snowden (2013 - 2023), is IETF keeping its promises?
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jan 2023 18:51:12 -0000

I want to thank Brad for looking beyond the technology and to point out
that safety and human rights _must not_ be framed as a dichotomy.

The human rights perspective is, IMHO, about inalienable rights whereas
safety is almost always a matter of cost and compromise. When a human
rights consideration raises safety issues in the context of a specific
protocol, it's the role of the HRPC section of that protocol specification
to clearly identify the safety concern and suggest mitigations for that
safety concern. The mitigations might be costly or might force changes to
the protocol late in the RFC process but because human rights are
unalienable, there's no choice but for that protocol workgroup to do the
work.

Simply put, ten years after Snowden, it's up to us to help all IETF add an
HRPC section along the privacy and security sections to _every_
specification. If there's no HRPC, a protocol can simply just state that.

Adrian

On Fri, Jan 6, 2023 at 10:02 AM Brad Chen <bradchen=
40google.com@dmarc.ietf.org> wrote:

> Thank you for the thoughtful feedback. I will be first to admit I do not
> know enough about the IETF and as I dig into this thread and recognize
> various participants I am learning a few things. I completely agree that
> engineers and the IETF have a substantial role participating in the policy
> discussion. Engineers can invent solutions to open problems. More broadly
> they need to provide an authoritative opinion on what is possible and what
> is impossible regarding technology, and provide expertise on cost and other
> implications of a technology option. When technology is the wrong way to
> solve a problem, engineers need to be a part of the conversation to explain
> why. It is necessary and proper that the IETF contribute to the broader
> expertise required to recognize problems that are amenable to a technology
> solution and those that are not.
>
> At Google I work on public safety. I think in my comments above I may have
> overreacted to some of the language in this thread. I apologize if that was
> disruptive. However my reaction is also coming out of my broader
> experience, and my frustration at times with technical designs that have
> the consequence of sacrificing one human right for another, while ignoring
> notions of responsibility and concretely making safety worse. The industry
> has made magnificent progress on privacy in the last decade, driven by the
> leadership, sometimes self-interested, of a subset of players. I can't say
> the same thing about our progress on public safety; on the contrary I would
> argue our progress has been negative, and our trajectory is yet to be
> corrected.
>
> Brad
>
> On Thu, Jan 5, 2023 at 5:19 PM Mark Nottingham <mnot=
> 40mnot.net@dmarc.ietf.org> wrote:
>
>> A few thoughts on parts of this thread --
>>
>> > On 6 Jan 2023, at 12:19 am, Brad Chen <bradchen=
>> 40google.com@dmarc.ietf.org> wrote:
>> >
>> > I question whether the IETF has the competence to unilaterally
>> determine policy in this space. Recent comments on this thread reassure me
>> that some of us are at least equipped to recognize the limits of our
>> competence and to recognize the discretion that the IETF needs to exercise
>> in how we impact policy.
>>
>> and:
>>
>> > On 6 Jan 2023, at 3:20 am, Vittorio Bertola <vittorio.bertola=
>> 40open-xchange.com@dmarc.ietf.org> wrote:
>> >
>> > Yes, I totally agree. Ten years ago, the IETF sincerely (with the best
>> of intentions) and naively thought to be in charge of setting this tradeoff
>> in Internet communications.
>>
>>
>> I'm going to pick on the language used here, because the framing of the
>> IETF as "unilaterally determining policy" or "being in charge" leads the
>> reader to assume that we should defer to other, seemingly more
>> authoritative institutions.
>>
>> In fact, policy for the Internet isn't set by any one entity -- it's
>> polycentric / decentred governance, a trend in regulation that's been
>> widely recognised now for a couple of decades. Even inside a single
>> country, policy matters are often arrived at through collaboration between
>> many stakeholders and often are effectively controlled by non-state actors.
>> When global, this is transnational private regulation and there are many
>> examples of it beyond the Internet. It means that we need to become
>> comfortable in our role co-regulating the Internet, not try to claim
>> control or cede it to others.
>>
>> The IETF has considerable legitimacy as not only an institution that can
>> create useful technical documents, but also as a steward of the Internet
>> architecture as a means to realise and maintain a global public good, even
>> as we ourselves are an essentially private institution. In contrast, state
>> actors are still relatively unproven in their roles as Internet regulators.
>>
>> Of course we should understand what other regulators of the Internet are
>> doing and what their attitudes are, along with those of other stakeholders
>> -- for our protocols to be successful, doing so is essential. That doesn't
>> mean, however, that we should tie our hands or ask permission before
>> developing protocols. Nor does it mean we should just give up and hand over
>> change control to others, or jump to accommodate their actions when we
>> identify serious concerns around security, privacy, ossification, or other
>> areas where we have expertise.
>>
>> > The direction explored on this thread represents a tremendous and
>> important task. I'm pretty sure the way to fail is for engineers to go it
>> alone. To be competent, we need to figure out how to recognize the
>> relevance of disciplines like law and philosophy and history, and how to
>> benefit from their perspective on these issues.
>>
>> Very much agreed here, but recognise that the IETF isn't 'just engineers'
>> -- we are an open organisation representing diverse viewpoints and
>> experiences. Is it diverse enough? Of course not, but we can take steps to
>> improve this and other factors that will shore up our legitimacy for the
>> task at hand. I'd much rather do that than bury our heads in the sand --
>> which is the outcome whether we defer to external parties *or* we ignore
>> them.
>>
>> Cheers,
>>
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>> --
>> Pearg mailing list
>> Pearg@irtf.org
>> https://www.irtf.org/mailman/listinfo/pearg
>>
> _______________________________________________
> hrpc mailing list
> hrpc@irtf.org
> https://www.irtf.org/mailman/listinfo/hrpc
>