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