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

From: Niels ten Oever <[email-masked]>
Date: Sun, 21 Jun 2015 17:46:00 -0300

Dear all,

Here you can find the draft ID as an easily readable version in pretty
html: http://digitaldissidents.org/draft-glossary.html

Best,

Niels

PS Massive thanks to dkg for greatly simplifying the ID building and
management process.

Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint    8D9F C567 BEE4 A431 56C4
                   678B 08B5 A0F2 636D 68E9

On 06/21/2015 02:30 PM, Niels ten Oever 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          )
> 
> 
>

---

From: Adamantia Rachovitsa <[email-masked]>
Date: Fri, 26 Jun 2015 22:24:39 +0300

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.

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.

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. Also, in the online environment privacy mostly ensures freedom of
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.

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.

Best,

Adamantia

On 21 June 2015 at 20:30, Niels ten Oever <[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).
>
> 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
> ============
>
> 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.
>
> working on Internet protocols can be improved with a shared vocabulary.
>
> 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.
>
> 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
> 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
> 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
>
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
>
>