idnits 2.17.1 draft-tenoever-hrpc-association-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (May 29, 2018) is 2151 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1022 -- Looks like a reference, but probably isn't: '2' on line 1024 -- Looks like a reference, but probably isn't: '3' on line 1026 -- 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: November 30, 2018 Derechos Digitales 6 May 29, 2018 8 Freedom of Association on the Internet 9 draft-tenoever-hrpc-association-05 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 exercise our human rights. The Internet provides a global public 17 space, but one that is built predominantly on private infrastructure. 18 Since Internet protocols play a central role in the management, 19 development and use of the Internet, the relation between protocols 20 and the aforementioned rights should be documented and any adverse 21 impacts of 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 November 30, 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 . . . . . . . . . . . 8 66 6.1.3. Internet Relay Chat . . . . . . . . . . . . . . . . . 8 67 6.2. Peer-to-peer networks and systems . . . . . . . . . . . . 9 68 6.2.1. Peer-to-peer system achitectures . . . . . . . . . . 9 69 6.2.2. Version control . . . . . . . . . . . . . . . . . . . 11 70 6.3. Grouping together (identities) . . . . . . . . . . . . . 11 71 6.3.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6.3.2. Autonomous Systems . . . . . . . . . . . . . . . . . 12 73 7. Discussion: Protocols vs Platforms . . . . . . . . . . . . . 13 74 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 12. Research Group Information . . . . . . . . . . . . . . . . . 15 79 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 13.1. Informative References . . . . . . . . . . . . . . . . . 15 81 13.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 84 1. Introduction 86 "We shape our tools and, thereafter, our tools shape us."  87 - John Culkin (1967) 89 The Internet is a technology which shapes modern information 90 societies. The ordering that the Internet provides is socio- 91 technical, in other words, the Internet infrastructure and 92 architecture consists of social and technological arrangements 93 [StarRuhleder]. This ordering is not always apparent because 94 infrastructure also tends to hide itself in the societal woodwork 95 [Mosco], or with [Weiser]: 'The most profound technologies are those 96 that disappear'. Next to that infrastructure is often taken for 97 granted by those using it. Infrastructure therefore is mostly known 98 by an epistemic community of experts [Haas] and only get recognized 99 by the larger public when it fails. With the increasing societal use 100 of the Internet the importance of the Internet is growing, and the 101 decisions made about its infrastructure and architecture therefore 102 also become more important. [RFC8280] established the relationship 103 between human rights and Internet protocols, and in this document we 104 seek to uncover the relation between two specific human rights and 105 the Internet infrastructure and architecture. 107 The rights to freedom of assembly and association protect collective 108 expression, in turn, systems and protocols that enable communal 109 communication between people and servers allow these rights to 110 prosper. The Internet itself was originally designed as "a medium of 111 communication for machines that share resources with each other as 112 equals" [NelsonHedlun], the Internet thus forms a basic 113 infrastructure for the right freedom of assembly and association. 115 The manner in which communication is designed and implemented impacts 116 the ways in which rights can be excercised. For instance a 117 decentralized and resilient architecture that protects anonymity and 118 privacy, offers a strong protection for the exercise of such freedoms 119 in the online environment. At the same time, centralized solutions 120 have enabled people to group together in recognizable places and 121 helped the visbility of groups. In other words, different 122 architectural designs come with different affordances, or 123 characteristics. These characteristics should be taken into account 124 at the time of design, and when designing, updating and maintaining 125 other parts of the architecture and infrastructure. 127 This draft continues the work started in [RFC8280] by investigating 128 the exact impact of Internet protocols on specific human rights, 129 namely the right to freedom of assembly and association given their 130 importance for the Internet, in order to mitigate (potential) 131 negative impacts. 133 2. Vocabulary used 135 Architecture The design of a structure 137 Autonomous System (AS) Autonomous Systems are the unit of routing 138 policy in the modern world of exterior routing [RFC1930]. 140 Within the Internet, an autonomous system (AS) is a collection of 141 connected Internet Protocol (IP) routing prefixes under the 142 control of one or more network operators on behalf of a single 143 administrative entity or domain that presents a common, clearly 144 defined routing policy to the Internet [RFC1930]. 146 The classic definition of an Autonomous System is a set of routers 147 under a single technical administration, using an interior gateway 148 protocol and common metrics to route packets within the AS, and 149 using an exterior gateway protocol to route packets to other ASs 150 [RFC1771]. 152 Border Gateway Protocol (BGP) An inter-Autonomous System routing 153 protocol [RFC4271]. 155 Connectivity The extent to which a device or network is able to 156 reach other devices or networks to exchange data. The Internet is 157 the tool for providing global connectivity [RFC1958]. Different 158 types of connectivity are further specified in [RFC4084]. The 159 combination of the end-to-end principle, interoperability, 160 distributed architecture, resilience, reliability and robustness 161 are the enabling factors that result in connectivity to and on the 162 Internet. 164 Decentralization Implementation or deployment of standards, 165 protocols or systems without one single point of control. 167 Distributed system A system with multiple components that have their 168 behavior co-ordinated via message passing. These components are 169 usually spatially separated and communicate using a network, and 170 may be managed by a single root of trust or authority. 171 [Troncosoetal] 173 Infrastructure Underlying basis or structure for a functioning 174 society, organization or community. Because infrastructure is a 175 precondition for other activities it has a procedural, rather than 176 static, nature due to its social and cultural embeddedness 177 [PipekWulf] [Bloketal]. This means that infrastructure is always 178 relational: infrastructure always develops in relation to 179 something or someone [Bowker]. 181 Internet The Network of networks, that consists of Autonomous 182 Systems that are connected through the Internet Protocol (IP). 184 A persistent socio-technical system over which services are 185 delivered [Mainwaringetal], 187 A techno-social assemblage of devices, users, sensors, networks, 188 routers, governance, administrators, operators and protocols 190 An emergent-process-driven thing that is born from the collections 191 of the ASes that happen to be gathered together at any given time. 192 The fact that they tend to interact at any given time means it is 193 an emergent property that happens because they use the protocols 194 defined at IETF. 196 3. Research questions 198 1. How does the internet architecture enable and/or inhibit freedom 199 of association and assembly? 201 2. If the Internet is used to exercise the right to freedom of 202 association, what are the implications for its architecture and 203 infrastructure? 205 4. Methodology 207 In order to answer the research questions, first a number of cases 208 have been collected to analyze where Internet infrastructure and 209 protocols have either enabled or inhibited groups of people to 210 collaborate, cooperate or communicate. This overview does not aim to 211 cover all possible ways in which people can collectively organize or 212 reach out to each other using Internet infrastructure and Internet 213 protocols, but rather cover typical uses in an attempt at an an 214 ethnography of infrastructure [Star]. Subsequently we analyze the 215 cases with the theoretical framework provided in the literature 216 review and provide recommendations based on the findings. 218 5. Literature Review 220 The rights to freedom of assembly and association protects and 221 enables collective action and expression [UDHR] [ICCPR]. These 222 rights ensure everyone in a society has the opportunity to express 223 the opinions they hold in common with others, which in turn 224 facilitates dialogue among citizens, as well as with political 225 leaders or governments [OSCE]. This is relevant because in the 226 process of democratic delibration, causes and opinions are more 227 widely heard when a group of people come together behind the same 228 cause or issue [Tocqueville]. 230 In international law, the rights to freedom of assembly and 231 association protect any collective, gathered either permanently or 232 temporarily for "peaceful" purposes. It is important to underline 233 the property of "freedom" because the right to freedom of association 234 and assembly are voluntary and uncoerced: anyone can join or leave a 235 group of choice, which in turn means one should not be forced to 236 either join, stay or leave. 238 The difference between freedom of assembly and freedom of association 239 is merely gradual one: the former tends to have an informal and 240 ephemeral nature, whereas the latter refers to established and 241 permanent bodies with specific objectives. Nonetheless, one and the 242 other are protected to the same degree. 244 An assembly is an intentional and temporary gathering of a collective 245 in a private or public space for a specific purpose: demonstrations, 246 indoor meetings, strikes, processions, rallies or even sits-in 247 [UNHRC]. Association on the other hand has a more formal and 248 established nature. It refers to a group of individuals or legal 249 entities brought together in order to collectively act, express, 250 pursue or defend a field of common interests [UNGA]. Within this 251 category we can think about civil society organizations, clubs, 252 cooperatives, NGOs, religious associations, political parties, trade 253 unions or foundations. 255 The right to freedom of assembly and association is quintessential 256 for the Internet, even if privacy and freedom of expression are the 257 most discussed human rights when it comes to the online world. 258 Online association and assembly are crucial to mobilise groups and 259 people where physical gatherings have been impossible or dangerous 260 [APC]. Throughout the world -from the Arab Spring to Latin American 261 student movements and the #WomensMarch- the Internet has also played 262 a crucial role by providing a means for the fast dissemination of 263 information that was otherwise mediated by broadcast media, or even 264 forbidden by the government [Pensado]. According to Hussain and 265 Howard the Internet helped to "build solidarity networks and 266 identification of collective identities and goals, extend the range 267 of local coverage to international broadcast networks" and as 268 platform for contestation for "the future of civil society and 269 information infrastructure" [HussainHoward]. 271 The IETF itself, defined as a 'open global community' of network 272 designers, operators, vendors, and researchers, is also protected by 273 freedom of assembly and association [RFC3233]. Discussions, comments 274 and consensus around RFCs are possible because of the collective 275 expression that freedom of association and assembly allow. The very 276 word "protocol" found its way into the language of computer 277 networking based on the need for collective agreement among network 278 users [HafnerandLyon]. 280 We are aware that some of these examples go beyond the use of 281 Internet protocols and flow over into the applications layer or 282 examples in the offline world whereas the purpose of the following 283 document is to break down the relationship between Internet protocols 284 and the right to freedom of assembly and association. Nonetheless, 285 given that protocols are a part of the socio-technical ordering of 286 reality, we do recognize that in some cases the line between them and 287 applications, implementations, policies and offline realities are 288 often blurred and hard (if not impossible) to differentiate. 290 6. Cases and examples 292 The Internet has become a central mediator for collective action and 293 collaboration. This means the Internet has become a strong enabler 294 of the rights to freedom of association and assembly. 296 Here we will discuss different cases to give an overview of how the 297 Internet protocol and architecture facilitates the freedom of 298 assembly and association. 300 6.1. Conversing 302 An interactive conversation between two or more people forms the 303 basis for people to organize and associate. According to Anderson 304 "the relationship between political conversation and engagement in 305 the democratic process is strong." [Anderson]. By this definition, 306 what defines the "political" is essentially assembly or association: 307 a basis for the development of social cohesion in society. 309 6.1.1. Mailing Lists 311 Since the beginning of the Internet mailing lists have been a key 312 site of assembly and association [RFC0155] [RFC1211]. In fact, 313 mailing lists were one of the Internet's first functionalities 314 [HafnerandLyon]. 316 In 1971, four years after the invention of email, the first mailing 317 list was created to talk about the idea of using Arpanet for 318 discussion. What had initially propelled the Arpanet project forward 319 as a resource sharing platform was gradually replaced by the idea of 320 a network as a means of bringing people together [Abbate]. More than 321 45 years after, mailing lists are pervasive and help communities to 322 engage, have discussion, share information, ask questions, and build 323 ties. Even as social media and discussion forums grow, mailing lists 324 continue to be widely used [AckermannKargerZhang]. They are a 325 crucial tool to organise groups and individuals around themes and 326 causes [APC]. 328 Mailinglist are still in wide use, also in the IETF because they 329 allow for easy association and allow people to subscribe (join) and 330 unsubscribe (leave) as they please. They also allow for association 331 of specific groups on closed lists. Finally the archival function 332 allows for accountabilty. The downsides of mailinglists are similar 333 to the ones generally associated with e-mail, except that end-to-end 334 encryption such as OpenPGP [RFC4880] and S/MIME [RFC5751] is not 335 possible because the final recipients are not known. There have been 336 experimental solutions to address this issue such as Schleuder 337 [Schleuder], but this has not been standardized or widely deployed. 339 6.1.2. Multi-party video conferencing 341 Multi-party video conferencing protocols such as WebRTC [RFC6176] 342 [RFC7118] allow for robust, bandwidth-adaptive, wideband and super- 343 wideband video and audio discussions in groups. 'The WebRTC protocol 344 was designed to enable responsive real-time communications over the 345 Internet, and is instrumental in allowing streaming video and 346 conferencing applications to run in the browser. In order to easily 347 facilitate direct connections between computers (bypassing the need 348 for a central server to act as a gatekeeper), WebRTC provides 349 functionality to automatically collect the local and public IP 350 addresses of Internet users (ICE or STUN). These functions do not 351 require consent from the user, and can be instantiated by sites that 352 a user visits without their awareness. The potential privacy 353 implications of this aspect of WebRTC are well documented, and 354 certain browsers have provided options to limit its behavior.' 355 [AndersonGuarnieri]. 357 While facilitating freedom of assembly and association multi-party 358 video conferencing tools might pose concrete risks for those who use 359 them. One the one hand WebRTC is providing resilient channels of 360 communications, but on the other hand it also exposes information 361 about those who are using the tool which might lead to increased 362 surveillance, identification and the consequences that might be 363 derived from that. This is especially concerning because the usage 364 of a VPN does not protect against the exposure of IP addresses 365 [Crawford]. 367 The risk of surveillance is also true in an offline space, but this 368 is generally easy to analyze for the end-user. Security and privacy 369 expectations of the end-user could be made more clear to the user (or 370 improved) which would result in a more secure and/or private 371 excercise of the right to freedom of assembly or association. 373 6.1.3. Internet Relay Chat 375 Internet Relay Chat (IRC) is an application layer protocol that 376 enables communication in the form of text through a a client/server 377 networking model [RFC2810]. In other words, a chat service. IRC 378 clients are computer programs that a user can install on their 379 system. These clients communicate with chat servers to transfer 380 messages to other clients. 382 For order to be kept within the IRC network, special clases of users 383 become "operators" and are allowed to perform general maintenance 384 functions on the network: basic network tasks such as disconnecting 385 (temporary or permanently) and reconnecting servers as needed 386 [RFC2812]. One of the most controversial power of operators is the 387 ability to remove a user from the connected network by 'force', i.e., 388 operators are able to close the connection between any client and 389 server [RFC2812]. 391 IRC servers may deploy different policies for the ability of users to 392 create their own channels or 'rooms', and for the delegation of 393 'operator'-rights in such a room. Some IRC servers support SSL/TLS 394 connections for security purposes [RFC7194]. This helps stop the use 395 of packet sniffer programs to obtain the passwords of IRC users, but 396 has little use beyond this scope due to the public nature of IRC 397 channels. TLS connections require both client and server support 398 (that may require the user to install TLS binaries and IRC client 399 specific patches or modules on their computers). Some networks also 400 use TLS for server to server connections, and provide a special 401 channel flag (such as +S) to only allow TLS-connected users on the 402 channel, while disallowing operator identification in clear text, to 403 better utilize the advantages that TLS provides. 405 6.2. Peer-to-peer networks and systems 407 At the organizational level, peer production is one of the most 408 relevant innovations from Internet mediated social practices. 409 According to [Benkler], it implies 'open collaborative innovation and 410 creation, performed by diverse, decentralized groups organized 411 principally by neither price signals nor organizational hierarchy, 412 harnessing heterogeneous motivations, and governed and managed based 413 on principles other than the residual authority of ownership 414 implemented through contract.' [Benkler]. 416 In his book The Wealth of Networks, Benkler significantly expands on 417 his definition of commons-based peer production. According to 418 Benkler, what distinguishes commons-based production is that it 419 doesn't rely upon or propagate proprietary knowledge: "The inputs and 420 outputs of the process are shared, freely or conditionally, in an 421 institutional form that leaves them equally available for all to use 422 as they choose at their individual discretion." [Benkler] To ensure 423 that the knowledge generated is available for free use, commons-based 424 projects are often shared under an open license. 426 6.2.1. Peer-to-peer system achitectures 428 Peer-to-peer (P2P) is esentially a model of how people interact in 429 real life because "we deal directly with one another whenever we wish 430 to" [Vu]. Usually if we need something we ask our peers, who in turn 431 refer us to other peers. In this sense, the ideal definition of P2P 432 is that "nodes are able to directly exchange resources and services 433 between themselves without the need for centralized servers" and 434 where each participating node typically acts both as a server and as 435 a client [Vu]. In RFC 5694 P2P has been defined as peers or nodes 436 that should be able to communicate directly between themselves 437 without passing intermediaries, and that the system should be self- 438 organizing and have decentralized control [RFC5694]. With this in 439 mind, the ultimate model of P2P is a completely decentralized system, 440 which is more resistant to speech regulation, immune to single points 441 of failure and have a higher performance and scalability. 442 Nonetheless, in practice some P2P systems are supported by 443 centralized servers and some others have hybrid models where nodes 444 are organized into two layers: the upper tier servers and the lower 445 tier common nodes [Vu]. 447 Since the ARPANET project, the original idea behind the Internet was 448 conceived as what we would now call a peer-to-peer system [RFC0001]. 449 Over time it has increasingly shifted towards a client/server model 450 with "millions of consumer clients communicating with a relatively 451 privileged set of servers" [NelsonHedlun]. 453 Whether for resource sharing or data sharing, P2P systems are 454 enabling freedom of assembly and association. Not only do they allow 455 for effective dissemination of information, but because they leverage 456 computing resources by diminishing costs allowing for the formation 457 of open collectives at the network level. At the same time, in 458 completely decentralized systems the nodes are autonomous and can 459 join or leave the network as they want, which also makes the system 460 unpredicable: a resource might be only sometimes available, and some 461 other resources might be missing or incomplete [Vu]. Lack of 462 information might in turn make association or assembly more 463 difficult. 465 Additionally, when one architecturally asseses the role of P2P 466 systems one can say that: "The main advantage of centralized P2P 467 systems is that they are able to provide a quick and reliable 468 resource locating. Their limitation, however, is that the 469 scalability of the systems is affected by the use of servers. While 470 decentralized P2P systems are better than centralized P2P systems in 471 this aspect, they require a longer time in resource locating. As a 472 result, hybrid P2P systems have been introduced to take advantage of 473 both centralized and decentralized architectures. Basically, to 474 maintain the scalability, similar to decentralized P2P systems, there 475 are no servers in hybrid P2P systems. However, peer nodes that are 476 more powerful than others can be selected to act as servers to serve 477 others. These nodes are often called super peers. In this way, 478 resource locating can be done by both decentralized search techniques 479 and centralized search techniques (asking super peers), and hence the 480 systems benefit from the search techniques of centralized P2P 481 systems." [Vu] 483 6.2.2. Version control 485 Ever since developers needed to collaboratively write, maintain and 486 discuss large code basis for the Internet there have been different 487 approaches of doing so. One approach is discussing code through 488 mailing lists, but this has proven to be hard in case of maintaining 489 the most recent versions. There are many different versions and 490 characteristics of version control systems. 492 A version control system is a piece of software that enables 493 developers on a software team to work together and also archive a 494 complete history of their work [Sink]. This allows teams to be 495 working simultaneously on updated versions. According to Sink, 496 broadly speaking, the history of version control tools can be 497 dividied into three generations. In the first one, concurrent 498 development meant that only one person could be working on a file at 499 a time. The second generation tools permit simultaneous 500 modifications as long as users merge the current revisions into their 501 work before they are allowed to commit. The third generation tools 502 allow merge and commit to be separated [Sink]. 504 Interestingly no version control system has ever been standardized in 505 the IETF whereas the version control systems like Subversion and Git 506 are widely used within the community, as well as by working groups. 507 There has been a spirited discussion on whether working groups should 508 use centralized forms of the Git protocol, such as those offered by 509 Gitlab or Github. Proponents argue that this simplifies the workflow 510 and allows for a more transparent workflow. Opponents argue that the 511 reliance on a centralized service which is not merely using the Git 512 protocol, but also uses non-standardized options like an Issue- 513 Tracker, makes the process less transparent and reliant on a third 514 party. 516 The IETF has not made a decision on the use of centralized instances 517 of Git, such as Github or Gitlab. There have been two efforts to 518 standardize the workflow vis a vis these third party services, but 519 these haven't come to fruition: [Wugh] [GithubIETF]. 521 6.3. Grouping together (identities) 523 Collective identities are also protected by freedom of association 524 and assembly. Acording to Melucci these are 'shared definitions 525 produced by several interacting individuals who are concerned with 526 the orientation of their action as well as the field of opportunities 527 and constraints in which their action takes place.' [Melucci] In 528 this sense, assemblies and associations are an important base in the 529 maintenance and development of culture, as well as preservation of 530 minority identities [OSCE]. 532 6.3.1. DNS 534 Domain names allow hosts to be identified by human parsable 535 information. Whereas an IP address might not be the expression of an 536 identity, a domain name can be, and often is. On the other hand the 537 grouping of a certain identity under a specific domain or even a Top 538 Level Domain brings about risks because connecting an identity to a 539 hierarchically structured identifier systems creates a central attack 540 surface. Some of these risks are the surveillance of the services 541 running on the domain, domain based censorship [RFC7754], or 542 impersonation of the domain through DNS cache poisoning. Several 543 technologies have been developed in the IETF to mitigated these risks 544 such as DNS over TLS [RFC7858], DNSSEC [RFC4033], and TLS [RFC5246]. 545 These mitigations would, when implemented, not make censorship 546 impossible, but rather make it visible. The use of a centralized 547 authority always makes censorship through a registry or registrar 548 possible, as well as by using a fake resolver or using proposed 549 standards such as DNS Response Policy Zones [RPZ]. 551 The structuring of DNS as a hierarchical authority structure also 552 brings about a specific characteristic, namely the possibility of 553 centralized policy making vis a vis the management and operation of 554 Top Level Domains, which is what (in part) happens at ICANN. The 555 impact of ICANN processes on human rights will not be discussed here. 557 6.3.2. Autonomous Systems 559 In order for edge-users to connect to the Internet, they need to be 560 connected to an Automous System (AS) which, in turn, has peering or 561 transit relations with other AS'es. This means that in the process 562 of accessing the Internet, edge-users need to accept the policies and 563 practices of the intermediary that provides them access to the other 564 networks. In other words, for users to be able to join the 'network 565 of networks', they always need to connect through an intermediary. 567 While accessing the Internet through an intermediary, the user is 568 forced to accept the policies, practices and principles of a network. 569 This could impede the rights of the edge-user, depending on the 570 implemented policies and practices on the network and how (if at all) 571 they are communicated to them. For example: filtering, blocking, 572 extensive logging, slowing down connection or specific services, or 573 other invasive practices that are not clearly communicated to the 574 user. 576 In some cases it also means that there is no other way for the edge- 577 user to connect to the network of networks, and is thus forced into 578 accepting the policies of a specific network, because it is not 579 trivial for an edge-user to operate an AS and engage in peering 580 relation with other ASes. This design, combined with the increased 581 importance of the Internet to make use of basic services, forces 582 edge-user to engage in association with a specific network eventhough 583 the user does not consent to the policies of the network. 585 It can be noted also that there is no standard and deployed way for 586 the edge-user to choose the routes her packets will go through. 587 [RFC0791], section 3.1, standardized "source routing" but it was 588 never deployed, mostly because of serious security issues. There is 589 not even a way for the edge-user to know about the routes that 590 packets have actually taken, and which ASes a packet has traversed. 591 [RFC0791], section 3.1, standardized "record route" but it was never 592 deployed. In practice, the user must accept policies of ASes he has 593 no relationship with, and didn't choose. For instance, there is no 594 way to direct the packets to avoid the Five Eyes, not even to know 595 after the fact where the packet went. [FiveEyes] [SchengenRouting] 596 (Traceroutes give you an idea but the path may change before and 597 after the traceroute.) 599 7. Discussion: Protocols vs Platforms 601 The Internet is increasingly becoming a vehicle for commercial, 602 propietary, non-interoperable platforms. The Internet has always 603 allowed for closed-off networks, but the current trend show the rise 604 of a small number of very large non-interoperable platforms. Chat 605 has moved from XMPP and IRC to Facebook Messenger, Whatsapp and 606 WeChat and there has been a strong rise of social media networks with 607 large numbers of users, such as Facebook, Twitter and Instagram. A 608 similar trend can be found among e-mail providers, with the 609 significant difference that e-mail is interoperable. 611 Often these non-interoperable platforms are built on open-protocols 612 but do not allow for inter-operability or data-portability. In the 613 case of these large platforms this leads to strong network 614 externalities, also know as a network effect; because the users are 615 there, users will be there. The use of social-media platforms has 616 enabled groups to associate, but is has also led to a 'tactical 617 freeze' because of the inability to change the platforms [Tufekci]. 618 Whereas these networks are a ready-to-hand networked public sphere, 619 they do not allow their inhabitants to change, or fully understand, 620 their workings. 622 This potentially has a significant impact on the distributed nature 623 of the Internet [RFC1287]. 625 8. Conclusions 627 This document scopes the relation between Internet protocols and the 628 right to freedom of assembly and association. For this reason, the 629 current research started out with two main questions. First, how 630 does the internet architecture enable and/or inhibit freedom of 631 association and assembly? And secondly: if the Internet is used to 632 exercise the right to freedom of association, what are the 633 implications for its architecture and infrastructure? 635 Communities, collaboration and joint action lie at the heart of the 636 Internet. Even at at linguistical level, the words "networks" and 637 "associations" are close synonyms. Both interconnected groups and 638 assemblies of people depend on "links" and "relationships" [Swire]. 639 Taking legal definitions given in international human rights law 640 jurisprudence, we could assert that the right to freedom of assembly 641 and association protect collective expression. These rights protect 642 any collective, gathered either permanently or temporarily for 643 "peaceful" purposes. It is voluntary and uncoerced. 645 Regarding the first question, we argued that given that the Internet 646 itself was originally designed as a medium of communication for 647 machines that share resources with each other as equals, the Internet 648 is one of the most basic infrastructures for the right to freedom of 649 assembly and association. Since Internet protocols play a central 650 role in the management, development and use of the Internet, we 651 established the relation between some protocols and the right to 652 freedom of assembly and association. 654 Regarding the second question, after reviewing protocols that allow 655 mailing lists, to multi-party video conferencing, IRC, peer-to-peer 656 architectures, version control or the functioning of autonomous 657 systems, we can conclude that the way in which infrastructure is 658 designed and implemented impacts the exercise of freedom of assembly 659 and association. This is because different architectural designs 660 come with different affordances, or characteristics. If a 661 decentralized architecture protects anonymity and privacy, both 662 freedoms in the online environment will be enabled. On the other 663 hand, centralized solutions have allowed users to group together and 664 visibilise groups. enabled people to group together in recognizable 665 places and helped the visbility of groups. 667 Lastly, the increasing shift towards closed and non-interoperable 668 platforms in chat and social media networks have a significant impact 669 on the distributed and open nature of the Internet. Often these non- 670 interoperable platforms are built on open-protocols but do not allow 671 for inter-operability or data-portability. The use of social-media 672 platforms has enabled groups to associate, but is has also rendered 673 users unable to change platforms, therefore leading to a sort of 674 "forced association" that stirs faraway from freedom. 676 9. Acknowledgements 678 - Fred Baker, Jefsey, and Andrew Sullivan for work on Internet 679 definitions 681 - Stephane Bortzmeyer for several concrete text suggestions that 682 found their way in this document (such as the AS filtering 683 example) 685 - Mark Perkins for finding a lot of typos 687 - the hrpc mailinglist at large for a very constructive discussion 688 on a hard topic. 690 10. Security Considerations 692 As this draft concerns a research document, there are no security 693 considerations. 695 11. IANA Considerations 697 This document has no actions for IANA. 699 12. Research Group Information 701 The discussion list for the IRTF Human Rights Protocol Considerations 702 Research Group is located at the e-mail address hrpc@ietf.org [1]. 703 Information on the group and information on how to subscribe to the 704 list is at https://www.irtf.org/mailman/listinfo/hrpc [2] 706 Archives of the list can be found at: https://www.irtf.org/mail- 707 archive/web/hrpc/current/index.html [3] 709 13. References 711 13.1. Informative References 713 [Abbate] Janet Abbate, ., "Inventing the Internet", Cambridge: MIT 714 Press (2013): 11. , 2013, 715 . 717 [AckermannKargerZhang] 718 Ackerman, M., Karger, D., and A. Zhang, "Mailing Lists: 719 Why Are They Still Here, What's Wrong With Them, and How 720 Can We Fix Them?", Mit. edu (2017): 1. , 2017, 721 . 724 [Anderson] 725 Andersson, E., "The political voice of young citizens 726 Educational conditions for political conversation - school 727 and social media", Utbildning & Demokrati: Tidskrift foer 728 Didaktik och Utbildningspolitik, Volume 21, Number 1, 729 2012, pp. 97-119(23) , 2012, 730 . 733 [AndersonGuarnieri] 734 Anderson, C. and C. Guarnieri, "Fictitious Profiles and 735 WebRTC's Privacy Leaks Used to Identify Iranian 736 Activists", 2016, 737 . 740 [APC] Association for Progressive Communications and . Gayathry 741 Venkiteswaran, "Freedom of assembly and association online 742 in India, Malaysia and Pakistan. Trends, challenges and 743 recommendations.", 2016, 744 . 747 [Benkler] Benkler, Y., "Peer Production and Cooperation", 2009, 748 . 751 [Bloketal] 752 Blok, A., Nakazora, M., and B. Winthereik, 753 "Infrastructuring Environments", Science as Culture 25:1, 754 1-22. , 2016. 756 [Bowker] Bowker, G., "Information mythology and infrastructure", 757 In: L. Bud (Ed.), Information Acumen: The Understanding 758 and use of Knowledge in Modern 759 Business,Routledge,London,1994,pp.231-247 , 1994. 761 [Crawford] 762 Crawford, D., "The WebRTC VPN "Bug" and How to Fix", 2015, 763 . 766 [FiveEyes] 767 Wikipedia, ., "Five Eyes", 2018, 768 . 770 [GithubIETF] 771 Thomson, M. and A. Atlas, "Using GitHub at the IETF", 772 2017. 774 [Haas] Haas, P., "Introduction: epistemic communities and 775 international policy coordination", International 776 Organization, special issue: Knowledge, Power, and 777 International Policy Coordination, Cambridge Journals. 46 778 (1): 1-35. , 1992. 780 [HafnerandLyon] 781 Hafnerand, K. and M. Lyon, "Where Wizards Stay Up Late. 782 The Origins of the Internet", First Touchstone Edition 783 (1998): 93. , 1998, . 785 [HussainHoward] 786 Hussain, M. and P. Howard, "What Best Explains Successful 787 Protest Cascades? ICTs and the Fuzzy Causes of the Arab 788 Spring", Int Stud Rev (2013) 15 (1): 48-66. , 2013, 789 . 791 [ICCPR] United Nations General Assembly, "International Covenant 792 on Civil and Political Rights", 1966, 793 . 796 [Mainwaringetal] 797 Mainwaring, S., Chang, M., and K. Anderson, 798 "Infrastructures and Their Discontents: Implications for 799 Ubicomp", DBLP Conference: Conference: UbiComp 2004: 800 Ubiquitous Computing: 6th International Conference, 801 Nottingham, UK, September 7-10, 2004. Proceedings , 2004, 802 . 805 [Melucci] Melucci, A., "The Process of Collective Identity", Temple 806 University Press, Philadelphia , 1995. 808 [Mosco] Mosco, V., "The Digital Sublime: Myth, Power, and 809 Cyberspace", 2005, 810 . 812 [NelsonHedlun] 813 Minar, N. and M. Hedlun, "A Network of Peers: Models 814 Through the History of the Internet", Peer to Peer: 815 Harnessing the Power of Disruptive Technologies, ed: Andy 816 Oram , 2001, . 821 [OSCE] OSCE Office for Democratic Institutions and Human Rights, 822 "Guidelines on Freedom of Peaceful Assembly", page 24 , 823 2010, . 825 [Pensado] Jaime Pensado, ., "Student Activism. Utopian Dreams.", 826 ReVista. Harvard Review of Latin America (2012). , 2012, 827 . 829 [PipekWulf] 830 Pipek, V. and W. Wolf, "Infrastructuring: Towards an 831 Integrated Perspective on the Design and Use of 832 Information Technology", Journal of the Association for 833 Information Systems (10) 5, pp. 306-332 , 2009. 835 [RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001, 836 April 1969, . 838 [RFC0155] North, J., "ARPA Network mailing lists", RFC 155, 839 DOI 10.17487/RFC0155, May 1971, 840 . 842 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 843 DOI 10.17487/RFC0791, September 1981, 844 . 846 [RFC1211] Westine, A. and J. Postel, "Problems with the maintenance 847 of large mailing lists", RFC 1211, DOI 10.17487/RFC1211, 848 March 1991, . 850 [RFC1287] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, 851 "Towards the Future Internet Architecture", RFC 1287, 852 DOI 10.17487/RFC1287, December 1991, 853 . 855 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 856 4)", RFC 1771, DOI 10.17487/RFC1771, March 1995, 857 . 859 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 860 selection, and registration of an Autonomous System (AS)", 861 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 862 . 864 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 865 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 866 . 868 [RFC2810] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 869 DOI 10.17487/RFC2810, April 2000, 870 . 872 [RFC2812] Kalt, C., "Internet Relay Chat: Client Protocol", 873 RFC 2812, DOI 10.17487/RFC2812, April 2000, 874 . 876 [RFC3233] Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58, 877 RFC 3233, DOI 10.17487/RFC3233, February 2002, 878 . 880 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 881 Rose, "DNS Security Introduction and Requirements", 882 RFC 4033, DOI 10.17487/RFC4033, March 2005, 883 . 885 [RFC4084] Klensin, J., "Terminology for Describing Internet 886 Connectivity", BCP 104, RFC 4084, DOI 10.17487/RFC4084, 887 May 2005, . 889 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 890 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 891 DOI 10.17487/RFC4271, January 2006, 892 . 894 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 895 Thayer, "OpenPGP Message Format", RFC 4880, 896 DOI 10.17487/RFC4880, November 2007, 897 . 899 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 900 (TLS) Protocol Version 1.2", RFC 5246, 901 DOI 10.17487/RFC5246, August 2008, 902 . 904 [RFC5694] Camarillo, G., Ed. and IAB, "Peer-to-Peer (P2P) 905 Architecture: Definition, Taxonomies, Examples, and 906 Applicability", RFC 5694, DOI 10.17487/RFC5694, November 907 2009, . 909 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 910 Mail Extensions (S/MIME) Version 3.2 Message 911 Specification", RFC 5751, DOI 10.17487/RFC5751, January 912 2010, . 914 [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer 915 (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 916 2011, . 918 [RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, 919 "The WebSocket Protocol as a Transport for the Session 920 Initiation Protocol (SIP)", RFC 7118, 921 DOI 10.17487/RFC7118, January 2014, 922 . 924 [RFC7194] Hartmann, R., "Default Port for Internet Relay Chat (IRC) 925 via TLS/SSL", RFC 7194, DOI 10.17487/RFC7194, August 2014, 926 . 928 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 929 Nordmark, "Technical Considerations for Internet Service 930 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 931 March 2016, . 933 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 934 and P. Hoffman, "Specification for DNS over Transport 935 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 936 2016, . 938 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 939 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 940 October 2017, . 942 [RPZ] Vixie, P. and V. Schyver, "DNS Response Policy Zones 943 (RPZ)", 2017, 944 . 946 [SchengenRouting] 947 Wikipedia, ., "Schengen Routing", 2018, 948 . 950 [Schleuder] 951 Nadir, "Schleuder - A gpg-enabled mailinglist with 952 remailing-capabilities.", 2017, 953 . 955 [Sink] Sink, E., "Version Control by Example", 2011, 956 . 958 [Star] Star, S., "The Ethnography of Infrastructure", American 959 Behavioral Scientist, Volume 43 (3), 377-391. , 1999, 960 . 963 [StarRuhleder] 964 Star, S. and K. Ruhleder, "Steps toward an ecology of 965 infrastructure: Design and access for large information 966 spaces", Information Systems Research 7 (1) (1996) 967 111-134. , 1996. 969 [Swire] Peter Swire, ., "Social Networks, Privacy, and Freedom of 970 Association: Data Empowerment vs. Data Protection", North 971 Carolina Law Review (2012) 90 (1): 104. , 2012, 972 . 975 [Tocqueville] 976 de Tocqueville, A., "Democracy in America", 1840, . 981 [Troncosoetal] 982 Troncoso, C., Isaakdis, M., Danezis, G., and H. Halpin, 983 "Systematizing Decentralization and Privacy: Lessons from 984 15 Years of Research and Deployments", Proceedings on 985 Privacy Enhancing Technologies ; 2017 (4):307-329 , 2017, 986 . 989 [Tufekci] Tufekci, Z., "Twitter and Tear Gas: The Power and 990 Fragility of Networked Protest", 2017, 991 . 993 [UDHR] United Nations General Assembly, "The Universal 994 Declaration of Human Rights", 1948, 995 . 997 [UNGA] Hina Jilani, ., "Human rights defenders", A/59/401 , 2004, 998 . 1001 [UNHRC] Maina Kiai, ., "Report of the Special Rapporteur on the 1002 rights to freedom of peaceful assembly and of 1003 association", A/HRC/20/27 , 2012, 1004 . 1007 [Vu] Vu, Quang Hieu, ., Lupu, Mihai, ., and . Ooi, Beng Chin, 1008 "Peer-to-Peer Computing: Principles and Applications", 1009 2010, . 1011 [Weiser] Weiser, L., "The Computer for the 21st Century", 1012 Scientific American Ubicomp Paper after Sci Am editing , 1013 1991, . 1016 [Wugh] Nottingham, M., "Using Third Party Services for IETF 1017 Work", 2017, . 1020 13.2. URIs 1022 [1] mailto:hrpc@ietf.org 1024 [2] https://www.irtf.org/mailman/listinfo/hrpc 1026 [3] https://www.irtf.org/mail-archive/web/hrpc/current/index.html 1028 Authors' Addresses 1030 Niels ten Oever 1031 University of Amsterdam 1033 EMail: mail@nielstenoever.net 1035 Gisela Perez de Acha 1036 Derechos Digitales 1038 EMail: gisela@derechosdigitales.org