Subject: [hrpc] HRPC draft research feedback

From: Scott Craig <[email-masked]>
Date: Fri, 13 May 2016 13:07:26 +0100

Hey Corrine, Niels,

I have been reading though your recent draft <https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/>  <https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/>on protocol considerations. There were a couple of things I couldn’t figure out from the text that I was hoping you might be able to clarify. 

Firstly, what specific relationship is the visual equation (of architectural features to rights) intended to imply?  

	eg. (  Connectivity )
   (      Privacy                )
   (      Security               )   = Right to freedom of expression
   (      Content agnosticism    )
   (      Internationalization   )
   (      Censorship resistance  )
   (      Open Standards         )
    (     Heterogeneity support )

Is it intended to imply that no other architectural feature bears upon that right? Or, is it intended to imply that ALL of the listed architectural features MUST be present in order for the right to be protected? And If not all, then how many features need not be present before a protocol can be considered to abrogate a right?
	
Secondly, what method/principals have you used to determine which rights are affected by which architectural features (technical concepts)? I was expecting an explanation of this in section 5.2.2 of the methodology but I can’t seem to find one there or elsewhere in the doc. Have I missed this somewhere?

Many thanks, and great work!

Scott

Scott Craig | Ford-Mozilla Fellow
Center for Democracy & Technology | cdt.org <https://cdt.org/>
E: [email-masked] <http://cdt.org/> | D: 1.202.407.8887 <tel:202.407.8887> | @scottdavidcraig

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 13 May 2016 19:08:43 +0200

Hi Scott,

Thanks for your question. The relationship that is implied (and I think
it is in the text, if not I should definitely add it), that these
concepts shape the enabling environment on the Internet for exercising a
specific right.

That does not mean that we could not imagine another Internet without
these properties where these rights could also be exercised, but in the
current Internet we think these are the crucial ingredient for enabling
the ability to exercise specific rights.

How we came to this is described in step 5.2.1.4.  Translating Human
Rights Concept into Technical Definitions

Hope this helps, and looking forward to discuss!

Best,

Niels

PS If you think this is not clear from the text, please say so (or even
better, create a pull request here:
https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md )

Niels ten Oever
Head of Digital

Article 19
www.article19.org

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

On 05/13/2016 02:07 PM, Scott Craig wrote:
> Hey Corrine, Niels,
> 
> I have been reading though your recent draft
> <https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/> 
> <https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/>on
> protocol considerations. There were a couple of things I couldn’t figure
> out from the text that I was hoping you might be able to clarify. 
> 
> Firstly, what specific relationship is the visual equation (of
> architectural features to rights) intended to imply?  
> 
> eg. (  Connectivity )
> 
>    (      Privacy                )
> Is it intended to imply that no other architectural feature bears upon
> that right? Or, i**
> *s it intended to imply *that ALL of the 
> ****
> listed
> ** **
> architectural features MUST be present in order for the right to
> be protected? And 
> ****
> *
> *If not all, then h*
> *ow many features need not be present before a protocol can be
> considered to abrogate a right?
> **
> Secondly, w
> hat method/principals have you used to determine which rights are
> affected by which architectural features (technical concepts)? 
> I was expecting an explanation of this in 
> section 5.2.2 of the methodology but I can’t seem to find one there or
> elsewhere in the doc. Have I missed this somewhere?
> *
> 
> *
> *Scott Craig* | Ford-Mozilla Fellow
> Center for Democracy & Technology |* cdt.org <https://cdt.org/>*
> *E:* [email-masked] <http://cdt.org/> | *D:* 1.202.407.8887
> <tel:202.407.8887> | **@scottdavidcraig
> 
> 
> 
> 
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Scott Craig <[email-masked]>
Date: Mon, 16 May 2016 11:37:07 +0100

Hi Niels, 

Thanks for the answer. I had another look through section 5.2.1.4. and I couldn't find a description of the test you have applied to determine whether an architectural feature is a 'crucial ingredient for enabling the ability to exercise specific rights’ (and therefore qualified for inclusion in the equation below.) 

>>    (     Heterogeneity support )

Say, for example, that someone were to claim that a feature (or combination of features) that you have listed as 'shaping the enabling environment' for freedom of expression did not do so. What criteria would be used to assess the merits of that claim? Is there a specific test that was applied during the creation of the second list (see quotation below) which could be examined? (this is what I’ve been trying to find).

>> Mapping the protocols and standards that are related to human rights and create a human rights enabeling environment was the first step. For that we needed to focus on specific technical concepts that underlie these protocols and  standards. On the basis of this list a number of technical concepts that appeared frequently was extracted, and used to create a second list of technical terms that, when combined, create an enabling environment for excercising human rights on the Internet. 

If no test was used, then I would argue it would be highly beneficial to develop one. A test would, I think, aid in ensuring the kind of clear, explicit and Human Rights conscious design decisions you describe below . 

>  It is however important to make consicious and explicit design decisions that take into account the human rights protocol considerations guidelines developed below. This will ensure that the impact protocols can have on human rights is clear and explicit, both for developers and for users.

I'm therefore tentatively proposing two possibilities (based on UK Judicial Review principals) for discussion:

1. Inevitability test (The stricter standard)

An architectural feature does not impinge upon a right unless a violation of the right in question would not be possible but for the inclusion (or absence) of that feature acting alone or in combination with at least one other feature. 

2. Highly Likely test (The weaker standard)

An architectural feature does not impinge upon a right unless the probability of the right in question being violated would be substantially different as a result of the presence (or absence) of that feature acting alone or in combination with at least one other feature

Scott

> On 13 May 2016, at 18:08, Niels ten Oever <[email-masked]> wrote:
> 
> Hi Scott,
>

---

From: Corinne Cath <[email-masked]>
Date: Mon, 16 May 2016 14:49:10 +0100

Hi Scott,

Thanks again for your comments.

Our methodology to determine whether an architectural feature is a 'crucial
ingredient for enabling the ability to exercise specific rights' is based
on several steps which you mentioned.

The meta-approach of linking certain technical properties to certain social
outcomes is based on the work done by Clark (1988) who explains the
relation between the design goals and the features of the protocols. And
that of Abbate (2000) and  Denardis (2013,2014) who explain how social
values, and the personal values of engineers enter into the Internet's
architecture, creating technology that elevates certain social values.

We argue that many of the technical features of the current Internet, like
the crucial features mentioned by Clark (1988) (interoperability,
redundancy, end-to-end etc), fundamentally enable human rights. In order to
establish this we have compared the different properties of human rights to
technical properties of protocols, and also gave multiple examples of cases
where the presence of certain technological features objectively undermine
or enable human rights (like injection of records, traffic interception,
XMPP). It is on the basis of these various case studies, elaborate
discussion on the mailinglist and at various IETF conferences that we came
to determine whether an architectural feature is a 'crucial ingredient for
enabling the ability to exercise specific rights’.

I think we might need to specify that by enabling human rights we do not
assume that if these features are present the realization of human rights
automatically follows suit. Or in other words, these features are necessary
but not sufficient. As we both know, for instance with freedom of
expression, if you have an open, accessible free Internet on a protocol
level but a government blocks access to it or filters for certain content
you do not have freedom of expression in the fullest sense.

The approach we take suggests that the relationship between technical
properties and human rights should be approached as a continuum, where
certain technical properties allow for human rights to be enabled to
different extends. The relationship between the presence of certain legal
principles for enabling human rights on the other hand is much more black
or white.

For example, the Internet can still enable freedom of expression when there
is connectivity (even though the end-users runs a greater risk than when
the technical properties of connectivity and privacy and security are also
present) but freedom of expression (as defined in the UDHR) cannot be fully
guaranteed when, for instance, people can seek and receive information but
not impart it.

As such I think it would be interesting to take up your suggestion and work
out a way to use the
"Highly Likely test", to define which features have what impact on human
rights. However, at the same time I am unsure if a legal test is the best
way to go about it. The potential impact of legal principles being present
or absent has a much clearer impact on for instance human rights like
freedom of expression, than does the presence or absence of certain
technical principles.

I would love to hear what you think!

Best,

On Mon, May 16, 2016 at 11:37 AM, Scott Craig <[email-masked]> wrote:

> Hi Niels,
>
> Thanks for the answer. I had another look through section 5.2.1.4. and I
> couldn't find a description of the test you have applied to determine
> whether an architectural feature is a 'crucial ingredient for enabling the
> ability to exercise specific rights’ (and therefore qualified for inclusion
> in the equation below.)
>
>
> eg. (  Connectivity )
>
>   (      Privacy                )
> Say, for example, that someone were to claim that a feature (or
> combination of features) that you have listed as 'shaping the enabling
> environment' for freedom of expression did not do so. What criteria would
> be used to assess the merits of that claim? Is there a specific test that
> was applied during the creation of the second list (see quotation below)
> which could be examined? (this is what I’ve been trying to find).
>
> Mapping the protocols and standards that are related to human rights and
> create a human rights enabeling environment was the first step. For that we
> needed to focus on specific technical concepts that underlie these
> protocols and  standards. On the basis of this list a number of technical
> concepts that appeared frequently was extracted, *and used to create a
> second list of technical terms that, when combined, create an enabling
> environment for excercising human rights on the Internet. *
>
>
> If no test was used, then I would argue it would be *highly beneficial to
> develop one*. A test would, I think, aid in ensuring the kind of clear,
> explicit and Human Rights conscious design decisions you describe below .
>
>  It is however important to make consicious and explicit design decisions
> that take into account the human rights protocol considerations guidelines
> developed below. This will ensure that the impact protocols can have on
> human rights is clear and explicit, both for developers and for users.
>
>
>
> I'm therefore tentatively proposing two possibilities (based on UK
> Judicial Review principals) for discussion:
>
> *1. Inevitability *test (The stricter standard)
>
> An architectural feature does not impinge upon a right unless a violation
> of the right in question would *not be possible but for the inclusion (or
> absence)* of that feature acting *alone or in combination with at least
> one other feature*.
>
>
> *2. Highly Likely* test (The weaker standard)
>
> An architectural feature does not impinge upon a right unless the
> *probability* of the right in question being violated *would
> be substantially differen*t as a result of the presence (or absence) of
> that feature acting* alone or in combination with at least one other
> feature*
>
>
> Scott
>
>
> *E:* [email-masked] | *D:* 1.202.407.8887 | @scottdavidcraig
>
>
>

-- 
Corinne J.N. Cath

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Mon, 16 May 2016 13:21:57 -0400

> Hope this helps, and looking forward to discuss!

Thanks, Niels!

So, from the text in 5.2.1.4, would you say that the bracketed list of
concepts/ingredients/properties serves as "a list of technical
concepts that when combined create an enabling environment for [a
specific] human right"?

It would be good to make sure we've interrogated, as a group, each of
the technical concepts in the LHS of these equations. E.g., while I'm
a privacy guy to the core, I suspect something more precise like
confidentiality is the underlying technical concept?

best, Joe

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Corinne Cath <[email-masked]>
Date: Tue, 17 May 2016 14:56:09 +0100

Hi Joe,

Great note! I have replied to some of these points in another thread where
I address Scott's comments. I think its titled "What test determines
whether an architectural feature is a crucial ingredient for enabling the
ability to exercise specific right?"

 Could you perhaps check if that thread already addresses some of the
points you made here?

Happy to further discuss,

Best, Corinne

-- 
Corinne Cath

'The management of normality is hard work'

---

From: Scott Craig <[email-masked]>
Date: Tue, 17 May 2016 15:17:12 +0100

Hey Corrine, 

That’s awesome, thanks for the explanation.

To clarify, the aim of the test I’m proposing is not about introducing any kind legal determination. Its purpose is to:

(1) Set a cut-off point on the continuum you describe (above which the effect of an architectural feature on a right can be considered to be material)  
(2) Constrain the authors’ scope of judgement (minimising potential bias)

I think the method you have described (quoted below) is great for identifying candidate features. But my concern is that it’s insufficient to determine that a candidate feature is an enabling (or restricting) feature. 

" It is on the basis of these various case studies, elaborate discussion on the mailinglist and at various IETF conferences that we came to determine whether an architectural feature is a 'crucial ingredient for enabling the ability to exercise specific rights’. "

If no explicit test is applied to the candidate features after identification, I think this causes three problems:

(1) Judgements are arbitrary    
i.e there is no basis on which to argue that the threshold for inclusion was the same for one technical concept as for another. 

(2) Judgements are not replicable. 
i.e it is not possible to claim that different authors would not have come to significantly different conclusions than you have.

(4) Judgements cannot be contested  
e.g if someone were to disagree with your contention that internationalisation has a bearing on the Right to political participation, on what basis would we adjudicate who is correct?

I would agree that the impact of a feature on a right will lie somewhere on a continuum. And perhaps deciding not to have a cut off threshold might actually be attractive (because it would allow us, when convenient, to claim that any feature has a bearing on rights).

However, the issue with the idea of a continuum is that there will always be a cut of point somewhere (for what is or is not included in the guidance). It would be much better that the point be based on some verifiable test than be arbitrary.   

As the time available for protocol designers to consider HR is always going to be limited, I would argue that there is a need to demonstrate that a feature crosses some threshold of effect in order to justify the kind of extra consideration by protocol designers that the document proposes.

The alternative would be to accept that, since every feature could be said to affect rights to some degree, every feature would have some cause to be considered to some extent by a protocol designer. This would make it much harder to argue that a protocol designer should give more consideration to the features contained in the guidance than those not outside it - potentially making the argument for producing such guidance void. 

Hope this makes sense!

Scott

> On 16 May 2016, at 14:49, Corinne Cath <[email-masked]> wrote:
> 
> Hi Scott,
> 
> Our methodology to determine whether an architectural feature is a 'crucial ingredient for enabling the ability to exercise specific rights' is based on several steps which you mentioned. 
> 
> The meta-approach of linking certain technical properties to certain social outcomes is based on the work done by Clark (1988) who explains the relation between the design goals and the features of the protocols. And that of Abbate (2000) and  Denardis (2013,2014) who explain how social values, and the personal values of engineers enter into the Internet's architecture, creating technology that elevates certain social values. 
> 
> We argue that many of the technical features of the current Internet, like the crucial features mentioned by Clark (1988) (interoperability, redundancy, end-to-end etc), fundamentally enable human rights. In order to establish this we have compared the different properties of human rights to technical properties of protocols, and also gave multiple examples of cases where the presence of certain technological features objectively undermine or enable human rights (like injection of records, traffic interception, XMPP). It is on the basis of these various case studies, elaborate discussion on the mailinglist and at various IETF conferences that we came to determine whether an architectural feature is a 'crucial ingredient for enabling the ability to exercise specific rights’. 
> 
> I think we might need to specify that by enabling human rights we do not assume that if these features are present the realization of human rights automatically follows suit. Or in other words, these features are necessary but not sufficient. As we both know, for instance with freedom of expression, if you have an open, accessible free Internet on a protocol level but a government blocks access to it or filters for certain content you do not have freedom of expression in the fullest sense.
> 
> The approach we take suggests that the relationship between technical properties and human rights should be approached as a continuum, where certain technical properties allow for human rights to be enabled to different extends. The relationship between the presence of certain legal principles for enabling human rights on the other hand is much more black or white. 
> 
> For example, the Internet can still enable freedom of expression when there is connectivity (even though the end-users runs a greater risk than when the technical properties of connectivity and privacy and security are also present) but freedom of expression (as defined in the UDHR) cannot be fully guaranteed when, for instance, people can seek and receive information but not impart it. 
> 
> As such I think it would be interesting to take up your suggestion and work out a way to use the 
> "Highly Likely test", to define which features have what impact on human rights. However, at the same time I am unsure if a legal test is the best way to go about it. The potential impact of legal principles being present or absent has a much clearer impact on for instance human rights like freedom of expression, than does the presence or absence of certain technical principles. 
> 
> On Mon, May 16, 2016 at 11:37 AM, Scott Craig <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Niels, 
> 
>> On 13 May 2016, at 18:08, Niels ten Oever <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Scott,
>> 
>> https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md <https://github.com/nllz/IRTF-HRPC/blob/master/draft-research.md> )
>> 
>> 
>> 
>> Niels ten Oever
>> Head of Digital
>> 
>> Article 19
>> www.article19.org <http://www.article19.org/>
>> 
>>> <https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/ <https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/>> 
>>> <https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/ <https://datatracker.ietf.org/doc/draft-tenoever-hrpc-research/>>on
>>> Center for Democracy & Technology |* cdt.org <http://cdt.org/> <https://cdt.org/ <https://cdt.org/>>*
>>> *E:* [email-masked] <mailto:[email-masked]> <http://cdt.org/ <http://cdt.org/>> | *D:* 1.202.407.8887 <tel:1.202.407.8887>
>>> <tel:202.407.8887 <tel:202.407.8887>> | **@scottdavidcraig
>>> 
>>> 
>>> 
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.irtf.org/mailman/listinfo/hrpc <https://www.irtf.org/mailman/listinfo/hrpc>
>>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.irtf.org/mailman/listinfo/hrpc <https://www.irtf.org/mailman/listinfo/hrpc>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/hrpc <https://www.irtf.org/mailman/listinfo/hrpc>
> 
> 
> 
> 
> -- 
> Corinne J.N. Cath

---

From: Scott Craig <[email-masked]>
Date: Tue, 17 May 2016 15:21:37 +0100

Clarification;

The final line should read  'than those outside it’ rather than 'than those not outside it'

> On 17 May 2016, at 15:17, Scott Craig <[email-masked]> wrote:
> 
> than those not outside it

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 17 May 2016 17:51:16 -0400

Yes, I didn't want to send a "Oh, I didn't see that larger answer on
the other thread". ::)

On Tue, May 17, 2016 at 9:56 AM, Corinne Cath <[email-masked]> wrote:
> Hi Joe,
>
> Great note! I have replied to some of these points in another thread where I
> address Scott's comments. I think its titled "What test determines whether
> an architectural feature is a crucial ingredient for enabling the ability to
> exercise specific right?"
>
>  Could you perhaps check if that thread already addresses some of the points
> you made here?
>