idnits 2.17.1 draft-irtf-hrpc-guidelines-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6973], [RFC8280]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC8280, but the abstract doesn't seem to directly say this. It does mention RFC8280 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 September 2021) is 952 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Duplicate reference: RFC2026, mentioned in 'RFC2026', was also mentioned in 'BCP9'. -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Human Rights Protocol Considerations Research Group G. Grover 3 Internet-Draft Centre for Internet and Society 4 Updates: 8280 (if approved) N. ten Oever 5 Intended status: Informational University of Amsterdam 6 Expires: 19 March 2022 15 September 2021 8 Guidelines for Human Rights Protocol and Architecture Considerations 9 draft-irtf-hrpc-guidelines-10 11 Abstract 13 This document sets guidelines for human rights considerations for 14 developers working on network protocols and architectures, similar to 15 the work done on the guidelines for privacy considerations [RFC6973]. 16 This is an updated version of the guidelines for human rights 17 considerations in [RFC8280]. 19 This document is not an Internet Standards Track specification; it is 20 published for informational purposes. 22 This informational document has consensus for publication from the 23 Internet Research Task Force (IRTF) Human Right Protocol 24 Considerations Research Group. It has been reviewed, tried, and 25 tested by both by the research group as well as by researchers and 26 practitioners from outside the research group. The research group 27 acknowledges that the understanding of the impact of internet 28 protocols and architecture on society is a developing practice and is 29 a body of research that is still in development. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 19 March 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Human rights threats . . . . . . . . . . . . . . . . . . . . 4 66 3. Guidelines for developing human rights protocol 67 considerations . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Conducting human rights reviews . . . . . . . . . . . . . 5 69 3.1.1. Analyzing drafts based on guidelines for human rights 70 considerations model . . . . . . . . . . . . . . . . 5 71 3.1.2. Analyzing drafts based on their perceived or speculated 72 impact . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1.3. Expert interviews . . . . . . . . . . . . . . . . . . 6 74 3.1.4. Interviews with impacted persons and communities . . 6 75 3.1.5. Tracing impacts of implementations . . . . . . . . . 6 76 3.2. Guidelines for human rights considerations . . . . . . . 6 77 3.2.1. Connectivity . . . . . . . . . . . . . . . . . . . . 7 78 3.2.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . 8 79 3.2.3. Content agnosticism . . . . . . . . . . . . . . . . . 8 80 3.2.4. Security . . . . . . . . . . . . . . . . . . . . . . 9 81 3.2.5. Internationalization . . . . . . . . . . . . . . . . 10 82 3.2.6. Censorship resistance . . . . . . . . . . . . . . . . 11 83 3.2.7. Open Standards . . . . . . . . . . . . . . . . . . . 12 84 3.2.8. Heterogeneity Support . . . . . . . . . . . . . . . . 14 85 3.2.9. Pseudonymity . . . . . . . . . . . . . . . . . . . . 15 86 3.2.10. Anonymity . . . . . . . . . . . . . . . . . . . . . . 16 87 3.2.11. Accessibility . . . . . . . . . . . . . . . . . . . . 17 88 3.2.12. Localization . . . . . . . . . . . . . . . . . . . . 17 89 3.2.13. Decentralization . . . . . . . . . . . . . . . . . . 18 90 3.2.14. Reliability . . . . . . . . . . . . . . . . . . . . . 19 91 3.2.15. Confidentiality . . . . . . . . . . . . . . . . . . . 20 92 3.2.16. Integrity . . . . . . . . . . . . . . . . . . . . . . 21 93 3.2.17. Authenticity . . . . . . . . . . . . . . . . . . . . 22 94 3.2.18. Adaptability . . . . . . . . . . . . . . . . . . . . 23 95 3.2.19. Outcome Transparency . . . . . . . . . . . . . . . . 23 96 3.2.20. Remedy . . . . . . . . . . . . . . . . . . . . . . . 24 97 3.2.21. Misc. considerations . . . . . . . . . . . . . . . . 25 98 4. Document Status . . . . . . . . . . . . . . . . . . . . . . . 25 99 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 101 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 102 8. Research Group Information . . . . . . . . . . . . . . . . . 26 103 9. Informative References . . . . . . . . . . . . . . . . . . . 26 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 106 1. Introduction 108 This document outlines a set of human rights protocol considerations 109 for protocol developers. It provides questions engineers should ask 110 themselves when developing or improving protocols if they want to 111 understand how their decisions can potentially influence the exercise 112 of human rights on the Internet. It should be noted that the impact 113 of a protocol cannot solely be deduced from its design, but its usage 114 and implementation should also be studied to form a full protocol 115 human rights impact assessment. 117 The questions are based on the research performed by the Human Rights 118 Protocol Considerations (hrpc) research group which has been 119 documented before these considerations. The research establishes 120 that human rights relate to standards and protocols, and offers a 121 common vocabulary of technical concepts that influence human rights 122 and how these technical concepts can be combined to ensure that the 123 Internet remains an enabling environment for human rights. With 124 this, the contours of a model for developing human rights protocol 125 considerations has taken shape. 127 This document is an iteration of the guidelines that can be found in 128 [RFC8280]. The methods for conducting human rights reviews 129 (Section 3.2), and guidelines for human rights considerations 130 (Section 3.3) in this document are being tested for relevance, 131 accuracy, and validity. The understanding of what human rights are 132 is based on the Universal Declaration of Human Rights and subsequent 133 treaties that jointly form the body of international human rights 134 law. 136 This document does not provide a detailed taxonomy of the nature of 137 (potential) human rights violations, whether direct or indirect, 138 long-term or short-term, certain protocol choices might present. In 139 part because this is highly context-dependent, and in part, because 140 this document aims to provide a practical set of guidelines. 141 However, further research in this field would definitely benefit 142 developers and implementers. 144 2. Human rights threats 146 Threats to the exercise of human rights on the Internet come in many 147 forms. Protocols and standards may harm or enable the right to 148 freedom of expression, right to freedom of information, right to non- 149 discrimination, right to equal protection, right to participate in 150 cultural life, arts and science, right to freedom of assembly and 151 association, right to privacy, and the right to security. An end- 152 user who is denied access to certain services or content may be 153 unable to disclose vital information about the malpractices of a 154 government or other authority. A person whose communications are 155 monitored may be prevented or dissuaded from exercising their right 156 to freedom of association or participate in political processes 157 [Penney]. In a worst-case scenario, protocols that leak information 158 can lead to physical danger. A realistic example to consider is when 159 individuals perceived as threats to the state are subjected to 160 torture, extra-judicial killing or detention on the basis of 161 information gathered by state agencies through the monitoring of 162 network traffic. 164 This document presents several examples of how threats to human 165 rights materialize on the Internet. This threat modeling is inspired 166 by [RFC6973] Privacy Considerations for Internet Protocols, which is 167 based on security threat analysis. This method is a work in progress 168 and by no means a perfect solution for assessing human rights risks 169 in Internet protocols and systems. Certain specific human rights 170 threats are indirectly considered in Internet protocols as part of 171 the security considerations [BCP72], but privacy considerations 172 [RFC6973] or reviews, let alone human rights impact assessments of 173 protocols are not standardized or implemented. 175 Many threats, enablers, and risks are linked to different rights. 176 This is not surprising if one takes into account that human rights 177 are interrelated, interdependent, and indivisible. Here however 178 we're not discussing all human rights because not all human rights 179 are relevant to ICTs in general and protocols and standards in 180 particular [Bless]: "The main source of the values of human rights is 181 the International Bill of Human Rights that is composed of the 182 Universal Declaration of Human Rights [UDHR] along with the 183 International Covenant on Civil and Political Rights [ICCPR] and the 184 International Covenant on Economic, Social and Cultural Rights 185 [ICESCR]. In the light of several cases of Internet censorship, the 186 Human Rights Council Resolution 20/8 was adopted in 2012, affirming 187 that "the same rights that people have offline must also be protected 188 online." [UNHRC2016] In 2015, the Charter of Human Rights and 189 Principles for the Internet [IRP] was developed and released. 190 According to these documents, some examples of human rights relevant 191 for ICT systems are human dignity (Art. 1 UDHR), non-discrimination 192 (Art. 2), rights to life, liberty and security (Art. 3), freedom of 193 opinion and expression (Art. 19), freedom of assembly and association 194 (Art. 20), rights to equal protection, legal remedy, fair trial, due 195 process, presumed innocent (Art. 7-11), appropriate social and 196 international order (Art. 28), participation in public affairs (Art. 197 21), participation in cultural life, protection of the moral and 198 material interests resulting from any scientific, literary or 199 artistic production of which [they are] the author (Art. 27), and 200 privacy (Art. 12)." A partial catalog of human rights related to 201 Information and Communications Technologies, including economic 202 rights, can be found in [Hill2014]. 204 This is by no means an attempt to exclude specific rights or 205 prioritize some rights over others. 207 3. Guidelines for developing human rights protocol considerations 209 3.1. Conducting human rights reviews 211 Human rights reviews can take place at different stages of the 212 development process of an Internet-Draft. However, generally 213 speaking, it is easier to influence the development of a technology 214 at earlier stages than at later stages. This does not mean that 215 reviews at last-call are not relevant, but they are less likely to 216 result in significant changes in the reviewed document. 218 Methods for analyzing technology for specific human rights impacts 219 are still quite nascent. Currently, five methods have been explored 220 by the Human Rights Review Team, often in conjunction with each 221 other: 223 3.1.1. Analyzing drafts based on guidelines for human rights 224 considerations model 226 This analysis of Internet-Drafts uses the model as described in 227 section 3.3. The outlined categories and questions can be used to 228 review an Internet-Draft. The advantage of this is that it provides 229 a known overview, and document authors can go back to this document 230 as well as [RFC8280] to understand the background and the context. 232 3.1.2. Analyzing drafts based on their perceived or speculated impact 234 When reviewing an Internet-Draft, specific human rights impacts can 235 become apparent by doing a close reading of the draft and seeking to 236 understand how it might affect networks or society. While less 237 structured than the straight use of the human rights considerations 238 model, this analysis may lead to new speculative understandings of 239 links between human rights and protocols. 241 3.1.3. Expert interviews 243 Interviews with document authors, active members of the Working 244 Group, or experts in the field can help explore the characteristics 245 of the protocol and its effects. There are two main advantages to 246 this approach: one the one hand, it allows the reviewer to gain a 247 deeper understanding of the (intended) workings of the protocol; on 248 the other hand, it also allows for the reviewer to start a discussion 249 with experts or even document authors, which can help the review gain 250 traction when it is published. 252 3.1.4. Interviews with impacted persons and communities 254 Protocols impact users of the Internet. Interviews can help the 255 reviewer understand how protocols affect the people that use the 256 protocols. Since human rights are best understood from the 257 perspective of the rights-holder, this approach will improve the 258 understanding of the real world effects of the technology. At the 259 same time, it can be hard to attribute specific changes to a 260 particular protocol, this is of course even harder when a protocol 261 has not been (widely) deployed. 263 3.1.5. Tracing impacts of implementations 265 The reality of deployed protocols can be at odds with the 266 expectations during the protocol design and development phase 267 [RFC8980]. When a specification already has associated running code, 268 the code can be analyzed either in an experimental setting or on the 269 Internet where its impact can be observed. In contrast to reviewing 270 the draft text, this approach can allow the reviewer to understand 271 how the specifications works in practice, and potentially what 272 unknown or unexpected effects the technology has. 274 3.2. Guidelines for human rights considerations 276 This section provides guidance for document authors in the form of a 277 questionnaire about protocols and how technical decisions can shape 278 the exercise of human rights. The questionnaire may be useful at any 279 point in the design process, particularly after the document authors 280 have developed a high-level protocol model as described in [RFC4101]. 281 These guidelines do not seek to replace any existing referenced 282 specifications, but rather contribute to them and look at the design 283 process from a human rights perspective. 285 Protocols and Internet Standards might benefit from a documented 286 discussion of potential human rights risks arising from potential 287 misapplications of the protocol or technology described in the RFC. 288 This might be coupled with an Applicability Statement for that RFC. 290 Note that the guidance provided in this section does not recommend 291 specific practices. The range of protocols developed in the IETF is 292 too broad to make recommendations about particular uses of data or 293 how human rights might be balanced against other design goals. 294 However, by carefully considering the answers to the following 295 questions, document authors should be able to produce a comprehensive 296 analysis that can serve as the basis for discussion on whether the 297 protocol adequately takes specific human rights threats into account. 298 This guidance is meant to help the thought process of a human rights 299 analysis; it does not provide specific directions for how to write a 300 human rights considerations section (following the example set in 301 [RFC6973]). 303 In considering these questions, authors will need to be aware of the 304 potential of technical advances or the passage of time to undermine 305 protections. In general, considerations of rights are likely to be 306 more effective if they are considered given a purpose and specific 307 use cases, rather than as abstract absolute goals. 309 Also note that while the section uses the word, 'protocol', the 310 principles identified in these questions may be applicable to other 311 types of solutions (extensions to existing protocols, architecture 312 for solutions to specific problems, etc.). 314 3.2.1. Connectivity 316 Question(s): Does your protocol add application-specific functions to 317 intermediary nodes? Could this functionality be added to end nodes 318 instead of intermediary nodes? Is your protocol optimized for low 319 bandwidth and high latency connections? Could your protocol also be 320 developed in a stateless manner? 322 Explanation: The end-to-end principle [Saltzer] holds that 'the 323 intelligence is end to end rather than hidden in the network' 324 [RFC1958]. Using the end-to-end principle in protocol design is 325 important to ensure the reliability and security of data 326 transmissions. 328 Considering the fact that network quality and conditions vary across 329 geography and time, it is also important to design protocols such 330 that they are reliable even on low bandwidth and high latency 331 connections. 333 Example: Encrypting connections, like done with HTTPS, can add a 334 significant network overhead and consequently make web resources less 335 accessible to those with low bandwidth and/or high latency 336 connections. [HTTPS-REL] Encrypting traffic is a net positive for 337 privacy and security, and thus protocol designers can acknowledge the 338 tradeoffs of connectivity made by such decisions. 340 Impacts: 342 * Right to freedom of expression 344 * Right to freedom of assembly and association 346 3.2.2. Privacy 348 Question(s): Did you have a look at the Guidelines in the Privacy 349 Considerations for Internet Protocols [RFC6973] section 7? Does your 350 protocol maintain the confidentiality of metadata? Could your 351 protocol counter traffic analysis? Does your protocol adhere to data 352 minimization principles? Does your document identify potentially 353 sensitive data logged by your protocol and/or for how long that needs 354 to be retained for technical reasons? 356 Explanation: Privacy refers to the right of an entity (normally a 357 person), acting on its own behalf, to determine the degree to which 358 it will interact with its environment, including the degree to which 359 the entity is willing to share its personal information with others. 360 [RFC4949]. If a protocol provides insufficient privacy protection it 361 may have a negative impact on freedom of expression as users self- 362 censor for fear of surveillance, or find themselves unable to express 363 themselves freely. 365 Example: See [RFC6973] 367 Impacts: 369 * Right to freedom of expression 371 * Right to non-discrimination 373 3.2.3. Content agnosticism 375 Question(s): If your protocol impacts packet handling, does it use 376 user data (packet data that is not included in the header)? Is it 377 making decisions based on the payload of the packet? Does your 378 protocol prioritize certain content or services over others in the 379 routing process? Is the protocol transparent about the 380 prioritization that is made (if any)? 381 Explanation: Content agnosticism refers to the notion that network 382 traffic is treated identically regardless of payload, with some 383 exceptions where it comes to effective traffic handling, for instance 384 where it comes to delay-tolerant or delay-sensitive packets, based on 385 the header. 387 Example: Content agnosticism prevents payload-based discrimination 388 against packets. This is important because changes to this principle 389 can lead to a two-tiered Internet, where certain packets are 390 prioritized over others on the basis of their content. Effectively 391 this would mean that although all users are entitled to receive their 392 packets at a certain speed, some users become more equal than others. 394 Impacts: 396 * Right to freedom of expression 398 * Right to non-discrimination 400 * Right to equal protection 402 3.2.4. Security 404 Question(s): Did you have a look at Guidelines for Writing RFC Text 405 on Security Considerations [BCP72]? Have you found any attacks that 406 are somewhat related to your protocol/specification, yet considered 407 out of scope of your document? Would these attacks be pertinent to 408 the human rights enabling features of the Internet (as described 409 throughout this document)? 411 Explanation: Security is not a single monolithic property of a 412 protocol or system, but rather a series of related but somewhat 413 independent properties. Not all of these properties are required for 414 every application. Since communications are carried out by systems 415 and access to systems is through communications channels, security 416 goals obviously interlock, but they can also be independently 417 provided. [BCP72]. 419 Example: See [BCP72]. 421 Impacts: 423 * Right to freedom of expression 425 * Right to freedom of assembly and association 427 * Right to non-discrimination 428 * Right to security 430 3.2.5. Internationalization 432 Question(s): Does your protocol or specification define text string 433 elements, in the payload or headers, that have to be understood or 434 entered by humans? Does your specification allow Unicode? If so, do 435 you accept texts in one charset (which must be UTF-8), or several 436 (which is dangerous for interoperability)? If character sets or 437 encodings other than UTF-8 are allowed, does your specification 438 mandate a proper tagging of the charset? Did you have a look at 439 [RFC6365]? 441 Explanation: Internationalization refers to the practice of making 442 protocols, standards, and implementations usable in different 443 languages and scripts (see Localization). In the IETF, 444 internationalization means to add or improve the handling of non- 445 ASCII text in a protocol. [RFC6365] A different perspective, more 446 appropriate to protocols that are designed for global use from the 447 beginning, is the definition used by W3C: 449 "Internationalization is the design and development of a 450 product, application or document content that enables easy 451 localization for target audiences that vary in culture, region, 452 or language." {{W3Ci18nDef}} 454 Many protocols that handle text only handle one charset (US-ASCII), 455 or leave the question of what coded character set and encoding are 456 used up to local guesswork (which leads, of course, to 457 interoperability problems). If multiple charsets are permitted, they 458 must be explicitly identified [RFC2277]. Adding non-ASCII text to a 459 protocol allows the protocol to handle more scripts, hopefully 460 representing users across the world. In today's world, that is 461 normally best accomplished by allowing Unicode encoded in UTF-8 only. 463 In the current IETF policy [RFC2277], internationalization is aimed 464 at user-facing strings, not protocol elements, such as the verbs used 465 by some text-based protocols. (Do note that some strings are both 466 content and protocol elements, such as the identifiers.) Given the 467 IETF's mission to make the Internet a global network of networks, 468 [RFC3935] developers should ensure that protocols work with languages 469 apart from English and character sets apart from Latin characters. 470 It is therefore crucial that at least the content carried by the 471 protocol can be in any script, and that all scripts are treated 472 equally. 474 Example: See localization 475 Impacts: 477 * Right to freedom of expression 479 * Right to political participation 481 * Right to participate in cultural life, arts and science 483 3.2.6. Censorship resistance 485 Question(s): Does your protocol make it apparent or transparent when 486 access to a resource is restricted and reasons therefor? Can your 487 protocol contribute to filtering in a way it could be implemented to 488 censor data or services? Could this be designed to ensure this 489 doesn't happen? Does your protocol introduce new identifiers or 490 reuse existing identifiers (e.g. MAC addresses) that might be 491 associated with persons or content? 493 Explanation: Censorship resistance refers to the methods and measures 494 to prevent Internet censorship. See [draft-irtf-pearg-censorship] 495 for a survey of censorship techniques employed across the world, 496 which lays out protocol properties that have been exploited to censor 497 access to information. 499 Example: Identifiers of content exposed within a protocol might be 500 used to facilitate censorship, as in the case of Application Layer 501 based censorship, which affects protocols like HTTP. In HTTP, denial 502 or restriction of access can be made apparent by the use of status 503 code 451, which allows server operators to operate with greater 504 transparency in circumstances where issues of law or public policy 505 affect their operation [RFC7725]. 507 If a protocol potentially enables censorship, protocol designers 508 should strive towards creating error codes that capture different 509 scenarios (blocked due to administrative policy, unavailable because 510 of legal requirements, etc.) to minimize ambiguity for end-users. 512 In the development of the IPv6 protocol, it was discussed to embed a 513 Media Access Control (MAC) address into unique IP addresses. This 514 would make it possible for 'eavesdroppers and other information 515 collectors to identify when different addresses used in different 516 transactions actually correspond to the same node. This is why 517 standardisation efforts like Privacy Extensions for Stateless Address 518 Autoconfiguration in IPv6 [RFC4941] and MAC address randomization 519 [draft-zuniga-mac-address-randomization] have been pursued. 521 Impacts: 523 * Right to freedom of expression 525 * Right to political participation 527 * Right to participate in cultural life, arts, and science 529 * Right to freedom of assembly and association 531 3.2.7. Open Standards 533 Question(s): Is your protocol fully documented in a way that it could 534 be easily implemented, improved, built upon and/or further developed? 535 Do you depend on proprietary code for the implementation, running or 536 further development of your protocol? Does your protocol favor a 537 particular proprietary specification over technically-equivalent 538 competing specification(s), for instance by making any incorporated 539 vendor specification "required" or "recommended" [RFC2026]? Do you 540 normatively reference another standard that is not available without 541 cost (and could you do without it)? Are you aware of any patents 542 that would prevent your standard from being fully implemented 543 [RFC8179] [RFC6701]? 545 Explanation: The Internet was able to be developed into the global 546 network of networks because of the existence of open, non-proprietary 547 standards [Zittrain]. They are crucial for enabling 548 interoperability. Yet, open standards are not explicitly defined 549 within the IETF. On the subject, [RFC2026] states: "Various national 550 and international standards bodies, such as ANSI, ISO, IEEE, and ITU- 551 T, develop a variety of protocol and service specifications that are 552 similar to Technical Specifications defined at the IETF. National 553 and international groups also publish "implementors' agreements" that 554 are analogous to Applicability Statements, capturing a body of 555 implementation-specific detail concerned with the practical 556 application of their standards. All of these are considered to be 557 "open external standards" for the purposes of the Internet Standards 558 Process." Similarly, [RFC3935] does not define open standards but 559 does emphasize the importance of an "open process", i.e. "any 560 interested person can participate in the work, know what is being 561 decided, and make his or her voice heard on the issue." 562 Open standards (and open source software) allow users to glean 563 information about how the tools they are using work, including the 564 tools' security and privacy properties. They additionally allow for 565 permissionless innovation, which is important to maintain the freedom 566 and ability to freely create and deploy new protocols on top of the 567 communications constructs that currently exist. It is at the heart 568 of the Internet as we know it, and to maintain its fundamentally open 569 nature, we need to be mindful of the need for developing open 570 standards. 572 All standards that need to be normatively implemented should be 573 freely available and with reasonable protection for patent 574 infringement claims, so it can also be implemented in open source or 575 free software. Patents have often held back open standardization or 576 been used against those deploying open standards, particularly in the 577 domain of cryptography [newegg]. An exemption of this is sometimes 578 made when a protocol is standardized that normatively relies on 579 specifications produced by others SDOs that are not freely available. 580 Patents in open standards or in normative references to other 581 standards should have a patent disclosure [notewell], royalty-free 582 licensing [patentpolicy], or some other form of fair, reasonable and 583 non-discriminatory terms. 585 Example: [RFC6108] describes a system for providing critical end-user 586 notifications to web browsers, which has been deployed by Comcast, an 587 Internet Service Provider (ISP). Such a notification system is being 588 used to provide near-immediate notifications to customers, such as to 589 warn them that their traffic exhibits patterns that are indicative of 590 malware or virus infection. There are other proprietary systems that 591 can perform such notifications, but those systems utilize Deep Packet 592 Inspection (DPI) technology. In contrast, that document describes a 593 system that does not rely upon DPI, and is instead based on open IETF 594 standards and open source applications. 596 Impacts: 598 * Right to freedom of expression 600 * Right to participate in cultural life, arts and science 602 3.2.8. Heterogeneity Support 604 Question(s): Does your protocol support heterogeneity by design? 605 Does your protocol allow for multiple types of hardware? Does your 606 protocol allow for multiple types of application protocols? Is your 607 protocol liberal in what it receives and handles? Will it remain 608 usable and open if the context changes? Does your protocol allow 609 there to be well-defined extension points? Do these extension points 610 allow for open innovation? 612 Explanation: The Internet is characterized by heterogeneity on many 613 levels: devices and nodes, router scheduling algorithms and queue 614 management mechanisms, routing protocols, levels of multiplexing, 615 protocol versions and implementations, underlying link layers (e.g., 616 point-to-point, multi-access links, wireless, FDDI, etc.), in the 617 traffic mix and in the levels of congestion at different times and 618 places. Moreover, as the Internet is composed of autonomous 619 organizations and Internet service providers, each with their own 620 separate policy concerns, there is a large heterogeneity of 621 administrative domains and pricing structures. As a result, the 622 heterogeneity principle proposed in [RFC1958] needs to be supported 623 by design [FIArch]. 625 Heterogeneity support in protocols can thus enable a wide range of 626 devices and (by extension) users to participate on the network. 628 Example: Heterogeneity is inevitable and needs be supported by 629 design. Multiple types of hardware must be allowed for, e.g. 630 transmission speeds differing by at least 7 orders of magnitude, 631 various computer word lengths, and hosts ranging from memory-starved 632 microprocessors up to massively parallel supercomputers. Multiple 633 types of application protocols must be allowed for, ranging from the 634 simplest such as remote login up to the most complex such as commit 635 protocols for distributed databases. [RFC1958]. 637 Impacts: 639 * Right to freedom of expression 641 * Right to political participation 643 3.2.9. Pseudonymity 645 Question(s): Have you considered the Privacy Considerations for 646 Internet Protocols [RFC6973], especially section 6.1.2 ? Does the 647 protocol collect personally derived data? Does the protocol generate 648 or process anything that can be, or be tightly correlated with, 649 personally identifiable information? Does the protocol utilize data 650 that is personally-derived, i.e. derived from the interaction of a 651 single person, or their device or address? Does this protocol 652 generate personally derived data, and if so how will that data be 653 handled? 655 Explanation: Pseudonymity - the ability to use a persistent 656 identifier not linked to one's offline identity - is an important 657 feature for many end-users, as it allows them different degrees of 658 disguised identity and privacy online. This can allow an enabling 659 environment for users to exercise other rights, including freedom of 660 expression and political participation, without fear or direct 661 identification or discrimination. 663 Example: While designing a standard that exposes personal data, it is 664 important to consider ways to mitigate the obvious impacts. While 665 pseudonyms cannot be simply reverse engineered - some early 666 approaches simply took approaches such as simple hashing of IP 667 addresses, these could then be simply reversed by generating a hash 668 for each potential IP address and comparing it to the pseudonym - 669 limiting the exposure of personal data remains important. 671 Pseudonymity means using a pseudonym instead of one's "real" name. 672 There are many reasons for users to use pseudonyms, for instance to: 673 hide their gender, protect themselves against harassment, protect 674 their families' privacy, frankly discuss sexuality, or develop an 675 artistic or journalistic persona without repercussions from an 676 employer, (potential) customers, or social surrounding. 677 [geekfeminism] The difference between anonymity and pseudonymity is 678 that a pseudonym often is persistent. "Pseudonymity is strengthened 679 when less personal data can be linked to the pseudonym; when the same 680 pseudonym is used less often and across fewer contexts; and when 681 independently chosen pseudonyms are more frequently used for new 682 actions (making them, from an observer's or attacker's perspective, 683 unlinkable)." [RFC6973] 685 Impacts: 687 * Right to non-discrimination 689 * Right to freedom of expression 690 * Right to political participation 692 * Right to freedom of assembly and association 694 3.2.10. Anonymity 696 Question(s): Does your protocol make use of persistent identifiers? 697 Can it be done without them? Did you have a look at the Privacy 698 Considerations for Internet Protocols [RFC6973], especially section 699 6.1.1 of that document? 701 Explanation: Anonymity refers to the condition of an identity being 702 unknown or concealed [RFC4949]. Even though full anonymity is hard 703 to achieve, it is a non-binary concept. Making pervasive monitoring 704 and tracking harder is important for many users as well as for the 705 IETF [RFC7258]. Achieving a higher level of anonymity is an 706 important feature for many end-users, as it allows them different 707 degrees of privacy online. Anonymity is an inherent part of the 708 right to freedom of opinion and expression and the right to privacy. 709 Avoid adding identifiers, options or configurations that create or 710 might lead to patterns or regularities that are not explicitly 711 required by the protocol. 713 If your protocol collects data and distributes it (see [RFC6235]), 714 you should anonymize the data, but keep in mind that "anonymizing" 715 data is notoriously hard. Do not think that just dropping the last 716 byte of an IP address "anonymizes" data. If your protocol allows for 717 identity management, there should be a clear barrier between the 718 identities to ensure that they cannot (easily) be associated with 719 each other. 721 Often protocols expose personal data, it is important to consider 722 ways to mitigate the obvious privacy impacts. A protocol that uses 723 data that could help identify a sender (items of interest) should be 724 protected from third parties. For instance, if one wants to hide the 725 source/destination IP addresses of a packet, the use of IPsec in 726 tunneling mode (e.g., inside a virtual private network) can be 727 helpful to protect from third parties likely to eavesdrop packets 728 exchanged between the tunnel endpoints. 730 Example: An example is DHCP where sending a persistent identifier as 731 the client name was not mandatory but, in practice, done by many 732 implementations, before [RFC7844]. 734 Impacts: 736 * Right to non-discrimination 737 * Right to political participation 739 * Right to freedom of assembly and association 741 * Right to security 743 3.2.11. Accessibility 745 Question(s): Is your protocol designed to provide an enabling 746 environment for all? Have you looked at the W3C Web Accessibility 747 Initiative for examples and guidance? 749 Explanation: Sometimes in the design of protocols, websites, web 750 technologies, or web tools, barriers are created that exclude people 751 from using the Web. The Internet should be designed to work for all 752 people, whatever their hardware, software, language, culture, 753 location, or physical or mental ability. When the Internet 754 technologies meet this goal, it will be accessible to people with a 755 diverse range of hearing, movement, sight, and cognitive ability. 756 [W3CAccessibility] 758 Example: The HTML protocol as defined in [HTML5] specifically 759 requires that every image must have an alt attribute (with a few 760 exceptions) to ensure images are accessible for people that cannot 761 themselves decipher non-text content in web pages. 763 Impacts: 765 * Right to non-discrimination 767 * Right to freedom of assembly and association 769 * Right to education 771 * Right to political participation 773 3.2.12. Localization 775 Question(s): Does your protocol uphold the standards of 776 internationalization? Have you made any concrete steps towards 777 localizing your protocol for relevant audiences? 778 Explanation: Localization refers to the adaptation of a product, 779 application or document content to meet the language, cultural and 780 other requirements of a specific target market (a locale) 781 [W3Ci18nDef]. For our purposes, it can be described as the practice 782 of translating an implementation to make it functional in a specific 783 language or for users in a specific locale (see 784 Internationalization). 786 Example: The Internet is a global medium, but many of its protocols 787 and products are developed with a certain audience in mind, that 788 often share particular characteristics like knowing how to read and 789 write in ASCII and knowing English. This limits the ability of a 790 large part of the world's online population from using the Internet 791 in a way that is culturally and linguistically accessible. An 792 example of a protocol that has taken into account the view that 793 individuals like to have access to data in their native language can 794 be found in [RFC5646]. This protocol labels the information content 795 with an identifier for the language in which it is written. And this 796 allows information to be presented in more than one language. 798 Impacts: 800 * Right to non-discrimination 802 * Right to participate in cultural life, arts and science 804 * Right to freedom of expression 806 3.2.13. Decentralization 808 Question(s): Can your protocol be implemented without a single point 809 of control? If applicable, can your protocol be deployed in a 810 federated manner? What is the potential for discrimination against 811 users of your protocol? How can your protocol be used to implicate 812 users? Does your protocol create additional centralized points of 813 control? 815 Explanation: Decentralization is one of the central technical 816 concepts of the architecture of the networks, and is embraced as such 817 by the IETF [RFC3935]. It refers to the absence or minimization of 818 centralized points of control, a feature that is assumed to make it 819 easy for new users to join and new uses to unfold [Brown]. It also 820 reduces issues surrounding single points of failure, and distributes 821 the network such that it continues to function even if one or several 822 nodes are disabled. With the commercialization of the Internet in 823 the early 1990s, there has been a slow move away from 824 decentralization, to the detriment of the technical benefits of 825 having a decentralized Internet. 827 Example: The bits traveling the Internet are increasingly susceptible 828 to monitoring and censorship, from both governments and Internet 829 service providers, as well as third (malicious) parties. The ability 830 to monitor and censor is further enabled by the increased 831 centralization of the network that creates central infrastructure 832 points that can be tapped into. The creation of peer-to-peer 833 networks and the development of voice-over-IP protocols using peer- 834 to-peer technology in combination with distributed hash table (DHT) 835 for scalability are examples of how protocols can preserve 836 decentralization [Pouwelse]. 838 Impacts: 840 * Right to freedom of expression 842 * Right to freedom of assembly and association 844 3.2.14. Reliability 846 Question(s): Is your protocol fault tolerant? Does it downgrade 847 gracefully, i.e. with mechanisms for fallback and/or notice? Can 848 your protocol resist malicious degradation attempts? Do you have a 849 documented way to announce degradation? Do you have measures in 850 place for recovery or partial healing from failure? Can your 851 protocol maintain dependability and performance in the face of 852 unanticipated changes or circumstances? 854 Explanation: Reliability and resiliency ensures that a protocol will 855 execute its function consistently and error resistant as described, 856 and function without unexpected result. A system that is reliable 857 degrades gracefully and will have a documented way to announce 858 degradation. It also has mechanisms to recover from failure 859 gracefully, and if applicable, allow for partial healing. 861 It is important here to draw a distinction between random degradation 862 and malicious degradation. Many current attacks against TLS, for 863 example, exploit TLS' ability to gracefully downgrade to older cipher 864 suites - from a functional perspective, this is useful; from a 865 security perspective, this can be disastrous. As with 866 confidentiality, the growth of the Internet and fostering innovation 867 in services depends on users having confidence and trust [RFC3724] in 868 the network. For reliability, it is necessary that services notify 869 the users if a delivery fails. In the case of real-time systems in 870 addition to the reliable delivery the protocol needs to safeguard 871 timeliness. 873 Example: In the modern IP stack structure, a reliable transport layer 874 requires an indication that transport processing has successfully 875 completed, such as given by TCP's ACK message [RFC0793], and not 876 simply an indication from the IP layer that the packet arrived. 877 Similarly, an application layer protocol may require an application- 878 specific acknowledgment that contains, among other things, a status 879 code indicating the disposition of the request (See [RFC3724]). 881 Impacts: 883 * Right to freedom of expression 885 * Right to security 887 3.2.15. Confidentiality 889 Question(s): Does this protocol expose information related to 890 identifiers or data? If so, does it do so to each other protocol 891 entity (i.e., recipients, intermediaries, and enablers) [RFC6973]? 892 What options exist for protocol implementers to choose to limit the 893 information shared with each entity? What operational controls are 894 available to limit the information shared with each entity? 896 What controls or consent mechanisms does the protocol define or 897 require before personal data or identifiers are shared or exposed via 898 the protocol? If no such mechanisms or controls are specified, is it 899 expected that control and consent will be handled outside of the 900 protocol? 902 Does the protocol provide ways for initiators to share different 903 pieces of information with different recipients? If not, are there 904 mechanisms that exist outside of the protocol to provide initiators 905 with such control? 907 Does the protocol provide ways for initiators to limit the sharing or 908 express individuals' preferences to recipients or intermediaries with 909 regard to the collection, use, or disclosure of their personal data? 910 If not, are there mechanisms that exist outside of the protocol to 911 provide users with such control? Is it expected that users will have 912 relationships that govern the use of the information (contractual or 913 otherwise) with those who operate these intermediaries? Does the 914 protocol prefer encryption over clear text operation? 916 Explanation: Confidentiality refers to keeping your data secret from 917 unintended listeners [BCP72]. The growth of the Internet depends on 918 users having confidence that the network protects their personal data 919 [RFC1984]. 921 Example: Protocols that do not encrypt their payload make the entire 922 content of the communication available to the idealized attacker 923 along their path. Following the advice in [RFC3365], most such 924 protocols have a secure variant that encrypts the payload for 925 confidentiality, and these secure variants are seeing ever-wider 926 deployment. A noteworthy exception is DNS [RFC1035], as DNSSEC 927 [RFC4033] does not have confidentiality as a requirement. This 928 implies that, in the absence of the use of more recent standards like 929 DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484], all DNS queries 930 and answers generated by the activities of any protocol are available 931 to the attacker. When store-and-forward protocols are used (e.g., 932 SMTP [RFC5321]), intermediaries leave this data subject to 933 observation by an attacker that has compromised these intermediaries, 934 unless the data is encrypted end-to-end by the application-layer 935 protocol or the implementation uses an encrypted store for this data 936 [RFC7624]. 938 Impacts: 940 * Right to privacy 942 * Right to security 944 3.2.16. Integrity 946 Question(s): Does your protocol maintain, assure and/or verify the 947 accuracy of payload data? Does your protocol maintain and assure the 948 consistency of data? Does your protocol in any way allow for the 949 data to be (intentionally or unintentionally) altered? 951 Explanation: Integrity refers to the maintenance and assurance of the 952 accuracy and consistency of data to ensure it has not been 953 (intentionally or unintentionally) altered. 955 Example: Integrity verification of data is important to prevent 956 vulnerabilities and attacks from on-path attackers. These attacks 957 happen when a third party (often for malicious reasons) intercepts a 958 communication between two parties, inserting themselves in the middle 959 changing the content of the data. In practice this looks as follows: 961 Alice wants to communicate with Bob. Corinne forges and sends a 962 message to Bob, impersonating Alice. Bob cannot see the data from 963 Alice was altered by Corinne. Corinne intercepts and alters the 964 communication as it is sent between Alice and Bob. Corinne is able to 965 control the communication content. 967 Impacts: 969 * Right to freedom of expression 971 * Right to security 973 3.2.17. Authenticity 975 Question(s): Do you have sufficient measures to confirm the truth of 976 an attribute of a single piece of data or entity? Can the attributes 977 get garbled along the way (see security)? If relevant, have you 978 implemented IPsec, DNSsec, HTTPS and other Standard Security Best 979 Practices? 981 Explanation: Authenticity ensures that data does indeed come from the 982 source it claims to come from. This is important to prevent certain 983 attacks or unauthorized access and use of data. 985 At the same time, authentication should not be used as a way to 986 prevent heterogeneity support, as is often done for vendor lock-in or 987 digital rights management. 989 Example: Authentication of data is important to prevent 990 vulnerabilities, and attacks from on-path attackers. These attacks 991 happen when a third party (often for malicious reasons) intercepts a 992 communication between two parties, inserting themselves in the middle 993 and posing as both parties. In practice this looks as follows: 995 Alice wants to communicate with Bob. Alice sends data to Bob. Corinne 996 intercepts the data sent to Bob. Corinne reads (and potentially 997 alters) the message to Bob. Bob cannot see the data did not come from 998 Alice but from Corinne. 1000 When there is proper authentication the scenario would be as follows: 1002 Alice wants to communicate with Bob. Alice sends data to Bob. Corinne 1003 intercepts the data sent to Bob. Corinne reads and alters the message 1004 to Bob. Bob can see the data did not come from Alice. 1006 Impacts: 1008 * Right to privacy 1010 * Right to freedom of expression 1012 * Right to security 1014 3.2.18. Adaptability 1016 Question(s): Is your protocol written in such a way that it would be 1017 easy for other protocols to be developed on top of it, or to interact 1018 with it? Does your protocol impact permissionless innovation? (See 1019 Open Standards) 1021 Explanation: Adaptability is closely interrelated with permissionless 1022 innovation: both maintain the freedom and ability to freely create 1023 and deploy new protocols on top of the communications constructs that 1024 currently exist. It is at the heart of the Internet as we know it, 1025 and to maintain its fundamentally open nature, we need to be mindful 1026 of the impact of protocols on maintaining or reducing permissionless 1027 innovation to ensure the Internet can continue to develop. 1029 Example: WebRTC generates audio and/or video data. In order to 1030 ensure that WebRTC can be used in different locations by different 1031 parties, it is important that standard Javascript APIs are developed 1032 to support applications from different voice service providers. 1033 Multiple parties will have similar capabilities, in order to ensure 1034 that all parties can build upon existing standards these need to be 1035 adaptable, and allow for permissionless innovation. 1037 Impacts: 1039 * Right to education 1041 * Freedom of expression 1043 * Freedom of assembly and association 1045 3.2.19. Outcome Transparency 1047 Question(s): Are the effects of your protocol fully and easily 1048 comprehensible, including with respect to unintended consequences of 1049 protocol choices? 1051 Explanation: Certain technical choices may have unintended 1052 consequences. 1054 Example: Lack of authenticity may lead to lack of integrity and 1055 negative externalities, of which spam is an example. Lack of data 1056 that could be used for billing and accounting can lead to so-called 1057 "free" arrangements which obscure the actual costs and distribution 1058 of the costs, for example the barter arrangements that are commonly 1059 used for Internet interconnection; and the commercial exploitation of 1060 personal data for targeted advertising which is the most common 1061 funding model for the so-called "free" services such as search 1062 engines and social networks. Other unexpected outcomes might not be 1063 technical, but rather architectural, social or economical. 1065 Impacts: 1067 * Freedom of expression 1069 * Privacy 1071 * Freedom of assembly and association 1073 * Access to information 1075 3.2.20. Remedy 1077 Question(s): Can your protocol facilitate a negatively impacted 1078 party's right to remedy without disproportionately impacting other 1079 parties' human rights, especially their right to privacy? 1081 Explanation: Access to remedy may help victims of human rights 1082 violations in seeking justice, or allow law enforcement agencies to 1083 identify a possible violator. However, such mechanisms may impede 1084 the exercise of the right to privacy. The former Special Rapporteur 1085 for Freedom of Expression has also argued that anonymity is an 1086 inherent part of freedom of expression [Kaye]. Considering the 1087 potential adverse impact of attribution on the right to privacy and 1088 freedom of expression, enabling attribution on an individual level is 1089 most likely not consistent with human rights. However, providing 1090 access to remedy by states and corporations is an inherent part of 1091 the UN Guiding Principles on Business and Human Rights [UNGP]. 1093 Impacts: 1095 * Right to remedy 1097 * Right to security 1099 * Right to privacy 1101 3.2.21. Misc. considerations 1103 Question(s): Have you considered potential negative consequences 1104 (individual or societal) that your protocol or document might have? 1106 Explanation: Publication of a particular RFC under a certain status 1107 has consequences. Publication as an Internet Standard as part of the 1108 Standards Track may signal to implementers that the specification has 1109 a certain level of maturity, operational experience, and consensus. 1110 Similarly, publication of a specification an experimental document as 1111 part of the non-standards track would signal to the community that 1112 the document "may be intended for eventual standardization but [may] 1113 not yet [be] ready" for wide deployment. The extent of the 1114 deployment, and consequently its overall impact on end-users, may 1115 depend on the document status presented in the RFC. See [BCP9] and 1116 updates to it for a fuller explanation. 1118 4. Document Status 1120 This RG document is currently documenting best practices and 1121 guidelines for human rights reviews of network protocols, 1122 architectures and other Internet-Drafts and RFCs. 1124 5. Acknowledgements 1126 Thanks to: 1128 * Corinne Cath-Speth for work on [RFC8280]. 1130 * Theresa Engelhard, Joe Hall, Avri Doria, Joey Salazar, Corinne 1131 Cath-Speth, Farzaneh Badii, Sandra Braman and the hrpc list for 1132 reviews and suggestions. 1134 * Individuals who conducted human rights reviews for their work and 1135 feedback: Amelia Andersdotter, Beatrice Martini, Karan Saini and 1136 Shivan Kaul Sahib. 1138 6. Security Considerations 1140 Article three of the Universal Declaration of Human Rights reads: 1141 "Everyone has the right to life, liberty and security of person.". 1142 This article underlines the importance of security and its 1143 interrelation with human life and liberty, but since human rights are 1144 indivisible, interrelated and interdependent, security is also 1145 closely linked to other human rights and freedoms. This document 1146 seeks to strengthen human rights, freedoms, and security by relating 1147 and translating these concepts to concepts and practices as they are 1148 used in Internet protocol and architecture development. The aim of 1149 this is to secure human right and thereby improve the susainability, 1150 usability, and effectiveness of the network. The document seeks to 1151 achieve this by providing guidelines as done in section three of this 1152 document. 1154 7. IANA Considerations 1156 This document has no actions for IANA. 1158 8. Research Group Information 1160 The discussion list for the IRTF Human Rights Protocol Considerations 1161 Research Group is located at the e-mail address hrpc@ietf.org 1162 (mailto:hrpc@ietf.org). Information on the group and information on 1163 how to subscribe to the list is at 1164 https://www.irtf.org/mailman/listinfo/hrpc 1165 (https://www.irtf.org/mailman/listinfo/hrpc) 1167 Archives of the list can be found at: https://www.irtf.org/mail- 1168 archive/web/hrpc/current/index.html (https://www.irtf.org/mail- 1169 archive/web/hrpc/current/index.html) 1171 9. Informative References 1173 [BCP72] IETF, "Guidelines for Writing RFC Text on Security 1174 Considerations", 2003, 1175 . 1177 [BCP9] Bradner, S. and IETF, "The Internet Standards Process -- 1178 Revision 3", 1996, 1179 . 1181 [Bless] Bless, R. and C. Orwat, "Values and Networks", 2015. 1183 [Brown] Brown, I. and M. Ziewitz, "A Prehistory of Internet 1184 Governance", Research Handbook on Governance of the 1185 Internet. Cheltenham, Edward Elgar. , 2013. 1187 [draft-irtf-pearg-censorship] 1188 Hall, J., Aaron, M., Adams, S., Jones, B., and N. 1189 Feamster, "A Survey of Worldwide Censorship Techniques", 1190 2020, 1191 . 1193 [draft-zuniga-mac-address-randomization] 1194 Zuniga, JC., Bernardos, CJ., and A. Andersdotter, "MAC 1195 address randomization", 2020, 1196 . 1198 [FIArch] "Future Internet Design Principles", January 2012, 1199 . 1202 [geekfeminism] 1203 Geek Feminism Wiki, "Pseudonymity", 2015, 1204 . 1206 [Hill2014] Hill, R., "Partial Catalog of Human Rights Related to ICT 1207 Activities", 2014, 1208 . 1210 [HTML5] W3C, "HTML5", 2014, . 1212 [HTTPS-REL] 1213 Meyer, E., "Securing Web Sites Made Them Less Accessible", 1214 2018, . 1217 [ICCPR] United Nations General Assembly, "International Covenant 1218 on Civil and Political Rights", 1976, 1219 . 1222 [ICESCR] United Nations General Assembly, "International Covenant 1223 on Economic, Social and Cultural Rights", 1966, 1224 . 1227 [IRP] Internet Rights and Principles Dynamic Coalition, "10 1228 Internet Rights & Principles", 2014, 1229 . 1233 [Kaye] Kaye, D., "The use of encryption and anonymity in digital 1234 communications", 2015, 1235 . 1238 [newegg] Mullin, J., "Newegg on trial: Mystery company TQP rewrites 1239 the history of encryption", 2013, . 1243 [notewell] IETF, "Note Well", 2015, 1244 . 1246 [patentpolicy] 1247 W3C, "W3C Patent Policy", 2004, 1248 . 1250 [Penney] Penney, J., "Chilling Effects: Online Surveillance and 1251 Wikipedia Use", 2016, . 1254 [Pouwelse] Pouwelse, Ed, J., "Media without censorship", 2012, 1255 . 1258 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1259 RFC 793, DOI 10.17487/RFC0793, September 1981, 1260 . 1262 [RFC1035] Mockapetris, P., "Domain names - implementation and 1263 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1264 November 1987, . 1266 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 1267 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 1268 . 1270 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 1271 Technology and the Internet", BCP 200, RFC 1984, 1272 DOI 10.17487/RFC1984, August 1996, 1273 . 1275 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1276 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 1277 . 1279 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1280 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 1281 January 1998, . 1283 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 1284 Engineering Task Force Standard Protocols", BCP 61, 1285 RFC 3365, DOI 10.17487/RFC3365, August 2002, 1286 . 1288 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 1289 the Middle and the Future of End-to-End: Reflections on 1290 the Evolution of the Internet Architecture", RFC 3724, 1291 DOI 10.17487/RFC3724, March 2004, 1292 . 1294 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 1295 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 1296 . 1298 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1299 Rose, "DNS Security Introduction and Requirements", 1300 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1301 . 1303 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 1304 DOI 10.17487/RFC4101, June 2005, 1305 . 1307 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1308 Extensions for Stateless Address Autoconfiguration in 1309 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1310 . 1312 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1313 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1314 . 1316 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1317 DOI 10.17487/RFC5321, October 2008, 1318 . 1320 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1321 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 1322 September 2009, . 1324 [RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. 1325 Van Lieu, "Comcast's Web Notification System Design", 1326 RFC 6108, DOI 10.17487/RFC6108, February 2011, 1327 . 1329 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 1330 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, 1331 . 1333 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 1334 Internationalization in the IETF", BCP 166, RFC 6365, 1335 DOI 10.17487/RFC6365, September 2011, 1336 . 1338 [RFC6701] Farrel, A. and P. Resnick, "Sanctions Available for 1339 Application to Violators of IETF IPR Policy", RFC 6701, 1340 DOI 10.17487/RFC6701, August 2012, 1341 . 1343 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1344 Morris, J., Hansen, M., and R. Smith, "Privacy 1345 Considerations for Internet Protocols", RFC 6973, 1346 DOI 10.17487/RFC6973, July 2013, 1347 . 1349 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1350 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1351 2014, . 1353 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1354 Trammell, B., Huitema, C., and D. Borkmann, 1355 "Confidentiality in the Face of Pervasive Surveillance: A 1356 Threat Model and Problem Statement", RFC 7624, 1357 DOI 10.17487/RFC7624, August 2015, 1358 . 1360 [RFC7725] Bray, T., "An HTTP Status Code to Report Legal Obstacles", 1361 RFC 7725, DOI 10.17487/RFC7725, February 2016, 1362 . 1364 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 1365 Profiles for DHCP Clients", RFC 7844, 1366 DOI 10.17487/RFC7844, May 2016, 1367 . 1369 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1370 and P. Hoffman, "Specification for DNS over Transport 1371 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1372 2016, . 1374 [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property 1375 Rights in IETF Technology", BCP 79, RFC 8179, 1376 DOI 10.17487/RFC8179, May 2017, 1377 . 1379 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 1380 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 1381 October 2017, . 1383 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1384 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1385 . 1387 [RFC8980] Arkko, J. and T. Hardie, "Report from the IAB Workshop on 1388 Design Expectations vs. Deployment Reality in Protocol 1389 Development", RFC 8980, DOI 10.17487/RFC8980, February 1390 2021, . 1392 [Saltzer] Saltzer, J.H., Reed, D.P., and D.D. Clark, "End-to-End 1393 Arguments in System Design", ACM TOCS, Vol 2, Number 4, 1394 November 1984, pp 277-288. , 1984. 1396 [UDHR] United Nations General Assembly, "The Universal 1397 Declaration of Human Rights", 1948, 1398 . 1400 [UNGP] United Nations, "United Nations Guiding Principles on 1401 Business and Human Rights", 2011, 1402 . 1405 [UNHRC2016] 1406 United Nations Human Rights Council, "UN Human Rights 1407 Council Resolution "The promotion, protection and 1408 enjoyment of human rights on the Internet" (A/HRC/32/ 1409 L.20)", 2016, . 1413 [W3CAccessibility] 1414 W3C, "Accessibility", 2015, 1415 . 1417 [W3Ci18nDef] 1418 W3C, "Localization vs. Internationalization", 2010, 1419 . 1421 [Zittrain] Zittrain, J., "The Future of the Internet - And How to 1422 Stop It", Yale University Press , 2008, 1423 . 1426 Authors' Addresses 1428 Gurshabad Grover 1429 Centre for Internet and Society 1431 Email: gurshabad@cis-india.org 1433 Niels ten Oever 1434 University of Amsterdam 1436 Email: mail@nielstenoever.net