Subject: [hrpc] adding comments on draft-guidelines

From: Joey S <[email-masked]>
Date: Fri, 19 Feb 2021 16:23:00 -0600

Hi all, GG, Niels,

Thank you for all the work and effort put into this I-D.

After going over it, I'm wondering about the scope and tone of some
sections;

"Abstract: It provides questions engineers should ask
themselves when developing or improving protocols if they want
to understand their potential human rights impact."

Are these guidelines aimed at IETF participants only? Or also for
the organisations and companies using and expanding the protocols
stardardised at the IETF? If the latter is part of the aim/scope,
then the abstract could use some rephrasing since the developers are
not the decision-makers in most scenarios that involve the planning,
design, implementation, and deployment of a protocol or extension.
Implementers might be a better term here since it encompasses both
the decision-makers and the devs actively coding.

Section 3.1: "several 'common' threats to human rights"

The meaning here doesn't seem clear to me. Do we mean, as phrased
later in the document, "protocols and their (potential) impact" to
human rights, or "human rights risks arising from potential
misapplications of the protocol or technology"? Perhaps something
along the lines of creating a "basis for discussion on whether the
protocol adequately takes specific human rights threats into
account" could also be included here for clarity.

Section 3.3 (and sub-sections 1-21):

I agree with CCS and also think it's nicely written regarding tone
and scope, but it seems to be in a bit of a contrast with other
sections of the I-D, specifically with 3.1 where the language and
tone seem to be harsher/more narrow, as well as in its sub-sections
1-21;

In hopes of more harmonious dialog (and less of the "hr-advocates vs
developers" mentality and arguments some might have encountered), I
think language here that is more collaborative might yield better
results in practice and aid in opening dialog between different
parties in other WGs/RGs when they use this draft as a reference or
for reviews. Framing, for example, "Does your protocol maintain the
confidentiality of metadata?" as "How can we ensure this protocol
maintains the confidentiality of metadata?" instead, or "Does your
protocol in any way allow for the data to be (intentionally or
unintentionally) altered?" as "can the data handled by this protocol
be (intentionally or unintentionally) altered? How can we prevent
that?", could signal a shift where 'hr-advocates' are not seen as
"regulators" (or trying to be regulators) but as the volunteers and
contributors that also want to work together towards a better
outcome. Sub-section 3.3.19. in paragraph 2 of the 'Explanation:' is
a strong example, in my opinion, of a tone that might not be
perceived as helpful or effective when we, as devs or advocates or
participants working in public interest technologies, aim to have
discussions with the devs/teams working on a protocol.

Sub-section 3.3.1:

This sub-section talks about "reliable even on low bandwidth and
high latency connections". Here I wonder if we could give an example
or talk about the impact that reliable connections have in the
effective access to connectivity in remote/developing areas.

Sub-sections 3.3.14 and 3.3.19:

Lastly, and similar to issue #29 in github requesting explicit
mention of 'Access to Information', although I see Anonymity and
'clear text / data encryption' mentioned in these sub-sections, I
wonder (without implying some rights/technologies are more or less
important than others) if they could be more explicitly mentioned
across the draft or given a bit more visibility somewhere (their
mention in sub-section 3.3.19. seems to me somewhat hidden since
it's towards the end of the ID).

Looking forward to your thoughts,

--
Joey Salazar
Digital Sr. Programme Officer
ARTICLE 19
6E9C 95E5 5BED 9413 5D08 55D5 0A40 4136 0DF0 1A91

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 19 Feb 2021 17:58:39 -0500

Hi,

(ObDisclaimer: I work for ISOC but this is just my opinion and not theirs)

On Fri, Feb 19, 2021 at 04:23:00PM -0600, Joey S wrote:
>  • "Abstract: It provides questions engineers should ask themselves when
>    developing or improving protocols if they want to understand their
>    potential human rights impact."
>
>Are these guidelines aimed at IETF participants only? Or also for the
>organisations and companies using and expanding the protocols stardardised at
>the IETF?

I think this goes to the scope question that I believe Stephane
Bortzmeyer asked at one point: is this about protocols,
specifications, or implementations (or maybe, even, the tools used to
make implementations)?  Assuming it's about protocols themselves, then
expanding it to organizations and companies wouldn't be correct, since
the protocols (at least in the IETF -- it's a different story
elsewhere) are developed by individuals who, as a matter of IETF
policy, do not participate as organizational representatives.  The
contributions to the IETF protocol development (which might turn up in
a specification in an RFC) are supposed to be individual ones.

If instead we're talking about implementation or deployment then it's
a different story (but also I'm not sure the document is aimed the
right way in that case).

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Gurshabad Grover <[email-masked]>
Date: Tue, 23 Feb 2021 00:06:43 +0530

Hiya,

Thanks for the review, Joey! I've incorporated all the issues your
raised on Github. And some comments also below.

On 2/20/21 3:53 AM, Joey S wrote:
>   * "Abstract: It provides questions engineers should ask themselves
>     when developing or improving protocols if they want to understand
>     their potential human rights impact."
> 
> organisations and companies using and expanding the protocols
> stardardised at the IETF? If the latter is part of the aim/scope, then
> the abstract could use some rephrasing since the developers are not the
> decision-makers in most scenarios that involve the planning, design,
> implementation, and deployment of a protocol or extension. Implementers
> might be a better term here since it encompasses both the
> decision-makers and the devs actively coding.
> 

I presume that these guidelines may be useful for companies and
implementers, but I do not think they are an intended primary audience
for this draft (and intentionally so). This document is primarily aimed
at those designing protocols and developing specifications.

A sentence in the introduction captures that "the [final] impact of a
protocol cannot solely be deduced from its design, but its usage and
implementation should also be studied to form a full protocol human
rights impact assessment." I personally think that this caveat is
implying the clarification on the scope, but happy to make this even
more explicit in the next versions if it is not clear already.

>   * Section 3.1: "several 'common' threats to human rights"
> 
> The meaning here doesn't seem clear to me. Do we mean, as phrased later
> in the document, "protocols and their (potential) impact" to human
> rights, or "human rights risks arising from potential misapplications of
> the protocol or technology"? Perhaps something along the lines of
> creating a "basis for discussion on whether the protocol adequately
> takes specific human rights threats into account" could also be included
> here for clarity.
> 

Thanks, this sentence has now been changed (as Bill suggested in their
review).

>   * Section 3.3 (and sub-sections 1-21):
> 
> I agree with CCS and also think it's nicely written regarding tone and
> scope, but it seems to be in a bit of a contrast with other sections of
> the I-D, specifically with 3.1 where the language and tone seem to be
> harsher/more narrow, as well as in its sub-sections 1-21;
> results in practice and aid in opening dialog between different parties
> in other WGs/RGs when they use this draft as a reference or for reviews.
> Framing, for example, "Does your protocol maintain the confidentiality
> of metadata?" as "How can we ensure this protocol maintains the
> confidentiality of metadata?" instead, or "Does your protocol in any way
> allow for the data to be (intentionally or unintentionally) altered?" as
> "can the data handled by this protocol be (intentionally or
> unintentionally) altered? How can we prevent that?", could signal a
> shift where 'hr-advocates' are not seen as "regulators" (or trying to be
> regulators) but as the volunteers and contributors that also want to
> work together towards a better outcome. Sub-section 3.3.19. in paragraph
> 2 of the 'Explanation:' is a strong example, in my opinion, of a tone
> that might not be perceived as helpful or effective when we, as devs or
> advocates or participants working in public interest technologies, aim
> to have discussions with the devs/teams working on a protocol.
> 

Thanks, Joey. Could not address this feedback in the current update, but
have noted it in the to-do list that I have shared on the list.

>   * Sub-section 3.3.1:
> 
> This sub-section talks about "reliable even on low bandwidth and high
> latency connections". Here I wonder if we could give an example or talk
> about the impact that reliable connections have in the effective access
> to connectivity in remote/developing areas.
> 

Added: Encrypting connections, like done with HTTPS, can add a
significant network overhead and consequently make web resources less
accessible to those with low bandwidth and/or high latency connections.
[ref] Encrypting traffic is a net positive for privacy and
security, and thus protocol designers can acknowledge the tradeoffs of
connectivity made by such decisions.

>   * Sub-sections 3.3.14 and 3.3.19:
> 
> Lastly, and similar to issue #29 in github requesting explicit mention
> of 'Access to Information', although I see Anonymity and 'clear text /
> data encryption' mentioned in these sub-sections, I wonder (without
> implying some rights/technologies are more or less important than
> others) if they could be more explicitly mentioned across the draft or
> given a bit more visibility somewhere (their mention in sub-section
> 3.3.19. seems to me somewhat hidden since it's towards the end of the ID).
> 

Yes. Incorporated the edit you suggested on Github. We note in the
introduction that the draft "is by no means an attempt to exclude
specific rights"; and happy to incorporate any edits where you think we
may need to visibilise certain rights more.

Thank you.
-Gurshabad