Subject: [hrpc] comments on draft guidelines

From: Sandra Braman <[email-masked]>
Date: Thu, 11 Feb 2021 17:25:04 -0600

Folks --

Following are some comments on draft guidelines, some of which echo points
already made on this list. If I've misunderstood anything, please let me
know.  Some of the comments are analytical.  Others are recommendations
that may make the document more effective.  Again, thanks to the authors
and those who provided feedback and input to the authors for all the labor
put in.

Sandra Braman

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

*Human Rights*

Graph 2 on page 4 identifies key sources of human rights.  The manner of
presentation conflates documents from sources that are importantly
different regarding their source and, thus, relative weight.  A document
created by the Internet Governance Forum -- a talk shop only that has no
status within the international legal system on its own -- with United
Nations treaties.  This section of the document will be much stronger if
separate paragraphs discuss actual legal foundations for human rights and
other sources of proposals for things that should be considered human
rights in the Internet environment (the latter would include Hill 2014,
too, for example).  The IGF document is certainly pertinent, but should be
discussed in the manner one would discuss the scholarly literature and
"gray matter" (reports from advocacy groups and non-profit organizations,
etc.), not as if it were international law.

Which human rights will be discussed in this document should be clearly
articulated in the opening section, with definitions for the purposes of
this document and the sources of those rights, and then used consistently
throughout the document.  Late in the document the "right to security"
shows up; is this a rephrasing of Article 28 of the Universal Declaration
on Human Rights, or something else that is not mentioned on page 4?

Theoretically and operationally defining each concept presented as a human
right more thoroughly will be important.  There is confusion in this
document, for example, between the right to access government information,
which is included in a number of constitutions and constitution-like
documents around the world and is considered essential to the ability to
hold governments accountable for their action, and a right to access
information in general (more typically considered necessary to freedom of
expression, since in order to talk about something you have to have
information about it).

What arguments justify which two or three human rights of concern for each
item in section 3.3?  As presented in this draft, it seems essentially
random in a manner that is not persuasive regarding what is in and what is
out.

*Direct vs Indirect Violations of Human Rights*

Perhaps the most interesting thread running through this document is the
implicit suggestion that impediments to technological innovation can
themselves be understood as violations of human rights.  (Fully developing
that argument would make a great scholarly journal article!)  I buy that
argument, as innovations are often/may well be needed to develop
work-arounds for exercises of power that violate human rights in
traditionally understood ways, but this piece will be much more effective
and stronger if it makes that argument explicit and uses it as a tool in
the structuring of the narrative.

The suggestions are two:  (1) Add an explicit discussion of the distinction
between direct violations of human rights (e.g., censorship) and indirect
violations of human rights (e.g., innovation, which includes matters such
as "adaptability" as introduced in this draft). (2) Structure the
discussion of topics in Section 3.3 to clearly distinguish between the
two.  A recommendation for an alternative structuring of those topics can
be found below.

Another distinction that could usefully be introduced in this document is
the difference between short-term and long-term effects on human rights.
Censorship is a short-term, immediate effect.  Differential ability to
access information about one's environment and that provides the
affordances for effective political action -- what was first labelled "the
knowledge gap" in the 1970s and is now more commonly referred to as "the
digital divide" -- is better understood as a long-term effect on human
rights.

*Stages of the Internet Design Process and the Institutional Context*

This draft mentions that different human rights issues come up at different
stages of the protocol development process.  It also asks for a lot of
types of research and thinking that, as others have pointed out, are not
generally within the job description of those working on Internet protocols
and for which they may not have been trained -- these are actually matters
of organizational design.  This document would be much stronger if it
unbundled each of these things.

For stages of the protocol design process, please say more about which
issues should be considered when?  Doing so would require offering a model
of the stages of the protocol design process.  It would be great to have a
section that does that and that then specifies which issues would be of
concern when.  The authors will probably want to include "implementation"
among the stages discussed.

On the organizational design side, the document would be stronger if it
offered at least a model of what an organizational structure might be that
would include all of the different kinds of expertise required to do the
work asked for here, along with a mapping of the work flow across employees
with different types of expertise.

*Research on the Effects of Design Decisions*

A recurring problem in research on communication and the media is confusing
what can be learned from research on an actual text or set of visuals and
the effects of that text or visuals on those who receive it.  In that
context, textual analysis can only tell the researcher what is in the text;
for effects research, quite other research methods must be used.  The same
problem runs throughout this document.  The authors are encouraged to
clearly distinguish the features of a protocol itself, how the protocol
operates within the network (the technical "context" in the sense of how it
interacts with other protocols), how it is used in the application layer,
how applications are used, and the effects of the uses of those
applications.  A second issue raised by the methods introduced here is that
they run the danger of being limited to "looking under the streetlight"
(the familiar story about where a drunk is looking for keys, irrespective
of where they may be), although in terms of provenance that problem may be
more reflective of the fact that the full scholarly literature and what can
be learned from researchers outside of the HRPC have not yet been brought
to bear.

Different research methods will be needed to examine each of these.  This
document would be much stronger if it broke out which of the kinds of
questions raised can actually be the subjects of research at each stage of
this sequence, too.  The mixing of application layer and use issues with
protocol design in my view undermines the effectiveness of the argument
this reader, at least, understands the authors to be trying to make.

Research on designer perceptions of possible human rights risks can be
useful and interesting (I've done some of that research myself), but does
not tell the researcher anything about the actual risks as experienced or
as understood by social scientists who have studied those effects on the
ground. There are, however, several significant bodies of research that the
authors could mine for more empirical detail on the effects of specific
protocol design features rather than assuming that universe is bounded by
what one or a few members of HRPC have done or asking computer scientists
and electrical engineers to undertake all of that work.  It is incredibly
important to keep human rights issues in front of those doing technical
work, including regularly showing up in IETF meetings to alert those
designing protocols to specific issues, but for research on the effects of
those protocols HRPC should be turning to social scientists who are
actually studying the effects and who could be encouraged to go further in
this area, sometimes -- so valuably -- in collaboration with technical
experts who have given themselves to this specific task.  In this regard,
the work of Ron Deibert's group at the University of Toronto (Citizen Lab)
should be highlighted as a model (https://citizenlab.ca/).  Work in fields
such as anthropology, sociology, political science, information science,
communication, STS (studies of technology and society), and economics will
all be useful.

To date the HRPC (to my knowledge) has largely engaged with the communities
of researchers working in this area by bringing individuals to IETF
meetings for short presentations.  Given the relatively small number of
people active within HRPC who come from social science backgrounds and
limits on the time of everyone within HRPC, some assistance may be needed
to take advantage of the many additional research methods that should be
used to evaluate the effects of protocol design on human rights as well as
to incorporate findings from research in this area already conducted into
this document.  A few thoughts regarding how that might be done will be
offered in a separate email.

However it is done, going much further with research methods will
significantly increase the sophistication and utility of this document.  As
it currently stands, the section on "expert interviews" is confusing
because it appears to be asking computer scientists to be expert on social
science matters, for example.  Interviews with various types of experts
will indeed be among the kinds of methods that can be useful, but the
different types of expertise involved should be acknowledged and different
kinds of questions would be asked of different kinds of experts.

*Grouping of Section 3.3 Topics*

Three dimensions of analysis could be used to better structure the
sequencing of topics in Section 3.3.  The suggestion here is to use the
focus of attention as the highest level used to group related issues
together, and then discuss differences between direct and indirect effects
and between short-term and long-term effects within each of the
categories.  A suggestion what the top-level of categorization might look
like is offered here, with the current number of the topics to be included
within it.  Because some of the current topics combine types of issues, the
final category includes one item that in my view should be unbundled for
clarification for the purposes of this document and three items that in my
view should be deleted.  The following section discusses individual topics
and/or the combinations suggested here.

*Network Operations*

Connectivity (3.3.1)
Internationalization (3.3.5)
Localization (3.3.11)
Adaptability (3.3.17)

Open Standards (3.3.7)
Heterogeneity Support (3.3.8)

Decentralization (3.3.12)

Reliability (3.3.13)

*The Individual User*

Privacy (3.3.2)
Pseudonymity (3.3.9)
Confidentiality (3.3.14)
Anonymity (3.3.19)

Accessibility (3.3.10)

*Content*

Content Agnosticism (3.3.3)

Censorship Resistance (3.3.6)
Integrity (3.3.15)
Authenticity (3.3.16)

*To Be Unbundled*

Security (3.3.4)

*Delete*

Outcome Transparency (3.3.18)
Remedy and Attribution (3.3.20)
Miscellaneous Considerations (3.3.21)

*Discussion of Topics and Topic Groupings*

*Network Operations*

Decentralization is separated out because the extent to which
decentralization can occur operates at so many different levels of the
structures involved -- the network, applications, the social structure, and
political structure -- that it is different in kind from the first 5 items
above that seem to me (as someone who is NOT a technical expert) to be
related to each other.  Reliability also seems to me to be different in
kind.

In the scholarly journal article "The Framing Years," the concept of
"technological democracy" as a key design principle for the Internet was
introduced.  The topics of Open Standards and Heterogeneity additionally
can be distinguished by this feature.

The Decentralization topic mixes several different types of control from
diverse sources (governments, protocol limits, etc.) together without
distinguishing them.  The document will be stronger, clearer, and more
useful if it distinguishes them.

In the scholarly journal article "The Geopolitical and the Network
Political:  Internet Designers and Governance," the tension between
geopolitical citizenship (allegiance to one's identity as a citizen of a
geopolitically recognized state -- a government recognized by the UN) and
network citizenship (allegiance to one's identity as a user/citizen of the
Internet, the success of which is critical to the user) is explored.  There
are often instances in which what is required of the geopolitical citizen
is the opposite of what is required of the network citizen.  That is the
tension discussed on page 17, graph 2.

*The Individual User*

All of the topics related to the diverse dimensions of personal privacy
should be grouped together.  They would be best introduced with a general
introduction to RFC 4949.  Doing so would then facilitate further analysis
of what might differently be needed to attend to when thinking about each
of the concepts distinguished there (if there are differences).

Accessibility is different in kind as a topic.  However, the RFC referred
to in that discussion, as I understand it, actually refers to technical
limits and/or limits of access to images that may be in place because of a
particular tool a specific individual chooses to use, not to human
disability.  Is there anything else that deals with human disability at the
protocol level that can be called upon here more validly?  Most of what I
am aware of is at the application level.

*Content*

Content agnosticism is a tough one for two reasons.  First, any decision
about structure made by definition will preference some content or users
(and thus those users' content) over others -- for any door that is opened,
another door is shut.  By the close of the 1990s (the period through which
my own research went), several different models were experimented with to
achieve "fair queuing," and struggles with "quality of service" have
continued since.  What is said here about content agnosticism should
reference all of that history and make specific recommendations if it sees
a way out of this dilemma that others have not yet been able to discover.
Second, national governments are always going to assert priority access.
It is wishful thinking only to believe that would be otherwise.  The fix
here for this document would be to simply acknowledge that.

In the discussion of Authenticity, isn't there another scenario when
considering authentication?  This would add another line to the last
scenario provided:  Bob knows who or what altered the data that did not
come from Alice.  Why should this not also be a requirement?  Surveillance
should go both ways (that is why we have access to government information
as a fundamental constitutional principle).

*To be Unbundled*

The existing topic of "security" includes elements that would, in my view,
be more strongly included if they were unbundled, with elements dispersed
into the above categories to join those that are like of kind.

*To be Deleted*

Outcome Transparency -- This is a reasonable expectation only if every
organization employing those involved in the protocol design process were
to take up recommendations these authors have yet to develop for
organizational structure and work flow processes adequate to the range of
kinds of research being asked for here.  Since it is unlikely that those
recommendations for organizational structure and work flow processes, will
be forthcoming within the probable life cycle of the writing of this
document, and since it is even more unlikely that all of the organizations
involved would follow such recommendations if offered, in my view it would
strengthen the document by deleting this item.  Doing so would be a
defensive writing gesture warding off critiques of naivete.

Remedy and Attribution -- Others have made excellent points on this matter
on the listserv.  Everything that would be pertinent here should be covered
by the topics introduced that apply to individual users.  If that is not
the case, the authors need to make clear what else would be involved.
Delete as a topic but add to the discussion that introduces the document.

Miscellaneous Considerations -- Don't see what this obvious point adds.

*Other Conceptual Issues*

How do the authors distinguish between the effects of protocol-shaped
communications between humans, between humans and non-humans, and between
non-humans from a human rights perspective?  Protocol design features that
impede the ability to make effective use of what is learned from
environmental sensors, for example, could generage long-term human rights
impacts.  Not mentioned at all here but it would be a stronger document if
it were.

Page 6, graph 4 (in 3.3) -- What is meant by "misapplication of the
protocol or technology"?  That is really two questions in one.  First, how
do the authors distinguish an appropriate application from a
misapplication?  Second, as again has been brought up in discussion of this
draft on the list, isn't this about users and not the protocol design that
is the focus of the document?  Those involved with attempts to prevent uses
of dual use technologies for purposes of war rather than peace have
struggled with this for decades; the inability to meaningfully, defensibly,
and effectively grab ahold of it has essentially led to the abandonment of
the effort.

How do the authors evaluate the "adequacy" with which a given protocol
takes human rights into account?  (page 6, graph 5)

The question of whether or not protocols need to be understandable by
humans is one of the most amusing elements of discussion in the RFCs during
their first decade (1969-1979) (again, an article available if of
interest).  In 3.3.5, on internationalization (p. 9, second graph from
bottom), the question is about text strings that "have to be" understood or
entered by humans.  What about situations in which the more accurate verb
would be "can be"?

Re Internationalization -- See my comments on draft association re the
language issue.

In areas such as degradation, the distinction should be drawn between
degradation and knowledge of degradation.  That is also true for integrity
and in other areas that can, under some circumstances, also include even
censorship.

*Writing Issues*

3.2.1 -- This paragraph is opaque.

3.2.2 -- This paragraph is tautological.

3.3.2 -- Page 8, graph 3 -- The document on privacy is not an "example."

3.3.20 -- Page 23, graph 1 -- The reference to Kaye's thinking on freedom
of expression and the Internet belongs in the discussion of human rights
principles, not here.

There are a number of typographical and grammar errors throughout.

---

From: Mark Perkins <[email-masked]>
Date: Mon, 15 Feb 2021 14:07:22 +1100

Thanks for the 'heavy lifting' done by Sandra

A few comments/issues:

The point on sources is well put, but the example 'right to access 
government information' is misused; the problem is more that the 
document has not taken into account the United Nations Human Rights 
Committee General Comments which indicate the official interpretation of 
the relevant articles, which indicates the need for 'separate paragraphs 
discuss actual legal foundations for human rights and other sources of 
proposals for things that should be considered human rights in the 
Internet environment' :

The United Nations Human Rights Committee confirmed in July 2011 that 
the right to freedom of expression protected by Article 19 of the 
International Covenant on Civil and Political Rights includes the right 
of access to information.The Committee said: “Article 19, paragraph 2 
embraces a right of access to information held by public bodies. Such 
information includes records held by a public body, regardless of the 
form in which the information is stored, its source and the date of 
production.”

Human Rights Committee, 102 nd session, Geneva, 11-29 July 2011
General comment No. 34 -vvArticle 19: Freedoms of opinion and expression

"Perhaps the most interesting thread running through this document is 
the implicit suggestion that impediments to technological innovation can 
themselves be understood as violations of human rights.  (Fully 
developing that argument would make a great scholarly journal article!)"

I agree - though perhaps Article 15 of International Covenant on 
Economic, Social and Cultural Rights would cover the question?

The distinction between short & long term effects needs to be drawn with 
care & the linkage between them made explicit:

While censorship can be seen as an 'immediate/short' term effect, such 
censorship can lead to long term effects, such as inability to hold 
government to account, inability to avoid hunger/famine, etc.

The digital divide (or knowledge gap) can be seen as a long term effect 
( affordances for effective political action) but for the individual it 
can have the same impact as censorship - inability to access 
information, ie. a short term effect.

'A second issue raised by the methods introduced here is that they run 
the danger of being limited to "looking under the streetlight" (the 
familiar story about where a drunk is looking for keys, irrespective of 
where they may be), although in terms of provenance that problem may be 
more reflective of the fact that the full scholarly literature and what 
can be learned from researchers outside of the HRPC have not yet been 
brought to bear.'

MP>>I would add the 'crooked neck' analogy (the story where everyone at 
a bus stop ends up looking in same direction, until someone asks the 
first in the queue what he is looking, & he replies - nothing, I have a 
crook in my neck). So 'full' scholarly literature should also include 
diversity...

'but for research on the effects of those protocols HRPC should be 
turning to social scientists who are actually studying the effects and 
who could be encouraged to go further in this area, sometimes -- so 
valuably -- in collaboration with technical experts who have given 
themselves to this specific task.  In this regard, the work of Ron 
Deibert's group at the University of Toronto (Citizen Lab) should be 
highlighted as a model (https://citizenlab.ca/ 
<https://citizenlab.ca/>).  Work in fields such as anthropology, 
sociology, political science, information science, communication, STS 
(studies of technology and society), and economics will all be useful.'

MP>> Oxford Internet Institute also, perhaps HRPC should try to create a 
listing of such groups?

Outcome Transparency: deleting this item.  Doing so would be a defensive 
writing gesture warding off critiques of naivete.

MP>>Disagree, perhaps needs to be reworded to indicate something to be 
aimed at, rather than something 'required'. Most references to human 
rights would be deleted if we followed the logic of expecting 
organizations to follow HR recommendations; international human rights 
are only normative, with no enforcement mechanism, this is especially 
true of the  International Covenant on Economic, Social and Cultural 
Rights, which is explictly has a 'Principle of progressive realisation'.

Best wishes, and again thanks to Sandra
Mark P.

Le 12/02/2021 à 10:25, Sandra Braman a écrit :
> Folks --
>
> Following are some comments on draft guidelines, some of which echo 
> points already made on this list. If I've misunderstood anything, 
> please let me know.  Some of the comments are analytical.  Others are 
> recommendations that may make the document more effective.  Again, 
> thanks to the authors and those who provided feedback and input to the 
> authors for all the labor put in.
>
> Sandra Braman
>
> _Human Rights_
> Graph 2 on page 4 identifies key sources of human rights. The manner 
> of presentation conflates documents from sources that are importantly 
> different regarding their source and, thus, relative weight.  A 
> document created by the Internet Governance Forum -- a talk shop only 
> that has no status within the international legal system on its own -- 
> with United Nations treaties.  This section of the document will be 
> much stronger if separate paragraphs discuss actual legal foundations 
> for human rights and other sources of proposals for things that should 
> be considered human rights in the Internet environment (the latter 
> would include Hill 2014, too, for example).  The IGF document is 
> certainly pertinent, but should be discussed in the manner one would 
> discuss the scholarly literature and "gray matter" (reports from 
> advocacy groups and non-profit organizations, etc.), not as if it were 
> international law.
>
> Which human rights will be discussed in this document should be 
> clearly articulated in the opening section, with definitions for the 
> purposes of this document and the sources of those rights, and then 
> used consistently throughout the document.  Late in the document the 
> "right to security" shows up; is this a rephrasing of Article 28 of 
> the Universal Declaration on Human Rights, or something else that is 
> not mentioned on page 4?
>
> Theoretically and operationally defining each concept presented as a 
> human right more thoroughly will be important. There is confusion in 
> this document, for example, between the right to access government 
> information, which is included in a number of constitutions and 
> constitution-like documents around the world and is considered 
> essential to the ability to hold governments accountable for their 
> action, and a right to access information in general (more typically 
> considered necessary to freedom of expression, since in order to talk 
> about something you have to have information about it).
>
> What arguments justify which two or three human rights of concern for 
> each item in section 3.3?  As presented in this draft, it seems 
> essentially random in a manner that is not persuasive regarding what 
> is in and what is out.
>
> _Direct vs Indirect Violations of Human Rights_
> _
> _
> Perhaps the most interesting thread running through this document is 
> the implicit suggestion that impediments to technological innovation 
> can themselves be understood as violations of human rights.  (Fully 
> developing that argument would make a great scholarly journal 
> article!)  I buy that argument, as innovations are often/may well be 
> needed to develop work-arounds for exercises of power that violate 
> human rights in traditionally understood ways, but this piece will be 
> much more effective and stronger if it makes that argument explicit 
> and uses it as a tool in the structuring of the narrative.
>
> The suggestions are two:  (1) Add an explicit discussion of the 
> distinction between direct violations of human rights (e.g., 
> censorship) and indirect violations of human rights (e.g., innovation, 
> which includes matters such as "adaptability" as introduced in this 
> draft). (2) Structure the discussion of topics in Section 3.3 to 
> clearly distinguish between the two.  A recommendation for an 
> alternative structuring of those topics can be found below.
>
> Another distinction that could usefully be introduced in this document 
> is the difference between short-term and long-term effects on human 
> rights.  Censorship is a short-term, immediate effect.  Differential 
> ability to access information about one's environment and that 
> provides the affordances for effective political action -- what was 
> first labelled "the knowledge gap" in the 1970s and is now more 
> commonly referred to as "the digital divide" -- is better understood 
> as a long-term effect on human rights.
>
> _Stages of the Internet Design Process and the Institutional Context_
> _
> _
> This draft mentions that different human rights issues come up at 
> different stages of the protocol development process. It also asks for 
> a lot of types of research and thinking that, as others have pointed 
> out, are not generally within the job description of those working on 
> Internet protocols and for which they may not have been trained -- 
> these are actually matters of organizational design.  This document 
> would be much stronger if it unbundled each of these things.
>
> issues should be considered when?  Doing so would require offering a 
> model of the stages of the protocol design process.  It would be great 
> to have a section that does that and that then specifies which issues 
> would be of concern when.  The authors will probably want to include 
> "implementation" among the stages discussed.
>
> On the organizational design side, the document would be stronger if 
> it offered at least a model of what an organizational structure might 
> be that would include all of the different kinds of expertise required 
> to do the work asked for here, along with a mapping of the work flow 
> across employees with different types of expertise.
>
> _Research on the Effects of Design Decisions_
> _
> _
> A recurring problem in research on communication and the media is 
> confusing what can be learned from research on an actual text or set 
> of visuals and the effects of that text or visuals on those who 
> receive it.  In that context, textual analysis can only tell the 
> researcher what is in the text; for effects research, quite other 
> research methods must be used. The same problem runs throughout this 
> document.  The authors are encouraged to clearly distinguish the 
> features of a protocol itself, how the protocol operates within the 
> network (the technical "context" in the sense of how it interacts with 
> other protocols), how it is used in the application layer, how 
> applications are used, and the effects of the uses of those 
> applications.  A second issue raised by the methods introduced here is 
> that they run the danger of being limited to "looking under the 
> streetlight" (the familiar story about where a drunk is looking for 
> keys, irrespective of where they may be), although in terms of 
> provenance that problem may be more reflective of the fact that the 
> full scholarly literature and what can be learned from researchers 
> outside of the HRPC have not yet been brought to bear.
>
> Different research methods will be needed to examine each of these.  
> This document would be much stronger if it broke out which of the 
> kinds of questions raised can actually be the subjects of research at 
> each stage of this sequence, too.  The mixing of application layer and 
> use issues with protocol design in my view undermines the 
> effectiveness of the argument this reader, at least, understands the 
> authors to be trying to make.
>
> useful and interesting (I've done some of that research myself), but 
> does not tell the researcher anything about the actual risks as 
> experienced or as understood by social scientists who have studied 
> those effects on the ground. There are, however, several significant 
> bodies of research that the authors could mine for more empirical 
> detail on the effects of specific protocol design features rather than 
> assuming that universe is bounded by what one or a few members of HRPC 
> have done or asking computer scientists and electrical engineers to 
> undertake all of that work.  It is incredibly important to keep human 
> rights issues in front of those doing technical work, including 
> regularly showing up in IETF meetings to alert those designing 
> protocols to specific issues, but for research on the effects of those 
> protocols HRPC should be turning to social scientists who are actually 
> studying the effects and who could be encouraged to go further in this 
> area, sometimes -- so valuably -- in collaboration with technical 
> experts who have given themselves to this specific task.  In this 
> regard, the work of Ron Deibert's group at the University of Toronto 
> (Citizen Lab) should be highlighted as a model (https://citizenlab.ca/ 
> <https://citizenlab.ca/>).  Work in fields such as anthropology, 
> sociology, political science, information science, communication, STS 
> (studies of technology and society), and economics will all be useful.
>
> To date the HRPC (to my knowledge) has largely engaged with the 
> communities of researchers working in this area by bringing 
> individuals to IETF meetings for short presentations.  Given the 
> relatively small number of people active within HRPC who come from 
> social science backgrounds and limits on the time of everyone within 
> HRPC, some assistance may be needed to take advantage of the many 
> additional research methods that should be used to evaluate the 
> effects of protocol design on human rights as well as to incorporate 
> findings from research in this area already conducted into this 
> document.  A few thoughts regarding how that might be done will be 
> significantly increase the sophistication and utility of this 
> document.  As it currently stands, the section on "expert interviews" 
> is confusing because it appears to be asking computer scientists to be 
> expert on social science matters, for example.  Interviews with 
> various types of experts will indeed be among the kinds of methods 
> that can be useful, but the different types of expertise involved 
> should be acknowledged and different kinds of questions would be asked 
> of different kinds of experts.
>
> _Grouping of Section 3.3 Topics_
> _
> _
> sequencing of topics in Section 3.3.  The suggestion here is to use 
> the focus of attention as the highest level used to group related 
> issues together, and then discuss differences between direct and 
> indirect effects and between short-term and long-term effects within 
> each of the categories.  A suggestion what the top-level of 
> categorization might look like is offered here, with the current 
> number of the topics to be included within it.  Because some of the 
> current topics combine types of issues, the final category includes 
> one item that in my view should be unbundled for clarification for the 
> purposes of this document and three items that in my view should be 
> deleted.  The following section discusses individual topics and/or the 
> combinations suggested here.
>
> /Network Operations/
> /
> /
> Connectivity (3.3.1)
> /The Individual User/
> /
> /
> /Content/
> /
> /
> /To Be Unbundled/
> /
> /
> /Delete/
> /
> /
> _Discussion of Topics and Topic Groupings_
> _
> _
> /Network Operations/
> /
> /
> structures involved -- the network, applications, the social 
> structure, and political structure -- that it is different in kind 
> from the first 5 items above that seem to me (as someone who is NOT a 
> technical expert) to be related to each other.  Reliability also seems 
> to me to be different in kind.
>
> "technological democracy" as a key design principle for the Internet 
> was introduced.  The topics of Open Standards and Heterogeneity 
> additionally can be distinguished by this feature.
>
> The Decentralization topic mixes several different types of control 
> from diverse sources (governments, protocol limits, etc.) together 
> without distinguishing them.  The document will be stronger, clearer, 
> and more useful if it distinguishes them.
>
> geopolitical citizenship (allegiance to one's identity as a citizen of 
> a geopolitically recognized state -- a government recognized by the 
> UN) and network citizenship (allegiance to one's identity as a 
> user/citizen of the Internet, the success of which is critical to the 
> user) is explored.  There are often instances in which what is 
> required of the geopolitical citizen is the opposite of what is 
> required of the network citizen.  That is the tension discussed on 
> page 17, graph 2.
>
> /The Individual User/
>
> All of the topics related to the diverse dimensions of personal 
> privacy should be grouped together.  They would be best introduced 
> with a general introduction to RFC 4949. Doing so would then 
> facilitate further analysis of what might differently be needed to 
> attend to when thinking about each of the concepts distinguished there 
> (if there are differences).
>
> Accessibility is different in kind as a topic.  However, the RFC 
> referred to in that discussion, as I understand it, actually refers to 
> technical limits and/or limits of access to images that may be in 
> place because of a particular tool a specific individual chooses to 
> use, not to human disability. Is there anything else that deals with 
> human disability at the protocol level that can be called upon here 
> more validly? Most of what I am aware of is at the application level.
>
> /Content/
>
> Content agnosticism is a tough one for two reasons.  First, any 
> decision about structure made by definition will preference some 
> content or users (and thus those users' content) over others -- for 
> any door that is opened, another door is shut.  By the close of the 
> 1990s (the period through which my own research went), several 
> different models were experimented with to achieve "fair queuing," and 
> struggles with "quality of service" have continued since.  What is 
> said here about content agnosticism should reference all of that 
> history and make specific recommendations if it sees a way out of this 
> dilemma that others have not yet been able to discover.  Second, 
> national governments are always going to assert priority access.  It 
> is wishful thinking only to believe that would be otherwise.  The fix 
> scenario provided:  Bob knows who or what altered the data that did 
> not come from Alice.  Why should this not also be a requirement?  
> Surveillance should go both ways (that is why we have access to 
> government information as a fundamental constitutional principle).
>
> /To be Unbundled/
> /
> /
> The existing topic of "security" includes elements that would, in my 
> view, be more strongly included if they were unbundled, with elements 
> dispersed into the above categories to join those that are like of kind.
>
> /To be Deleted/
> /
> /
> organization employing those involved in the protocol design process 
> were to take up recommendations these authors have yet to develop for 
> organizational structure and work flow processes adequate to the range 
> of kinds of research being asked for here.  Since it is unlikely that 
> those recommendations for organizational structure and work flow 
> processes, will be forthcoming within the probable life cycle of the 
> writing of this document, and since it is even more unlikely that all 
> of the organizations involved would follow such recommendations if 
> offered, in my view it would strengthen the document by deleting this 
> item.  Doing so would be a defensive writing gesture warding off 
> critiques of naivete.
>
> Remedy and Attribution -- Others have made excellent points on this 
> matter on the listserv.  Everything that would be pertinent here 
> should be covered by the topics introduced that apply to individual 
> users.  If that is not the case, the authors need to make clear what 
> else would be involved. Delete as a topic but add to the discussion 
> that introduces the document.
>
> _Other Conceptual Issues_
> _
> _
> communications between humans, between humans and non-humans, and 
> between non-humans from a human rights perspective?  Protocol design 
> features that impede the ability to make effective use of what is 
> learned from environmental sensors, for example, could generage 
> long-term human rights impacts.  Not mentioned at all here but it 
> would be a stronger document if it were.
>
> protocol or technology"?  That is really two questions in one.  First, 
> how do the authors distinguish an appropriate application from a 
> misapplication? Second, as again has been brought up in discussion of 
> this draft on the list, isn't this about users and not the protocol 
> design that is the focus of the document?  Those involved with 
> attempts to prevent uses of dual use technologies for purposes of war 
> rather than peace have struggled with this for decades; the inability 
> to meaningfully, defensibly, and effectively grab ahold of it has 
> essentially led to the abandonment of the effort.
>
> humans is one of the most amusing elements of discussion in the RFCs 
> during their first decade (1969-1979) (again, an article available if 
> of interest).  In 3.3.5, on internationalization (p. 9, second graph 
> from bottom), the question is about text strings that "have to be" 
> understood or entered by humans.  What about situations in which the 
> more accurate verb would be "can be"?
>
> degradation and knowledge of degradation.  That is also true for 
> integrity and in other areas that can, under some circumstances, also 
> include even censorship.
>
> _Writing Issues_
> _
> _
> 3.3.20 -- Page 23, graph 1 -- The reference to Kaye's thinking on 
> freedom of expression and the Internet belongs in the discussion of 
> human rights principles, not here.
>
> _
> _
> _
> _
> _
> _
> _
> _
> _
> _
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc

-- 
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

---

From: Gurshabad Grover <[email-masked]>
Date: Mon, 15 Feb 2021 18:56:55 +0530

Prof. Braman,

Thanks for your detailed feedback.

Apologies for the silence on the list: just a note that we are working
on pushing a major update based on your comments and the suggestions
from Bill Woodcock, Corinne and others.

Will send a response to all the comments with the update as well.

Thank you.
-Gurshabad

On 2/12/21 4:55 AM, Sandra Braman wrote:
> points already made on this list. If I've misunderstood anything, please
> let me know.  Some of the comments are analytical.  Others are
> separate paragraphs discuss actual legal foundations for human rights
> and other sources of proposals for things that should be considered
> human rights in the Internet environment (the latter would include Hill
> 2014, too, for example).  The IGF document is certainly pertinent, but
> should be discussed in the manner one would discuss the scholarly
> literature and "gray matter" (reports from advocacy groups and
> non-profit organizations, etc.), not as if it were international law.
> 
> this document and the sources of those rights, and then used
> consistently throughout the document.  Late in the document the "right
> to security" shows up; is this a rephrasing of Article 28 of the
> Universal Declaration on Human Rights, or something else that is not
> mentioned on page 4?
> 
> constitution-like documents around the world and is considered essential
> to the ability to hold governments accountable for their action, and a
> right to access information in general (more typically considered
> necessary to freedom of expression, since in order to talk about
> something you have to have information about it).
> 
> essentially random in a manner that is not persuasive regarding what is
> in and what is out.
> 
> developing that argument would make a great scholarly journal article!) 
> I buy that argument, as innovations are often/may well be needed to
> develop work-arounds for exercises of power that violate human rights in
> traditionally understood ways, but this piece will be much more
> effective and stronger if it makes that argument explicit and uses it as
> a tool in the structuring of the narrative.
> 
> distinction between direct violations of human rights (e.g., censorship)
> and indirect violations of human rights (e.g., innovation, which
> includes matters such as "adaptability" as introduced in this draft).
> (2) Structure the discussion of topics in Section 3.3 to clearly
> distinguish between the two.  A recommendation for an alternative
> structuring of those topics can be found below.
> 
> ability to access information about one's environment and that provides
> the affordances for effective political action -- what was first
> labelled "the knowledge gap" in the 1970s and is now more commonly
> referred to as "the digital divide" -- is better understood as a
> long-term effect on human rights.
> 
> Internet protocols and for which they may not have been trained -- these
> are actually matters of organizational design.  This document would be
> much stronger if it unbundled each of these things.
> 
> offered at least a model of what an organizational structure might be
> that would include all of the different kinds of expertise required to
> do the work asked for here, along with a mapping of the work flow across
> employees with different types of expertise.
> 
> confusing what can be learned from research on an actual text or set of
> visuals and the effects of that text or visuals on those who receive
> it.  In that context, textual analysis can only tell the researcher what
> is in the text; for effects research, quite other research methods must
> be used.  The same problem runs throughout this document.  The authors
> are encouraged to clearly distinguish the features of a protocol itself,
> how the protocol operates within the network (the technical "context" in
> the sense of how it interacts with other protocols), how it is used in
> the application layer, how applications are used, and the effects of the
> uses of those applications.  A second issue raised by the methods
> introduced here is that they run the danger of being limited to "looking
> under the streetlight" (the familiar story about where a drunk is
> looking for keys, irrespective of where they may be), although in terms
> of provenance that problem may be more reflective of the fact that the
> This document would be much stronger if it broke out which of the kinds
> of questions raised can actually be the subjects of research at each
> stage of this sequence, too.  The mixing of application layer and use
> issues with protocol design in my view undermines the effectiveness of
> the argument this reader, at least, understands the authors to be trying
> to make. 
> 
> experienced or as understood by social scientists who have studied those
> effects on the ground. There are, however, several significant bodies of
> research that the authors could mine for more empirical detail on the
> effects of specific protocol design features rather than assuming that
> universe is bounded by what one or a few members of HRPC have done or
> asking computer scientists and electrical engineers to undertake all of
> that work.  It is incredibly important to keep human rights issues in
> front of those doing technical work, including regularly showing up in
> IETF meetings to alert those designing protocols to specific issues, but
> for research on the effects of those protocols HRPC should be turning to
> social scientists who are actually studying the effects and who could be
> encouraged to go further in this area, sometimes -- so valuably -- in
> collaboration with technical experts who have given themselves to this
> specific task.  In this regard, the work of Ron Deibert's group at the
> University of Toronto (Citizen Lab) should be highlighted as a model
> (https://citizenlab.ca/).  Work in fields such as anthropology,
> communities of researchers working in this area by bringing individuals
> to IETF meetings for short presentations.  Given the relatively small
> number of people active within HRPC who come from social science
> backgrounds and limits on the time of everyone within HRPC, some
> assistance may be needed to take advantage of the many additional
> research methods that should be used to evaluate the effects of protocol
> design on human rights as well as to incorporate findings from research
> in this area already conducted into this document.  A few thoughts
> regarding how that might be done will be offered in a separate email.
> 
> significantly increase the sophistication and utility of this document. 
> As it currently stands, the section on "expert interviews" is confusing
> because it appears to be asking computer scientists to be expert on
> social science matters, for example.  Interviews with various types of
> experts will indeed be among the kinds of methods that can be useful,
> but the different types of expertise involved should be acknowledged and
> different kinds of questions would be asked of different kinds of experts.
> 
> together, and then discuss differences between direct and indirect
> effects and between short-term and long-term effects within each of the
> categories.  A suggestion what the top-level of categorization might
> look like is offered here, with the current number of the topics to be
> included within it.  Because some of the current topics combine types of
> issues, the final category includes one item that in my view should be
> unbundled for clarification for the purposes of this document and three
> items that in my view should be deleted.  The following section
> discusses individual topics and/or the combinations suggested here. 
> 
> /Network Operations/
> /
> /
> Connectivity (3.3.1)
> structures involved -- the network, applications, the social structure,
> and political structure -- that it is different in kind from the first 5
> items above that seem to me (as someone who is NOT a technical expert)
> to be related to each other.  Reliability also seems to me to be
> different in kind.
> 
> geopolitically recognized state -- a government recognized by the UN)
> and network citizenship (allegiance to one's identity as a user/citizen
> of the Internet, the success of which is critical to the user) is
> explored.  There are often instances in which what is required of the
> geopolitical citizen is the opposite of what is required of the network
> citizen.  That is the tension discussed on page 17, graph 2.
> 
> /The Individual User/
> 
> should be grouped together.  They would be best introduced with a
> general introduction to RFC 4949.  Doing so would then facilitate
> further analysis of what might differently be needed to attend to when
> thinking about each of the concepts distinguished there (if there are
> differences).
> 
> technical limits and/or limits of access to images that may be in place
> because of a particular tool a specific individual chooses to use, not
> to human disability.  Is there anything else that deals with human
> disability at the protocol level that can be called upon here more
> validly?  Most of what I am aware of is at the application level.
> 
> /Content/
> 
> (and thus those users' content) over others -- for any door that is
> opened, another door is shut.  By the close of the 1990s (the period
> through which my own research went), several different models were
> experimented with to achieve "fair queuing," and struggles with "quality
> of service" have continued since.  What is said here about content
> agnosticism should reference all of that history and make specific
> recommendations if it sees a way out of this dilemma that others have
> not yet been able to discover.  Second, national governments are always
> going to assert priority access.  It is wishful thinking only to believe
> that would be otherwise.  The fix here for this document would be to
> simply acknowledge that.
> 
> come from Alice.  Why should this not also be a requirement? 
> writing of this document, and since it is even more unlikely that all of
> the organizations involved would follow such recommendations if offered,
> in my view it would strengthen the document by deleting this item. 
> Doing so would be a defensive writing gesture warding off critiques of
> naivete.
> 
> matter on the listserv.  Everything that would be pertinent here should
> be covered by the topics introduced that apply to individual users.  If
> that is not the case, the authors need to make clear what else would be
> involved.  Delete as a topic but add to the discussion that introduces
> the document.
> 
> long-term human rights impacts.  Not mentioned at all here but it would
> be a stronger document if it were.
> 
> design that is the focus of the document?  Those involved with attempts
> to prevent uses of dual use technologies for purposes of war rather than
> peace have struggled with this for decades; the inability to
> meaningfully, defensibly, and effectively grab ahold of it has
> during their first decade (1969-1979) (again, an article available if of
> bottom), the question is about text strings that "have to be" understood
> or entered by humans.  What about situations in which the more accurate
> verb would be "can be"?
>

---

From: Sandra Braman <[email-masked]>
Date: Mon, 15 Feb 2021 09:18:16 -0600

Thanks for letting me know.  Will your response to comments include those
that came from Corinne, Bill, and others as well, so we can all understand
the arguments, corrections, additional points, etc., to which the new draft
is responding, since (unless I have missed it), these have not all been
shared with the list yet?

On Mon, Feb 15, 2021 at 7:27 AM Gurshabad Grover <[email-masked]>
wrote:

> > (
> https://urldefense.com/v3/__https://citizenlab.ca/__;!!KwNVnqRv!RUZdCcJt8Ap1Rd6uZryyfmW8H5VGuVrmDYRRl9SFgVzE7xWxLLyDMfrrza9gzw$
> ).  Work in fields such as anthropology,
> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!RUZdCcJt8Ap1Rd6uZryyfmW8H5VGuVrmDYRRl9SFgVzE7xWxLLyDMfrZoGjVnA$
> >
>

---

From: Gurshabad Grover <[email-masked]>
Date: Mon, 15 Feb 2021 20:49:33 +0530

Yes, will be sending a detailed response (including what changes were
made to address the feedback) to each review.

-Gurshabad

On 2/15/21 8:48 PM, Sandra Braman wrote:
> Thanks for letting me know.  Will your response to comments include
> those that came from Corinne, Bill, and others as well, so we can all
> understand the arguments, corrections, additional points, etc., to which
> the new draft is responding, since (unless I have missed it), these have
> not all been shared with the list yet?
> 
> On Mon, Feb 15, 2021 at 7:27 AM Gurshabad Grover
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Prof. Braman,
> 
>     please
>     document
>     clearly
>     essential
>     article!) 
>     censorship)
>     provides
>     these
>     kinds
>     those
>     (https://urldefense.com/v3/__https://citizenlab.ca/__;!!KwNVnqRv!RUZdCcJt8Ap1Rd6uZryyfmW8H5VGuVrmDYRRl9SFgVzE7xWxLLyDMfrrza9gzw$
>     individuals
>     document. 
>     structure,
>     privacy
>     place
>     decision
>     should
>     attempts
>     > [email-masked] <mailto:[email-masked]>
>     >