Subject: [hrpc] draft human rights considerations

From: Niels ten Oever <[email-masked]>
Date: Tue, 9 Feb 2016 16:58:05 +0100

Dear all,

I hope this email finds you well. Corinne and I added a substantial
amount of text to the methodology draft, which we just made available
for you here:

https://www.ietf.org/id/draft-varon-hrpc-methodology-04.txt

Most additions are a first stab at actual human rights considerations,
modeled after RFC6973. I pasted this specific part also underneath for
your convenience and consideration. There are also some small
additions to the middlebox text as well as other nits than can be
found directly in the draft (and in the diff
https://tools.ietf.org/rfcdiff?url2=draft-varon-hrpc-methodology-04.txt
).

Looking forward to the discussion, as well as questions and comments.

Best,

Niels

### Human Rights Threats
The human rights threats on the Internet come in a myriad of forms.
Protocols and standards can harm or enable the right to freedom of
expression, right to non-discrimination, right to equal protection,
right to be presumed innocence, right to participate in cultural life,
arts and science, right to freedom of assembly and association, and
the right to security. An end-user who is denied access to certain
services, data or websites may be unable to disclose vital information
about the malpractices of a government or other authority.  A person
whose communications are monitored may be prevented from exercising
their right to freedom of association. In a worst-case scenario,
protocols that leak information can lead to physical danger. A
realistic example to consider is when opposition leaders in
totalitarian regimes are subjected to torture on the basis of
information gathered by the regime through information leakage in
protocols.

This sections details several ‘common’ threats to human rights,
indicating how each of these can lead to human rights violations/harms
and present several examples of how these threats to human rights
materialize on the Internet. This threat modeling is inspired by
{{RFC6973}} Privacy Considerations for Internet Protocols, which bases
itself on security threat analysis. This method is by no means a
perfect solution for assessing human rights risks in Internet
protocols and systems; it is however the best approach currently
available. Certain human rights threats are indirectly considered in
Internet protocols as part of the standard privacy and security
considerations. Others suggested are tailored specifically to human
rights, and represents considerations not currently considered in
other RFCs.

Many threats, enablers and risks are linked to different rights. This
is not unsurprising if one takes into account that human rights are
interrelated, interdependent and universal.
Here however we're not discussing all human rights because not all
human rights are relevant to ICTs in general and protocols and
standards in particular. This is by no means an attempt to cherry
picks right, if other rights seem relevant, please contact the authors
and/or the hrpc mailinglist.

### Human Rights Guidelines

This section provides guidance for document authors in the form of a
questionnaire about a protocol being designed. The questionnaire may
be useful at any point in the design process, particularly after
document authors have developed a high-level protocol model as
described in {{RFC4101}}.

Note that the guidance provided in this section does not recommend
specific practices.  The range of protocols developed in the IETF is
too broad to make recommendations about particular uses of data or how
human rights might be balanced against other design goals.  However,
by carefully considering the answers to each question, document
authors should be able to produce a comprehensive analysis that can
serve as the basis for discussion of whether the protocol adequately
protects against human rights threats.  This guidance is meant to help
the thought process of a human rights analysis; it does not provide
specific directions for how to write a human rights protocol
considerations section (following the example set in {{RFC6973}}).

#### Right to freedom of expression

##### Connectivity
Does your protocol honor the end-to-end principle?

##### Privacy
Did you have a look at the Guidelines in the Privacy Considerations
for Internet Protocols {{RFC6973}} section 7? Does your protocol in
any way impact the confidentiality of protocol metadata? Does your
protocol countering traffic analysis, or data minimisation?

##### Security
Did you have a look at Guidelines for Writing RFC Text on Security
Considerations {{RFC3552}}?

##### Content agnosticism
If your protocol impact packet handling, does it look at the packet
content? Is it making decisions based on the content of the packet? Is
the protocol transparent about its decision? Does your protocol
prioritize certain content or services over others?

##### Internationalization
Does your protocol have text string that are readable or entered by
humans? Does your protocol allow Unicode encoded in UTF-8 only,
thereby shifting conversion issues away from individual choices? Did
you have a look at {{RFC6365}}?

##### Censorship resistance
Does your protocol make censorship easier by exposing specific
identifiers that could be sensitive for filtering. When filtering is
happening, does your protocol help make it apparent or transparent?

##### Open Standards
Is your protocol fully documented in a way that it could be easily
implemented, improved, build upon and/or further developed. Is there
any proprietary code needed for the implementation, running or further
development of your protocol?

##### Heterogeneity Support
Does your protocol support heterogeneity by design? Does your protocol
allow for multiple types of hardware? Does your protocol allow for
multiple types of application protocols?

#### Right to non-discrimination

##### Anonymity
Did you have a look at the Privacy Considerations for Internet
Protocols {{RFC6973}}, especially section 6.1.1 ?

##### Privacy
See above

##### Pseudonymity
Did you have a look at the Privacy Considerations for Internet
Protocols {{RFC6973}}, especially section 6.1.2 ?

##### Content agnosticism
See above

##### Accessibility
Is your protocol optimized for low bandwidth and high latency
connections? Could your protocol also be developed in a stateless manner
?

#### Right to equal protection

##### Content agnosticism
See above

#### Right to be presumed innocent
Is is possible to deploy your protocol without a single point of
control? If applicable, can it also implemented in a federated way?

##### Anonymity
See above

##### Privacy
See above

##### Security
See above

#### Right to political participation

##### Accessibility
when websites, web technologies, or web tools are badly designed, they
can create barriers that exclude people from using the Web. Is your
protocol designed to provide an enabling environment for people with
disabilities? It might be relevant to look at the W3C Web
Accessibility Initiative for examples and guidance.

##### Internationalization
See above

##### Censorship resistance
See above

#### Right to participate in cultural life, arts and science

##### Open Standards
See above

##### Localization
Does your protocol live up to standards of internationalization (see
above)? Have you considered localizing your protocol for relevant
audiences?

##### Internationalization
See above

##### Censorship resistance
See above

#### Right to freedom of assembly and association

##### Connectivity
See above

##### Decentralization
Does your protocol contribute to more centralized points of control?
Can your protocol be implemented without one single point of control.
If applicable, can your protocol be deployed in a federated manner?

##### Censorship resistance
See above

##### Pseudonymity
See above

##### Anonymity
See above

#### Security
See above

#### Right to security

##### Reliability
Is your protocol fault tolerant? Does it degrade gracefully? Do you
have a documented way to announce degradation? Do you have measures in
place for recovery or partial healing from failure? Is your protocol
able to maintain dependability and performance in the face of
unanticipated changes or circumstances?

##### Confidentiality
(cf {{RFC6973}} ) Which information related to identifiers or data  is
exposed to each other protocol entity (i.e., recipients,
intermediaries, and enablers)?  Are there ways for protocol
implementers to choose to limit the information shared with each
entity?  Are there operational controls available to limit the
information shared with each entity?

What controls or consent mechanisms does the protocol define or
require before personal data or identifiers are shared or exposed via
the protocol?  If no such mechanisms or controls are specified, is it
expected that control and consent will be handled outside of the protoco
l?

Does the protocol provide ways for initiators to share different
information with different recipients?  If not, are there mechanisms
that exist outside of the protocol to provide initiators with such
control?

Does the protocol provide ways for initiators to limit which
information is shared with intermediaries?  If not, are there
mechanisms that exist outside of the protocol to provide users with
such control?  Is it expected that users will have relationships that
govern the  use of the information (contractual or otherwise) with
those who operate these intermediaries?

Does the protocol provide ways for initiators to express individuals'
preferences to recipients or intermediaries with regard to the
collection, use, or disclosure of their personal data?

##### Integrity
Does your protocol maintain and assure the accuracy of data? Does your
protocol maintain and assure the consistency of data? Does your
protocol in any way allow for the data to be (intentionally or
unintentionally) altered?

##### Authenticity
Do you have enough measures to confirm the truth of an attribute of a
single piece of data or entity? Can the attributes get garbled along
the way (see security)? If relevant have you implemented IPsec and
other Standard Security Best Practices?

##### Anonymity
See above

#### Right to education

##### Acceptability
Do your protocols adhere to the principle of non-discrimination (see
above)? Do your protocols adhere to the principle of content
agnosticism (see above)?

##### Availability
Do your protocols use or depend on proprietary code? Also see 'Open
Standards' above. Also see 'Connectivity' above.

##### Accessibility
See above

##### Adaptability
Could your protocol stifle or hinder permissionless innovation in any
way? See 'Connectivity' above

- -- 
Niels ten Oever
Head of Digital

Article 19
www.article19.org

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

---

From: Will Scott <[email-masked]>
Date: Wed, 10 Feb 2016 14:30:22 -0800

I'd argue for a different angle in the "right to be presumed innocent"
section within the "right to equal protection" section.

The text there seems to be focused on decentralization, which helps prevent
centralized control, but is different from presumed innocence.  The failure
case I'd want that section to talk to is the a hypothetical standard for
DPI policy, where you wouldn't want to block all bittorrent traffic for
copyright infringement. Instead, you'd want to have systems and standards
structured so that protocols and carried data isn't discriminated based on
stereotypes, but on the specific content of the transmissions.

Here's a proposal for an alternate framing:
What is the potential for discrimination against users of your protocol?
How can use of your protocol be used to implicate participants?

--Will

On Tue, Feb 9, 2016 at 7:58 AM, Niels ten Oever <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Dear all,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJWugyNAAoJEAi1oPJjbWjpIwQIAIUDFA9yn4Fe7UCZ+qjsjnW5
> cRJnsvYnC4GGIehM2/OKFmsgajakTuSVsqH068Nwz1OCE2hHg4PsUFXlxNny+NyH
> vF+j4gVrq9CMphVIvJXz4tgGQu623ED0iCA2fH7CXyPMtiVH9HcUkYt5Mija0ZjW
> ocYjG4VkEFLGaV7/zG7NZAQGKlm9eJeX1WwIZrdUkN+63XzFcValL5pkiChKlLbp
> /TlSarjrajonXf4+HWQxz17i/s1htuAb7pib1KRuikYchYe8kOxlDKFzznw1jzPH
> Ga2lzY0/rKGq/14OaOr70GGQDQI+UUYAcv17rrWLWxXy1tsZCy31lHlArSxvSEY=
> =zGci
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 15 Feb 2016 11:50:02 +0100

Hi Will,

Thanks for this. Reply inline:

On 02/10/2016 11:30 PM, Will Scott wrote:
> I'd argue for a different angle in the "right to be presumed
> innocent" section within the "right to equal protection" section.
> 

They are both seperate human rights, so they both have their own
section (4.7.2.3 and 4.7.2.4)

> The text there seems to be focused on decentralization, which
> helps prevent centralized control,

The draft may be unclear here, but decentralization (4.7.2.7.2) is
part of the right to freedom of assembly and association (4.7.2.7),
not of any other right at the moment.

> but is different from presumed innocence. The failure case I'd want
> that section to talk to is the a hypothetical standard for DPI
> policy, where you wouldn't want to block all bittorrent traffic for
> copyright infringement. Instead, you'd want to have systems and
> standards structured so that protocols and carried data isn't 
> discriminated based on stereotypes, but on the specific content of
> the transmissions.

So, would you argue decentralization should be part of Right to
freedom of expression (4.7.2.1) and Right to non-discrimination
(4.7.2.2) as well?

> 
> Here's a proposal for an alternate framing: What is the potential
> for discrimination against users of your protocol? How can use of
> your protocol be used to implicate participants?
> 

Would this be fixed by the proposal suggested above, or do you think
we should add other considerations to the Right to non-discrimination
(4.7.2.2) ?

Looking forward to discuss!

Best,

Niels

> --Will
> 
> 
> On Tue, Feb 9, 2016 at 7:58 AM, Niels ten Oever
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Dear all,
> 
> I hope this email finds you well. Corinne and I added a
> substantial amount of text to the methodology draft, which we just
> made available for you here:
> 
> Most additions are a first stab at actual human rights
> considerations, modeled after RFC6973. I pasted this specific part
> also underneath for your convenience and consideration. There are
> also some small additions to the middlebox text as well as other
> nits than can be found directly in the draft (and in the diff 
).
> ### Human Rights Threats The human rights threats on the Internet
> come in a myriad of forms. Protocols and standards can harm or
> enable the right to freedom of expression, right to
> non-discrimination, right to equal protection, right to be presumed
> innocence, right to participate in cultural life, arts and science,
> right to freedom of assembly and association, and the right to
> security. An end-user who is denied access to certain services,
> data or websites may be unable to disclose vital information about
> the malpractices of a government or other authority.  A person 
> whose communications are monitored may be prevented from
> exercising their right to freedom of association. In a worst-case
> scenario, protocols that leak information can lead to physical
> danger. A realistic example to consider is when opposition leaders
> in totalitarian regimes are subjected to torture on the basis of 
> indicating how each of these can lead to human rights
> violations/harms and present several examples of how these threats
> to human rights materialize on the Internet. This threat modeling
> is inspired by {{RFC6973}} Privacy Considerations for Internet
> Protocols, which bases itself on security threat analysis. This
> method is by no means a perfect solution for assessing human rights
> risks in Internet protocols and systems; it is however the best
> approach currently available. Certain human rights threats are
> indirectly considered in Internet protocols as part of the standard
> privacy and security considerations. Others suggested are tailored
> specifically to human rights, and represents considerations not
> currently considered in other RFCs.
> 
> Many threats, enablers and risks are linked to different rights.
> This is not unsurprising if one takes into account that human
> rights are interrelated, interdependent and universal. Here however
> we're not discussing all human rights because not all human rights
> are relevant to ICTs in general and protocols and standards in
> particular. This is by no means an attempt to cherry picks right,
> if other rights seem relevant, please contact the authors and/or
> the hrpc mailinglist.
> 
> This section provides guidance for document authors in the form of
> a questionnaire about a protocol being designed. The questionnaire
> may be useful at any point in the design process, particularly
> after document authors have developed a high-level protocol model
> as described in {{RFC4101}}.
> 
> specific practices.  The range of protocols developed in the IETF
> is too broad to make recommendations about particular uses of data
> or how human rights might be balanced against other design goals.
> However, by carefully considering the answers to each question,
> document authors should be able to produce a comprehensive analysis
> that can serve as the basis for discussion of whether the protocol
> adequately protects against human rights threats.  This guidance is
> meant to help the thought process of a human rights analysis; it
> does not provide specific directions for how to write a human
> rights protocol considerations section (following the example set
> in {{RFC6973}}).
> 
> ##### Connectivity Does your protocol honor the end-to-end
> principle?
> 
> ##### Privacy Did you have a look at the Guidelines in the Privacy
> Considerations for Internet Protocols {{RFC6973}} section 7? Does
> your protocol in any way impact the confidentiality of protocol
> metadata? Does your protocol countering traffic analysis, or data
> minimisation?
> 
> ##### Security Did you have a look at Guidelines for Writing RFC
> Text on Security Considerations {{RFC3552}}?
> 
> ##### Content agnosticism If your protocol impact packet handling,
> does it look at the packet content? Is it making decisions based on
> the content of the packet? Is the protocol transparent about its
> decision? Does your protocol prioritize certain content or services
> over others?
> 
> ##### Internationalization Does your protocol have text string that
> are readable or entered by humans? Does your protocol allow Unicode
> encoded in UTF-8 only, thereby shifting conversion issues away from
> individual choices? Did you have a look at {{RFC6365}}?
> 
> ##### Censorship resistance Does your protocol make censorship
> easier by exposing specific identifiers that could be sensitive for
> filtering. When filtering is happening, does your protocol help
> make it apparent or transparent?
> 
> ##### Open Standards Is your protocol fully documented in a way
> that it could be easily implemented, improved, build upon and/or
> further developed. Is there any proprietary code needed for the
> implementation, running or further development of your protocol?
> 
> ##### Heterogeneity Support Does your protocol support
> heterogeneity by design? Does your protocol allow for multiple
> types of hardware? Does your protocol allow for multiple types of
> application protocols?
> 
> ##### Anonymity Did you have a look at the Privacy Considerations
> for Internet Protocols {{RFC6973}}, especially section 6.1.1 ?
> 
> ##### Privacy See above
> 
> ##### Pseudonymity Did you have a look at the Privacy
> Considerations for Internet Protocols {{RFC6973}}, especially
> section 6.1.2 ?
> 
> ##### Content agnosticism See above
> 
> ##### Accessibility Is your protocol optimized for low bandwidth
> and high latency connections? Could your protocol also be developed
> in a stateless manner ?
> 
> ##### Content agnosticism See above
> 
> #### Right to be presumed innocent Is is possible to deploy your
> protocol without a single point of control? If applicable, can it
> also implemented in a federated way?
> 
> ##### Anonymity See above
> 
> ##### Privacy See above
> 
> ##### Security See above
> 
> ##### Accessibility when websites, web technologies, or web tools
> are badly designed, they can create barriers that exclude people
> from using the Web. Is your protocol designed to provide an
> enabling environment for people with disabilities? It might be
> relevant to look at the W3C Web Accessibility Initiative for
> examples and guidance.
> 
> ##### Internationalization See above
> 
> ##### Censorship resistance See above
> 
> ##### Open Standards See above
> 
> ##### Localization Does your protocol live up to standards of
> internationalization (see above)? Have you considered localizing
> your protocol for relevant audiences?
> 
> ##### Internationalization See above
> 
> ##### Censorship resistance See above
> 
> ##### Connectivity See above
> 
> ##### Decentralization Does your protocol contribute to more
> centralized points of control? Can your protocol be implemented
> without one single point of control. If applicable, can your
> protocol be deployed in a federated manner?
> 
> ##### Censorship resistance See above
> 
> ##### Pseudonymity See above
> 
> ##### Anonymity See above
> 
> #### Security See above
> 
> 
> #### Right to security
> 
> ##### Reliability Is your protocol fault tolerant? Does it degrade
> gracefully? Do you have a documented way to announce degradation?
> Do you have measures in place for recovery or partial healing from
> failure? Is your protocol able to maintain dependability and
> performance in the face of unanticipated changes or circumstances?
> 
> ##### Confidentiality (cf {{RFC6973}} ) Which information related
> to identifiers or data  is exposed to each other protocol entity
> (i.e., recipients, intermediaries, and enablers)?  Are there ways
> for protocol implementers to choose to limit the information shared
> with each entity?  Are there operational controls available to
> limit the information shared with each entity?
> 
> require before personal data or identifiers are shared or exposed
> via the protocol?  If no such mechanisms or controls are specified,
> is it expected that control and consent will be handled outside of
> the protoco l?
> 
> information with different recipients?  If not, are there
> mechanisms that exist outside of the protocol to provide initiators
> with such control?
> 
> mechanisms that exist outside of the protocol to provide users
> with such control?  Is it expected that users will have
> relationships that govern the  use of the information (contractual
> or otherwise) with those who operate these intermediaries?
> 
> Does the protocol provide ways for initiators to express
> individuals' preferences to recipients or intermediaries with
> regard to the collection, use, or disclosure of their personal
> data?
> 
> ##### Integrity Does your protocol maintain and assure the accuracy
> of data? Does your protocol maintain and assure the consistency of
> data? Does your protocol in any way allow for the data to be
> (intentionally or unintentionally) altered?
> 
> ##### Authenticity Do you have enough measures to confirm the truth
> of an attribute of a single piece of data or entity? Can the
> attributes get garbled along the way (see security)? If relevant
> have you implemented IPsec and other Standard Security Best
> Practices?
> 
> ##### Anonymity See above
> 
> #### Right to education
> 
> ##### Acceptability Do your protocols adhere to the principle of
> non-discrimination (see above)? Do your protocols adhere to the
> principle of content agnosticism (see above)?
> 
> ##### Availability Do your protocols use or depend on proprietary
> code? Also see 'Open Standards' above. Also see 'Connectivity'
> above.
> 
> ##### Accessibility See above
> 
> ##### Adaptability Could your protocol stifle or hinder
> permissionless innovation in any way? See 'Connectivity' above
> 
> 
> 
> 
> _______________________________________________ hrpc mailing list 
> [email-masked] <mailto:[email-masked]> 
> _______________________________________________ hrpc mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Will Scott <[email-masked]>
Date: Tue, 16 Feb 2016 10:53:10 -0800

Inline Replies

On Mon, Feb 15, 2016 at 2:50 AM, Niels ten Oever <[email-masked]>
wrote:

> I misread, my bad.

> This seems like the correct place for it, but the sample question "Is it
possible to deploy your protocol without a single point of control?" feels
like a decentralization issue.

> Adding it to 4.7.2.2 seems appropriate.

My point above was trying to say that right to presumed innocence feels
uncentered. the sample questions feel like 'decentralization' and the
subheadings are anonymity, privacy, and security.  None of those places
feel like they solicit answers to the questions below. I think content
agnosticism is the closest area, and should be in there.

> iQEcBAEBCAAGBQJWwa1aAAoJEAi1oPJjbWjp8mgH/ioOET2gqgPTdvgvK3mNMGBa
> /ciYsROw/8Rjt+e17YR3+b1MZpF9S+seyMfCwiPDbnRiF9KNpVo9tH6JuOEOh71r
> 5QS7Vmc9+s8BEYv/OYASqC910+SOsAngO+5eBgkzIMRX8fdaIdbCYUmvSdo1p49E
> mGst1d/BHFpz9U2hBYvgDdMLqVNkMeTUdZCt5g7A2MHqinw8tF0QwV48LXW0S+5+
> J5blhuXpQln7i/wyCYWOWThzm9SwutNud3+hGud0qGfVxTYdh4RdbqlTVaVbpzKa
> vu6xWDu9BuPG361aWTvp6Jb9lHccW7K7NX2sYcx4zzOzoXKn/C6FAUlmUCDQeNo=
> =bqPr

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 22 Feb 2016 13:40:51 +0100

On 02/16/2016 07:53 PM, Will Scott wrote:
> Inline Replies
> 
> On Mon, Feb 15, 2016 at 2:50 AM, Niels ten Oever

np

> part of the right to freedom of assembly and association
> (4.7.2.7), not of any other right at the moment.
> 
>> This seems like the correct place for it, but the sample question
>> "Is it possible to deploy your protocol without a single point of
>> control?" feels like a decentralization issue.
> 

Agree. It should have never been mentioned under Right to be Presumed
Innocent directly but always under a technical subheader, so removed,
but added the subhead 'decentralization' under the Right to be
Presumed Innocent.

> 
>> but is different from presumed innocence. The failure case I'd
>> want that section to talk to is the a hypothetical standard for
>> DPI policy, where you wouldn't want to block all bittorrent
>> traffic for copyright infringement. Instead, you'd want to have
>> systems and standards structured so that protocols and carried
>> data isn't discriminated based on stereotypes, but on the
>> specific content of the transmissions.
> 

I don't disagree, but I'm not sure whether DPI policies fall within
the purview of the IETF / IRTF. How we could fix this is add 'Content
Agnosticism' as a subheading under the Right to be Presumed Innocent,
but I'm not sure how that would be stronger (or more elaborate) than
privacy.

>> Adding it to 4.7.2.2 seems appropriate.

Done

>> My point above was trying to say that right to presumed innocence
>> feels uncentered. the sample questions feel like
>> 'decentralization' and the subheadings are anonymity, privacy,
>> and security.  None of those places feel like they solicit
>> answers to the questions below. I think content agnosticism is
>> the closest area, and should be in there.
> 

Agree, so adding 'Content agnosticism" (as well as 'Decentralization')
to Right to be presumed innocent.
I understand your point much better now. Corinne and I will redo the
considerations list because offlist I also got quite some comments
that the current structure is not helpful (there are too many 'see
above's'.

So what we'll do is that we leave the different technical
considerations (anonymity, privacy, content agnosticism, etc) and in
brackets put the rights they're related to behind them.

> 
>> Here's a proposal for an alternate framing: What is the
>> potential for discrimination against users of your protocol? How
>> can use of your protocol be used to implicate participants?
> 

Nice! I've added 'What is the potential for discrimination against
users of your protocol? How can use of your protocol be used to
implicate users?' to 'decentralization', but somehow I feel these
questions would also fit under privacy or anonymity. What do you think?

For the moment I'll leave it here.

Cheers,

Niels

> 
> Would this be fixed by the proposal suggested above, or do you
> think we should add other considerations to the Right to
> non-discrimination (4.7.2.2) ?
> 
>> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> 
>> Dear all,
> 
>> substantial amount of text to the methodology draft, which we
>> just made available for you here:
> 
>> considerations, modeled after RFC6973. I pasted this specific
>> part also underneath for your convenience and consideration.
>> There are also some small additions to the middlebox text as well
>> as other nits than can be found directly in the draft (and in the
>> diff 
>> https://tools.ietf.org/rfcdiff?url2=draft-varon-hrpc-methodology-04.t
x
t
> <https://tools.ietf.org/rfcdiff?url2=draft-varon-hrpc-methodology-04.t
x
t>
>> ### Human Rights Threats The human rights threats on the
>> Internet come in a myriad of forms. Protocols and standards can
>> harm or enable the right to freedom of expression, right to 
>> non-discrimination, right to equal protection, right to be
>> presumed innocence, right to participate in cultural life, arts
>> and science, right to freedom of assembly and association, and
>> the right to security. An end-user who is denied access to
>> certain services, data or websites may be unable to disclose
>> vital information about the malpractices of a government or other
>> authority.  A person whose communications are monitored may be
>> prevented from exercising their right to freedom of association.
>> In a worst-case scenario, protocols that leak information can
>> lead to physical danger. A realistic example to consider is when
>> opposition leaders in totalitarian regimes are subjected to
>> torture on the basis of information gathered by the regime
>> through information leakage in protocols.
> 
>> violations/harms and present several examples of how these
>> threats to human rights materialize on the Internet. This threat
>> modeling is inspired by {{RFC6973}} Privacy Considerations for
>> Internet Protocols, which bases itself on security threat
>> analysis. This method is by no means a perfect solution for
>> assessing human rights risks in Internet protocols and systems;
>> it is however the best approach currently available. Certain
>> human rights threats are indirectly considered in Internet
>> protocols as part of the standard privacy and security
>> considerations. Others suggested are tailored specifically to
>> human rights, and represents considerations not currently
>> considered in other RFCs.
> 
>> rights are interrelated, interdependent and universal. Here
>> however we're not discussing all human rights because not all
>> picks right, if other rights seem relevant, please contact the
>> authors and/or the hrpc mailinglist.
> 
>> This section provides guidance for document authors in the form
>> of a questionnaire about a protocol being designed. The
>> questionnaire may be useful at any point in the design process,
>> particularly after document authors have developed a high-level
>> protocol model as described in {{RFC4101}}.
> 
>> Note that the guidance provided in this section does not
>> recommend specific practices.  The range of protocols developed
>> in the IETF is too broad to make recommendations about particular
>> uses of data or how human rights might be balanced against other
>> design goals. However, by carefully considering the answers to
>> each question, document authors should be able to produce a
>> comprehensive analysis that can serve as the basis for discussion
>> of whether the protocol adequately protects against human rights
>> threats.  This guidance is meant to help the thought process of a
>> human rights analysis; it does not provide specific directions
>> for how to write a human rights protocol considerations section
>> (following the example set in {{RFC6973}}).
> 
>> ##### Privacy Did you have a look at the Guidelines in the
>> Privacy Considerations for Internet Protocols {{RFC6973}} section
>> 7? Does your protocol in any way impact the confidentiality of
>> protocol metadata? Does your protocol countering traffic
>> analysis, or data minimisation?
> 
>> ##### Content agnosticism If your protocol impact packet
>> handling, does it look at the packet content? Is it making
>> decisions based on the content of the packet? Is the protocol
>> transparent about its decision? Does your protocol prioritize
>> certain content or services over others?
> 
>> ##### Internationalization Does your protocol have text string
>> that are readable or entered by humans? Does your protocol allow
>> Unicode encoded in UTF-8 only, thereby shifting conversion issues
>> away from individual choices? Did you have a look at
>> {{RFC6365}}?
> 
>> easier by exposing specific identifiers that could be sensitive
>> for filtering. When filtering is happening, does your protocol
>> help make it apparent or transparent?
> 
>> types of hardware? Does your protocol allow for multiple types
>> of application protocols?
> 
>> ##### Anonymity Did you have a look at the Privacy
>> section 6.1.1 ?
>> and high latency connections? Could your protocol also be
>> developed in a stateless manner ?
> 
>> protocol without a single point of control? If applicable, can
>> it also implemented in a federated way?
> 
>> ##### Accessibility when websites, web technologies, or web
>> tools are badly designed, they can create barriers that exclude
>> people from using the Web. Is your protocol designed to provide
>> an enabling environment for people with disabilities? It might
>> be relevant to look at the W3C Web Accessibility Initiative for 
>> examples and guidance.
> 
>> ##### Reliability Is your protocol fault tolerant? Does it
>> degrade gracefully? Do you have a documented way to announce
>> degradation? Do you have measures in place for recovery or
>> partial healing from failure? Is your protocol able to maintain
>> dependability and performance in the face of unanticipated
>> changes or circumstances?
> 
>> ##### Confidentiality (cf {{RFC6973}} ) Which information
>> related to identifiers or data  is exposed to each other protocol
>> entity (i.e., recipients, intermediaries, and enablers)?  Are
>> there ways for protocol implementers to choose to limit the
>> information shared with each entity?  Are there operational
>> controls available to limit the information shared with each
>> entity?
> 
>> require before personal data or identifiers are shared or
>> exposed via the protocol?  If no such mechanisms or controls are
>> specified, is it expected that control and consent will be
>> handled outside of the protoco l?
> 
>> mechanisms that exist outside of the protocol to provide
>> initiators with such control?
> 
>> relationships that govern the  use of the information
>> (contractual or otherwise) with those who operate these
>> intermediaries?
> 
>> ##### Integrity Does your protocol maintain and assure the
>> accuracy of data? Does your protocol maintain and assure the
>> consistency of data? Does your protocol in any way allow for the
>> data to be (intentionally or unintentionally) altered?
> 
>> ##### Authenticity Do you have enough measures to confirm the
>> truth of an attribute of a single piece of data or entity? Can
>> the attributes get garbled along the way (see security)? If
>> relevant have you implemented IPsec and other Standard Security
>> Best Practices?
> 
>> ##### Availability Do your protocols use or depend on
>> proprietary code? Also see 'Open Standards' above. Also see
>> 'Connectivity' above.
> 
>> _______________________________________________ hrpc mailing
>> list [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>> _______________________________________________ hrpc mailing
>> list [email-masked] <mailto:[email-masked]>