idnits 2.17.1 draft-irtf-hrpc-association-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 22, 2019) is 1701 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1119 -- Looks like a reference, but probably isn't: '2' on line 1121 -- Looks like a reference, but probably isn't: '3' on line 1123 == Unused Reference: 'RFC5246' is defined on line 985, 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: 0 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Human Rights Protocol Considerations Research Group S. Couture 3 Internet-Draft University of Montreal 4 Intended status: Informational J. Hall 5 Expires: February 23, 2020 CDT 6 N. ten Oever 7 University of Amsterdam 8 G. Perez de Acha 9 Derechos Digitales 10 August 22, 2019 12 Freedom of Association on the Internet 13 draft-irtf-hrpc-association-03 15 Abstract 17 This document establishes the link between the Internet architecture 18 and the ability of people to exercise their right to freedom of 19 assembly and association online. The Internet increasingly mediates 20 our lives, our relationships and our ability to exercise our human 21 rights. As a forum, it provides a global public space despite being 22 built on predominantly private infrastructure. Since Internet 23 protocols play a central role in the management, development and use 24 of the Internet, the relation between protocols and the 25 aforementioned rights should be analyzed and any adverse impacts 26 should be mitigated. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on February 23, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Vocabulary used . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Research question . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Literature Review . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Cases and examples . . . . . . . . . . . . . . . . . . . . . 7 68 6.1. Conversing . . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . 8 70 6.1.2. Multi-party video conferencing . . . . . . . . . . . 8 71 6.1.3. Internet Relay Chat . . . . . . . . . . . . . . . . . 9 72 6.2. Peer-to-peer networks and systems . . . . . . . . . . . . 10 73 6.2.1. Peer-to-peer system architectures . . . . . . . . . . 10 74 6.2.2. Version control . . . . . . . . . . . . . . . . . . . 12 75 6.3. Grouping together (identities) . . . . . . . . . . . . . 12 76 6.3.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 6.3.2. Autonomous Systems . . . . . . . . . . . . . . . . . 13 78 7. Discussion: Establishing the relation . . . . . . . . . . . . 14 79 8. Discussion: Protocols and Platforms . . . . . . . . . . . . . 15 80 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 83 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 13. Research Group Information . . . . . . . . . . . . . . . . . 17 85 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 14.1. Informative References . . . . . . . . . . . . . . . . . 17 87 14.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 90 1. Introduction 92 We shape our tools and, thereafter, our tools shape us.  93 - John Culkin (1967) 95 The Internet is constantly shaping modern information societies by 96 providing a socio-technical ordering. In other words, the Internet 97 infrastructure and architecture consist of social and technological 98 arrangements [StarRuhleder]. Such ordering is not always apparent 99 because infrastructure is often taken for granted by those using it. 100 It tends to hide itself in the societal woodwork [Mosco], or put 101 otherwise: 'The most profound technologies are those that disappear' 102 [Weiser]. 104 Infrastructure therefore is mostly known by an epistemic community of 105 experts [Haas] and only gets recognized by the larger public when it 106 fails. As the Internet grows, decisions made about its architecture 107 are become more important. [RFC8280] established the relationship 108 between human rights and Internet protocols. Following the same 109 methodology, we now seek to uncover the relation between the right to 110 assembly, association and the Internet infrastructure. 112 One one hand, the right to freedom of assembly and association 113 protects collective expression. Likewise, systems and protocols that 114 enable communal interactions between people and servers enable this 115 right given that the Internet itself was originally designed as "a 116 medium of communication for machines that share resources with each 117 other as equals" [NelsonHedlun]. 119 The current draft continues the work started in [RFC8280] by 120 investigating the exact impact of Internet protocols on specific 121 human rights, namely the right to freedom of assembly and 122 association, in order to mitigate potential negative impacts. 124 2. Vocabulary used 126 Architecture The design of a structure 128 Autonomous System (AS) Autonomous Systems are the unit of routing 129 policy in the modern world of exterior routing [RFC1930]. 131 Within the Internet, an autonomous system (AS) is a collection of 132 connected Internet Protocol (IP) routing prefixes under the 133 control of one or more network operators on behalf of a single 134 administrative entity or domain that presents a common, clearly 135 defined routing policy to the Internet [RFC1930]. 137 The classic definition of an Autonomous System is a set of routers 138 under a single technical administration, using an interior gateway 139 protocol and common metrics to route packets within the AS, and 140 using an exterior gateway protocol to route packets to other ASs 141 [RFC1771]. 143 Border Gateway Protocol (BGP) An inter-Autonomous System routing 144 protocol [RFC4271]. 146 Connectivity The extent to which a device or network is able to 147 reach other devices or networks to exchange data. The Internet is 148 the tool for providing global connectivity [RFC1958]. Different 149 types of connectivity are further specified in [RFC4084]. The 150 combination of the end-to-end principle, interoperability, 151 distributed architecture, resilience, reliability and robustness 152 are the enabling factors that result in connectivity to and on the 153 Internet. 155 Decentralization Implementation or deployment of standards, 156 protocols or systems without one single point of control. 158 Distributed system A system with multiple components that have their 159 behavior co-ordinated via message passing. These components are 160 usually spatially separated and communicate using a network, and 161 may be managed by a single root of trust or authority. 162 [Troncosoetal] 164 Infrastructure Underlying basis or structure for a functioning 165 society, organization or community. Because infrastructure is a 166 precondition for other activities it has a procedural, rather than 167 static, nature due to its social and cultural embeddedness 168 [PipekWulf] [Bloketal]. This means that infrastructure is always 169 relational: infrastructure always develops in relation to 170 something or someone [Bowker]. 172 Internet The Network of networks, that consists of Autonomous 173 Systems that are connected through the Internet Protocol (IP). 175 A persistent socio-technical system over which services are 176 delivered [Mainwaringetal], 178 A techno-social assemblage of devices, users, sensors, networks, 179 routers, governance, administrators, operators and protocols 181 An emergent-process-driven thing that is born from the collections 182 of the ASes that happen to be gathered together at any given time. 183 The fact that they tend to interact at any given time means it is 184 an emergent property that happens because they use the protocols 185 defined at IETF. 187 3. Research question 189 How does the architecture of the internet enable and/or inhibit the 190 right to freedom of assembly and association? 192 4. Methodology 194 The point of departure of the present work is [RFC8280] - an initial 195 effort to establish the relationship between human rights and the 196 Internet architecture, specifically protocols and standards. As 197 such, [RFC8280] was inductive and explorative in nature, and it 198 ultimately established relationships between aforementioned concepts 199 through a series of case studies. 201 The methodology was based on process tracing, semi-structured 202 interviews and quantitative and qualitative document analysis which 203 has been further validated through confirmatory research in the form 204 of Human Rights Protocol Reviews. The relationship, proposed as a 205 hypothesis in [RFC8280] says that there is an inherent relation 206 between protocols, the Internet architecture, and human rights. The 207 guidelines in [RFC8280] describe a relationship between the right to 208 freedom of assembly and association and connectivity, security, 209 censorship resistance, anonymity, pseudonymity, accessibility, 210 decentralization, adaptability, and outcome transparency. 212 Taking into consideration the international human rights framework 213 regarding freedom of assembly and association, the present document 214 seeks to deepen the relationship between the Internet architecture, 215 protocols, and standards without creating new guidelines. In that 216 way, we continue the work proposed in [RFC8280] and follow the 217 primary aim of the Human Rights Protocol Consideration Research 218 Group, as laid out in its charter where one of the research aims is 219 'to expose the relation between protocols and human rights, with a 220 focus on the rights to freedom of expression and freedom of 221 assembly'. Even though the present work does not seek to create new 222 guidelines, the conclusions could inform the development of new 223 guidelines such as is done in draft-irtf-hrpc-guidelines. 225 Given that our current research proposition is that "the Internet 226 infrastructure significantly impacts the ability of people to 227 exercise the human rights to freedom of association and assembly', we 228 therefore aim to test the relationship between protocols and 229 association through a case-selection method, where we have adopted a 230 purposive sampling approach, aimed at the typicality and paradigmatic 231 nature of the cases [SeawrightGerring] to help us achieve an attempt 232 at an an ethnography of infrastructure [Star]. Subsequently we 233 analyze the cases through the theoretical framework provided in the 234 literature review and based on that provide recommendations based on 235 the findings. 237 5. Literature Review 239 The right to freedom of assembly and association protects and enables 240 collective action and expression [UDHR] [ICCPR]. It's purpose is to 241 ensure that everyone in a society has the opportunity to express 242 opinions they hold in common with others. As such, it is a tool that 243 facilitates dialogue among citizens, as well as with political 244 leaders or governments [OSCE]. In a democracy, causes and opinions 245 are more widely heard when a group of people come together behind the 246 same cause or issue [Tocqueville]. 248 In international law, the right to freedom of assembly and 249 association protects any collective, gathered either permanently or 250 temporarily for "peaceful" purposes. It is important to underline 251 the property of "freedom" because the right to freedom of association 252 and assembly is voluntary and uncoerced: anyone can join or leave a 253 group of choice, which in turn means one should not be forced to 254 either join, stay or leave. What constitutes a definition of 255 "peaceful" is outside the scope of the present document. 257 The difference between freedom of assembly and freedom of association 258 is merely a gradual one: the former tends to have an informal and 259 ephemeral nature, whereas the latter refers to established and 260 permanent bodies with specific objectives. Nonetheless, both are 261 protected to the same degree. 263 Where an assembly is an intentional and temporary gathering of a 264 collective in a private or public space for a specific purpose: 265 demonstrations, indoor meetings, strikes, processions, rallies or 266 even sits-in [UNHRC]; association has a more formal and established 267 nature. It refers to a group of individuals or legal entities 268 brought together in order to collectively act, express, pursue or 269 defend a field of common interests [UNGA]. Think about civil society 270 organizations, clubs, cooperatives, NGOs, religious associations, 271 political parties, trade unions or foundations. 273 Even if privacy and freedom of expression are the most discussed 274 human rights when it comes to the online world, the right to freedom 275 of assembly and association is quintessential for the Internet. 276 Online association and assembly are the starting point of group to 277 mobilization in modern democracies, and even more so where physical 278 gatherings have been impossible or dangerous [APC]. Throughout the 279 world -from the Arab Spring to Latin American student movements and 280 the #WomensMarch- the Internet has played a crucial role by providing 281 means for the fast dissemination of information otherwise mediated by 282 the press, or even forbidden by the government [Pensado]. According 283 to Hussain and Howard the Internet helped to "build solidarity 284 networks and identification of collective identities and goals, 285 extend the range of local coverage to international broadcast 286 networks" and as platform for contestation for "the future of civil 287 society and information infrastructure" [HussainHoward]. 289 The IETF itself, defined as a 'open global community' of network 290 designers, operators, vendors, and researchers is also protected by 291 freedom of assembly and association [RFC3233]. Discussions, comments 292 and consensus around RFCs are possible because of the collective 293 expression that freedom of association and assembly allow. The very 294 word "protocol" found its way into the language of computer 295 networking based on the need for collective agreement among network 296 users [HafnerandLyon]. 298 We are aware that some of the following examples go beyond the use of 299 Internet protocols and flow over into the application layer or 300 examples in the offline world whereas the purpose of the current 301 document is to break down the relationship between Internet protocols 302 and the right to freedom of assembly and association. Nonetheless, 303 given that protocols are a part of the socio-technical ordering of 304 reality, we do recognize that in some cases the line between them and 305 applications, implementations, policies and offline realities are 306 often blurred and hard -if not impossible- to differentiate. 308 6. Cases and examples 310 As the Internet mediates collective action and collaboration, it 311 impacts on freedom of association and assembly. To answer our 312 research question regarding how internet architecture enable and/or 313 inhibits such human right, we researched several independent and 314 typical cases related to protocols that have been either adopted by 315 the IETF, or are widely used on the Internet. Our goal is to figure 316 out whether they facilitate freedom of assembly and association, or 317 whether they inhibit it through their design or implementation. We 318 also indicate, per case, the interrelation with issues in [RFC8280]. 320 6.1. Conversing 322 An interactive conversation between two or more people forms the 323 basis to organize and associate. According to Anderson "the 324 relationship between political conversation and engagement in the 325 democratic process is strong." [Anderson]. A conversation is 326 inherently of social nature. Therefore, by these definitions the 327 core of the "political" is essentially assembly or association: a 328 basis for the development of social cohesion in society. 330 6.1.1. Mailing Lists 332 Since the beginning of the Internet mailing lists have been a key 333 site of assembly and association [RFC0155] [RFC1211]. In fact, 334 mailing lists were one of the Internet's first functionalities 335 [HafnerandLyon]. 337 In 1971, four years after the invention of email, the first mailing 338 list was created to talk about the idea of using Arpanet for 339 discussion. What had initially propelled the Arpanet project forward 340 as a resource sharing platform was gradually replaced by the idea of 341 a network as a means of bringing people together [Abbate]. More than 342 45 years after, mailing lists are pervasive and help communities to 343 engage, have discussions, share information, ask questions, and build 344 ties. Even as social media and discussion forums grow, mailing lists 345 continue to be widely used [AckermannKargerZhang] and are still a 346 crucial tool to organise groups and individuals around themes and 347 causes [APC]. 349 Mailing lists' pervasive use are partly explained because they allow 350 for "free" association: people subscribe (join) and unsubscribe 351 (leave) as they please. Mailing lists also allow for association of 352 specific groups on closed lists. Furthermore, the archival function 353 of mailinglists allows for posterior accountability and analysis. 354 The downsides of mailinglists are similar to the ones generally 355 associated with e-mail, except that end-to-end encryption such as 356 OpenPGP [RFC4880] and S/MIME [RFC5751] are not possible because the 357 final recipients are not known. There have been experimental 358 solutions to address this issue such as Schleuder [Schleuder], but 359 this has not been standardized or widely deployed. 361 This case relates to the following considerations in [RFC8280]: - 362 Security - Privacy - Decentralization - Censorship Resistance - Open 363 Standards - Confidentiality 365 6.1.2. Multi-party video conferencing 367 Multi-party video conferencing protocols like WebRTC [RFC6176] 368 [RFC7118] allow for robust, bandwidth-adaptive, wideband and super- 369 wideband video and audio discussions in groups. 'The WebRTC protocol 370 was designed to enable responsive real-time communications over the 371 Internet, and is instrumental in allowing streaming video and 372 conferencing applications to run in the browser. In order to easily 373 facilitate direct connections between computers (bypassing the need 374 for a central server to act as a gatekeeper), WebRTC provides 375 functionality to automatically collect the local and public IP 376 addresses of Internet users (ICE or STUN). These functions do not 377 require consent from the user, and can be instantiated by sites that 378 a user visits without their awareness. The potential privacy 379 implications of this aspect of WebRTC are well documented, and 380 certain browsers have provided options to limit its behavior.' 381 [AndersonGuarnieri]. 383 Even though some multi-party video conferencing tools facilitate 384 freedom of assembly and association, their own configuration might 385 might pose concrete risks for those who use them. One the one hand 386 WebRTC is providing resilient channels of communications, but on the 387 other hand it also exposes information about those who are using the 388 tool which might lead to increased surveillance, identification and 389 the consequences that might be derived from that. This is especially 390 concerning because the usage of a VPN does not protect against the 391 exposure of IP addresses [Crawford]. 393 The risk of surveillance is also true in an offline space, but this 394 is generally easy to analyze for the end-user. Security and privacy 395 expectations of the end-user could be either improved or made 396 explicit. This in turn would result in a more secure and/or private 397 exercise of the right to freedom of assembly or association. 399 This case relates to the following considerations in [RFC8280]: - 400 Security - Privacy - Decentralization - Censorship Resistance - Open 401 Standards - Anonymity - Confidentiality 403 6.1.3. Internet Relay Chat 405 Internet Relay Chat (IRC) is an application layer protocol that 406 enables communication in the form of text through a client/server 407 networking model [RFC2810]. In other words, a chat service. IRC 408 clients are computer programs that a user can install on their 409 system. These clients communicate with chat servers to transfer 410 messages to other clients. 412 For order to be kept within the IRC network, special classes of users 413 become "operators" and are allowed to perform general maintenance 414 functions on the network: basic network tasks such as disconnecting 415 (temporary or permanently) and reconnecting servers as needed 416 [RFC2812]. One of the most controversial power of operators is the 417 ability to remove a user from the connected network by 'force', i.e., 418 operators are able to close the connection between any client and 419 server [RFC2812]. 421 IRC servers may deploy different policies for the ability of users to 422 create their own channels or 'rooms', and for the delegation of 423 'operator'-rights in such spaces. Some IRC servers support SSL/TLS 424 connections for security purposes [RFC7194] which helps stop the use 425 of packet sniffer programs to obtain the passwords of IRC users, but 426 has little use beyond this scope due to the public nature of IRC 427 channels. TLS connections require both client and server support 428 (that may require the user to install TLS binaries and IRC client 429 specific patches or modules on their computers). Some networks also 430 use TLS for server to server connections, and provide a special 431 channel flag (such as +S) to only allow TLS-connected users on the 432 channel, while disallowing operator identification in clear text, to 433 better utilize the advantages that TLS provides. 435 This case relates to the following considerations in [RFC8280]: - 436 Security - Privacy - Censorship Resistance 438 6.2. Peer-to-peer networks and systems 440 At the organizational level, peer production is one of the most 441 relevant innovations from Internet mediated social practices. 442 According to [Benkler] these networks imply 'open collaborative 443 innovation and creation, performed by diverse, decentralized groups 444 organized principally by neither price signals nor organizational 445 hierarchy, harnessing heterogeneous motivations, and governed and 446 managed based on principles other than the residual authority of 447 ownership implemented through contract.' [Benkler]. 449 In his book The Wealth of Networks, Benkler significantly expands on 450 his definition of commons-based peer production. In his view, what 451 distinguishes commons-based production is that it doesn't rely upon 452 or propagate proprietary knowledge: "The inputs and outputs of the 453 process are shared, freely or conditionally, in an institutional form 454 that leaves them equally available for all to use as they choose at 455 their individual discretion." [Benkler] To ensure that the knowledge 456 generated is available for free use, commons-based projects are often 457 shared under an open license. 459 6.2.1. Peer-to-peer system architectures 461 Peer-to-peer (P2P) is essentially a model of how people interact in 462 real life because "we deal directly with one another whenever we wish 463 to" [Vu]. Usually if we need something we ask our peers, who in turn 464 refer us to other peers. In this sense, the ideal definition of P2P 465 is that "nodes are able to directly exchange resources and services 466 between themselves without the need for centralized servers" where 467 each participating node typically acts both as a server and as a 468 client [Vu]. RFC 5694 has defined it as peers or nodes that should 469 be able to communicate directly between themselves without passing 470 intermediaries, and that the system should be self-organizing and 471 have decentralized control [RFC5694]. With this in mind, the 472 ultimate model of P2P is a completely decentralized system, which is 473 more resistant to speech regulation, immune to single points of 474 failure and has a higher performance and scalability. Nonetheless, 475 in practice some P2P systems are supported by centralized servers and 476 some others have hybrid models where nodes are organized into two 477 layers: the upper tier servers and the lower tier common nodes [Vu]. 479 Since the ARPANET project, the original idea behind the Internet was 480 conceived as what we would now call a peer-to-peer system [RFC0001]. 481 Over time it has increasingly shifted towards a client/server model 482 with "millions of consumer clients communicating with a relatively 483 privileged set of servers" [NelsonHedlun]. 485 Whether for resource sharing or data sharing, P2P systems are 486 enabling freedom of assembly and association. Not only do they allow 487 for effective dissemination of information, but they leverage 488 computing resources by diminishing costs allowing for the formation 489 of open collectives at the network level. At the same time, in 490 completely decentralized systems the nodes are autonomous and can 491 join or leave the network as they want -a characteristic that makes 492 the system unpredictable: a resource might be only sometimes 493 available, and some other resources might be missing or incomplete 494 [Vu]. Lack of information might in turn makes association or 495 assembly more difficult. 497 Additionally, when architecturally assessing the role of P2P systems 498 we could say that: "the main advantage of centralized P2P systems is 499 that they are able to provide a quick and reliable resource locating. 500 Their limitation, however, is that the scalability of the systems is 501 affected by the use of servers. While decentralized P2P systems are 502 better than centralized P2P systems in this aspect, they require a 503 longer time in resource locating. As a result, hybrid P2P systems 504 have been introduced to take advantage of both centralized and 505 decentralized architectures. Basically, to maintain the scalability, 506 similar to decentralized P2P systems, there are no servers in hybrid 507 P2P systems. However, peer nodes that are more powerful than others 508 can be selected to act as servers to serve others. These nodes are 509 often called super peers. In this way, resource locating can be done 510 by both decentralized search techniques and centralized search 511 techniques (asking super peers), and hence the systems benefit from 512 the search techniques of centralized P2P systems." [Vu] 514 This case relates to the following considerations in [RFC8280]: - 515 Security - Privacy - Decentralization - Censorship Resistance - Open 516 Standards - Anonymity - Heterogeneity Support - Integrity - 517 Authenticity - Adaptability 519 6.2.2. Version control 521 Ever since developers needed to collaboratively write, maintain and 522 discuss large code basis for the Internet there have been different 523 approaches of doing so. The easiest approach has been discussing 524 code through mailing lists even though this has proven to be hard 525 when maintaining the most recent versions, which is why version 526 control systems ultimately make sense. 528 A version control system is a piece of software that enables 529 developers on a software team to work together and also archive a 530 complete history of their work [Sink]. This allows teams to be 531 working simultaneously on updated versions. According to Sink, 532 broadly speaking, the history of version control tools can be divided 533 into three generations. In the first one, concurrent development 534 meant that only one person could be working on a file at a time. The 535 second generation tools permit simultaneous modifications as long as 536 users merge the current revisions into their work before they are 537 allowed to commit. The third generation tools allow merge and commit 538 to be separated [Sink]. 540 Interestingly no version control system has ever been standardized in 541 the IETF whereas the version control systems like Subversion and Git 542 are widely used within the community and working groups. There has 543 been a spirited discussion on whether working groups should use 544 centralized forms of the Git protocol, such as those offered by 545 Gitlab or Github. Proponents argue that this simplifies the workflow 546 and allows for more transparency. Opponents argue that the reliance 547 on a centralized service which is not merely using the Git protocol 548 but also uses non-standardized options like an Issue-Tracker, makes 549 the process less transparent and reliant on a third party. 551 The IETF has not made a decision on the use of centralized instances 552 of Git, such as Github or Gitlab. There have been two efforts to 553 standardize the workflow vis a vis these third party services, but 554 these haven't come to fruition: [Wugh] [GithubIETF]. 556 This case relates to the following considerations in [RFC8280]: - 557 Security - Decentralization - Open Standards - Heterogeneity Support 558 - Integrity - Authenticity - Adaptability 560 6.3. Grouping together (identities) 562 Collective identities are also protected by freedom of association 563 and assembly. According to Melucci these are 'shared definitions 564 produced by several interacting individuals who are concerned with 565 the orientation of their action as well as the field of opportunities 566 and constraints in which their action takes place.' [Melucci] In 567 this sense, assemblies and associations are an important base in the 568 maintenance and development of culture, as well as preservation of 569 minority identities [OSCE]. 571 6.3.1. DNS 573 Domain names allow hosts to be identified by human parsable 574 information. Whereas an IP address might not be the expression of an 575 identity, a domain name can be and often is. The grouping of certain 576 identities under specific domains or even Top Level Domains are 577 risky: connecting an identity to a hierarchically structured 578 identifier systems creates a central attack surface which allows for 579 an easier surveillance of the services running on the domain, domain 580 based censorship [RFC7754], or impersonation of the domain through 581 DNS cache poisoning. The use of a centralized authority always makes 582 censorship through a registry or registrar possible, as well as by 583 using a fake resolver or using proposed standards such as DNS 584 Response Policy Zones [RPZ]. Several technologies have been 585 developed in the IETF to mitigate these risks such as DNS over TLS 586 [RFC7858], DNSSEC [RFC4033], DNS over HTTPS [RFC8484]. When these 587 mitigations are implemented, censorship will not be made impossible 588 but it will be made visible. 590 The structuring of DNS as a hierarchical authority structure also 591 brings about a specific characteristic, namely the possibility of 592 centralized policy making vis-a-vis the management and operation of 593 Top Level Domains, which is what happens partly at ICANN. The impact 594 of ICANN processes on human rights will not be discussed here. 596 This case relates to the following considerations in [RFC8280]: - 597 Security - Privacy - Decentralization - Censorship Resistance - 598 Anonymity - Heterogeneity Support - Integrity - Authenticity - 599 Adaptability - Outcome Transparency 601 6.3.2. Autonomous Systems 603 In order for edge-users to connect to the Internet, they need to be 604 connected to an Autonomous System (AS) which, in turn, has peering or 605 transit relations with other AS'es. This means that in the process 606 of accessing the Internet, edge-users need to accept the policies and 607 practices of the intermediary that provides them access to the other 608 networks. In other words, for users to be able to join the 'network 609 of networks', they always need to connect through an intermediary. 611 While accessing the Internet through an intermediary, the user is 612 forced to accept the policies, practices and principles of a network. 613 This could impede the rights of the edge-user, depending on the 614 implemented policies and practices on the network and how (if at all) 615 they are communicated to them. For example: filtering, blocking, 616 extensive logging, slowing down connection or specific services, or 617 other invasive practices that are not clearly communicated to the 618 user. 620 In practice, the user must accept policies of ASes he has no 621 relationship with, and didn't choose. For instance, there is no way 622 to direct the packets to avoid the Five Eyes, not even to know after 623 the fact where the packet went. [FiveEyes] [SchengenRouting] 624 (Traceroutes give you an idea but the path may change before and 625 after the traceroute.) Given that it is not trivial for an edge-user 626 to operate an AS and engage in peering relation with other ASes, 627 there might not be another way for the edge-user to connect to the 628 network of networks. In this case, users are forced into accepting 629 the policies of a specific network. Such design, combined with the 630 increased importance of the Internet to make use of basic services, 631 forces edge-users to associate with a specific network without 632 consenting -or even knowing- the policies of the network. 634 Additionally, it can be noted that there is no standard and deployed 635 way for the edge-user to choose the routes her packets will go 636 through. [RFC0791] section 3.1 standardized "source routing" and 637 "record route" but neither were deployed, mainly because of serious 638 security issues. 640 This case relates to the following considerations in [RFC8280]: - 641 Security - Privacy - Decentralization - Censorship Resistance - 642 Anonymity - Heterogeneity Support - Integrity - Authenticity - 643 Adaptability - Outcome Transparency 645 7. Discussion: Establishing the relation 647 The case studies show that the Internet infrastructure, the 648 combination of architecture and protocols, facilitates freedom of 649 association and assembly, by allowing groups of people to converse, 650 collaborate, exchange, and build and maintain identities in both 651 structural and occasional manners. The structural forms of group 652 activities are more related to freedom of association, whereas 653 freedom of assembly often has a more incidental nature. The 654 difference between the two, as mentioned, is a gradual one. This is 655 equally true to the infrastructural mediations of these rights. 657 Whereas we established that the Internet infrastructure facilitates 658 freedom of association and assembly, by its very technical and 659 material nature, it both creates and limits the spaces for it. This 660 is an interesting tension because juridically only lawful limitations 661 to the rights are allowed, and even then only if they are necessary, 662 and proportionate. This exposes legal implications of the 663 characteristics of the Internet infrastructure. 665 These preliminary finding suggest that the properties and 666 characteristic through which the Internet infrastructure enables and 667 inhibits freedom of assemblies and association should also be 668 analyzed from a legal lens. The case studies have pointed out 669 several caveats in implementations, that might not necessarily be 670 understood by people while exercising their right to association of 671 assembly, and which thus should either be mitigated, or at least, be 672 communicated to the rights holders. 674 8. Discussion: Protocols and Platforms 676 Whereas the Internet is a network of networks, and can therefore be 677 understood as an assembly, applications on top of the Internet do not 678 necessarily inherit the same structure. Quite the opposite, the 679 Internet increasingly becomes a vehicle for commercial, proprietary 680 and non-interoperable platforms. This lack of interoperation is 681 harming the ability of people to set or negotiate their own terms on 682 which they would like to assemble or associate, or host their own 683 interoperating services. 685 Even though the Internet has always allowed for (partially) closed- 686 off networks, the current trend shows the rise of a small number of 687 very large non-interoperable platforms. Chat has moved from XMPP and 688 IRC to Facebook Messenger, Whatsapp and WeChat and there has been a 689 strong rise of social media networks with large numbers of users, 690 such as Facebook, Twitter and Instagram. A similar trend can be 691 found among e-mail providers, with the significant difference that 692 e-mail is interoperable. 694 Often these non-interoperable platforms are built on open-protocols 695 but do not allow for inter-operability or data-portability. In the 696 case of large private platforms, this in turn leads to strong network 697 externalities also know as a network effect; because the users are 698 there, users will be there. Even though social-media platforms have 699 enabled groups to associate, they have also led to a 'tactical 700 freeze' because of the inability to change the platforms [Tufekci]. 702 Whereas these networks are a ready-to-hand networked public sphere, 703 they do not allow their inhabitants to change or fully understand 704 their workings. In a near future, this could potentially impact 705 infrastructure itself and the distributed nature of the Internet 706 [RFC1287]. 708 9. Conclusions 710 Communities, collaboration and joint action lie at the heart of the 711 Internet. Even at at linguistical level, the words "networks" and 712 "associations" are close synonyms. Both interconnected groups and 713 assemblies of people depend on "links" and "relationships" [Swire]. 714 Taking legal definitions given in international human rights law 715 jurisprudence, we could assert that the right to freedom of assembly 716 and association protect collective expression. These rights protect 717 any collective, gathered either permanently or temporarily for 718 "peaceful" purposes. It is voluntary and uncoerced. 720 Given that the Internet itself was originally designed as a medium of 721 communication for machines that share resources with each other as 722 equals [RFC0903], the Internet is now one of the most basic 723 infrastructures for the right to freedom of assembly and association. 724 Since Internet protocols and the Internet architecture play a central 725 role in the management, development and use of the Internet, we 726 established the relation between some protocols and the right to 727 freedom of assembly and association. 729 After reviewing several typical representative cases, we can conclude 730 that the way in which infrastructure is designed and implemented 731 impacts people's ability to exercise their freedom of assembly and 732 association. This is because different technical designs come with 733 different properties and characteristics. These properties and 734 characteristics on the one hand enable people to assemble and 735 associate, but on the other hand also adds limiting, or even 736 potentially endangering, characteristics. More often than not, this 737 depends on the context. A clearly identified group for open 738 communications, where messages are sent in cleartext and where 739 peoples persistent identities are viisble, can help to faciliate an 740 assembly and build trust, but in other context the same configuration 741 could pose a significant danger. Endangering characteristics should 742 be mitigated, or at least clearly communicated to the users of these 743 technologies. 745 Lastly, the increasing shift towards closed and non-interoperable 746 platforms in chat and social media networks have a significant impact 747 on the distributed and open nature of the Internet. Often these non- 748 interoperable platforms are built on open-protocols but do not allow 749 for inter-operability or data-portability. The use of social-media 750 platforms has enabled groups to associate, but is has also rendered 751 users unable to change platforms, therefore leading to a sort of 752 "forced association" that inhibits people to fully exercise their 753 freedom of assembly and association. 755 10. Acknowledgements 757 - Fred Baker, Jefsey, and Andrew Sullivan for work on Internet 758 definitions. 760 - Stephane Bortzmeyer for several concrete text suggestions that 761 found their way in this document (such as the AS filtering 762 example). 764 - Mark Perkins and Gurshabad for finding a lot of typos. 766 - Gurshabad Grover and an anonymous reviewer for a full review. 768 - The hrpc mailinglist at large for a very constructive discussion 769 on a hard topic. 771 11. Security Considerations 773 As this draft concerns a research document, there are no security 774 considerations. 776 12. IANA Considerations 778 This document has no actions for IANA. 780 13. Research Group Information 782 The discussion list for the IRTF Human Rights Protocol Considerations 783 Research Group is located at the e-mail address hrpc@ietf.org [1]. 784 Information on the group and information on how to subscribe to the 785 list is at https://www.irtf.org/mailman/listinfo/hrpc [2] 787 Archives of the list can be found at: https://www.irtf.org/mail- 788 archive/web/hrpc/current/index.html [3] 790 14. References 792 14.1. Informative References 794 [Abbate] Janet Abbate, ., "Inventing the Internet", Cambridge: MIT 795 Press (2013): 11. , 2013, 796 . 798 [AckermannKargerZhang] 799 Ackerman, M., Karger, D., and A. Zhang, "Mailing Lists: 800 Why Are They Still Here, What's Wrong With Them, and How 801 Can We Fix Them?", Mit. edu (2017): 1. , 2017, 802 . 805 [Anderson] 806 Andersson, E., "The political voice of young citizens 807 Educational conditions for political conversation - school 808 and social media", Utbildning & Demokrati: Tidskrift foer 809 Didaktik och Utbildningspolitik, Volume 21, Number 1, 810 2012, pp. 97-119(23) , 2012, 811 . 814 [AndersonGuarnieri] 815 Anderson, C. and C. Guarnieri, "Fictitious Profiles and 816 WebRTC's Privacy Leaks Used to Identify Iranian 817 Activists", 2016, 818 . 821 [APC] Association for Progressive Communications and . Gayathry 822 Venkiteswaran, "Freedom of assembly and association online 823 in India, Malaysia and Pakistan. Trends, challenges and 824 recommendations.", 2016, 825 . 828 [Benkler] Benkler, Y., "Peer Production and Cooperation", 2009, 829 . 832 [Bloketal] 833 Blok, A., Nakazora, M., and B. Winthereik, 834 "Infrastructuring Environments", Science as Culture 25:1, 835 1-22. , 2016. 837 [Bowker] Bowker, G., "Information mythology and infrastructure", 838 In: L. Bud (Ed.), Information Acumen: The Understanding 839 and use of Knowledge in Modern 840 Business,Routledge,London,1994,pp.231-247 , 1994. 842 [Crawford] 843 Crawford, D., "The WebRTC VPN "Bug" and How to Fix", 2015, 844 . 847 [FiveEyes] 848 Wikipedia, ., "Five Eyes", 2018, 849 . 851 [GithubIETF] 852 Thomson, M. and A. Atlas, "Using GitHub at the IETF", 853 2017. 855 [Haas] Haas, P., "Introduction: epistemic communities and 856 international policy coordination", International 857 Organization, special issue: Knowledge, Power, and 858 International Policy Coordination, Cambridge Journals. 46 859 (1): 1-35. , 1992. 861 [HafnerandLyon] 862 Hafnerand, K. and M. Lyon, "Where Wizards Stay Up Late. 863 The Origins of the Internet", First Touchstone Edition 864 (1998): 93. , 1998, . 866 [HussainHoward] 867 Hussain, M. and P. Howard, "What Best Explains Successful 868 Protest Cascades? ICTs and the Fuzzy Causes of the Arab 869 Spring", Int Stud Rev (2013) 15 (1): 48-66. , 2013, 870 . 872 [ICCPR] United Nations General Assembly, "International Covenant 873 on Civil and Political Rights", 1966, 874 . 877 [Mainwaringetal] 878 Mainwaring, S., Chang, M., and K. Anderson, 879 "Infrastructures and Their Discontents: Implications for 880 Ubicomp", DBLP Conference: Conference: UbiComp 2004: 881 Ubiquitous Computing: 6th International Conference, 882 Nottingham, UK, September 7-10, 2004. Proceedings , 2004, 883 . 886 [Melucci] Melucci, A., "The Process of Collective Identity", Temple 887 University Press, Philadelphia , 1995. 889 [Mosco] Mosco, V., "The Digital Sublime: Myth, Power, and 890 Cyberspace", 2005, 891 . 893 [NelsonHedlun] 894 Minar, N. and M. Hedlun, "A Network of Peers: Models 895 Through the History of the Internet", Peer to Peer: 896 Harnessing the Power of Disruptive Technologies, ed: Andy 897 Oram , 2001, . 902 [OSCE] OSCE Office for Democratic Institutions and Human Rights, 903 "Guidelines on Freedom of Peaceful Assembly", page 24 , 904 2010, . 906 [Pensado] Jaime Pensado, ., "Student Activism. Utopian Dreams.", 907 ReVista. Harvard Review of Latin America (2012). , 2012, 908 . 910 [PipekWulf] 911 Pipek, V. and W. Wolf, "Infrastructuring: Towards an 912 Integrated Perspective on the Design and Use of 913 Information Technology", Journal of the Association for 914 Information Systems (10) 5, pp. 306-332 , 2009. 916 [RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001, 917 April 1969, . 919 [RFC0155] North, J., "ARPA Network mailing lists", RFC 155, 920 DOI 10.17487/RFC0155, May 1971, 921 . 923 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 924 DOI 10.17487/RFC0791, September 1981, 925 . 927 [RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 928 Reverse Address Resolution Protocol", STD 38, RFC 903, 929 DOI 10.17487/RFC0903, June 1984, 930 . 932 [RFC1211] Westine, A. and J. Postel, "Problems with the maintenance 933 of large mailing lists", RFC 1211, DOI 10.17487/RFC1211, 934 March 1991, . 936 [RFC1287] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, 937 "Towards the Future Internet Architecture", RFC 1287, 938 DOI 10.17487/RFC1287, December 1991, 939 . 941 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 942 4)", RFC 1771, DOI 10.17487/RFC1771, March 1995, 943 . 945 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 946 selection, and registration of an Autonomous System (AS)", 947 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 948 . 950 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 951 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 952 . 954 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 955 DOI 10.17487/RFC2810, April 2000, 956 . 958 [RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", 959 RFC 2812, DOI 10.17487/RFC2812, April 2000, 960 . 962 [RFC3233] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58, 963 RFC 3233, DOI 10.17487/RFC3233, February 2002, 964 . 966 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 967 Rose, "DNS Security Introduction and Requirements", 968 RFC 4033, DOI 10.17487/RFC4033, March 2005, 969 . 971 [RFC4084] Klensin, J., "Terminology for Describing Internet 972 Connectivity", BCP 104, RFC 4084, DOI 10.17487/RFC4084, 973 May 2005, . 975 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 976 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 977 DOI 10.17487/RFC4271, January 2006, 978 . 980 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 981 Thayer, "OpenPGP Message Format", RFC 4880, 982 DOI 10.17487/RFC4880, November 2007, 983 . 985 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 986 (TLS) Protocol Version 1.2", RFC 5246, 987 DOI 10.17487/RFC5246, August 2008, 988 . 990 [RFC5694] Camarillo, G., Ed. and IAB, "Peer-to-Peer (P2P) 991 Architecture: Definition, Taxonomies, Examples, and 992 Applicability", RFC 5694, DOI 10.17487/RFC5694, November 993 2009, . 995 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 996 Mail Extensions (S/MIME) Version 3.2 Message 997 Specification", RFC 5751, DOI 10.17487/RFC5751, January 998 2010, . 1000 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 1001 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 1002 2011, . 1004 [RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, 1005 "The WebSocket Protocol as a Transport for the Session 1006 Initiation Protocol (SIP)", RFC 7118, 1007 DOI 10.17487/RFC7118, January 2014, 1008 . 1010 [RFC7194] Hartmann, R., "Default Port for Internet Relay Chat (IRC) 1011 via TLS/SSL", RFC 7194, DOI 10.17487/RFC7194, August 2014, 1012 . 1014 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 1015 Nordmark, "Technical Considerations for Internet Service 1016 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 1017 March 2016, . 1019 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1020 and P. Hoffman, "Specification for DNS over Transport 1021 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1022 2016, . 1024 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 1025 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 1026 October 2017, . 1028 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1029 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1030 . 1032 [RPZ] Vixie, P. and V. Schyver, "DNS Response Policy Zones 1033 (RPZ)", 2017, 1034 . 1036 [SchengenRouting] 1037 Wikipedia, ., "Schengen Routing", 2018, 1038 . 1040 [Schleuder] 1041 Nadir, "Schleuder - A gpg-enabled mailinglist with 1042 remailing-capabilities.", 2017, 1043 . 1045 [SeawrightGerring] 1046 Seawright, J. and J. Gerring, "Case Selection Techniques 1047 in Case Study Research: A Menu of Qualitative and 1048 Quantitative Options", Political Research Quarterly, 1049 61(2), 294-308. , 2008, . 1052 [Sink] Sink, E., "Version Control by Example", 2011, 1053 . 1055 [Star] Star, S., "The Ethnography of Infrastructure", American 1056 Behavioral Scientist, Volume 43 (3), 377-391. , 1999, 1057 . 1060 [StarRuhleder] 1061 Star, S. and K. Ruhleder, "Steps toward an ecology of 1062 infrastructure: Design and access for large information 1063 spaces", Information Systems Research 7 (1) (1996) 1064 111-134. , 1996. 1066 [Swire] Peter Swire, ., "Social Networks, Privacy, and Freedom of 1067 Association: Data Empowerment vs. Data Protection", North 1068 Carolina Law Review (2012) 90 (1): 104. , 2012, 1069 . 1072 [Tocqueville] 1073 de Tocqueville, A., "Democracy in America", 1840, . 1078 [Troncosoetal] 1079 Troncoso, C., Isaakdis, M., Danezis, G., and H. Halpin, 1080 "Systematizing Decentralization and Privacy: Lessons from 1081 15 Years of Research and Deployments", Proceedings on 1082 Privacy Enhancing Technologies ; 2017 (4):307-329 , 2017, 1083 . 1086 [Tufekci] Tufekci, Z., "Twitter and Tear Gas: The Power and 1087 Fragility of Networked Protest", 2017, 1088 . 1090 [UDHR] United Nations General Assembly, "The Universal 1091 Declaration of Human Rights", 1948, 1092 . 1094 [UNGA] Hina Jilani, ., "Human rights defenders", A/59/401 , 2004, 1095 . 1098 [UNHRC] Maina Kiai, ., "Report of the Special Rapporteur on the 1099 rights to freedom of peaceful assembly and of 1100 association", A/HRC/20/27 , 2012, 1101 . 1104 [Vu] Vu, Quang Hieu, ., Lupu, Mihai, ., and . Ooi, Beng Chin, 1105 "Peer-to-Peer Computing: Principles and Applications", 1106 2010, . 1108 [Weiser] Weiser, L., "The Computer for the 21st Century", 1109 Scientific American Ubicomp Paper after Sci Am editing , 1110 1991, . 1113 [Wugh] Nottingham, M., "Using Third Party Services for IETF 1114 Work", 2017, . 1117 14.2. URIs 1119 [1] mailto:hrpc@ietf.org 1121 [2] https://www.irtf.org/mailman/listinfo/hrpc 1123 [3] https://www.irtf.org/mail-archive/web/hrpc/current/index.html 1125 Authors' Addresses 1127 Stephane Couture 1128 University of Montreal 1130 EMail: steph@stephcouture.info 1132 Joseph Lorenzo Hall 1133 CDT 1135 EMail: joe@cdt.org 1137 Niels ten Oever 1138 University of Amsterdam 1140 EMail: mail@nielstenoever.net 1142 Gisela Perez de Acha 1143 Derechos Digitales 1145 EMail: gisela@derechosdigitales.org