idnits 2.17.1 draft-irtf-hrpc-research-06.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]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 25, 2016) is 2709 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 3193 -- Looks like a reference, but probably isn't: '2' on line 3195 -- Looks like a reference, but probably isn't: '3' on line 3197 == Unused Reference: 'RFC4033' is defined on line 2876, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 226 (Obsoleted by RFC 247) -- Obsolete informational reference (is this intentional?): RFC 760 (Obsoleted by RFC 791) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1631 (Obsoleted by RFC 3022) -- Obsolete informational reference (is this intentional?): RFC 1766 (Obsoleted by RFC 3066, RFC 3282) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3536 (Obsoleted by RFC 6365) -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Human Rights Protocol Considerations Research Group N. ten Oever 3 Internet-Draft ARTICLE 19 4 Intended status: Informational C. Cath 5 Expires: May 29, 2017 Oxford Internet Institute 6 November 25, 2016 8 Research into Human Rights Protocol Considerations 9 draft-irtf-hrpc-research-06 11 Abstract 13 This document provides a proposal for a vocabulary to discuss the 14 relation between human rights and Internet protocols, an overview of 15 the discussion in technical and academic literature and communities, 16 a proposal for the mapping of the relation between human rights and 17 technical concepts, and a proposal for guidelines for human rights 18 considerations, similar to the work done on the guidelines for 19 privacy considerations [RFC6973]. 21 If you want to see how to apply this work to your own, you can 22 directly go to Section 3. The rest of the document explains the 23 background of the guidelines and how they were developed. 25 This document is not an Internet Standards Track specification; it is 26 published for informational purposes. 28 This document is a product of the Internet Research Task Force 29 (IRTF). The IRTF publishes the results of Internet-related research 30 and development activities. This documents aims to be a consensus 31 document of the Human Rights Protocol Consideration Research Group of 32 the Internet Research Task Force (IRTF). 34 Discussion of this draft at: hrpc@irtf.org // 35 https://www.irtf.org/mailman/listinfo/hrpc 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on May 29, 2017. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Vocabulary used . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Model for developing human rights protocol considerations . . 9 74 3.1. Human rights threats . . . . . . . . . . . . . . . . . . 10 75 3.1.1. Guidelines for human rights considerations . . . . . 11 76 4. Research Questions . . . . . . . . . . . . . . . . . . . . . 25 77 5. Literature and Discussion Review . . . . . . . . . . . . . . 25 78 6. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 28 79 6.1. Data Sources . . . . . . . . . . . . . . . . . . . . . . 29 80 6.1.1. Discourse analysis of RFCs . . . . . . . . . . . . . 29 81 6.1.2. Interviews with members of the IETF community . . . . 30 82 6.1.3. Participant observation in Working Groups . . . . . . 30 83 6.2. Data analysis strategies . . . . . . . . . . . . . . . . 30 84 6.2.1. Identifying qualities of technical concepts that 85 relate to human rights . . . . . . . . . . . . . . . 30 86 6.2.2. Translating human rights to technical terms . . . . . 32 87 6.2.3. Map cases of protocols that adversely impact human 88 rights or are enablers thereof . . . . . . . . . . . 34 89 7. Document Status . . . . . . . . . . . . . . . . . . . . . . . 52 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 53 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 93 11. Research Group Information . . . . . . . . . . . . . . . . . 53 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 95 12.1. Informative References . . . . . . . . . . . . . . . . . 53 96 12.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 68 98 1. Introduction 100 "There's a freedom about the Internet: As long as we accept the 101 rules of sending packets around, we can send packets containing 102 anything to anywhere." 104 [Berners-Lee] 106 "The Internet isn't value-neutral, and neither is the IETF." 108 [RFC3935] 110 The evergrowing interconnectedness of Internet and society increases 111 the impact of the Internet on the lives of individuals. Because of 112 this, the design and development of the Internet infrastructure also 113 has a growing impact on society. This has led to an broad 114 recognition that human rights [UDHR] [ICCPR] [ICESCR] have a role in 115 the development and management of the Internet [HRC2012] [UNGA2013] 116 [NETmundial]. It has also been argued that the Internet should be 117 strengthened as a human rights enabling environment [Brown]. 119 This document aims to expose the relation between protocols and human 120 rights, propose possible guidelines to protect the Internet as a 121 human-rights-enabling environment in future protocol development, in 122 a manner similar to the work done for Privacy Considerations in 123 [RFC6973], and to increase the awareness in both the human rights 124 community and the technical community on the importance of the 125 technical workings of the Internet and its impact on human rights. 127 Open, secure and reliable connectivity is necessary (although not 128 sufficient) to excercise human rights such as freedom of expression 129 and freedom of association [FOC], as defined in the Universal 130 Declaration of Human Rights [UDHR]. The purpose of the Internet to 131 be a global network of networks that provides unfettered connectivity 132 to all users and for any content [RFC1958]. This objective of 133 stimulating global connectivity contributes to the Internet's role as 134 an enabler of human rights. Next to that, the strong commitment to 135 security [RFC1984] [RFC3365] and privacy [RFC6973] [RFC7258] in the 136 Internet's architectural design contribute to the strengthening of 137 the Internet as a human rights enabling environment. One could even 138 argue that the Internet is not only an enabler of human rights, but 139 that human rights lie at the basis of, and are ingrained in, the 140 architecture of the networks that make up the Internet. Internet 141 connectivity increases the capacity for individuals to exercise their 142 rights, the core of the Internet, its architectural design is 143 therefore closely intertwined with the human rights framework 144 [CathFloridi]. The quintessential link between the Internet's 145 infrastructure and human rights has been argued by many. [Bless] for 146 instance argues that, 'to a certain extent, the Internet and its 147 protocols have already facilitated the realization of human rights, 148 e.g., the freedom of assembly and expression. In contrast, measures 149 of censorship and pervasive surveillance violate fundamental human 150 rights.' [Denardis15] argues that 'Since the first hints of Internet 151 commercialization and internationalization, the IETF has supported 152 strong security in protocol design and has sometimes served as a 153 force resisting protocol-enabled surveillance features.' By doing 154 so, the IETF enabled the manifestation of the right to privacy, 155 through the Internet's infrastructure. Additionally, access to 156 information gives people access to knowledge that enables them to 157 help satisfy other human rights, as such the Internet increasingly 158 becoming a pre-condition for human rights rather than a supplement. 160 Human rights can be in conflict with each other, such as the right to 161 freedom of expression and the right to privacy. In such as case the 162 different affected rights need to be balanced. In order to do this 163 it is crucial that the rights impacts are clearly documented in order 164 to mitigate the potential harm in a proportional way. Making that 165 process tangible and practical for protocol developers is what this 166 research aims to ultimately contribute to. Technology can never be 167 fully equated with a human right. Whereas a specific technology 168 might be strong enabler of a specific human right, it might have an 169 adverse impact on another human right. In this case decisions on 170 design and deployment need to take this into account. 172 The open nature of the initial technical design (open standards, open 173 source, etc) fostered freedom of communication as a core value, 174 everyone could join and everyone could submit code. However as the 175 scale and the commercialization of the Internet grew, topics like 176 access, rights and connectivity are forced to compete with other 177 values. Therefore, important human rights enabling characteristics 178 of the Internet might be degraded if they're not properly defined, 179 described and protected as such. And, the other way around, not 180 protecting human right enabling characteristics could also result in 181 (partial) loss of functionality and connectivity, and other inherent 182 parts of the Internet's architecture of networks. New protocols, 183 particularly those that upgrade the core infrastructure of the 184 network, should be designed to continue to enable fundamental human 185 rights. 187 The IETF has produced guidelines and procedures to ensure and 188 galvanize the privacy and security of the network in protocol 189 development. This document aims to explore the possibility of the 190 development of similar procedures for guidelines for human rights 191 considerations to ensure that protocols developed in the IETF do not 192 have an adverse impact on the realization of human rights on the 193 Internet. By carefully considering the answers to the questions 194 posed in the considerations Section 3 part of this document, document 195 authors should be able to produce a comprehensive analysis that can 196 serve as the basis for discussion on whether the protocol adequately 197 protects against human rights threats. 199 2. Vocabulary used 201 In the discussion of human rights and Internet architecture concepts 202 developed in computer science, networking, law, policy-making and 203 advocacy are coming together [Dutton],[Kaye],[Franklin], [RFC1958]. 204 The same concepts might have a very different meaning and 205 implications in other areas of expertise. In order to foster a 206 constructive interdisciplinary debate, and minimize differences in 207 interpretation, the following glossary is provided, building as much 208 as possible on existing definitions, and where these were not 209 available definitions have been developed. 211 Accessibility Full Internet Connectivity as described in [RFC4084] 212 to provide unfettered access to the Internet 214 The design of protocols, services or implementation that provide 215 an enabling environment for people with disabilities. 217 The ability to receive information available on the Internet 219 Anonymity The condition of an identity being unknown or concealed. 220 [RFC4949] 222 Anonymous A state of an individual in which an observer or attacker 223 cannot identify the individual within a set of other individuals 224 (the anonymity set). [RFC6973] 226 Authenticity The fact that the data does indeed come from the source 227 it claims to come from. (It is strongly linked with Integrity, 228 see below). 230 Censorship resistance Methods and measures to mitigate Internet 231 censorship. 233 Confidentiality The non-disclosure of information to any unintended 234 person or host or party [RFC4949]. 236 Connectivity The extent to which a device or network is able to 237 reach other devices or networks to exchange data. The Internet is 238 the tool for providing global connectivity [RFC1958]. Different 239 types of connectivity are further specified in [RFC4084]. 241 Content agnosticism Treating network traffic identically regardless 242 of content. 244 Decentralized Implementation or deployment of standards, protocols 245 or systems without one single point of control. 247 End-to-End The principal of extending characteristics of a protocol 248 or system as far as possible within the system. This means that 249 intermediaries in the network should not modify messages but 250 simply route them to their desired end-points. Functionality 251 should be expanded at the end-points to ensure that the network 252 interconnects rather than controls. For example, end-to-end 253 instant message encryption would conceal communications from one 254 user's instant messaging application through any intermediate 255 devices and servers all the way to the recipient's instant 256 messaging application. If the message was decrypted at any 257 intermediate point-for example at a service provider-then the 258 property of end-to-end encryption would not be present. 260 One of the key architectural guidelines of the Internet is the 261 end-to-end principle in the papers by Saltzer, Reed, and Clark 262 [Saltzer] [Clark]. The end-to-end principle was originally 263 articulated as a question of where best not to put functions in a 264 communication system. Yet, in the ensuing years, it has evolved 265 to address concerns of maintaining openness, increasing 266 reliability and robustness, and preserving the properties of user 267 choice and ease of new service development as discussed by 268 Blumenthal and Clark in [Blumenthal]; concerns that were not part 269 of the original articulation of the end-to-end principle. 270 [RFC3724] 272 Federation The possibility of connecting autonomous and possibly 273 centralized systems into single system without a central 274 authority. 276 Heterogeneity The Internet is characterized by heterogeneity on many 277 levels: devices and nodes, router scheduling algorithms and queue 278 management mechanisms, routing protocols, levels of multiplexing, 279 protocol versions and implementations, underlying link layers 280 (e.g., point-to-point, multi-access links, wireless, FDDI, etc.), 281 in the traffic mix and in the levels of congestion at different 282 times and places. Moreover, as the Internet is composed of 283 independent organizations and Internet service providers, each 284 with their own separate policy concerns,there is a large 285 heterogeneity of administrative domains and pricing structures. 286 As a result, the heterogeneity principle proposed in [RFC1958] 287 needs to be supported by design. [FIArch] 289 Integrity Maintenance and assurance of the accuracy and consistency 290 of data to ensure it has not been (intentionally or 291 unintentionally) altered [RFC4949]. 293 Internet censorship Internet censorship is the intentional 294 suppression of information originating, flowing or stored on 295 systems connected to the Internet where that information is 296 relevant for decision making to some entity. [Elahi] 298 Interoperable A property of a documented standard or protocol which 299 allows different independent implementations to work with each 300 other without any restricted access or functionality. 302 Internationalization (i18n) The practice of making protocols, 303 standards, and implementations usable in different languages and 304 scripts (see Localization). 306 "In the IETF, "internationalization" means to add or improve the 307 handling of non-ASCII text in a protocol" [RFC6365]. A different 308 perspective, more appropriate to protocols that are designed for 309 global use from the beginning, is the definition used by W3C: 311 "Internationalization is the design and development of a product, 312 application or document content that enables easy localization for 313 target audiences that vary in culture, region, or language." 314 [W3Ci18nDef] 316 Many protocols that handle text only handle one charset (US- 317 ASCII), or leave the question of encoding up to local guesswork 318 (which leads, of course, to interoperability problems) [RFC3536]. 319 If multiple charsets are permitted, they must be explicitly 320 identified [RFC2277]. Adding non-ASCII text to a protocol allows 321 the protocol to handle more scripts, hopefully all of the ones 322 useful in the world. In today's world, that is normally best 323 accomplished by allowing Unicode encoded in UTF-8 only, thereby 324 shifting conversion issues away from ad hoc choices. 326 Localization (l10n) The practice of translating an implementation to 327 make it functional in a specific language or for users in a 328 specific locale (see Internationalization). 330 (cf [RFC6365]): The process of adapting an internationalized 331 application platform or application to a specific cultural 332 environment. In localization, the same semantics are preserved 333 while the syntax may be changed. [FRAMEWORK] 335 Localization is the act of tailoring an application for a 336 different language or script or culture. Some internationalized 337 applications can handle a wide variety of languages. Typical 338 users only understand a small number of languages, so the program 339 must be tailored to interact with users in just the languages they 340 know. The major work of localization is translating the user 341 interface and documentation. Localization involves not only 342 changing the language interaction, but also other relevant changes 343 such as display of numbers, dates, currency, and so on. The 344 better internationalized an application is, the easier it is to 345 localize it for a particular language and character encoding 346 scheme. 348 Open standards Conform [RFC2606]: Various national and international 349 standards bodies, such as ANSI, ISO, IEEE, and ITU-T, develop a 350 variety of protocol and service specifications that are similar to 351 Technical Specifications defined here. National and international 352 groups also publish "implementors' agreements" that are analogous 353 to Applicability Statements, capturing a body of implementation- 354 specific detail concerned with the practical application of their 355 standards. All of these are considered to be "open external 356 standards" for the purposes of the Internet Standards Process. 358 Openness The quality of the unfiltered Internet that allows for free 359 access to other hosts. 361 Absence of centralized points of control - a feature that is 362 assumed to make it easy for new users to join and new uses to 363 unfold [Brown]. 365 Permissionless innovation The freedom and ability to freely create 366 and deploy new protocols on top of the communications constructs 367 that currently exist. 369 Privacy The right of an entity (normally a person), acting in its 370 own behalf, to determine the degree to which it will interact with 371 its environment, including the degree to which the entity is 372 willing to share its personal information with others. [RFC4949] 374 The right of individuals to control or influence what information 375 related to them may be collected and stored and by whom and to 376 whom that information may be disclosed. 378 Privacy is a broad concept relating to the protection of 379 individual or group autonomy and the relationship between an 380 individual or group and society, including government, companies 381 and private individuals. It is often summarized as "the right to 382 be left alone" but it encompasses a wide range of rights including 383 protections from intrusions into family and home life, control of 384 sexual and reproductive rights, and communications secrecy. It is 385 commonly recognized as a core right that underpins human dignity 386 and other values such as freedom of association and freedom of 387 speech. 389 The right to privacy is also recognized in nearly every national 390 constitution and in most international human rights treaties. It 391 has been adjudicated upon both by international and regional 392 bodies. The right to privacy is also legally protected at the 393 national level through provisions in civil and/or criminal codes. 395 Reliable Reliability ensures that a protocol will execute its 396 function consistently as described and function without unexpected 397 result. A system that is reliable degenerates gracefully and will 398 have a documented way to announce degradation. It also has 399 mechanisms to recover from failure gracefully, and if applicable, 400 allow for partial healing [dict]. 402 Resilience The maintaining of dependability and performance in the 403 face of unanticipated changes and circumstances [Meyer]. 405 Robustness The resistance of protocols and their implementations to 406 errors, and to involuntary, legal or malicious attempts to disrupt 407 its mode of operations. [RFC0760] [RFC0791] [RFC0793] [RFC1122]. 408 Or framed more positively, a system can provide functionality 409 consistently and without errors despite involuntary, legal or 410 malicious attempts to disrupt its mode of operations. 412 Scalable The ability to handle increased or decreased workloads 413 predictably within defined expectations. There should be a clear 414 definition of its scope and applicability. The limits of a 415 systems scalability should be defined. 417 Strong encryption / cryptography Used to describe a cryptographic 418 algorithm that would require a large amount of computational power 419 to defeat it. [RFC4949] 421 Connectivity The combination of the end-to-end principle, 422 interoperability, resilience, reliability and robustness are the 423 enableing factors that result in connectivity to and on the 424 Internet. 426 3. Model for developing human rights protocol considerations 428 This section outlines a set of human rights protocol considerations 429 for protocol developers. It provides questions engineers should ask 430 themselves when developing or improving protocols if they want to 431 understand their human rights impact. It should however be noted 432 that the impact of a protocol cannot solely be deduced from its 433 design, but its usage and implementation should also be studied to 434 form a full protocol human rights impact assessment. 436 The questions are based on the research performed by the hrpc 437 research group which has been documented after these considerations. 438 The research establishes that human rights relate to standards and 439 protocols and offers a common vocabulary of technical concepts that 440 impact human rights and how these technical concept can be combined 441 to ensure that the Internet remains an enabling environment for human 442 rights. With this the contours of a model for developing human 443 rights protocol considerations has taken shape. 445 3.1. Human rights threats 447 Human rights threats on the Internet come in a myriad of forms. 448 Protocols and standards can harm or enable the right to freedom of 449 expression, right to non-discrimination, right to equal protection, 450 right to participate in cultural life, arts and science, right to 451 freedom of assembly and association, and the right to security. An 452 end-user who is denied access to certain services, data or websites 453 may be unable to disclose vital information about the malpractices of 454 a government or other authority. A person whose communications are 455 monitored may be prevented from exercising their right to freedom of 456 association or participate in political processes [Penney]. In a 457 worst-case scenario, protocols that leak information can lead to 458 physical danger. A realistic example to consider is when opposition 459 group members (or those identified as such) in totalitarian regimes 460 are subjected to torture on the basis of information gathered by the 461 regime through information leakage in protocols. 463 This sections details several 'common' threats to human rights, 464 indicating how each of these can lead to human rights violations/ 465 harms and present several examples of how these threats to human 466 rights materialize on the Internet. This threat modeling is inspired 467 by [RFC6973] Privacy Considerations for Internet Protocols, which is 468 based on the security threat analysis. This method is by no means a 469 perfect solution for assessing human rights risks in Internet 470 protocols and systems; it is however the best approach currently 471 available. Certain specific human rights threats are indirectly 472 considered in Internet protocols as part of the security 473 considerations [BCP72], but privacy guidelines [RFC6973] or reviews, 474 let alone human rights impact assessments of protocols are not 475 standardized or implemented. 477 Many threats, enablers and risks are linked to different rights. 478 This is not unsurprising if one takes into account that human rights 479 are interrelated, interdependent and indivisible. Here however we're 480 not discussing all human rights because not all human rights are 481 relevant to ICTs in general and protocols and standards in particular 482 [Bless]. This is by no means an attempt to exclude specific rights 483 or proritize some rights over others. If other rights seem relevant, 484 please contact the authors. 486 3.1.1. Guidelines for human rights considerations 488 This section provides guidance for document authors in the form of a 489 questionnaire about protocols and their (potential) impact. The 490 questionnaire may be useful at any point in the design process, 491 particularly after document authors have developed a high-level 492 protocol model as described in [RFC4101]. 494 Protocols and Internet Standard might benefit from a documented 495 discussion of potential human rights risks arising from potential 496 misapplications of the protocol or technology described in the RFC. 497 This might be coupled with an Applicability Statement for that RFC. 499 Note that the guidance provided in this section does not recommend 500 specific practices. The range of protocols developed in the IETF is 501 too broad to make recommendations about particular uses of data or 502 how human rights might be balanced against other design goals. 503 However, by carefully considering the answers to the following 504 questions, document authors should be able to produce a comprehensive 505 analysis that can serve as the basis for discussion on whether the 506 protocol adequately protects against specific human rights threats. 507 This guidance is meant to help the thought process of a human rights 508 analysis; it does not provide specific directions for how to write a 509 human rights protocol considerations section (following the example 510 set in [RFC6973]), and the addition of a human rights protocol 511 considerations section has also not yet been proposed. In 512 considering these questions, authors will need to be aware of the 513 potential of technical advances or the passage of time to undermine 514 protections. In general, considerations of rights are likely to be 515 more effective if they are considered given a purpose and specific 516 use cases, rather than as abstract absolute goals. 518 3.1.1.1. Technical concepts as they relate to human rights 520 3.1.1.1.1. Connectivity 522 Question(s): Does your protocol add application-specific functions to 523 intermediary nodes? Could this functionality be added to end nodes 524 instead of intermediary nodes? 526 Explanation: The end-to-end principle [Saltzer] which aims to extend 527 characteristics of a protocol or system as far as possible within the 528 system, or in other words 'the intelligence is end to end rather than 529 hidden in the network' [RFC1958]. Middleboxes (which can be Content 530 Delivery Networks, Firewalls, NATs or other intermediary nodes that 531 provide other 'services' than routing), and the protocols guiding 532 them, influence individuals' ability to communicate online freely and 533 privately. The potential for abuse and intentional and unintentional 534 censoring and limiting permissionless innovation, and thus ultimately 535 the impact of middleboxes on the Internet as a place of unfiltered, 536 unmonitored freedom of speech, is real. 538 Example: End-to-end instant message encryption would conceal the 539 content of communications from one user's instant messaging 540 application through any intermediate devices and servers all the way 541 to the recipient's instant messaging application. If the message was 542 decrypted at any intermediate point-for example at a service 543 provider-then the property of end-to-end encryption would not be 544 present. 546 Impacts: 548 - Right to freedom of expression 550 - Right to freedom of assembly and association 552 3.1.1.1.2. Privacy 554 Question(s): Did you have a look at the Guidelines in the Privacy 555 Considerations for Internet Protocols [RFC6973] section 7? Could 556 your protocol in any way impact the confidentiality of protocol 557 metadata? Could your protocol counter traffic analysis? Could you 558 protocol improve data minimization? Does your document identify 559 potentially sensitive logged data by your protocol and/or for how 560 long that needs to be retained for technical reasons? 562 Explanation: Privacy refers to the right of an entity (normally a 563 person), acting in its own behalf, to determine the degree to which 564 it will interact with its environment, including the degree to which 565 the entity is willing to share its personal information with others. 566 [RFC4949]. If a protocol provides insufficient privacy it may stifle 567 speech as users self-censor for fear of surveillance, or find 568 themselves unable to express themselves freely. 570 Example: See [RFC6973] 572 Impacts: 574 - Right to freedom of expression 576 - Right to non-discrimination 578 3.1.1.1.3. Content agnosticism 580 Question(s): If your protocol impacts packet handling, does it look 581 at the packet payload? Is it making decisions based on the payload 582 of the packet? Does your protocol prioritize certain content or 583 services over others in the routing process ? Is the protocol 584 transparent about the priotization that is made (if any)? 586 Explanation: Content agnosticism refers to the notion that network 587 traffic is treated identically regardless of payload, with some 588 exception where it comes to effective traffic handling, for instance 589 where it comes to delay tolerant or delay sensitive packets, based on 590 the header. 592 Example: Content agnosticism prevents payload-based discrimination 593 against packets. This is important because changes to this principle 594 can lead to a two-tiered Internet, where certain packets are 595 prioritized over others on the basis of their content. Effectively 596 this would mean that although all users are entitled to receive their 597 packets at a certain speed, some users become more equal than others. 599 Impacts: 601 - Right to freedom of expression 603 - Right to non-discrimination 605 - Right to equal protection 607 3.1.1.1.4. Security 609 Question(s): Did you have a look at Guidelines for Writing RFC Text 610 on Security Considerations [BCP72]? Have you found any attacks that 611 are out of scope for your protocol? Would these attacks be pertinent 612 to the human rights enabling features of the Internet (as described 613 throughout this document)? 615 Explanation: Most people speak of security as if it were a single 616 monolithic property of a protocol or system, however, upon 617 reflection; one realizes that it is clearly not true. Rather, 618 security is a series of related but somewhat independent properties. 619 Not all of these properties are required for every application. 620 Since communications are carried out by systems and access to systems 621 is through communications channels, these goals obviously interlock, 622 but they can also be independently provided [BCP72]. 624 Example: See [BCP72]. 626 Impacts: 628 - Right to freedom of expression 630 - Right to freedom of assembly and association 632 - Right to non discrimination 634 3.1.1.1.5. Internationalization 636 Question(s): Does your protocol have text strings that have to be 637 understood or entered by humans? Does your protocol allow Unicode 638 encoded in UTF-8 only? If other character sets or encodings are 639 allowed, does your protocol mandate a proper tagging of the charset? 640 Did you have a look at [RFC6365]? 642 Explanation: Internationalization refers to the practice of making 643 protocols, standards, and implementations usable in different 644 languages and scripts (see Localization). In the IETF, 645 internationalization means to add or improve the handling of non- 646 ASCII text in a protocol. [RFC6365] A different perspective, more 647 appropriate to protocols that are designed for global use from the 648 beginning, is the definition used by W3C: 650 "Internationalization is the design and development of a 651 product, application or document content that enables easy 652 localization for target audiences that vary in culture, region, 653 or language." {{W3Ci18nDef}} 655 Many protocols that handle text only handle one charset (US-ASCII), 656 or leave the question of what CCS and encoding are used up to local 657 guesswork (which leads, of course, to interoperability problems). If 658 multiple charsets are permitted, they must be explicitly identified 659 [RFC2277]. Adding non-ASCII text to a protocol allows the protocol 660 to handle more scripts, hopefully representing users across the 661 world. In today's world, that is normally best accomplished by 662 allowing Unicode encoded in UTF-8 only. 664 In aforementioned IETF documents internationalization is aimed at 665 user-facing strings. The authors believe that this should also be 666 extended to protocols themselves because if the Internet wants to be 667 a global network of networks, the protocols should not only work in 668 English and non-latin characters. 670 Example: See localization 672 Impacts: 674 - Right to freedom of expression 676 - Right to political participation 678 - Right to participate in cultural life, arts and science 680 - Right to political participation 682 3.1.1.1.6. Censorship resistance 684 Question(s): Does this protocol introduce new identifiers or reuse 685 existing identifiers (e.g. MAC addresses) that might be associated 686 with persons or content? Does your protocol make it apparent or 687 transparent when filtering happens? Can your protocol contribute to 688 filtering in a way it could be implemented to censor data or 689 services? Could this be designed to ensure this doesn't happen? 691 Explanation: Censorship resistance refers to the methods and measures 692 to prevent Internet censorship. 694 Example: Identifiers of content exposed within a protocol might be 695 used to facilitate censorship, as in the case of IP based censorship, 696 which affects protocols like HTTP. Filtering can be made apparent by 697 the use of status code 451 - which allows server operators to operate 698 with greater transparency in circumstances where issues of law or 699 public policy affect their operation [Bray]. 701 Impacts: 703 - Right to freedom of expression 705 - Right to political participation 707 - Right to participate in cultural life, arts and science 709 - Right to freedom of assembly and association 711 3.1.1.1.7. Open Standards 713 Question(s): Is your protocol fully documented in a way that it could 714 be easily implemented, improved, built upon and/or further developed? 715 Do you depend on proprietary code for the implementation, running or 716 further development of your protocol? Does your protocol favor a 717 particular proprietary specification over technically equivalent and 718 competing specification(s), for instance by making any incorporated 719 vendor specification "required" or "recommended" [RFC2026]? Do you 720 normatively reference another standard that is not available without 721 cost? Are you aware of any patents that would prevent your standard 722 from being fully implemented [RFC3979] [RFC6701]? 724 Explanation: The Internet was able to developed into the global 725 network of networks because of the existence of open, non-proprietary 726 standards [Zittrain]. They are crucial for enabling 727 interoperability. Yet, open standards are not explicitly defined 728 within the IETF. On the subject, [RFC2606] states: Various national 729 and international standards bodies, such as ANSI, ISO, IEEE, and ITU- 730 T, develop a variety of protocol and service specifications that are 731 similar to Technical Specifications defined at the IETF. National 732 and international groups also publish "implementors' agreements" that 733 are analogous to Applicability Statements, capturing a body of 734 implementation-specific detail concerned with the practical 735 application of their standards. All of these are considered to be 736 "open external standards" for the purposes of the Internet Standards 737 Process. Similarly, [RFC3935] does not define open standards but 738 does emphasize the importance of 'open process': any interested 739 person can participate in the work, know what is being decided, and 740 make his or her voice heard on the issue. Part of this principle is 741 the IETF's commitment to making its documents, WG mailing lists, 742 attendance lists, and meeting minutes publicly available on the 743 Internet. 745 Open standards are important as they allow for permissionless 746 innovation, which is important to maintain the freedom and ability to 747 freely create and deploy new protocols on top of the communications 748 constructs that currently exist. It is at the heart of the Internet 749 as we know it, and to maintain its fundamentally open nature, we need 750 to be mindful of the need for developing open standards. 752 All standards that need to be normatively implemented should be 753 freely available and with reasonable protection for patent 754 infringement claims, so it can also be implemented in open source or 755 free software. Patents have often held back open standardization or 756 been used against those deploying open standards, particularly in the 757 domain of cryptography [newegg]. Patents in open standards or in 758 normative references to other standards should have a patent 759 disclosure [notewell], royalty-free licensing [patentpolicy], or some 760 other form of reasonable protection. Reasonable patent protection 761 should includes but is not limited to cryptographic primitives. 763 Example: [RFC6108] describes a system for providing critical end-user 764 notifications to web browsers, which has been deployed by Comcast, an 765 Internet Service Provider (ISP). Such a notification system is being 766 used to provide near-immediate notifications to customers, such as to 767 warn them that their traffic exhibits patterns that are indicative of 768 malware or virus infection. There are other proprietary systems that 769 can perform such notifications, but those systems utilize Deep Packet 770 Inspection (DPI) technology. In contrast to DPI, this document 771 describes a system that does not rely upon DPI, and is instead based 772 in open IETF standards and open source applications. 774 Impacts: 776 - Right to freedom of expression 778 - Right to participate in cultural life, arts and science 780 3.1.1.1.8. Heterogeneity Support 782 Question(s): Does your protocol support heterogeneity by design? 783 Does your protocol allow for multiple types of hardware? Does your 784 protocol allow for multiple types of application protocols? Is your 785 protocol liberal in what it receives and handles? Will it remain 786 usable and open if the context changes? Does your protocol allow 787 there to be well-defined extension points? Do these extension points 788 to allow open innovation possibly have security and privacy 789 ramifications, and if so,how can these be dealt with? 791 Explanation: The Internet is characterized by heterogeneity on many 792 levels: devices and nodes, router scheduling algorithms and queue 793 management mechanisms, routing protocols, levels of multiplexing, 794 protocol versions and implementations, underlying link layers (e.g., 795 point-to-point, multi-access links, wireless, FDDI, etc.), in the 796 traffic mix and in the levels of congestion at different times and 797 places. Moreover, as the Internet is composed of autonomous 798 organizations and Internet service providers, each with their own 799 separate policy concerns, there is a large heterogeneity of 800 administrative domains and pricing structures. As a result, the 801 heterogeneity principle proposed in [RFC1958] needs to be supported 802 by design [FIArch]. 804 Example: Heterogeneity is inevitable and needs be supported by 805 design. Multiple types of hardware must be allowed for, e.g. 806 transmission speeds differing by at least 7 orders of magnitude, 807 various computer word lengths, and hosts ranging from memory-starved 808 microprocessors up to massively parallel supercomputers. Multiple 809 types of application protocol must be allowed for, ranging from the 810 simplest such as remote login up to the most complex such as 811 distributed databases [RFC1958]. 813 Impacts: 815 - Right to freedom of expression 816 - Right to security 818 3.1.1.1.9. Anonymity 820 Question(s): Did you have a look at the Privacy Considerations for 821 Internet Protocols [RFC6973], especially section 6.1.1 ? 823 Explanation: Anonymity refers to the condition of an identity being 824 unknown or concealed [RFC4949]. Even though full anonymity is hard 825 to achieve, it is non-binary concept. Making pervasive monitoring 826 and tracking harder is important for many users as well as for the 827 IETF [RFC7258]. Achieving a higher level of anonymity is an 828 important feature for many end-users, as it allows them different 829 degrees of privacy online. 831 Example: Often standards expose private information, it is important 832 to consider ways to mitigate the obvious privacy impacts. For 833 instance, a feature which uses deep packet inspection or geolocation 834 data could refuse to open this data to third parties, that might be 835 able to connect the data to a physical person. 837 Impacts: 839 - Right to non-discrimination 841 - Right to political participation 843 - Right to freedom of assembly and association 845 - Right to security 847 3.1.1.1.10. Pseudonymity 849 Question(s): Have you considered the Privacy Considerations for 850 Internet Protocols [RFC6973], especially section 6.1.2 ? Does this 851 specification collect personally derived data? Does the protocol 852 generates or processes anything that can be, or be tightly correlated 853 with, personally identifiable information? Does the standard utilize 854 data that is personally-derived, i.e. derived from the interaction of 855 a single person, or their device or address? Does this specification 856 generate personally derived data, and if so how will that data be 857 handled? 859 Explanation: Pseudonymity - the ability to disguise one's identity 860 online - is an important feature for many end-users, as it allows 861 them different degrees of disguised identity and privacy online. 863 Example: Designing a standard that exposes private information, it is 864 important to consider ways to mitigate the obvious impacts. For 865 instance, a feature which uses deep packet inspection or geolocation 866 data could refuse to open this data to third parties, that might be 867 able to connect the data to a physical person. 869 Impacts: 871 - Right to non-discrimination 873 - Right to freedom of assembly and association 875 3.1.1.1.11. Accessibility 877 Question(s): Is your protocol designed to provide an enabling 878 environment for people who are not able-bodied? Have you looked at 879 the W3C Web Accessibility Initiative for examples and guidance? Is 880 your protocol optimized for low bandwidth and high latency 881 connections? Could your protocol also be developed in a stateless 882 manner? 884 Explanation: The Internet is fundamentally designed to work for all 885 people, whatever their hardware, software, language, culture, 886 location, or physical or mental ability. When the Internet meets 887 this goal, it is accessible to people with a diverse range of 888 hearing, movement, sight, and cognitive ability [W3CAccessibility]. 889 Sometimes in the design of protocols, websites, web technologies, or 890 web tools, barriers are created that exclude people from using the 891 Web. 893 Example: The HTML protocol as defined in [HTML5] specifically 894 requires that every image must have an alt attribute (with a few 895 exceptions) to ensure images are accessible for people that cannot 896 themselves decipher non-text content in web pages. 898 Impacts: 900 - Right to non-discrimination 902 - Right to freedom of assembly and association 904 - Right to education 906 - Right to political participation 908 3.1.1.1.12. Localization 910 Question(s): Does your protocol uphold the standards of 911 internationalization? Have made any concrete steps towards 912 localizing your protocol for relevant audiences? 914 Explanation: Localization refers to the adaptation of a product, 915 application or document content to meet the language, cultural and 916 other requirements of a specific target market (a locale) 917 [W3Ci18nDef]. It is also described as the practice of translating an 918 implementation to make it functional in a specific language or for 919 users in a specific locale (see Internationalization). 921 Example: The Internet is a global medium, but many of its protocols 922 and products are developed with a certain audience in mind, that 923 often share particular characteristics like knowing how to read and 924 write in ASCII and knowing English. This limits the ability of a 925 large part of the world's online population from using the Internet 926 in a way that is culturally and linguistically accessible. An 927 example of a protocol that has taken into account the view that 928 individuals like to have access to data in their native language can 929 be found in [RFC1766]. This protocol labels the information content 930 with an identifier for the language in which it is written. And this 931 allows information to be presented in more than one language. 933 Impacts: 935 - Right to non-discrimination 937 - Right to participate in cultural life, arts and science 939 - Right to Freedom of Expression 941 3.1.1.1.13. Decentralization 943 Question(s): Can your protocol be implemented without one single 944 point of control? If applicable, can your protocol be deployed in a 945 federated manner? What is the potential for discrimination against 946 users of your protocol? How can the use of your protocol be used to 947 implicate users? Does your protocol create additional centralized 948 points of control? 950 Explanation: Decentralization is one of the central technical 951 concepts of the architecture of the networks, and embraced as such by 952 the IETF [RFC3935]. It refers to the absence or minimization of 953 centralized points of control; a feature that is assumed to make it 954 easy for new users to join and new uses to unfold [Brown]. It also 955 reduces issues surrounding single points of failure, and distributes 956 the network such that it continues to function if one or several 957 nodes are disabled. With the commercialization of the Internet in 958 the early 1990's there has been a slow move to move away from 959 decentralization, to the detriment of the technical benefits of 960 having a decentralized Internet. 962 Example: The bits traveling the Internet are increasingly susceptible 963 to monitoring and censorship, from both governments and Internet 964 service providers, as well as third (malicious) parties. The ability 965 to monitor and censor is further enabled by the increased 966 centralization of the network that creates central infrastructure 967 points that can be tapped in to. The creation of peer-to-peer 968 networks and the development of voice-over-IP protocols using peer- 969 to-peer technology in combination with distributed hash table (DHT) 970 for scalability are examples of how protocols can preserve 971 decentralization [Pouwelse]. 973 Impacts: 975 - Right to freedom of assembly and association 977 3.1.1.1.14. Reliability 979 Question(s): Is your protocol fault tolerant? Does it degrade 980 gracefully? Do you have a documented way to announce degradation? 981 Do you have measures in place for recovery or partial healing from 982 failure? Can your protocol maintain dependability and performance in 983 the face of unanticipated changes or circumstances? 985 Explanation: Reliability ensures that a protocol will execute its 986 function consistently and error resistant as described, and function 987 without unexpected result. A system that is reliable degenerates 988 gracefully and will have a documented way to announce degradation. 989 It also has mechanisms to recover from failure gracefully, and if 990 applicable, allow for partial healing. As with confidentiality, the 991 growth of the Internet and fostering innovation in services depends 992 on users having confidence and trust [RFC3724] in the network. For 993 reliability it is necessary that services notify the users if a 994 delivery fails. In the case of real-time systems in addition to the 995 reliable delivery the protocol needs to safeguard timeliness. 997 Example: In the modern IP stack structure, a reliable transport layer 998 requires an indication that transport processing has successfully 999 completed, such as given by TCP's ACK message [RFC0793], and not 1000 simply an indication from the IP layer that the packet arrived. 1001 Similarly, an application layer protocol may require an application- 1002 specific acknowledgement that contains, among other things, a status 1003 code indicating the disposition of the request (See [RFC3724]). 1005 Impacts: 1007 - Right to security 1009 3.1.1.1.15. Confidentiality 1011 Question(s): Does this protocol expose information related to 1012 identifiers or data? If so, does it do so to each other protocol 1013 entity (i.e., recipients, intermediaries, and enablers) [RFC6973]? 1014 What options exist for protocol implementers to choose to limit the 1015 information shared with each entity? What operational controls are 1016 available to limit the information shared with each entity? 1018 What controls or consent mechanisms does the protocol define or 1019 require before personal data or identifiers are shared or exposed via 1020 the protocol? If no such mechanisms or controls are specified, is it 1021 expected that control and consent will be handled outside of the 1022 protocol? 1024 Does the protocol provide ways for initiators to share different 1025 pieces of information with different recipients? If not, are there 1026 mechanisms that exist outside of the protocol to provide initiators 1027 with such control? 1029 Does the protocol provide ways for initiators to limit which 1030 information is shared with intermediaries? If not, are there 1031 mechanisms that exist outside of the protocol to provide users with 1032 such control? Is it expected that users will have relationships that 1033 govern the use of the information (contractual or otherwise) with 1034 those who operate these intermediaries? Does the protocol prefer 1035 encryption over clear text operation? 1037 Does the protocol provide ways for initiators to express individuals' 1038 preferences to recipients or intermediaries with regard to the 1039 collection, use, or disclosure of their personal data? 1041 Explanation: Confidentiality refers to keeping your data secret from 1042 unintended listeners [BCP72]. The growth of the Internet depends on 1043 users having confidence that the network protects their private 1044 information [RFC1984]. 1046 Example: Protocols that do not encrypt their payload make the entire 1047 content of the communication available to the idealized attacker 1048 along their path. Following the advice in [RFC3365], most such 1049 protocols have a secure variant that encrypts the payload for 1050 confidentiality, and these secure variants are seeing ever-wider 1051 deployment. A noteworthy exception is DNS [RFC1035], as DNSSEC 1052 [RFC4033]does not have confidentiality as a requirement. This 1053 implies that, in the absence of changes to the protocol as presently 1054 under development in the IETF's DNS Private Exchange (DPRIVE) working 1055 group, all DNS queries and answers generated by the activities of any 1056 protocol are available to the attacker. When store-and-forward 1057 protocols are used (e.g., SMTP [RFC5321]), intermediaries leave this 1058 data subject to observation by an attacker that has compromised these 1059 intermediaries, unless the data is encrypted end-to-end by the 1060 application-layer protocol or the implementation uses an encrypted 1061 store for this data [RFC7624]. 1063 Impacts: 1065 - Right to security 1067 3.1.1.1.16. Integrity 1069 Question(s): Does your protocol maintain and assure the accuracy of 1070 data? Does your protocol maintain and assure the consistency of 1071 data? Does your protocol in any way allow for the data to be 1072 (intentionally or unintentionally) altered? 1074 Explanation: Integrity refers to the maintenance and assurance of the 1075 accuracy and consistency of data to ensure it has not been 1076 (intentionally or unintentionally) altered. 1078 Example: See authenticity 1080 Impacts: 1082 - Right to security 1084 3.1.1.1.17. Authenticity 1086 Question(s): Do you have sufficient measures to confirm the truth of 1087 an attribute of a single piece of data or entity? Can the attributes 1088 get garbled along the way (see security)? If relevant have you 1089 implemented IPsec, DNSsec, HTTPS and other Standard Security Best 1090 Practices? 1092 Explanation: Authenticity ensures that data does indeed come from the 1093 source it claims to come from. This is important to prevent attacks 1094 or unauthorized access and use of data. 1096 Example: Authentication of data is important to prevent 1097 vulnerabilities and attacks, like man-in-the-middle-attacks. These 1098 attacks happen when a third party (often for malicious reasons) 1099 intercepts a communication between two parties, inserting themselves 1100 in the middle and posing as both parties. In practice this looks as 1101 follows: 1103 Alice wants to communicate with Bob. 1104 Alice sends data to Bob. 1105 Corinne intercepts the data sent to Bob. 1106 Corinne reads and alters the message to Bob. 1107 Bob cannot see the data did not come from Alice but from Corinne. 1108 Corinne intercepts and alters the communication as it is sent between 1109 Alice and Bob. 1110 Corinne knows all. 1112 Impacts: 1114 - Right to security 1116 3.1.1.1.18. Adaptability 1118 Question(s): Is your protocol written in such a way that is would be 1119 easy for other protocols to be developed on top of it, or to interact 1120 with it? Does your protocol impact permissionless innovation? See 1121 'Connectivity' above. 1123 Explanation: Adaptability is closely interrelated permissionless 1124 innovation, both maintain the freedom and ability to freely create 1125 and deploy new protocols on top of the communications constructs that 1126 currently exist. It is at the heart of the Internet as we know it, 1127 and to maintain its fundamentally open nature, we need to be mindful 1128 of the impact of protocols on maintaining or reducing permissionless 1129 innovation to ensure the Internet can continue to develop. 1131 Example: WebRTC generates audio and/or video data. In order to 1132 ensure that WebRTC can be used in different locations by different 1133 parties it is important that standard Javascript APIs are developed 1134 to support applications from different voice service providers. 1135 Multiple parties will have similar capabilities, in order to ensure 1136 that all parties can build upon existing standards these need to be 1137 adaptable, and allow for permissionless innovation. 1139 Impacts: 1141 - Right to education 1143 - Freedom of expression 1145 - Freedom of assembly and association 1147 4. Research Questions 1149 The Human Rights Protocol Considerations Research Group (hrpc) in the 1150 Internet Research Taskforce (IRTF) embarked on its mission to answer 1151 the following two questions which are also the main two questions 1152 which this documents seeks to answer: 1154 1. How can Internet protocols and standards impact human rights, 1155 either by enabling them or by creating a restrictive environment? 1157 2. Can guidelines be developed to improve informed and transparent 1158 decision making about potential human rights impact of protocols? 1160 5. Literature and Discussion Review 1162 Protocols and standards are regularly seen as merely performing 1163 technical functions. However, these protocols and standards do not 1164 exist outside of their technical context nor outside of their 1165 political, historical, economic, legal or cultural context. This is 1166 best exemplified by the way in which protocols have become part and 1167 parcel of political processes and public policies: one only has to 1168 look at the IANA transition, the RFC on pervasive monitoring or 1169 global innovation policy for concrete examples [Denardis15]. To 1170 quote [Abbate]: "protocols are politics by other means". This 1171 statement confers that protocols are based on decision making, most 1172 often by humans. In this process the values and ideas about the role 1173 that a particular technology should perform in society is embedded 1174 into the design. Often these design decisions are part pure- 1175 technical, and part inspired by certain world view of how technology 1176 should function that is inspired by personal and political views. 1177 Since the late 1990's a burgeoning group of academics and 1178 practitioners researched questions surrounding the societal impact of 1179 protocols, and the politics of protocols. These studies vary in 1180 focus and scope: some focus on specific standards [Davidsonetal] 1181 [Musiani], others look into the political, legal, commercial or 1182 social impact of protocols [BrownMarsden] [Lessig], [Mueller] and yet 1183 others look at how the engineers' personal set of values get 1184 translated into technology [Abbate],[CathFloridi] [Denardis15] 1185 [WynsbergheMoura]. 1187 Commercial and political influences on the management of the 1188 Internet's infrastructure are well-documented in the academic 1189 literature and will thus not be discussed here [Benkler] [Brownetal] 1190 [Denardis15] [Lessig] [Mueller] [Zittrain]. It is sufficient to 1191 say that the IETF community consistently tries to push back against 1192 the standardization of surveillance and certain other issues that 1193 negatively influence end-users' experience of and trust in the 1194 Internet [Denardis14]. The role human rights play in engineering, 1195 infrastructure maintenance and protocol design is much less clear. 1197 It is very important to understand how protocols and standards impact 1198 human rights. In particular because Standard Developing 1199 Organizations (SDOs) are increasingly becoming venues where social 1200 values (like human rights) are discussed, although often from a 1201 technological point of view. These SDOs are becoming a new focal 1202 point for discussions about values-by-design, and the role of 1203 technical engineers in protecting or enabling human rights 1204 [Brownetal] [Clarketal] [Denardis14] [CathFloridi] [Lessig] 1205 [Rachovitsa]. 1207 In the academic literature five clear positions can be discerned, in 1208 relation to the role of human rights in protocol design and how to 1209 account for these human rights in protocol development: Clark et al. 1210 argue that there is a need to 'design for variation in outcome, so 1211 that the outcome can be different in different places, and the tussle 1212 takes place within the design (...) [as] Rigid designs will be 1213 broken; designs that permit variation will flex under pressure and 1214 survive [Clarketal].' They hold that human rights should not be 1215 hard-coded into protocols because of four reasons: first, the rights 1216 in the UDHR are not absolute. Second, technology is not the only 1217 tool in the tussle over human rights. Third, there are inherent 1218 dangers to using the UDHR. What the authors mean by this is that if 1219 the IETF were to bake the UDHR into its protocols, countries who do 1220 not agree with that might completely withdraw from the standard 1221 setting process. And last but not least, it is dangerous to make 1222 promises that can't be kept. The open nature of the Internet will 1223 never, they argue, be enough to fully protect individuals' human 1224 rights. 1226 Conversely, Brown et al. [Brownetal] state that 'some key, universal 1227 values - of which the UDHR is the most legitimate expression - should 1228 be baked into the architecture at design time.' They argue that 1229 design choices have offline consequences, and are able to shape the 1230 power positions of groups or individuals in society. As such, the 1231 individuals making these technical decisions have a moral obligation 1232 to take into account the impact of their decisions on society, and by 1233 extension human rights. Brown et al recognise that values and the 1234 implementation of human rights vary across the globe. Yet they argue 1235 that all members of the United Nations have found 'common agreement 1236 on the values proclaimed in the Universal Declaration of Human 1237 Rights. In looking for the most legitimate set of global values to 1238 embed in the future Internet architectures, the UDHR has the 1239 democratic assent of a significant fraction of the planet's 1240 population, through their elected representatives." 1241 The main disagreement between these two academic positions lies 1242 mostly in the question on whether a particular value system should be 1243 embedded into the Internet's architectures or whether the 1244 architectures need to account for a varying set of values. 1246 A third position that is similar to that of Brown et al., is taken by 1247 [Broeders] who argues that 'we must find ways to continue 1248 guaranteeing the overall integrity and functionality of the public 1249 core of the Internet.' He argues that the best way to do this is by 1250 declaring the backbone of the Internet - which includes the TCP/IP 1251 protocol suite, numerous standards, the Domain Name System (DNS), and 1252 routing protocols - a common public good. This is a different 1253 approach than that of [Clarketal] and [Brownetal] because Broeders 1254 does not suggest that social values should (or should not) be 1255 explicitly coded into the Internet, but rather that the existing 1256 infrastructure should be seen as an entity of public value. 1258 Bless and Orwat [Bless] represent a fourth position. They argue that 1259 it is too early to make any definitive claims, but that there is a 1260 need for more careful analysis of the impact of protocol design 1261 choices on human rights. They also argue that it is important to 1262 search for solutions that 'create awareness in the technical 1263 community about impact of design choices on social values. And work 1264 towards a methodology for co-design of technical and institutional 1265 systems.' 1267 Berners-Lee and Halpin argue that the Internet could lead to even new 1268 capacities, and these capacities may over time be viewed as new kinds 1269 of rights. For example, Internet access may be viewed as a human 1270 right in of itself if it is taken to be a pre-condition for other 1271 rights, even if it could not have been predicted at the declaration 1272 of the UNHDR after the end of World War 2.[BernersLeeHalpin]. 1274 It is important to contextualize the technical discussion with the 1275 academic discussions on this issue. The academic discussions also 1276 are important to document as they inform the position of the authors 1277 of this document. Our position is that hard-coding human rights into 1278 protocols is complicated and changes with the context. At this point 1279 is difficult to say whether hard-coding human rights into protocols 1280 is wise or feasible. It is however important to make conscious and 1281 explicit design decisions that take into account the human rights 1282 protocol considerations guidelines developed above. This will ensure 1283 that the impact protocols can have on human rights is clear and 1284 explicit, both for developers and for users. In addition, it ensures 1285 that the impact of specific protocol on human rights is carefully 1286 considered and that concrete design decisions are documented in the 1287 protocol. 1289 Pursuant to the principle of constant change, since the function and 1290 scope of the Internet evolves, so does the role of the IETF in 1291 developing standards. Internet standards are adopted on the basis of 1292 a series of criteria, including high technical quality, support by 1293 community consensus, and their overall benefit to the Internet. The 1294 latter calls for an assessment of the interests of all affected 1295 parties and the specifications' impact on the Internet's users. In 1296 this respect, the effective exercise of the human rights of the 1297 Internet users is a relevant consideration that needs to be 1298 appreciated in the standardization process insofar as it is directly 1299 linked to the reliability and core values of the Internet. [RFC1958] 1300 [RFC0226] [RFC3724] 1302 This document details the steps taken in the research into human 1303 rights protocol considerations by the hrpc research group to clarify 1304 the relation between technical concepts used in the IETF and human 1305 rights. This document sets out some preliminary steps and 1306 considerations for engineers to take into account when developing 1307 standards and protocols. 1309 6. Methodology 1311 Mapping the relation between human rights, protocols and 1312 architectures is a new research challenge, which requires a good 1313 amount of interdisciplinary and cross organizational cooperation to 1314 develop a consistent methodology. 1316 The methodological choices made in this document are based on the 1317 political science-based method of discourse analysis and ethnographic 1318 research methods [Cath]. This work departs from the assumption that 1319 language reflects the understanding of concepts. Or as [Jabri] 1320 holds, policy documents are 'social relations represented in texts 1321 where language is used to construct meaning and representation'. 1322 This process happens in 'the social space of society' [Schroeder] and 1323 manifests itself in institutions and organizations [King], exposed 1324 using the ethnographic methods of semi-structured interviews and 1325 participant observation. Or in non-academic language, the way the 1326 language in IETF/IRTF documents describes and approaches the issues 1327 they are trying to address is an indicator for the underlying social 1328 assumptions and relations of the engineers to their engineering. By 1329 reading and analyzing these documents, as well as interviewing 1330 engineers and participating in the IETF/IRTF working groups, it is 1331 possible to distill the relation between human rights, protocols and 1332 the Internet's infrastructure as it pertains to the work of the IETF. 1334 The discourse analysis was operationalized using qualitative and 1335 quantitative means. The first step taken by the authors and 1336 contributors was reading RFCs and other official IETF documents. The 1337 second step was the use of a python-based analyzer, using the tool 1338 Big Bang, adapted by Nick Doty [Doty] to scan for the concepts that 1339 were identified as important architectural principles (distilled on 1340 the initial reading and supplemented by the interviews and 1341 participant observation). Such a quantitative method is very precise 1342 and speeds up the research process [Richie]. But this tool is unable 1343 to understand 'latent meaning' [Denzin]. In order to mitigate these 1344 issues of automated word-frequency based approaches, and to get a 1345 sense of the 'thick meaning' [Geertz] of the data, a second 1346 qualitative analysis of the data set was performed. These various 1347 rounds of discourse analysis were used to inform the interviews and 1348 further data analysis. As such the initial rounds of quantitative 1349 discourse analysis were used to inform the second rounds of 1350 qualitative analysis.The results from the qualitative interviews were 1351 again used to feed new concepts into the quantitative discourse 1352 analysis. As such the two methods continued to support and enrich 1353 each other. 1355 The ethnographic methods of the data collection and processing 1356 allowed the research group to acquire the data necessary to 'provide 1357 a holistic understanding of research participants' views and actions' 1358 [Denzin] that highlighted ongoing issues and case studies where 1359 protocols impact human rights. The interview participants were 1360 selected through purposive sampling [Babbie], as the research group 1361 was interested in getting a wide variety of opinions on the role of 1362 human rights in guiding protocol development. This sampling method 1363 also ensured that individuals with extensive experience working at 1364 the IETF in various roles were targeted. The interviewees included 1365 individuals in leadership positions (Working Group (WG) chairs, Area 1366 Directors (ADs)), 'regular participants', individuals working for 1367 specific entities (corporate, civil society, political, academic) and 1368 represented various backgrounds, nationalities and genders. 1370 6.1. Data Sources 1372 In order to map the potential relation between human rights and 1373 protocols, the HRPC research group gathered data from three specific 1374 sources: 1376 6.1.1. Discourse analysis of RFCs 1378 To start addressing the issue, a mapping exercise analyzing Internet 1379 infrastructure and protocols features, vis-a-vis their possible 1380 impact on human rights was undertaken. Therefore, research on the 1381 language used in current and historic RFCs and mailing list 1382 discussions was undertaken to expose core architectural principles, 1383 language and deliberations on human rights of those affected by the 1384 network. 1386 6.1.2. Interviews with members of the IETF community 1388 Over 30 interviews with the current and past members of the Internet 1389 Architecture Board (IAB), current and past members of the Internet 1390 Engineering Steering Group (IESG) and chairs of selected working 1391 groups and RFC authors were done at the IETF92 Dallas meeting in 1392 March 2015. To get an insider understanding of how they view the 1393 relationship (if any) between human rights and protocols to play out 1394 in their work. Several of the participants opted to remain 1395 anonymous, if you are interested in this data set please contact the 1396 authors. 1398 6.1.3. Participant observation in Working Groups 1400 By participating in various working groups, in person at IETF 1401 meetings and on mailinglists, information was gathered about the 1402 IETFs day-to-day workings. From which general themes, technical 1403 concepts, and use-cases about human rights and protocols were 1404 extracted. This process started at the IETF91 meeting and continues 1405 today. 1407 6.2. Data analysis strategies 1409 The data above was processed using three consecutive strategies: 1410 mapping protocols related to human rights, extracting concepts from 1411 these protocols, and creation of a common glossary (detailed under 1412 Section 2). Before going over these strategies some elaboration on 1413 the process of identifying technical concepts as they relate to human 1414 rights needs to be given: 1416 6.2.1. Identifying qualities of technical concepts that relate to human 1417 rights 1419 6.2.1.1. Mapping protocols and standards related to human rights 1421 By combining data from the three data sources named above, an 1422 extensive list of protocols and standards that potentially enable the 1423 Internet as a tool for freedom of expression and association. In 1424 order to determine the enabling (or inhibiting) features we relied on 1425 direct references of such impact in the RFCs, as well as input from 1426 the community. On the basis of this analysis a list of RFCs that 1427 describe standards and protocols that are potentially closely related 1428 to human rights was compiled. 1430 6.2.1.2. Extracting concepts from mapped RFCs 1432 Mapping the protocols and standards that are related to human rights 1433 and create a human rights enabeling environment was the first step. 1434 For that we needed to focus on specific technical concepts that 1435 underlie these protocols and standards. On the basis of this list a 1436 number of technical concepts that appeared frequently was extracted, 1437 and used to create a second list of technical terms that, when 1438 combined, create an enabling environment for excercising human rights 1439 on the Internet. 1441 6.2.1.3. Building a common vocabulary of technical concepts that impact 1442 human rights 1444 While interviewing experts, mapping RFCs and compiling technical 1445 definitions several concepts of convergence and divergence were 1446 identified. To ensure that the discussion was based on a common 1447 understanding of terms and vocabulary, a list of definitions was 1448 created. The definitions are based on the wording found in various 1449 IETF documents, and if these were unavailable definitions were taken 1450 from definitions from other Standards Developing Organizations or 1451 academic literature, as indicated in the vocabulary section. 1453 6.2.1.4. Translating Human Rights Concepts into Technical Definitions 1455 The previous steps allowed for the clarification of relation between 1456 human rights and technical concepts. The steps taken show how the 1457 research process zoomed in, from compiling a broad lists of protocols 1458 and standards that relate to human rights to extracting the precise 1459 technical concepts that make up these protocols and standards, in 1460 order to understand the relationship between the two. This sub- 1461 section presents the next step: translating human rights to technical 1462 concepts by matching the individuals components of the rights to the 1463 accompanying technical concepts, allowing for the creation of a list 1464 of technical concepts that when combined create an enabling 1465 environment for human rights. 1467 6.2.1.5. List technical terms that combined create enabling environment 1468 for human rights 1470 On the basis of the prior steps the following list of technical 1471 terms, that when combined create an enabling environment for human 1472 rights, such a freedom of expression and freedom of association, was 1473 drafted. 1475 Architectural principles Enabling features 1476 and characteristics for user rights 1478 /------------------------------------------------\ 1479 | | 1480 +=================|=============================+ | 1481 = | = | 1482 = | End to end = | 1483 = | Reliability = | 1484 = | Resilience = Access as | 1485 = | Interoperability = Human Right | 1486 = Good enough | Transparency = | 1487 = principle | Data minimization = | 1488 = | Permissionless innovation = | 1489 = Simplicity | Graceful degradation = | 1490 = | Connectivity = | 1491 = | Heterogeneity = | 1492 = | = | 1493 = | = | 1494 = \------------------------------------------------/ 1495 = = 1496 +===============================================+ 1498 figure 1 - relation between architectural principles and enabling 1499 features for user rights. 1501 6.2.2. Translating human rights to technical terms 1503 The combination of the technical concepts that have been gathered the 1504 steps above have been grouped according to their impact on specific 1505 rights as they have been mentioned in the interviews done at IETF92 1506 as well as study of literature (see literature and discussion review 1507 above). 1509 This analysis aims to assist protocol developers in better 1510 understanding the roles specific technical concepts have with regards 1511 to their contribution to an enabeling environment for people to 1512 excise their human rights. 1514 This analysis does not claim to be a complete or exhaustive mapping 1515 of all possible ways in which a protocols could potentially impact 1516 human rights, but it presents an initial concept mapping based on 1517 interviews and literature and discussion review. 1519 +-----------------------+-----------------------------------------+ 1520 | Technical Concepts | Rights potentially impacted | 1521 +-----------------------+-----------------------------------------+ 1522 | Connectivity | | 1523 | Privacy | | 1524 | Security | | 1525 | Content agnosticism | Right to freedom of expression | 1526 | Internationalization | | 1527 | Censorship resistance | | 1528 | Open Standards | | 1529 | Heterogeneity support | | 1530 +-----------------------+-----------------------------------------+ 1531 | Anonymity | | 1532 | Privacy | | 1533 | Pseudonymity | Right to non-discrimination | 1534 | Accessibility | | 1535 +-----------------------+-----------------------------------------+ 1536 | Content agnosticism | | 1537 | Security | Right to equal protection | 1538 +-----------------------+-----------------------------------------+ 1539 | Accessibility | | 1540 | Internationalization | Right to political participation | 1541 | Censorship resistance | | 1542 | Accessibility | | 1543 +-----------------------+-----------------------------------------+ 1544 | Open standards | | 1545 | Localization | Right to participate in cultural life, | 1546 | Internationalization | arts and science & | 1547 | Censorship resistance | Right to education | 1548 | Accessibility | | 1549 +-----------------------+-----------------------------------------+ 1550 | Connectivity | | 1551 | Decentralization | | 1552 | Censorship resistance | Right to freedom of assembly | 1553 | Pseudonymity | and association | 1554 | Anonymity | | 1555 | Security | | 1556 +-----------------------+-----------------------------------------+ 1557 | Reliability | | 1558 | Confidentiality | | 1559 | Integrity | Right to security | 1560 | Authenticity | | 1561 | Anonymity | | 1562 | | | 1563 +-----------------------+-----------------------------------------+ 1565 figure 2 - relation between specific technical concepts with regards 1566 to their contribution to an enabeling environment for people to 1567 excise their human rights 1569 6.2.3. Map cases of protocols that adversely impact human rights or are 1570 enablers thereof 1572 Given the information above, the following list of cases of protocols 1573 that adversely impact or enable human rights was formed. 1575 It is important to note that the assessment here is not a general 1576 judgment on these protocols. When they were conceived, there were 1577 many criteria to take into account. For instance, relying on an 1578 external server can be bad for freedom of speech (it creates one more 1579 control point, where censorship could be applied) but it may be a 1580 necessity if the endpoints are not connected and reachable 1581 permanently. So, when we say "protocol X has feature Y, which may 1582 endanger the freedom of speech", it does not mean that protocol X is 1583 bad and even less that its authors were evil. The goal here is to 1584 show, with actual examples, that the design of protocols have 1585 practical consequences for some human rights and these consequences 1586 have to be considered at design time. 1588 6.2.3.1. IPv4 1590 The Internet Protocol version 4 (IPv4), also known as 'layer 3' of 1591 the Internet, and specified as a common encapsulation and protocol 1592 header, is defined in [RFC0791]. The evolution of Internet 1593 communications led to continued development in this area, 1594 encapsulated in the development of version 6 (IPv6) of the protocol 1595 in [RFC2460]. In spite of this updated protocol, we find that 25 1596 years after the specification of version 6 of the protocol, the older 1597 v4 standard continues to account for a sizeable majority of Internet 1598 traffic, and most of the issues discussed here (with the big 1599 exception of NAT, see Address Translation) are valid for IPv4 as well 1600 as IPv6. 1602 The Internet was designed as a platform for free and open 1603 communication, most notably encoded in the end-to-end principle, and 1604 that philosophy is also present in the technical implementation of 1605 the Internet Protocol. [RFC3724] While the protocol was designed to 1606 exist in an environment where intelligence is at the end hosts, it 1607 has proven to provide sufficient information that a more intelligent 1608 network core can make policy decisions and enforce policy shaping and 1609 restricting the communications of end hosts. These capabilities for 1610 network control and limitations of the freedom of expression by end 1611 hosts can be traced back to the IPv4 design, helping us understand 1612 which technical protocol decisions have led to harm of this human 1613 rights. A feature that can harm freedom of expression as well as the 1614 right to privacy through misuse of the Internet Protocol is the 1615 exploitation of the public visibility of the host pairs for all 1616 communications, and the corresponding ability to discriminate and 1617 block traffic as a result of that metadata. 1619 6.2.3.1.1. Network visibility of Source and Destination 1621 The IPv4 protocol header contains fixed location fields for both the 1622 source and destination IP addresses [RFC0791]. These addresses 1623 identify both the host sending and receiving each message, and allow 1624 the core network to understand who is talking to whom, and to 1625 practically limit communication selectively between pairs of hosts. 1626 Blocking of communication based on the pair of source and destination 1627 is one of the most common limitations on the ability for people to 1628 communicate today, [caida] and can be seen as a restriction of the 1629 ability for people to assemble or to consensually express themselves. 1631 Inclusion of an Internet-wide identified source in the IP header is 1632 not the only possible design, especially since the protocol is most 1633 commonly implemented over Ethernet networks exposing only link-local 1634 identifiers [RFC0894]. A variety of alternative designs including 1635 source routing, which would allow for the sender to choose a per 1636 defined (safe) route, and spoofing of the source IP address are 1637 technically supported by the protocol, but neither are considered 1638 good practice on the Internet [Farrow]. While projects like 1639 [torproject] provide an alternative implementation of anonymity in 1640 connections, they have been developed in spite of the IPv4 protocol 1641 design. 1643 6.2.3.1.2. Address Translation and Mobility 1645 A major structural shift in the Internet which undermined the 1646 protocol design of IPv4, and significantly reduced the freedom of end 1647 users to communicate and assemble is the introduction of network 1648 address translation. [RFC1631] Network address translation is a 1649 process whereby organizations and autonomous systems connect two 1650 networks by translating the IPv4 source and destination addresses 1651 between the two. This process puts the router performing the 1652 translation into a privileged position, where it can decide which 1653 subset of communications are worthy of translation, and whether an 1654 unknown request for communication will be correctly forwarded to a 1655 host on the other network. 1657 This process of translation has widespread adoption despite promoting 1658 a process that goes against the stated end-to-end process of the 1659 underlying protocol [natusage]. In contrast, the proposed mechanism 1660 to provide support for mobility and forwarding to clients which may 1661 move, encoded instead as an option in the IP protocol in [RFC5944], 1662 has failed to gain traction. In this situation the compromise made 1663 in the design of the protocol resulted in a technology that is not 1664 coherent with the end-to-end principles and thus creates an extra 1665 possible hurdle for freedom of expression in its design, even though 1666 a viable alternative exists. There is a particular problem 1667 surrounding NATs and VPN (as well as other connections used for 1668 privacy purposes) as NATs sometimes cause VPNs not to work. 1670 6.2.3.2. DNS 1672 The Domain Name System (DNS) [RFC1035], provides service discovery 1673 capabilities, and provides a mechanism to associate human readable 1674 names with services. The DNS system is organized around a set of 1675 independently operated 'Root Servers' run by organizations which 1676 function in line with ICANN's policy by answering queries for which 1677 organizations have been delegated to manage registration under each 1678 Top Level Domain (TLD). The DNS is organized as a rooted tree, and 1679 this brings up political and social concerns over control. Top Level 1680 domains are maintained and determined by ICANN. These namespaces 1681 encompass several classes of services. The initial name spaces 1682 including '.Com' and '.Net', provide common spaces for expression of 1683 ideas, though their policies are enacted through US based companies. 1684 Other name spaces are delegated to specific nationalities, and may 1685 impose limits designed to focus speech in those forums both to 1686 promote speech from that nationality, and to comply with local limits 1687 on expression and social norms. Finally, the system has recently 1688 been expanded with additional generic and sponsored name spaces, for 1689 instance '.travel' and '.ninja', which are operated by a range of 1690 organizations which may independently determine their registration 1691 policies. This new development has both positive and negative 1692 implications in terms of enabling human rights. Some individuals 1693 argue that it undermines the right to freedom of expression because 1694 some of these new gtlds have restricted policies on registration and 1695 particular rules on hate speech content. Others argue that precisely 1696 these properties are positive because they enable certain (mostly 1697 minority) communities to build safer spaces for association, thereby 1698 enabling their right to freedom of association. An often mentioned 1699 example is an application like .gay [CoE]. 1701 DNS has significant privacy issues per [RFC7626]. Most notable the 1702 lack of encryption to limit the visibility of requests for domain 1703 resolution from intermediary parties, and a limited deployment of 1704 DNSSEC to provide authentication, allowing the client to know that 1705 they received a correct, "authoritative", answer to a query. In 1706 response to the privacy issues, the IETF DNS PRIVate Exchange 1707 (DPRIVE) Working Group is developing mechanisms to provide 1708 confidentiality to DNS transactions, to address concerns surrounding 1709 pervasive monitoring [RFC7258]. 1711 Authentication through DNSSEC creates a validation path for records. 1712 This authentication protects against forged or manipulated DNS data. 1713 As such DNSSEC protects the directory look-up and makes hijacking of 1714 a session harder. This is important because currently interference 1715 with the operation of the DNS is becoming one of the central 1716 mechanisms used to block access to websites. This interference 1717 limits both the freedom of expression of the publisher to offer their 1718 content, and the freedom of assembly for clients to congregate in a 1719 shared virtual space. Even though DNSSEC doesn't prevent censorship, 1720 it makes it clear that the returned information is not the 1721 information that was requested, which contributes to the right to 1722 security and increases trust in the network. It is however important 1723 to note that DNSSEC is currently not widely supported or deployed by 1724 domain name registrars, making it difficult to authenticate and use 1725 correctly. 1727 6.2.3.2.1. Removal of records 1729 There have been a number of cases where the records for a domain are 1730 removed from the name system due to real-world events. Examples of 1731 this removal includes the 'seizure' of wikileaks [bbc-wikileaks] and 1732 the names of illegally operating gambling operations by the United 1733 States Immigrations and Customs Enforcement unit, which compelled the 1734 US-based registry in charge of the .com TLD to hand ownership of 1735 those domains over to the US government. The same technique has been 1736 used in Libya to remove sites in violation of "our Country's Law and 1737 Morality (which) do not allow any kind of pornography or its 1738 promotion." [techyum] 1740 At a protocol level, there is no technical auditing for name 1741 ownership, as in alternate systems like [namecoin]. As a result, 1742 there is no ability for users to differentiate seizure from the 1743 legitimate transfer of name ownership, which is purely a policy 1744 decision of registrars. While DNSSEC addresses network distortion 1745 events described below, it does not tackle this problem. 1747 (While mentioning alternative techniques, this is not a comparison of 1748 DNS with Namecoin: the latter has its own problems and limitations. 1749 The idea here is to show that there are several possible choices, and 1750 they have consequences for human rights.) 1752 6.2.3.2.2. Distortion of records 1754 The most common mechanism by which the DNS system is abused to limit 1755 freedom of expression is through manipulation of protocol messages by 1756 the network. One form occurs at an organizational level, where 1757 client computers are instructed to use a local DNS resolver 1758 controlled by the organization. The DNS resolver will then 1759 selectively distort responses rather than request the authoritative 1760 lookup from the upstream system. The second form occurs through the 1761 use of deep packet inspection, where all DNS protocol messages are 1762 inspected by the network, and objectionable content is distorted, as 1763 can be observed in Chinese network. 1765 A notable instance of distortion occurred in Greece [ververis], where 1766 a study found evidence of both of deep packet inspection to distort 1767 DNS replies, and overblocking of content. ISPs prevented clients 1768 from resolving the names of domains which they were instructed to do 1769 through a governmental order, prompting this particular blocking 1770 systems there. 1772 At a protocol level, the effectiveness of these attacks is made 1773 possible by a lack of authentication in the DNS protocol. DNSSEC 1774 provides the ability to determine authenticity of responses when 1775 used, but it is not regularly checked by resolvers. DNSSEC is not 1776 effective when the local resolver for a network is complicit in the 1777 distortion, for instance when the resolver assigned for use by an ISP 1778 is the source of injection. Selective distortion of records is also 1779 been made possible by the predictable structure of DNS messages, 1780 which make it computationally easy for a network device to watch all 1781 passing messages even at high speeds, and the lack of encryption, 1782 which allows the network to distort only an objectionable subset of 1783 protocol messages. Specific distortion mechanisms are discussed 1784 further in [hall]. 1786 Users can switch to another resolver, for instance a public one such 1787 as those operated by Telecomix (http://dns.telecomix.org/). The 1788 distorter can then try to block or hijack the connection to this 1789 resolver. This may start an arm's race, the user switching to 1790 secured connections to this alternative resolver ([RFC7858]), the 1791 disruptor then trying to find more sophisticated ways to block or 1792 hijack. In some cases, this search for an alternative, non- 1793 disrupting resolver, may lead to more centralisation, many people 1794 going to a few big commercial public resolvers. 1796 6.2.3.2.3. Injection of records 1798 Responding incorrectly to requests for name lookups is the most 1799 common mechanism that in-network devices use to limit the ability of 1800 end users to discover services. A deviation, which accomplishes a 1801 similar objective may be seen as different from a freedom of 1802 expression perspective, is the injection of incorrect responses to 1803 queries. The most prominent example of this behavior occurs in 1804 China, where requests for lookups of sites deemed inappropriate will 1805 trigger the network to respond with a false response, causing the 1806 client to ignore the real response when it subsequently arrives. 1807 [greatfirewall] Unlike the other forms of discussion mentioned above, 1808 injection does not stifle the ability of a server to announce it's 1809 name, it instead provides another voice which answers sooner. This 1810 is effective because without DNSSEC, the protocol will respond to 1811 whichever answer is received first, without listening for subsequent 1812 answers. 1814 6.2.3.3. HTTP 1816 The Hypertext Transfer Protocol (HTTP), described in its version 1.1 1817 in RFC 7230 to 7237, is a request-response application protocol 1818 developed throughout the 1990s, and factually contributed to the 1819 exponential growth of the Internet and the inter-connection of 1820 populations around the world. Its simple design strongly contributed 1821 to the fact that HTTP has become the foundation of most modern 1822 Internet platforms and communication systems, from websites, to chat 1823 systems, and computer-to-computer applications. In its manifestation 1824 with the World Wide Web, HTTP radically revolutionized the course of 1825 technological development and the ways people interact with online 1826 content and with each other. 1828 However, HTTP is also a fundamentally insecure protocol, that doesn't 1829 natively provide encryption properties. While the definition of the 1830 Secure Sockets Layer (SSL) [RFC6101], and later of Transport Layer 1831 Security (TLS)[RFC5246], also happened during the 1990s, the fact 1832 that HTTP doesn't mandate the use of such encryption layers to 1833 developers and service providers, was one of the reasons for a very 1834 late adoption of encryption. Only in the middle of the 2000s did we 1835 observe big Internet service providers, such as Google, starting to 1836 provide encrypted access to their web services. 1838 The lack of sensitivity and understanding of the critical importance 1839 of securing web traffic incentivized certain (offensive) actors to 1840 develop, deploy and utilize at large interception systems and later 1841 active injection attacks, in order to swipe large amounts of data, 1842 compromise Internet-enabled devices. The commercial availability of 1843 systems and tools to perform these types of attacks also led to a 1844 number of human rights abuses that have been discovered and reported 1845 over the years. 1847 Generally we can identify in Traffic Interception and Traffic 1848 Manipulation the two most problematic attacks that can be performed 1849 against applications employing a clear-text HTTP transport layer. 1850 That being said, the IETF is taking steady steps to move to the 1851 encrypted version of HTTP, HTTPSecure (HTTPS). 1853 6.2.3.3.1. Traffic Interception 1855 While we are seeing an increasing trend in the last couple of years 1856 to employ SSL/TLS as a secure traffic layer for HTTP-based 1857 applications, we are still far from seeing an ubiquitous use of 1858 encryption on the World Wide Web. It is important to consider that 1859 the adoption of SSL/TLS is also a relatively recent phenomena. 1860 E-mail providers such as riseup.net were the first ones to enable SSL 1861 by default. Google introduced an option for its GMail users to 1862 navigate with SSL only in 2008 [Rideout], and turned TLS on by 1863 default later in 2010 [Schillace]. It took an increasing amount of 1864 security breaches and revelations on global surveillance from Edward 1865 Snowden to have other mail service providers to follow suit. For 1866 example, Yahoo enabled SSL/TLS by default on its webmail services 1867 only towards the end of 2013 [Peterson]. 1869 TLS itself has been subject to many attacks and bugs which can be 1870 attributed to some fundamental design weaknesses such as lack of a 1871 state machine, which opens a vulnerability for a Triple Handshake 1872 Attack, and flaws caused by early U.S. government restrictions on 1873 cryptography, leading to cipher-suite downgrade attacks (Logjam 1874 attack). These vulnerabilities are being corrected in TLS1.3. 1875 [Bhargavan] [Adrian] 1877 HTTP upgrading to HTTPS is also vulnerable to having an attacker 1878 remove the "S" in any links to HTTPS URIs from a web-page transferred 1879 in cleartext over HTTP, an attack called "SSL Stripping" [sslstrip]. 1880 Thus, for high security use of HTTPS IETF standards such as HSTS 1881 [RFC6797], certificate pinning [RFC7469] and/or DANE [RFC6698] should 1882 be used. 1884 As we learned through the Snowden's revelations, intelligence 1885 agencies have been intercepting and collecting unencrypted traffic at 1886 large for many years. There are documented examples of such mass 1887 surveillance programs with GCHQ's TEMPORA [WP-Tempora] and NSA's 1888 XKEYSCORE [Greenwald]. Through these programs NSA/GCHQ have been 1889 able to swipe large amounts of data including email and instant 1890 messaging communications which have been transported by the 1891 respective providers in clear for years, unsuspecting of the 1892 pervasiveness and scale of governments' efforts and investment into 1893 global mass surveillance capabilities. 1895 However, similar mass interception of unencrypted HTTP communications 1896 is also often employed at a nation-level by some democratic countries 1897 by exercising control over state-owned Internet Service Providers 1898 (ISP) and through the use of commercially available monitoring, 1899 collection, and censorship equipment. Over the last few years a lot 1900 of information has come to public attention on the role and scale of 1901 a surveillance industry dedicated to develop interception gear of 1902 different types, making use of known and unknown weaknesses in 1903 existing protocols [RFC7258]. We have several records of such 1904 equipment being sold and utilized by some regimes in order to monitor 1905 entire segments of population especially at times of social and 1906 political distress, uncovering massive human rights abuses. For 1907 example, in 2013 the group Telecomix revealed that the Syrian regime 1908 was making use of BlueCoat products in order to intercept clear-text 1909 traffic as well as to enforce censorship of unwanted content [RSF]. 1910 Similarly in 2012 it was found that the French Amesys provided the 1911 Gaddafi's government with equipment able to intercept emails, 1912 Facebook traffic, and chat messages at a country level [WSJ]. The 1913 use of such systems, especially in the context of the Arab Spring and 1914 of civil uprisings against the dictatorships, has caused serious 1915 concerns of significant human rights abuses in Libya. 1917 6.2.3.3.2. Traffic Manipulation 1919 The lack of a secure transport layer under HTTP connections not only 1920 exposes the users to interception of the content of their 1921 communications, but is more and more commonly abused as a vehicle for 1922 actively compromising computers and mobile devices. If an HTTP 1923 session travels in the clear over the network, any node positioned at 1924 any point in the network is able to perform man-in-the-middle attacks 1925 and observe, manipulate, and hijack the session and modify the 1926 content of the communication in order to trigger unexpected behavior 1927 by the application generating the traffic. For example, in the case 1928 of a browser the attacker would be able to inject malicious code in 1929 order to exploit vulnerabilities in the browser or any of its 1930 plugins. Similarly, the attacker would be able to intercept, add 1931 malware, and repackage binary software updates that are very commonly 1932 downloaded in clear by applications such as word processors and media 1933 players. If the HTTP session would be encrypted, the tampering of 1934 the content would not be possible, and these network injection 1935 attacks would not be successful. 1937 While traffic manipulation attacks have been long known, documented, 1938 and prototyped especially in the context of WiFi and LAN networks, in 1939 the last few years we observed an increasing investment into the 1940 production and sale of network injection equipment both available 1941 commercially as well as deployed at scale by intelligence agencies. 1943 For example, we learned from some of the documents provided by Edward 1944 Snowden to the press, that the NSA has constructed a global network 1945 injection infrastructure, called QUANTUM, able to leverage mass 1946 surveillance in order to identify targets of interests and 1947 subsequently task man-on-the-side attacks to ultimately compromise a 1948 selected device. Among other attacks, NSA makes use of an attack 1949 called QUANTUMINSERT [Haagsma] which intercepts and hijacks an 1950 unencrypted HTTP communication and forces the requesting browser to 1951 redirect to a host controlled by NSA instead of the intended website. 1952 Normally, the new destination would be an exploitation service, 1953 referred in Snowden documents as FOXACID, which would attempt at 1954 executing malicious code in the context of the target's browser. The 1955 Guardian reported in 2013 that NSA has for example been using these 1956 techniques to target users of the popular anonymity service Tor 1957 [Schneier]. The German NDR reported in 2014 that NSA has also been 1958 using its mass surveillance capabilities to identify Tor users at 1959 large [Appelbaum]. 1961 Recently similar capabilities of Chinese authorities have been 1962 reported as well in what has been informally called the "Great 1963 Cannon" [Marcak], which raised numerous concerns on the potential 1964 curb on human rights and freedom of speech due to the increasing 1965 tighter control of Chinese Internet communications and access to 1966 information. 1968 Network injection attacks are also made widely available to state 1969 actors around the world through the commercialization of similar, 1970 smaller scale equipment that can be easily acquired and deployed at a 1971 country-wide level. Certain companies are known to have network 1972 injection gear within their products portfolio [Marquis-Boire]. The 1973 technology devised and produced by some of them to perform network 1974 traffic manipulation attacks on HTTP communications is even the 1975 subject of a patent application in the United States [Googlepatent]. 1976 Access to offensive technologies available on the commercial lawful 1977 interception market has led to human rights abuses and illegitimate 1978 surveillance of journalists, human rights defenders, and political 1979 activists in many countries around the world [Collins]. While 1980 network injection attacks haven't been the subject of much attention, 1981 they do enable even unskilled attackers to perform silent and very 1982 resilient compromises, and unencrypted HTTP remains one of the main 1983 vehicles. 1985 There is a new version of HTTP, called HTTP/2, which was published as 1986 [RFC7540] and which aimed to be largely backwards compatible but also 1987 offer new option such as data compression of HTTP headers and 1988 pipelining of request and multiplexing multiple requests over a 1989 single TCP connection. In addition to decreasing latency to improve 1990 page loading speeds it also facilitates more efficient use of 1991 connectivity in low-bandwith environments, which is an enabler for 1992 freedom of expression, the right to assembly, right to political 1993 participation and the right to participate in cultural life, art and 1994 science. [RFC7540] does not mandate Transport Layer Security or any 1995 other form of encryption, is also does not support opportunistic 1996 encryption, so the vulnerabilities listed above for HTTP/1 are also 1997 valid for HTTP/2 as defined in [RFC7540]. 1999 6.2.3.4. XMPP 2001 The Extensible Messaging and Presence Protocol (XMPP), specified in 2002 [RFC6120], provides a standard for interactive chat messaging, and 2003 has evolved to encompass interoperable text, voice, and video chat. 2004 The protocol is structured as a federated network of servers, similar 2005 to email, where users register with a local server which acts one 2006 their behalf to cache and relay messages. This protocol design has 2007 many advantages, allowing servers to shield clients from denial of 2008 service and other forms of retribution for their expression, and 2009 designed to avoid central entities which could control the ability to 2010 communicate or assemble using the protocol. 2012 None-the-less, there are plenty of aspects of the protocol design of 2013 XMPP which shape the ability for users to communicate freely, and to 2014 assembly through the protocol. 2016 6.2.3.4.1. User Identification 2018 The XMPP specification dictates that clients are identified with a 2019 resource (node@domain/home [1] / node@domain/work [2]) to distinguish 2020 the conversations to specific devices. While the protocol does not 2021 specify that the resource must be exposed by the client's server to 2022 remote users, in practice this has become the default behavior. In 2023 doing so, users can be tracked by remote friends and their servers, 2024 who are able to monitor presence not just of the user, but of each 2025 individual device the user logs in with. This has proven to be 2026 misleading to many users [pidgin], since many clients only expose 2027 user level rather than device level presence. Likewise, user 2028 invisibility so that communication can occur while users don't notify 2029 all buddies and other servers of their availability is not part of 2030 the formal protocol, and has only been added as an extension within 2031 the XML stream rather than enforced by the protocol. 2033 6.2.3.4.2. Surveillance of Communication 2035 The XMPP protocol specifies the standard by which communication of 2036 channels may be encrypted, but it does not provide visibility to 2037 clients of whether their communications are encrypted on each link. 2038 In particular, even when both clients ensure that they have an 2039 encrypted connection to their XMPP server to ensure that their local 2040 network is unable to read or disrupt the messages they send, the 2041 protocol does not provide visibility into the encryption status 2042 between the two servers. As such, clients may be subject to 2043 selective disruption of communications by an intermediate network 2044 which disrupts communications based on keywords found through Deep 2045 Packet Inspection. While many operators have commited to only 2046 establishing encrypted links from their servers in recognition of 2047 this vulnerability, it remains impossible for users to audit this 2048 behavior and encrypted connections are not required by the protocol 2049 itself [xmppmanifesto]. 2051 In particular, section 13.14 of the protocol specification [RFC6120] 2052 explicitly acknowledges the existence of a downgrade attack where an 2053 adversary controlling an intermediate network can force the inter 2054 domain federation between servers to revert to a non-encrypted 2055 protocol were selective messages can then be disrupted. 2057 6.2.3.4.3. Group Chat Limitations 2059 Group chat in the XMPP protocol is defined as an extension within the 2060 XML specification of the XMPP protocol (https://xmpp.org/extensions/ 2061 xep-0045.html). However, it is not encoded or required at a protocol 2062 level, and not uniformly implemented by clients. 2064 The design of multi-user chat in the XMPP protocol suffers from 2065 extending a protocol that was not designed with assembly of many 2066 users in mind. In particular, in the federated protocol provided by 2067 XMPP, multi-user communities are implemented with a distinguished 2068 'owner', who is granted control over the participants and structure 2069 of the conversation. 2071 Multi-user chat rooms are identified by a name specified on a 2072 specific server, so that while the overall protocol may be federated, 2073 the ability for users to assemble in a given community is moderated 2074 by a single server. That server may block the room and prevent 2075 assembly unilaterally, even between two users neither of whom trust 2076 or use that server directly. 2078 6.2.3.5. Peer to Peer 2080 Peer-to-Peer (P2P) is a distributed network architecture in which all 2081 the participant nodes can be responsible for the storage and 2082 dissemination of information from any other node (defined in 2083 [RFC7574], an IETF standard that used a P2P architecture). A P2P 2084 network is a logical overlay that lives on top of the physical 2085 network, and allows nodes (or "peers") participating to it to 2086 establish contact and exchange information directly from one to each 2087 other. The implementation of a P2P network may very widely: it may 2088 be structured or unstructured, and it may implement stronger or 2089 weaker cryptographic and anonymity properties. While its most common 2090 application has traditionally been file-sharing (and other types of 2091 content delivery systems), P2P is a popular architecture for networks 2092 and applications that require (or encourage) decentralization. A 2093 prime example is Bitcoin (and similar cryptocurrencies), as well as 2094 Bitcoin and proprietary multimedia applications. 2096 In a time of heavily centralized online services, peer-to-peer is 2097 regularly described as an alternative, more democratic, and resistant 2098 option that displaces structures of control over data and 2099 communications and delegates all peers equally to be responsible for 2100 the functioning, integrity, and security of the data. While in 2101 principle peer-to-peer remains imporant to the design and development 2102 of future content distribution, messaging, and publishing systems, it 2103 poses numerous security and privacy challenges which are mostly 2104 delegated to individual developers to recognize, analyze, and solve 2105 in each implementation of a given P2P network. 2107 6.2.3.5.1. Network Poisoning 2109 Since content, and in some occasions peer lists, are safeguarded and 2110 distributed by its members, P2P networks are prone to what are 2111 generally defined as "poisoning attacks". Poisoning attacks might be 2112 aimed directly at the data that is being distributed, for example by 2113 intentionally corrupting it, or at the index tables used to instruct 2114 the peers where to fetch the data, or at routing tables, with the 2115 attempt of providing connecting peers with lists of rogue or non- 2116 existing peers, with the intention to effectively cause a Denial of 2117 Service on the network. 2119 6.2.3.5.2. Throttling 2121 Peer-to-Peer traffic (and BitTorrent in particular) represents a high 2122 percentage of global Internet traffic and it has become increasingly 2123 popular for Internet Service Providers to perform throttling of 2124 customers lines in order to limit bandwidth usage [torrentfreak1] and 2125 sometimes probably as an effect of the ongoing conflict between 2126 copyright holders and file-sharing communities [wikileaks]. Such 2127 throttling undermines the end-to-end principle. 2129 Throttling the peer-to-peer traffic makes some uses of P2P networks 2130 ineffective and it might be coupled with stricter inspection of 2131 users' Internet traffic through Deep Packet Inspection techniques 2132 which might pose additional security and privacy risks. 2134 6.2.3.5.3. Tracking and Identification 2136 One of the fundamental and most problematic issues with traditional 2137 peer-to-peer networks is a complete lack of anonymization of its 2138 users. For example, in the case of BitTorrent, all peers' IP 2139 addresses are openly available to the other peers. This has lead to 2140 an ever-increasing tracking of peer-to-peer and file-sharing users 2141 [ars]. As the geographical location of the user is directly exposed, 2142 and so could be his identity, the user might become target of 2143 additional harassment and attacks, being of physical or legal nature. 2144 For example, it is known that in Germany law firms have made 2145 extensive use of peer-to-peer and file-sharing tracking systems in 2146 order to identify downloaders and initiate legal actions looking for 2147 compensations [torrentfreak2]. 2149 It is worth noting that there are varieties of P2P networks that 2150 implement cryptographic practices and that introduce anonymization of 2151 its users. Such implementations may be proved to be successful in 2152 resisting censorship of content, and tracking of the network peers. 2153 A primary example is FreeNet [freenet1], a free software application 2154 designed to significantly increase the difficulty of users and 2155 content identification, and dedicated to foster freedom of speech 2156 online [freenet2]. 2158 6.2.3.5.4. Sybil Attacks 2160 In open-membership P2P networks, a single attacker can pretend to be 2161 many participants, typically by creating multiple fake identities of 2162 whatever kind the P2P network uses [Douceur]. Attackers can use 2163 Sybil attacks to bias choices the P2P network makes collectively 2164 toward the attacker's advantage, e.g., by making it more likely that 2165 a particular data item (or some threshold of the replicas or shares 2166 of a data item) are assigned to attacker-controlled participants. If 2167 the P2P network implements any voting, moderation, or peer review- 2168 like functionality, Sybil attacks may be used to "stuff the ballots" 2169 toward the attacker's benefit. Companies and governments can use 2170 Sybil attacks on discussion-oriented P2P systems for "astroturfing" 2171 or creating the appearance of mass grassroots support for some 2172 position where there is none in reality. It is important to know 2173 that there are no known complete, environmentally sustainable, and 2174 fully distributed solutions to Sybil attacks, and routing via 2175 'friends' allows users to be de-anonymized via their social graph. 2176 It is important to note that Sybil attacks in this context (e.f. 2177 astroturfing) are relevant to more than P2P protocols. And are also 2178 common on web based systems, and exploited by governments and 2179 commercial entitities. 2181 Encrypted P2P and Anonymous P2P networks already emerged and provided 2182 viable platforms for sharing material [tribler], publish content 2183 anonymously, and communicate securely [bitmessage]. These platforms 2184 are not perfect, and more research needs to be done. If adopted at 2185 large, well-designed and resistant P2P networks might represent a 2186 critical component of a future secure and distributed Internet, 2187 enabling freedom of speech and freedom of information at scale. 2189 6.2.3.6. Virtual Private Network 2191 The Virtual Private Networks (VPN) that are being discussed here are 2192 point-to-point connections that enables two computers to communicate 2193 over an encrypted tunnel. There are multiple implementations and 2194 protocols used in the deployment of VPNs, and they generally 2195 diversify by encryption protocol or particular requirements, most 2196 commonly in proprietary and enterprise solutions. VPNs are used 2197 commonly either to enable some devices to communicate through 2198 peculiar network configurations, or in order to use some privacy and 2199 security properties in order to protect the traffic generated by the 2200 end user; or both. VPNs have also become a very popular technology 2201 among human rights defenders, dissidents, and journalists worldwide 2202 to avoid local monitoring and eventually also to circumvent 2203 censorship. Among human rights defenders VPNs are often debated as a 2204 potential alternative to Tor or other anonymous networks. Such 2205 comparison is misleading, as some of the privacy and security 2206 properties of VPNs are often misunderstood by less tech-savvy users, 2207 which could ultimately lead to unintended problems. 2209 As VPNs increased in popularity, commercial VPN providers have 2210 started growing in business and are very commonly picked by human 2211 rights defenders and people at risk, as they are normally provided 2212 with an easy-to-use service and sometimes even custom applications to 2213 establish the VPN tunnel. Not being able to control the 2214 configuration of the network, and even less so the security of the 2215 application, assessing the general privacy and security state of 2216 common VPNs is very hard. Often such services have been discovered 2217 leaking information, and their custom applications have been found 2218 flawed. While Tor and similar networks receive a lot of scrutiny 2219 from the public and the academic community, commercial or non- 2220 commercial VPN networks are way less analyzed and understood 2221 [Insinuator] [Alshalanetal] , and it might be valuable to establish 2222 some standards to guarantee a minimal level of privacy and security 2223 to those who need them the most. 2225 6.2.3.6.1. No anonymity against VPN provider 2227 One of the common misconceptions among users of VPNs is the level of 2228 anonymity VPN can provide. This sense of anonymity can be betrayed 2229 by a number of attacks or misconfigurations of the VPN provider. It 2230 is important to remember that, in contrast to Tor and similar 2231 systems, VPN was not designed to provide anonymity properties. From 2232 a technical point of view, the VPN might leak identifiable 2233 information, or might be subject of correlation attacks that could 2234 expose the originating address of the connecting user. Most 2235 importantly, it is vital to understand that commercial and non- 2236 commercial VPN providers are bound by the law of the jurisdiction 2237 they reside in or in which their infrastructure is located, and they 2238 might be legally forced to turn over data of specific users if legal 2239 investigations or intelligence requirements dictate so. In such 2240 cases, if the VPN providers retain logs, it is possible that the 2241 information of the user is provided to the user's adversary and leads 2242 to his or her identification. 2244 6.2.3.6.2. Logging 2246 With VPN being point-to-point connections, the service providers are 2247 in fact able to observe the original location of the connecting users 2248 and they are able to track at what time they started their session 2249 and eventually also to which destinations they're trying to connect 2250 to. If the VPN providers retain logs for long enough, they might be 2251 forced to turn over the relevant data or they might be otherwise 2252 compromised, leading to the same data getting exposed. A clear log 2253 retaining policy could be enforced, but considerig that countries 2254 enforce different levels of data retention policies, VPN providers 2255 should at least be transparent on what information do they store and 2256 for how long is being kept. 2258 6.2.3.6.3. 3rd Party Hosting 2260 VPN providers very commonly rely on 3rd parties to provision the 2261 infrastructure that is later going to be used to run VPN endpoints. 2262 For example, they might rely on external dedicated server hosting 2263 providers, or on uplink providers. In those cases, even if the VPN 2264 provider itself isn't retaining any significant logs, the information 2265 on the connecting users might be retained by those 3rd parties 2266 instead, introducing an additional collection point for the 2267 adversary. 2269 6.2.3.6.4. IPv6 Leakage 2271 Some studies proved that several commercial VPN providers and 2272 applications suffer of critical leakage of information through IPv6 2273 due to improper support and configuration [PETS2015VPN]. This is 2274 generally caused by a lack of proper configuration of the client's 2275 IPv6 routing tables. Considering that most popular browsers and 2276 similar applications have been supporting IPv6 by default, if the 2277 host is provided with a functional IPv6 configuration, the traffic 2278 that is generated might be leaked if the VPN application isn't 2279 designed to manipulate such traffic properly. 2281 6.2.3.6.5. DNS Leakage 2283 Similarly, VPN services that aren't handling DNS requests and are not 2284 running DNS servers of their own, might be prone to DNS leaking which 2285 might not only expose sensitive information on the activity of the 2286 user, but could also potentially lead to DNS hijacking attacks and 2287 following compromises. 2289 6.2.3.6.6. Traffic Correlation 2291 Some implementations of VPN appear to be particularly vulnerable to 2292 identification and collection of key exchanges which, some Snowden 2293 documents revealed, are systematically collected and stored for 2294 future reference. The ability of an adversary to monitor network 2295 connections at many different points over the Internet, can allow 2296 them to perform traffic correlation attacks and identify the origin 2297 of certain VPN traffic by cross referencing the connection time of 2298 the user to the endpoint and the connection time of the endpoint to 2299 the final destination. These types of attacks, although very 2300 expensive and normally only performed by very resourceful 2301 adversaries, have been documented [spiegel] to be already in practice 2302 and could completely vanify the use of a VPN and ultimately expose 2303 the activity and the identity of a user at risk. 2305 6.2.3.7. HTTP Status Code 451 2307 Every Internet user has run into the '404 Not Found' Hypertext 2308 Transfer Protocol (HTTP) status code when trying, and failing, to 2309 access a particular website [Cath]. It is a response status that the 2310 server sends to the browser, when the server cannot locate the URL. 2311 '403 Forbidden' is another example of this class of code signals that 2312 gives users information about what is going on. In the '403' case 2313 the server can be reached, but is blocking the request because the 2314 user is trying to access content forbidden to them. This can be 2315 because the specific user is not allowed access to the content (like 2316 a government employee trying to access pornography on a work- 2317 computer) or because access is restricted to all users (like social 2318 network sites in certain countries). As surveillance and censorship 2319 of the Internet is becoming more commonplace, voices were raised at 2320 the IETF to introduce a new status code that indicates when something 2321 is not available for 'legal reasons' (like censorship): 2323 The 451 status code would allow server operators to operate with 2324 greater transparency in circumstances where issues of law or public 2325 policy affect their operation. This transparency may be beneficial 2326 both to these operators and to end-users [Bray]. 2328 The status code is named '451', a reference to Bradbury's famous 2329 novel on censorship, and the temperature (in Fahrenheit) at which 2330 bookpaper autoignites. 2332 During the IETF92 meeting in Dallas, there was discussion about the 2333 usefulness of '451'. The main tension revolved around the lack of an 2334 apparent machine-readable technical use of the information. The 2335 extent to which '451' is just 'political theatre' or whether it has a 2336 concrete technical use was heatedly debated. Some argued that 'the 2337 451 status code is just a status code with a response body' others 2338 said it was problematic because 'it brings law into the picture'. 2339 Again others argued that it would be useful for individuals, or 2340 organizations like the 'Chilling Effects' project, crawling the web 2341 to get an indication of censorship (IETF discussion on '451' - 2342 author's field notes March 2015). There was no outright objection 2343 during the Dallas meeting against moving forward on status code 2344 '451', and on December 18, 2015 the Internet Engineering Steering 2345 Group approved publication of 'An HTTP Status Code to Report Legal 2346 Obstacles'. It is now an IETF approved HTTP status code to signal 2347 when resource access is denied as a consequence of legal demands 2348 [RFC7725]. 2350 What is interesting about this particular case is that not only 2351 technical arguments but also the status code's outright potential 2352 political use for civil society played a substantial role in shaping 2353 the discussion, and the decision to move forward with this 2354 technology. 2356 It is nonetheless important to note that HTTP status code 451 is not 2357 a solution to detect all occasions of censorship. A large swath of 2358 Internet filtering occurs in the network rather than the server 2359 itself. For these forms of censorship 451 plays a limited role, as 2360 the servers will not be able to send the code, because they haven't 2361 received the requests (as is the case with servers with resources 2362 blocked by the Chinese Golden shield). Such filtering regimes are 2363 unlikely to voluntarily inject a 451 status code. The use of 451 is 2364 most likely to apply in the case of cooperative, legal versions of 2365 content removal resulting from requests to providers. One can think 2366 of content that is removed or blocked for legal reasons, like 2367 copyright infringement, gambling laws, child abuse, et cetera. Large 2368 Internet companies and search engines are constantly asked to censor 2369 content in various jurisdictions. 451 allows this to be easily 2370 discovered, for instance by initiatives like the Lumen Database. 2372 Overall, the strength of 451 lies in its ability to provide 2373 transparency by giving the reason for blocking, and giving the end- 2374 user the ability to file a complaint. It allows organizations to 2375 easily measure censorship in an automated way, and prompts the user 2376 to access the content via another path (e.g. TOR, VPNs) when (s)he 2377 encounters the 451 status code. 2379 Status code 451 impact human rights by making censorship more 2380 transparent and measurable. The status code increases transparency 2381 both by signaling the existence of censorship (instead of a much more 2382 broad HTTP error message like HTTP status code 404) as well as 2383 providing details of the legal restriction, which legal authority is 2384 imposing it, and what class of resources it applies to. This 2385 empowers the user to seek redress. 2387 6.2.3.8. DDoS attacks 2389 Many individuals, not excluding IETF engineers, have argued that DDoS 2390 attacks are fundamentally against freedom of expression. Technically 2391 DDoS attacks are when one or multiple host overload the bandwidth or 2392 resources of another host by flooding it with traffic or making 2393 resource intensive requests, causing it to temporarily stop being 2394 available to users. One can roughly differentiate three types of 2395 DDoS attacks: Volume Based Attacked (This attack aims to make the 2396 host unreachable by using up all it's bandwith, often used techniques 2397 are: UDP floods and ICMP floods), Protocol Attacks (This attacks aims 2398 to use up actual server resources, often used techniques are SYN 2399 floods, fragmented packet attacks, and Ping of Death [RFC4949]) and 2400 Application Layer Attacks (this attack aims to bring down a server, 2401 such as the webserver). 2403 DDoS attacks can thus stifle freedom of expression, complicate the 2404 ability of independent media and human rights organizations to 2405 exercise their right to (online) freedom of association, while 2406 facilitating the ability of governments to censor dissent. When it 2407 comes to comparing DDoS attacks to protests in offline life, it is 2408 important to remember that only a limited number of DDoS attacks 2409 involved solely willing participants. In the overwhelming majority 2410 of cases, the clients are hacked hosts of unrelated parties that have 2411 not consented to being part of a DDoS (for exceptions see Operation 2412 Abibil [Abibil] or the Iranian Green Movement DDoS [GreenMovement]). 2414 In addition, DDoS attacks are increasingly used as an extortion 2415 tactic. 2417 All of these issues seem to suggest that the IETF should try to 2418 ensure that their protocols cannot be used for DDoS attacks, which is 2419 consistent with the long-standing IETF consensus that DDoS is an 2420 attack that protocols should mitigate them to the extent they can 2421 [BCP72]. Decreasing the number of vulnerabilities in protocols and 2422 (outside of IETF) the number of bugs in the network stacks of routers 2423 or computers could address this issue. The IETF can clearly play a 2424 role in bringing about some of these changes but the IETF cannot be 2425 expected to take a positive stance on (specific) DDoS attacks, or 2426 create protocols to enable some attacks and inhibit others. What the 2427 IETF can do is critically reflect on its role in the development of 2428 the Internet, and how this impacts the ability of people to excercise 2429 their human rights, such as freedom of expression. 2431 7. Document Status 2433 This document has been developed within the framework of the Human 2434 Rights Protocols Considerations Research Group, based on discussions 2435 on the hrpc mailinglist and during hrpc sessions, where this document 2436 also has been extensively discussed. The draft in its current form 2437 and iteration has received eight in-depth reviews on list, and 2438 received many comments from inside and outside the IRTF and IETF 2439 community. The authors believe that the issues that have been raised 2440 by the reviewers have been addressed. 2442 8. Acknowledgements 2444 A special thanks to all members of the hrpc RG who contributed to 2445 this draft. The following deserve a special mention: 2447 - Joana Varon for helping draft the first iteration of the 2448 methodology, previous drafts and the direction of the film Net of 2449 Rights and working on the interviews at IETF92 in Dallas. 2451 - Daniel Kahn Gillmor (dkg) for helping with the first iteration of 2452 the glossary as well as a lot of technical guidance, support and 2453 language suggestions. 2455 - Claudio Guarnieri for writing the first iterations of the case 2456 studies on VPN, HTTP, and Peer to Peer. 2458 - Will Scott for writing the first iterations of the case studies on 2459 DNS, IP, XMPP. 2461 - Avri Doria for proposing writing a glossary in the first place, 2462 help with writing the initial proposals and Internet Drafts, her 2463 reviews and contributions to the glossary. 2465 and Stephane Bortzmeyer, John Curran, Barry Shein, Joe Hall, Joss 2466 Wright, Harry Halpin, and Tim Sammut who made a lot of excellent 2467 suggestions, many of which found their way directly into the text. 2468 We want to thank Amerlia Andersdotter, Stephen Farrell, Stephane 2469 Bortzemeyer, Shane Kerr, Giovane Moura, James Gannon, and Scott Craig 2470 for their reviews and testing the HRPC guidelines in the wild. We 2471 would also like to thank Molly Sauter, Arturo Filasto, Nathalie 2472 Marechal, Eleanor Saitta and all others who provided input on the 2473 draft or the conceptualization of the idea. Thanks to Edward Snowden 2474 for his comments regarding the impact of protocols on the rights of 2475 users at IETF93. 2477 9. Security Considerations 2479 As this document concerns a research document, there are no security 2480 considerations. 2482 10. IANA Considerations 2484 This document has no actions for IANA. 2486 11. Research Group Information 2488 The discussion list for the IRTF Human Rights Protocol Considerations 2489 proposed working group is located at the e-mail address hrpc@ietf.org 2490 [3]. Information on the group and information on how to subscribe to 2491 the list is at https://www.irtf.org/mailman/listinfo/hrpc 2493 Archives of the list can be found at: https://www.irtf.org/mail- 2494 archive/web/hrpc/current/index.html 2496 12. References 2498 12.1. Informative References 2500 [Abbate] Abbate, J., "Inventing the Internet", MIT Press , 2000, 2501 . 2503 [Abibil] Danchev, D., "Dissecting 'Operation Ababil' - an OSINT 2504 Analysis", 2012, . 2507 [Adrian] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., 2508 Green, M., Halderman, J., Heninger, N., Springall, D., 2509 Thome, E., Valenta, L., VanderSloot, B., Wustrow, E., 2510 Zanella Beguelin, S., and P. Zimmermann, "Imperfect 2511 Forward Secrecy: How Diffie-Hellman Fails in Practice", 2512 ACM Conference on Computer and Communications Security 2513 2015: 5-17 , 2015. 2515 [Alshalanetal] 2516 Alshalan, A., Pisharody, S., and D. Huang, "A Survey of 2517 Mobile VPN Technologies", 2016, 2518 . 2521 [Appelbaum] 2522 Appelbaum, J., Gibson, A., Kabish, V., Kampf, L., and L. 2523 Ryge, "NSA targets the privacy-conscious", 2015, 2524 . 2527 [BCP72] IETF, "Guidelines for Writing RFC Text on Security 2528 Considerations", 2003, . 2531 [Babbie] Babbie, E., "The Basics of Social Research", Belmont CA 2532 Cengage , 2010. 2534 [Benkler] Benkler, Y., "The wealth of Networks - How social 2535 production transforms markets and freedom", New Haven and 2536 London - Yale University Press , 2006, 2537 . 2539 [Berners-Lee] 2540 Berners-Lee, T. and M. Fischetti, "Weaving the Web,", 2541 HarperCollins p 208, 1999. 2543 [BernersLeeHalpin] 2544 Berners-Lee, T. and H. Halpin, "Defend the Web", 2012, 2545 . 2548 [Bhargavan] 2549 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 2550 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 2551 Breaking and Fixing Authentication over TLS", IEEE 2552 Symposium on Security and Privacy 2014: 98-113 , 2014. 2554 [Bless] Bless, R. and C. Orwat, "Values and Networks", 2015. 2556 [Blumenthal] 2557 Blumenthal, M. and D. Clark, "Rethinking the design of the 2558 Internet: The end-to-end arguments vs. the brave new 2559 world", ACM Transactions on Internet Technology, Vol. 1, 2560 No. 1, August 2001, pp 70-109. , 2001. 2562 [Bray] Bray, T., "A New HTTP Status Code for Legally-restricted 2563 Resources", 2016, . 2566 [Broeders] 2567 Broeders, D., "The public core of the Internet", WRR , 2568 2015, 2569 . 2572 [Brown] Brown, I. and M. Ziewitz, "A Prehistory of Internet 2573 Governance", Research Handbook on Governance of the 2574 Internet. Cheltenham, Edward Elgar. , 2013. 2576 [BrownMarsden] 2577 Brown, I. and C. Marsden, "Regulating code", MIT Press , 2578 2013, . 2580 [Brownetal] 2581 Brown, I., Clark, D., and D. Trossen, "Should specific 2582 values be embedded in the Internet Architecture?", Sigcomm 2583 , 2010, . 2586 [Cath] Cath, C., "A Case Study of Coding Rights: Should Freedom 2587 of Speech Be Instantiated in the Protocols and Standards 2588 Designed by the Internet Engineering Task Force?", 2015, 2589 . 2592 [CathFloridi] 2593 Cath, C. and L. Floridi, "The Design of the Internet's 2594 Architecture by the Internet Engineering Task Force (IETF) 2595 and Human Rights", November 2016. 2597 [Clark] Clark, D., "The Design Philosophy of the DARPA Internet 2598 Protocols", Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, 2599 August 1988, pp. 106-114. , 1988. 2601 [Clarketal] 2602 Clark, D., Wroclawski, J., Sollins, K., and R. Braden, 2603 "Tussle in cyberspace - defining tomorrow's Internet", ACM 2604 Digital Library , 2005, . 2607 [CoE] Council of Europe, "Applications to ICANN for community- 2608 based new generic top level domains: Opportunities and 2609 challenges from a human rights perspective", 2016, 2610 . 2613 [Collins] Collins, K., "Hacking Team's oppressive regimes customer 2614 list revealed in hack", 2015, 2615 . 2618 [Davidsonetal] 2619 Davidson, A., Morris, J., and R. Courtney, "Strangers in a 2620 strange land", Telecommunications Policy Research 2621 Conference , 2002, 2622 . 2624 [Denardis14] 2625 Denardis, L., "The Global War for Internet Governance", 2626 Yale University Press , 2014, 2627 . 2629 [Denardis15] 2630 Denardis, L., "The Internet Design Tension between 2631 Surveillance and Security", IEEE Annals of the History of 2632 Computing (volume 37-2) , 2015, . 2634 [Denzin] Denzin, N. and Y. Lincoln, "Handbook of Qualitative 2635 Research", Thousand Oaks CA Sage , 2000, 2636 . 2639 [Doty] Doty, N., "Automated text analysis of Requests for Comment 2640 (RFCs)", 2014, . 2642 [Douceur] Douceur, J., "The Sybil Attack", 2002, 2643 . 2646 [Dutton] Dutton, W., "Freedom of Connection, Freedom of Expression: 2647 the Changing legal and regulatory Ecology Shaping the 2648 Internet.", 2011, . 2651 [Elahi] Elahi, T. and I. Goldberg, "CORDON - A taxonomy of 2652 Internet Censorship Resistance Strategies", 2012, 2653 . 2656 [FIArch] "Future Internet Design Principles", January 2012, 2657 . 2660 [FOC] Ministers of the Freedom Online Coalition, "The Tallinn 2661 Agenda - Recommendations for Freedom Online", 2014, 2662 . 2666 [FRAMEWORK] 2667 ISO/IEC, ., "Information technology - Framework for 2668 internationalization, prepared by ISO/IEC JTC 1/SC 22/WG 2669 20 ISO/IEC TR 11017", 1997. 2671 [Farrow] Farrow, R., "Source Address Spoofing", 2016, 2672 . 2674 [Franklin] 2675 Franklin, U., "The Real World of Technology", 1999, 2676 . 2679 [Geertz] Clifford, G., "Kinship in Bali", Chicago University of 2680 Chicago Press. , 1975, 2681 . 2684 [Googlepatent] 2685 Google, ., "Method and device for network traffic 2686 manipulation", 2012, . 2689 [GreenMovement] 2690 Villeneuve, N., "Iran DDoS", 2009, 2691 . 2693 [Greenwald] 2694 Greenwald, G., "XKeyscore: NSA tool collects 'nearly 2695 everything a user does on the internet'", 2013, 2696 . 2699 [HRC2012] United Nations Human Rights Council, "UN General Assembly 2700 Resolution "The right to privacy in the digital age" 2701 (A/C.3/68/L.45)", 2011, 2702 . 2704 [HTML5] W3C, "HTML5", 2014, . 2706 [Haagsma] Haagsma, L., "Deep dive into QUANTUM INSERT", 2015, 2707 . 2710 [ICCPR] United Nations General Assembly, "International Covenant 2711 on Civil and Political Rights", 1976, 2712 . 2715 [ICESCR] United Nations General Assembly, "International Covenant 2716 on Economic, Social and Cultural Rights", 1966, 2717 . 2720 [Insinuator] 2721 Schiess, N., "Vulnerabilities & attack vectors of VPNs (Pt 2722 1)", 2013, . 2725 [Jabri] Jabri, V., "Discourses on Violence - conflict analysis 2726 reconsidered", Manchester University Press , 1996. 2728 [Kaye] Kaye, D., "Report of the Special Rapporteur on the 2729 promotion and protection of the right to freedom of 2730 opinion and expression", 2016, 2731 . 2734 [King] King, C., "Power, Social Violence and Civil Wars", 2735 Washington D.C. United States Institute of Peace Press , 2736 2007. 2738 [Lessig] Lessig, L., "Code - And Other Laws of Cyberspace, Version 2739 2.0.", New York Basic Books , 2006, . 2741 [Marcak] Marcak, B., Weaver, N., Dalek, J., Ensafi, R., Fifield, 2742 D., McKune, S., Rey, A., Scott-Railton, J., Deibert, R., 2743 and V. Paxson, "China's Great Fire Cannon", 2015, 2744 . 2746 [Marquis-Boire] 2747 Marquis-Boire, M., "Schrodinger's Cat Video and the Death 2748 of Clear-Text", 2014, . 2751 [Meyer] Meyer, J., "Defining and Evaluating Resilience: A 2752 Performability Perspective, presentation at International 2753 Workshop on Performability Modeling of Computer and 2754 Communication Systems.", 2009. 2756 [Mueller] Mueller, M., "Networks and States", MIT Press , 2010, 2757 . 2759 [Musiani] Musiani, F., "Giants, Dwarfs and Decentralized 2760 Alternatives to Internet-based Services - An Issue of 2761 Internet Governance", Westminister Papers in Communication 2762 and Culture , 2015, . 2764 [NETmundial] 2765 NETmundial, "NETmundial Multistakeholder Statement", 2014, 2766 . 2769 [PETS2015VPN] 2770 Pera, V., Barbera, M., Tyson, G., Haddadi, H., and A. Mei, 2771 "A Glance through the VPN Looking Glass", 2015, 2772 . 2775 [Penney] Penney, J., "Chilling Effects: Online Surveillance and 2776 Wikipedia Use", 2016, . 2779 [Peterson] 2780 Peterson, A., Gellman, B., and A. Soltani, "Yahoo to make 2781 SSL encryption the default for Webmail users. Finally.", 2782 2013, . 2785 [Pouwelse] 2786 Pouwelse, Ed, J., "Media without censorship", 2012, 2787 . 2790 [RFC0226] Karp, P., "Standardization of host mnemonics", RFC 226, 2791 DOI 10.17487/RFC0226, September 1971, 2792 . 2794 [RFC0760] Postel, J., "DoD standard Internet Protocol", RFC 760, DOI 2795 10.17487/RFC0760, January 1980, 2796 . 2798 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 2799 10.17487/RFC0791, September 1981, 2800 . 2802 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 2803 793, DOI 10.17487/RFC0793, September 1981, 2804 . 2806 [RFC0894] Hornig, C., "A Standard for the Transmission of IP 2807 Datagrams over Ethernet Networks", STD 41, RFC 894, DOI 2808 10.17487/RFC0894, April 1984, 2809 . 2811 [RFC1035] Mockapetris, P., "Domain names - implementation and 2812 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 2813 November 1987, . 2815 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2816 Communication Layers", STD 3, RFC 1122, DOI 10.17487/ 2817 RFC1122, October 1989, 2818 . 2820 [RFC1631] Egevang, K. and P. Francis, "The IP Network Address 2821 Translator (NAT)", RFC 1631, DOI 10.17487/RFC1631, May 2822 1994, . 2824 [RFC1766] Alvestrand, H., "Tags for the Identification of 2825 Languages", RFC 1766, DOI 10.17487/RFC1766, March 1995, 2826 . 2828 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 2829 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 2830 . 2832 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 2833 Technology and the Internet", BCP 200, RFC 1984, DOI 2834 10.17487/RFC1984, August 1996, 2835 . 2837 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 2838 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 2839 . 2841 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 2842 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 2843 January 1998, . 2845 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2846 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2847 December 1998, . 2849 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 2850 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 2851 . 2853 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 2854 Engineering Task Force Standard Protocols", BCP 61, RFC 2855 3365, DOI 10.17487/RFC3365, August 2002, 2856 . 2858 [RFC3536] Hoffman, P., "Terminology Used in Internationalization in 2859 the IETF", RFC 3536, DOI 10.17487/RFC3536, May 2003, 2860 . 2862 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 2863 the Middle and the Future of End-to-End: Reflections on 2864 the Evolution of the Internet Architecture", RFC 3724, DOI 2865 10.17487/RFC3724, March 2004, 2866 . 2868 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 2869 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 2870 . 2872 [RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF 2873 Technology", BCP 79, RFC 3979, DOI 10.17487/RFC3979, March 2874 2005, . 2876 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2877 Rose, "DNS Security Introduction and Requirements", RFC 2878 4033, DOI 10.17487/RFC4033, March 2005, 2879 . 2881 [RFC4084] Klensin, J., "Terminology for Describing Internet 2882 Connectivity", BCP 104, RFC 4084, DOI 10.17487/RFC4084, 2883 May 2005, . 2885 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 2886 DOI 10.17487/RFC4101, June 2005, 2887 . 2889 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 2890 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 2891 . 2893 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2894 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 2895 RFC5246, August 2008, 2896 . 2898 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2899 DOI 10.17487/RFC5321, October 2008, 2900 . 2902 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 2903 RFC 5944, DOI 10.17487/RFC5944, November 2010, 2904 . 2906 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 2907 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, DOI 2908 10.17487/RFC6101, August 2011, 2909 . 2911 [RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. 2912 Van Lieu, "Comcast's Web Notification System Design", RFC 2913 6108, DOI 10.17487/RFC6108, February 2011, 2914 . 2916 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 2917 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 2918 March 2011, . 2920 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 2921 Internationalization in the IETF", BCP 166, RFC 6365, DOI 2922 10.17487/RFC6365, September 2011, 2923 . 2925 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 2926 of Named Entities (DANE) Transport Layer Security (TLS) 2927 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2928 2012, . 2930 [RFC6701] Farrel, A. and P. Resnick, "Sanctions Available for 2931 Application to Violators of IETF IPR Policy", RFC 6701, 2932 DOI 10.17487/RFC6701, August 2012, 2933 . 2935 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 2936 Transport Security (HSTS)", RFC 6797, DOI 10.17487/ 2937 RFC6797, November 2012, 2938 . 2940 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2941 Morris, J., Hansen, M., and R. Smith, "Privacy 2942 Considerations for Internet Protocols", RFC 6973, DOI 2943 10.17487/RFC6973, July 2013, 2944 . 2946 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2947 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2948 2014, . 2950 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 2951 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2952 2015, . 2954 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2955 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 2956 10.17487/RFC7540, May 2015, 2957 . 2959 [RFC7574] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to- 2960 Peer Streaming Peer Protocol (PPSPP)", RFC 7574, DOI 2961 10.17487/RFC7574, July 2015, 2962 . 2964 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 2965 Trammell, B., Huitema, C., and D. Borkmann, 2966 "Confidentiality in the Face of Pervasive Surveillance: A 2967 Threat Model and Problem Statement", RFC 7624, DOI 2968 10.17487/RFC7624, August 2015, 2969 . 2971 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 2972 DOI 10.17487/RFC7626, August 2015, 2973 . 2975 [RFC7725] Bray, T., "An HTTP Status Code to Report Legal Obstacles", 2976 RFC 7725, DOI 10.17487/RFC7725, February 2016, 2977 . 2979 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 2980 and P. Hoffman, "Specification for DNS over Transport 2981 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2982 2016, . 2984 [RSF] RSF, "Syria using 34 Blue Coat Servers to spy on Internet 2985 users", 2013, . 2988 [Rachovitsa] 2989 Rachovitsa, A., "Engineering 'Privacy by Design' in the 2990 Internet Protocols - Understanding Online Privacy both as 2991 a Technical and a Human Rights Issue in the Face of 2992 Pervasive Monitoring", International Journal of Law and 2993 Information Technology , 2015, . 2996 [Richie] Richie, J. and J. Lewis, "Qualitative Research Practice - 2997 A Guide for Social Science Students and Researchers", 2998 London Sage , 2003, . 3002 [Rideout] Rideout, A., "Making security easier", 2008, 3003 . 3006 [Saltzer] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments 3007 in System Design", ACM TOCS, Vol 2, Number 4, November 3008 1984, pp 277-288. , 1984. 3010 [Schillace] 3011 Schillace, S., "Default https access for Gmail", 2010, 3012 . 3015 [Schneier] 3016 Schneier, B., "Attacking Tor - how the NSA targets users' 3017 online anonymity", 2013, 3018 . 3021 [Schroeder] 3022 Schroeder, I. and B. Schmidt, "Introduction - Violent 3023 Imaginaries and Violent Practice", London and New York 3024 Routledge , 2001, . 3028 [UDHR] United Nations General Assembly, "The Universal 3029 Declaration of Human Rights", 1948, 3030 . 3032 [UNGA2013] 3033 United Nations General Assembly, "UN General Assembly 3034 Resolution "The right to privacy in the digital age" 3035 (A/C.3/68/L.45)", 2013, 3036 . 3038 [W3CAccessibility] 3039 W3C, "Accessibility", 2015, 3040 . 3042 [W3Ci18nDef] 3043 W3C, "Localization vs. Internationalization", 2010, 3044 . 3046 [WP-Tempora] 3047 Wikipedia, "Tempora", 2016, 3048 . 3050 [WSJ] Sonne, P. and M. Coker, "Firms Aided Libyan Spies", 2011, 3051 . 3054 [WynsbergheMoura] 3055 Wynsberghe, A. and G. Moura, "The concept of embedded 3056 values and the example of internet security", 2013, 3057 . 3059 [Zittrain] 3060 Zittrain, J., "The Future of the Internet - And How to 3061 Stop It", Yale University Press , 2008, 3062 . 3065 [ars] Anderson, N., "P2P researchers - use a blocklist or you 3066 will be tracked... 100% of the time", 2007, 3067 . 3071 [bbc-wikileaks] 3072 BBC, "Whistle-blower site taken offline", 2008, 3073 . 3075 [bitmessage] 3076 Bitmessage, "Bitmessage Wiki?", 2014, 3077 . 3079 [caida] Dainotti, A., Squarcella, C., Aben, E., Claffy, K., 3080 Chiesa, M., Russo, M., and A. Pescape, "Analysis of 3081 Country-wide Internet Outages Caused by Censorship", 2013, 3082 . 3085 [dict] BusinessDictionary.com. WebFinance, Inc., "Reliability 3086 (dictionary entry)", 2016, 3087 . 3090 [freenet1] 3091 Freenet, "What is Freenet?", n.d., 3092 . 3094 [freenet2] 3095 Ian Clarke, ., "The Philosphy behind Freenet?", n.d., 3096 . 3098 [greatfirewall] 3099 Anonymous, ., "Towards a Comprehensive Picture of the 3100 Great Firewall's DNS Censorship", 2014, 3101 . 3104 [hall] Hall, J., Aaron, M., and B. Jones, "A Survey of Worldwide 3105 Censorship Techniques", 2015, 3106 . 3109 [namecoin] 3110 Namecoin, "Namecoin - Decentralized secure names", 2015, 3111 . 3113 [natusage] 3114 Maier, G., Schneider, F., and A. Feldmann, "NAT usage in 3115 Residential Broadband networks", 2011, 3116 . 3119 [newegg] Mullin, J., "Newegg on trial: Mystery company TQP rewrites 3120 the history of encryption", 2013, . 3124 [notewell] 3125 IETF, "Note Well", 2015, . 3128 [patentpolicy] 3129 W3C, "W3C Patent Policy", 2004, 3130 . 3132 [pidgin] js, . and Pidgin Developers, "-XMPP- Invisible mode 3133 violating standard", July 2015, 3134 . 3136 [spiegel] SPIEGEL, "Prying Eyes - Inside the NSA's War on Internet 3137 Security", 2014, 3138 . 3141 [sslstrip] 3142 Marlinspike, M., "Software >> sslstrip", 2011, 3143 . 3145 [techyum] Violet, ., "Official - vb.ly Link Shortener Seized by 3146 Libyan Government", 2010, . 3150 [torproject] 3151 The Tor Project, ., "Tor Project - Anonymity Online", 3152 2007, . 3154 [torrentfreak1] 3155 Van der Sar, E., "Proposal for research on human rights 3156 protocol considerations", 2015, . 3160 [torrentfreak2] 3161 Andy, ., "LAWYERS SENT 109,000 PIRACY THREATS IN GERMANY 3162 DURING 2013", 2014, . 3166 [tribler] Delft University of Technology, Department EWI/PDS/ 3167 Tribler, "About Tribler", 2013, . 3170 [ververis] 3171 Vasilis, V., Kargiotakis, G., Filasto, A., Fabian, B., and 3172 A. Alexandros, "Understanding Internet Censorship Policy - 3173 The Case of Greece", 2015, 3174 . 3177 [wikileaks] 3178 Sladek, T. and E. Broese, "Market Survey : Detection & 3179 Filtering Solutions to Identify File Transfer of Copyright 3180 Protected Content for Warner Bros. and movielabs", 2011, 3181 . 3184 [xmppmanifesto] 3185 Saint-Andre, P. and . XMPP Operators, "A Public Statement 3186 Regarding Ubiquitous Encryption on the XMPP Network", 3187 2014, 3188 . 3191 12.2. URIs 3193 [1] mailto:node@domain/home 3195 [2] mailto:node@domain/work 3197 [3] mailto:hrpc@ietf.org 3199 Authors' Addresses 3201 Niels ten Oever 3202 ARTICLE 19 3204 EMail: niels@article19.org 3206 Corinne Cath 3207 Oxford Internet Institute 3209 EMail: corinnecath@gmail.com