idnits 2.17.1 draft-irtf-hrpc-association-05.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 78 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2020) is 1397 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'APC1' is mentioned on line 404, but not defined -- Looks like a reference, but probably isn't: '1' on line 1329 -- Looks like a reference, but probably isn't: '2' on line 1331 -- Looks like a reference, but probably isn't: '3' on line 1333 == Unused Reference: 'Haas' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'Mosco' is defined on line 1091, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 1189, but no explicit reference was found in the text == Unused Reference: 'SeawrightGerring' is defined on line 1251, but no explicit reference was found in the text == Unused Reference: 'Star' is defined on line 1261, but no explicit reference was found in the text == Unused Reference: 'StarRuhleder' is defined on line 1266, but no explicit reference was found in the text == Unused Reference: 'Tocqueville' is defined on line 1278, but no explicit reference was found in the text == Unused Reference: 'Undertake' is defined on line 1301, but no explicit reference was found in the text == Unused Reference: 'Weiser' is defined on line 1318, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 155 (Obsoleted by RFC 168) -- Obsolete informational reference (is this intentional?): RFC 1771 (Obsoleted by RFC 4271) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 8 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 University of Amsterdam 4 Intended status: Informational S. Couture 5 Expires: December 31, 2020 University de Montreal 6 G. Perez de Acha 7 Derechos Digitales 8 June 29, 2020 10 Freedom of Association on the Internet 11 draft-irtf-hrpc-association-05 13 Abstract 15 This document discusses the relationships between the Internet 16 architecture and the ability of people to exercise their right to 17 freedom of assembly and association online. The Internet 18 increasingly mediates our lives, our relationships and our ability to 19 exercise our human rights. As a global forum, the Internet provides 20 a public space, yet it is predominantly built on private 21 infrastructure. Since Internet protocols play a central role in the 22 management, development and use of the Internet, we analyse the 23 relationship between protocols and the rights to assemble and 24 associate in order to mitigate infringements upon those rights. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 31, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Vocabulary used . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Research question . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Literature Review . . . . . . . . . . . . . . . . . . . . . . 5 65 5.1. FAA definition and core treaties . . . . . . . . . . . . 5 66 5.2. FAA in the digital era . . . . . . . . . . . . . . . . . 7 67 5.3. Specific questions raised from the literature review . . 10 68 6. Cases and examples . . . . . . . . . . . . . . . . . . . . . 11 69 6.1. Conversing . . . . . . . . . . . . . . . . . . . . . . . 11 70 6.1.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . 11 71 6.1.2. Multi-party video conferencing . . . . . . . . . . . 12 72 6.1.3. Internet Relay Chat . . . . . . . . . . . . . . . . . 13 73 6.2. Peer-to-peer networks and systems . . . . . . . . . . . . 14 74 6.2.1. Peer-to-peer system architectures . . . . . . . . . . 14 75 6.2.2. Version control . . . . . . . . . . . . . . . . . . . 15 76 6.3. Grouping together (identities) . . . . . . . . . . . . . 16 77 6.3.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 6.3.2. Autonomous Systems . . . . . . . . . . . . . . . . . 17 79 7. Discussion: Establishing the relation . . . . . . . . . . . . 18 80 8. Discussion: Protocols and Platforms . . . . . . . . . . . . . 19 81 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 13. Research Group Information . . . . . . . . . . . . . . . . . 21 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 14.1. Informative References . . . . . . . . . . . . . . . . . 21 88 14.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 91 1. Introduction 93 "In the digital age, the exercise of the rights of peaceful assembly 94 and association has become largely dependent on business enterprises, 95 whose legal obligations, policies, technical standards, financial 96 models and algorithms can affect these freedoms". 98 - Annual Report to the UN Human Rights Council by the Special Rapporteur on the rights to freedom of peaceful assembly and of association (2019). 100 We shape our tools and, thereafter, our tools shape us.  101 - John Culkin (1967) 103 The current draft continues the work started in "Research into Human 104 Rights Protocol Considerations" [RFC8280] by investigating the impact 105 of Internet protocols on a specific set of human rights, namely the 106 right to freedom of assembly and association. Taking into 107 consideration the international human rights framework regarding 108 freedom of assembly and association, the present document seeks to 109 deepen the relationship between this human right and Internet 110 architecture, protocols, and standards. In that way, we continue the 111 work of the Human Rights Protocol Consideration Research Group, as 112 laid out in its charter, where one of the research aims is "to expose 113 the relation between protocols and human rights, with a focus on the 114 rights to freedom of expression and freedom of assembly" 115 [hrpc-charter]. The conclusions may inform the development of new 116 guidelines for protocol developers. 118 2. Vocabulary used 120 Architecture The design of a structure 122 Autonomous System (AS) Autonomous Systems are the unit of routing 123 policy in the modern world of exterior routing [RFC1930]. 125 Within the Internet, an autonomous system (AS) is a collection of 126 connected Internet Protocol (IP) routing prefixes under the 127 control of one or more network operators on behalf of a single 128 administrative entity or domain that presents a common, clearly 129 defined routing policy to the Internet [RFC1930]. 131 The classic definition of an Autonomous System is a set of routers 132 under a single technical administration, using an interior gateway 133 protocol and common metrics to route packets within the AS, and 134 using an exterior gateway protocol to route packets to other ASs 135 [RFC1771]. 137 Border Gateway Protocol (BGP) An inter-Autonomous System routing 138 protocol [RFC4271]. 140 Connectivity The extent to which a device or network is able to 141 reach other devices or networks to exchange data. The Internet is 142 the tool for providing global connectivity [RFC1958]. Different 143 types of connectivity are further specified in [RFC4084]. The 144 combination of the end-to-end principle, interoperability, 145 distributed architecture, resilience, reliability and robustness 146 are the enabling factors that result in connectivity to and on the 147 Internet. 149 Decentralization Implementation or deployment of standards, 150 protocols or systems without one single point of control. 152 Distributed system A system with multiple components that have their 153 behavior co-ordinated via message passing. These components are 154 usually spatially separated and communicate using a network, and 155 may be managed by a single root of trust or authority. 156 [Troncosoetal] 158 Infrastructure Underlying basis or structure for a functioning 159 society, organization or community. Because infrastructure is a 160 precondition for other activities it has a procedural, rather than 161 static, nature due to its social and cultural embeddedness 162 [PipekWulf] [Bloketal]. This means that infrastructure is always 163 relational: infrastructure always develops in relation to 164 something or someone [Bowker]. 166 Internet The Network of networks, that consists of Autonomous 167 Systems that are connected through the Internet Protocol (IP). 169 A persistent socio-technical system over which services are 170 delivered [Mainwaringetal], 172 A techno-social assemblage of devices, users, sensors, networks, 173 routers, governance, administrators, operators and protocols 175 An emergent-process-driven thing that is born from the collections 176 of the ASes that happen to be gathered together at any given time. 177 The fact that they tend to interact at any given time means it is 178 an emergent property that happens because they use the protocols 179 defined at IETF. 181 3. Research question 183 The research question of this document is: what are the 184 considerations of the right to freedom of assembly and association 185 for protocol development? 187 4. Methodology 189 The point of departure of the present work [RFC8280] is an initial 190 effort to expose the relationship between human rights and the 191 Internet architecture, specifically protocols and standards. As 192 such, [RFC8280] was inductive and exploratory in nature. The 193 methodology in this previous work was based on discourse analysis of 194 RFCs, interviews with Members of the IETF community and participant 195 observation in IETF working groups, with the goal of identifying 196 technical concepts related to human rights. This work resulted in 197 the proposal of guidelines to describe a relationship between the 198 right to freedom of assembly and association, and connectivity, 199 security, censorship resistance, anonymity, pseudonymity, 200 accessibility, decentralization, adaptability, and outcome 201 transparency. 203 In this document we deepen our exploration of human rights and 204 protocols by assessing one specific set of human rights: freedom of 205 association and assembly, abbreviated as FAA. Our methodology for 206 doing so is the following: first we provide a brief twofold 207 literature review addressing the philosophical and legal definitions 208 of FAA and how this right has already been interpreted or analysed in 209 relation to the digital. This literature review is not exhaustive 210 nor systematic but aims at providing some lines of questioning that 211 could later be used for protocol development. The second part of our 212 methodology looks at some cases of Internet protocols that are 213 relevant to the sub-questions highlighted in the literature review, 214 and analyses how these protocols facilitate and inhibit the right to 215 assembly and association. 217 5. Literature Review 219 5.1. FAA definition and core treaties 221 The rights to freedom of association and assembly are defined and 222 guaranteed by many national laws and international treaties. Article 223 20 of the Universal Declaration of Human Rights [UDHR] states for 224 instance that "Everyone has the right to freedom of peaceful assembly 225 and association" and that "No one may be compelled to belong to an 226 association". Article 23 further guarantees that "Everyone has the 227 right to form and to join trade unions for the protection of his 228 interests". In the International Covenant on Civil and Political 229 Rights [ICCPR], article 21 stipulates that "The right of peaceful 230 assembly shall be recognised" and that "No restrictions may be placed 231 on the exercise of this right other than those imposed in conformity 232 with the law and which are necessary in a democratic society in the 233 interests of national security or public safety, public order (ordre 234 public), the protection of public health or morals or the protection 235 of the rights and freedoms of others" while article 22 states that 236 "Everyone shall have the right to freedom of association with others, 237 including the right to form and join trade unions". Other treaties 238 are sometimes cited as the source and framework to the right to 239 freedom of association and assembly. The Australian government 240 [Australia] refers for instance to Article 5 of the Convention on the 241 Elimination of All Forms of Racial Discrimination [CERD] which 242 stipulates that freedom of peaceful assembly and association should 243 be guaranteed "without discrimination as to race, colour, national or 244 ethnic origin"; Article 15 of the Convention on the Rights of the 245 Child [CRC] which recognises the right to child pending the 246 restrictions cited above; and Article 21 of the Convention on the 247 Rights of Persons with Disabilities [CRPD] which insists on usable 248 and accessible formats and technologies appropriate for persons with 249 different kinds of disabilities. 251 In a more philosophical perspective, Brownlee and Jenkins make some 252 interesting distinctions in regard to the concepts of association, 253 assembly and interaction. On one hand, "interaction" refers to any 254 kind of interpersonal and often incidental engagements in daily life, 255 like encountering strangers on a bus. Interaction is seen as a 256 "prerequisite" for association. "Assembly", on the other hand, has a 257 more political connotation and is often used to refer to activists, 258 protesters, or members of a group in a deliberating event. In 259 between the two, "association" refers to more "persistent 260 connections" that are not necessarily political in nature. The 261 authors thus distinguish between intimate associations, like 262 friendship, love or family, and collective associations like trade 263 union, commercial business, or "expressive associations" like civil 264 rights organizations or lgbtqia associations. For Brownlee and 265 Jenkins, the right to association is linked to different relative 266 freedoms: permission (to association or dissociate), claim-right (to 267 oppose others interfering with our conduct), power (to alter the 268 status of our association), and immunity (from other people 269 interfering in our right). Freedom of association and assembly thus 270 refers both to the individual right to join or leave a group and to 271 the collective right to form or dissolve a group and to organize 272 itself. 274 In international law, the right to freedom of assembly and 275 association protects any collective, gathered either permanently or 276 temporarily for "peaceful" purposes. It is important to highlight 277 the dimension of "freedom" because the right to freedom of 278 association and assembly is voluntary and uncoerced: anyone can join 279 or leave a group by choice, which in turn means one should not be 280 forced to either join, stay or leave. The difference between freedom 281 of assembly and freedom of association is merely one of degree: the 282 former tends to have an informal and ephemeral nature, whereas the 283 latter refers to established and permanent bodies with specific 284 objectives. Nonetheless, both are protected in the same way. Where 285 an assembly is an intentional and temporary gathering of a collective 286 in a private or public space for a specific purpose: demonstrations, 287 indoor meetings, strikes, processions, rallies or even sits-in 288 [UNHRC]; association has a more formal and established nature. It 289 refers to a group of individuals or legal entities brought together 290 in order to collectively act, express, pursue or defend a field of 291 common interests [UNGA]. Think of civil society organizations, 292 clubs, cooperatives, NGOs, religious associations, political parties, 293 trade unions or foundations. 295 Brownlee and Jenkins also more explicitly address the right to 296 exclude someone from an association, and the right to leave an 297 association. In all this, they insist that freedom of association 298 and assembly is never absolute. Parents, for instance, have limited 299 rights to exclude their underage children from the family household. 300 Excluding someone from an association based on their sex, race or 301 other individual characteristic is also often contentious if not 302 illegal. (Might go on to discuss other legitimate limits of FAA). 304 5.2. FAA in the digital era 306 The right to freedom of assembly and association is the subject of 307 increasing discussions and analysis. In 2016, the Council of Europe 308 published a report, "Report by the Committee of experts on cross- 309 border flow of Internet traffic and Internet freedom on Freedom of 310 assembly and association on the Internet" [MSI-INT], which notes that 311 while the Internet and technologies are not explicitly mentioned in 312 international treaties, these treaties nevertheless apply to "the 313 online environment". The report argues that the "Internet is the 314 public sphere of the 21st century", something demonstrated by the 315 fact that informal associations can be gathered at scale in a matter 316 of hours on the Internet, and that digital communication tools often 317 serve to facilitate, publicize and otherwise enable presential 318 associations or assemblies, like protests or demonstrations. The 319 report also notes the negative ways in which the Internet can also be 320 used to promote or facilitate terrorism, urban violence and hate 321 speech, thus insisting on the "extremely important and urgent" need 322 to fight online terrorist activities such as recruitment or 323 mobilization, while at the same time respecting the right to peaceful 324 assembly and association of other users. The report mentions the 325 following cases that could help further our reflection: 327 - Instances of network shutdowns in the Arab Spring, to prevent 328 people from organising or assembling 330 - California's Bay Area Rapid Transit (BART) shutdown of mobile 331 phone service, to avoid protester violence and disruption of 332 service 334 - The wholesale blocking of Google as a violation of freedom of 335 expression 337 - Telus, a telecom company which blocked customers' access to 338 websites critical of Telus during a Telecommunications Workers 339 Union strike against it 341 - The targeting of social media users who call for or organise 342 protests though the Internet in Turkey's Gezi Park protests 344 - Mass surveillance or other interferences with privacy in the 345 context of law enforcement and national security 347 - Use of VPNs (Virtual Private Networks) to the TOR network to 348 ensure anonymity 350 - Distributed Denial of Service attacks (DDoS) as civil 351 disobedience. 353 More recently, the 2019 Annual Report addressed to the UN Human 354 Rights Council by the Special Rapporteur on the rights to freedom of 355 peaceful assembly and of association, also notes the opportunities 356 and challenges posed by digital networks to the rights to freedom of 357 peaceful assembly and of association. The report recommends that 358 international human rights norms and principles should also be used 359 as a framework "that guides digital technology companies' design, 360 control and governance of digital technologies". The report states 361 that "technical standards" in particular can affect the freedom of 362 association and assembly, and makes some recommendations of which the 363 following could be relevant to our discussion: 365 - "[Undertake] human rights impact assessments which incorporate the 366 rights to freedom of peaceful assembly and of association when 367 developing or modifying their products and services," 369 - "increase the quality of participation in and implementation of 370 existing multi-stakeholder initiatives," 372 - "collaborate with governments and civil society to develop 373 technology that promotes and strengthens human rights," 375 - "support the research and development of appropriate technological 376 solutions to online harassment, disinformation and propaganda, 377 including tools to detect and identify State-linked accounts and 378 bots," and 380 - "adopt monitoring indicators that include specific concerns 381 related to freedom of peaceful assembly and association." 382 (Possible gap looking at FAA and interoperability) In one of their 383 "training kits", the Association of Progressive Communications 384 (APC) addressed different impacts of the Internet on association 385 and assembly and raised three particular issues worthy of note: 387 1. Organisation of protests. Internet and social media is an 388 enabler of protests, such as was seen in the "Arab Spring". Some 389 of these protests - such as online petitions and campaigns - are 390 similar to offline association and assembly, but other forms of 391 protest are inherent to the Internet like hacking andDDoS, and 392 are subject to controversy within the Internet community, some 393 people finding it legitimate, and others not. 395 2. Surveillance. While the Internet facilitates association, 396 association in turn leaves of a lot of traces which can be used 397 by law enforcement but also for repressing political dissent. As 398 APC notes, even the threat of surveillance can deter association. 400 3. Anonymity and pseudonymity can be useful protection mechanisms 401 for those who would like to attend legitimate associations 402 without facing retribution. On the other hand, anonymity can be 403 used to harm society, such as in online fraud or sexual 404 predation. [APC1] 406 (TBD) [Sauter] 408 Online association and assembly are the starting point of group 409 mobilization in modern democracies, and even more so where physical 410 gatherings have been impossible or dangerous [APC2]. Throughout the 411 world - from the Arab Spring to Latin American student movements and 412 the #WomensMarch - the Internet has played a crucial role by 413 providing means for the fast dissemination of information otherwise 414 mediated by the press, or even forbidden by the government [Pensado]. 415 According to Hussain and Howard, the Internet helped to "build 416 solidarity networks and identification of collective identities and 417 goals, extend the range of local coverage to international broadcast 418 networks" and served as a platform for contestation for "the future 419 of civil society and information infrastructure" [HussainHoward]. 420 The IETF itself, defined as a 'open global community' of network 421 designers, operators, vendors, and researchers [RFC3233], is also 422 protected by freedom of assembly and association. Discussions, 423 comments and consensus around RFCs are possible because of the 424 collective expression that freedom of association and assembly 425 allows. The very word "protocol" found its way into the language of 426 computer networking based on the need for collective agreement among 427 network users [HafnerandLyon]. 429 RFC8280 is a paper on Internet protocols and human rights and in turn 430 discusses issues of FAA, specifically: 432 - The expansion of DNS for generic namespace as enabler of 433 association for minorities. 435 - The difficulty to compare DDoS with offline protestation as not 436 everyone participates willingly in DDoS. It is in particular 437 suggested that IETF "should try to ensure that their protocols 438 cannot be used for DDoS attacks" 440 - Freedom of association can be threatened by the denial of access 441 of certain services, or by surveillance. 443 - Connectivity can impact freedom of assembly and association 444 (6.2.2) 446 - "Open, secure, and reliable connectivity is necessary (although 447 not sufficient) to exercise human rights such as freedom of 448 expression and freedom of association" 450 5.3. Specific questions raised from the literature review 452 Here are some questions raised from the literature review that can 453 have implications for protocol design: 455 1. As a general matter, what are the features of protocols that 456 enable freedom of association and assembly? Can protocols 457 facilitate agency of membership in associations, assemblies and 458 interactions? Where in the stack do we care for FAA? 460 2. Does protocol development sufficiently consider the enabling of 461 freedom of association without discrimination as to race, colour, 462 national, ethnic origin? 464 3. Does protocol development sufficiently consider usable and 465 accessible formats and technologies appropriate for persons with 466 different kinds of disabilities? 468 4. Is it possible to distinguish "peaceful" and "non-peaceful" 469 association from the perspective of protocol development? If 470 yes, can and should protocols be designed to limit "non-peaceful" 471 association? 473 5. In particular, should protocols be designed to enable legitimate 474 limitations on association in the interests of "national security 475 or public safety, public order, the protection of public health 476 or morals or the protection of the rights and freedoms of 477 others", as stated in the ICCPR article 21? 479 6. Can a protocol be designed to legitimately exclude someone from 480 an association? 482 7. In general, what kind of human rights impact assessments should 483 be made to incorporate the rights to freedom of peaceful assembly 484 and of association when developing protocols? 486 6. Cases and examples 488 As the Internet mediates collective action and collaboration, it 489 impacts on freedom of association and assembly. To answer our 490 research question regarding how internet architecture enable and/or 491 inhibits such human right, we researched several independent and 492 typical cases related to protocols that have been either adopted by 493 the IETF, or are widely used on the Internet. Our goal is to figure 494 out whether they facilitate freedom of assembly and association, or 495 whether they inhibit it through their design or implementation. We 496 also indicate, per case, the interrelation with issues in [RFC8280]. 498 6.1. Conversing 500 An interactive conversation between two or more people forms the 501 basis to organize and associate. According to Anderson "the 502 relationship between political conversation and engagement in the 503 democratic process is strong." [Anderson]. A conversation is 504 inherently of social nature. Therefore, by these definitions the 505 core of the "political" is essentially assembly or association: a 506 basis for the development of social cohesion in society. 508 6.1.1. Mailing Lists 510 Since the beginning of the Internet mailing lists have been a key 511 site of assembly and association [RFC0155] [RFC1211]. In fact, 512 mailing lists were one of the Internet's first functionalities 513 [HafnerandLyon]. 515 In 1971, four years after the invention of email, the first mailing 516 list was created to talk about the idea of using Arpanet for 517 discussion. What had initially propelled the Arpanet project forward 518 as a resource sharing platform was gradually replaced by the idea of 519 a network as a means of bringing people together [Abbate]. More than 520 45 years after, mailing lists are pervasive and help communities to 521 engage, have discussions, share information, ask questions, and build 522 ties. Even as social media and discussion forums grow, mailing lists 523 continue to be widely used [AckermannKargerZhang] and are still a 524 crucial tool to organise groups and individuals around themes and 525 causes [APC]. 527 Mailing lists' pervasive use are partly explained because they allow 528 for "free" association: people subscribe (join) and unsubscribe 529 (leave) as they please. Mailing lists also allow for association of 530 specific groups on closed lists. Furthermore, the archival function 531 of mailinglists allows for posterior accountability and analysis. 532 The downsides of mailinglists are similar to the ones generally 533 associated with e-mail, except that end-to-end encryption such as 534 OpenPGP [RFC4880] and S/MIME [RFC5751] are not possible because the 535 final recipients are not known. There have been experimental 536 solutions to address this issue such as Schleuder [Schleuder], but 537 this has not been standardized or widely deployed. 539 This case relates to the following considerations in [RFC8280]: - 540 Security - Privacy - Decentralization - Censorship Resistance - Open 541 Standards - Confidentiality 543 6.1.2. Multi-party video conferencing 545 Multi-party video conferencing protocols like WebRTC [RFC6176] 546 [RFC7118] allow for robust, bandwidth-adaptive, wideband and super- 547 wideband video and audio discussions in groups. 'The WebRTC protocol 548 was designed to enable responsive real-time communications over the 549 Internet, and is instrumental in allowing streaming video and 550 conferencing applications to run in the browser. In order to easily 551 facilitate direct connections between computers (bypassing the need 552 for a central server to act as a gatekeeper), WebRTC provides 553 functionality to automatically collect the local and public IP 554 addresses of Internet users (ICE or STUN). These functions do not 555 require consent from the user, and can be instantiated by sites that 556 a user visits without their awareness. The potential privacy 557 implications of this aspect of WebRTC are well documented, and 558 certain browsers have provided options to limit its behavior.' 559 [AndersonGuarnieri]. 561 Even though some multi-party video conferencing tools facilitate 562 freedom of assembly and association, their own configuration might 563 might pose concrete risks for those who use them. One the one hand 564 WebRTC is providing resilient channels of communications, but on the 565 other hand it also exposes information about those who are using the 566 tool which might lead to increased surveillance, identification and 567 the consequences that might be derived from that. This is especially 568 concerning because the usage of a VPN does not protect against the 569 exposure of IP addresses [Crawford]. 571 The risk of surveillance is also true in an offline space, but this 572 is generally easy to analyze for the end-user. Security and privacy 573 expectations of the end-user could be either improved or made 574 explicit. This in turn would result in a more secure and/or private 575 exercise of the right to freedom of assembly or association. 577 This case relates to the following considerations in [RFC8280]: - 578 Security - Privacy - Decentralization - Censorship Resistance - Open 579 Standards - Anonymity - Confidentiality 581 6.1.3. Internet Relay Chat 583 Internet Relay Chat (IRC) is an application layer protocol that 584 enables communication in the form of text through a client/server 585 networking model [RFC2810]. In other words, a chat service. IRC 586 clients are computer programs that a user can install on their 587 system. These clients communicate with chat servers to transfer 588 messages to other clients. 590 For order to be kept within the IRC network, special classes of users 591 become "operators" and are allowed to perform general maintenance 592 functions on the network: basic network tasks such as disconnecting 593 (temporary or permanently) and reconnecting servers as needed 594 [RFC2812]. One of the most controversial power of operators is the 595 ability to remove a user from the connected network by 'force', i.e., 596 operators are able to close the connection between any client and 597 server [RFC2812]. 599 IRC servers may deploy different policies for the ability of users to 600 create their own channels or 'rooms', and for the delegation of 601 'operator'-rights in such spaces. Some IRC servers support SSL/TLS 602 connections for security purposes [RFC7194] which helps stop the use 603 of packet sniffer programs to obtain the passwords of IRC users, but 604 has little use beyond this scope due to the public nature of IRC 605 channels. TLS connections require both client and server support 606 (that may require the user to install TLS binaries and IRC client 607 specific patches or modules on their computers). Some networks also 608 use TLS for server to server connections, and provide a special 609 channel flag (such as +S) to only allow TLS-connected users on the 610 channel, while disallowing operator identification in clear text, to 611 better utilize the advantages that TLS provides. 613 This case relates to the following considerations in [RFC8280]: - 614 Security - Privacy - Censorship Resistance 616 6.2. Peer-to-peer networks and systems 618 At the organizational level, peer production is one of the most 619 relevant innovations from Internet mediated social practices. 620 According to [Benkler] these networks imply 'open collaborative 621 innovation and creation, performed by diverse, decentralized groups 622 organized principally by neither price signals nor organizational 623 hierarchy, harnessing heterogeneous motivations, and governed and 624 managed based on principles other than the residual authority of 625 ownership implemented through contract.' [Benkler]. 627 In his book The Wealth of Networks, Benkler significantly expands on 628 his definition of commons-based peer production. In his view, what 629 distinguishes commons-based production is that it doesn't rely upon 630 or propagate proprietary knowledge: "The inputs and outputs of the 631 process are shared, freely or conditionally, in an institutional form 632 that leaves them equally available for all to use as they choose at 633 their individual discretion." [Benkler] To ensure that the knowledge 634 generated is available for free use, commons-based projects are often 635 shared under an open license. 637 6.2.1. Peer-to-peer system architectures 639 Peer-to-peer (P2P) is essentially a model of how people interact in 640 real life because "we deal directly with one another whenever we wish 641 to" [Vu]. Usually if we need something we ask our peers, who in turn 642 refer us to other peers. In this sense, the ideal definition of P2P 643 is that "nodes are able to directly exchange resources and services 644 between themselves without the need for centralized servers" where 645 each participating node typically acts both as a server and as a 646 client [Vu]. RFC 5694 has defined it as peers or nodes that should 647 be able to communicate directly between themselves without passing 648 intermediaries, and that the system should be self-organizing and 649 have decentralized control [RFC5694]. With this in mind, the 650 ultimate model of P2P is a completely decentralized system, which is 651 more resistant to speech regulation, immune to single points of 652 failure and has a higher performance and scalability. Nonetheless, 653 in practice some P2P systems are supported by centralized servers and 654 some others have hybrid models where nodes are organized into two 655 layers: the upper tier servers and the lower tier common nodes [Vu]. 657 Since the ARPANET project, the original idea behind the Internet was 658 conceived as what we would now call a peer-to-peer system [RFC0001]. 659 Over time it has increasingly shifted towards a client/server model 660 with "millions of consumer clients communicating with a relatively 661 privileged set of servers" [NelsonHedlun]. 663 Whether for resource sharing or data sharing, P2P systems are 664 enabling freedom of assembly and association. Not only do they allow 665 for effective dissemination of information, but they leverage 666 computing resources by diminishing costs allowing for the formation 667 of open collectives at the network level. At the same time, in 668 completely decentralized systems the nodes are autonomous and can 669 join or leave the network as they want -a characteristic that makes 670 the system unpredictable: a resource might be only sometimes 671 available, and some other resources might be missing or incomplete 672 [Vu]. Lack of information might in turn makes association or 673 assembly more difficult. 675 Additionally, when architecturally assessing the role of P2P systems 676 we could say that: "the main advantage of centralized P2P systems is 677 that they are able to provide a quick and reliable resource locating. 678 Their limitation, however, is that the scalability of the systems is 679 affected by the use of servers. While decentralized P2P systems are 680 better than centralized P2P systems in this aspect, they require a 681 longer time in resource locating. As a result, hybrid P2P systems 682 have been introduced to take advantage of both centralized and 683 decentralized architectures. Basically, to maintain the scalability, 684 similar to decentralized P2P systems, there are no servers in hybrid 685 P2P systems. However, peer nodes that are more powerful than others 686 can be selected to act as servers to serve others. These nodes are 687 often called super peers. In this way, resource locating can be done 688 by both decentralized search techniques and centralized search 689 techniques (asking super peers), and hence the systems benefit from 690 the search techniques of centralized P2P systems." [Vu] 692 This case relates to the following considerations in [RFC8280]: - 693 Security - Privacy - Decentralization - Censorship Resistance - Open 694 Standards - Anonymity - Heterogeneity Support - Integrity - 695 Authenticity - Adaptability 697 6.2.2. Version control 699 Ever since developers needed to collaboratively write, maintain and 700 discuss large code basis for the Internet there have been different 701 approaches of doing so. The easiest approach has been discussing 702 code through mailing lists even though this has proven to be hard 703 when maintaining the most recent versions, which is why version 704 control systems ultimately make sense. 706 A version control system is a piece of software that enables 707 developers on a software team to work together and also archive a 708 complete history of their work [Sink]. This allows teams to be 709 working simultaneously on updated versions. According to Sink, 710 broadly speaking, the history of version control tools can be divided 711 into three generations. In the first one, concurrent development 712 meant that only one person could be working on a file at a time. The 713 second generation tools permit simultaneous modifications as long as 714 users merge the current revisions into their work before they are 715 allowed to commit. The third generation tools allow merge and commit 716 to be separated [Sink]. 718 Interestingly no version control system has ever been standardized in 719 the IETF whereas the version control systems like Subversion and Git 720 are widely used within the community and working groups. There has 721 been a spirited discussion on whether working groups should use 722 centralized forms of the Git protocol, such as those offered by 723 Gitlab or Github. Proponents argue that this simplifies the workflow 724 and allows for more transparency. Opponents argue that the reliance 725 on a centralized service which is not merely using the Git protocol 726 but also uses non-standardized options like an Issue-Tracker, makes 727 the process less transparent and reliant on a third party. 729 The IETF has not made a decision on the use of centralized instances 730 of Git, such as Github or Gitlab. There have been two efforts to 731 standardize the workflow vis a vis these third party services, but 732 these haven't come to fruition: [Wugh] [GithubIETF]. 734 This case relates to the following considerations in [RFC8280]: - 735 Security - Decentralization - Open Standards - Heterogeneity Support 736 - Integrity - Authenticity - Adaptability 738 6.3. Grouping together (identities) 740 Collective identities are also protected by freedom of association 741 and assembly. According to Melucci these are 'shared definitions 742 produced by several interacting individuals who are concerned with 743 the orientation of their action as well as the field of opportunities 744 and constraints in which their action takes place.' [Melucci] In 745 this sense, assemblies and associations are an important base in the 746 maintenance and development of culture, as well as preservation of 747 minority identities [OSCE]. 749 6.3.1. DNS 751 Domain names allow hosts to be identified by human parsable 752 information. Whereas an IP address might not be the expression of an 753 identity, a domain name can be and often is. The grouping of certain 754 identities under specific domains or even Top Level Domains are 755 risky: connecting an identity to a hierarchically structured 756 identifier systems creates a central attack surface which allows for 757 an easier surveillance of the services running on the domain, domain 758 based censorship [RFC7754], or impersonation of the domain through 759 DNS cache poisoning. The use of a centralized authority always makes 760 censorship through a registry or registrar possible, as well as by 761 using a fake resolver or using proposed standards such as DNS 762 Response Policy Zones [RPZ]. Several technologies have been 763 developed in the IETF to mitigate these risks such as DNS over TLS 764 [RFC7858], DNSSEC [RFC4033], DNS over HTTPS [RFC8484]. When these 765 mitigations are implemented, censorship will not be made impossible 766 but it will be made visible. 768 The structuring of DNS as a hierarchical authority structure also 769 brings about a specific characteristic, namely the possibility of 770 centralized policy making vis-a-vis the management and operation of 771 Top Level Domains, which is what happens partly at ICANN. The impact 772 of ICANN processes on human rights will not be discussed here. 774 This case relates to the following considerations in [RFC8280]: - 775 Security - Privacy - Decentralization - Censorship Resistance - 776 Anonymity - Heterogeneity Support - Integrity - Authenticity - 777 Adaptability - Outcome Transparency 779 6.3.2. Autonomous Systems 781 In order for edge-users to connect to the Internet, they need to be 782 connected to an Autonomous System (AS) which, in turn, has peering or 783 transit relations with other AS'es. This means that in the process 784 of accessing the Internet, edge-users need to accept the policies and 785 practices of the intermediary that provides them access to the other 786 networks. In other words, for users to be able to join the 'network 787 of networks', they always need to connect through an intermediary. 789 While accessing the Internet through an intermediary, the user is 790 forced to accept the policies, practices and principles of a network. 791 This could impede the rights of the edge-user, depending on the 792 implemented policies and practices on the network and how (if at all) 793 they are communicated to them. For example: filtering, blocking, 794 extensive logging, slowing down connection or specific services, or 795 other invasive practices that are not clearly communicated to the 796 user. 798 In practice, the user must accept policies of ASes he has no 799 relationship with, and didn't choose. For instance, there is no way 800 to direct the packets to avoid the Five Eyes, not even to know after 801 the fact where the packet went. [FiveEyes] [SchengenRouting] 802 (Traceroutes give you an idea but the path may change before and 803 after the traceroute.) Given that it is not trivial for an edge-user 804 to operate an AS and engage in peering relation with other ASes, 805 there might not be another way for the edge-user to connect to the 806 network of networks. In this case, users are forced into accepting 807 the policies of a specific network. Such design, combined with the 808 increased importance of the Internet to make use of basic services, 809 forces edge-users to associate with a specific network without 810 consenting -or even knowing- the policies of the network. 812 Additionally, it can be noted that there is no standard and deployed 813 way for the edge-user to choose the routes her packets will go 814 through. [RFC0791] section 3.1 standardized "source routing" and 815 "record route" but neither were deployed, mainly because of serious 816 security issues. 818 This case relates to the following considerations in [RFC8280]: - 819 Security - Privacy - Decentralization - Censorship Resistance - 820 Anonymity - Heterogeneity Support - Integrity - Authenticity - 821 Adaptability - Outcome Transparency 823 7. Discussion: Establishing the relation 825 The case studies show that the Internet infrastructure, the 826 combination of architecture and protocols, facilitates freedom of 827 association and assembly, by allowing groups of people to converse, 828 collaborate, exchange, and build and maintain identities in both 829 structural and occasional manners. The structural forms of group 830 activities are more related to freedom of association, whereas 831 freedom of assembly often has a more incidental nature. The 832 difference between the two, as mentioned, is a gradual one. This is 833 equally true to the infrastructural mediations of these rights. 835 Whereas we established that the Internet infrastructure facilitates 836 freedom of association and assembly, by its very technical and 837 material nature, it both creates and limits the spaces for it. This 838 is an interesting tension because juridically only lawful limitations 839 to the rights are allowed, and even then only if they are necessary, 840 and proportionate. This exposes legal implications of the 841 characteristics of the Internet infrastructure. 843 These preliminary finding suggest that the properties and 844 characteristic through which the Internet infrastructure enables and 845 inhibits freedom of assemblies and association should also be 846 analyzed from a legal lens. The case studies have pointed out 847 several caveats in implementations, that might not necessarily be 848 understood by people while exercising their right to association of 849 assembly, and which thus should either be mitigated, or at least, be 850 communicated to the rights holders. 852 8. Discussion: Protocols and Platforms 854 Whereas the Internet is a network of networks, and can therefore be 855 understood as an assembly, applications on top of the Internet do not 856 necessarily inherit the same structure. Quite the opposite, the 857 Internet increasingly becomes a vehicle for commercial, proprietary 858 and non-interoperable platforms. This lack of interoperation is 859 harming the ability of people to set or negotiate their own terms on 860 which they would like to assemble or associate, or host their own 861 interoperating services. 863 Even though the Internet has always allowed for (partially) closed- 864 off networks, the current trend shows the rise of a small number of 865 very large non-interoperable platforms. Chat has moved from XMPP and 866 IRC to Facebook Messenger, Whatsapp and WeChat and there has been a 867 strong rise of social media networks with large numbers of users, 868 such as Facebook, Twitter and Instagram. A similar trend can be 869 found among e-mail providers, with the significant difference that 870 e-mail is interoperable. 872 Often these non-interoperable platforms are built on open-protocols 873 but do not allow for inter-operability or data-portability. In the 874 case of large private platforms, this in turn leads to strong network 875 externalities also know as a network effect; because the users are 876 there, users will be there. Even though social-media platforms have 877 enabled groups to associate, they have also led to a 'tactical 878 freeze' because of the inability to change the platforms [Tufekci]. 880 Whereas these networks are a ready-to-hand networked public sphere, 881 they do not allow their inhabitants to change or fully understand 882 their workings. In a near future, this could potentially impact 883 infrastructure itself and the distributed nature of the Internet 884 [RFC1287]. 886 9. Conclusions 888 Communities, collaboration and joint action lie at the heart of the 889 Internet. Even at at linguistical level, the words "networks" and 890 "associations" are close synonyms. Both interconnected groups and 891 assemblies of people depend on "links" and "relationships" [Swire]. 892 Taking legal definitions given in international human rights law 893 jurisprudence, we could assert that the right to freedom of assembly 894 and association protect collective expression. These rights protect 895 any collective, gathered either permanently or temporarily for 896 "peaceful" purposes. It is voluntary and uncoerced. 898 Given that the Internet itself was originally designed as a medium of 899 communication for machines that share resources with each other as 900 equals [RFC0903], the Internet is now one of the most basic 901 infrastructures for the right to freedom of assembly and association. 902 Since Internet protocols and the Internet architecture play a central 903 role in the management, development and use of the Internet, we 904 established the relation between some protocols and the right to 905 freedom of assembly and association. 907 After reviewing several typical representative cases, we can conclude 908 that the way in which infrastructure is designed and implemented 909 impacts people's ability to exercise their freedom of assembly and 910 association. This is because different technical designs come with 911 different properties and characteristics. These properties and 912 characteristics on the one hand enable people to assemble and 913 associate, but on the other hand also adds limiting, or even 914 potentially endangering, characteristics. More often than not, this 915 depends on the context. A clearly identified group for open 916 communications, where messages are sent in cleartext and where 917 peoples persistent identities are viisble, can help to faciliate an 918 assembly and build trust, but in other context the same configuration 919 could pose a significant danger. Endangering characteristics should 920 be mitigated, or at least clearly communicated to the users of these 921 technologies. 923 Lastly, the increasing shift towards closed and non-interoperable 924 platforms in chat and social media networks have a significant impact 925 on the distributed and open nature of the Internet. Often these non- 926 interoperable platforms are built on open-protocols but do not allow 927 for inter-operability or data-portability. The use of social-media 928 platforms has enabled groups to associate, but is has also rendered 929 users unable to change platforms, therefore leading to a sort of 930 "forced association" that inhibits people to fully exercise their 931 freedom of assembly and association. 933 10. Acknowledgements 935 - Fred Baker, Jefsey, and Andrew Sullivan for work on Internet 936 definitions. 938 - Stephane Bortzmeyer for several concrete text suggestions that 939 found their way in this document (such as the AS filtering 940 example). 942 - Mark Perkins and Gurshabad for finding a lot of typos. 944 - Gurshabad Grover and an anonymous reviewer for a full review. 946 - The hrpc mailinglist at large for a very constructive discussion 947 on a hard topic. 949 11. Security Considerations 951 As this draft concerns a research document, there are no security 952 considerations. 954 12. IANA Considerations 956 This document has no actions for IANA. 958 13. Research Group Information 960 The discussion list for the IRTF Human Rights Protocol Considerations 961 Research Group is located at the e-mail address hrpc@ietf.org [1]. 962 Information on the group and information on how to subscribe to the 963 list is at https://www.irtf.org/mailman/listinfo/hrpc [2] 965 Archives of the list can be found at: https://www.irtf.org/mail- 966 archive/web/hrpc/current/index.html [3] 968 14. References 970 14.1. Informative References 972 [Abbate] Janet Abbate, ., "Inventing the Internet", Cambridge: MIT 973 Press (2013): 11. , 2013, 974 . 976 [AckermannKargerZhang] 977 Ackerman, M., Karger, D., and A. Zhang, "Mailing Lists: 978 Why Are They Still Here, What's Wrong With Them, and How 979 Can We Fix Them?", Mit. edu (2017): 1. , 2017, 980 . 983 [Anderson] 984 Andersson, E., "The political voice of young citizens 985 Educational conditions for political conversation - school 986 and social media", Utbildning & Demokrati: Tidskrift foer 987 Didaktik och Utbildningspolitik, Volume 21, Number 1, 988 2012, pp. 97-119(23) , 2012, 989 . 992 [AndersonGuarnieri] 993 Anderson, C. and C. Guarnieri, "Fictitious Profiles and 994 WebRTC's Privacy Leaks Used to Identify Iranian 995 Activists", 2016, 996 . 999 [APC] Association for Progressive Communications and . Gayathry 1000 Venkiteswaran, "Freedom of assembly and association online 1001 in India, Malaysia and Pakistan. Trends, challenges and 1002 recommendations.", 2016, 1003 . 1006 [APC2] Gayathry Venkiteswaran, . and Association for Progressive 1007 Communications, "Freedom of assembly and association 1008 online in India, Malaysia and Pakistan. Trends, challenges 1009 and recommendations.", 2016, 1010 . 1013 [Australia] 1014 Australian Government, Attorney-General's Department, 1015 "Right to freedom of assembly and association", 2020, 1016 . 1021 [Benkler] Benkler, Y., "Peer Production and Cooperation", 2009, 1022 . 1025 [Bloketal] 1026 Blok, A., Nakazora, M., and B. Winthereik, 1027 "Infrastructuring Environments", Science as Culture 25:1, 1028 1-22. , 2016. 1030 [Bowker] Bowker, G., "Information mythology and infrastructure", 1031 In: L. Bud (Ed.), Information Acumen: The Understanding 1032 and use of Knowledge in Modern 1033 Business,Routledge,London,1994,pp.231-247 , 1994. 1035 [CERD] Wikipedia, ., "Lorum", 2000, . 1037 [Crawford] 1038 Crawford, D., "The WebRTC VPN "Bug" and How to Fix", 2015, 1039 . 1042 [CRC] Wikipedia, ., "Lorum", 2000, . 1044 [CRPD] Wikipedia, ., "Lorum", 2000, . 1046 [FiveEyes] 1047 Wikipedia, ., "Five Eyes", 2018, 1048 . 1050 [GithubIETF] 1051 Thomson, M. and A. Atlas, "Using GitHub at the IETF", 1052 2017. 1054 [Haas] Haas, P., "Introduction: epistemic communities and 1055 international policy coordination", International 1056 Organization, special issue: Knowledge, Power, and 1057 International Policy Coordination, Cambridge Journals. 46 1058 (1): 1-35. , 1992. 1060 [HafnerandLyon] 1061 Hafnerand, K. and M. Lyon, "Where Wizards Stay Up Late. 1062 The Origins of the Internet", First Touchstone Edition 1063 (1998): 93. , 1998, . 1065 [hrpc-charter] 1066 Wikipedia, ., "Lorum", 2000, . 1068 [HussainHoward] 1069 Hussain, M. and P. Howard, "What Best Explains Successful 1070 Protest Cascades? ICTs and the Fuzzy Causes of the Arab 1071 Spring", Int Stud Rev (2013) 15 (1): 48-66. , 2013, 1072 . 1074 [ICCPR] United Nations General Assembly, "International Covenant 1075 on Civil and Political Rights", 1966, 1076 . 1079 [Mainwaringetal] 1080 Mainwaring, S., Chang, M., and K. Anderson, 1081 "Infrastructures and Their Discontents: Implications for 1082 Ubicomp", DBLP Conference: Conference: UbiComp 2004: 1083 Ubiquitous Computing: 6th International Conference, 1084 Nottingham, UK, September 7-10, 2004. Proceedings , 2004, 1085 . 1088 [Melucci] Melucci, A., "The Process of Collective Identity", Temple 1089 University Press, Philadelphia , 1995. 1091 [Mosco] Mosco, V., "The Digital Sublime: Myth, Power, and 1092 Cyberspace", 2005, 1093 . 1095 [MSI-INT] Wikipedia, ., "Lorum", 2000, . 1097 [NelsonHedlun] 1098 Minar, N. and M. Hedlun, "A Network of Peers: Models 1099 Through the History of the Internet", Peer to Peer: 1100 Harnessing the Power of Disruptive Technologies, ed: Andy 1101 Oram , 2001, . 1106 [OSCE] OSCE Office for Democratic Institutions and Human Rights, 1107 "Guidelines on Freedom of Peaceful Assembly", page 24 , 1108 2010, . 1110 [Pensado] Jaime Pensado, ., "Student Activism. Utopian Dreams.", 1111 ReVista. Harvard Review of Latin America (2012). , 2012, 1112 . 1114 [PipekWulf] 1115 Pipek, V. and W. Wolf, "Infrastructuring: Towards an 1116 Integrated Perspective on the Design and Use of 1117 Information Technology", Journal of the Association for 1118 Information Systems (10) 5, pp. 306-332 , 2009. 1120 [RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001, 1121 April 1969, . 1123 [RFC0155] North, J., "ARPA Network mailing lists", RFC 155, 1124 DOI 10.17487/RFC0155, May 1971, 1125 . 1127 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1128 DOI 10.17487/RFC0791, September 1981, 1129 . 1131 [RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 1132 Reverse Address Resolution Protocol", STD 38, RFC 903, 1133 DOI 10.17487/RFC0903, June 1984, 1134 . 1136 [RFC1211] Westine, A. and J. Postel, "Problems with the maintenance 1137 of large mailing lists", RFC 1211, DOI 10.17487/RFC1211, 1138 March 1991, . 1140 [RFC1287] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, 1141 "Towards the Future Internet Architecture", RFC 1287, 1142 DOI 10.17487/RFC1287, December 1991, 1143 . 1145 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 1146 4)", RFC 1771, DOI 10.17487/RFC1771, March 1995, 1147 . 1149 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 1150 selection, and registration of an Autonomous System (AS)", 1151 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 1152 . 1154 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 1155 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 1156 . 1158 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 1159 DOI 10.17487/RFC2810, April 2000, 1160 . 1162 [RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", 1163 RFC 2812, DOI 10.17487/RFC2812, April 2000, 1164 . 1166 [RFC3233] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58, 1167 RFC 3233, DOI 10.17487/RFC3233, February 2002, 1168 . 1170 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1171 Rose, "DNS Security Introduction and Requirements", 1172 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1173 . 1175 [RFC4084] Klensin, J., "Terminology for Describing Internet 1176 Connectivity", BCP 104, RFC 4084, DOI 10.17487/RFC4084, 1177 May 2005, . 1179 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1180 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1181 DOI 10.17487/RFC4271, January 2006, 1182 . 1184 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1185 Thayer, "OpenPGP Message Format", RFC 4880, 1186 DOI 10.17487/RFC4880, November 2007, 1187 . 1189 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1190 (TLS) Protocol Version 1.2", RFC 5246, 1191 DOI 10.17487/RFC5246, August 2008, 1192 . 1194 [RFC5694] Camarillo, G., Ed. and IAB, "Peer-to-Peer (P2P) 1195 Architecture: Definition, Taxonomies, Examples, and 1196 Applicability", RFC 5694, DOI 10.17487/RFC5694, November 1197 2009, . 1199 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1200 Mail Extensions (S/MIME) Version 3.2 Message 1201 Specification", RFC 5751, DOI 10.17487/RFC5751, January 1202 2010, . 1204 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 1205 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 1206 2011, . 1208 [RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, 1209 "The WebSocket Protocol as a Transport for the Session 1210 Initiation Protocol (SIP)", RFC 7118, 1211 DOI 10.17487/RFC7118, January 2014, 1212 . 1214 [RFC7194] Hartmann, R., "Default Port for Internet Relay Chat (IRC) 1215 via TLS/SSL", RFC 7194, DOI 10.17487/RFC7194, August 2014, 1216 . 1218 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 1219 Nordmark, "Technical Considerations for Internet Service 1220 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 1221 March 2016, . 1223 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1224 and P. Hoffman, "Specification for DNS over Transport 1225 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1226 2016, . 1228 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 1229 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 1230 October 2017, . 1232 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1233 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1234 . 1236 [RPZ] Vixie, P. and V. Schyver, "DNS Response Policy Zones 1237 (RPZ)", 2017, 1238 . 1240 [Sauter] Wikipedia, ., "Lorum", 2000, . 1242 [SchengenRouting] 1243 Wikipedia, ., "Schengen Routing", 2018, 1244 . 1246 [Schleuder] 1247 Nadir, "Schleuder - A gpg-enabled mailinglist with 1248 remailing-capabilities.", 2017, 1249 . 1251 [SeawrightGerring] 1252 Seawright, J. and J. Gerring, "Case Selection Techniques 1253 in Case Study Research: A Menu of Qualitative and 1254 Quantitative Options", Political Research Quarterly, 1255 61(2), 294-308. , 2008, . 1258 [Sink] Sink, E., "Version Control by Example", 2011, 1259 . 1261 [Star] Star, S., "The Ethnography of Infrastructure", American 1262 Behavioral Scientist, Volume 43 (3), 377-391. , 1999, 1263 . 1266 [StarRuhleder] 1267 Star, S. and K. Ruhleder, "Steps toward an ecology of 1268 infrastructure: Design and access for large information 1269 spaces", Information Systems Research 7 (1) (1996) 1270 111-134. , 1996. 1272 [Swire] Peter Swire, ., "Social Networks, Privacy, and Freedom of 1273 Association: Data Empowerment vs. Data Protection", North 1274 Carolina Law Review (2012) 90 (1): 104. , 2012, 1275 . 1278 [Tocqueville] 1279 de Tocqueville, A., "Democracy in America", 1840, 1280 . 1285 [Troncosoetal] 1286 Troncoso, C., Isaakdis, M., Danezis, G., and H. Halpin, 1287 "Systematizing Decentralization and Privacy: Lessons from 1288 15 Years of Research and Deployments", Proceedings on 1289 Privacy Enhancing Technologies ; 2017 (4):307-329 , 2017, 1290 . 1293 [Tufekci] Tufekci, Z., "Twitter and Tear Gas: The Power and 1294 Fragility of Networked Protest", 2017, 1295 . 1297 [UDHR] United Nations General Assembly, "The Universal 1298 Declaration of Human Rights", 1948, 1299 . 1301 [Undertake] 1302 Wikipedia, ., "Lorum", 2000, . 1304 [UNGA] Hina Jilani, ., "Human rights defenders", A/59/401 , 2004, 1305 . 1308 [UNHRC] Maina Kiai, ., "Report of the Special Rapporteur on the 1309 rights to freedom of peaceful assembly and of 1310 association", A/HRC/20/27 , 2012, 1311 . 1314 [Vu] Vu, Quang Hieu, ., Lupu, Mihai, ., and . Ooi, Beng Chin, 1315 "Peer-to-Peer Computing: Principles and Applications", 1316 2010, . 1318 [Weiser] Weiser, L., "The Computer for the 21st Century", 1319 Scientific American Ubicomp Paper after Sci Am editing , 1320 1991, . 1323 [Wugh] Nottingham, M., "Using Third Party Services for IETF 1324 Work", 2017, . 1327 14.2. URIs 1329 [1] mailto:hrpc@ietf.org 1331 [2] https://www.irtf.org/mailman/listinfo/hrpc 1333 [3] https://www.irtf.org/mail-archive/web/hrpc/current/index.html 1335 Authors' Addresses 1337 Niels ten Oever 1338 University of Amsterdam 1340 EMail: mail@nielstenoever.net 1342 Stephane Couture 1343 University de Montreal 1345 EMail: stephane.couture@umontreal.ca 1347 Gisela Perez de Acha 1348 Derechos Digitales 1350 EMail: gisela@derechosdigitales.org