rfc9620.original | rfc9620.txt | |||
---|---|---|---|---|
Human Rights Protocol Considerations Research Group G. Grover | Internet Research Task Force (IRTF) G. Grover | |||
Internet-Draft | Request for Comments: 9620 | |||
Updates: 8280 (if approved) N. ten Oever | Updates: 8280 N. ten Oever | |||
Intended status: Informational University of Amsterdam | Category: Informational University of Amsterdam | |||
Expires: 15 August 2024 12 February 2024 | ISSN: 2070-1721 August 2024 | |||
Guidelines for Human Rights Protocol and Architecture Considerations | Guidelines for Human Rights Protocol and Architecture Considerations | |||
draft-irtf-hrpc-guidelines-21 | ||||
Abstract | Abstract | |||
This document sets guidelines for human rights considerations for | This document sets guidelines for human rights considerations for | |||
developers working on network protocols and architectures, similar to | developers working on network protocols and architectures, similar to | |||
the work done on the guidelines for privacy considerations [RFC6973]. | the work done on the guidelines for privacy considerations (RFC | |||
This is an updated version of the guidelines for human rights | 6973). This is an updated version of the guidelines for human rights | |||
considerations in [RFC8280]. | considerations in RFC 8280. | |||
This document is not an Internet Standards Track specification; it is | This document is not an Internet Standards Track specification; it is | |||
published for informational purposes. | published for informational purposes. | |||
This informational document has consensus for publication from the | This informational document has consensus for publication from the | |||
Internet Research Task Force (IRTF) Human Right Protocol | Internet Research Task Force (IRTF) Human Right Protocol | |||
Considerations Research (HRPC) Group. It has been reviewed, tried, | Considerations (HRPC) Research Group. It has been reviewed, tried, | |||
and tested by both by the research group as well as by researchers | and tested by both the research group as well as researchers and | |||
and practitioners from outside the research group. The research | practitioners from outside the research group. The research group | |||
group acknowledges that the understanding of the impact of Internet | acknowledges that the understanding of the impact of Internet | |||
protocols and architecture on society is a developing practice and is | protocols and architecture on society is a developing practice and is | |||
a body of research that is still in development. | a body of research that is still in development. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This document is not an Internet Standards Track specification; it is | |||
provisions of BCP 78 and BCP 79. | published for informational purposes. | |||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Research Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IRTF). The IRTF publishes the results of Internet-related research | |||
time. It is inappropriate to use Internet-Drafts as reference | and development activities. These results might not be suitable for | |||
material or to cite them other than as "work in progress." | 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. | ||||
This Internet-Draft will expire on 15 August 2024. | 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 Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
extracted from this document must include Revised BSD License text as | to this document. | |||
described in Section 4.e of the Trust Legal Provisions and are | ||||
provided without warranty as described in the Revised BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction | |||
2. Human rights threats . . . . . . . . . . . . . . . . . . . . 4 | 2. Human Rights Threats | |||
3. Conducting human rights reviews . . . . . . . . . . . . . . . 5 | 3. Conducting Human Rights Reviews | |||
3.1. Analyzing drafts based on guidelines for human rights | 3.1. Analyzing Internet-Drafts Based on Guidelines for Human | |||
considerations model . . . . . . . . . . . . . . . . . . 6 | Rights Considerations Model | |||
3.2. Analyzing drafts based on their perceived or speculated | 3.2. Analyzing Internet-Drafts Based on Their Perceived or | |||
impact . . . . . . . . . . . . . . . . . . . . . . . . . 6 | Speculated Impact | |||
3.3. Expert interviews . . . . . . . . . . . . . . . . . . . . 6 | 3.3. Expert Interviews | |||
3.4. Interviews with impacted persons and communities . . . . 7 | 3.4. Interviews with Impacted Persons and Communities | |||
3.5. Tracing impacts of implementations . . . . . . . . . . . 7 | 3.5. Tracing Impacts of Implementations | |||
4. Guidelines for human rights considerations . . . . . . . . . 7 | 4. Guidelines for Human Rights Considerations | |||
4.1. Intermediaries . . . . . . . . . . . . . . . . . . . . . 8 | 4.1. Intermediaries | |||
4.2. Connectivity . . . . . . . . . . . . . . . . . . . . . . 9 | 4.2. Connectivity | |||
4.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 9 | 4.3. Reliability | |||
4.4. Content signals . . . . . . . . . . . . . . . . . . . . . 10 | 4.4. Content Signals | |||
4.5. Internationalization . . . . . . . . . . . . . . . . . . 11 | 4.5. Internationalization | |||
4.6. Localization . . . . . . . . . . . . . . . . . . . . . . 12 | 4.6. Localization | |||
4.7. Open Standards . . . . . . . . . . . . . . . . . . . . . 13 | 4.7. Open Standards | |||
4.8. Heterogeneity Support . . . . . . . . . . . . . . . . . . 15 | 4.8. Heterogeneity Support | |||
4.9. Adaptability . . . . . . . . . . . . . . . . . . . . . . 16 | 4.9. Adaptability | |||
4.10. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 17 | 4.10. Integrity | |||
4.11. Authenticity . . . . . . . . . . . . . . . . . . . . . . 17 | 4.11. Authenticity | |||
4.12. Confidentiality . . . . . . . . . . . . . . . . . . . . . 18 | 4.12. Confidentiality | |||
4.13. Security . . . . . . . . . . . . . . . . . . . . . . . . 20 | 4.13. Security | |||
4.14. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 4.14. Privacy | |||
4.15. Anonymity and Pseudonymity . . . . . . . . . . . . . . . 21 | 4.15. Anonymity and Pseudonymity | |||
4.15.1. Pseudonymity . . . . . . . . . . . . . . . . . . . . 22 | 4.15.1. Pseudonymity | |||
4.15.2. Unlinkability . . . . . . . . . . . . . . . . . . . 23 | 4.15.2. Unlinkability | |||
4.16. Censorship resistance . . . . . . . . . . . . . . . . . . 23 | 4.16. Censorship Resistance | |||
4.17. Outcome Transparency . . . . . . . . . . . . . . . . . . 24 | 4.17. Outcome Transparency | |||
4.18. Accessibility . . . . . . . . . . . . . . . . . . . . . . 25 | 4.18. Accessibility | |||
4.19. Decentralization . . . . . . . . . . . . . . . . . . . . 26 | 4.19. Decentralization | |||
4.20. Remedy . . . . . . . . . . . . . . . . . . . . . . . . . 26 | 4.20. Remedy | |||
4.21. Misc. considerations . . . . . . . . . . . . . . . . . . 27 | 4.21. Miscellaneous Considerations | |||
5. Document Status . . . . . . . . . . . . . . . . . . . . . . . 28 | 5. Document Status | |||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 | 6. Security Considerations | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | 7. IANA Considerations | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | 8. Research Group Information | |||
9. Research Group Information . . . . . . . . . . . . . . . . . 29 | 9. Informative References | |||
10. Informative References . . . . . . . . . . . . . . . . . . . 29 | Acknowledgements | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
This document outlines a set of human rights protocol considerations | This document outlines a set of human rights protocol considerations | |||
for protocol developers. It provides questions engineers should ask | for protocol developers. It provides questions that engineers should | |||
themselves when developing or improving protocols if they want to | ask themselves when developing or improving protocols if they want to | |||
understand how their decisions can potentially influence the exercise | understand how their decisions can potentially influence the exercise | |||
of human rights on the Internet. It should be noted that the impact | of human rights on the Internet. It should be noted that the impact | |||
of a protocol cannot solely be deduced from its design, but its usage | of a protocol cannot solely be deduced from its design, but its usage | |||
and implementation should also be studied to form a full protocol | and implementation should also be studied to form a full protocol | |||
human rights impact assessment. | human rights impact assessment. | |||
The questions are based on the research performed by the Human Rights | The questions are based on the research performed by the Human Rights | |||
Protocol Considerations (HRPC) research group which has been | Protocol Considerations (HRPC) Research Group, which has been | |||
documented before these considerations. The research establishes | documented before these considerations. The research establishes | |||
that human rights relate to standards and protocols, and offers a | that human rights relate to standards and protocols and offers a | |||
common vocabulary of technical concepts that influence human rights | common vocabulary of technical concepts that influence human rights | |||
and how these technical concepts can be combined to ensure that the | and how these technical concepts can be combined to ensure that the | |||
Internet remains an enabling environment for human rights. With | Internet remains an enabling environment for human rights. With | |||
this, the contours of a model for developing human rights protocol | this, the contours of a model for developing human rights protocol | |||
considerations has taken shape. | considerations has taken shape. | |||
This document is an iteration of the guidelines that can be found in | This document is an iteration of the guidelines that can be found in | |||
[RFC8280]. The methods for conducting human rights reviews | [RFC8280]. The methods for conducting human rights reviews | |||
(Section 3.2), and guidelines for human rights considerations | (Section 3.2) and the guidelines for human rights considerations | |||
(Section 3.3) in this document are being tested for relevance, | (Section 3.3) in this document are being tested for relevance, | |||
accuracy, and validity. [HR-RT] The understanding of what human | accuracy, and validity [HR-RT]. The understanding of what human | |||
rights are is based on the Universal Declaration of Human Rights | rights are is based on the "Universal Declaration of Human Rights" | |||
[UDHR] and subsequent treaties that jointly form the body of | [UDHR] and subsequent treaties that jointly form the body of | |||
international human rights law [UNHR]. | international human rights law [UNHR]. | |||
This document does not provide a detailed taxonomy of the nature of | This document does not provide a detailed taxonomy of the nature of | |||
(potential) human rights violations, whether direct or indirect, | (potential) human rights violations, whether direct or indirect / | |||
long-term or short-term, certain protocol choices might present. In | long-term or short-term, that certain protocol choices might present. | |||
part because this is highly context-dependent, and in part, because | In part, it is because this is highly context-dependent and also | |||
this document aims to provide a practical set of guidelines. | because this document aims to provide a practical set of guidelines. | |||
However, further research in this field would definitely benefit | However, further research in this field would definitely benefit | |||
developers and implementers. | developers and implementers. | |||
This document is not an Internet Standards Track specification; it is | This document is not an Internet Standards Track specification; it is | |||
published for informational purposes. | published for informational purposes. | |||
This informational document has consensus for publication from the | This informational document has consensus for publication from the | |||
Internet Research Task Force (IRTF) Human Right Protocol | Internet Research Task Force (IRTF) Human Right Protocol | |||
Considerations Research Group. It has been reviewed, tried, and | Considerations Research Group. It has been reviewed, tried, and | |||
tested by both by the research group as well as by researchers and | tested by both the research group as well as researchers and | |||
practitioners from outside the research group. The HRPC research | practitioners from outside the research group. The HRPC Research | |||
group acknowledges that the understanding of the impact of Internet | Group acknowledges that the understanding of the impact of Internet | |||
protocols and architecture on society is a developing practice and is | protocols and architecture on society is a developing practice and is | |||
a body of research that is still in development. | a body of research that is still in development. | |||
2. Human rights threats | 2. Human Rights Threats | |||
Threats to the exercise of human rights on the Internet come in many | Threats to the exercise of human rights on the Internet come in many | |||
forms. Protocols and standards may harm or enable the right to | forms. Protocols and standards may harm or enable the right to | |||
freedom of expression, right to freedom of information, right to non- | freedom of expression; right to freedom of information; right to non- | |||
discrimination, right to equal protection, right to participate in | discrimination; right to equal protection; right to participate in | |||
cultural life, arts and science, right to freedom of assembly and | cultural life, arts, and science; right to freedom of assembly and | |||
association, right to privacy, and the right to security. An end- | association; right to privacy; and right to security. An end user | |||
user who is denied access to certain services or content may be | who is denied access to certain services or content may be unable to | |||
unable to disclose vital information about the malpractices of a | disclose vital information about the malpractices of a government or | |||
government or other authority. A person whose communications are | other authority. A person whose communications are monitored may be | |||
monitored may be prevented or dissuaded from exercising their right | prevented or dissuaded from exercising their right to freedom of | |||
to freedom of association or participate in political processes | association or participate in political processes [Penney]. In a | |||
[Penney]. In a worst-case scenario, protocols that leak information | worst-case scenario, protocols that leak information can lead to | |||
can lead to physical danger. A realistic example to consider is when | physical danger. A realistic example to consider is when individuals | |||
individuals perceived as threats to the state are subjected to | perceived as threats to the state are subjected to torture, extra- | |||
torture, extra-judicial killing or detention on the basis of | judicial killing, or detention on the basis of information gathered | |||
information gathered by state agencies through the monitoring of | by state agencies through the monitoring of network traffic. | |||
network traffic. | ||||
This document presents several examples of how threats to human | This document presents several examples of how threats to human | |||
rights materialize on the Internet. This threat modeling is inspired | rights materialize on the Internet. This threat modeling is inspired | |||
by [RFC6973] Privacy Considerations for Internet Protocols, which is | by "Privacy Considerations for Internet Protocols" [RFC6973], which | |||
based on security threat analysis. This method is a work in progress | is based on security threat analysis. This method is a work in | |||
and by no means a perfect solution for assessing human rights risks | progress and by no means a perfect solution for assessing human | |||
in Internet protocols and systems. Certain specific human rights | rights risks in Internet protocols and systems. Certain specific | |||
threats are indirectly considered in Internet protocols as part of | human rights threats are indirectly considered in Internet protocols | |||
the security considerations [BCP72], but privacy considerations | as part of the security considerations [BCP72]; however, privacy | |||
[RFC6973] or reviews, let alone human rights impact assessments of | considerations [RFC6973] or reviews, let alone human rights impact | |||
protocols, are neither standardized nor implemented. | assessments of protocols, are neither standardized nor implemented. | |||
Many threats, enablers, and risks are linked to different rights. | Many threats, enablers, and risks are linked to different rights. | |||
This is not surprising if one takes into account that human rights | This is not surprising if one takes into account that human rights | |||
are interrelated, interdependent, and indivisible. Here, however, | are interrelated, interdependent, and indivisible. However, here | |||
we’re not discussing all human rights because not all human rights | we're not discussing all human rights because not all human rights | |||
are relevant to information and communication technologies (ICTs) in | are relevant to Information and Communication Technologies (ICTs) in | |||
general and protocols and standards in particular [Bless]: “The main | general and to protocols and standards in particular [Orwat]: | |||
source of the values of human rights is the International Bill of | ||||
Human Rights that is composed of the Universal Declaration of Human | | The main source of the values of human rights is the | |||
Rights [UDHR] along with the International Covenant on Civil and | | _International Bill of Human Rights_ that is composed of the | |||
Political Rights [ICCPR] and the International Covenant on Economic, | | _Universal Declaration of Human Rights_ (UDHR) [UDHR] along with | |||
Social and Cultural Rights [ICESCR]. In the light of several cases | | the _International Covenant on Civil and Political Rights_ (ICCPR) | |||
of Internet censorship, the UN Human Rights Council Resolution 20/8 | | [ICCPR] and the _International Covenant on Economic, Social and | |||
was adopted in 2012, affirming that “the same rights that people have | | Cultural Rights_ (ICESCR) [ICESCR]. In the light of several cases | |||
offline must also be protected online.” [UNHRC2016] In 2015, the | | of Internet censorship, the UN Human Rights Council Resolution | |||
Charter of Human Rights and Principles for the Internet [IRP] was | | 20/8 was adopted in 2012, affirming that "...the same rights that | |||
developed and released. According to these documents, some examples | | people have offline must also be protected online..." [UNHRC2016]. | |||
of human rights relevant for ICT systems are human dignity (Art. 1 | | In 2015, the _Charter of Human Rights and Principles for the | |||
UDHR), non-discrimination (Art. 2), rights to life, liberty and | | Internet_ [IRP] was developed and released [Jorgensen]. According | |||
security (Art. 3), freedom of opinion and expression (Art. 19), | | to these documents, some examples of human rights relevant for ICT | |||
freedom of assembly and association (Art. 20), rights to equal | | systems are _human dignity_ (Art. 1 UDHR), _non-discrimination_ | |||
protection, legal remedy, fair trial, due process, presumed innocent | | (Art. 2), _rights to life, liberty and security_ (Art. 3), | |||
(Art. 7–11), appropriate social and international order (Art. 28), | | _freedom of opinion and expression_ (Art. 19), _freedom of | |||
participation in public affairs (Art. 21), participation in cultural | | assembly and association_ (Art. 20), _rights to equal protection, | |||
life, protection of the moral and material interests resulting from | | legal remedy, fair trial, due process, presumed innocent_ (Art. | |||
any scientific, literary or artistic production of which [they are] | | 7-11), _appropriate social and international order_ (Art. 28), | |||
the author (Art. 27), and privacy (Art. 12).” A partial catalog of | | _participation in public affairs_ (Art. 21), _participation in | |||
human rights related to Information and Communications Technologies, | | cultural life, protection of intellectual property_ (Art. 27), and | |||
including economic rights, can be found in [Hill2014]. | | _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 | This is by no means an attempt to exclude specific rights or | |||
prioritize some rights over others. | prioritize some rights over others. | |||
3. Conducting human rights reviews | 3. Conducting Human Rights Reviews | |||
Ideally, protocol developers and collaborators should incorporate | Ideally, protocol developers and collaborators should incorporate | |||
human rights considerations into the design process itself (see | human rights considerations into the design process itself (see | |||
Guidelines for human rights considerations). This section provides | Section 3.1 ("Analyzing Internet-Drafts Based on Guidelines for Human | |||
guidance on how to conduct a human rights review, i.e., gauge the | Rights Considerations Model")). This section provides guidance on | |||
impact or potential impact of a protocol or standard on human rights. | how to conduct a human rights review, i.e., gauge the impact or | |||
potential impact of a protocol or standard on human rights. | ||||
Human rights reviews can be done by any participant, and can take | Human rights reviews can be done by any participant and can take | |||
place at different stages of the development process of an Internet- | place at different stages of the development process of an Internet- | |||
Draft. Generally speaking, it is easier to influence the development | Draft. Generally speaking, it is easier to influence the development | |||
of a technology at earlier stages than at later stages. This does | of a technology at earlier stages than at later stages. This does | |||
not mean that reviews at last-call are not relevant, but they are | not mean that reviews at Last Call are not relevant, but they are | |||
less likely to result in significant changes in the reviewed | less likely to result in significant changes in the reviewed | |||
document. | document. | |||
Human rights review can be done by document authors, document | Human rights reviews can be done by document authors, document | |||
shepherds, members of review teams, advocates, or impacted | shepherds, members of review teams, advocates, or impacted | |||
communities to influence the standard development process. IETF | communities to influence the standards development process. IETF | |||
documents can benefit from people with different knowledges, | documents can benefit from people with different knowledge, | |||
perspectives, and backgrounds, especially since their implementation | perspectives, and backgrounds, especially since their implementations | |||
can impact many different communities as well. | can impact many different communities as well. | |||
Methods for analyzing technology for specific human rights impacts | Methods for analyzing technology for specific human rights impacts | |||
are still quite nascent. Currently, five methods have been explored | are still quite nascent. Currently, five methods have been explored | |||
by the human rights review team, often in conjunction with each | by the human rights review team, often in conjunction with each | |||
other: | other. | |||
3.1. Analyzing drafts based on guidelines for human rights | 3.1. Analyzing Internet-Drafts Based on Guidelines for Human Rights | |||
considerations model | Considerations Model | |||
This analysis of Internet-Drafts uses the model as described in | This analysis of Internet-Drafts uses the model as described in | |||
section 4. The outlined categories and questions can be used to | Section 4. The outlined categories and questions can be used to | |||
review an Internet-Draft. The advantage of this is that it provides | review an Internet-Draft. The advantage of this is that it provides | |||
a known overview, and document authors can go back to this document | a known overview, and document authors can go back to this document | |||
as well as [RFC8280] to understand the background and the context. | as well as [RFC8280] to understand the background and the context. | |||
3.2. Analyzing drafts based on their perceived or speculated impact | 3.2. Analyzing Internet-Drafts Based on Their Perceived or Speculated | |||
Impact | ||||
When reviewing an Internet-Draft, specific human rights impacts can | When reviewing an Internet-Draft, specific human rights impacts can | |||
become apparent by doing a close reading of the draft and seeking to | become apparent by doing a close reading of the draft and seeking to | |||
understand how it might affect networks or society. While less | understand how it might affect networks or society. While less | |||
structured than the straight use of the human rights considerations | structured than the straight use of the human rights considerations | |||
model, this analysis may lead to new speculative understandings of | model, this analysis may lead to new speculative understandings of | |||
links between human rights and protocols. | links between human rights and protocols. | |||
3.3. Expert interviews | 3.3. Expert Interviews | |||
Interviews with document authors, active members of the Working | Interviews with document authors, active members of the working | |||
Group, or experts in the field can help explore the characteristics | group, or experts in the field can help explore the characteristics | |||
of the protocol and its effects. There are two main advantages to | of the protocol and its effects. There are two main advantages to | |||
this approach: one the one hand, it allows the reviewer to gain a | this approach: on the one hand, it allows the reviewer to gain a | |||
deeper understanding of the (intended) workings of the protocol; on | deeper understanding of the (intended) workings of the protocol; on | |||
the other hand, it also allows for the reviewer to start a discussion | the other hand, it also allows for the reviewer to start a discussion | |||
with experts or even document authors, which can help the review gain | with experts or even document authors, which can help the review gain | |||
traction when it is published. | traction when it is published. | |||
3.4. Interviews with impacted persons and communities | 3.4. Interviews with Impacted Persons and Communities | |||
Protocols impact users of the Internet. Interviews can help the | Protocols impact users of the Internet. Interviews can help the | |||
reviewer understand how protocols affect the people that use the | reviewer understand how protocols affect the people that use the | |||
protocols. Since human rights are best understood from the | protocols. Since human rights are best understood from the | |||
perspective of the rights-holder, this approach will improve the | perspective of the rights-holder, this approach will improve the | |||
understanding of the real world effects of the technology. At the | understanding of the real-world effects of the technology. At the | |||
same time, it can be hard to attribute specific changes to a | same time, it can be hard to attribute specific changes to a | |||
particular protocol, this is of course even harder when a protocol | particular protocol; this is of course even harder when a protocol | |||
has not been (widely) deployed. | has not been widely deployed. | |||
3.5. Tracing impacts of implementations | 3.5. Tracing Impacts of Implementations | |||
The reality of deployed protocols can be at odds with the | The reality of deployed protocols can be at odds with the | |||
expectations during the protocol design and development phase | expectations during the protocol design and development phase | |||
[RFC8980]. When a specification already has associated running code, | [RFC8980]. When a specification already has associated running code, | |||
the code can be analyzed either in an experimental setting or on the | the code can be analyzed either in an experimental setting or on the | |||
Internet where its impact can be observed. In contrast to reviewing | Internet where its impact can be observed. In contrast to reviewing | |||
the draft text, this approach can allow the reviewer to understand | the draft text, this approach can allow the reviewer to understand | |||
how the specifications works in practice, and potentially what | how the specifications work in practice and potentially what unknown | |||
unknown or unexpected effects the technology has. | or unexpected effects the technology has. | |||
4. Guidelines for human rights considerations | 4. Guidelines for Human Rights Considerations | |||
This section provides guidance for document authors in the form of a | This section provides guidance for document authors in the form of a | |||
questionnaire about protocols and how technical decisions can shape | questionnaire about protocols and how technical decisions can shape | |||
the exercise of human rights. The questionnaire may be useful at any | the exercise of human rights. The questionnaire may be useful at any | |||
point in the design process, particularly after the document authors | point in the design process, particularly after the document authors | |||
have developed a high-level protocol model as described in [RFC4101]. | have developed a high-level protocol model as described in [RFC4101]. | |||
These guidelines do not seek to replace any existing referenced | These guidelines do not seek to replace any existing referenced | |||
specifications, but rather contribute to them and look at the design | specifications but, rather, contribute to them and look at the design | |||
process from a human rights perspective. | process from a human rights perspective. | |||
Protocols and Internet Standards might benefit from a documented | Protocols and Internet Standards might benefit from a documented | |||
discussion of potential human rights risks arising from potential | discussion of potential human rights risks arising from potential | |||
misapplications of the protocol or technology described in the | misapplications of the protocol or technology described in the | |||
Request For Comments (RFC). This might be coupled with an | Request for Comments (RFC). This might be coupled with an | |||
Applicability Statement for that RFC. | Applicability Statement for that RFC. | |||
Note that the guidance provided in this section does not recommend | Note that the guidance provided in this section does not recommend | |||
specific practices. The range of protocols developed in the IETF is | specific practices. The range of protocols developed in the IETF is | |||
too broad to make recommendations about particular uses of data or | too broad to make recommendations about particular uses of data or | |||
how human rights might be balanced against other design goals. | how human rights might be balanced against other design goals. | |||
However, by carefully considering the answers to the following | However, by carefully considering the answers to the following | |||
questions, document authors should be able to produce a comprehensive | questions, document authors should be able to produce a comprehensive | |||
analysis that can serve as the basis for discussion on whether the | analysis that can serve as the basis for discussion on whether the | |||
protocol adequately takes specific human rights threats into account. | protocol adequately takes specific human rights threats into account. | |||
This guidance is meant to help the thought process of a human rights | This guidance is meant to help the thought process of a human rights | |||
analysis; it does not provide specific directions for how to write a | analysis; it does not provide specific directions for how to write a | |||
human rights considerations section (following the example set in | human rights considerations section (following the example set in | |||
[RFC6973]). | [RFC6973]). | |||
In considering these questions, authors will need to be aware of the | In considering these questions, authors will need to be aware of the | |||
potential of technical advances or the passage of time to undermine | potential of technical advances or the passage of time to undermine | |||
protections. In general, considerations of rights are likely to be | protections. In general, considerations of rights are likely to be | |||
more effective if they are considered given a purpose and specific | more effective if they are considered given a purpose and specific | |||
use cases, rather than as abstract absolute goals. | use cases, rather than as abstract, absolute goals. | |||
Also note that while the section uses the word, ‘protocol’, the | Also note that while the section uses the word "protocol", the | |||
principles identified in these questions may be applicable to other | principles identified in these questions may be applicable to other | |||
types of solutions (extensions to existing protocols, architecture | types of solutions (extensions to existing protocols, architecture | |||
for solutions to specific problems, etc.). | for solutions to specific problems, etc.). | |||
4.1. Intermediaries | 4.1. Intermediaries | |||
Question(s): Does your protocol depend on or allow for protocol- | Question(s): Does your protocol depend on or allow for protocol- | |||
specific functions at intermediary nodes? | specific functions at intermediary nodes? | |||
Explanation: The end-to-end principle [Saltzer] holds that certain | Explanation: The end-to-end principle [Saltzer] holds that certain | |||
functions can and should be performed at ‘ends’ of the network. | functions can and should be performed at "ends" of the network. | |||
[RFC1958] states “that in very general terms, the community believes | [RFC1958] states that "in very general terms, the community believes | |||
that the goal is connectivity […] and the intelligence is end to end | that the goal is connectivity ... and the intelligence is end to end | |||
rather than hidden in the network.” When a protocol exchange includes | rather than hidden in the network". When a protocol exchange | |||
both endpoints and an intermediary, there are new opportunities for | includes both endpoints and an intermediary, there are new | |||
failure, especially when the intermediary is not under control of | opportunities for failure, especially when the intermediary is not | |||
either endpoint, or even largely invisible to it, as, for instance, | under control of either endpoint, or even largely invisible to it, as | |||
in intercepting HTTPS proxies [https-interception]. This pattern | in, for instance, intercepting HTTPS proxies [HTTPS-interception]. | |||
also contributes to ossification, because the intermediaries may | This pattern also contributes to ossification because the | |||
impose protocol restrictions – sometimes in violation of the | intermediaries may impose protocol restrictions -- sometimes in | |||
specification – that prevent the endpoints from using more modern | violation of the specification -- that prevent the endpoints from | |||
protocols, as described in Section 9.3 of [RFC8446]. | using more modern protocols, as described in Section 9.3 of | |||
[RFC8446]. | ||||
Note that intermediaries are distinct from services: in the former | Note that intermediaries are distinct from services. In the former | |||
case the third party element is part of the protocol exchange, | case, the third-party element is part of the protocol exchange; | |||
whereas in the latter the endpoints communicate explicitly with the | whereas in the latter, the endpoints communicate explicitly with the | |||
service. The client/server pattern provides clearer separation of | service. The client/server pattern provides clearer separation of | |||
responsibilities between elements than having an intermediary. | responsibilities between elements than having an intermediary. | |||
However, even in client/server systems, it is often good practice to | However, even in client/server systems, it is often good practice to | |||
provide for end-to-end encryption between endpoints for protocol | provide for end-to-end encryption between endpoints for protocol | |||
elements which are outside of the scope of the service, as in the | elements that are outside of the scope of the service, as in the | |||
design of MLS [I-D.ietf-mls-protocol]. | design of Messaging Layer Security (MLS) [RFC9420]. | |||
Example: Encryption between the endpoints can be used to protect the | Example: Encryption between the endpoints can be used to protect the | |||
protocol from interference by intermediaries. The encryption of | protocol from interference by intermediaries. The encryption of | |||
transport layer information in QUIC [RFC9000] and of the TLS Server | transport layer information in QUIC [RFC9000] and of the TLS Server | |||
Name Indication field [I-D.ietf-tls-esni] are examples of this | Name Indication (SNI) field [TLS-ESNI] are examples of this practice. | |||
practice. One consequence of this is to limit the extent to which | One consequence of this is to limit the extent to which network | |||
network operators can inspect traffic, requiring them to have control | operators can inspect traffic, requiring them to have control of the | |||
of the endpoints in order to monitor their behavior. | endpoints in order to monitor their behavior. | |||
Impacts: | Impacts: | |||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to freedom of assembly and association | * Right to freedom of assembly and association | |||
4.2. Connectivity | 4.2. Connectivity | |||
Questions(s): Is your protocol optimized for low bandwidth and high | Questions(s): Is your protocol optimized for low-bandwidth and high- | |||
latency connections? Could your protocol also be developed in a | latency connections? Could your protocol also be developed in a | |||
stateless manner? | stateless manner? | |||
Also considering the fact that network quality and conditions vary | Considering the fact that network quality and conditions vary across | |||
across geography and time, it is also important to design protocols | geography and time, it is also important to design protocols such | |||
such that they are reliable even on low bandwidth and high latency | that they are reliable even on low-bandwidth and high-latency | |||
connections. | connections. | |||
Impacts: | Impacts: | |||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to freedom of assembly and association | * Right to freedom of assembly and association | |||
4.3. Reliability | 4.3. Reliability | |||
Question(s): Is your protocol fault tolerant? Does it downgrade | Question(s): Is your protocol fault tolerant? Does it downgrade | |||
gracefully, i.e., with mechanisms for fallback and/or notice? Can | gracefully, i.e., with mechanisms for fallback and/or notice? Can | |||
your protocol resist malicious degradation attempts? Do you have a | your protocol resist malicious degradation attempts? Do you have a | |||
documented way to announce degradation? Do you have measures in | documented way to announce degradation? Do you have measures in | |||
place for recovery or partial healing from failure? Can your | place for recovery or partial healing from failure? Can your | |||
protocol maintain dependability and performance in the face of | protocol maintain dependability and performance in the face of | |||
unanticipated changes or circumstances? | unanticipated changes or circumstances? | |||
Explanation: Reliability and resiliency ensures that a protocol will | Explanation: Reliability and resiliency ensures that a protocol will | |||
execute its function consistently and error resistant as described, | execute its function consistently and resistant to error, as | |||
and function without unexpected result. Measures for reliability in | described, and will function without unexpected results. Measures | |||
protocols assure users that their intended communication was | for reliability in protocols assure users that their intended | |||
successfully executed. | communication was successfully executed. | |||
A system that is reliable degrades gracefully and will have a | A system that is reliable degrades gracefully and will have a | |||
documented way to announce degradation. It will also have mechanisms | documented way to announce degradation. It will also have mechanisms | |||
to recover from failure gracefully, and if applicable, will allow for | to recover from failure gracefully and, if applicable, will allow for | |||
partial healing. | partial healing. | |||
It is important here to draw a distinction between random degradation | It is important here to draw a distinction between random degradation | |||
and malicious degradation. Some attacks against previous versions of | and malicious degradation. Some attacks against previous versions of | |||
TLS, for example, exploited TLS’ ability to gracefully downgrade to | TLS, for example, exploited TLS' ability to gracefully downgrade to | |||
non-secure cipher suites [FREAK][Logjam]– from a functional | non-secure cipher suites [FREAK] [Logjam]; from a functional | |||
perspective, this is useful; from a security perspective, this can be | perspective, this is useful, but from a security perspective, this | |||
disastrous. | can be disastrous. | |||
For reliability, it is necessary that services notify the users if a | For reliability, it is necessary that services notify the users if a | |||
delivery fails. In the case of real-time systems, in addition to the | delivery fails. In the case of real-time systems, in addition to the | |||
reliable delivery, the protocol needs to safeguard timeliness. | reliable delivery, the protocol needs to safeguard timeliness. | |||
Example: In the modern IP stack structure, a reliable transport layer | Example: In the modern IP stack structure, a reliable transport layer | |||
requires an indication that transport processing has successfully | requires an indication that transport processing has successfully | |||
completed, such as given by TCP’s ACK message [RFC0793]. Similarly, | completed, such as given by TCP's ACK message [RFC9293]. Similarly, | |||
an application layer protocol may require an application-specific | an application-layer protocol may require an application-specific | |||
acknowledgment that contains, among other things, a status code | acknowledgement that contains, among other things, a status code | |||
indicating the disposition of the request (See [RFC3724]). | indicating the disposition of the request (see [RFC3724]). | |||
Impacts: | Impacts: | |||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to security | * Right to security | |||
4.4. Content signals | 4.4. Content Signals | |||
Question(s): Does your protocol include explicit or implicit | Question(s): Does your protocol include explicit or implicit | |||
plaintext elements, either in the payload or headers, that can be | plaintext elements, in either the payload or the headers, that can be | |||
used for differential treatment? Is there a way minimise leaking of | used for differential treatment? Is there a way to minimize leaking | |||
such data to network intermediaries? If not, is there a way for | such data to network intermediaries? If not, is there a way for | |||
deployments of the protocol to make the differential treatment | deployments of the protocol to make the differential treatment | |||
(including prioritisation of certain traffic), if any, auditable for | (including prioritization of certain traffic), if any, auditable for | |||
negative impacts on net neutrality? | negative impacts on net neutrality? | |||
Example: When network intermediaries are able to determine the type | Example: When network intermediaries are able to determine the type | |||
of content that a packet is carrying then they can use that | of content that a packet is carrying, then they can use that | |||
information to discriminate in favor of one type of content and | information to discriminate in favor of one type of content and | |||
against another. This impacts users ability to send and receive the | against another. This impacts users' ability to send and receive the | |||
content of their choice. | content of their choice. | |||
As recommended in [RFC8558] protocol designers should avoid the | As recommended in [RFC8558], protocol designers should avoid the | |||
construction of implicit signals of their content. In general, | construction of implicit signals of their content. In general, | |||
protocol designers should avoid adding explicit signals for | protocol designers should avoid adding explicit signals for | |||
intermediaries. In certain cases, it may be necessary to add such | intermediaries. In certain cases, it may be necessary to add such | |||
explicit signals, but designers should only do so when they provide | explicit signals, but designers should only do so when they provide | |||
clear benefit to end users (see [RFC8890] for more on the priority of | clear benefit to end users (see [RFC8890] for more on the priority of | |||
constituencies). In these cases, the implications of those signal | constituencies). In these cases, the implications of those signals | |||
for human rights should be documented. | for human rights should be documented. | |||
Note that many protocols provide signals that are intended for | Note that many protocols provide signals that are intended for | |||
endpoints that can be used as implicit signals by intermediaries for | endpoints that can be used as implicit signals by intermediaries for | |||
traffic discrimination, either based on content (e.g., TCP port | traffic discrimination, based on either the content (e.g., TCP port | |||
numbers) or sender/receiver (IP addresses). Where possible, these | numbers) or the sender/receiver (IP addresses). Where possible, | |||
should be protected from intermediaries by encryption. In many cases | these should be protected from intermediaries by encryption. In many | |||
– e.g., IP address – these signals are difficult to remove, but in | cases (e.g., IP addresses), these signals are difficult to remove; | |||
other cases, such as TLS Application Layer Protocol Negotiation | but in other cases, such as TLS Application Layer Protocol | |||
[RFC7301], there are active efforts to protect this data | Negotiation [RFC7301], there are active efforts to protect this data | |||
[I-D.ietf-tls-esni]. | [TLS-ESNI]. | |||
Impacts: | ||||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to non-discrimination | * Right to non-discrimination | |||
* Right to equal protection | * Right to equal protection | |||
4.5. Internationalization | 4.5. Internationalization | |||
Question(s): Does your protocol or specification define text string | Question(s): Does your protocol or specification define text string | |||
elements, in the payload or headers, that have to be understood or | elements, in the payload or headers, that have to be understood or | |||
entered by humans? Does your specification allow Unicode? If so, do | entered by humans? Does your specification allow Unicode? If so, do | |||
you accept texts in one charset (which must be UTF-8), or several | you accept texts in one charset (which must be UTF-8) or several | |||
(which is dangerous for interoperability)? If character sets or | (which is dangerous for interoperability)? If character sets or | |||
encodings other than UTF-8 are allowed, does your specification | encodings other than UTF-8 are allowed, does your specification | |||
mandate a proper tagging of the charset? Did you have a look at | mandate a proper tagging of the charset? Did you have a look at | |||
[RFC6365]? | [RFC6365]? | |||
Explanation: Internationalization refers to the practice of making | Explanation: Internationalization refers to the practice of making | |||
protocols, standards, and implementations usable in different | protocols, standards, and implementations usable in different | |||
languages and scripts (see Localization). In the IETF, | languages and scripts (see Section 4.6 ("Localization")). In the | |||
internationalization means to add or improve the handling of non- | IETF, internationalization means to add or improve the handling of | |||
ASCII text in a protocol. [RFC6365] A different perspective, more | non-ASCII text in a protocol [RFC6365]. A different perspective, | |||
appropriate to protocols that are designed for global use from the | more appropriate to protocols that are designed for global use from | |||
beginning, is the definition used by the World Wide Web Consortium | the beginning, is the definition used by the World Wide Web | |||
(W3C): | Consortium (W3C) [W3Ci18nDef]: | |||
"Internationalization is the design and development of a | | Internationalization is the design and development of a product, | |||
product, application or document content that enables easy | | application or document content that enables easy localization for | |||
localization for target audiences that vary in culture, region, | | target audiences that vary in culture, region, or language. | |||
or language." {{W3Ci18nDef}} | ||||
Many protocols that handle text only handle one charset (US-ASCII), | Many protocols that handle text only handle one charset (US-ASCII) or | |||
or leave the question of what coded character set and encoding are | leave the question of what coded character set and encoding are used | |||
used up to local guesswork (which leads, of course, to | up to local guesswork (which leads, of course, to interoperability | |||
interoperability problems). If multiple charsets are permitted, they | problems). If multiple charsets are permitted, they must be | |||
must be explicitly identified [RFC2277]. Adding non-ASCII text to a | explicitly identified [RFC2277]. Adding non-ASCII text to a protocol | |||
protocol allows the protocol to handle more scripts, hopefully | allows the protocol to handle more scripts, hopefully representing | |||
representing users across the world. In today’s world, that is | users across the world. In today's world, that is normally best | |||
normally best accomplished by allowing Unicode encoded in UTF-8 only. | accomplished by allowing only Unicode encoded in UTF-8. | |||
In current IETF practice [RFC2277], internationalization is aimed at | In current IETF practice [RFC2277], internationalization is aimed at | |||
user-facing strings, not protocol elements, such as the verbs used by | user-facing strings, not protocol elements, such as the verbs used by | |||
some text-based protocols. (Do note that some strings are both | some text-based protocols. (Do note that some strings are both | |||
content and protocol elements, such as identifiers.) Although this | content and protocol elements, such as identifiers.) Although this | |||
is reasonable practice for non-user visible elements, given the | is reasonable practice for non-user-visible elements, given the | |||
IETF’s mission to make the Internet a global network of networks, | IETF's mission to make the Internet a global network of networks | |||
[RFC3935] developers should provide full and equal support for all | [RFC3935], developers should provide full and equal support for all | |||
scripts and character sets in the user-facing features of protocols | scripts and character sets in the user-facing features of protocols | |||
and for any content they carry. | and for any content they carry. | |||
Example: See localization | Example: See Section 4.6 ("Localization"). | |||
Impacts: | Impacts: | |||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to political participation | * Right to political participation | |||
* Right to participate in cultural life, arts and science | * Right to participate in cultural life, arts, and science | |||
4.6. Localization | 4.6. Localization | |||
Question(s): Does your protocol uphold the standards of | Question(s): Does your protocol uphold the standards of | |||
internationalization? Have you made any concrete steps towards | internationalization? Have you made any concrete steps towards | |||
localizing your protocol for relevant audiences? | localizing your protocol for relevant audiences? | |||
Explanation: Localization refers to the adaptation of a product, | Explanation: "Localization refers to the adaptation of a product, | |||
application or document content to meet the language, cultural and | application or document content to meet the language, cultural and | |||
other requirements of a specific target market (a locale) | other requirements of a specific target market (a 'locale')" | |||
[W3Ci18nDef]. For our purposes, it can be described as the practice | [W3Ci18nDef]. For our purposes, it can be described as the practice | |||
of translating an implementation to make it functional in a specific | of translating an implementation to make it functional in a specific | |||
language or for users in a specific locale (see | language or for users in a specific locale (see Section 4.5 | |||
Internationalization). Internationalization is related to | ("Internationalization")). Internationalization is related to | |||
localization, but they are not the same. Internationalization is a | localization, but they are not the same. Internationalization is a | |||
necessary precondition for localization. | necessary precondition for localization. | |||
Example: The Internet is a global medium, but many of its protocols | Example: The Internet is a global medium, but many of its protocols | |||
and products are developed with a certain audience in mind, that | and products are developed with certain audiences in mind that often | |||
often share particular characteristics like knowing how to read and | share particular characteristics like knowing how to read and write | |||
write in American Standard Code for Information Interchange (ASCII) | in American Standard Code for Information Interchange (ASCII) and | |||
and knowing English. This limits the ability of a large part of the | knowing English. This limits the ability of a large part of the | |||
world’s online population from using the Internet in a way that is | world's online population from using the Internet in a way that is | |||
culturally and linguistically accessible. An example of a standard | culturally and linguistically accessible. An example of a standard | |||
that has taken into account the view that individuals like to have | that has taken into account the view that individuals like to have | |||
access to data in their native language can be found in [RFC5646]. | access to data in their native language can be found in [RFC5646]. | |||
The document describes a way to label information with an identifier | The document describes a way to label information with an identifier | |||
for the language in which it is written. And this allows information | for the language in which it is written. And this allows information | |||
to be presented and accessed in more than one language. | to be presented and accessed in more than one language. | |||
Impacts: | Impacts: | |||
* Right to non-discrimination | * Right to non-discrimination | |||
* Right to participate in cultural life, arts and science | * Right to participate in cultural life, arts, and science | |||
* Right to freedom of expression | * Right to freedom of expression | |||
4.7. Open Standards | 4.7. Open Standards | |||
Question(s): Is your protocol fully documented in a way that it could | Question(s): Is your protocol fully documented in a way that it could | |||
be easily implemented, improved, built upon and/or further developed? | be easily implemented, improved, built upon, and/or further | |||
Do you depend on proprietary code for the implementation, running or | developed? Do you depend on proprietary code for the implementation, | |||
further development of your protocol? Does your protocol favor a | running, or further development of your protocol? Does your protocol | |||
particular proprietary specification over technically-equivalent | favor a particular proprietary specification over technically | |||
competing specification(s), for instance by making any incorporated | equivalent competing specification(s), for instance, by making any | |||
vendor specification “required” or “recommended” [RFC2026]? Do you | incorporated vendor specification "required" or "recommended" | |||
normatively reference another standard that is not available without | [RFC2026]? Do you normatively reference another standard that is not | |||
cost (and could you do without it)? Are you aware of any patents | available without cost (and could you do without it)? Are you aware | |||
that would prevent your standard from being fully implemented | of any patents that would prevent your standard from being fully | |||
[RFC8179] [RFC6701]? | implemented [RFC8179] [RFC6701]? | |||
Explanation: The Internet was able to be developed into the global | Explanation: The Internet was able to be developed into the global | |||
network of networks because of the existence of open, non-proprietary | network of networks because of the existence of open, non-proprietary | |||
standards [Zittrain]. They are crucial for enabling | standards [Zittrain]. They are crucial for enabling | |||
interoperability. Yet, open standards are not explicitly defined | interoperability. Yet, open standards are not explicitly defined | |||
within the IETF. On the subject, [RFC2026] states: “Various national | within the IETF. On the subject, [RFC2026] states: | |||
and international standards bodies, such as ANSI, ISO, IEEE, and ITU- | ||||
T, develop a variety of protocol and service specifications that are | | Various national and international standards bodies, such as ANSI, | |||
similar to Technical Specifications defined at the IETF. National | | ISO, IEEE, and ITU-T, develop a variety of protocol and service | |||
and international groups also publish “implementors’ agreements” that | | specifications that are similar to Technical Specifications | |||
are analogous to Applicability Statements, capturing a body of | | defined here [at the IETF]. National and international groups | |||
implementation-specific detail concerned with the practical | | also publish "implementors' agreements" that are analogous to | |||
application of their standards. All of these are considered to be | | Applicability Statements, capturing a body of implementation- | |||
“open external standards” for the purposes of the Internet Standards | | specific detail concerned with the practical application of their | |||
Process.” Similarly, [RFC3935] does not define open standards but | | standards. All of these are considered to be "open external | |||
does emphasize the importance of an “open process”, i.e., “any | | standards" for the purposes of the Internet Standards Process. | |||
interested person can participate in the work, know what is being | ||||
decided, and make [their] voice heard on the issue.” | Similarly, [RFC3935] does not define open standards but 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) allow users to glean | Open standards (and open source software) allow users to glean | |||
information about how the tools they are using work, including the | information about how the tools they are using work, including the | |||
tools’ security and privacy properties. They additionally allow for | tools' security and privacy properties. They additionally allow for | |||
permissionless innovation, which is important to maintain the freedom | permissionless innovation, which is important to maintain the freedom | |||
and ability to freely create and deploy new protocols on top of the | and ability to freely create and deploy new protocols on top of the | |||
communications constructs that currently exist. It is at the heart | communications constructs that currently exist. It is at the heart | |||
of the Internet as we know it, and to maintain its fundamentally open | of the Internet as we know it, and to maintain its fundamentally open | |||
nature, we need to be mindful of the need for developing open | nature, we need to be mindful of the need for developing open | |||
standards. | standards. | |||
All standards that need to be normatively implemented should be | All standards that need to be normatively implemented should be | |||
freely available and with reasonable protection for patent | freely available and with reasonable protection for patent | |||
infringement claims, so it can also be implemented in open source or | infringement claims so that they can also be implemented in open | |||
free software. Patents have often held back open standardization or | source or free software. Patents have often held back open | |||
been used against those deploying open standards, particularly in the | standardization or been used against those deploying open standards, | |||
domain of cryptography [newegg]. An exemption of this is sometimes | particularly in the domain of cryptography [Newegg]. An exemption of | |||
made when a protocol is standardized that normatively relies on | this is sometimes made when a protocol is standardized that | |||
specifications produced by others standards development organizations | normatively relies on specifications produced by others Standards | |||
(SDOs) that are not freely available. Patents in open standards or | Development Organizations (SDOs) that are not freely available. | |||
in normative references to other standards should have a patent | Patents in open standards or in normative references to other | |||
disclosure [notewell], royalty-free licensing [patentpolicy], or some | standards should have a patent disclosure [Note-well], royalty-free | |||
other form of fair, reasonable and non-discriminatory terms. | licensing [Patent-policy], or some other form of fair, reasonable, | |||
and non-discriminatory terms. | ||||
Example: [RFC6108] describes a system for providing critical end-user | Example: [RFC6108] describes a system for providing critical end-user | |||
notifications to web browsers, which has been deployed by Comcast, an | notifications to web browsers, which has been deployed by Comcast, an | |||
Internet Service Provider (ISP). Such a notification system is being | Internet Service Provider (ISP). Such a notification system is being | |||
used to provide near-immediate notifications to customers, such as to | used to provide near-immediate notifications to customers, such as to | |||
warn them that their traffic exhibits patterns that are indicative of | warn them that their traffic exhibits patterns that are indicative of | |||
malware or virus infection. There are other proprietary systems that | malware or virus infection. There are other proprietary systems that | |||
can perform such notifications, but those systems utilize Deep Packet | can perform such notifications, but those systems utilize Deep Packet | |||
Inspection (DPI) technology. In contrast, that document describes a | Inspection (DPI) technology. In contrast, that document describes a | |||
system that does not rely upon DPI, and is instead based on open IETF | system that does not rely upon DPI and is instead based on open IETF | |||
standards and open source applications. | standards and open source applications. | |||
Impacts: | Impacts: | |||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to participate in cultural life, arts and science | * Right to participate in cultural life, arts, and science | |||
4.8. Heterogeneity Support | 4.8. Heterogeneity Support | |||
Question(s): Does your protocol support heterogeneity by design? | Question(s): Does your protocol support heterogeneity by design? | |||
Does your protocol allow for multiple types of hardware? Does your | Does your protocol allow for multiple types of hardware? Does your | |||
protocol allow for multiple types of application protocols? Is your | protocol allow for multiple types of application protocols? Is your | |||
protocol liberal in what it receives and handles? Will it remain | protocol liberal in what it receives and handles? Will it remain | |||
usable and open if the context changes? | usable and open if the context changes? | |||
Explanation: The Internet is characterized by heterogeneity on many | Explanation: The Internet is characterized by heterogeneity on many | |||
levels: devices and nodes, router scheduling algorithms and queue | levels: devices, nodes, router scheduling algorithms, queue | |||
management mechanisms, routing protocols, levels of multiplexing, | management mechanisms, routing protocols, levels of multiplexing, | |||
protocol versions and implementations, underlying link layers (e.g., | protocol versions and implementations, and underlying link layers | |||
point-to-point, multi-access links, wireless, FDDI, etc.), in the | (e.g., point-to-point, multi-access links, wireless, Fiber | |||
traffic mix and in the levels of congestion at different times and | Distributed Data Interface (FDDI), etc.) in the traffic mix and in | |||
places. Moreover, as the Internet is composed of autonomous | the levels of congestion at different times and places. Moreover, as | |||
organizations and ISPs, each with their own separate policy concerns, | the Internet is composed of autonomous organizations and ISPs, each | |||
there is a large heterogeneity of administrative domains and pricing | with their own separate policy concerns, there is a large | |||
structures. As a result, the heterogeneity principle proposed in | heterogeneity of administrative domains and pricing structures. As a | |||
[RFC1958] needs to be supported by design [FIArch]. | result, the heterogeneity principle proposed in [RFC1958] needs to be | |||
supported by design [FIArch]. | ||||
Heterogeneity support in protocols can thus enable a wide range of | Heterogeneity support in protocols can, thus, enable a wide range of | |||
devices and (by extension) users to participate on the network. | devices and (by extension) users to participate on the network. | |||
Example: Heterogeneity significantly contributed to the success of | Example: Heterogeneity significantly contributed to the success of | |||
the internet architecture [Zittrain]. Niels Bohr famously said: | the Internet architecture [Zittrain]. Niels Bohr famously said: | |||
“Prediction is very difficult, especially if it’s about the future”, | "Prediction is very difficult, especially if it's about the future." | |||
this also holds true for future uses of the internet architecture and | This also holds true for future uses of the Internet architecture and | |||
infrastructure. Therefore, as a rule of thumb it is important to - | infrastructure. Therefore, as a rule of thumb, it is important to -- | |||
as far as possible - design your protocol for different devices and | as far as possible -- design your protocol for different devices and | |||
uses, especially at lower layers of the stack. However, if you | uses, especially at lower layers of the stack. However, if you | |||
choose not to do this, it could be relevant to document the reasoning | choose not to do this, it could be relevant to document the reasoning | |||
for that. | for that. | |||
Impacts: | Impacts: | |||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to political participation | * Right to political participation | |||
4.9. Adaptability | 4.9. Adaptability | |||
Question(s): Question: Is your protocol written in a modular fashion | Question(s): Is your protocol written in a modular fashion, and does | |||
and does it facilitate or hamper extensibility? In this sense, does | it facilitate or hamper extensibility? In this sense, does your | |||
your protocol impact permissionless innovation? (See Open Standards) | protocol impact permissionless innovation? (See Section 4.7 ("Open | |||
Standards").) | ||||
Explanation: Adaptability is closely interrelated with permissionless | Explanation: Adaptability is closely interrelated with permissionless | |||
innovation: both maintain the freedom and ability to freely create | innovation: both maintain the freedom and ability to create and | |||
and deploy new protocols on top of the communications constructs that | deploy new protocols on top of the communications constructs that | |||
currently exist. It is at the heart of the Internet as we know it, | currently exist. It is at the heart of the Internet as we know it, | |||
and to maintain its fundamentally open nature, we need to be mindful | and to maintain its fundamentally open nature, we need to be mindful | |||
of the impact of protocols on maintaining or reducing permissionless | of the impact of protocols on maintaining or reducing permissionless | |||
innovation to ensure the Internet can continue to develop. | innovation to ensure that the Internet can continue to develop. | |||
Adaptability and permissionless innovation can be used to shape | Adaptability and permissionless innovation can be used to shape | |||
information networks as preferenced by groups of users. Furthermore, | information networks as groups of users prefer. Furthermore, a | |||
a precondition of adaptability is the ability of the people who can | precondition of adaptability is the ability of the people who can | |||
adapt the network to be able to know and understand the network. | adapt the network to be able to know and understand the network. | |||
This is why adaptability and permissionless innovation are inherently | This is why adaptability and permissionless innovation are inherently | |||
connected to the right to education and the right to science as well | connected to the right to education and the right to science as well | |||
as the right to freedom of assembly and association as well as the | as the right to freedom of assembly and association and the right to | |||
right to freedom of expression. Since it allows the users of the | freedom of expression, since it allows the users of the network to | |||
network to determine how to assemble, collaborate, and express | determine how to assemble, collaborate, and express themselves. | |||
themselves. | ||||
Example: WebRTC generates audio and/or video data. WebRTC can be | Example: WebRTC generates audio and/or video data. WebRTC can be | |||
used in different locations by different parties; WebRTC’s standard | used in different locations by different parties; WebRTC's standard | |||
application programming interfaces (APIs) are developed to support | Application Programming Interfaces (APIs) are developed to support | |||
applications from different voice service providers. Multiple | applications from different voice service providers. Multiple | |||
parties will have similar capabilities, in order to ensure that all | parties will have similar capabilities. In order to ensure that all | |||
parties can build upon existing standards these need to be adaptable, | parties can build upon existing standards, these need to be adaptable | |||
and allow for permissionless innovation. | and allow for permissionless innovation. | |||
Impacts: | Impacts: | |||
* Right to education | * Right to education | |||
* Right to science | * Right to science | |||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to freedom of assembly and association | * Right to freedom of assembly and association | |||
4.10. Integrity | 4.10. Integrity | |||
Question(s): Does your protocol maintain, assure and/or verify the | Question(s): Does your protocol maintain, assure, and/or verify the | |||
accuracy of payload data? Does your protocol maintain and assure the | accuracy of payload data? Does your protocol maintain and assure the | |||
consistency of data? Does your protocol in any way allow for the | consistency of data? Does your protocol in any way allow for the | |||
data to be (intentionally or unintentionally) altered? | data to be (intentionally or unintentionally) altered? | |||
Explanation: Integrity refers to the maintenance and assurance of the | Explanation: Integrity refers to the maintenance and assurance of the | |||
accuracy and consistency of data to ensure it has not been | accuracy and consistency of data to ensure it has not been | |||
(intentionally or unintentionally) altered. | (intentionally or unintentionally) altered. | |||
Example: Integrity verification of data is important to prevent | Example: Integrity verification of data is important to prevent | |||
vulnerabilities and attacks from on-path attackers. These attacks | vulnerabilities and attacks from on-path attackers. These attacks | |||
happen when a third party (often for malicious reasons) intercepts a | happen when a third party (often for malicious reasons) intercepts a | |||
communication between two parties, inserting themselves in the middle | communication between two parties, inserting themselves in the middle | |||
changing the content of the data. In practice this looks as follows: | and changing the content of the data. In practice, this looks as | |||
follows: | ||||
Alice wants to communicate with Bob. Alice sends a message to Bob, | Alice wants to communicate with Bob. Alice sends a message to Bob, | |||
which Corinne intercepts and modifies. Bob cannot see that the data | which Corinne intercepts and modifies. Bob cannot see that the data | |||
from Alice was altered by Corinne. Corinne intercepts and alters the | from Alice was altered by Corinne. Corinne intercepts and alters the | |||
communication as it is sent between Alice and Bob. Corinne is able | communication as it is sent between Alice and Bob. Corinne is able | |||
to control the communication content. | to control the communication content. | |||
Impacts: | Impacts: | |||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to security | * Right to security | |||
4.11. Authenticity | 4.11. Authenticity | |||
Question(s): Do you have sufficient measures to confirm the truth of | 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 | an attribute of a single piece of data or entity? Can the attributes | |||
get garbled along the way (see security)? If relevant, have you | get garbled along the way (see Section 4.13 ("Security"))? If | |||
implemented IPsec, DNS Security (DNSSEC), HTTPS and other Standard | relevant, have you implemented IPsec, DNS Security (DNSSEC), HTTPS, | |||
Security Best Practices? | and other standard security best practices? | |||
Explanation: Authenticity ensures that data does indeed come from the | Explanation: Authenticity ensures that data does indeed come from the | |||
source it claims to come from. This is important to prevent certain | source it claims to come from. This is important to prevent certain | |||
attacks or unauthorized access and use of data. | attacks or unauthorized access and use of data. | |||
At the same time, authentication should not be used as a way to | At the same time, authentication should not be used as a way to | |||
prevent heterogeneity support, as is often done for vendor lock-in or | prevent heterogeneity support, as is often done for vendor lock-in or | |||
digital rights management. | digital rights management. | |||
Example: Authentication of data is important to prevent | Example: Authentication of data is important to prevent | |||
vulnerabilities, and attacks from on-path attackers. These attacks | vulnerabilities and attacks from on-path attackers. These attacks | |||
happen when a third party (often for malicious reasons) intercepts a | happen when a third party (often for malicious reasons) intercepts a | |||
communication between two parties, inserting themselves in the middle | communication between two parties, inserting themselves in the middle | |||
and posing as both parties. In practice this looks as follows: | and posing as both parties. In practice, this looks as follows: | |||
Alice wants to communicate with Bob. Alice sends data to Bob. | Alice wants to communicate with Bob. Alice sends data to Bob. | |||
Corinne intercepts the data sent to Bob. Corinne reads (and | Corinne intercepts the data sent to Bob. Corinne reads (and | |||
potentially alters) the message to Bob. Bob cannot see that the data | potentially alters) the message to Bob. Bob cannot see that the data | |||
did not come from Alice but from Corinne. | did not come from Alice but from Corinne. | |||
With proper authentication, the scenario would be as follows: | With proper authentication, the scenario would be as follows: | |||
Alice wants to communicate with Bob. Alice sends data to Bob. | Alice wants to communicate with Bob. Alice sends data to Bob. | |||
Corinne intercepts the data sent to Bob. Corinne reads and alters | Corinne intercepts the data sent to Bob. Corinne reads and alters | |||
skipping to change at page 19, line 4 ¶ | skipping to change at line 832 ¶ | |||
What controls or consent mechanisms does the protocol define or | What controls or consent mechanisms does the protocol define or | |||
require before personal data or identifiers are shared or exposed via | require before personal data or identifiers are shared or exposed via | |||
the protocol? If no such mechanisms or controls are specified, is it | the protocol? If no such mechanisms or controls are specified, is it | |||
expected that control and consent will be handled outside of the | expected that control and consent will be handled outside of the | |||
protocol? | protocol? | |||
Does the protocol provide ways for initiators to share different | Does the protocol provide ways for initiators to share different | |||
pieces of information with different recipients? If not, are there | pieces of information with different recipients? If not, are there | |||
mechanisms that exist outside of the protocol to provide initiators | mechanisms that exist outside of the protocol to provide initiators | |||
with such control? | with such control? | |||
Does the protocol provide ways for initiators to limit the sharing or | Does the protocol provide ways for initiators to limit the sharing or | |||
express individuals’ preferences to recipients or intermediaries with | expressing of individuals' preferences to recipients or | |||
regard to the collection, use, or disclosure of their personal data? | intermediaries with regard to the collection, use, or disclosure of | |||
If not, are there mechanisms that exist outside of the protocol to | their personal data? If not, are there mechanisms that exist outside | |||
provide users with such control? Is it expected that users will have | of the protocol to provide users with such control? Is it expected | |||
relationships that govern the use of the information (contractual or | that users will have relationships that govern the use of the | |||
otherwise) with those who operate these intermediaries? Does the | information (contractual or otherwise) with those who operate these | |||
protocol prefer encryption over clear text operation? | intermediaries? Does the protocol prefer encryption over cleartext | |||
operation? | ||||
Explanation: Confidentiality refers to keeping your data secret from | Explanation: Confidentiality refers to keeping your data secret from | |||
unintended listeners [BCP72]. The growth of the Internet depends on | unintended listeners [BCP72]. The growth of the Internet depends on | |||
users having confidence that the network protects their personal data | users having confidence that the network protects their personal data | |||
[RFC1984]. The possibility of pervasive monitoring and surveillance | [RFC1984]. The possibility of pervasive monitoring and surveillance | |||
undermines users’ trust, and can be mitigated by ensuring | undermines users' trust and can be mitigated by ensuring | |||
confidentiality, i.e., passive attackers should gain little or no | confidentiality, i.e., passive attackers should gain little or no | |||
information from observation or inference of protocol activity. | information from observation or inference of protocol activity | |||
[RFC7258][RFC7624]. | [RFC7258] [RFC7624]. | |||
Example: Protocols that do not encrypt their payload make the entire | Example: Protocols that do not encrypt their payload make the entire | |||
content of the communication available to the idealized attacker | content of the communication available to the idealized attacker | |||
along their path. Following the advice in [RFC3365], most such | along their path. Following the advice in [RFC3365], most such | |||
protocols have a secure variant that encrypts the payload for | protocols have a secure variant that encrypts the payload for | |||
confidentiality, and these secure variants are seeing ever-wider | confidentiality, and these secure variants are seeing ever-wider | |||
deployment. A noteworthy exception is DNS [RFC1035], as DNSSEC | deployment. A noteworthy exception is DNS [RFC1035], as DNSSEC | |||
[RFC4033] does not have confidentiality as a requirement. This | [RFC4033] does not have confidentiality as a requirement. This | |||
implies that, in the absence of the use of more recent standards like | implies that, in the absence of the use of more recent standards like | |||
DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484], all DNS queries | DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484], all DNS queries | |||
skipping to change at page 20, line 7 ¶ | skipping to change at line 877 ¶ | |||
[RFC7624]. | [RFC7624]. | |||
Impacts: | Impacts: | |||
* Right to privacy | * Right to privacy | |||
* Right to security | * Right to security | |||
4.13. Security | 4.13. Security | |||
Question(s): Did you have a look at Guidelines for Writing RFC Text | Question(s): Did you have a look at "Guidelines for Writing RFC Text | |||
on Security Considerations [BCP72]? Have you found any attacks that | on Security Considerations" [BCP72]? Have you found any attacks that | |||
are somewhat related to your protocol/specification, yet considered | are somewhat related to your protocol/specification yet considered | |||
out of scope of your document? Would these attacks be pertinent to | out of scope of your document? Would these attacks be pertinent to | |||
the human rights enabling features of the Internet (as described | the human-rights-enabling features of the Internet (as described | |||
throughout this document)? | throughout this document)? | |||
Explanation: Security is not a single monolithic property of a | Explanation: Security is not a single monolithic property of a | |||
protocol or system, but rather a series of related but somewhat | protocol or system but rather a series of related yet somewhat | |||
independent properties. Not all of these properties are required for | independent properties. Not all of these properties are required for | |||
every application. Since communications are carried out by systems | every application. Since communications are carried out by systems | |||
and access to systems is through communications channels, security | and access to systems is through communications channels, security | |||
goals obviously interlock, but they can also be independently | goals obviously interlock, but they can also be independently | |||
provided. [BCP72]. | provided [BCP72]. | |||
Typically, any protocol operating on the Internet can be the target | Typically, any protocol operating on the Internet can be the target | |||
of passive attacks (when the attacker can access and read packets on | of passive attacks (when the attacker can access and read packets on | |||
the network); active attacks (when an attacker is capable of writing | the network) and active attacks (when an attacker is capable of | |||
information to the network packets). [BCP72] | writing information to the network packets) [BCP72]. | |||
Example: See [BCP72]. | Example: See [BCP72]. | |||
Impacts: | Impacts: | |||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to freedom of assembly and association | * Right to freedom of assembly and association | |||
* Right to non-discrimination | * Right to non-discrimination | |||
* Right to security | * Right to security | |||
4.14. Privacy | 4.14. Privacy | |||
Question(s): Did you have a look at the Guidelines in the Privacy | Question(s): Did you have a look at the guidelines described in | |||
Considerations for Internet Protocols [RFC6973] section 7? Does your | Section 7 of "Privacy Considerations for Internet Protocols" | |||
protocol maintain the confidentiality of metadata? Could your | [RFC6973]? Does your protocol maintain the confidentiality of | |||
protocol counter traffic analysis? Does your protocol adhere to data | metadata? Could your protocol counter traffic analysis? Does your | |||
minimization principles? Does your document identify potentially | protocol adhere to data minimization principles? Does your document | |||
sensitive data logged by your protocol and/or for how long that needs | identify potentially sensitive data logged by your protocol and/or | |||
to be retained for technical reasons? | for how long that needs to be retained for technical reasons? | |||
Explanation: Privacy refers to the right of an entity (normally a | Explanation: Privacy refers to the right of an entity (normally a | |||
person), acting on its own behalf, to determine the degree to which | person), acting on its own behalf, to determine the degree to which | |||
it will interact with its environment, including the degree to which | it will interact with its environment, including the degree to which | |||
the entity is willing to share its personal information with others. | the entity is willing to share its personal information with others | |||
[RFC4949]. If a protocol provides insufficient privacy protection, | ||||
[RFC4949]. If a protocol provides insufficient privacy protection it | it may have a negative impact on freedom of expression as users self- | |||
may have a negative impact on freedom of expression as users self- | censor for fear of surveillance or find themselves unable to express | |||
censor for fear of surveillance, or find themselves unable to express | ||||
themselves freely. | themselves freely. | |||
Example: See [RFC6973] | Example: See [RFC6973]. | |||
Impacts: | Impacts: | |||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to privacy | * Right to privacy | |||
* Right to non-discrimination | * Right to non-discrimination | |||
4.15. Anonymity and Pseudonymity | 4.15. Anonymity and Pseudonymity | |||
Question(s): Does your protocol make use of identifiers? Are these | Question(s): Does your protocol make use of identifiers? Are these | |||
identifiers persistent? Are they used across multiple contexts? Is | identifiers persistent? Are they used across multiple contexts? Is | |||
it possible for the user to reset or rotate them without negatively | it possible for the user to reset or rotate them without negatively | |||
impacting the operation fo the protocol? Are they visible to others | impacting the operation of the protocol? Are they visible to others | |||
besides the protocol endpoints? Are they tied to real-world | besides the protocol endpoints? Are they tied to real-world | |||
identities? Have you considered the Privacy Considerations for | identities? Have you considered "Privacy Considerations for Internet | |||
Internet Protocols [RFC6973], especially section 6.1.2? | Protocols" [RFC6973], especially Section 6.1.2? | |||
Explanation: Most protocols depend on the use of some kind of | Explanation: Most protocols depend on the use of some kind of | |||
identifier in order to correlate activity over time and space. For | identifier in order to correlate activity over time and space. For | |||
instance: | instance: | |||
* IP addresses are used as an identity for the source and | * IP addresses are used as an identity for the source and | |||
destination for IP datagrams. | destination for IP datagrams. | |||
* QUIC connection identifiers are used to correlate packets | * QUIC connection identifiers are used to correlate packets | |||
belonging to the same connection. | belonging to the same connection. | |||
* HTTP uses cookies to correlate multiple HTTP requests from the | * HTTP uses cookies to correlate multiple HTTP requests from the | |||
same client. | same client. | |||
* Email uses email addresses of the form example@example.com | * Email uses email addresses of the form example@example.com to | |||
(mailto:example@example.com) to identify senders and receivers. | identify senders and receivers. | |||
In general, these identifiers serve a necessary function for protocol | In general, these identifiers serve a necessary function for protocol | |||
operations, by allowing them to maintain continuity. However, they | operations by allowing them to maintain continuity. However, they | |||
can also create privacy risks. There are two major ways in which | can also create privacy risks. There are two major ways in which | |||
those risks manifest: | those risks manifest: | |||
* The identifier may itself reveal the user’s identity in some way | * The identifier may itself reveal the user's identity in some way | |||
or be tied to an identifier which does, as is the case when E.164 | or be tied to an identifier that does, as is the case when E.164 | |||
(telephone) numbers are used as identifiers for instant messaging | (telephone) numbers are used as identifiers for instant messaging | |||
systems. | systems. | |||
* While the identifier may not reveal the user’s identity, it may | * While the identifier may not reveal the user's identity, it may | |||
make it possible to link enough of a user’s behavior to threaten | make it possible to link enough of a user's behavior to threaten | |||
their privacy, as is the case with HTTP cookies. | their privacy, as is the case with HTTP cookies. | |||
Because identifiers are necessary for protocol operation, true | Because identifiers are necessary for protocol operation, true | |||
anonymity is very difficult to achieve, but there are practices which | anonymity is very difficult to achieve, but there are practices that | |||
promote user privacy even when identifiers are used. | promote user privacy even when identifiers are used. | |||
Impacts: | Impacts: | |||
* Right to non-discrimination | * Right to non-discrimination | |||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to political participation | * Right to political participation | |||
* Right to freedom of assembly and association | * Right to freedom of assembly and association | |||
4.15.1. Pseudonymity | 4.15.1. Pseudonymity | |||
In general, user privacy is better preserved when identifiers are | In general, user privacy is better preserved when identifiers are | |||
pseudonymous (not tied to a user’s real-world identity). | pseudonymous (not tied to a user's real-world identity). | |||
Example: In the development of the IPv6 protocol, it was discussed to | Example: In the development of the IPv6 protocol, it was discussed to | |||
embed a Media Access Control (MAC) address into unique IP addresses. | embed a Media Access Control (MAC) address into unique IP addresses. | |||
This would make it possible for eavesdroppers and other information | This would make it possible for eavesdroppers and other information | |||
collectors to identify when different addresses used in different | collectors to identify when different addresses used in different | |||
transactions actually correspond to the same node. This is why | transactions actually correspond to the same node. This is why | |||
standardization efforts like Privacy Extensions for Stateless Address | standardization efforts like "Temporary Address Extensions for | |||
Autoconfiguration in IPv6 [RFC4941] and MAC address randomization | Stateless Address Autoconfiguration in IPv6" [RFC8981] and MAC | |||
[draft-zuniga-mac-address-randomization] have been pursued. | address randomization [MAC-ADDRESS-RANDOMIZATION] have been pursued. | |||
Note that it is often attractive to try to create a pseudonym from a | Note that it is often attractive to try to create a pseudonym from a | |||
persistent identifier. This can be very difficult to do correctly in | persistent identifier. This can be very difficult to do correctly in | |||
a way that does not allow for recovering the persistent identifiers. | a way that does not allow for recovering the persistent identifiers. | |||
Example: A common practice in Web tracking is to “encrypt” email | Example: A common practice in web tracking is to "encrypt" email | |||
addresses by hashing them, thus allegedly making them “non-personally | addresses by hashing them, thus allegedly making them "non-personally | |||
identifying”. However, because hash functions are public operations, | identifying". However, because hash functions are public operations, | |||
it is possible to dictionary search candidate email addresses and | it is possible to do a dictionary search for candidate email | |||
recover the original address [email-hashing]. | addresses and recover the original address [Email-hashing]. | |||
4.15.2. Unlinkability | 4.15.2. Unlinkability | |||
Even true pseudonymous identifiers can present a privacy risk if they | Even true pseudonymous identifiers can present a privacy risk if they | |||
are used across a wide enough scope. User privacy is better | are used across a wide enough scope. User privacy is better | |||
preserved if identifiers have limited scope both in time and space. | preserved if identifiers have limited scope both in time and space. | |||
Example: An example is Dynamic Host Configuration Protocol (DHCP) | Example: An example is the Dynamic Host Configuration Protocol (DHCP) | |||
where sending a persistent identifier as the client name was not | where sending a persistent identifier as the client name was not | |||
mandatory but, in practice, done by many implementations, before | mandatory but, in practice, done by many implementations, before | |||
[RFC7844]. | [RFC7844]. | |||
Example: Third party cookies in HTTP allow trackers to correlate HTTP | Example: Third-party cookies in HTTP allow trackers to correlate HTTP | |||
traffic across sites. This is the foundation of a whole ecosystem of | traffic across sites. This is the foundation of a whole ecosystem of | |||
Web tracking. Increasingly, Web browsers are restricting the use of | web tracking. Increasingly, web browsers are restricting the use of | |||
third party cookies in order to protect user privacy. | third-party cookies in order to protect user privacy. | |||
4.16. Censorship resistance | 4.16. Censorship Resistance | |||
Question(s): Does your protocol architecture facilitate censorship? | Question(s): Does your protocol architecture facilitate censorship? | |||
Does it include “choke points” which are easy to use for censorship? | Does it include "choke points" that are easy to use for censorship? | |||
Does it expose identifiers which can be used to selectively block | Does it expose identifiers that can be used to selectively block | |||
certain kinds of trafic? Could it be designed to be more censorship | certain kinds of traffic? Could it be designed to be more censorship | |||
resistant? Does your protocol make it apparent or transparent when | resistant? Does your protocol make it apparent or transparent when | |||
access to a resource is restricted and the reasons why it is | access to a resource is restricted and why it is restricted? | |||
restricted? | ||||
Explanation: Governments and service providers block or filter | Explanation: Governments and service providers block or filter | |||
content or traffic, often without the knowledge of end-users. | content or traffic, often without the knowledge of end users | |||
[RFC7754] See [draft-irtf-pearg-censorship] for a survey of | [RFC7754]. For a survey of censorship techniques employed across the | |||
censorship techniques employed across the world, which lays out | world, see [RFC9505], which lays out protocol properties that have | |||
protocol properties that have been exploited to censor access to | been exploited to censor access to information. Censorship | |||
information. Censorship resistance refers to the methods and | resistance refers to the methods and measures to prevent Internet | |||
measures to prevent Internet censorship. | censorship. | |||
Example: The current design of the Web has a number of architectural | Example: The current design of the Web has a number of architectural | |||
choke points where it is possible for censors to intervene. These | choke points where it is possible for censors to intervene. These | |||
include obtaining the control of the domain name itself, DNS blocking | include obtaining the control of the domain name itself, DNS blocking | |||
at either the protocol layer or at the resolver, IP address 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 | and blocking at the web server. There has been extensive work on | |||
content distribution systems which are intended to be more censorship | content distribution systems, which are intended to be more | |||
resistant, and some, such as BitTorrent, are in wide use, but these | censorship resistant; and some, such as BitTorrent, are in wide use. | |||
systems may have inferior reliability and performance compared to the | However, these systems may have inferior reliability and performance | |||
Web (e.g., they do not support active content on the server). | compared to the Web (e.g., they do not support active content on the | |||
server). | ||||
Example: Identifiers of content exposed within a protocol might be | Example: Identifiers of content exposed within a protocol might be | |||
used to facilitate censorship by allowing the censor to determine | used to facilitate censorship by allowing the censor to determine | |||
which traffic to block. DNS queries, the “host” request header in an | which traffic to block. DNS queries, the "host" request header in an | |||
HTTP request, the Server Name Indication (SNI) in a Transport Layer | HTTP request, and the Server Name Indication (SNI) in a Transport | |||
Security (TLS) ClientHello are all examples of protocol elements that | Layer Security (TLS) ClientHello are all examples of protocol | |||
can travel in plaintext and be used by censors to identify what | elements that can travel in plaintext and be used by censors to | |||
content a user is trying to access. [draft-irtf-pearg-censorship]. | identify what content a user is trying to access [RFC9505]. Protocol | |||
Protocol mechanisms such as Encrypted Client Hello | mechanisms such as Encrypted ClientHello [TLS-ESNI] or DNS over HTTPS | |||
[I-D.ietf-tls-esni] or DNS over HTTPS [RFC8484] that encrypt metadata | [RFC8484] that encrypt metadata provide some level of resistance to | |||
provide some level of resistance to this type of protocol inspection. | this type of protocol inspection. Full traffic encryption systems, | |||
Full traffic encryption systems such as Tor [https://torproject.org] | such as Tor <https://torproject.org>, can also be used by people to | |||
can also be used by people access otherwise censored resources. | access otherwise censored resources. | |||
Example: As noted above, one way to censor Web traffic is to require | Example: As noted above, one way to censor web traffic is to require | |||
the server to block it or require internet service providers to block | the server to block it or require ISPs to block requests to the | |||
requests to the server. In HTTP, denial or restriction of access can | server. In HTTP, denial or restriction of access can be made | |||
be made apparent by the use of status code 451, which allows server | apparent by the use of status code 451, which allows server operators | |||
operators and intermediaries to operate with greater transparency in | and intermediaries to operate with greater transparency in | |||
circumstances where issues of law or public policy affect their | circumstances where issues of law or public policy affect their | |||
operation [RFC7725]. If a protocol potentially enables censorship, | operation [RFC7725]. If a protocol potentially enables censorship, | |||
protocol designers should strive towards creating error codes that | protocol designers should strive towards creating error codes that | |||
capture different scenarios (blocked due to administrative policy, | capture different scenarios (e.g., blocked due to administrative | |||
unavailable because of legal requirements, etc.) to minimize | policy, unavailable because of legal requirements, etc.) to minimize | |||
ambiguity for end-users. | ambiguity for end users. | |||
Impacts: | Impacts: | |||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to political participation | * Right to political participation | |||
* Right to participate in cultural life, arts, and science | * Right to participate in cultural life, arts, and science | |||
* Right to freedom of assembly and association | * Right to freedom of assembly and association | |||
4.17. Outcome Transparency | 4.17. Outcome Transparency | |||
Question(s): Are the intended and forseen effects of your protocol | Question(s): Are the intended and foreseen effects of your protocol | |||
documented and easily comprehensible? | documented and easily comprehensible? | |||
Explanation: Certain technical choices may have unintended | Explanation: Certain technical choices may have unintended | |||
consequences. Have you described the central use case(s) for your | consequences. Have you described the central use case(s) for your | |||
protocol with a clear description of expected behavior and how it | protocol with a clear description of expected behavior and how it | |||
may, or may not, impact other protocols, implementations, user | may, or may not, impact other protocols, implementations, user | |||
expectations, or behavior? Have you reviewed other protocols that | expectations, or behavior? Have you reviewed other protocols that | |||
solve similar problems, or make use of similar mechanisms, to see if | solve similar problems, or make use of similar mechanisms, to see if | |||
there are lessons that can be learnt from their use and misuse? | there are lessons that can be learned from their use and misuse? | |||
Example: Lack of authenticity may lead to lack of integrity and | Example: Lack of authenticity may lead to lack of integrity and | |||
negative externalities, of which spam is an example. Lack of data | negative externalities; of which, spam is an example. Lack of data | |||
that could be used for billing and accounting can lead to so-called | that could be used for billing and accounting can lead to so-called | |||
“free” arrangements which obscure the actual costs and distribution | "free" arrangements that obscure the actual costs and distribution of | |||
of the costs, for example the barter arrangements that are commonly | the costs, for example, the barter arrangements that are commonly | |||
used for Internet interconnection; and the commercial exploitation of | used for Internet interconnection, and the commercial exploitation of | |||
personal data for targeted advertising which is the most common | personal data for targeted advertising, which is the most common | |||
funding model for the so-called “free” services such as search | funding model for the so-called "free" services such as search | |||
engines and social networks. Unexpected outcomes might not be | engines and social networks. Unexpected outcomes might not be | |||
technical, but rather architectural, social or economic. Therefore | technical but rather architectural, social, or economic. Therefore, | |||
it is of importance to document the intended outcomes and other | it is of importance to document the intended outcomes and other | |||
possible outcomes that have been considered. | possible outcomes that have been considered. | |||
Impacts: | Impacts: | |||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to privacy | * Right to privacy | |||
* Right to freedom of assembly and association | * Right to freedom of assembly and association | |||
skipping to change at page 25, line 35 ¶ | skipping to change at line 1143 ¶ | |||
Question(s): Is your protocol designed to provide an enabling | Question(s): Is your protocol designed to provide an enabling | |||
environment for all? Have you looked at the W3C Web Accessibility | environment for all? Have you looked at the W3C Web Accessibility | |||
Initiative for examples and guidance? | Initiative for examples and guidance? | |||
Explanation: Sometimes in the design of protocols, websites, web | Explanation: Sometimes in the design of protocols, websites, web | |||
technologies, or web tools, barriers are created that exclude people | technologies, or web tools, barriers are created that exclude people | |||
from using the Web. The Internet should be designed to work for all | from using the Web. The Internet should be designed to work for all | |||
people, whatever their hardware, software, language, culture, | people, whatever their hardware, software, language, culture, | |||
location, or physical or mental ability. When the Internet | location, or physical or mental ability. When the Internet | |||
technologies meet this goal, it will be accessible to people with a | technologies meet this goal, it will be accessible to people with a | |||
diverse range of hearing, movement, sight, and cognitive ability. | diverse range of hearing, movement, sight, and cognitive ability | |||
[W3CAccessibility] | [W3CAccessibility]. | |||
Example: The HTML protocol as defined in [HTML5] specifically | Example: The HTML protocol as defined in [HTML] specifically requires | |||
requires that every image must have an alt attribute (with a few | that every image must have an alt attribute (with a few exceptions) | |||
exceptions) to ensure images are accessible for people that cannot | to ensure images are accessible for people who cannot themselves | |||
themselves decipher non-text content in web pages. | decipher non-text content in web pages. | |||
Another example is the work done in the AVT and AVTCORE working | Another example is the work done in the AVT and AVTCORE Working | |||
groups in the IETF that enables text conversation in multimedia, text | Groups in the IETF that enables text conversation in multimedia, text | |||
telephony, wireless multimedia and video communications for sign | telephony, wireless multimedia, and video communications for sign | |||
language and lip-reading (i.e., [RFC9071]). | language and lipreading (i.e., [RFC9071]). | |||
Impacts: | Impacts: | |||
* Right to non-discrimination | * Right to non-discrimination | |||
* Right to freedom of assembly and association | * Right to freedom of assembly and association | |||
* Right to education | * Right to education | |||
* Right to political participation | * Right to political participation | |||
4.19. Decentralization | 4.19. Decentralization | |||
Question(s): Can your protocol be implemented without a single point | Question(s): Can your protocol be implemented without a single point | |||
of control? If applicable, can your protocol be deployed in a | of control? If applicable, can your protocol be deployed in a | |||
federated manner? Does your protocol create additional centralized | federated manner? Does your protocol create additional centralized | |||
points of control? | points of control? | |||
Explanation: Decentralization is one of the central technical | Explanation: Decentralization is one of the central technical | |||
concepts of the architecture of the Internet, and is embraced as such | concepts of the architecture of the Internet and is embraced as such | |||
by the IETF [RFC3935]. It refers to the absence or minimization of | by the IETF [RFC3935]. It refers to the absence or minimization of | |||
centralized points of control, a feature that is assumed to make it | centralized points of control, a feature that is assumed to make it | |||
easy for new users to join and new uses to unfold [Brown]. It also | easy for new users to join and new uses to unfold [Ziewitz]. It also | |||
reduces issues surrounding single points of failure, and distributes | reduces issues surrounding single points of failure and distributes | |||
the network such that it continues to function even if one or several | the network such that it continues to function even if one or several | |||
nodes are disabled. With the commercialization of the Internet in | nodes are disabled. With the commercialization of the Internet in | |||
the early 1990s, there has been a slow move away from | the early 1990s, there has been a slow move away from | |||
decentralization, to the detriment of the technical benefits of | decentralization, to the detriment of the technical benefits of | |||
having a decentralized Internet. For a more detailed discussion of | having a decentralized Internet. For a more detailed discussion of | |||
this topic, please see [arkkoetal]. | this topic, please see [Arkko]. | |||
Example: The bits traveling the Internet are increasingly susceptible | Example: The bits traveling the Internet are increasingly susceptible | |||
to monitoring and censorship, from both governments and ISPs, as well | to monitoring and censorship from both governments and ISPs as well | |||
as third (malicious) parties. The ability to monitor and censor is | as third (malicious) parties. The ability to monitor and censor is | |||
further enabled by the increased centralization of the network that | further enabled by the increased centralization of the network that | |||
creates central infrastructure points that can be tapped into. The | creates central infrastructure points that can be tapped into. The | |||
creation of peer-to-peer networks and the development of voice-over- | creation of peer-to-peer networks and the development of voice-over- | |||
IP protocols using peer-to-peer technology in combination with | IP protocols using peer-to-peer technology in combination with | |||
distributed hash table (DHT) for scalability are examples of how | Distributed Hash Table (DHT) for scalability are examples of how | |||
protocols can preserve decentralization [Pouwelse]. | protocols can preserve decentralization [Pouwelse]. | |||
Impacts: | Impacts: | |||
* Right to freedom of expression | * Right to freedom of expression | |||
* Right to freedom of assembly and association | * Right to freedom of assembly and association | |||
4.20. Remedy | 4.20. Remedy | |||
Question(s): Can your protocol facilitate a negatively impacted | Question(s): Can your protocol facilitate a negatively impacted | |||
party’s right to remedy without disproportionately impacting other | party's right to remedy without disproportionately impacting other | |||
parties’ human rights, especially their right to privacy? | parties' human rights, especially their right to privacy? | |||
Explanation: Providing access to remedy by states and corporations is | Explanation: Providing access to remedy by states and corporations is | |||
a part of the UN Guiding Principles on Business and Human Rights | a part of the UN Guiding Principles on Business and Human Rights | |||
[UNGP]. Access to remedy may help victims of human rights violations | [UNGP]. Access to remedy may help victims of human rights violations | |||
in seeking justice, or allow law enforcement agencies to identify a | in seeking justice or allow law enforcement agencies to identify a | |||
possible violator. However, current mechanisms in protocols that try | possible violator. However, current mechanisms in protocols that try | |||
to enable ‘attribution’ to individuals impede the exercise of the | to enable "attribution" to individuals impede the exercise of the | |||
right to privacy. The former UN Special Rapporteur for Freedom of | right to privacy. The former UN Special Rapporteur for Freedom of | |||
Expression has also argued that anonymity is an inherent part of | Expression has also argued that anonymity is an inherent part of | |||
freedom of expression [Kaye]. Considering the potential adverse | freedom of expression [Kaye]. Considering the potential adverse | |||
impact of attribution on the right to privacy and freedom of | impact of attribution on the right to privacy and freedom of | |||
expression, enabling attribution on an individual level is most | expression, enabling attribution on an individual level is most | |||
likely not consistent with human rights. | likely not consistent with human rights. | |||
Example: Adding personally identifiable information to data streams | Example: Adding personally identifiable information to data streams | |||
as a means to enable the human right to remedy might help in | as a means to enable the human right to remedy might help in | |||
identifying a violator of human rights and provide access to remedy, | identifying a violator of human rights and provide access to remedy, | |||
but this would disproportionally affect all users right to privacy, | but this would disproportionately affect all users right to privacy, | |||
anonymous expression, and association. Furthermore, there are some | anonymous expression, and association. Furthermore, there are some | |||
recent advances in enabling abuse detection in end-to-end encrypted | recent advances in enabling abuse detection in end-to-end encrypted | |||
messaging systems, which also carry some risk to users’ privacy | messaging systems, which also carry some risk to users' privacy | |||
[messenger-franking][hecate]. | [Messenger-franking] [Hecate]. | |||
Impacts: | Impacts: | |||
* Right to remedy | * Right to remedy | |||
* Right to security | * Right to security | |||
* Right to privacy | * Right to privacy | |||
4.21. Misc. considerations | 4.21. Miscellaneous Considerations | |||
Question(s): Have you considered potential negative consequences | Question(s): Have you considered potential negative consequences | |||
(individual or societal) that your protocol or document might have? | (individual or societal) that your protocol or document might have? | |||
Explanation: Publication of a particular RFC under a certain status | Explanation: Publication of a particular RFC under a certain status | |||
has consequences. Publication as an Internet Standard as part of the | has consequences. Publication as an Internet Standard as part of the | |||
Standards Track may signal to implementers that the specification has | Standards Track may signal to implementers that the specification has | |||
a certain level of maturity, operational experience, and consensus. | a certain level of maturity, operational experience, and consensus. | |||
Similarly, publication of a specification an experimental document as | Similarly, publication of a specification as an experimental document | |||
part of the non-standards track would signal to the community that | not part of the Standards Track would signal to the community that | |||
the document “may be intended for eventual standardization but [may] | the document "may be intended for eventual standardization but [may] | |||
not yet [be] ready” for wide deployment. The extent of the | not yet [be] ready" for wide deployment. The extent of the | |||
deployment, and consequently its overall impact on end-users, may | deployment, and consequently its overall impact on end users, may | |||
depend on the document status presented in the RFC. See [BCP9] and | depend on the document status presented in the RFC. See [RFC2026] | |||
updates to it for a fuller explanation. | and updates to it for a fuller explanation. | |||
5. Document Status | 5. Document Status | |||
This RG document lays out best practices and guidelines for human | This research group document lays out best practices and guidelines | |||
rights reviews of network protocols, architectures and other | for human rights reviews of network protocols, architectures, and | |||
Internet-Drafts and RFCs. | other Internet-Drafts and RFCs. | |||
6. 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. | ||||
7. Security Considerations | 6. Security Considerations | |||
Article three of the Universal Declaration of Human Rights reads: | Article three of the "Universal Declaration of Human Rights" reads: | |||
“Everyone has the right to life, liberty and security of person.”. | "Everyone has the right to life, liberty and security of person" | |||
This article underlines the importance of security and its | [UDHR]. This article underlines the importance of security and its | |||
interrelation with human life and liberty, but since human rights are | interrelation with human life and liberty; but since human rights are | |||
indivisible, interrelated and interdependent, security is also | indivisible, interrelated, and interdependent, security is also | |||
closely linked to other human rights and freedoms. This document | closely linked to other human rights and freedoms. This document | |||
seeks to strengthen human rights, freedoms, and security by relating | seeks to strengthen human rights, freedoms, and security by relating | |||
and translating these concepts to concepts and practices as they are | and translating these concepts to concepts and practices as they are | |||
used in Internet protocol and architecture development. The aim of | used in Internet protocol and architecture development. The aim of | |||
this is to secure human rights and thereby improve the | this is to secure human rights and thereby improve the | |||
sustainability, usability, and effectiveness of the network. The | sustainability, usability, and effectiveness of the network. The | |||
document seeks to achieve this by providing guidelines as done in | document seeks to achieve this by providing guidelines as done in | |||
section three of this document. | Section 3 of this document. | |||
8. IANA Considerations | 7. IANA Considerations | |||
This document has no actions for IANA. | This document has no IANA actions. | |||
9. Research Group Information | 8. Research Group Information | |||
The discussion list for the IRTF Human Rights Protocol Considerations | The discussion list for the IRTF Human Rights Protocol Considerations | |||
Research Group is located at the e-mail address hrpc@ietf.org | Research Group is located at the e-mail address: | |||
(mailto:hrpc@ietf.org). Information on the group and information on | <mailto:hrpc@ietf.org>. | |||
how to subscribe to the list is at | ||||
https://www.irtf.org/mailman/listinfo/hrpc | ||||
(https://www.irtf.org/mailman/listinfo/hrpc) | ||||
Archives of the list can be found at: https://www.irtf.org/mail- | Information on the group and information on how to subscribe to the | |||
archive/web/hrpc/current/index.html (https://www.irtf.org/mail- | list is at: <https://www.irtf.org/mailman/listinfo/hrpc>. | |||
archive/web/hrpc/current/index.html) | ||||
10. Informative References | Archives of the list can be found at: | |||
<https://mailarchive.ietf.org/arch/browse/hrpc/>. | ||||
[arkkoetal] | 9. Informative References | |||
Arkko, J., Trammell, B., Notthingham, M., Huitema, C., | ||||
Thomson, M., Tantsure, J., and N. ten Oever, | [Arkko] Arkko, J., Trammell, B., Nottingham, M., Huitema, C., | |||
Thomson, M., Tantsura, J., and N. ten Oever, | ||||
"Considerations on Internet Consolidation and the Internet | "Considerations on Internet Consolidation and the Internet | |||
Architecture", 2019, | Architecture", Work in Progress, Internet-Draft, draft- | |||
arkko-iab-internet-consolidation-02, 8 July 2019, | ||||
<https://datatracker.ietf.org/doc/html/draft-arkko-iab- | <https://datatracker.ietf.org/doc/html/draft-arkko-iab- | |||
internet-consolidation-02>. | internet-consolidation-02>. | |||
[BCP72] IETF, "Guidelines for Writing RFC Text on Security | [BCP72] Best Current Practice 72, | |||
Considerations", 2003, | <https://www.rfc-editor.org/info/bcp72>. | |||
<https://datatracker.ietf.org/doc/bcp72/>. | At the time of writing, this BCP comprises the following: | |||
[BCP9] Bradner, S. and IETF, "The Internet Standards Process -- | ||||
Revision 3", 1996, | ||||
<https://datatracker.ietf.org/doc/rfc2026/>. | ||||
[Bless] Bless, R. and C. Orwat, "Values and Networks", 2015. | ||||
[Brown] Brown, I. and M. Ziewitz, "A Prehistory of Internet | ||||
Governance", Research Handbook on Governance of the | ||||
Internet. Cheltenham, Edward Elgar , 2013. | ||||
[draft-ietf-ohai-ohttp] | ||||
Thomson, M. and C.A. Wood, "Oblivious DNS Over HTTPS", | ||||
2023, <https://datatracker.ietf.org/doc/html/draft-ietf- | ||||
ohai-ohttp>. | ||||
[draft-irtf-pearg-censorship] | Rescorla, E. and B. Korver, "Guidelines for Writing RFC | |||
Hall, J., Aaron, M., Adams, S., Jones, B., and N. | Text on Security Considerations", BCP 72, RFC 3552, | |||
Feamster, "A Survey of Worldwide Censorship Techniques", | DOI 10.17487/RFC3552, July 2003, | |||
2020, | <https://www.rfc-editor.org/info/rfc3552>. | |||
<https://tools.ietf.org/html/draft-irtf-pearg-censorship>. | ||||
[draft-zuniga-mac-address-randomization] | Gont, F. and I. Arce, "Security Considerations for | |||
Zuniga, J.C., Bernardos, C.J., and A. Andersdotter, "MAC | Transient Numeric Identifiers Employed in Network | |||
address randomization", 2020, | Protocols", BCP 72, RFC 9416, DOI 10.17487/RFC9416, July | |||
<https://tools.ietf.org/html/draft-ietf-madinas-mac- | 2023, <https://www.rfc-editor.org/info/rfc9416>. | |||
address-randomization>. | ||||
[email-hashing] | [Email-hashing] | |||
Acar, G., Englehardt, S., and A. Narayanan, "Four cents to | Acar, G., Englehardt, S., and A. Narayanan, "Four cents to | |||
deanonymize: Companies reverse hashed email addresses", | deanonymize: Companies reverse hashed email addresses", | |||
n.d., <https://freedom-to-tinker.com/2018/04/09/four- | April 2018, <https://freedom-to-tinker.com/2018/04/09/ | |||
cents-to-deanonymize-companies-reverse-hashed-email- | four-cents-to-deanonymize-companies-reverse-hashed-email- | |||
addresses/>. | addresses/>. | |||
[FIArch] "Future Internet Design Principles", January 2012, | [FIArch] "Future Internet Design Principles", January 2012, | |||
<http://www.future-internet.eu/uploads/media/ | <http://www.future-internet.eu/uploads/media/ | |||
FIArch_Design_Principles_V1.0.pdf>. | FIArch_Design_Principles_V1.0.pdf>. | |||
[FREAK] "Tracking the FREAK Attack", 2015, | [FREAK] University of Michigan, "Tracking the FREAK Attack", | |||
Wayback Machine archive, March 2015, | ||||
<https://web.archive.org/web/20150304002021/ | <https://web.archive.org/web/20150304002021/ | |||
https://freakattack.com/>. | https://freakattack.com/>. | |||
[geekfeminism] | [geekfeminism] | |||
Geek Feminism Wiki, "Pseudonymity", 2015, | Geek Feminism Wiki, "Pseudonymity", June 2015, | |||
<http://geekfeminism.wikia.com/wiki/Pseudonymity>. | <https://geekfeminism.fandom.com/wiki/ | |||
Pseudonymity?oldid=30906>. | ||||
[hecate] Issa, R., Alhaddad, N., and M. Varia, "Hecate, Abuse | [Hecate] Issa, R., Alhaddad, N., and M. Varia, "Hecate: Abuse | |||
Reporting in Secure Messengers with Sealed Sender", 2022, | Reporting in Secure Messengers with Sealed Sender", | |||
Cryptology ePrint Archive, Paper 2021/1686, August 2022, | ||||
<https://eprint.iacr.org/2021/1686>. | <https://eprint.iacr.org/2021/1686>. | |||
[Hill2014] Hill, R., "Partial Catalog of Human Rights Related to ICT | [Hill] Hill, R., "Partial Catalog of Human Rights Related to ICT | |||
Activities", 2014, | Activities", May 2014, | |||
<http://www.apig.ch/UNIGE%20Catalog.pdf>. | <http://www.apig.ch/UNIGE%20Catalog.pdf>. | |||
[HR-RT] "Human Rights Reviews", 2022, | [HR-RT] "IRTF-HRPC / reviews", commit 3f5fbff, December 2020, | |||
<https://github.com/IRTF-HRPC/reviews>. | <https://github.com/IRTF-HRPC/reviews>. | |||
[HTML5] W3C, "HTML5", 2014, <https://www.w3.org/TR/html5/>. | [HTML] WHATWG, "HTML Living Standard", August 2024, | |||
<https://html.spec.whatwg.org/multipage/>. | ||||
[https-interception] | [HTTPS-interception] | |||
Durumeric, Z., Ma, Z., Springall, D., Barnes, R., | Durumeric, Z., Ma, Z., Springall, D., Barnes, R., | |||
Sullivan, N., Bursztein, E., Bailey, M., Halderman, J., | Sullivan, N., Bursztein, E., Bailey, M., Halderman, J., | |||
and V. Paxson, "The Security Impact of HTTPS | and V. Paxson, "The Security Impact of HTTPS | |||
Interception", 2017. | Interception", NDSS Symposium 2017, | |||
DOI 10.14722/ndss.2017.23456, February 2017, | ||||
[I-D.ietf-mls-protocol] | <https://doi.org/10.14722/ndss.2017.23456>. | |||
Barnes, R., Beurdouche, B., Robert, R., Millican, J., | ||||
Omara, E., and K. Cohn-Gordon, "The Messaging Layer | ||||
Security (MLS) Protocol", 2023, | ||||
<https://datatracker.ietf.org/doc/draft-ietf-mls- | ||||
protocol/>. | ||||
[I-D.ietf-tls-esni] | ||||
Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS | ||||
Encrypted Client Hello", Work in Progress, Internet-Draft, | ||||
draft-ietf-tls-esni-17, 9 October 2023, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-tls- | ||||
esni-17>. | ||||
[ICCPR] United Nations General Assembly, "International Covenant | [ICCPR] United Nations General Assembly, "International Covenant | |||
on Civil and Political Rights", 1976, | on Civil and Political Rights", December 1966, | |||
<http://www.ohchr.org/EN/ProfessionalInterest/Pages/ | <https://www.ohchr.org/en/instruments- | |||
CCPR.aspx>. | mechanisms/instruments/international-covenant-civil-and- | |||
political-rights>. | ||||
[ICESCR] United Nations General Assembly, "International Covenant | [ICESCR] United Nations General Assembly, "International Covenant | |||
on Economic, Social and Cultural Rights", 1966, | on Economic, Social and Cultural Rights", December 1966, | |||
<http://www.ohchr.org/EN/ProfessionalInterest/Pages/ | <https://www.ohchr.org/en/instruments- | |||
CESCR.aspx>. | mechanisms/instruments/international-covenant-economic- | |||
social-and-cultural-rights>. | ||||
[IRP] Internet Rights and Principles Dynamic Coalition, "10 | [IRP] Internet Rights and Principles Dynamic Coalition, "10 | |||
Internet Rights & Principles", 2014, | Internet Rights & Principles", | |||
<http://internetrightsandprinciples.org/site/wp- | <https://internetrightsandprinciples.org/campaign/>. | |||
content/uploads/2014/06/ | ||||
IRPC_10RightsandPrinciples_28May2014-11.pdf>. | ||||
[Kaye] Kaye, D., "The use of encryption and anonymity in digital | [Jorgensen] | |||
communications", 2015, | Jørgensen, R. F., "An internet bill of rights", Research | |||
<https://www.ohchr.org/EN/HRbodies/HRC/RegularSessions/ | Handbook on Governance of the Internet, edited by Ian | |||
Session29/Documents/A.HRC.29.32_AEV.doc>. | Brown. Cheltenham: Edward Elgar Publishing, | |||
DOI 10.4337/9781849805025.00022, April 2013, | ||||
<https://doi.org/10.4337/9781849805025.00022>. | ||||
[Logjam] Adrian, D., Bhargavan, K., and . et al, "Imperfect Forward | [Kaye] Kaye, D., "Report of the Special Rapporteur on the | |||
Secrecy, How Diffie-Hellman Fails in Practice", 2015, | Promotion and Protection of the Right to Freedom of | |||
<https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf>. | Opinion and Expression, David Kaye", A/HRC/29/32, May | |||
2015, <https://digitallibrary.un.org/record/798709?v=pdf>. | ||||
[messenger-franking] | [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 | Grubbs, P., Lu, J., and T. Ristenpart, "Message Franking | |||
via Committing Authenticated Encryption", 2017, | via Committing Authenticated Encryption", Cryptology | |||
ePrint Archive, Paper 2017/664, July 2017, | ||||
<https://eprint.iacr.org/2017/664>. | <https://eprint.iacr.org/2017/664>. | |||
[newegg] Mullin, J., "Newegg on trial: Mystery company TQP rewrites | [Newegg] Mullin, J., "Newegg on trial: Mystery company TQP rewrites | |||
the history of encryption", 2013, <http://arstechnica.com/ | the history of encryption", Ars Technica, November 2013, | |||
tech-policy/2013/11/newegg-on-trial-mystery-company-tqp- | <https://arstechnica.com/tech-policy/2013/11/newegg-on- | |||
re-writes-the-history-of-encryption/>. | trial-mystery-company-tqp-re-writes-the-history-of- | |||
encryption/>. | ||||
[notewell] IETF, "Note Well", 2015, | [Note-well] | |||
<https://www.ietf.org/about/note-well.html>. | IETF, "Note Well", | |||
<https://www.ietf.org/about/note-well/>. | ||||
[patentpolicy] | [Orwat] Orwat, C. and R. Bless, "Values and Networks: Steps Toward | |||
W3C, "W3C Patent Policy", 2004, | 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>. | ||||
[Patent-policy] | ||||
Weitzner, D., "W3C Patent Policy", W3C Recommendation, | ||||
February 2004, | ||||
<https://www.w3.org/Consortium/Patent-Policy-20040205/>. | <https://www.w3.org/Consortium/Patent-Policy-20040205/>. | |||
Latest version available at | ||||
<https://www.w3.org/policies/patent-policy/>. | ||||
[Penney] Penney, J., "Chilling Effects: Online Surveillance and | [Penney] Penney, J., "Chilling Effects: Online Surveillance and | |||
Wikipedia Use", 2016, <http://papers.ssrn.com/sol3/ | Wikipedia Use", Berkeley Technology Law Journal, vol. 31, | |||
no. 1, pp 117-182, DOI 10.15779/Z38SS13, September 2016, | ||||
<https://papers.ssrn.com/sol3/ | ||||
papers.cfm?abstract_id=2769645>. | papers.cfm?abstract_id=2769645>. | |||
[Pouwelse] Pouwelse, Ed, J., "Media without censorship", 2012, | [Pouwelse] Pouwelse, J., Ed., "Media without censorship (CensorFree) | |||
<https://tools.ietf.org/html/draft-pouwelse-censorfree- | scenarios", Work in Progress, Internet-Draft, draft- | |||
scenarios>. | pouwelse-censorfree-scenarios-02, 22 October 2012, | |||
<https://datatracker.ietf.org/doc/html/draft-pouwelse- | ||||
[RFC0793] Postel, J., "Transmission Control Protocol", RFC 793, | censorfree-scenarios-02>. | |||
DOI 10.17487/RFC0793, September 1981, | ||||
<https://www.rfc-editor.org/info/rfc793>. | ||||
[RFC1035] Mockapetris, P., "Domain names - implementation and | [RFC1035] Mockapetris, P., "Domain names - implementation and | |||
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | |||
November 1987, <https://www.rfc-editor.org/info/rfc1035>. | November 1987, <https://www.rfc-editor.org/info/rfc1035>. | |||
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the | [RFC1958] Carpenter, B., Ed., "Architectural Principles of the | |||
Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, | Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, | |||
<https://www.rfc-editor.org/info/rfc1958>. | <https://www.rfc-editor.org/info/rfc1958>. | |||
[RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic | [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic | |||
skipping to change at page 33, line 24 ¶ | skipping to change at line 1493 ¶ | |||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "DNS Security Introduction and Requirements", | Rose, "DNS Security Introduction and Requirements", | |||
RFC 4033, DOI 10.17487/RFC4033, March 2005, | RFC 4033, DOI 10.17487/RFC4033, March 2005, | |||
<https://www.rfc-editor.org/info/rfc4033>. | <https://www.rfc-editor.org/info/rfc4033>. | |||
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, | [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, | |||
DOI 10.17487/RFC4101, June 2005, | DOI 10.17487/RFC4101, June 2005, | |||
<https://www.rfc-editor.org/info/rfc4101>. | <https://www.rfc-editor.org/info/rfc4101>. | |||
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy | ||||
Extensions for Stateless Address Autoconfiguration in | ||||
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, | ||||
<https://www.rfc-editor.org/info/rfc4941>. | ||||
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", | [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", | |||
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, | FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, | |||
<https://www.rfc-editor.org/info/rfc4949>. | <https://www.rfc-editor.org/info/rfc4949>. | |||
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, | [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, | |||
DOI 10.17487/RFC5321, October 2008, | DOI 10.17487/RFC5321, October 2008, | |||
<https://www.rfc-editor.org/info/rfc5321>. | <https://www.rfc-editor.org/info/rfc5321>. | |||
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying | [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying | |||
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, | Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, | |||
skipping to change at page 35, line 40 ¶ | skipping to change at line 1595 ¶ | |||
[RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, | [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, | |||
DOI 10.17487/RFC8890, August 2020, | DOI 10.17487/RFC8890, August 2020, | |||
<https://www.rfc-editor.org/info/rfc8890>. | <https://www.rfc-editor.org/info/rfc8890>. | |||
[RFC8980] Arkko, J. and T. Hardie, "Report from the IAB Workshop on | [RFC8980] Arkko, J. and T. Hardie, "Report from the IAB Workshop on | |||
Design Expectations vs. Deployment Reality in Protocol | Design Expectations vs. Deployment Reality in Protocol | |||
Development", RFC 8980, DOI 10.17487/RFC8980, February | Development", RFC 8980, DOI 10.17487/RFC8980, February | |||
2021, <https://www.rfc-editor.org/info/rfc8980>. | 2021, <https://www.rfc-editor.org/info/rfc8980>. | |||
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, | ||||
"Temporary Address Extensions for Stateless Address | ||||
Autoconfiguration in IPv6", RFC 8981, | ||||
DOI 10.17487/RFC8981, February 2021, | ||||
<https://www.rfc-editor.org/info/rfc8981>. | ||||
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | |||
Multiplexed and Secure Transport", RFC 9000, | Multiplexed and Secure Transport", RFC 9000, | |||
DOI 10.17487/RFC9000, May 2021, | DOI 10.17487/RFC9000, May 2021, | |||
<https://www.rfc-editor.org/info/rfc9000>. | <https://www.rfc-editor.org/info/rfc9000>. | |||
[RFC9071] Hellström, G., "RTP-Mixer Formatting of Multiparty Real- | [RFC9071] Hellström, G., "RTP-Mixer Formatting of Multiparty Real- | |||
Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021, | Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021, | |||
<https://www.rfc-editor.org/info/rfc9071>. | <https://www.rfc-editor.org/info/rfc9071>. | |||
[Saltzer] Saltzer, J.H., Reed, D.P., and D.D. Clark, "End-to-End | [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", | |||
Arguments in System Design", ACM TOCS, Vol 2, Number 4, | STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, | |||
November 1984, pp 277-288. , 1984. | <https://www.rfc-editor.org/info/rfc9293>. | |||
[UDHR] United Nations General Assembly, "The Universal | [RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J., | |||
Declaration of Human Rights", 1948, | Omara, E., and K. Cohn-Gordon, "The Messaging Layer | |||
<http://www.un.org/en/documents/udhr/>. | Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, | |||
July 2023, <https://www.rfc-editor.org/info/rfc9420>. | ||||
[UNGP] United Nations, "United Nations Guiding Principles on | [RFC9458] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458, | |||
Business and Human Rights", 2011, | DOI 10.17487/RFC9458, January 2024, | |||
<https://www.ohchr.org/documents/publications/ | <https://www.rfc-editor.org/info/rfc9458>. | |||
guidingprinciplesbusinesshr_en.pdf>. | ||||
[RFC9505] Hall, J. L., Aaron, M. D., Andersdotter, A., Jones, B., | ||||
Feamster, N., and M. Knodel, "A Survey of Worldwide | ||||
Censorship Techniques", RFC 9505, DOI 10.17487/RFC9505, | ||||
November 2023, <https://www.rfc-editor.org/info/rfc9505>. | ||||
[Saltzer] Saltzer, J. H., Reed, D. P., and D. D. Clark, "End-to-end | ||||
arguments in system design", ACM Transactions on Computer | ||||
Systems, vol. 2, no. 4, pp 277-288, | ||||
DOI 10.1145/357401.357402, November 1984, | ||||
<https://doi.org/10.1145/357401.357402>. | ||||
[TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS | ||||
Encrypted Client Hello", Work in Progress, Internet-Draft, | ||||
draft-ietf-tls-esni-20, 4 August 2024, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-tls- | ||||
esni-20>. | ||||
[UDHR] United Nations General Assembly, "Universal Declaration of | ||||
Human Rights", December 1948, <https://www.un.org/en/ | ||||
about-us/universal-declaration-of-human-rights>. | ||||
[UNGP] United Nations, "Guiding Principles on Business and Human | ||||
Rights: Implementing the United Nations 'Protect, Respect | ||||
and Remedy' Framework", January 2012, | ||||
<https://www.ohchr.org/en/publications/reference- | ||||
publications/guiding-principles-business-and-human- | ||||
rights>. | ||||
[UNHR] United Nations, "The Core International Human Rights | [UNHR] United Nations, "The Core International Human Rights | |||
Instruments and their monitoring bodies", 2011, | Instruments and their monitoring bodies", | |||
<https://www.ohchr.org/en/professionalinterest/pages/ | <https://www.ohchr.org/en/core-international-human-rights- | |||
coreinstruments.aspx>. | instruments-and-their-monitoring-bodies>. | |||
[UNHRC2016] | [UNHRC2016] | |||
United Nations Human Rights Council, "UN Human Rights | United Nations Human Rights Council, "The promotion, | |||
Council Resolution "The promotion, protection and | protection and enjoyment of human rights on the Internet", | |||
enjoyment of human rights on the Internet" (A/HRC/32/ | A/HRC/32/L.20, June 2016, | |||
L.20)", 2016, <https://documents-dds- | <https://digitallibrary.un.org/record/845728?ln=en>. | |||
ny.un.org/doc/UNDOC/LTD/G16/131/89/PDF/ | ||||
G1613189.pdf?OpenElement>. | ||||
[W3CAccessibility] | [W3CAccessibility] | |||
W3C, "Accessibility", 2015, | W3C, "Accessibility", | |||
<https://www.w3.org/standards/webdesign/accessibility>. | <https://www.w3.org/standards/webdesign/accessibility>. | |||
[W3Ci18nDef] | [W3Ci18nDef] | |||
W3C, "Localization vs. Internationalization", 2010, | Ishida, R. and S. Miller, "Localization vs. | |||
<http://www.w3.org/International/questions/qa-i18n.en>. | Internationalization", December 2005, | |||
<https://www.w3.org/International/questions/qa-i18n.en>. | ||||
[Zittrain] Zittrain, J., "The Future of the Internet - And How to | [Ziewitz] Ziewitz, M. and I. Brown, "A Prehistory of Internet | |||
Stop It", Yale University Press , 2008, | Governance", Research Handbook on Governance of the | |||
<https://dash.harvard.edu/bitstream/handle/1/4455262/ | Internet, edited by Ian Brown. Cheltenham: Edward Elgar | |||
Zittrain_Future%20of%20the%20Internet.pdf?sequence=1>. | 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 | Authors' Addresses | |||
Gurshabad Grover | Gurshabad Grover | |||
Email: gurshabad@cis-india.org | Email: gurshabad@cis-india.org | |||
Niels ten Oever | Niels ten Oever | |||
University of Amsterdam | University of Amsterdam | |||
Email: mail@nielstenoever.net | Email: mail@nielstenoever.net | |||
End of changes. 197 change blocks. | ||||
624 lines changed or deleted | 679 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |