Subject: [hrpc] Comment on draft-guidelines for RG Last Call

From: Corinne Cath <[email-masked]>
Date: Sat, 30 Jan 2021 18:34:39 +0300

Hi all,

I trust this email finds you well. I did a review of the draft, from my
perspective as an academic. Take it as you please. My main concern is that
some of the language reads a bit deterministic (as, I know so does RFC
8280). It means that a lot of onus is put on the impact of a protocol, as
opposed the role of the individuals that write them.

I think through out the document, it would be interesting (especially in
section 1 through 3.2.5) to see if you can rewrite such that you speak more
directly to the protocol developers. I think that section 3.3 does that
well, in terms of the tone it takes. As it clearly connects the actions of
protocol developers to their potential outcomes.

Hope this is helpful!

Kind regards,

Corinne

---------------------------------

*1. Introduction*

"It provides questions engineers should ask

   themselves when developing or improving protocols if they want to
   understand their potential human rights impact."

>> maybe if they want to understand potential human rights concerns? Impact seems a little deterministic, as you also mention in the next sentence, I wonder if you can prove such direct impact between protocol development in the IETF and impact on human rights.

"The research establishes

   that human rights relate to standards and protocols, and offers a
   common vocabulary of technical concepts that impact human rights and
   how these technical concepts can be combined to ensure that the
   Internet remains an enabling environment for human rights."

>> same comment for the word impact, perhaps shape? influence? etc.

3.1 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.1>.
Human rights threats

 "Protocols and standards can harm or enable the right to freedom of
   expression, right to non-discrimination, right to equal protection,
   right to participate in cultural life, arts and science, right to

   freedom of assembly and association, and the right to security. "

>> again, deterministic language. Perhaps soften or add more concrete examples for context, that draw from current IETF discussions/standards.

3.3 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.3>.
Guidelines for human rights considerations

again, use of the word impact in the introduction.

-- 
Corinne Cath - Speth
Ph.D. Candidate, Oxford Internet Institute & Alan Turing Institute

Web: www.oii.ox.ac.uk/people/corinne-cath
Email: [email-masked] & [email-masked]
Twitter: @C_CS

---

From: farzaneh badii <[email-masked]>
Date: Sat, 30 Jan 2021 17:00:00 -0500

Hello

Adding my comments on this document:
https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05

1. One major issue that I see here and you might be able to easily solve it
is that there is no distinction between user facing protocols and other
protocols. For example, you ask for accessibility and consideration of
culture etc. Are you asking all the protocols to be provided in multiple
languages, even those that only developers and implementers use and not the
actual users? You might want to clarify that.

2.section 3.3.1 on connectivity, you mention that "considering the fact
that network quality and conditions vary across geography and time it is
also important to design protocols such that they are reliable even on low
bandwidth ...". Then in your example you say: Middleboxes (including
NAT).... can create potential for abuse. NAT is a Network Address
Translation protocol. I don't think it has anything to do with bandwidth.
In this example you also mention CDNs. Are you suggesting that the
developer should not consider "Middleboxes" protocols? I think you need to
work on the example of section 3.3.1 some more to make it clearer.

3. section 3.3.20 remedy and attribution
This section worries me. As a  scholar I have worked on cyber attribution
to some extent and believe in general when we have the right processes in
place, attribution is very important and can hold cyber-attackers
accountable. I am aware of some of the attribution processes and
unfortunately some threat intelligence firms and open source intelligence
organizations can violate the privacy of individuals by profiling them.
Also, uncontrolled attribution mechanisms can lead to
frivolous intellectual property claims. Both some threat intelligence firms
and IP firms have used WHOIS extensively in their favor to attribute
cybersecurity attacks and bring forward IP claims. WHOIS protocol did not
have the intention to actually identify organizations and individuals, but
to make them "contactable".and it was still used and mined for so many
years and those who have abused WHOIS have not been held accountable.When
you suggest they consider "attribution" when developing protocols it
concerns me because it is not enough that you limit attribution to
organizations and states. These kinds of attributions can be used against
individuals and until we do not have the right preserving processes to put
in place for those who want to be in the attribution business, rights of
the individual can be at risk. there are very privacy
conscious cybersecurity researchers out there but unfortunately that does
not ensure a systematic practice of attribution in a fair manner. And you
mention attribution to associations is fine and may not directly negatively
impact human rights. Associations can themselves be at risk of
frivolous attacks and frivolous attribution. I am concerned about this
paragraph. I think we should have a conversation about it.

4. Nice to see that you mention DoH. It's a great privacy preserving
protocol.

Farzaneh

On Sat, Jan 30, 2021 at 10:35 AM Corinne Cath <[email-masked]> wrote:

> 3.1 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.1>.  Human rights threats
>
>
> 3.3 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.3>.  Guidelines for human rights considerations
>
>
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Niels ten Oever <[email-masked]>
Date: Sun, 31 Jan 2021 11:51:42 +0100

Hi Farzaneh,

Thanks a lot for the review!

On 30-01-2021 23:00, farzaneh badii wrote:
> Hello
> 
> Adding my comments on this document: https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05 <https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05>
> 
> 1. One major issue that I see here and you might be able to easily solve it is that there is no distinction between user facing protocols and other protocols. For example, you ask for accessibility and consideration of culture etc. Are you asking all the protocols to be provided in multiple languages, even those that only developers and implementers use and not the actual users? You might want to clarify that. 
> 

We had a quite extensive discussion about this in relation to the presentation by Ramsey Nasr who create Qalb, an Arabic programming language. Programmers are the most frequent 'users' of protocols - if we continue using only latin characters and English documentation in protocols we are likely to reproduce the existing lack of diversity in protocol developers communities. But we can make the text on this clearer as well!

> 2.section 3.3.1 on connectivity, you mention that "considering the fact that network quality and conditions vary across geography and time it is also important to design protocols such that they are reliable even on low bandwidth ...". Then in your example you say: Middleboxes (including NAT).... can create potential for abuse. NAT is a Network Address Translation protocol. I don't think it has anything to do with bandwidth. In this example you also mention CDNs. Are you suggesting that the developer should not consider "Middleboxes" protocols? I think you need to work on the example of section 3.3.1 some more to make it clearer. 
> 

Excellent point - we'll address this in a future version. 

> This section worries me. As a  scholar I have worked on cyber attribution to some extent and believe in general when we have the right processes in place, attribution is very important and can hold cyber-attackers accountable. I am aware of some of the attribution processes and unfortunately some threat intelligence firms and open source intelligence organizations can violate the privacy of individuals by profiling them. Also, uncontrolled attribution mechanisms can lead to frivolous intellectual property claims. Both some threat intelligence firms and IP firms have used WHOIS extensively in their favor to attribute cybersecurity attacks and bring forward IP claims. WHOIS protocol did not have the intention to actually identify organizations and individuals, but to make them "contactable".and it was still used and mined for so many years and those who have abused WHOIS have not been held accountable.When you suggest they consider "attribution" when developing protocols it
> concerns me because it is not enough that you limit attribution to organizations and states. These kinds of attributions can be used against individuals and until we do not have the right preserving processes to put in place for those who want to be in the attribution business, rights of the individual can be at risk. there are very privacy conscious cybersecurity researchers out there but unfortunately that does not ensure a systematic practice of attribution in a fair manner. And you mention attribution to associations is fine and may not directly negatively impact human rights. Associations can themselves be at risk of frivolous attacks and frivolous attribution. I am concerned about this paragraph. I think we should have a conversation about it.
> 

In the proposed text I tried to capture the consensus that emerged from the extensive discussion that was had on this list. Do you have concrete suggestions on how to better capture that conensensus? I am afraid we would go back and repeat the same discussion. 

> 4. Nice to see that you mention DoH. It's a great privacy preserving protocol. 
> 
> 

Thanks!

Niels

> 
> 
> 
> 
> 
> 
> 
> 
> Farzaneh
> 
> 
> On Sat, Jan 30, 2021 at 10:35 AM Corinne Cath <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi all,
> 
>     I trust this email finds you well. I did a review of the draft, from my perspective as an academic. Take it as you please. My main concern is that some of the language reads a bit deterministic (as, I know so does RFC 8280). It means that a lot of onus is put on the impact of a protocol, as opposed the role of the individuals that write them. 
> 
>     I think through out the document, it would be interesting (especially in section 1 through 3.2.5) to see if you can rewrite such that you speak more directly to the protocol developers. I think that section 3.3 does that well, in terms of the tone it takes. As it clearly connects the actions of protocol developers to their potential outcomes. 
> 
>     Hope this is helpful! 
> 
>     Kind regards, 
> 
>     Corinne
> 
>     Web: www.oii.ox.ac.uk/people/corinne-cath <http://www.oii.ox.ac.uk/people/corinne-cath>
>     Email: [email-masked] <mailto:[email-masked]> & [email-masked] <mailto:[email-masked]>
>     Twitter: @C_CS
>     [email-masked] <mailto:[email-masked]>
>     https://www.irtf.org/mailman/listinfo/hrpc <https://www.irtf.org/mailman/listinfo/hrpc>
> 
> 

-- 
Niels ten Oever, PhD
Postdoctoral Researcher - Media Studies Department - University of Amsterdam
Postdoctoral Research Fellow - Communications Department - Texas A&M University
Research Fellow - Centre for Internet and Human Rights - European University Viadrina
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas

W: https://nielstenoever.net
E: [email-masked]
T: @nielstenoever
P/S/WA: +31629051853
PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3

Read my dissertation 'Wired Norms' here: https://pure.uva.nl/ws/files/50781961/Thesis.pdf

---

From: Eliot Lear <[email-masked]>
Date: Sun, 31 Jan 2021 12:21:44 +0100

Hi Farzaneh

> On 30 Jan 2021, at 23:00, farzaneh badii <[email-masked]> wrote:
> 
> Hello
> 

I would suggest that there needs to be a more relevant example of both, perhaps with some specificity.  IMHO mostly for the IETF this has to do with several classes of issues:
How we handle errors.  If there are human readable errors, then we end up with two kinds of issues- language and character set.  Error codes work well to address some of these problems, but we can’t create codes for everything that might go wrong.
This is also an area where evolution of the RFC series and Internet drafts probably needs to take note of, and has in the past.  We have, for instance, a love of ASCII art.  To my knowledge we have had one blind person in our organization who is astonishingly brilliant and was able to parse these things.  Would alt-text be better, and how is that represented in PDF-A?
Finally we might define a format that needs to be represented to the user, and in that case, we have to handle language and character set  considerations.
FWIW, I think it would be better to bind this to real HR examples.  How does language and accessibility concerns, for instance, impact HR?  A reference would be useful for lay people.

> 2.section 3.3.1 on connectivity, you mention that "considering the fact that network quality and conditions vary across geography and time it is also important to design protocols such that they ar…

Indeed the whole section is off.  For one thing, the citation of [Saltzer] should be dropped, because the quote is from RFC 1958, and he, Reed, and Clark were making a slightly more nuanced point about where to put functionality.  Consider the [Saltzer]’s section entitled “Performance” for counter examples.  Also, this isn’t really a connectivity issue.  However, one could argue quite reasonably that requiring middle boxes in design can lead to market concentration, which can in itself limit connectivity and create unwanted control points that could be subject to HR abuse, but please do so with some better analysis than me pulling that out of my hat ;-)

This reminds me: the authors and chairs are encouraged to review citations.

Second, you are correct the the NAT/middlebox discussion is somewhat in the wrong place.  It’s not that the risks described aren’t there, but that they are not primarily a connectivity issue.

Eliot

---

From: farzaneh badii <[email-masked]>
Date: Sun, 31 Jan 2021 13:16:30 -0500

Hello Niels.

I don't know how we measure consensus here. But I remember weighing in back
then as well(When Mr. Curran weighed in back in 2019). Here is the thread:
https://mailarchive.ietf.org/arch/browse/hrpc/?q=attribution

I can see that unfortunately I missed the discussion on this topic during
the past year, and that's my fault, but I can bring reasons not to add
"attribution and legal remedy" to this document at all.

1. Access to legal remedy is something that the States are supposedly in
charge of bringing to their citizens.Which should (in theory) ensure that
human rights are enforced. I don't think there was an intention to
provide  mechanisms for "enforcement" of human rights in various legal
systems through Internet protocols. As mentioned in the beginning of your
document:
"Human rights threats on the Internet come in a myriad of forms. *P**rotocols
and standards can harm or enable* the right to freedom of expression, right
to non-discrimination, right to equal protection, right to participate in
cultural life, arts and science, right to freedom of assembly and
association, and the right to security."

So we are not in the business of enforcing but providing an enabling
environment. Because if we want to help law enforcement and the judicial
authorities enforce human rights through Internet protocols we should bear
in mind that that they are not always staunch advocates of human rights. So
what I assume we are trying to do here is to help Internet protocol not to
facilitate harm and "enable" human rights.

2. Attribution, section 3.3.20  of the Guideline, the authors assert
that: "However,
attribution to corporate entities, associations, and/or countries may not
directly negatively impact human rights." I think this is not a very well
backed up claim. Because in some cases some associations might be political
or they might be human rights associations dealing with a dictatorship.
Attribution to those associations certainly can impact their human rights
negatively. Even when it comes to corporations, some CEOs of digital
companies are put in jail because of the materials posted on their
websites. I don't think we can argue that attribution to corporate entities
might not adversely impact human rights.

All in all I think section 3.3.20 does not help Internet Protocols enable
human rights and it can be misinterpreted.

And in my previous email I talked about the problems with threat
intelligence agencies and some of their conducts and the use of WHOIS for
attribution (which was actually not designed to "identify" actors but
unfortunately was used for that) so I will not reiterate here.

On Sun, Jan 31, 2021 at 5:52 AM Niels ten Oever <[email-masked]>
wrote:

> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05 <
> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05>
> >
> > 1. One major issue that I see here and you might be able to easily solve
> it is that there is no distinction between user facing protocols and other
> We had a quite extensive discussion about this in relation to the
> presentation by Ramsey Nasr who create Qalb, an Arabic programming
> language. Programmers are the most frequent 'users' of protocols - if we
> continue using only latin characters and English documentation in protocols
> we are likely to reproduce the existing lack of diversity in protocol
> developers communities. But we can make the text on this clearer as well!
>
> > This section worries me. As a  scholar I have worked on cyber
> attribution to some extent and believe in general when we have the right
> processes in place, attribution is very important and can hold
> cyber-attackers accountable. I am aware of some of the attribution
> processes and unfortunately some threat intelligence firms and open source
> intelligence organizations can violate the privacy of individuals by
> profiling them. Also, uncontrolled attribution mechanisms can lead to
> In the proposed text I tried to capture the consensus that emerged from
> the extensive discussion that was had on this list. Do you have concrete
> suggestions on how to better capture that conensensus? I am afraid we would
> go back and repeat the same discussion.
>
> >     I trust this email finds you well. I did a review of the draft, from
> my perspective as an academic. Take it as you please. My main concern is
> that some of the language reads a bit deterministic (as, I know so does RFC
> >     I think through out the document, it would be interesting
> (especially in section 1 through 3.2.5) to see if you can rewrite such that
> you speak more directly to the protocol developers. I think that section
> 3.3 does that well, in terms of the tone it takes. As it clearly connects
> the actions of protocol developers to their potential outcomes.
> >
> >     Hope this is helpful!
> >
> >     Kind regards,
> >
> >     Corinne
> >
> >     >> maybe if they want to understand potential human rights concerns?
> Impact seems a little deterministic, as you also mention in the next
> sentence, I wonder if you can prove such direct impact between protocol
> development in the IETF and impact on human rights.
> >
> >           3.1 <
> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.1>.
> Human rights threats
> >
> >
> >
> >     >> again, deterministic language. Perhaps soften or add more
> concrete examples for context, that draw from current IETF
> discussions/standards.
> >
> >
> >
> >           3.3 <
> https://tools.ietf.org/html/draft-irtf-hrpc-guidelines-05#section-3.3>.
> >     Web: www.oii.ox.ac.uk/people/corinne-cath <
> http://www.oii.ox.ac.uk/people/corinne-cath>
> >     Email: [email-masked] <mailto:[email-masked]> &
> [email-masked] <mailto:[email-masked]>
> >     Twitter: @C_CS
> >     https://www.irtf.org/mailman/listinfo/hrpc <
> https://www.irtf.org/mailman/listinfo/hrpc>
> >
> >
> Read my dissertation 'Wired Norms' here:
> https://pure.uva.nl/ws/files/50781961/Thesis.pdf