idnits 2.17.1 draft-tenoever-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 89 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 16, 2018) is 2260 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1058 -- Looks like a reference, but probably isn't: '2' on line 1060 -- Looks like a reference, but probably isn't: '3' on line 1062 == Unused Reference: 'Abibil' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'ARTICLE19' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'BCP72' is defined on line 773, but no explicit reference was found in the text == Unused Reference: 'GreenMovement' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'Marcus' is defined on line 831, but no explicit reference was found in the text == Unused Reference: 'Pariser' is defined on line 855, but no explicit reference was found in the text == Unused Reference: 'RFC4949' is defined on line 934, but no explicit reference was found in the text == Unused Reference: 'RFC6973' is defined on line 957, but no explicit reference was found in the text == Unused Reference: 'Weisser' is defined on line 1053, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 155 (Obsoleted by RFC 168) -- Obsolete informational reference (is this intentional?): RFC 1771 (Obsoleted by RFC 4271) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Human Rights Protocol Considerations Research Group N. ten Oever 3 Internet-Draft University of Amsterdam 4 Intended status: Informational G. Perez de Acha 5 Expires: August 20, 2018 Derechos Digitales 6 February 16, 2018 8 Freedom of Association on the Internet 9 draft-tenoever-hrpc-association-03 11 Abstract 13 This document scopes the relation between Internet protocols and the 14 right to freedom of assembly and association. Increasingly, the 15 Internet mediates our lives, our relationships and our ability to 16 excercise our human rights. The Internet provides a global public 17 space, but one that is built on private infrastructure. Since 18 Internet protocols play a central role in the management, development 19 and use of the Internet, the relation between protocols and the 20 aforementioned rights should be documented and any adverse impacts of 21 this relation should be mitigated. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 20, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Vocabulary used . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Research questions . . . . . . . . . . . . . . . . . . . . . 5 60 4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Literature Review . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Cases and examples . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Conversing . . . . . . . . . . . . . . . . . . . . . . . 7 64 6.1.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . 7 65 6.1.2. Multi-party video conferencing and risks . . . . . . 8 66 6.1.3. Inter Relay Chat . . . . . . . . . . . . . . . . . . 8 67 6.2. Peer-to-peer networks and systems . . . . . . . . . . . . 9 68 6.2.1. Peer-to-peer system achitectures . . . . . . . . . . 10 69 6.2.2. Version control . . . . . . . . . . . . . . . . . . . 11 70 6.3. Grouping together (identities) . . . . . . . . . . . . . 12 71 6.3.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6.3.2. ASes . . . . . . . . . . . . . . . . . . . . . . . . 12 73 7. Discussion: Protocols vs Platforms . . . . . . . . . . . . . 13 74 8. Discussion: The Internet as an association . . . . . . . . . 14 75 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 77 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 13. Research Group Information . . . . . . . . . . . . . . . . . 16 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 14.1. Informative References . . . . . . . . . . . . . . . . . 16 82 14.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 85 1. Introduction 87 "We shape our tools and, thereafter, our tools shape us."  88 -- John Culkin (1967) 90 The Internet is a technology which shapes modern information 91 societies. The ordering that the Internet provides is socio- 92 technical, in other words, the Internet infrastructure and 93 architecture consists of social and technological arrangements 94 [StarRuhleder]. This odering is not always apparent because 95 infrastructure also tends to hide itself in the societal woodwork 96 [Mosco], or with [Weiser]: 'The most profound technologies are those 97 that disappear'. Next to that infrastructure is often taken for 98 granted by those using it. Infrastructure therefore mostly presents 99 itself either to an epistemic community of experts [Haas] or to a 100 larger public upon breakdown. With the increasing societal use of 101 the Internet the importance of the Internet is growing, and the 102 decisions made about its infrastructure and architecture therefore 103 also become more important. [RFC8280] established the relationship 104 between human rights and Internet protocols, and in this document we 105 seek to uncover the relation between two specific human rights and 106 the Internet infrastructure and architecture. 108 The right to freedom of assembly and association protects collective 109 expression, in turn, systems and protocols than enable communal 110 communication between people and servers allow these rights to 111 prosper. The Internet itself was originally designed as "a medium of 112 communication for machines that share resources with each other as 113 equals" [NelsonHedlun], the Internet thus forms a basic 114 infrastructure for the right freedom of assembly and association. 116 The manner in which communication is designed and implemented impacts 117 the ways in which rights can be excercised. For instance a 118 decentralized and resilient architecture that protects anonimity and 119 privacy, offers a strong protection for the exercise of such freedoms 120 in the online environment. At the same time, centralized solutions 121 have enabled people to group together in recognizable places and 122 helped the visbility of groups. In other words, different 123 architectural designs come with different affordances, or 124 characteristics. These characteristics should be taken into account 125 at the time of design, and when designing, updating and maintaining 126 other parts of the architecture and infrastructure. 128 This draft continues the work started in [RFC8280] by investigating 129 the exact impact of Internet protocols on a specific human rights, 130 namely the right to freedom of assembly and association given their 131 importance for the Internet, in order to mitigate (potential) 132 negative impacts. 134 2. Vocabulary used 136 Architecture The design of a structure 138 Autonomous System (AS) Autonomous Systems are the unit of routing 139 policy in the modern world of exterior routing [RFC1930]. 141 Within the Internet, an autonomous system (AS) is a collection of 142 connected Internet Protocol (IP) routing prefixes under the 143 control of one or more network operators on behalf of a single 144 administrative entity or domain that presents a common, clearly 145 defined routing policy to the Internet [RFC1930]. 147 The classic definition of an Autonomous System is a set of routers 148 under a single technical administration, using an interior gateway 149 protocol and common metrics to route packets within the AS, and 150 using an exterior gateway protocol to route packets to other ASs 151 [RFC1771]. 153 Border Gateway Protocol (BGP) An inter-Autonomous System routing 154 protocol [RFC4271]. 156 Connectivity The extent to which a device or network is able to 157 reach other devices or networks to exchange data. The Internet is 158 the Stool for providing global connectivity [RFC1958]. Different 159 types of connectivity are further specified in [RFC4084]. The 160 combination of the end-to-end principle, interoperability, 161 distributed architecture, resilience, reliability and robustness 162 are the enabling factors that result in connectivity to and on the 163 Internet. 165 Data portability The ability to export ones data from a databases in 166 a format that is compatible with other databases. 168 Decentralization Implementation or deployment of standards, 169 protocols or systems without one single point of control. 171 Distributed system A system with multiple components that have their 172 behavior co-ordinated via message passing. These components are 173 usually spatially separated and communicate using a network, and 174 may be managed by a single root of trust or authority. 175 [Troncosoetal] 177 Infrastructure Underlying basis or structure for a functioning 178 society, organization or community. Because infrastructure is a 179 precondition for other activities it has a procedural, rather than 180 static, nature due to its social and cultural embeddedness. 181 [PipekWulf] [Bloketal]. This means that infrastructure is always 182 relational: infrastructure always develops in relation to 183 something or someone [Bowker]. 185 Internet The Network of networks, that consists of Autonomous 186 Systems that are connected through the Internet Protocol (IP). 188 A persistent socio-technical system over which services are 189 delivered [Mainwaringetal] 190 A techno-social assemblage of devices, users, sensors, networks, 191 routers, governance, administrators, operators and protocols 193 An emergent-process-driven thing that is born from the collections 194 of the ASes that happen to be gathered together at any given time. 195 The fact that they tend to interact at any given time means it is 196 an emergent property that happens because they use the protocols 197 defined at IETF. 199 3. Research questions 201 1. How does the internet architecture enable and/or inhibit freedom 202 of association and assembly? 204 2. If the Internet is used to excercise the right to freedom of 205 association, what are the implications for its architecture and 206 infrastructure? 208 4. Methodology 210 In order to answer the research questions, first a number of cases 211 have been collected to analyze where Internet infrastructure and 212 protocols have either enabled or inhibited groups of people to 213 collaborate, cooperate or communicate. This overview does not aim to 214 cover all possible ways in which people can collectively organize or 215 reach out to each other using Internet infrastructure and Internet 216 protocols, but rather cover typical uses in an effort of doing an 217 ethnography of infrastructure [Star]. Subsequently we analyze the 218 cases with the theoretical framework provided in the literature 219 review and provide recommendations based on the findings. 221 5. Literature Review 223 The right to freedom of assembly and association protects and enables 224 collective action and expression [UDHR] [ICCPR]. These rights ensure 225 everyone in a society has the opportunity to express the opinions 226 they hold in common with others, which in turn facilitates dialogue 227 among citizens, as well as with political leaders or governments 228 [OSCE]. This is relevant because in the process of democratic 229 delibration, causes and opinions are more widely heard when a group 230 of people come together behind the same cause or issue [Tocqueville]. 232 In international law, the right to freedom of assembly and 233 association protects any collective, gathered either permanently or 234 temporarily for "peaceful" purposes. We will later expand on the 235 definitions and limits of "peacefulness" within these rights. For 236 now it is important to underline the propery of "freedom" because the 237 right to freedom of association and assembly is voluntary and 238 uncoerced: anyone can join or leave a group of choice, which in turn 239 means on should not be forced to either join, stay or leave. 241 The difference between freedom of assembly and freedom of association 242 is merely gradual one: the former tends to have an informal and 243 ephemeral nature, whereas the latter refers to established and 244 permanent bodies with specific objectives. Nonetheless, one and the 245 other are protected to the same degree. 247 An assembly is an intentional and temporary gathering of a collective 248 in a private or public space for a specific purpose: demonstrations, 249 indoor meetings, strikes, processions, rallies or even sits-in 250 [UNHRC]. Association on the other hand has a more formal and 251 established nature. It refers to a group of individuals or legal 252 entities brought together in order to collectively act, express, 253 pursue or defend a field of common interests [UNGA]. Within this 254 category we can think about civil society organizations, clubs, 255 cooperatives, NGOs, religious associations, political parties, trade 256 unions or foundations. 258 The right to freedom of assembly and association is quitessential for 259 the Internet, even if privacy and freedom of expression are the most 260 discussed human rights when it comes to the online world. Online 261 association and assembly are crucial to mobilise groups and people 262 where physical gatherings have been impossible or dangerous [APC]. 263 Throughout the world -from the Arab Spring to Latin American student 264 movements- the Internet has also played a crucial role by providing a 265 means for the fast dissemination of information that was otherwise 266 mediated by broadcast media, or even forbidden by the government 267 [Pensado]. According to Hussain and Howard the Internet helped to 268 "build solidarity networks and identification of collective 269 identities and goals, extend the range of local coverage to 270 international broadcast networks" and as platform for contestation 271 for the future of "the future of civil society and information 272 infrastructure" [HussainHoward]. 274 The IETF itself, defined as a 'open global community' of network 275 designers, operators, vendors, and researchers, is also protected by 276 freedom of assembly and association [RFC3233]. Discussions, comments 277 and consensus around RFCs are possible because of the collective 278 expression that freedom of association and assembly allow. The very 279 word "protocol" found its way into the language of computer 280 networking based on the need for collective agreement among network 281 users [HafnerandLyon]. 283 We are aware that some of these examples go beyond the use of 284 Internet protocols and flow over into the applications layer or 285 examples in the offline world whereas the purpose of the following 286 document is to break down the relationship between Internet protocols 287 and the right to freedom of assembly and association. Nonetheless, 288 given that protocols are a part of the socio-technical ordering of 289 reality, we do recognize that in some cases the line between them and 290 applications, implementations, policies and offline realities are 291 often blurred and hard (if not impossible) to differentiate. 293 6. Cases and examples 295 The Internet has become a central mediator for collective action and 296 collaboration. This means the Internet has become a strong enabler 297 of the rights to freedom of association and assembly. 299 Here we will discuss different cases to give an overview of how the 300 Internet protocol and architecture facilitates the freedom of 301 assembly and association. 303 6.1. Conversing 305 +An interactive conversation between two or more people forms the 306 basis for people to organize and associate. According to Anderson 307 "the relationship between political conversation and engagement in 308 the democratic process is strong." [Anderson]. By this definition, 309 what defines the "political" is essentially assembly or association: 310 a basis for the development of social cohesion in society. 312 6.1.1. Mailing Lists 314 Since the beginning of the Internet mailing lists have been a key 315 site of assembly and association [RFC0155] [RFC1211]. In fact, 316 mailing lists were one of the Internet's first functionalities 317 [HafnerandLyon]. 319 In 1971, four years after the invention of email, the first mailing 320 list was created to talk about the idea of using Arpanet for 321 discussion. What had initially propelled the Arpanet project forward 322 as a resource sharing platform was gradually replaced by the idea of 323 a network as a means of bringing people together [Abbate]. More than 324 45 years after, mailing lists are pervasive and help communities to 325 engage, have discussion, share information, ask questions, and build 326 ties. Even as social media and discussion forums grew, mailing lists 327 continue to be widely used [AckermannKargerZhang]. They are a 328 crucial tool to organise groups and individuals around themes and 329 causes [APC]. 331 Mailinglist are still in wide use, also in the IETF because they 332 allow for easy association and allow people to subscribe (join) and 333 unsubscribe (leave) as they please. They also allow for association 334 of specific groups on closed lists. Finally the archival function 335 allows for accountabilty. The downsides of mailinglists are similar 336 to the ones generally associated with e-mail, except that end-to-end 337 encryption such as OpenPGP [RFC4880] and S/MIME [RFC5751] is not 338 possible because the final recipients are not known. There have been 339 experimental solutions to address this issues such as Schleuder 340 [Schleuder], but this has not been standardized or widely deployed. 342 6.1.2. Multi-party video conferencing and risks 344 Multi-party video conferencing protocols such as WebRTC [RFC6176] 345 [RFC7118] allow for robust, bandwidth-adaptive, wideband and super- 346 wideband video and audio discussions in groups. 'The WebRTC protocol 347 was designed to enable responsive real-time communications over the 348 Internet, and is instrumental in allowing streaming video and 349 conferencing applications to run in the browser. In order to easily 350 facilitate direct connections between computers (bypassing the need 351 for a central server to act as a gatekeeper), WebRTC provides 352 functionality to automatically collect the local and public IP 353 addresses of Internet users (ICE or STUN). These functions do not 354 require consent from the user, and can be instantiated by sites that 355 a user visits without their awareness. The potential privacy 356 implications of this aspect of WebRTC are well documented, and 357 certain browsers have provided options to limit its behavior.' 358 [AndersonGuarnieri]. 360 While facilitating freedom of assembly and association multi-party 361 video conferencing tools might pose concrete risks for those who use 362 them. One the one hand WebRTC is providing a resilient channels of 363 communications, but on the other hand it also exposes information 364 about those who are using the tool which might lead to increased 365 surveillance, identification and the consequences that might be 366 derived from that. This is especially concerning because the usage 367 of a VPN does not protect against the exposure of IP addresses 368 [Crawford]. 370 The risk of surveillance is also true in an offline space, but this 371 is generally easy to analyze for the end-user. Security and privacy 372 expectations of the end-user could be made more clear to the user (or 373 improved) which would result in a more secure and/or private 374 excercise or the right to freedom of assembly or association. 376 6.1.3. Inter Relay Chat 378 Internet Relay Chat (IRC) is an application layer protocol that 379 enables communication in the form of text through a a client/server 380 networking model [RFC4059]. In other words, a chat service. IRC 381 clients are computer programs that a user can install on their 382 system. These clients communicate with chat servers to transfer 383 messages to other clients [RFC4059]. 385 For order to be kept within the IRC network, special clases of users 386 become "operators" and are allowed to perform general maintenance 387 functions on the network: basic network tasks such as disconnecting 388 (temporary or permanently) and reconnecting servers as needed 389 [RFC2812]. One of the most controversial power of operators is the 390 ability to remove a user from the connected network by 'force', i.e., 391 operators are able to close the connection between any client and 392 server [RFC2812]. 394 IRC servers may deploy different policies for the ability of users to 395 create their own channels or 'rooms', and for the delegation of 396 'operator'-rights in such a room. Some IRC servers support SSL/TLS 397 connections for security purposes. This helps stop the use of packet 398 sniffer programs to obtain the passwords of IRC users, but has little 399 use beyond this scope due to the public nature of IRC channels. SSL 400 connections require both client and server support (that may require 401 the user to install SSL binaries and IRC client specific patches or 402 modules on their computers). Some networks also use SSL for server 403 to server connections, and provide a special channel flag (such as 404 +S) to only allow SSL-connected users on the channel, while 405 disallowing operator identification in clear text, to better utilize 406 the advantages that SSL provides. 408 6.2. Peer-to-peer networks and systems 410 At the organizational level, peer production is one of the most 411 relevant innovations from Internet mediated social practices. 412 According to [Benkler], it implies 'open collaborative innovation and 413 creation, performed by diverse, decentralized groups organized 414 principally by neither price signals nor organizational hierarchy, 415 harnessing heterogeneous motivations, and governed and managed based 416 on principles other than the residual authority of ownership 417 implemented through contract.' [Benkler]. 419 In his book The Wealth of Networks, Benkler significantly expands on 420 his definition of commons-based peer production. According to 421 Benkler, what distinguishes commons-based production is that it 422 doesn't rely upon or propagate proprietary knowledge: "The inputs and 423 outputs of the process are shared, freely or conditionally, in an 424 institutional form that leaves them equally available for all to use 425 as they choose at their individual discretion." [Benkler] To ensure 426 that the knowledge generated is available for free use, commons-based 427 projects are often shared under an open license. 429 6.2.1. Peer-to-peer system achitectures 431 Peer-to-peer (P2P) is esentially a model of how people interact in 432 real life because "we deal directly with one another whenever we wish 433 to" [Vu]. Usually if we need something we ask our peers, who in turn 434 refer us to other peers. In this sense, the ideal definition of P2P 435 is that "nodes are able to directly exchange resources and services 436 between themselves without the need for centralized servers" and 437 where each participating node typically acts both as a server and as 438 a client [Vu]. In RFC 5694 P2P has been defined as peers or nodes 439 that should be able to communicate directly between themselves 440 without passing intermediaries, and that the system should be self- 441 organizing and have decentralized control [RFC5694]. With this in 442 mind, the ultimate model of P2P is a completely decentralized system, 443 which is more resistant to speech regulation, immune to single points 444 of failure and have a higher performance and scalability. 445 Nonetheless, in practice some P2P systems are supported by 446 centralized servers and some others have hybrid models where nodes 447 are organized into two layers: the upper tier servers and the lower 448 tier common nodes [Vu]. 450 Since the ARPANET project, the original idea behind the Internet was 451 conceived as what we would now call a peer-to-peer system [RFC0001]. 452 Over time it has increasingly shifted towards a client/server model 453 with "millions of consumer clients communicating with a relatively 454 priviledged set of servers" [NelsonHedlun]. 456 Whether for resource sharing or data sharing, P2P systems are a form 457 of enabling freedom of assembly and association. Not only they allow 458 for effective dissemination of information, but because they leverage 459 computing resources by diminishing costs allowing for the formation 460 of open collectives at the network level. At the same time, in 461 completely descentralized systems the nodes are autonomous and can 462 join or leave the network as they want also makes the system 463 unpredicable: a resource might be only sometimes available, and some 464 others it might be missing or incomplete [Vu]. Lack of information 465 might in turn make association or assembly more difficult. 467 Additionally, when one architecturally asseses the role of P2P 468 systems one can say that: "The main advantage of centralized P2P 469 systems is that they are able to provide a quick and reliable 470 resource locating. Their limitation, however, is that the 471 scalability of the systems is affected by the use of servers. While 472 decentralized P2P systems are better than centralized P2P systems in 473 this aspect, they require a longer time in resource locating. As a 474 result, hybrid P2P systems have been introduced to take advantage of 475 both centralized and decentralized architectures. Basically, to 476 maintain the scalability, similar to decentralized P2P systems, there 477 are no servers in hybrid P2P systems. However, peer nodes that are 478 more powerful than others can be selected to act as servers to serve 479 others. These nodes are often called super peers. In this way, 480 resource locating can be done by both decentralized search techniques 481 and centralized search techniques (asking super peers), and hence the 482 systems benefit from the search techniques of centralized P2P 483 systems." [Vu] 485 6.2.2. Version control 487 Ever since developers needed to collaboratively write, maintain and 488 discuss large code basis for the Internet there have been different 489 approaches of doing so. One approach is discussing code through 490 mailing lists, but this has proven to be hard in case of maintaining 491 the most recent versions. There are many different versions and 492 characteristics of version control systems. 494 A version control system is a piece of software that enables 495 developers on a software team to work together and also archive a 496 complete history of their work [Sink]. This allows teams to be 497 working simultaneously on updated. According to Sink, broadly 498 speaking, the history of version control tools can be dividied into 499 three generations. In the first one, concurrent development meant 500 that only one person could be working on a file at a time. The 501 second generation tools permit simultaneous modifications as long as 502 users merge the current revisions into their work before they are 503 allowed to commit. The third generation tools allow merge and commit 504 to be separated [Sink]. 506 Interestingly no version control system has ever been standardized in 507 the IETF whereas the version control systems like Subversion and Git 508 have are widely used within the community, as well as by working 509 groups. There has been a spirited discussion on whether working 510 groups should use centralized forms of the Git protocol, such as 511 those offered by Gitlab or Github. Proponents argue that this 512 simplifies the workflow and allows for a more transparent workflow. 513 Opponents argue that the relience on a centralized service which is 514 not merely using the Git protocol, but also used non-standardize 515 options like an Issue-Tracker, makes the process less transparent and 516 reliant on a third party. 518 The IETF has not made a decision on the use of centralized instances 519 of git, such as Github or Gitlab. There have been two efforts to 520 standardize the workflow vis a vis these third party services, but 521 these haven't come to fruition: https://www.ietf.org/archive/id/ 522 draft-nottingham-wugh-services-00.txt 523 https://www.ietf.org/archive/id/draft-thomson-github-bcp-00.txt 525 6.3. Grouping together (identities) 527 Collective identities are also protected by freedom of association 528 and assembly. Acording to Melucci these are 'shared definitions 529 produced by several interacting individuals who are concerned with 530 the orientation of their action as well as the field of opportunities 531 and constraints in which their action takes place.' [Melucci] In 532 this sense, assemblies and associations are an important base in the 533 maintenance and development of culture, as well as preservation of 534 minority identities [OSCE]. 536 6.3.1. DNS 538 Domain names allow hosts to be identified by human parsable 539 information. Whereas an IP address might not be the expression of an 540 identity, a domain name can be, and often is. On the other hand the 541 grouping of a certain identity under a specific domain or even a Top 542 Level Domain brings about risks because connecting an identity to a 543 hierarchically structured identifier systems creates a central attack 544 surface. Some of these risks are the surveillance of the services 545 running on the domain, domain based censorship [RFC7754], or 546 impersonation of the domain through DNS cache poisoning. Several 547 technologies have been developed in the IETF to mitigated these risks 548 such as DNS over TLS [RFC7858], DNSSEC [RFC4033], and TLS [RFC5246]. 549 These mitigations would, when implemented, not make censorship 550 impossible, but rather make it visible. The use of a centralized 551 authority always makes censorship through a registry or registrar 552 possible, as well as by using a fake resolver or using proposed 553 standards such as DNS Response Policy Zones [RPZ]. 555 The structuring of DNS as a hierarchical authority structure also 556 brings about specific characteristic, namely the possibility of 557 centralized policy making vis a vis the management and operation of 558 Top Level Domains, which is what (in part) happens at ICANN. The 559 impact of ICANN processes on human rights will not be discussed here. 561 6.3.2. ASes 563 In order for edge-users to connect to the Internet, they need to be 564 connected to an Automous System (AS) which, in turn, has peering or 565 transit relations with other AS'es. This means that in the process 566 of accessing the Internet, edge-users need to accept the policies and 567 practices of the intermediary that provides them access to the other 568 networks. In other words, for users to be able to join the 'network 569 of networks', they always need to connect through an intermediary. 571 While accessing the Internet through an intermediary, the user is 572 forced to accept the policies, practices and principles of a network. 574 This could impede the rights of the edge-user, depending on the 575 implemented policies and practices on the network and how (if at all) 576 they are communicated to them. For example: filtering, blocking, 577 extensive logging, slowing down connection or specific services, or 578 other invasive practices that are not clearly communicated to the 579 user. 581 In some cases it also means that there is no other way for the edge- 582 user to connect to the network of networks, and is thus forced into 583 accepting the policies of a specific network, because it is not 584 trivial for an edge-user to operate an AS and engage in peering 585 relation with other ASes. This design, combined with the increased 586 importance of the Internet to make use of basic services, forces 587 edge-user to engage in association with a specific network eventhough 588 the user does not consent with the policies of the network. 590 This is also true for the Border Gateway Protocol - the protocol that 591 selects the route for traffic over the Internet. Aside from 592 significant security issues there is no transparency about the routes 593 that packets have taken, and thus it is also unclear which ASes a 594 packet has transversed. 596 7. Discussion: Protocols vs Platforms 598 The Internet increasingly becomes a vehicle for commercial, 599 propietary, non-interoperable platforms. The Internet has always 600 allowed for closed-off networks, but the current trend show the rise 601 of a small number of very large non-interoperable platforms. Chat 602 has moved from finger [RFC1288], XMPP and IRC to Facebook Messenger, 603 Whatsapp and WeChat and there has been a strong rise of social media 604 networks with large numbers of users, such as Facebook, Twitter and 605 Instagram. A similar trend can be found among e-mail providers, with 606 the significant difference that e-mail is interoperable. 608 Often these non-interoperable platform are built on open-protocols 609 but do not allow for inter-operability or data-portability. In the 610 case of these large platforms this leads to strong network 611 externalities, also know as a network effect; because the users are 612 there, users will be there. The use of social-media platforms has 613 enabled groups to associate, but is has also led to a 'tactical 614 freeze' because of the inability to change the platforms [Tufekci]. 615 Whereas these networks a ready-to-hand networked public sphere, it 616 does not allow for its inhabitants to change, or fully understand, 617 their workings. 619 This potentially has a significant impact on the distributed nature 620 of the Internet [RFC1287]. 622 8. Discussion: The Internet as an association 624 It is undeniable that communities, collaboration and joint action lie 625 at the heart of the Internet. Even at at linguistical level, the 626 words "networks" and "associations" are close synonyms. Both 627 interconnected groups and assemblies of people depend on "links" and 628 "relationships" [Swire]. Assemblies however have an inherently 629 temporary nature, whereas associations do not. Taking these 630 definition and the previous analysis into consideration, we argue 631 that the Internet constitutes an an association. What are the 632 implications of this? Does it mean that every network is an assembly 633 within the association and has absolute freedom to implement its own 634 rules? Or does the importance of a functioning 'larger' association 635 (the Internet) has prevails over the preferences of the smaller 636 assemblies (individual AS'es)? Or rather, is there a tipping point? 637 For instance if an operator (an AS) wants to filter a specific IP- 638 range. Today, they can do it _technically_ (it is quite easy) and 639 _legally_ (their network, their rules, and, for this specific case, 640 few people would complain). _But_ if everyone started to do it, and 641 to filter networks they don't like (or filtering TLDs they don't like 642 in their DNS resolvers), then there would be a significant problem. 643 A minority of operators filtering a specific IP-range, the Internet 644 would still work and would still be "the Internet". A majority of 645 operators filtering a lot of networks they don't like and, at a 646 point, this would no longer be the Internet. This is a case where 647 quantitative changes bring qualitative changes: too much filtering 648 and we would no longer have a global network. Despite that fact that 649 each AS has the right to take decisions such as filtering, if 650 everyone started to exercice this right fully, this would destroy the 651 Internet. 653 The demands that have been set for ASes is very limited and are based 654 on routing principles: an AS must be used for exchanging external 655 routing information with other ASes through BGP, should therefore use 656 BGP and IP and have a routing policy [RFC1930]. So in order to be 657 able to connect to the Internet as an AS, which means to engage in 658 peering or transit relations, there are basic rules one needs to 659 adhere to. But theses rules do not say anything on how the AS will 660 or should treat traffic on its network. If we take the example of 661 ASes, we could say they are private infrastructure (therefore 662 souvereign with the ability to set their own policies), but jointly 663 they form a type of public infrastructure, from the moment the 664 receive an Autonomous Systems Number. But, even things that are 665 private, need to live up to standards because they have public 666 consequences. Especially because specific behaviour of ASes can lead 667 to vicious or virtuous circles. 669 The Internet is made of up interconnected ASes (one would argue that 670 this doesn't include IXPs, but most modern IXPs will have an ASN for 671 their route server (and possibly a separate ASN for their management 672 infrastructure), which jointly form an association. This association 673 should be protected. This means that rights and obligations that 674 sterm from this organizational form, should also be protected and 675 respected. 677 9. Conclusions 679 The Internet has an impact on the ability for people to excercise 680 their right to freedom of association and assembly. The Internet, 681 since its inception has enabled people to jointly communicate, 682 collaborate and collaborate. The same could also be argued with 683 relation to freedom of expression, some have argued that the text in 684 article 19 of the [UDHR] reads like a description of the Internet: 686 [the] freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers. {{UDHR}} 688 The difference between freedom of expression and freedom of 689 association and assembly is that the Internet itself takes the form 690 on an association; it reproduces its features of collaboration. 691 Recognizing this is a crucial step in determining architectural 692 features of the Internet and its usage. 694 10. Acknowledgements 696 - Fred Baker, Jefsey, and Andrew Sullivan for work on Internet 697 definitions 699 - Stephane Bortzmeyer for several concrete text suggestions that 700 found their way in this document (such as the AS filtering 701 example) 703 - the hrpc mailinglist at large for a very constructive discussion 704 on a hard topic. 706 11. Security Considerations 708 As this draft concerns a research document, there are no security 709 considerations. 711 12. IANA Considerations 713 This document has no actions for IANA. 715 13. Research Group Information 717 The discussion list for the IRTF Human Rights Protocol Considerations 718 Research Group is located at the e-mail address hrpc@ietf.org [1]. 719 Information on the group and information on how to subscribe to the 720 list is at https://www.irtf.org/mailman/listinfo/hrpc [2] 722 Archives of the list can be found at: https://www.irtf.org/mail- 723 archive/web/hrpc/current/index.html [3] 725 14. References 727 14.1. Informative References 729 [Abbate] Janet Abbate, ., "Inventing the Internet", Cambridge: MIT 730 Press (2013): 11. , 2013, 731 . 733 [Abibil] Danchev, D., "Dissecting 'Operation Ababil' - an OSINT 734 Analysis", 2012, . 737 [AckermannKargerZhang] 738 Ackerman, M., Karger, D., and A. Zhang, "Mailing Lists: 739 Why Are They Still Here, What's Wrong With Them, and How 740 Can We Fix Them?", Mit. edu (2017): 1. , 2017, 741 . 744 [Anderson] 745 Andersson, E., "The political voice of young citizens 746 Educational conditions for political conversation - school 747 and social media", Utbildning & Demokrati: Tidskrift foer 748 Didaktik och Utbildningspolitik, Volume 21, Number 1, 749 2012, pp. 97-119(23) , 2012, 750 . 753 [AndersonGuarnieri] 754 Anderson, C. and C. Guarnieri, "Fictitious Profiles and 755 WebRTC's Privacy Leaks Used to Identify Iranian 756 Activists", 2016, 757 . 760 [APC] Association for Progressive Communications and . Gayathry 761 Venkiteswaran, "Freedom of assembly and association online 762 in India, Malaysia and Pakistan. Trends, challenges and 763 recommendations.", 2016, 764 . 767 [ARTICLE19] 768 ARTICLE 19, "The Right to Protest Principles: Background 769 Paper", 2016, 770 . 773 [BCP72] IETF, "Guidelines for Writing RFC Text on Security 774 Considerations", 2003, 775 . 777 [Benkler] Benkler, Y., "Peer Production and Cooperation", 2009, 778 . 781 [Bloketal] 782 Blok, A., Nakazora, M., and B. Winthereik, 783 "Infrastructuring Environments", Science as Culture 25:1, 784 1-22. , 2016. 786 [Bowker] Bowker, G., "Information mythology and infrastructure", 787 In: L. Bud (Ed.), Information Acumen: The Understanding 788 and use of Knowledge in Modern 789 Business,Routledge,London,1994,pp.231-247 , 1994. 791 [Crawford] 792 Crawford, D., "The WebRTC VPN "Bug" and How to Fix", 2015, 793 . 796 [GreenMovement] 797 Villeneuve, N., "Iran DDoS", 2009, 798 . 800 [Haas] Haas, P., "Introduction: epistemic communities and 801 international policy coordination", International 802 Organization, special issue: Knowledge, Power, and 803 International Policy Coordination, Cambridge Journals. 46 804 (1): 1-35. , 1992. 806 [HafnerandLyon] 807 Hafnerand, K. and M. Lyon, "Where Wizards Stay Up Late. 808 The Origins of the Internet", First Touchstone Edition 809 (1998): 93. , 1998, . 811 [HussainHoward] 812 Hussain, M. and P. Howard, "What Best Explains Successful 813 Protest Cascades? ICTs and the Fuzzy Causes of the Arab 814 Spring", Int Stud Rev (2013) 15 (1): 48-66. , 2013, 815 . 817 [ICCPR] United Nations General Assembly, "International Covenant 818 on Civil and Political Rights", 1966, 819 . 822 [Mainwaringetal] 823 Mainwaring, S., Chang, M., and K. Anderson, 824 "Infrastructures and Their Discontents: Implications for 825 Ubicomp", DBLP Conference: Conference: UbiComp 2004: 826 Ubiquitous Computing: 6th International Conference, 827 Nottingham, UK, September 7-10, 2004. Proceedings , 2004, 828 . 831 [Marcus] Marcus, J., "Commercial Speech on the Internet: Spam and 832 the first amendment", 1998, . 835 [Melucci] Melucci, A., "The Process of Collective Identity", Temple 836 University Press, Philadelphia , 1995. 838 [Mosco] Mosco, V., "The Digital Sublime: Myth, Power, and 839 Cyberspace", 2005, 840 . 842 [NelsonHedlun] 843 Minar, N. and M. Hedlun, "A Network of Peers: Models 844 Through the History of the Internet", Peer to Peer: 845 Harnessing the Power of Disruptive Technologies, ed: Andy 846 Oram , 2001, . 851 [OSCE] OSCE Office for Democratic Institutions and Human Rights, 852 "Guidelines on Freedom of Peaceful Assembly", page 24 , 853 2010, . 855 [Pariser] Pariser, E., "The Filter Bubble: How the New Personalized 856 Web Is Changing What We Read and How We Think", Peguin 857 Books, London. , 2012. 859 [Pensado] Jaime Pensado, ., "Student Activism. Utopian Dreams.", 860 ReVista. Harvard Review of Latin America (2012). , 2012, 861 . 863 [PipekWulf] 864 Pipek, V. and W. Wolf, "Infrastructuring: Towards an 865 Integrated Perspective on the Design and Use of 866 Information Technology", Journal of the Association for 867 Information Systems (10) 5, pp. 306-332 , 2009. 869 [RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001, 870 April 1969, . 872 [RFC0155] North, J., "ARPA Network mailing lists", RFC 155, 873 DOI 10.17487/RFC0155, May 1971, 874 . 876 [RFC1211] Westine, A. and J. Postel, "Problems with the maintenance 877 of large mailing lists", RFC 1211, DOI 10.17487/RFC1211, 878 March 1991, . 880 [RFC1287] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, 881 "Towards the Future Internet Architecture", RFC 1287, 882 DOI 10.17487/RFC1287, December 1991, 883 . 885 [RFC1288] Zimmerman, D., "The Finger User Information Protocol", 886 RFC 1288, DOI 10.17487/RFC1288, December 1991, 887 . 889 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 890 4)", RFC 1771, DOI 10.17487/RFC1771, March 1995, 891 . 893 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 894 selection, and registration of an Autonomous System (AS)", 895 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 896 . 898 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 899 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 900 . 902 [RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", 903 RFC 2812, DOI 10.17487/RFC2812, April 2000, 904 . 906 [RFC3233] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58, 907 RFC 3233, DOI 10.17487/RFC3233, February 2002, 908 . 910 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 911 Rose, "DNS Security Introduction and Requirements", 912 RFC 4033, DOI 10.17487/RFC4033, March 2005, 913 . 915 [RFC4059] Linsenbardt, D., Pontius, S., and A. Sturgeon, "Internet 916 X.509 Public Key Infrastructure Warranty Certificate 917 Extension", RFC 4059, DOI 10.17487/RFC4059, May 2005, 918 . 920 [RFC4084] Klensin, J., "Terminology for Describing Internet 921 Connectivity", BCP 104, RFC 4084, DOI 10.17487/RFC4084, 922 May 2005, . 924 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 925 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 926 DOI 10.17487/RFC4271, January 2006, 927 . 929 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 930 Thayer, "OpenPGP Message Format", RFC 4880, 931 DOI 10.17487/RFC4880, November 2007, 932 . 934 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 935 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 936 . 938 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 939 (TLS) Protocol Version 1.2", RFC 5246, 940 DOI 10.17487/RFC5246, August 2008, 941 . 943 [RFC5694] Camarillo, G., Ed. and IAB, "Peer-to-Peer (P2P) 944 Architecture: Definition, Taxonomies, Examples, and 945 Applicability", RFC 5694, DOI 10.17487/RFC5694, November 946 2009, . 948 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 949 Mail Extensions (S/MIME) Version 3.2 Message 950 Specification", RFC 5751, DOI 10.17487/RFC5751, January 951 2010, . 953 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 954 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 955 2011, . 957 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 958 Morris, J., Hansen, M., and R. Smith, "Privacy 959 Considerations for Internet Protocols", RFC 6973, 960 DOI 10.17487/RFC6973, July 2013, 961 . 963 [RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, 964 "The WebSocket Protocol as a Transport for the Session 965 Initiation Protocol (SIP)", RFC 7118, 966 DOI 10.17487/RFC7118, January 2014, 967 . 969 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 970 Nordmark, "Technical Considerations for Internet Service 971 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 972 March 2016, . 974 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 975 and P. Hoffman, "Specification for DNS over Transport 976 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 977 2016, . 979 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 980 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 981 October 2017, . 983 [RPZ] Vixie, P. and V. Schyver, "DNS Response Policy Zones 984 (RPZ)", 2017, 985 . 987 [Schleuder] 988 Nadir, "Schleuder - A gpg-enabled mailinglist with 989 remailing-capabilities.", 2017, 990 . 992 [Sink] Sink, E., "Version Control by Example", 2011, 993 . 995 [Star] Star, S., "The Ethnography of Infrastructure", American 996 Behavioral Scientist, Volume 43 (3), 377-391. , 1999, 997 . 1000 [StarRuhleder] 1001 Star, S. and K. Ruhleder, "Steps toward an ecology of 1002 infrastructure: Design and access for large information 1003 spaces", Information Systems Research 7 (1) (1996) 1004 111-134. , 1996. 1006 [Swire] Peter Swire, ., "Social Networks, Privacy, and Freedom of 1007 Association: Data Empowerment vs. Data Protection", North 1008 Carolina Law Review (2012) 90 (1): 104. , 2012, 1009 . 1012 [Tocqueville] 1013 de Tocqueville, A., "Democracy in America", 1840, . 1018 [Troncosoetal] 1019 Troncoso, C., Isaakdis, M., Danezis, G., and H. Halpin, 1020 "Systematizing Decentralization and Privacy: Lessons from 1021 15 Years of Research and Deployments", Proceedings on 1022 Privacy Enhancing Technologies ; 2017 (4):307-329 , 2017, 1023 . 1026 [Tufekci] Tufekci, Z., "Twitter and Tear Gas: The Power and 1027 Fragility of Networked Protest", 2017, 1028 . 1030 [UDHR] United Nations General Assembly, "The Universal 1031 Declaration of Human Rights", 1948, 1032 . 1034 [UNGA] Hina Jilani, ., "Human rights defenders", A/59/401 , 2004, 1035 . 1038 [UNHRC] Maina Kiai, ., "Report of the Special Rapporteur on the 1039 rights to freedom of peaceful assembly and of 1040 association", A/HRC/20/27 , 2012, 1041 . 1044 [Vu] Vu, Quang Hieu, ., Lupu, Mihai, ., and . Ooi, Beng Chin, 1045 "Peer-to-Peer Computing: Principles and Applications", 1046 2010, . 1048 [Weiser] Weiser, L., "The Computer for the 21st Century", 1049 Scientific American Ubicomp Paper after Sci Am editing , 1050 1991, . 1053 [Weisser] Weiser, M., "The computer for the 21st century", 1054 Scientific American 265 (3) p. 94-104. , 1991. 1056 14.2. URIs 1058 [1] mailto:hrpc@ietf.org 1060 [2] https://www.irtf.org/mailman/listinfo/hrpc 1062 [3] https://www.irtf.org/mail-archive/web/hrpc/current/index.html 1064 Authors' Addresses 1066 Niels ten Oever 1067 University of Amsterdam 1069 EMail: mail@nielstenoever.net 1071 Gisela Perez de Acha 1072 Derechos Digitales 1074 EMail: gisela@derechosdigitales.org