RFC 9620

Guidelines for Human Rights Protocol and Architecture Considerations

📅 published September 2024, from ietf

RFC 9620 💖 Guidelines for Human Rights Protocol and Architecture Considerations

Internet Research Task Force (IRTF) ✨ G. Grover 🎀 N. ten Oever 💅 University of Amsterdam 🌸

Okay bestie, let's get into it! 🦋 This one is an Informational document from the IRTF, not a standard, published in September 2024 🍓. Its authors are G. Grover and N. ten Oever (University of Amsterdam). It updates RFC 8280 🧚, which means it's a fresher take on the human rights guidelines from that earlier doc. It's giving continuity, periodt 💜.

Abstract ✨

This document sets guidelines for human rights considerations for developers working on network protocols and architectures, similar to the work done on the guidelines for privacy considerations (RFC 6973). This is an updated version of the guidelines for human rights considerations in RFC 8280.

This document is a product of the Human Right Protocol Considerations (HRPC) Research Group in the IRTF.

Status of This Memo 🌈

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Human Rights Protocol Considerations Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9620.

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Table of Contents 📖

1.  Introduction
2.  Human Rights Threats
3.  Conducting Human Rights Reviews
  3.1.  Analyzing Internet-Drafts Based on Guidelines for Human
        Rights Considerations Model
  3.2.  Analyzing Internet-Drafts Based on Their Perceived or
        Speculated Impact
  3.3.  Expert Interviews
  3.4.  Interviews with Impacted Persons and Communities
  3.5.  Tracing Impacts of Implementations
4.  Guidelines for Human Rights Considerations
  4.1.  Intermediaries
  4.2.  Connectivity
  4.3.  Reliability
  4.4.  Content Signals
  4.5.  Internationalization
  4.6.  Localization
  4.7.  Open Standards
  4.8.  Heterogeneity Support
  4.9.  Adaptability
  4.10. Integrity
  4.11. Authenticity
  4.12. Confidentiality
  4.13. Security
  4.14. Privacy
  4.15. Anonymity and Pseudonymity
    4.15.1.  Pseudonymity
    4.15.2.  Unlinkability
  4.16. Censorship Resistance
  4.17. Outcome Transparency
  4.18. Accessibility
  4.19. Decentralization
  4.20. Remedy
  4.21. Miscellaneous Considerations
5.  Document Status
6.  Security Considerations
7.  IANA Considerations
8.  Research Group Information
9.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🎀

Okay so, this doc gives protocol developers a list of human rights questions to ask themselves while building or improving protocols. The goal is to figure out how their choices might affect people's ability to exercise human rights online 🫶. Just know that a protocol's impact can't be figured out from its design alone. You also have to look at how it's actually used and implemented to do a full human rights impact assessment 👀.

The questions come from research by the Human Rights Protocol Considerations (HRPC) Research Group, which came before these guidelines. That research shows human rights relate to standards and protocols, and it gives a shared vocabulary of technical concepts that affect human rights, plus how those concepts can work together so the Internet stays an enabling place for human rights. From all that, a model for writing human rights protocol considerations has started to take shape ✨.

This document is an iteration of the guidelines in [RFC8280]. The methods for conducting human rights reviews (Section 3.2) and the guidelines for human rights considerations (Section 3.3) in this document are being tested for relevance, accuracy, and validity [HR-RT]. The understanding of what human rights are is based on the "Universal Declaration of Human Rights" [UDHR] and later treaties that together make up international human rights law [UNHR].

This document doesn't give a detailed taxonomy of the nature of (potential) human rights violations, whether direct or indirect / long-term or short-term, that certain protocol choices might cause. Part of the reason is that this depends a lot on context, and part is that the doc is meant to be a practical set of guidelines. Still, more research in this area would definitely help developers and implementers 🧐.

This informational document has consensus for publication from the Internet Research Task Force (IRTF) Human Right Protocol Considerations (HRPC) Research Group. It has been reviewed, tried, and tested by the research group as well as by researchers and practitioners from outside it. The research group acknowledges that understanding how Internet protocols and architecture affect society is a developing practice, and the research is still ongoing. This document is not an IETF product and is not a standard 💅.

2. Human Rights Threats 🚨

Threats to human rights on the Internet show up in lots of ways. Protocols and standards can either harm or enable the right to freedom of expression; the right to freedom of information; the right to non-discrimination; the right to equal protection; the right to take part in cultural life, arts, and science; the right to freedom of assembly and association; the right to privacy; and the right to security. An end user who is denied access to certain services or content might not be able to disclose vital information about a government's or another authority's malpractices. A person whose communications are monitored might be stopped or discouraged from exercising their right to freedom of association or from taking part in political processes [Penney]. In a worst-case scenario, protocols that leak information can lead to physical danger. A realistic example: people seen as threats to the state get tortured, killed outside the legal process, or detained based on information state agencies collected by monitoring network traffic. That's seriously scary, bestie 😭.

This document presents several examples of how threats to human rights show up on the Internet. The threat modeling is inspired by "Privacy Considerations for Internet Protocols" [RFC6973], which is based on security threat analysis. This method is a work in progress and is by no means a perfect way to assess human rights risks in Internet protocols and systems. Some specific human rights threats are considered indirectly in Internet protocols as part of the security considerations [RFC3552]. However, privacy considerations [RFC6973] or reviews, let alone human rights impact assessments of protocols, are neither standardized nor implemented 🙈.

Lots of threats, enablers, and risks are linked to different rights. That's not surprising, since human rights are interrelated, interdependent, and indivisible. Still, this doc doesn't cover every human right, because not all of them are relevant to Information and Communication Technologies (ICTs) in general or to protocols and standards in particular [Orwat]:

The main source of the values of human rights is the _International Bill of Human Rights_ that is composed of the _Universal Declaration of Human Rights_ (UDHR) [UDHR] along with the _International Covenant on Civil and Political Rights_ (ICCPR) [ICCPR] and the _International Covenant on Economic, Social and Cultural Rights_ (ICESCR) [ICESCR]. In the light of several cases of Internet censorship, the UN Human Rights Council Resolution 20/8 was adopted in 2012, affirming that "...the same rights that people have offline must also be protected online..." [UNHRC2016]. In 2015, the _Charter of Human Rights and Principles for the Internet_ [IRP] was developed and released [Jorgensen]. According to these documents, some examples of human rights relevant for ICT systems are _human dignity_ (Art. 1 UDHR), _non-discrimination_ (Art. 2), _rights to life, liberty and security_ (Art. 3), _freedom of opinion and expression_ (Art. 19), _freedom of assembly and association_ (Art. 20), _rights to equal protection, legal remedy, fair trial, due process, presumed innocent_ (Art. 7-11), _appropriate social and international order_ (Art. 28), _participation in public affairs_ (Art. 21), _participation in cultural life, protection of intellectual property_ (Art. 27), and _privacy_ (Art. 12).

A partial catalog of human rights related to ICTs, including economic rights, can be found in [Hill].

This is by no means an attempt to exclude specific rights or to rank some rights above others. 🌷

3. Conducting Human Rights Reviews 🔍

Ideally, protocol developers and collaborators should build human rights considerations into the design process itself (see Section 3.1 ("Analyzing Internet-Drafts Based on Guidelines for Human Rights Considerations Model")). This section gives guidance on how to run a human rights review, i.e., how to gauge the impact or potential impact of a protocol or standard on human rights.

Anyone can do a human rights review, and it can happen at different stages of an Internet-Draft's development. Generally speaking, it's easier to influence a technology at earlier stages than at later ones. That doesn't mean reviews at Last Call don't matter, but they're less likely to lead to big changes in the reviewed document.

Human rights reviews can be done by document authors, document shepherds, review team members, advocates, or impacted communities who want to shape the standards development process. IETF documents can benefit from people with different knowledge, perspectives, and backgrounds, especially since their implementations can affect many different communities too 🌍.

Methods for analyzing technology for specific human rights impacts are still pretty nascent. For now, the human rights review team has explored five methods, often used together 💫.

3.1. Analyzing Internet-Drafts Based on Guidelines for Human Rights Considerations Model

This analysis of Internet-Drafts uses the model described in Section 4. The outlined categories and questions can be used to review an Internet-Draft. The advantage is that it gives a known overview, and document authors can go back to this document as well as [RFC8280] to understand the background and context 🧚.

(Part 1 of 8. Keep going, more parts are coming!) 🦋

3.2. Analyzing Internet-Drafts Based on Their Perceived or Speculated Impact ✨

okay so when you're reviewing an Internet-Draft, specific human rights impacts can totally pop out at you if you do a close reading of the draft and really think about how it might affect networks or society 👀 this is less structured than the straight-up human rights considerations model, so it's more of a vibes-and-hunches kind of analysis, but it can lead to new speculative understandings of links between human rights and protocols 🔮💅

3.3. Expert Interviews 🎤

okay bestie, talking to document authors, active working group members, or experts in the field is seriously so helpful for figuring out the characteristics of a protocol and what it does to people 🫶 there are two main advantages:

  1. It lets the reviewer gain a deeper understanding of the (intended) workings of the protocol 🧠
  2. It lets the reviewer start a discussion with experts or even document authors, which can help the review gain traction when it gets published 🚀

3.4. Interviews with Impacted Persons and Communities 🌍

protocols impact the people who use the Internet, obviously 💀 interviews can help the reviewer understand how protocols affect the people actually using them. human rights are best understood from the perspective of the rights-holder, so this approach totally levels up the understanding of the real-world effects of the tech 📈 real talk though, it can be hard to pin specific changes on one particular protocol 😩 and it's even harder when a protocol hasn't been widely deployed yet 🙈

3.5. Tracing Impacts of Implementations 🕵️‍♀️

the reality of deployed protocols can be at odds with what everyone expected during design and development [RFC8980] 😭 when a specification already has running code, the code can be analyzed either in an experimental setting or on the Internet, where its impact can be observed 👀 compared to reviewing the draft text, this approach lets the reviewer understand how the specs actually work in practice and what unknown or unexpected effects the tech might have ✨

4. Guidelines for Human Rights Considerations 📝

this section gives document authors a questionnaire about protocols and how technical decisions can shape the exercise of human rights 💖 it may be useful at any point in the design process, especially after the authors have developed a high-level protocol model as described in [RFC4101] 🧩 these guidelines don't replace any existing referenced specifications; they contribute to them and look at the design process from a human rights perspective 🌸

protocols and Internet Standards might benefit from a documented discussion of potential human rights risks from possible misapplications of the protocol or technology described in the Request for Comments (RFC) 🎀 this might be paired with an Applicability Statement for that RFC 💜

⚠️ note that the guidance in this section does NOT recommend specific practices. the range of protocols developed in the IETF is too broad to make recommendations about particular uses of data or how human rights might be balanced against other design goals 🙅‍♀️ still, by carefully considering the answers to the following questions, document authors should be able to produce a comprehensive analysis that can serve as the basis for discussion on whether the protocol adequately takes specific human rights threats into account 🦋 this guidance is meant to help the thought process of a human rights analysis; it does not give specific directions for how to write a human rights considerations section (following the example set in [RFC6973]) 📚

authors need to be aware that technical advances or the passage of time can undermine protections 🕰️ in general, considerations of rights are more effective when they have a purpose and specific use cases, rather than abstract, absolute goals 🎯

also, while this section uses the word "protocol," the principles here may apply to other kinds of solutions too (extensions to existing protocols, architecture for solutions to specific problems, etc.) 🧚

4.1. Intermediaries 🕸️

Question(s): does your protocol depend on or allow for protocol-specific functions at intermediary nodes? 🤔

Explanation: the end-to-end principle [Saltzer] holds that certain functions can and should be performed at the "ends" of the network 🔚 [RFC1958] says that "in very general terms, the community believes that the goal is connectivity ... and the intelligence is end to end rather than hidden in the network" 💫 there are new opportunities for failure when a protocol exchange includes both endpoints and an intermediary, especially when the intermediary isn't under control of either endpoint, or is even largely invisible to it, like with intercepting HTTPS proxies [HTTPS-interception] 😬 this pattern also contributes to ossification, because intermediaries may impose protocol restrictions (sometimes in violation of the specification) that stop endpoints from using more modern protocols, as described in Section 9.3 of [RFC8446] 🙅‍♀️

note that intermediaries are distinct from services. with intermediaries, the third-party element is part of the protocol exchange; with services, the endpoints communicate explicitly with the service 🤝 the client/server pattern gives clearer separation of responsibilities than having an intermediary 💅 still, even in client/server systems, it's often good practice to provide end-to-end encryption between endpoints for protocol elements outside the scope of the service, as in the design of Messaging Layer Security (MLS) [RFC9420] 🔐

example: encryption between the endpoints can protect the protocol from interference by intermediaries 🛡️ encrypting transport layer information in QUIC [RFC9000] and the TLS Server Name Indication (SNI) field [TLS-ESNI] are examples of this practice ✨ one consequence is that it limits how much network operators can inspect traffic, since they'd need control of the endpoints to monitor their behavior 👀

Impacts:

  • Right to freedom of expression 🗣️
  • Right to freedom of assembly and association 🎉

4.2. Connectivity 📶

Question(s): is your protocol optimized for low-bandwidth and high-latency connections? could your protocol also be developed in a stateless manner? 🤷‍♀️

okay, considering network quality and conditions vary across geography and time, it's also important to design protocols so they're reliable even on low-bandwidth and high-latency connections 🐢💖

Impacts:

  • Right to freedom of expression 🗣️
  • Right to freedom of assembly and association 🎉

4.3. Reliability 🛡️

Question(s): is your protocol fault tolerant? does it downgrade gracefully, i.e., with mechanisms for fallback and/or notice? can your protocol resist malicious degradation attempts? do you have a documented way to announce degradation? do you have measures in place for recovery or partial healing from failure? can your protocol maintain dependability and performance in the face of unanticipated changes or circumstances? 😵‍💫

Explanation: reliability and resiliency mean a protocol will execute its function consistently and resist errors, as described, and will work without unexpected results 💪 measures for reliability assure users that their intended communication was successfully executed 📬

a system that's reliable degrades gracefully and has a documented way to announce degradation 📣 it also has mechanisms to recover from failure gracefully and, if applicable, allows for partial healing 🩹

it's important to draw a distinction between random degradation and malicious degradation 🚨 some attacks against previous versions of TLS, for example, exploited TLS's ability to gracefully downgrade to non-secure cipher suites [FREAK] [Logjam] 😭 functionally that's useful, but security-wise it can be disastrous 💀

for reliability, services need to notify users if a delivery fails 📩 for real-time systems, the protocol also needs to safeguard timeliness, on top of reliable delivery ⏱️

example: in the modern IP stack, a reliable transport layer requires an indication that transport processing has successfully completed, such as TCP's ACK message [RFC9293] ✅ similarly, an application-layer protocol may require an application-specific acknowledgement that contains, among other things, a status code indicating the disposition of the request (see [RFC3724]) 🧾

Impacts:

  • Right to freedom of expression 🗣️
  • Right to security 🔒

4.4. Content Signals 🚦

Question(s): does your protocol include explicit or implicit plaintext elements, in either the payload or the headers, that can be used for differential treatment? is there a way to minimize leaking such data to network intermediaries? if not, is there a way for deployments of the protocol to make the differential treatment (including prioritization of certain traffic), if any, auditable for negative impacts on net neutrality? 🕵️‍♀️

example: when network intermediaries can figure out what type of content a packet is carrying, they can use that info to discriminate in favor of one type of content and against another 😤 this impacts users' ability to send and receive the content of their choice 💔

as recommended in [RFC8558], protocol designers should avoid building implicit signals of their content 🙅‍♀️ in general, designers should avoid adding explicit signals for intermediaries 🚫 in certain cases it may be necessary to add such explicit signals, but designers should only do so when they provide clear benefit to end users (see [RFC8890] for more on the priority of constituencies) 💡 in these cases, the implications of those signals for human rights should be documented 📝

note that many protocols provide signals intended for endpoints that intermediaries can use as implicit signals for traffic discrimination, based on either the content (e.g., TCP port numbers) or the sender/receiver (IP addresses) 👀 where possible, these should be protected from intermediaries by encryption 🔐 in many cases (e.g., IP addresses) these signals are hard to remove, but in other cases, like TLS Application Layer Protocol Negotiation [RFC7301], there are active efforts to protect this data [TLS-ESNI] 🌈

Impacts:

  • Right to freedom of expression 🗣️
  • Right to non-discrimination ⚖️
  • Right to equal protection 💜

4.5. Internationalization 🌍✨

Question(s): Okay bestie, so does your protocol define text string elements, in the payload or headers, that humans have to understand or type in? Does your spec allow Unicode? If so, do you accept texts in one character set (which must be UTF-8) or several (which is dangerous for interoperability)? If charsets or encodings other than UTF-8 are allowed, does your spec mandate a proper tagging of the charset? Did you have a look at [RFC6365]? 💅

Explanation: Internationalization is the practice of making protocols, standards, and implementations usable in different languages and scripts (see Section 4.6 ("Localization")). In the IETF, internationalization means adding or improving how non-ASCII text is handled in a protocol [RFC6365]. 🦋 A different vibe, which fits protocols built for global use from the start, is the definition from the World Wide Web Consortium (W3C) [W3Ci18nDef]:

Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.

Lowkey, lots of protocols that handle text only handle one charset (US-ASCII), or they leave the question of which coded charset and encoding get used to local guesswork. 💀 That leads, of course, to interoperability problems. If multiple charsets are permitted, they must be explicitly identified [RFC2277]. Adding non-ASCII text lets a protocol handle more scripts, which hopefully represents users all over the world 🌸. In today's world, that is normally best done by allowing only Unicode encoded in UTF-8.

In current IETF practice [RFC2277], internationalization is aimed at user-facing strings, not protocol elements, like the verbs used by some text-based protocols. (Do note that some strings are both content and protocol elements, such as identifiers.) This is reasonable for non-user-visible elements, but developers should provide full and equal support for all scripts and charsets in the user-facing features of protocols and for any content they carry. It's giving respect 🫶.

Example: See Section 4.6 ("Localization").

Impacts:

  • Right to freedom of expression
  • Right to political participation
  • Right to participate in cultural life, arts, and science

4.6. Localization 🗺️💖

Question(s): Does your protocol uphold the standards of internationalization? Have you made any concrete steps towards localizing your protocol for relevant audiences?

Explanation: "Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a 'locale')" [W3Ci18nDef]. For our purposes, it's the practice of translating an implementation so it works in a specific language or for users in a specific locale (see Section 4.5 ("Internationalization")). Internationalization and localization are related, but they are not the same thing. Internationalization is a necessary precondition for localization. 🧚

Example: The Internet is a global medium, but many of its protocols and products are developed with certain audiences in mind, audiences that often share particular traits, like knowing how to read and write in American Standard Code for Information Interchange (ASCII) and knowing English. 😭 This limits the ability of a large part of the world's online population to use the Internet in a way that is culturally and linguistically accessible. An example of a standard that took into account that individuals like to have access to data in their preferred language is [RFC5646]. The document describes a way to label information with an identifier for the language it's written in, and this allows information to be presented and accessed in more than one language. Iconic 👑.

Impacts:

  • Right to non-discrimination
  • Right to participate in cultural life, arts, and science
  • Right to freedom of expression

4.7. Open Standards 🔓📜

Question(s): Is your protocol fully documented in a way that it could be easily implemented, improved, built upon, and/or further developed? Do you depend on proprietary code for the implementation, running, or further development of your protocol? Does your protocol favor a particular proprietary specification over technically equivalent competing specification(s), for instance, by making any incorporated vendor specification "required" or "recommended" [RFC2026]? Do you normatively reference another standard that is behind a paywall (and could you do without it)? Are you aware of any patents that would prevent your standard from being fully implemented [RFC8179] [RFC6701]?

Explanation: The Internet became the global network of networks because open, non-proprietary standards existed [Zittrain]. 🌈 They are crucial for enabling interoperability. Yet open standards are not explicitly defined within the IETF. On the subject, [RFC2026] states:

Various national and international standards bodies, such as ANSI, ISO, IEEE, and ITU-T, develop a variety of protocol and service specifications that are similar to Technical Specifications defined here [at the IETF]. National and international groups also publish "implementors' agreements" that are analogous to Applicability Statements, capturing a body of implementation- specific detail concerned with the practical application of their standards. All of these are considered to be "open external standards" for the purposes of the Internet Standards Process.

Similarly, [RFC3935] doesn't define open standards, but it does emphasize the importance of an "open process", i.e.:

... any interested person can participate in the work, know what is being decided, and make [their] voice heard on the issue.

Open standards (and open source software) let users figure out how the tools they're using work, including their security and privacy properties. 🔍 They also allow for permissionless innovation, which keeps the freedom and ability to create and deploy new protocols on top of the communications constructs that already exist. This is at the heart of the Internet as we know it, and to keep its fundamentally open nature, we need to be mindful of developing open standards. Main character energy for the open web 🦋.

All standards that need to be normatively implemented should be freely available, with reasonable protection against patent infringement claims, so they can also be implemented in open source or free software. Patents have often held back open standardization, or been used against those deploying open standards, particularly in the domain of cryptography [Newegg]. 😤 There is one exception: a standardized protocol sometimes normatively relies on specifications produced by other Standards Development Organizations (SDOs) that are not freely available. Patents in open standards, or in normative references to other standards, should have a patent disclosure [Note-well], royalty-free licensing [Patent-policy], or some other form of fair, reasonable, and non-discriminatory terms.

Example: [RFC6108] describes a system for providing critical end-user notifications to web browsers, and it has been deployed by Comcast, an Internet Service Provider (ISP). 📡 Such a notification system is used to provide near-immediate notifications to customers, for example to warn them that their traffic shows patterns indicative of malware or virus infection. There are other proprietary systems that can do such notifications, but those utilize Deep Packet Inspection (DPI) technology. In contrast, that document describes a system that does not rely on DPI and is instead based on open IETF standards and open source applications. Not the surveillance vibes, honestly 🙈.

Impacts:

  • Right to freedom of expression
  • Right to participate in cultural life, arts, and science

4.8. Heterogeneity Support 🧩🌷

Question(s): Does your protocol support heterogeneity by design? Does your protocol allow for multiple types of hardware? Does your protocol allow for multiple types of application protocols? Is your protocol liberal in what it receives and handles? Will it remain usable and open if the context changes?

Explanation: The Internet is full of heterogeneity on many levels: devices, nodes, router scheduling algorithms, queue management mechanisms, routing protocols, levels of multiplexing, protocol versions and implementations, and underlying link layers (e.g., point-to-point, multi-access links, wireless, Fiber Distributed Data Interface (FDDI), etc.) in the traffic mix and in the levels of congestion at different times and places. 🌐 Plus, because the Internet is made of autonomous organizations and ISPs, each with their own policy concerns, there's a huge mix of administrative domains and pricing structures. As a result, the heterogeneity principle proposed in [RFC1958] needs to be supported by design [FIArch]. ✨

Heterogeneity support in protocols can enable a wide range of devices and, by extension, users to take part in the network. It's a whole vibe 💜.

Example: Heterogeneity significantly contributed to the success of the Internet architecture [Zittrain]. There's a famous quote often attributed to Niels Bohr: "Prediction is very difficult, especially if it's about the future." 🔮 This also holds true for future uses of the Internet architecture and infrastructure. Therefore, as a rule of thumb, it is important to -- as far as possible -- design your protocol for different devices and uses, especially at lower layers of the stack. However, if you choose not to do this, it could be relevant to document the reasoning for that. Receipts, bestie 🧾.

Impacts:

  • Right to freedom of expression
  • Right to political participation

4.9. Adaptability ✨

Okay so, bestie, this section is about adaptability and permissionless innovation, and honestly? These two are like a power couple 💅. The whole point is keeping people free to build and ship brand new protocols on top of the communication stuff that already exists. That's basically the heart of the Internet as we know it 🌈. So the question is: is your protocol built in a modular way that makes it easy to extend, or does it make that stuff harder? Does it help or hurt permissionless innovation? (See Section 4.7 ("Open Standards").) 🫶

Here's why it's giving so much importance. We want the Internet to keep growing, which means we have to watch how protocols affect whether people can keep innovating 🦋. Adaptability also lets groups of users shape their information networks the way they want 🎀. And here's the thing: you can't adapt a network you don't understand. So being able to know and understand the network is a precondition for adapting it 🧚. That's lowkey why adaptability ties into the right to education and the right to science, plus the right to freedom of assembly and association and the right to freedom of expression. Users need to be able to figure out how to gather, collaborate, and express themselves ✨.

Example: WebRTC generates audio and/or video data 🎥. It can be used in different locations by different parties, and its standard Application Programming Interfaces (APIs) were developed to support applications from different voice service providers 📞. Lots of parties end up with similar capabilities 💜. So if everyone's going to build on existing standards, those standards have to be adaptable and allow for permissionless innovation 🙌.

Impacts:

  • Right to education 📚
  • Right to science 🔬
  • Right to freedom of expression 🗣️
  • Right to freedom of assembly and association 🤝

4.10. Integrity 🔒

Question(s): Does your protocol maintain, assure, and/or verify the accuracy of payload data? Does your protocol maintain and assure the consistency of data? Does your protocol in any way allow for the data to be (intentionally or unintentionally) altered?

Explanation: Integrity is all about maintaining and assuring that data is accurate and consistent, so we know it hasn't been changed (on purpose or by accident) 💖.

Example: Integrity verification matters a lot for preventing vulnerabilities and attacks from on-path attackers 😭. These are the baddies who sneak in between two parties, pretend to be in the middle, and change what's being sent 💀. Here's how it plays out:

Alice wants to communicate with Bob. Alice sends a message to Bob, which Corinne intercepts and modifies. Bob cannot see that the data from Alice was altered by Corinne. Corinne intercepts and alters the communication as it is sent between Alice and Bob. Corinne is able to control the communication content.

Impacts:

  • Right to freedom of expression 🗣️
  • Right to security 🛡️

4.11. Authenticity 🪪

Question(s): Do you have sufficient measures to confirm the truth of an attribute of a single piece of data or entity? Can the attributes get garbled along the way (see Section 4.13 ("Security"))? If relevant, have you implemented IPsec, DNS Security (DNSSEC), HTTPS, and other standard security best practices?

Explanation: Authenticity makes sure data actually comes from the source it says it comes from 💅. That matters for stopping certain attacks and unauthorized access and use of data 🙈.

But ngl, authentication should never be used as a way to block heterogeneity support, which is sadly something that happens for vendor lock-in or digital rights management 😤.

Example: Authentication of data is a huge deal for preventing vulnerabilities and attacks from on-path attackers 🚨. These are the sneaky third parties (usually up to no good) who intercept a communication between two parties, slide in the middle, and pose as both of them 👀. Here's the drama:

Alice wants to communicate with Bob. Alice sends data to Bob. Corinne intercepts the data sent to Bob. Corinne reads (and potentially alters) the message to Bob. Bob cannot see that the data did not come from Alice but from Corinne.

And with proper authentication, the scenario would be as follows:

Alice wants to communicate with Bob. Alice sends data to Bob. Corinne intercepts the data sent to Bob. Corinne reads and alters the message to Bob. Bob is unable to verify whether that the data came from Alice.

Impacts:

  • Right to privacy 🫣
  • Right to freedom of expression 🗣️
  • Right to security 🛡️

4.12. Confidentiality 🤫

Question(s): Does the protocol expose the transmitted data over the wire? Does the protocol expose information related to identifiers or data? If so, what does it reveal to each protocol entity (i.e., recipients, intermediaries, and enablers) [RFC6973]? What options exist for protocol implementers to choose to limit the information shared with each entity? What operational controls are available to limit the information shared with each entity?

What controls or consent mechanisms does the protocol define or require before personal data or identifiers are shared or exposed via the protocol? If no such mechanisms or controls are specified, is it expected that control and consent will be handled outside of the protocol?

Does the protocol provide ways for initiators to share different pieces of information with different recipients? If not, are there mechanisms that exist outside of the protocol to provide initiators with such control?

Does the protocol provide ways for initiators to limit the sharing or expressing of individuals' preferences to recipients or intermediaries with regard to the collection, use, or disclosure of their personal data? If not, are there mechanisms that exist outside of the protocol to provide users with such control? Is it expected that users will have relationships that govern the use of the information (contractual or otherwise) with those who operate these intermediaries? Does the protocol prefer encryption over cleartext operation?

Explanation: Confidentiality means keeping your data a secret from unintended listeners [RFC3552] 🧏‍♀️. The growth of the Internet depends on users being confident that the network protects their personal data [RFC1984] 💜. Pervasive monitoring and surveillance chip away at that trust, and it can be mitigated by ensuring confidentiality, so passive attackers get little or no information from watching or inferring protocol activity [RFC7258] [RFC7624] 🔐.

Example: Protocols that don't encrypt their payload leave the entire content of the communication visible to the idealized attacker along their path 😬. Following the advice in [RFC3365], most such protocols have a secure variant that encrypts the payload for confidentiality, and these secure variants are seeing ever-wider deployment 📈. A noteworthy exception is DNS [RFC1035], since DNSSEC [RFC4033] does not have confidentiality as a requirement 🙃. This implies that, without more recent standards like DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484], all DNS queries and answers generated by the activities of any protocol are available to the attacker 🫠. When store-and-forward protocols are used (e.g., SMTP [RFC5321]), intermediaries leave this data open to observation by an attacker that has compromised them, unless the data is encrypted end-to-end by the application-layer protocol or the implementation uses an encrypted store for this data [RFC7624] 📦.

Impacts:

  • Right to privacy 🫣
  • Right to security 🛡️

4.13. Security 🛡️

Question(s): Did you have a look at "Guidelines for Writing RFC Text on Security Considerations" [RFC3552]? Have you found any attacks that are somewhat related to your protocol/specification yet considered out of scope of your document? Would these attacks be pertinent to the human-rights-enabling features of the Internet (as described throughout this document)?

Explanation: Security isn't one big monolithic property of a protocol or system. It's a series of related but somewhat independent properties 🧩. Not all of them are required for every application. Since communications are carried out by systems, and access to systems is through communications channels, security goals obviously interlock, but they can also be provided independently [RFC3552] ✨.

Typically, any protocol operating on the Internet can be the target of passive attacks (when the attacker can access and read packets on the network) and active attacks (when an attacker is capable of writing information to the network packets) [RFC3552] 👀.

Example: See [RFC3552] 📖.

Impacts:

  • Right to freedom of expression 🗣️
  • Right to freedom of assembly and association 🤝
  • Right to non-discrimination 🌈
  • Right to security 🛡️

4.14. Privacy 🫣

Question(s): Did you have a look at the guidelines described in Section 7 of "Privacy Considerations for Internet Protocols" [RFC6973]? Does your protocol maintain the confidentiality of metadata? Could your protocol counter traffic analysis? Does your protocol adhere to data minimization principles? Does your document identify potentially sensitive data logged by your protocol and/or for how long that needs to be retained for technical reasons?

Explanation: Privacy is the right of an entity (usually a person), acting on its own behalf, to decide how much it interacts with its environment, including how much of its personal information it's willing to share with others [RFC4949] 🙋‍♀️. If a protocol doesn't protect privacy well enough, it can hurt freedom of expression, because users self-censor for fear of surveillance or find they can't express themselves freely 😰.

Example: See [RFC6973] 📖.

Impacts:

  • Right to freedom of expression 🗣️
  • Right to privacy 🫣
  • Right to non-discrimination 🌈

4.15. Anonymity and Pseudonymity 🦋

Okay bestie, let's talk about who is who on the internet 👀 Question(s): Does your protocol use identifiers? Are they persistent? Are they used across multiple contexts? Can the user reset or rotate them without breaking the protocol? Are they visible to anyone besides the protocol endpoints? Are they tied to real-world identities? Have you considered "Privacy Considerations for Internet Protocols" [RFC6973], especially Section 6.1.2? 💅

Explanation: Most protocols need some kind of identifier so they can connect activity over time and space. Think of it like a name tag so the system knows it's still you 🏷️ For instance:

  • IP addresses are used as an identity for the source and destination of IP datagrams.
  • QUIC connection identifiers are used to correlate packets belonging to the same connection.
  • HTTP uses cookies to correlate multiple HTTP requests from the same client.
  • Email uses email addresses of the form example@example.com to identify senders and receivers.

Identifiers are genuinely necessary for protocols to keep continuity going, but they can also create privacy risks 😬 There are two major ways those risks show up:

  • The identifier may itself reveal the user's identity in some way, or be tied to an identifier that does. This happens when E.164 (telephone) numbers are used as identifiers for instant messaging systems 📱
  • The identifier may not reveal who you are, but it can still make it possible to link enough of a user's behavior to threaten their privacy. HTTP cookies are a classic example 🍪

Because identifiers are needed for the protocol to work, true anonymity is very difficult to achieve. Still, there are practices that promote user privacy even when identifiers are in use ✨

Impacts:

  • Right to non-discrimination
  • Right to freedom of expression
  • Right to political participation
  • Right to freedom of assembly and association

4.15.1. Pseudonymity 🎭

In general, user privacy is better preserved when identifiers are pseudonymous (not tied to a user's real-world identity). Pseudonyms are the glow-up we want 💖

Example: While the IPv6 protocol was being developed, people discussed embedding a Media Access Control (MAC) address into unique IP addresses. That would make it possible for eavesdroppers and other information collectors to tell when different addresses used in different transactions actually belong to the same node 👀 This is why standardization efforts like "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6" [RFC8981] and MAC address randomization [MAC-ADDRESS-RANDOMIZATION] have been pursued 🙌

Note that it's often tempting to create a pseudonym from a persistent identifier. Doing that correctly, in a way that doesn't allow the persistent identifier to be recovered, can be really hard 😭

Example: A common practice in web tracking is to "encrypt" email addresses by hashing them, so they're supposedly "non-personally identifying". Not so fast 🙅‍♀️ Because hash functions are public operations, someone can run a dictionary search over candidate email addresses and recover the original address [Email-hashing]. Hashing isn't a disguise, bestie 💀

4.15.2. Unlinkability 🔗

Even truly pseudonymous identifiers can be a privacy risk if they're used across a wide enough scope. User privacy is better preserved when identifiers have limited scope in both time and space ⏳

Example: The Dynamic Host Configuration Protocol (DHCP) is one example. Sending a persistent identifier as the client name was not mandatory, but in practice many implementations did it anyway before DHCP [RFC7844] 🫠

Example: Third-party cookies in HTTP let trackers correlate HTTP traffic across sites. This is the foundation of a whole ecosystem of web tracking 🕸️ Thankfully, web browsers are increasingly restricting the use of third-party cookies to protect user privacy 🛡️

4.16. Censorship Resistance 🕊️

Question(s): Does your protocol architecture facilitate censorship? Does it include "choke points" that are easy to use for censorship? Does it expose identifiers that can be used to selectively block certain kinds of traffic? Could it be designed to be more censorship resistant? Does your protocol make it apparent or transparent when access to a resource is restricted, and why it is restricted? 🤔

Explanation: Governments and service providers block or filter content or traffic, often without end users knowing [RFC7754]. For a survey of censorship techniques used around the world, see [RFC9505], which lays out protocol properties that have been exploited to censor access to information 📚 Censorship resistance refers to the methods and measures used to prevent Internet censorship. Protect the vibes, protect the access 🌈

Example: The current design of the Web has a number of architectural choke points where censors can intervene. These include obtaining control of the domain name itself, DNS blocking either at the protocol layer or at the resolver, IP address blocking, and blocking at the web server 🚧 There has been extensive work on content distribution systems that are intended to be more censorship resistant, and some, such as BitTorrent, are in wide use. However, these systems may have inferior reliability and performance compared to the Web (for example, they do not support active content on the server) 😮‍💨

Example: Identifiers of content exposed within a protocol might be used to facilitate censorship, because they let a censor work out which traffic to block 🎯 DNS queries, the "host" request header in an HTTP request, and the Server Name Indication (SNI) in a Transport Layer Security (TLS) ClientHello are all examples of protocol elements that can travel in plaintext and be used by censors to identify what content a user is trying to access [RFC9505]. Protocol mechanisms that encrypt metadata, such as Encrypted ClientHello [TLS-ESNI] or DNS over HTTPS [RFC8484], provide some level of resistance to this type of protocol inspection 🔐 Full traffic encryption systems, such as Tor <https://torproject.org>, can also be used by people to access otherwise censored resources 🧅

Example: As noted above, one way to censor web traffic is to require the server to block it, or to require ISPs to block requests to the server. In HTTP, denial or restriction of access can be made apparent by using status code 451, which lets server operators and intermediaries operate with greater transparency when issues of law or public policy affect their operation [RFC7725] 🫶 If a protocol potentially enables censorship, protocol designers should strive towards creating error codes that capture different scenarios (for example, blocked due to administrative policy, or unavailable because of legal requirements) to minimize ambiguity for end users. Clear error codes are a love language 💌

Impacts:

  • Right to freedom of expression
  • Right to political participation
  • Right to participate in cultural life, arts, and science
  • Right to freedom of assembly and association

4.17. Outcome Transparency 🔍

Question(s): Are the intended and foreseen effects of your protocol documented and easily understood? Have you described the central use case(s) for your protocol with a clear description of expected behavior, and how it may or may not impact other protocols, implementations, user expectations, or behavior? Have you reviewed other protocols that solve similar problems, or use similar mechanisms, to see if there are lessons to learn from their use and misuse? 🧐

Explanation: Certain technical choices may have unintended consequences. Plan the main character arc, but also check what the side characters are doing 🎬

Example: Lack of authenticity may lead to lack of integrity and negative externalities, and spam is an example of that 📧 Lack of data that could be used for billing and accounting can lead to so-called "free" arrangements that hide the actual costs and how those costs are distributed. Examples include the barter arrangements commonly used for Internet interconnection, and the commercial exploitation of personal data for targeted advertising. That's the most common funding model for so-called "free" services like search engines and social networks 💸 Unexpected outcomes might not be technical at all. They can be architectural, social, or economic. So it's important to document the intended outcomes and the other possible outcomes that have been considered 📝

Impacts:

  • Right to freedom of expression
  • Right to privacy
  • Right to freedom of assembly and association
  • Right to access to information

4.18. Accessibility 🌸

Question(s): Is your protocol designed to provide an enabling environment for all? Have you looked at the W3C Web Accessibility Initiative for examples and guidance [W3CAccessibility]? 🫧

Explanation: Sometimes, in the design of protocols, websites, web technologies, or web tools, barriers get created that keep people from using the Web. The Internet should be designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability 🌍 When Internet technologies meet this goal, the Internet will be accessible to people with a diverse range of hearing, movement, sight, and cognitive ability [W3CAccessibility]. Everyone deserves a seat at the table 🪑

Example: The HTML protocol as defined in [HTML] specifically requires that every image must have an alt attribute (with a few exceptions). This makes sure images are accessible to people who can't decipher non-text content on web pages by themselves 🖼️

Another example is the work done in the AVT and AVTCORE Working Groups in the IETF. It enables text conversation in multimedia, text telephony, wireless multimedia, and video communications for sign language and lipreading (that is, [RFC9071]) 🤟 Absolutely iconic work 👑

Impacts:

  • Right to non-discrimination
  • Right to freedom of assembly and association
  • Right to education
  • Right to political participation

4.19. Decentralization 🌸

Question(s): Okay bestie, can your protocol be implemented without a single point of control? If it applies, can it be deployed in a federated way? And does your protocol accidentally create new centralized points of control? 🧐

Explanation: Decentralization is literally one of the core ideas behind the Internet's architecture, and the IETF is obsessed with it too [RFC3935]. It means having no centralized points of control, or at least as few as possible. That's assumed to make it easier for new users to join and for new uses to unfold [Ziewitz]. It also cuts down on single points of failure, so the network keeps working even if one or several nodes go down. 💅 Ngl, when the Internet got commercialized in the early 1990s, things slowly drifted away from decentralization, and we lost a lot of the technical benefits that came with it 😭. If you want the deep dive on this, check out [Arkko] 📚.

Example: The bits moving across the Internet are getting more and more exposed to monitoring and censorship from governments, ISPs, and third (malicious) parties 👀. That's made even easier by the growing centralization of the network, which creates central infrastructure points that can be tapped into. But it's not all doom! Peer-to-peer networks, plus voice-over-IP protocols that use peer-to-peer technology together with a Distributed Hash Table (DHT) for scalability, are great examples of protocols that keep decentralization alive ✨ [Pouwelse].

Impacts:

  • Right to freedom of expression 🦋
  • Right to freedom of assembly and association 🫶

4.20. Remedy 💜

Question(s): Can your protocol help a party who's been negatively impacted get their right to remedy, without disproportionately hurting other parties' human rights, especially their right to privacy? 🥺

Explanation: Giving access to remedy, whether through states or corporations, is part of the UN Guiding Principles on Business and Human Rights [UNGP]. Access to remedy can help victims of human rights violations get justice, or let law enforcement agencies identify a possible violator 🕵️‍♀️. The tea, though: current mechanisms in protocols that try to enable "attribution" to individuals get in the way of the right to privacy 😤. The former UN Special Rapporteur for Freedom of Expression has also argued that anonymity is an inherent part of freedom of expression [Kaye]. So given how badly attribution could hit privacy and freedom of expression, enabling attribution on an individual level is most likely not consistent with human rights 🚫.

Example: Adding personally identifiable information to data streams as a way to enable the human right to remedy might help identify a human rights violator and provide access to remedy. Lowkey, though, it would disproportionately affect every user's right to privacy, anonymous expression, and association 💀. There are also some recent advances in enabling abuse detection in end-to-end encrypted messaging systems, and those carry some risk to users' privacy too [Messenger-franking] [Hecate] 🔐.

Impacts:

  • Right to remedy 🎀
  • Right to security 🛡️
  • Right to privacy 🌈

4.21. Miscellaneous Considerations 🍓

Question(s): Have you thought about the potential negative consequences, individual or societal, that your protocol or document might have? 🤔

Explanation: Publishing an RFC under a certain status has real consequences, bestie 📜. Publication as an Internet Standard on the Standards Track can signal to implementers that the specification is mature, has operational experience, and has consensus behind it ✅. On the flip side, publishing a specification as an experimental document that's not on the Standards Track tells the community that the document "may not be intended to be an Internet Standard, or it may be intended for eventual standardization but not yet ready" for wide deployment [RFC2026]. So how far a protocol spreads, and how much it ends up affecting end users, may depend on the status the RFC carries 🧠. See [RFC2026] and its updates for the full explanation 📖.

5. Document Status 🌷

This research group document lays out best practices and guidelines for human rights reviews of network protocols, architectures, and other Internet-Drafts and RFCs 🫧.

6. Security Considerations 🚨

Okay, this one's serious, so let's give it the respect it deserves 🥹. Article three of the "Universal Declaration of Human Rights" reads: "Everyone has the right to life, liberty and security of person" [UDHR]. This article underlines how important security is and how closely it's tied to human life and liberty. But human rights are indivisible, interrelated, and interdependent, so security is also closely linked to other human rights and freedoms 🕊️. This document wants to strengthen human rights, freedoms, and security by relating and translating these concepts into the concepts and practices used in Internet protocol and architecture development 🛠️. The goal is to secure human rights and, in doing so, improve the sustainability, usability, and effectiveness of the network 💪. It goes about this by providing guidelines, as done in Section 3 of this document 📋.

7. IANA Considerations 🎈

This document has no IANA actions. Easy peasy, no registries to touch 🙌.

8. Research Group Information 🌟

The discussion list for the IRTF Human Rights Protocol Considerations Research Group lives at the e-mail address: <mailto:hrpc@ietf.org> 💌.

Info about the group, plus how to subscribe to the list, is at: https://www.irtf.org/mailman/listinfo/hrpc 🔗.

Archives of the list can be found at: https://mailarchive.ietf.org/arch/browse/hrpc/ 🗂️.

9. Informative References 📚

[Arkko] Arkko, J., Trammell, B., Nottingham, M., Huitema, C., Thomson, M., Tantsura, J., and N. ten Oever, "Considerations on Internet Consolidation and the Internet Architecture", Work in Progress, Internet-Draft, draft-arkko-iab-internet-consolidation-02, 8 July 2019, https://datatracker.ietf.org/doc/html/draft-arkko-iab-internet-consolidation-02.

[Email-hashing] Acar, G., Englehardt, S., and A. Narayanan, "Four cents to deanonymize: Companies reverse hashed email addresses", April 2018, https://freedom-to-tinker.com/2018/04/09/four-cents-to-deanonymize-companies-reverse-hashed-email-addresses/.

[FIArch] Papadimitriou, D., Zahariadis, T., Martinez-Julia, P., Papafili, I., Morreale, V., Torelli, F., Sales, B., and P. Demeester, "Design Principles for the Future Internet Architecture", The Future Internet, pp. 55-67, DOI 10.1007/978-3-642-30241-1_6, January 2012, https://link.springer.com/chapter/10.1007/978-3-642-30241-1_6.

[FREAK] University of Michigan, "Tracking the FREAK Attack", Wayback Machine archive, March 2015, https://web.archive.org/web/20150304002021/https://freakattack.com/.

[Hecate] Issa, R., Alhaddad, N., and M. Varia, "Hecate, Abuse Reporting in Secure Messengers with Sealed Sender", 31st USENIX Security Symposium (USENIX Security 22), pp 2335-2352, August 2022, https://www.usenix.org/conference/usenixsecurity22/presentation/issa.

[Hill] Hill, R., "Partial Catalog of Human Rights Related to ICT Activities", May 2014, http://www.apig.ch/UNIGE%20Catalog.pdf.

[HR-RT] "IRTF-HRPC / reviews", commit 3f5fbff, December 2020, https://github.com/IRTF-HRPC/reviews.

[HTML] WHATWG, "HTML Living Standard", August 2024, https://html.spec.whatwg.org/multipage/.

[HTTPS-interception] Durumeric, Z., Ma, Z., Springall, D., Barnes, R., Sullivan, N., Bursztein, E., Bailey, M., Halderman, J., and V. Paxson, "The Security Impact of HTTPS Interception", NDSS Symposium 2017, DOI 10.14722/ndss.2017.23456, February 2017, https://doi.org/10.14722/ndss.2017.23456.

[ICCPR] United Nations General Assembly, "International Covenant on Civil and Political Rights", December 1966, https://www.ohchr.org/en/instruments-mechanisms/instruments/international-covenant-civil-and-political-rights.

[ICESCR] United Nations General Assembly, "International Covenant on Economic, Social and Cultural Rights", December 1966, https://www.ohchr.org/en/instruments-mechanisms/instruments/international-covenant-economic-social-and-cultural-rights.

[IRP] Internet Rights and Principles Dynamic Coalition, "10 Internet Rights & Principles", https://internetrightsandprinciples.org/campaign/.

[Jorgensen] Jørgensen, R. F., "An internet bill of rights", Research Handbook on Governance of the Internet, edited by Ian Brown. Cheltenham: Edward Elgar Publishing, DOI 10.4337/9781849805025.00022, April 2013, https://doi.org/10.4337/9781849805025.00022.

[Kaye] Kaye, D., "Report of the Special Rapporteur on the Promotion and Protection of the Right to Freedom of Opinion and Expression, David Kaye", A/HRC/29/32, May 2015, https://digitallibrary.un.org/record/798709?v=pdf.

[Logjam] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., Green, M., Halderman, J., Heninger, N., Springall, D., Thomé, E., Valenta, L., VanderSloot, B., Wustrow, E., Zanella-Béguelin, S., and P. Zimmerman, "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice", CCS '15: Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pp 5-17, DOI 10.1145/2810103.2813707, October 2015, https://doi.org/10.1145/2810103.2813707.

[MAC-ADDRESS-RANDOMIZATION] Zúñiga, J. C., Bernardos, C. J., Ed., and A. Andersdotter, "Randomized and Changing MAC Address State of Affairs", Work in Progress, Internet-Draft, draft-ietf-madinas-mac-address-randomization-15, 15 July 2024, https://datatracker.ietf.org/doc/html/draft-ietf-madinas-mac-address-randomization-15.

[Messenger-franking] Grubbs, P., Lu, J., and T. Ristenpart, "Message Franking via Committing Authenticated Encryption", Cryptology ePrint Archive, Paper 2017/664, July 2017, https://eprint.iacr.org/2017/664.

[Newegg] Mullin, J., "Newegg on trial: Mystery company TQP rewrites the history of encryption", Ars Technica, November 2013, https://arstechnica.com/tech-policy/2013/11/newegg-on-trial-mystery-company-tqp-re-writes-the-history-of-encryption/.

[Note-well] IETF, "Note Well", https://www.ietf.org/about/note-well/.

[Orwat] Orwat, C. and R. Bless, "Values and Networks: Steps Toward Exploring their Relationships", ACM SIGCOMM Computer Communication Review, vol. 46, no. 2, pp 25-31, DOI 10.1145/2935634.2935640, May 2016, https://doi.org/10.1145/2935634.2935640.

[Ziewitz] Ziewitz, M. and I. Brown, "A Prehistory of Internet Governance", Research Handbook on Governance of the Internet, edited by Ian Brown. Cheltenham: Edward Elgar Publishing, DOI 10.4337/9781849805025.00008, April 2013, https://doi.org/10.4337/9781849805025.00008. 📚✨

[Zittrain] Zittrain, J., "The Future of the Internet and How to Stop It", Yale University Press, 2008, https://dash.harvard.edu/handle/1/4455262. 🧠💜

Acknowledgements 🫶

Thanks to:

  • Corinne Cath-Speth for work on [RFC8280]. 💅
  • Reese Enghardt, Joe Hall, Avri Doria, Joey Salazar, Corinne Cath-Speth, Farzaneh Badii, Sandra Braman, Colin Perkins, John Curran, Eliot Lear, Mallory Knodel, Brian Trammell, Jane Coffin, Eric Rescorla, Sofía Celi, and the hrpc list for reviews and suggestions. 🌸🙌
  • Individuals who conducted human rights reviews for their work and feedback: Amelia Andersdotter, Shane Kerr, Beatrice Martini, Karan Saini, and Shivan Kaul Sahib. 🎀✨

Authors' Addresses 🦋

Gurshabad Grover Email: gurshabad@cis-india.org

Niels ten Oever University of Amsterdam Email: mail@nielstenoever.net

📦 where this page comes from