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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> wrote:A few thoughts on parts of this thread --
> On 6 Jan 2023, at 12:19 am, Brad Chen <bradchen=40google.com@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxx
https://www.irtf.org/mailman/listinfo/pearg
hrpc mailing list
hrpc@xxxxxxxx
https://www.irtf.org/mailman/listinfo/hrpc
