Subject: Re: [hrpc] draft ID Human Rights Protocol Considerations Glossary (hrpcg)

From: Niels ten Oever <[email-masked]>
Date: Mon, 21 Sep 2015 12:51:37 +0200

Hi Adamantia,

Please find my way overdue response below. I needed to think more
about the issues raised here, so I hope you don't mind.

On 07/05/2015 09:45 AM, Adamantia Rachovitsa wrote:
> Thanks Niels. Please find some responses below.
> 
> 
> I understand that the aim is to give the engineers the language to
>> talk about rights. But what do you mean in the minutes by 
>> ''reverse translation''? Translating the technical concepts
>> outside the technical community? If yes, it opens up the scope of
>> work a lot but there might be a good point. I am not sure if it
>> is possible to develop a shared vocabulary unless we try to 
>> ‘translate’ both ways.
>> 
> 
> That is exactly what was meant with reverse translating.
> 
> OK. Is this supposed to take place in the Glossary draft or
> another document?
> 

I think the glossary is to get a good understanding of both technical
and legal implications of a concept. We might need to introduce legal
concepts there as well and link to treaties etc.

> I agree in general with the visualization of what the freedom of
>> expression is in page 4 of the Glossary draft. There are however 
>> many nuances within this sketch. I hope this is the starting
>> point of the discussion. For example, freedom of expression as a
>> human right is not entirely ‘content agnostic’. In principle, all
>> types of speech fall within the scope of the freedom of
>> expression (commercial speech, political speech, pornography,
>> hate speech) but they are accorded different levels of protection
>> subject to whether legitimate, necessary and proportionate
>> limitations come into play.
>> 
> Agree, but can this ever be decided technically? If not, the
> system should not make a decision, hence this technical
> definition.
> 
> But I might agree with you that this is not a definition, but
> rather a pre-condition.
> 
> I agree - I think that decisions on a technical level can not
> /should not accommodate the human rights point of view. Network
> remains content-agnostic on a technical level. But this is
> something that should be explained to the non-technical
> communities. For example, that freedom of communications on an
> Internet protocols level is not subject to limitations or
> 'trade-offs'.
> 

Agree, I have given this a try with the new definitions of privacy in
the glossary.

Let me know what you think!

>> Also, in the online environment privacy mostly ensures freedom
>> of expression
> 
> Disagree, please elaborate.
> 
> My take on this is that offline freedom of expression and privacy
> are almost always in tension (privacy as a possible limitation to 
> expression). Online however things are different. Privacy
> enhancing measures and the IETF's contemporary work on stepping up
> privacy & security (authentication, preserving anonymity,
> encryption etc) strengthen the effective exercise of freedom of
> expression online. In this way, these technical decisions solidify
> both the right to privacy and freedom of expression.  Schematically
> speaking the technical community decided to protect the user's
> privacy in order to preserve the trust to the network and this
> (unintentionally?) secures the conditions for expressing freely
> online. [Privacy --- Trust --- Right to freedom of expression].
> This is the ordinary functioning of the network, as I see it. There
> are instances of course that privacy may be in tension with 
> expression.
> 
>> – but we cannot deny that there can be tensions between the two.
>> In this sense the sketch describes an ideal condition but we need
>> to elaborate further in order to contextualize the vocabulary
>> both from a human rights and a technical point of view.
>> 
> 
> Excellent, looking forward to suggestions. Sure. I need to see
> first what kind of examples you wish to discuss. I can then try to
> provide context from human rights law. That said, and since many
> people mention the 'balancing' buzzword, it should be explain on
> the one hand how 'trade-offs' take place in standardization process
> (and what are the factors considered as relevant) and on the other
> hand what 'balancing' means in the human rights law context. If you
> agree with this, I can try drafting something.
> 

Agree! It would be great to have guidelines for this balancing act. As
Corinne mentions in her thesis, these will of course be recommendations.

> 
> I am not sure what you would like me to do with the concepts
> mentioned under 2., since I think these are mostly quotes from RFC,
> right? Is your suggestions that we add Interoperability, Quality,
> Relevance, Evolving System and Internet Standards as an Arena for
> Conflict to the glossary?
> 
> I think it will be hard to define some of these terms, but we can
> give it a try. Would you help us start off with some definitions
> for these terms?
> 
> Right. I gave it a go but I understand that the text below is a
> bit creative and not exactly a definition:
> 
> 
> Quality of Internet standards and relevance of human rights 
> considerations in the standardization process
> 
> 
> 
> Pursuant to the principle of constant change, since the function
> and scope of the Internet evolves, so does the role of the IETF in 
> developing standards. Internet standards are adopted on the basis
> of a series of criteria, including high technical quality, support
> by community consensus, and their overall benefit to the Internet.
> The latter calls for an assessment of the interests of all affected
> parties and the specifications’ impact on the Internet’s users. In
> this respect, the effective exercise of the human rights of the
> Internet users is a relevant consideration that needs to be
> appreciated in the standardization process insofar as it is
> directly linked to the reliability and core values of the
> Internet.
> 
> 
> [See B. Carpenter, ed., (June 1996), Architectural Principles of
> the Internet, RFC 1958, Informational; H. Alvestrand, (October
> 2004), A Mission Statement for the IETF, Best Current Practice 95,
> RFC 3935; S. Bradner, (October 1996), The Internet Standards
> Process – Revision 3, RFC 2026, Best Current Practice 9; J. Kempf,
> R. Austein, eds, (March 2004) The Rise of the Middle and the Future
> of the End-to-End: Reflections on the Evolution of the Internet
> Architecture, IAB, RFC 3724, Informational; B. Carpenter, ed.,
> (June 1996), Architectural Principles of the Internet, RFC 1958,
> Informational]__
> 
> 

Added! Would you like to propose definitions for the other concepts
you mentioned as well (Quality, Relevance, Evolving System)?

Best,

Niels

> 
> On 1 July 2015 at 22:54, Niels ten Oever <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Hi Adamantia,
> 
> Thank you for your extensive email and sorry for my late response. 
> Please allow me to reply in line:
> 
> 
> On 06/26/2015 09:24 PM, Adamantia Rachovitsa wrote:ank
>> Hi all. Thanks for all this work. A few thoughts on the
>> documents and emails that Niels circulated:
> 
> 
> 
>> 1. I don’t think that the (theoretical) debate on encoding
>> values into protocols is very useful as a starting point. It is
>> of course informative for members of the technical, social and
>> legal communities in order to have a broader perspective on
>> things. But my understanding is that for the purposes of the
>> present work nobody is talking about encoding values into
>> protocols. It would be a mistake to frame it as such and to
>> promote it like this to the technical community. The issue at
>> stake is what is the impact of protocols on human rights
>> (interaction, enable, hinder etc). In other words we are trying
>> to enable the technical community to recognize (adverse) human
>> rights impacts. When they are in position to do that they will be
>> able to take this impact into consideration when creating and
>> updating protocols alongside many other factors with possible
>> ‘’trade-offs’’. Therefore this discussion is not about encoding
>> freedom of association or freedom of expression into the
>> protocols but rather taking into account the possible impact of 
>> the protocols to human rights. The critical question is can, and 
>> should, the engineers do this? The answer is simply yes:
>> Internet standards are adopted not only on the basis of their
>> technical quality but also following an assessment of the
>> interests of all affected parties as well as the specification’s
>> contribution to the Internet [e.g. S. Bradner, (October 1996),
>> The Internet Standards Process – Revision 3, RFC 2026, Best
>> Current Practice 9, at 2].
> 
> 
> 
>> The momentum of this work is great following the privacy 
>> considerations. I do think however that things with privacy were 
>> easier in the sense that engineers were already aware of its
>> value to their work. Things with other human rights could be
>> trickier and so we need to be convincing about the impact | link
>> | relevance to the interests of all affected parties and the
>> contribution to the Internet.
> 
> 
> Was this a direct reaction to the draft or to the minutes? I don't 
> think we disagree.
> 
> I hope that the methodology that Joana and Corinne have been
> working on can also shed more light on this.
> 
> 
> 
> 
>> 2. Developing a vocabulary and language
> 
> 
> 
>> I agree that there is a need for a basic vocabulary before 
>> developing considerations. We should not see this exhaustively 
>> however. I think there will be lots of work in progress while 
>> developing the considerations and subsequently.
> 
> 
> 
>> I understand that the aim is to give the engineers the language
>> to talk about rights. But what do you mean in the minutes by 
>> ''reverse translation''? Translating the technical concepts
>> outside the technical community? If yes, it opens up the scope of
>> work a lot but there might be a good point. I am not sure if it
>> is possible to develop a shared vocabulary unless we try to 
>> ‘translate’ both ways.
> 
> 
> 
> That is exactly what was meant with reverse translating.
> 
> 
> 
>> I agree in general with the visualization of what the freedom of 
>> expression is in page 4 of the Glossary draft. There are however 
>> many nuances within this sketch. I hope this is the starting
>> point of the discussion. For example, freedom of expression as a
>> human right is not entirely ‘content agnostic’. In principle, all
>> types of speech fall within the scope of the freedom of
>> expression (commercial speech, political speech, pornography,
>> hate speech) but they are accorded different levels of protection
>> subject to whether legitimate, necessary and proportionate
>> limitations come into play.
> 
> Agree, but can this ever be decided technically? If not, the
> system should not make a decision, hence this technical
> definition.
> 
> But I might agree with you that this is not a definition, but
> rather a pre-condition.
> 
> 
>> Also, in the online environment privacy mostly ensures freedom
>> of expression
> 
> Disagree, please elaborate.
> 
>> – but we cannot deny that there can be tensions between the two.
>> In this sense the sketch describes an ideal condition but we need
>> to elaborate further in order to contextualize the vocabulary
>> both from a human rights and a technical point of view.
> 
> 
> Excellent, looking forward to suggestions.
> 
> 
>> I include in the document attached some other possible concepts
>> | keywords for the RFC’s analysis and some terms and notes that
>> I keep in my record that could be relevant to developing the 
>> glossary.
> 
> 
> Thanks for this as well. I added the concepts under 1. to the RFC 
> search list
> 
> I am not sure what you would like me to do with the concepts
> mentioned under 2., since I think these are mostly quotes from RFC,
> right? Is your suggestions that we add Interoperability, Quality,
> Relevance, Evolving System and Internet Standards as an Arena for
> Conflict to the glossary?
> 
> I think it will be hard to define some of these terms, but we can
> give it a try. Would you help us start off with some definitions
> for these terms?
> 
> Best,
> 
> Niels
> 
> 
>> Best,
> 
>> Adamantia
> 
> 
> 
>> On 21 June 2015 at 20:30, Niels ten Oever <[email-masked]
>> <mailto:[email-masked]> <mailto:[email-masked]
>> <mailto:[email-masked]>>> wrote:
> 
>> Dear all,
> 
>> Please find one of the draft IDs on which we worked during the 
>> interim meeting and afterwards underneath (and also attached in 
>> markdown).
> 
>> Happy reading and commenting. Am greatly looking forward to your 
>> comments and/or additions.
> 
>> Best,
> 
>> Niels
> 
>> --- abstract
> 
>> This document presents a glossary of terms used to map between 
>> concepts common in human rights discussions and engineering 
>> discussions.  It is intended to facilitate work by the proposed 
>> Human Rights Protocol Considerations research group, as well as 
>> other authors within the IETF.
> 
>> --- middle
> 
> 
>> Introduction ============
> 
>> "There's a freedom about the Internet: As long as we accept the 
>> rules of sending packets around, we can send packets containing 
>> anything to anywhere."
> 
>> {{Berners-Lee}}
> 
>> The Human Rights Protocol Consideration Proposed Research Group 
>> aims to research whether standards and protocols can enable, 
>> strengthen or threaten human rights, as defined in the Universal 
>> Declaration of Human Rights {{UDHR}} and the International
>> Covenant ons Civil and Political Rights {{ICCPR}}, specifically,
>> but not limited to the right to freedom of expression and the
>> right to freedom of assembly.
> 
>> Comunications between peple working on human rights and
>> engineers working on Internet protocols can be improved with a
>> shared vocabulary.
> 
>> This document aims to provide a shared vocabulary to facilitate 
>> understanding of the intersection between human rights and 
>> Internet protocol design.
> 
>> Glossary ========
> 
>> In the analysis of existing RFCs central design and technical 
>> concepts have been found which impact human rights.  This is an 
>> initial glossary of concepts that could bridge human rights 
>> discourse and technical vocabulary. These definitions should be 
>> improved and further aligned with existing RFCs.
> 
>> Accessibility : Full Internet Connectivity as described in 
>> {{RFC4084}} to provide unfettered access to the Internet
> 
>> : The design of protocols, services or implementation that
>> provide an enabling environment for people with disabilities.
> 
>> : The ability to use information found on the Internet
> 
>> Connectivity : The Internet is the tool for providing global 
>> connectivity {{RFC1958}}. It is the ability to either send and
>> or receive packets.
> 
>> Content-agnosticism : Treating packets identically regardless of 
>> their user content.
> 
>> Distributed : A distributed architecture is a system in which
>> not all processes reside in a single host.
> 
>> Decentralized : Opportunity for implementation of standards or 
>> protocols without a single point of control.
> 
>> Federation : The possibility of of transparently connecting 
>> autonomous systems into a single service
> 
>> Inter-operable : A property of a documented standard or protocol 
>> which allows different implementations to work with each other 
>> without any restricted access or negotiation.
> 
>> Reliable : Reliability ensures that a protocol will execute its 
>> function consistently and error resistant as described and
>> function without unexpected result. A system that is reliable
>> degenerates gracefully and will have a documented way to announce
>> degradation. It also has mechanisms to recover from failure
>> gracefully, and if applicable allow for partial healing.
> 
>> Open standards : Conform  {{RFC2606}}: Various national and 
>> international standards bodies, such as ANSI, ISO, IEEE, and
>> ITU-T, develop a variety of protocol and service specifications
>> that are similar to Technical Specifications defined here.
>> National and international groups also publish "implementors'
>> agreements" that are analogous to Applicability Statements,
>> capturing a body of implementation-specific detail concerned with
>> the practical application of their standards.  All of these are
>> considered to be "open external standards" for the purposes of
>> the Internet Standards Process.
> 
>> Scalable : There should be a clear definition of its scope and 
>> applicability. The limits of a systems scalability should be 
>> defined.
> 
>> Stateless / stateful : In computing, a stateless protocol is a 
>> communications protocol that treats each request as an
>> independent transaction that is unrelated to any previous request
>> so that the communication consists of independent pairs of
>> request and response. A stateless protocol does not require the
>> server to retain session information or status about each
>> communications partner for the duration of multiple requests. In
>> contrast, a protocol which requires keeping of the internal state
>> on the server is known as a stateful protocol. {{WP-Stateless}}
> 
>> Transparent: : "transparency" refers to the original Internet 
>> concept of a single universal logical addressing scheme, and the 
>> mechanisms by which packets may flow from source to destination 
>> essentially unaltered. {{RFC2775}}
> 
>> Debugging: : Debugging is a methodical process of finding and 
>> reducing the number of bugs, or defects, or malfunctions in a 
>> protocol or its implementation, thus making it behave as
>> expected and analyse the consequences that might have emanated
>> from the error. Debugging tends to be harder when various
>> subsystems are tightly coupled, as changes in one may cause bugs
>> to emerge in another. {{WP-Debugging}}
> 
>> End-to-End : One of the key architectural guidelines of the 
>> Internet is the end-to-end principle in the papers by Saltzer, 
>> Reed, and Clark {{Saltzer}} {{Clark}}. The end-to-end principle
>> was originally articulated as a question of where best not to
>> put functions in a communication system. Yet, in the ensuing
>> years, it has evolved to address concerns of maintaining
>> openness, increasing reliability and robustness, and preserving
>> the properties of user choice and ease of new service development
>> as discussed by Blumenthal and Clark in {{Blumenthal}}; concerns
>> that were not part of the original articulation of the end-to-end
>> principle. {{RFC3724}}
> 
>> Internationalization : The practice of the adaptation and 
>> facilitation of protocols, standards, and implementation to 
>> different languages.
> 
>> Openness : The quality of the unfiltered Internet that allows
>> for free access to other hosts
> 
>> Permissionless innovation :  The freedom and ability of to
>> freely create and deploy new protocols on top of the
>> communications constructs that currently exist
> 
>> Privacy : Please see {{ RFC6973 }}
> 
>> Confidentiality : The non-disclosure of information to any 
>> unintended person or host or party
> 
>> Integrity : Maintenance and assurance of the accuracy and 
>> consistency of data to ensure it has not been (intentionally or 
>> unintentionally) altered
> 
>> Anonymity : The fact of not being identified
> 
>> Authenticity : The act of confirming the truth of an attribute of
>> a single piece of data or entity.
> 
>> Robust : The resistance of protocols and their implementations
>> to errors, and to involuntary, legal or malicious attempts to
>> disrupt its mode of operations.
> 
>> The combination of reliability, resilience, anonymity and 
>> authenticity is what makes up security on the Internet
> 
>> ( Reliability  ) security =  (  Resilience    ) (  Integrity
>> ) (  Authenticity  ) ( Anonymity    )
> 
>> The combination of content agnosticism, connectivity, security, 
>> privacy (as defined in {{RFC6973}}, and open standards are the 
>> technical principles that underlay freedom of expression on the 
>> Internet.
> 
> 
> 
>> (  ( End-to-End      )               ) (  (  Interoperability ) )
>> (   (  Resilience       )  Connectivity  ) (   (  Reliability )
>> )   = freedom of expression (    ( Robustness )                 )
>> (              Privacy                   ) ( Security
>> ) (             Content agnosticism ) (            Open Standards
>> )
> 
> 
> 
>> -- Niels ten Oever Head of Digital
> 
>> Article 19 www.article19.org <http://www.article19.org>
> <http://www.article19.org>
> 
>> PGP fingerprint    8D9F C567 BEE4 A431 56C4 678B 08B5 A0F2 636D 
>> 68E9
> 
>> _______________________________________________ hrpc mailing
>> list [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>> https://www.irtf.org/mailman/listinfo/hrpc
> 
> 
> 
>