Subject: Re: [hrpc] IRTF Chair review of draft-irtf-hrpc-guidelines-10

From: Gurshabad Grover <[email-masked]>
Date: Sun, 23 Jan 2022 21:25:10 +0530

Colin, thanks very much for the review. I hope the new version of the
document adequately addresses your comments and suggestions. Please see
comments in-line to track the change corresponding to each comment.

On 11/8/21 1:43 AM, Colin Perkins wrote:

> [...]
> 
> 1) The UN human rights declarations are clearly important, but different countries and cultures interpret those rights and responsibilities in differing ways, and the extent to which they’re incorporated into national laws also varies. Some countries guarantee additional rights, while others try to restrict rights that are accepted elsewhere. It would help the reader if the document said more about the rights being considered and how the authors interpret them, and gave examples of how those rights are incorporated into various national laws. This would help provide context for the discussion, and may illustrate differences in interpretation of those rights around the world. Section 2 hints at some of this, but more details would provide important context for protocol designers that may not be familiar with the way the relevant rights are described, their interpretation and implications, and their practical incorporation into relevant laws and regulations. 
> 

You are, of course, right in that different countries may interpret
those rights and responsibilities in different ways. But, we feel that
it is out of the scope of the document to comment on how international
human rights are practically incorporated into domestic law.

We are following the framework of international human rights, which is a
body of work and practice in its own right, independent from domestic
legislation. For example, the Guiding Principles on Business and Human
Rights [0] talk about state responsibility to protect human rights, but
also of the corporate responsibility (mostly without regard to the state
the company is domiciled in).

I hope this explanation is satisfactory, please let me know if you have
any other comments or questions regarding this.

> 2) Section 3.1 seems to assume that a protocol is developed, then a human rights review is conducted. A less adversarial phrasing might be to suggest ways in which protocol designers can incorporate awareness of human rights issues into the protocol design process.
> 

Thanks, done.

> 3) Section 3.2 includes a detailed list of questions to consider, to illustrate the human rights impact of various protocol design choices. The approach taken, listing questions, followed by some discussion of how the questions relate to human rights, and finally giving some examples to illustrate the issues, is good. The chosen topics are, however, not always presented in a logical order, and there is some considerable overlap between the different questions. The material would benefit from a review of the order of presentation to ensure related material is grouped together, and to reduce duplication (I accept that the nature of the material is that there will always be some overlap between topics).
> 

Thanks, makes sense. I've done some re-ordering of the sections so that
they're in a more logical order.

> 4) The discussion in Section 3.2 is, at times, phrased in a manner that advocates a particular approach without acknowledging the complexity of the trade-offs that must be made, and that there are, perhaps, reasons why alternative approaches are chosen. It might be helpful to review the material to ensure a neutral point of view is adopted when presenting the questions and issues.
> 

There may be circumstances with design trade-offs, but for each section,
the intention is the document is advance what design choices align with
values in international human rights. This is clearly done in
Connectivity and Remedy, for instance. Arguably, the document is not
'neutral' to begin with, however, because we aim to provide clear
guidance on those trade-offs. That said, we would love pointers to
specific text which you think it is too tendentious or does not argue a
particular point of view clearly.

> 5) The discussion in Section 3.2 is structured in a way that it’s not always clear what actions a protocol designer can take to address the issues raised. I accept that, in many cases, the concrete action depends on the protocol being designed, but general principles can often be stated if the desire is to achieve a certain outcome. Similarly, highlighting principles that are in conflict, where a trade-off may exist between different goals, is important. 
> 
> 

As you said, the concrete action depends on the protocol. Given the
group's and others' experience in applying these considerations, it's
usually clear to how to practically implement the principle in a
particular circumstance (and has been useful in that way according to
the feedback we've received).

I think we've already highlighted trade-offs in decisions. Any specific
section where you think we should take another look?

> 
> Specific comments on details follow:
> 
> RFC 5743 requires certain statements be present in the Abstract and Introduction to the draft. The draft includes these in the Abstract, but not the Introduction.
> 

Thanks, done now.

> §1: “The understanding of what human rights are is based on the Universal Declaration of Human Rights and subsequent treaties that jointly form the body of international human rights law“ – The UN UDHR is easy to find, of course, but it would be helpful to reference the subsequent treaties considered. Section 2 has some additional references, but their status is not always clear.
> 

Done.

> 
> Editorial: the organisation of the document might be clearer if Sections 3.1 and 3.2 were promoted to be top level sections.
> 

Makes sense, done!

> 
> Section 3.2.1 considers three topics: where protocol functions are performed, how well the protocol works in certain environments, and whether state is maintained. These are all important to consider, but seem to be largely separable concerns. Separating them might allow for more nuanced discussion of each topic.
> 

Thank you, have separated them into two buckets.

> This section cites the end-to-end principle, but doesn’t discuss the implications of the choice of end points. The statement that “the end-to-end principle in protocol design is important to ensure the reliability and security” over-simplifies a complex set of concerns around service placement, the different types of security being provided, and how reliability and availability are ensured.
> 

I've edited this, hopefully in a way that conveys the general
applicability of the principle to reliability.

> “Considering the fact that network quality and conditions vary across geography and time, it is also important to design protocols such that they are reliable even on low bandwidth and high latency connections” – not all protocols need to be reliable in any conditions, and certain services require some minimum set of resources to be able to operate. There’s perhaps a more nuanced discussion that can be had around understanding the conditions under which a protocol will operate, how it can scale / gracefully degrade across a range of conditions, and what are the implications of the scaling limitations?
> 

I'm sorry that I'm slightly confused by this. Could you clarify what you
mean? Isn't it generally ideal that user-facing protocols are reliable
across the mentioned conditions? What's an example of "protocols [that
need not be ideally] reliable in any conditions"?

> Section 3.2.2 mentions confidentiality of metadata but not of data. The discussion would benefit from a discussion of potential threat models: privacy for whom, and against what adversaries? 
> 

Thanks, rephrased accordingly.

> What are the trade-offs of confidentiality vs operational needs? RFCs 7258, 7624, 8404, 8546, and 9065 seem relevant, and I’m sure there is a significant amount of related academic work. 
> 

Thanks for sharing specific resources. I went through all of them, and
most of them are advocating for more confidentiality (with one noting
how to operationally deal with that shift in design).

By "operational needs", I am guessing you are referring to the network
operator and not really the end-user. However, I think the document only
intends to discuss trade-offs of different decisions _if_ they
facilitate/hinder specific rights. Even though some design and
implementation choices may present an operational challenge, those kinds
of trade-offs are not in the scope of this particular document in my
opinion.

> This section would benefit from some discussion around content moderation, wire tapping, and so on.
> 

Thanks, done.

> 
> Section 3.2.3 gives some specific examples of prioritisation relating to low-level packet forwarding. The examples highlight cases where prioritisation is problematic, but not its potential benefits in allowing critical services to operate in environments where resources are constrained, or in supporting user preferences – there is more nuance to the argument than is expressed. 
> 

I think the section presents a general principle for design of network
protocols. For the exceptions, I think this consideration already covers
what the designer/implementer must do if prioritisation is considered
important (as in the examples you state):

"Does your protocol prioritize certain content or services over others
in the routing process? Is the protocol transparent about the
prioritization that is made (if any)?"

> Section 3.2.3 could usefully discuss other aspects of content agnosticism. There are difficult question around moderation, child protection, legally mandated restrictions on content, or legal requirement to prioritise certain types of content or traffic, that are not mentioned. 
> 

The section aims to explain the general principle, and mentions the
example of traffic handling. If protocol designers are making exceptions
(for the cases you mentioned or otherwise), then it should be clearly
documented, for which I've added a sentence of for now.

> Section 3.2.4 focussed on security, but that’s a very open-ended topic. The guidance might be easier to translate into concrete changes in protocol design if specific classes of attack from BCP 72 were brought into this document and discussed in more detail.
> 

Thanks, done. We do want in this section for readers to primarily read
BCP72 themselves.

> Section 3.2.5 discusses internationalisation, but seems primarily focussed on textual elements in protocol data. That’s an important aspect of internationalisation, but there are many other issues to consider. Languages, names, addresses, dates and times, can all be protocol visible information and are often treated inappropriately. There are also issues around what services and featured can be offered in particular regions, and with what protocol features and mechanisms are used to determine how to internationalise a system and decide what features/services to offer. The document would benefit from broader discussion of these topics.
> 

[to-do]

> Section 3.2.6 is focussed on censorship resistance, but an alternative phrasing might be to consider the implications of censorship, content filtering, moderation, and user identity and tracking on human rights. There is more depth and nuance to this topic than is suggested here, that’s important when designing protocols.
> 

Thanks, slightly rephrased. I think the implications of censorship on
human rights are quite direct and understood widely, so to me, the
current text seems to be doing a good job of briefly explaining the
context, and providing specific guidance. User identity/tracking is
probably out of the scope of this particular section, but happy to add
more on censorship based on your suggestions.

> Section 3.2.7 on open standards advocates a particular approach to standards setting, but there are many widely used standards that were developed following different approaches. The document could include a more neutral discussion of the trade-offs, recognising that there are benefits as well as problems in different models of protocol standardisation, implementation, and deployment, while still highlighting the implications for human rights.
> 

Could you elaborate on what you consider the trade-offs to be
(particularly for the approach advocated for in the document)?

> Section 3.2.8 seems to conflate heterogeneity and extensibility. A protocol may support different types of hardware and scale to meet a wide range of performance characteristics, while providing a single, non-extensible, service. Equally, a protocol may extensible in how certain features can be provided while being entirely unscalable in terms of performance. Both questions are important, but could be more effectively discussed if separated.
> 

Right. I agree, I think the extensibility parts did not have an adequate
explanation, so have removed them to focus on heterogeneity support in
this particular section.

> Section 3.2.9 is entitled pseudonymity, but the first paragraph begins with a broader discussion of personally identifiable data. That broader discussion is valuable, but this section isn’t well structured.
> 

Thanks, have restructured the text. Hope it looks better now.

> “consider ways to mitigate the obvious impacts” – state what are those risks. 
> 

That line was not very helpful, have removed it.

> 
> Section 3.2.10 discusses anonymity, and says “If your protocol collects data and distributes it (see [RFC6235]), you should anonymize the data”. The phrasing here is overly broad: an email server collects and distributes data, in the form of email messages, but shouldn’t try to anonymise those messages, for example.
> 

Rephrased to avoid that confusion.

> Section 3.2.10: “Often protocols expose personal data, it is important to consider ways to mitigate the obvious privacy impacts” – expand on what are the privacy issues, or reference previous discussion. That is obvious to one may not be to another.
> 

Deleted this sentence.

> The discussion in Sections 3.2.9 and 3.2.10 seems surprisingly focussed on low-level protocol aspects. These are important, but there is also much that could be said about application level protocols. 
> 

Right, added an example of application layer protocol.

> Section 3.2.11 would benefit from some examples relating to protocols rather than just mark-up languages. The work Gunnar Hellström has been doing in AVT/AVTCORE around timed text protocols might provide an example.
> 

[to-do]

> Section 3.2.12: internationalised DNS might be another example (or maybe for §3.2.5)? I was surprised that Section 3.2.5 and 3.2.12 were so far apart in the document.
> 

Re-ordered now.

> Section 3.2.13 discusses decentralisation, but doesn’t clearly tie the concerns listed in the questions to the issue of centralisation of protocols. DINRG held a recent workshop on this topic (https://datatracker.ietf.org/meeting/interim-2021-dinrg-01/session/dinrg) that might inform the discussion.
> 

[to-do]

> Section 3.2.14 could more clearly tie the issues of protocol reliability to the identified rights. How do these issues relate to those of integrity discussed in Section 3.2.16?
> 

Done.

> Section 3.2.15 clearly identifies some issues around confidentiality, but it is less clear is how these issues are distinct from those around privacy discussed in Section 3.2.5.
> 

I hope the text also captures this understanding: by now,
confidentiality is well-defined and understood technical security
property (eg. on a channel, no leakage of content to any other entity
except the intended recipient), while privacy is much broader.
Confidentiality is one part of privacy, but you need other
considerations for privacy as well (eg. metadata is discussed more in
detail in privacy for this reason).

> Section 3.2.18 could more clearly relate issues of adaptability and permissionless innovation to human rights. I agree that the ability to extend and adapt protocols is desirable, but it’s less clear how, for example, the inability to extend a protocol impacts freedom of assembly.
> 

[to-do]

> Section 3.2.19 discusses outcome transparency. It’s not clear that the effects of any protocol are “fully and easily comprehensible”, and it would seem that are unintended consequences are, by definition, unpredictable. This section doesn’t seem actionable, and could maybe be removed?
> 

I think 'unintended' may not necessarily mean 'unforeseeable'. The text
in this section has actually been used for a review/document, so while I
agree that it's much more open-ended than other sections, I am still of
the opinion that we can leave it in the document.

> Section 3.2.20 highlights the issue of Remedy, but without some examples, it’s difficult to understand how it can be applied to protocol design. 
> 

[shortly continuing this discussion on the thread]

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 25 Jan 2022 14:35:15 +0100

Dear all,

I have sought to address the remaining to-do's in -11. See the particular commits for reference below:

On 23-01-2022 16:55, Gurshabad Grover wrote:
>> Section 3.2.5 discusses internationalisation, but seems primarily focussed on textual elements in protocol data. That’s an important aspect of internationalisation, but there are many other issues to consider. Languages, names, addresses, dates and times, can all be protocol visible information and are often treated inappropriately. 

This is covered in the W3C definition that is provided, right?

>> There are also issues around what services and featured can be offered in particular regions, and with what protocol features and mechanisms are used to determine how to internationalise a system and decide what features/services to offer. The document would benefit from broader discussion of these topics.
>>
> 

Is this a protocol issue or an implementation issue? Anyhow, I think this is already touched upon under 'localionzation' I think, which also refers to RFC5646.  

>> Section 3.2.11 would benefit from some examples relating to protocols rather than just mark-up languages. The work Gunnar Hellström has been doing in AVT/AVTCORE around timed text protocols might…

Excellent suggestion, added.

https://github.com/IRTF-HRPC/drafts/commit/4ced5d988efb4d562b6e6adb87975e9dec05d4a9

>> Section 3.2.13 discusses decentralisation, but doesn’t clearly tie the concerns listed in the questions to the issue of centralisation of protocols. DINRG held a recent workshop on this topic (htt…

Good point. I removed some questions and added a reference to https://datatracker.ietf.org/doc/html/draft-arkko-iab-internet-consolidation-02 . That seemed easier for the prospective users. 

https://github.com/IRTF-HRPC/drafts/commit/3a691da2be957edf4711f77365bb43dc4bf8c7ef

>> Section 3.2.18 could more clearly relate issues of adaptability and permissionless innovation to human rights. I agree that the ability to extend and adapt protocols is desirable, but it’s less cl…

Done. I have sought to make it more clear by adding a paragraph.

https://github.com/IRTF-HRPC/drafts/commit/5500acb24a3ddcd1bad2c474cea81f0b298e83e1

> [shortly continuing this discussion on the thread]

Best,

Niels

-- 
Niels ten Oever, PhD
Postdoctoral Researcher - Media Studies Department - University of Amsterdam
Affiliated Faculty - Digital Democracy Institute - Simon Fraser University
Non-Resident Fellow 2022-2023 - Center for Democracy & Technology
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas
Research Fellow - Centre for Internet and Human Rights - European University Viadrina

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

Read my latest article on Internet infrastructure governance in Globalizations here: https://www.tandfonline.com/doi/full/10.1080/14747731.2021.1953221

---

From: farzaneh badii <[email-masked]>
Date: Tue, 25 Jan 2022 08:43:21 -0500

< I am unclear what research you believe is required; the present
difficulties of real-world prosecution due to lack of attribution are quite
well-known - >

But should we solve them here? In this research group? By just inserting
opinions in the document? This has been the fundamental problem we have had
at HRPC. This group was supposed to be a “research group”. That’s what RG
means! Copy and pasting from other sources without even coming up with
scope and method and just expressing opinion and which will end up in the
document is not research.

On Sat, Dec 18, 2021 at 8:17 PM John Curran <[email-masked]> wrote:

>
> On 18 Dec 2021, at 7:18 PM, farzaneh badii <[email-masked]>
> wrote:
>
> I don't agree. I raised the challenges that legal remedies and attribution
> could have for human rights here but we are at it again.
> I am sure you don't want to add  "legal remedy against blasphemy" as an
> example... so lets cross out defamation.
> I have mentioned it over and over that legal remedy cannot be "greatly
> facilitated" if clear attribution is possible. But maybe we should do
> actual research not to discuss things based on our impressions of things.
> Something I was hoping this group could facilitate.
>
>
> I am unclear what research you believe is required; the present
> difficulties of real-world prosecution due to lack of attribution are quite
> well-known -
>
> *"However, many, including experts in the Internet Society’s discussions,
> raise concerns with the use of digital signatures to enable traceability:*
>
> * • Digital attribution is not absolute and vulnerable to
> impersonation: To establish criminal liability, guilt has to be
> proven beyond reasonable doubt–a threshold that is hard to overcome,
> especially when impersonation online is so easy and pervasive. Proving that
> Person A, the user of Mobile/Computer A, actually sent those messages
> running a disinformation campaign is very difficult to prove even if law
> enforcement has the sender ID. Establishing whether the use of a
> person’s device is necessarily evidence of the person’s use of the device
> requires additional information.[9] Of even greater concern is that
> innocent users’ may be implicated in illegal conduct by cyber criminals
> that impersonate their sender ID. …**”*
>
> *–– Traceability and Cybersecurity* *Experts’ Workshop Series on
> Encryption in India”,  27 Nov 2020, **<**https://www.internetsociety.org/resources/doc/2020/traceability-and-cybersecurity-experts-workshop-series-on-encryption-in-india/
> <https://www.internetsociety.org/resources/doc/2020/traceability-and-cybersecurity-experts-workshop-series-on-encryption-in-india/>>*
>
>
>
> *"**D. Accountability*
>
>
> *Once norms are adopted and implemented there must be accountability for
> those who violate them. This raises the complicated issues of attribution
> and response, both of which have proven challenging in addressing cyber
> attacks.*
>
> *To support a claim that a state or non-state actor has acted wrongfully
> requires credible attribution. This starts with collecting and analyzing
> evidence, and there is both technical and procedural work that can be done
> now to improve the quality and timeliness of attribution. More
> specifically, as with other technical disciplines, having well-accepted
> protocols for collecting and analyzing evidence is important to improving
> the quality of investigations. Thus, the standardization of investigative
> methods is important because it may reduce concerns over the integrity of
> evidence, even if attribution must be decided on a case-by-case basis. In
> addition to improving attribution as a technical matter, there is much that
> can be done to shorten the bureaucratic processes associated with making
> attribution decisions and then, when appropriate, making them public. The
> often long delay between an event and a declaration of responsibility is
> due, in no small part, to unclear or unwieldy processes for reaching such
> decisions at a national level and is exacerbated when several countries are
> involved in making collective attribution statements. Designing and
> exercising processes for reaching attribution at a national level and
> international level, and improving information sharing between countries,
> can significantly improve the timeliness and effectiveness of attribution
> statements and facilitate any further appropriate action.*
>
> *Even after the evidence points to a given actor, the next step
> (attribution) may remain challenging. In the past, some state and non-state
> actors have asserted that attribution is impossible or required absolute
> proof. But absolute proof is not required and while attribution may be
> difficult, it is not as insurmountable as some have suggested. In
> the nation state context, attribution, whether in the cyber or physical
> realm, is often a political act, and while there is no particular agreed
> upon standard of proof, countries still have a strong incentive to not make
> spurious allegations, lest they lose credibility. In short, what is needed
> is for attribution to be convincing to other countries and to the public.*
>
> –– “ ADVANCING CYBERSTABILITY, FINAL REPORT, NOVEMBER 2019”, Global
> Commission on the Stability of Cyberspace, <
> https://cyberstability.org/report/>,
>
>
>
> Or feel free to speak with nearly anyone in law enforcement with regard to
> the present challenges in legal remedy due to lack of attribution… These
> challenges are rather perfectly obvious given the circumstances and have
> been well-documented by the cybersecurity when it comes to post-incident
> remedy and enforcement.
>
> FYI,
> /John
>
> Disclaimer: my views alone.
>
>
>
> --
Farzaneh

---

From: John Curran <[email-masked]>
Date: Wed, 26 Jan 2022 16:30:36 -0500

On 25 Jan 2022, at 8:43 AM, farzaneh badii <[email-masked]> wrote:
> 
> < I am unclear what research you believe is required; the present difficulties of real-world prosecution due to lack of attribution are quite well-known - >
> 
> But should we solve them here? In this research group? By just inserting opinions in the document? This has been the fundamental problem we have had at HRPC. This group was supposed to be a “research group”. That’s what RG means! Copy and pasting from other sources without even coming up with scope and method and just expressing opinion and which will end up in the document is not research.

Farsaneh - 

I did not see the guidelines document as an effort to “solve” anything with regard to the Internet, but rather to serve as a tool to provide protocol developers with guidance that will aid in their understanding of how their protocol decisions can potentially influence the exercise of human rights on the Internet.

One of the human rights impacted by protocol design is access to remedy, and out of completeness I would expect that we’d want to include mention of how some protocol attributes (i.e. lack of attribution and/or anonymity) impacts access to remedy.  This impact is already clearly documented (e.g. review the section of the "Global Commission on the Stability of Cyberspace" report that I cited earlier, or simply attempt yourself to obtain legal remedy against a harm committed anonymously over the Internet) but I do understand that including such a statement in the guidance to protocol developers may be controversial since “access to remedy” is not a particularly popular topic in most academic discussions of human rights.  

Thanks,
/John

Disclaimer: my views alone - free to use/reuse/discard as you see fit.

---

From: Gurshabad Grover <[email-masked]>
Date: Mon, 31 Jan 2022 23:14:08 +0530

Colin, John, Farzaneh, Mallory, Eric: thank you for sharing your 
thoughts on right to remedy/attribution section.

As Niels said, the text of the section was arrived at after much 
discussion, in the hope that it presents group consensus. I think it 
successfully conveys the trade-offs being discussed on this thread. It 
also conveys explicitly to the reader that building in attribution 
mechanisms in a protocol is "most likely not consistent with human rights."

Since it tends towards advocating _against_ attribution, adding an 
example is perhaps not as useful as it is for other sections (and may be 
more contentious than the current text itself). After re-reading all the 
emails on the topic, I am of the opinion that we should leave the text 
as it is.

-Gurshabad

On 1/27/22 03:00, John Curran wrote:
> On 25 Jan 2022, at 8:43 AM, farzaneh badii <[email-masked] 
> <mailto:[email-masked]>> wrote:
>>
>> difficulties of real-world prosecution due to lack of attribution are 
>> quite well-known - >
>>
>> But should we solve them here? In this research group? By just 
>> inserting opinions in the document? This has been the fundamental 
>> problem we have had at HRPC. This group was supposed to be a “research 
>> group”. That’s what RG means! Copy and pasting from other sources 
>> without even coming up with scope and method and just expressing 
>> opinion and which will end up in the document is not research.
> 
> Farsaneh -
> 
>     I did not see the guidelines document as an effort to “solve”
>     anything with regard to the Internet, but rather to serve as a tool
>     to provide protocol developers with guidance that will aid in their
>     understanding of how their protocol decisions can potentially
>     influence the exercise of human rights on the Internet.
> 
>     One of the human rights impacted by protocol design is access to
>     remedy, and out of completeness I would expect that we’d want to
>     include mention of how some protocol attributes (i.e. lack of
>     attribution and/or anonymity) impacts access to remedy.  This impact
>     is already clearly documented (e.g. review the section of the
>     "Global Commission on the Stability of Cyberspace" report that I
>     cited earlier, or simply attempt yourself to obtain legal remedy
>     against a harm committed anonymously over the Internet) but I do
>     understand that including such a statement in the guidance to
>     protocol developers may be controversial since “access to remedy” is
>     not a particularly popular topic in most academic discussions of
>     human rights. 
> 
> 
> Thanks,
> /John
> 
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc

---

From: John Curran <[email-masked]>
Date: Mon, 31 Jan 2022 12:48:36 -0500

Gurshabad - 

	I am fine with whatever outcome the working group decides - I provided some possible example text solely to be responsive to the comment received in the review and it was truly optional in nature. 

Thanks,
/John

Disclaimer: my views alone - Note: made with 100% recycled electrons. 

> On 31 Jan 2022, at 12:44 PM, Gurshabad Grover <[email-masked]> wrote:
> 
> Colin, John, Farzaneh, Mallory, Eric: thank you for sharing your thoughts on right to remedy/attribution section.
> 
> As Niels said, the text of the section was arrived at after much discussion, in the hope that it presents group consensus. I think it successfully conveys the trade-offs being discussed on this thread. It also conveys explicitly to the reader that building in attribution mechanisms in a protocol is "most likely not consistent with human rights."
> 
> Since it tends towards advocating _against_ attribution, adding an example is perhaps not as useful as it is for other sections (and may be more contentious than the current text itself). After re-reading all the emails on the topic, I am of the opinion that we should leave the text as it is.
> 
> -Gurshabad
> 
>> On 25 Jan 2022, at 8:43 AM, farzaneh badii <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>    human rights. Thanks,