Proposal for research on human rights protocol considerations

From IUWG
Jump to: navigation, search


Ce Draft est en discussion à l'IRTF : Texte - version actuelle.


Work has been done on privacy issues that should be considered when creating an Internet protocol. This draft suggests that similar considerations may apply for other human rights such as freedom of expression or freedom of association. A proposal is made for work in the IRTF researching the possible connections between human rights and Internet standards and protocols. The goal is to create an informational RFC concerning human rights protocol considerations.



1. Introduction

The recognition that human rights have a role in Internet policies is slowly becoming part of the general discourse. Several reports from former United Nations (UN) Special Rapporteur on the promotion and protection of the right to freedom of opinion and expression, Frank La Rue, have made such relation explicit, which lead to the approval of the landmark resolution "on the promotion, protection and enjoyment of human rights on the Internet" [HRC2012] at the UN Human Rights Council (HRC). More recently, to the resolution "The right to privacy in the digital age" [UNGA2013] at the UN General Assembly.

The NETmundial outcome document [NETmundial] affirms that human rights, as reflected in the Universal Declaration of Human Rights [UDHR], should underpin Internet governance principles.

Nevertheless, a direct relation between Internet Standards and human rights is still something to be explored and more clearly evidenced.


Concerns for freedom of expression and association were a strong part of the world-view of the community involved in developing the first Internet protocols. Apparently, by intention or by coincidence, the Internet was designed with freedom and openness of communications as core values. But as the scale and the industrialization of the Internet has grown greatly, the influence of such world-views started to compete with other values. The belief of the authors is that as the Internet continues to grow, the linkage of Internet protocols to human rights needs to become explicit, structured, and intentional.

Standards and protocols form the basis of the human rights enabling infrastructure of the Internet. It needs to be determined whether there is a causal relationship between Internet protocols and standards, and human rights such as freedom of expression. To study the relationship between the two one would need to carefully consider structural and architectural considerations, as well as specific protocols. The Internet Society paper "Human Rights and Internet Protocols" [HRIP] "explores human rights and Internet protocols comparing the processes for their making and the principles by which they operate and concludes that there are some shared principles between the two." Though that paper does not go into possible reasons, dependencies or guidelines, it initiates the discussion.

More research is needed to map human rights concerns to protocol elements and to frame possible approaches towards protocols that satisfy the implications of human rights standards.

To move this debate further, a list has been created for discussion of this draft: hrpc@article19.io and related ideas - information or subscriptions at: https://lists.ghserv.net/mailman/listinfo/hrpc

1.1. Requirements Language

As this is an informational document describing a research effort, it will not make use of requirements language as defined in RFC 2119 [RFC2119].


2. Research topic

In a manner similar to the work done for RFC 6973 [RFC6973] on Privacy Consideration Guidelines, the premise of this research is that some standards and protocols can solidify, enable or threaten user rights.

As stated in RFC 1958 [RFC1958], the Internet aims to be the global network of networks that provides unfettered connectivity to all users at all times and for any content. Open, secure and reliable connectivity is essential for rights such as freedom of expression and freedom of association, as defined in the Universal Declaration of Human Rights [UDHR]. Therefore, considering connectivity as the ultimate objective of the Internet, this makes a clear case that the Internet is not only an enabler of human rights, but that human rights lie at the basis of, and are ingrained in, the architecture of the network.

An essential part of maintaining the Internet as a tool for communication and connectivity is security. Indeed, "development of security mechanisms is seen as a key factor in the future growth of the Internet as a motor for international commerce and communication" RFC 1984 [RFC1984] and according to the Danvers Doctrine RFC 3365 [RFC3365], there is an overwhelming consensus in the IETF that the best security should be used and standardized.

In RFC 1984 [RFC1984], the Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, expressed: "concern by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy." Indeed, the IETF has been doing a significant job in this area [RFC6973] [RFC7258], considering privacy concerns as a subset of security concerns. [RFC6973] Besides privacy, it should be possible to highlight other aspects of connectivity embedded in standards and protocols that can have human rights considerations, such as freedom of expression and the right to association and assembly online. This research is working to develop a methodology that enables us to extract these considerations.

2.1. Protocol and Standard Examples

Some initial topics that need exploration are indicated in this section. Most of this work has yet to move beyond speculation and casual conversation. Continuing releases of this draft will develop these foundational discussions further, based on discussions to be held on the hrpc@article19.io email list and the work of researchers working on the project.

2.1.1. Architecture

RFC 1958 [RFC1958] mentions "the community believes that the goal [of the Internet] is connectivity, the tool is the Internet Protocol." It continues a bit further: "The current exponential growth of the network seems to show that connectivity is its own reward, and is more valuable than any individual application such as mail or the World-Wide Web." This marks the intrinsic value of connectivity, which is facilitated by the Internet, both in its principle, and in practice. This shows that the underlying principles of the Internet aim to preserve connectivity, which is fundamental and similar to the part of Article 19 of the Universal Declaration of Human Rights [UDHR], which defines a right to receive and to impart information.

Article 19

Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers.

2.1.2. Transparency

Another part of Article 19 of the Universal Declaration of Human Rights [UDHR] mentions that one has the right to hold opinions _without interference_ (emphasis added). This same sentiment can be found in IAB RFC4924 [RFC4924] - Reflection on Internet Transparency where it states: "A network that does not filter or transform the data that it carries may be said to be transparent" or "oblivious" to the content of packets. Networks that provide oblivious transport enable the deployment of new services without requiring changes to the core. It is this flexibility that is perhaps both the Internet's most essential characteristic as well as one of the most important contributors to its success."

2.1.3. HTTP

Websites made it extremely easy for individuals to publish their ideas, opinions and thoughts. Never before has the world seen an infrastructure that made it this easy to share information and ideas with such a large group of other people. The HTTP architecture and standards, including RFC 7230 [RFC7230], RFC 7231 [RFC7231], RFC 7232 [RFC7232], RFC 7234 [RFC7234], RFC 7235 [RFC7235], RFC 7236 [RFC7236], and RFC 7327 [RFC7237], are essential for the publishing of information. The HTTP protocol, therefore, forms an crucial enabler for freedom of expression, but also for the right to freely participate in the culture life of the community (Article 27) [UDHR], to enjoy the arts and to share in scientific advancement and its benefits.

2.1.4. Mailing lists

Collaboration and cooperation have been part of the Internet since its early beginning, one of the instruments of facilitating working together in groups are mailing lists (as described in RFC 2369 [RFC2919], RFC 2919 [RFC2919], and RFC 6783 [RFC6783]. Mailing lists are critical instruments and enablers for group communication and organization, and therefore form early artefacts of the (standardized) ability of Internet standards to enable the right to freedom of assembly and association.

2.1.5. Real time communications

Collaborations and cooperation via the Internet have take a large step forward with the progress of chat and other other real time communications protocols. The work on XMPP RFC 6162 [RFC6162] has enabled new methods of global interactions, cooperation and human right advocacy. The WebRTC work being done to standardize the API and protocol elements to support real-time communications for browsers, mobile applications and IoT by the World Wide Consortium (W3C) and the IETF is another artefact enabling human rights globally on the Internet.

2.1.6. IDNs

English has been the lingua franca of the Internet, but for many Internet user English is not their first language. To have a true global Internet, one that serves the whole world, it would need to reflect the languages of these different communities. The Internationalized Domain Names IDNA2008 (RFC 5890 [RFC5890], RFC 5891 [RFC5891], RFC 5892 [RFC5892], and RFC 5893 [RFC5893]), describes standards for the use of a broad range of strings and characters (some also written from right to left). This enables users who use other characters than the standard LDH ascii typeset to have their own URLs. This shows the ambition of the Internet community to reflect the diversity of users and to be in line with Article 2 of the Universal Declaration of Human Rights which clearly stipulates that "everyone is entitles to all rights and freedoms [..], without distinction of any kind, such as [..] language [..]."[UDHR]


3. Proposal

To start addressing the issue, a mapping exercise analyzing Internet architecture and protocols features, vis-a-vis possible impact on human rights needs is being undertaken.

As part of the research, interviews will be requested with the current and past members of the Internet Architecture Board (IAB), current and past members of the Internet Engineering Steering Group(IESG) and chairs of selected working groups and RFC authors.

Mapping the relation between human rights and protocols and architectures is a new research challenge, which requires a good amount of cross organizational cooperation to develop a consistent methodology. While the authors of this first draft are involved in both human rights advocacy and research on Internet technologies - we believe that bringing this work into the IRTF facilitates and improves this work by bringing human rights experts together with the community of researchers and developers of Internet standards and technologies.

Assuming that the research produces useful results, the objective will evolve into the creation of a set of recommended considerations for the protection of applicable human rights.

3.1. Working Assumptions

In the analysis of existing RFCs central design and technical concepts have been found which impact human rights. These concepts, working assumptions, will form the lens for the analysis of RFCs and will be further described vis a vis their impact on human rights.

The combination of content agnosticism, connectivity, security (as defined in RFC 3365 [RFC3365] and privacy (as defined in RFC 6973 [RFC6973]) are the technical principles that underlay freedom of expression on the Internet.

Privacy and security are defined, so here we focus on concepts that have not been defined as considerations that are relevant for freedom of expression.

This is a first list of concepts, which definitions should be improved and further aligned with existing RFCs.


Connectivity:

The Internet is the tool for providing global connectivity that conforms with RFC 1958 [RFC1958]. Therefore all protocols and standards should aim to improve connectivity, and not to limit it.


Distributed:

To enable and strengthen connectivity, stability, and sustainability of the network, protocols and standards should be developed in a way that can be implemented in a distributed way.

If they are not instrumented in a distributed manner, other 'accountability mechanisms' should be in place. Accountability mechanisms might include features such as access control, logging and other protocol management.


Inter-operable:

Standards exist to design systems that allow for other systems to interact freely and openly.


Reliable:

Reliability ensures that a protocol will execute its function consistently and error resistant as described and function without unexpected result. This includes factors such as throughput, middle boxes, and delay/disruption tolerance. A system that is reliable degenerates gracefully and will have a documented way to announce degradation. It will also have mechanisms to recover from failure.


Scalable:

Any solution should support growth of the network with more hosts, users and traffic. And have clear definition of its scope and ideally a proposition how it can be expanded in order to support greater capacity. Any limits in scalability should be defined.


Stateless / state-full:

If possible protocols should be implemented stateless for reliability and privacy considerations. If not, they should keep as little state as possible.


Content agnostic:

Protocols should not treat packets/datagrams differently based on their content.


Transparent:

Protocols should be transparent in what they can do and can not do and how it is done.


Debugging:

A protocol should allow a user to troubleshoot and debug possible causes of malfunction and loss of reliability.


Robust:

Protocols should be resistant to errors, and to involuntary, legal or malicious attempts to disrupt its mode of operations.

Protocols should be developed in a way that there is no hidden back doors or kill switches. There should also be a clear description on how a protocol recovers from potential failures.


End user-centric / representing stakeholder rights:

As proposed in draft-nottingham-stakeholder-rights-00:

Protocols MUST document relevant primary stakeholders and their interrelationships. [..] End-user-facing application protocols MUST prioritise their users higher than any other stakeholders.


Extensions to existing protocols MUST document how they interact with the extended protocol's stakeholders. If the extended protocol's stakeholders are not yet documented, the extension MAY estimate its impact, in coordination with that protocol's community and the IESG.

The burden of this documentation need not be high; if HTML can do it in a paragraph, so can most protocols. While it might be appropriate in a separate document (e.g., a requirements or use cases draft) or the protocol specification itself, documenting stakeholders in the WG charter has considerable benefits, since it clarifies their relationships up-front.


4. Acknowledgements

This builds on work done by RFC 6973 [RFC6973].

Thanks go to those who have discussed and edited the ideas in this draft. Special thanks go to Joy Liddicoat as the co-author of Human Rights and Internet Protocols [HRIP]


5. IANA Considerations

This memo includes no request to IANA.


6. Security Considerations

As this draft concerns a research proposal, there are no security considerations.


7. References

7.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.


7.2. Informative References

[HRC2011] Human Rights Council, , "Report of the Special Rapporteur on the promotion and protection of the right to freedom of opinion and expression, Human Rights Council, May 2011", 2011.

[HRC2012] General Assembly, UN., "Human Rights Council Resolution on the promotion, protection and enjoyment of human rights on the Internet", 2011, <http://daccess-ods.un.org/TMP/554342.120885849.html>.

[HRC2013] General Assembly, UN., "Report of the Special Rapporteur on the promotion and protection of the right to freedom of opinion and expression, Human Rights Council, April 2013", 2013.

[HRIP] Joy Liddicoat, JL. and AD. Avri Doria, "Human Rights and Internet Protocols: Comparing Processes and Principles", 2012, <https://www.Internetsociety.org/sites/default/files/Human %20Rights%20and%20Internet%20Protocols-%20Comparing%20Proc esses%20and%20Principles.pdf>.

[ICCPR] General Assembly, UN., "International Covenant on Civil and Political Rights", 1966, <http://www.ohchr.org/EN/ProfessionalInterest/Pages/ CCPR.aspx>.

[NETmundial] NetMundial, , "NETmundial Multistakeholder Statement", 2014, <http://netmundial.br/wp-content/uploads/2014/04/ NETmundial-Multistakeholder-Document.pdf>.

[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.

[RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG Statement on Cryptographic Technology and the Internet", RFC 1984, August 1996.

[RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and Procedures", BCP 8, RFC 2014, October 1996.

[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998.

[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.

[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.

[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002.

[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.

[RFC3869] Atkinson, R., Floyd, S., and Internet Architecture Board, "IAB Concerns and Recommendations Regarding Internet Research and Evolution", RFC 3869, August 2004.

[RFC4440] Floyd, S., Paxson, V., Falk, A., and IAB, "IAB Thoughts on the Role of the Internet Research Task Force (IRTF)", RFC 4440, March 2006.

[RFC4924] Aboba, B. and E. Davies, "Reflections on Internet Transparency", RFC 4924, July 2007.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5564] El-Sherbiny, A., Farah, M., Oueichek, I., and A. Al-Zoman, "Linguistic Guidelines for the Use of the Arabic Language in Internet Domains", RFC 5564, February 2010.

[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.

[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.

[RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.

[RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010.

[RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type", RFC 6162, April 2011.

[RFC6783] Levine, J. and R. Gellens, "Mailing Lists and Non-ASCII Addresses", RFC 6783, November 2012.

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013.

[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.

[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

[RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.

[RFC7233] Fielding, R., Lafon, Y., and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.

[RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014.

[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.

[RFC7236] Reschke, J., "Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations", RFC 7236, June 2014.

[RFC7237] Reschke, J., "Initial Hypertext Transfer Protocol (HTTP) Method Registrations", RFC 7237, June 2014.

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014.

[UDHR] General Assembly, UN., "Universal Declaration of Human Rights", 1948, <http://www.un.org/en/documents/udhr/index.shtmlhttp://www.ohchr.org/en/udhr/pages/ introduction.aspx>.

[UNGA2013] General Assembly, UN., "UN General Assembly Resolution "The right to privacy in the digital age" (A/C.3/68/ L.45)", 2013, <http://daccess-ods.un.org/TMP/1133732.05065727.html>.


This is a place holder for an Appendix if it is needed.


Authors

Avri Doria
dotgay LLC
Providence
USA
Email: avri@acm.org
Niels ten Oever
Article 19
Netherlands
Email: niels@article19.org
Joana Varon
Brazil
Email: joana@varonferraz.com