Subject: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques"

From: "Christopher Wood" <[email-masked]>
Date: Wed, 20 May 2020 09:59:41 -0700

This is the research group last call for the "A Survey of Worldwide Censorship Techniques" (draft-irtf-pearg-censorship) draft available here:

   https://datatracker.ietf.org/doc/draft-irtf-pearg-censorship/
 
Please review the document and send your comments to the list by June 5, 2020. Feedback may also be sent to the GitHub repository located here:

   https://github.com/IRTF-PEARG/rfc-censorship-tech

Thanks,
Chris, on behalf of the chairs

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 May 2020 12:02:24 +0200

Hi Chris,

Several points.

I have a concern about the use of the term “censorship”.  Is removal of fraudulent material censorship?  How about taking down a system that part of a DOS attack?  Is taking down a system that is attacking critical infrastructure censorship?  Is botnet disruption censorship?  Are FCC frequency rules against harmful interference censorship?  By the sweeping definition given, they are.  This  immediately diminishes the credibility of the work because it flies in the face of what normal people think censorship is.

I would propose a narrower definition, and at least some discussion to make clear that we are all handling double-edged swords.  I don’t think doing this invalidates the content that follows.  Even better would be for you to find a more value-neutral term that acknowledges the nature of the problem, although I would concede that I have no great suggestion.  

Also, it seems to me that a reference check is in order.  If we look at Sections 6.2 and 6.3 the authors are discussing various forms of takedowns, and a reference is made to [Anderson-2011].  To begin with, as a nit, the first person on that work is Murdoch, not Anderson.  Second, the chapter referenced doesn’t go into any detail about take downs.  There are better more specific references such as Moore and Clayton, and specifically “The Impact of Incentives on Notice and Take-down”, WEIS 2008, although I would imagine that there is even later work available.

Finally, did I miss the part where one discusses domain name takedowns by registry, or has that not been used as a form of censorship?

Eliot

---

From: Mallory Knodel <[email-masked]>
Date: Tue, 26 May 2020 13:04:27 -0400

Hi Eliot,

> I have a concern about the use of the term “censorship”.  Is removal of fraudulent material censorship?  How about taking down a system that part of a DOS attack?  Is taking down a system that is a…

It's important to remember two things: Not all governments and decision 
makers operate in good faith, or with the same legal and moral 
frameworks, so the legality of censorship can't be relied upon to define 
what is censorship. Second it is strategic to define censorship as any 
restriction on content so as to raise the cost. Because while there are 
indeed recognized legal, legitimate and proportional reasons why the 
rights to free expression and to access information should be violated, 
censorship measures should not be taken without careful consideration as 
it is a human rights matter.

This is roughly what anyone working on free expression and censorship 
would say and I'm happy to have backup from those folks on this list.

> I would propose a narrower definition, and at least some discussion to make clear that we are all handling double-edged swords.  I don’t think doing this invalidates the content that follows.  Even…

Before responding a re-read the introduction to this draft and I think 
it does an excellent job of framing and narrowing the draft to exactly 
what it does and not more. Well done, Joe!

-Mallory

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 May 2020 21:46:37 +0200

Hi Mallory

> On 26 May 2020, at 19:04, Mallory Knodel <[email-masked]> wrote:
> 
> Hi Eliot,
> 
> It's important to remember two things: Not all governments and decision makers operate in good faith, or with the same legal and moral frameworks, so the legality of censorship can't be relied upon to define what is censorship.

I agree.

> Second it is strategic to define censorship as any restriction on content so as to raise the cost. Because while there are indeed recognized legal, legitimate and proportional reasons why the rights to free expression and to access information should be violated, censorship measures should not be taken without careful consideration as it is a human rights matter.

But the definition in the doc is so broad as to vary substantially from its commonly understood pejorative meaning without any foundation or qualification.  That gives governments license to say, “It’s okay to censor sometimes: it’s necessary for our national defense!”  That is where the definition leads when it includes BOTNET/DOS mitigation.

Eliot

---

From: Mallory Knodel <[email-masked]>
Date: Tue, 26 May 2020 16:37:26 -0400

> But the definition in the doc is so broad as to vary substantially from its commonly understood pejorative meaning without any foundation or qualification.  That gives governments license to say, “…
I prefer this to a government saying, "It's okay because what we're 
doing isn't even considered censorship," which is what happens when we 
get too scared to call some forms of content control what they are: 
censorship.

-Mallory

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 26 May 2020 23:56:53 +0000

(I work for the Internet Society but here represent only myself.)

On May 26, 2020, at 6:02 AM, Eliot Lear <lear=[email-masked]<mailto:lear=[email-masked]>> wrote:

Hi Chris,

Several points.

Thanks, Eliot, I appreciate your review and feedback.

This draft has been through this discussion a few times now. This is a reference document meant to help protocol designers and implementers understand how features of other protocols have been used to block or impair traffic by entities in positions of power — regardless of what the entity is or what the traffic is — so that these designers and implementers can at least design/implement a protocol knowing what they can expect in the wild. The definition of censorship here is pretty generic and I haven’t seen much of an appetite to adopt something different. I want to emphasize what Mallory just said in a message to this thread: entities adversarially messing with information flows is censorship (that is perhaps too pithy for our purposes!).

Ah, will fix to get the order of authors right and you’re right that it doesn’t go into any detail. Here we were looking for something that actually went into physical seizure of server hardware or seizure of entire logical entities (instead of notice and takedown, the next section, which is often directed at individual pieces of content or a single domain on a webserver). I’ll check out the citation above and citations since and see if we can’t get better pointers in there (this section is obviously to be complete and quite svelte).

We can add it if you have citations. Would love a PR of course or suggested text.

Eliot

--
Pearg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/pearg

--
Joseph Lorenzo Hall, Senior Vice President, Strong Internet
[email-masked]<mailto:[email-masked]> | +1-703-483-9504
internetsociety.org<http://internetsociety.org> | @internetsociety
pgp: https://josephhall.org/gpg-key
3CA28D7B9F6DDBD34B1016075F86698740A9A871

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 May 2020 11:47:17 +0200

Hi Joe,

> I want to emphasize what Mallory just said in a message to this thread: entities adversarially messing with information flows is censorship (that is perhaps too pithy for our purposes!).

To me at least, “information flows” immediately improves the situation.  No one can claim that a DOS attack, or a cyberattack of any kind, is an information flow.  One can reasonably argue that spam is not an information flow.  Moreover, the term seems to fit your draft well.

> Ah, will fix to get the order of authors right and you’re right that it doesn’t go into any detail. Here we were looking for something that actually went into physical seizure of server hardware or…

Ok.  That sounds like a classic asset seizure.  It may be worth expanding on how and when physical asset seizure is effective, especially in a cloud-based world.

> We can add it if you have citations. Would love a PR of course or suggested text.

I guess I would suggest starting with the references in guidance-domain-seizures-07mar12-en.pdf <https://www.icann.org/en/system/files/files/guidance-domain-seizures-07mar12-en.pdf>.

Eliot

> 
>> Eliot
>> 
>> -- 
>> Pearg mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.irtf.org/mailman/listinfo/pearg <https://www.irtf.org/mailman/listinfo/pearg>
> 
> -- 
> [email-masked] <mailto:[email-masked]> | +1-703-483-9504
> internetsociety.org <http://internetsociety.org/> | @internetsociety
> pgp: https://josephhall.org/gpg-key <https://josephhall.org/gpg-key>

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 27 May 2020 11:07:03 +0000

Sorry, I didn't mean anything prescriptive by "information flows"... "traffic flows" is better. Sorry for any confusion.
________________________________
From: Eliot Lear <[email-masked]>
Sent: Wednesday, May 27, 2020 5:47:17 AM
To: Joseph Lorenzo Hall <[email-masked]>
Cc: Christopher Wood <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques"

Hi Joe,

I guess I would suggest starting with the references in guidance-domain-seizures-07mar12-en.pdf<https://www.icann.org/en/system/files/files/guidance-domain-seizures-07mar12-en.pdf>.

Eliot

Eliot

internetsociety.org<http://internetsociety.org/> | @internetsociety

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 May 2020 16:53:15 +0200

> On 27 May 2020, at 13:07, Joseph Lorenzo Hall <[email-masked]> wrote:
> 

Then I have to ask my question again: is stopping a DOS attack censorship?

Eliot

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 27 May 2020 15:10:45 +0000

On May 27, 2020, at 10:53 AM, Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:

On 27 May 2020, at 13:07, Joseph Lorenzo Hall <[email-masked]<mailto:[email-masked]>> wrote:

Sure, I don’t see why it couldn’t be. Have you seen Molly Sauter’s book on this? It’s worth checking out: https://www.amazon.com/Coming-Swarm-Hacktivism-Disobedience-Internet/dp/1623564565

I don’t think that’s an important question for this document, however. best, Joe

---

From: Gurshabad Grover <[email-masked]>
Date: Thu, 28 May 2020 05:16:03 +0530

On 5/27/20 2:07 AM, Mallory Knodel wrote:
>>>> I have a concern about the use of the term “censorship”.  Is removal
>>>> of fraudulent material censorship?  How about taking down a system
>>>> that part of a DOS attack?  Is taking down a system that is
>>>> attacking critical infrastructure censorship?  Is botnet disruption
>>>> censorship?  Are FCC frequency rules against harmful interference
>>>> censorship?  By the sweeping definition given, they are.  This 
>>>> immediately diminishes the credibility of the work because it flies
>>>> in the face of what normal people think censorship is.
>>> Second it is strategic to define censorship as any restriction on
>>> content so as to raise the cost. Because while there are indeed
>>> recognized legal, legitimate and proportional reasons why the rights
>>> to free expression and to access information should be violated,
>>> censorship measures should not be taken without careful consideration
>>> as it is a human rights matter.
>> But the definition in the doc is so broad as to vary substantially
>> from its commonly understood pejorative meaning without any foundation
>> or qualification.  That gives governments license to say, “It’s okay
>> to censor sometimes: it’s necessary for our national defense!”  That
>> is where the definition leads when it includes BOTNET/DOS mitigation.
>>

Agree with everything Mallory has said on this thread.

---

From: Amelia Andersdotter <[email-masked]>
Date: Thu, 28 May 2020 08:37:34 +0200

On 2020-05-27 17:10, Joseph Lorenzo Hall wrote:
>>> Sorry, I didn't mean anything prescriptive by "information flows"...
>>> "traffic flows" is better. Sorry for any confusion.
>>
>>
> Sure, I don’t see why it couldn’t be. Have you seen Molly Sauter’s
> book on this? It’s worth checking
> out: https://www.amazon.com/Coming-Swarm-Hacktivism-Disobedience-Internet/dp/1623564565 
>
> I don’t think that’s an important question for this document,

+1

best regards,

Amelia

> however. best, Joe
> internetsociety.org <http://internetsociety.org> | @internetsociety

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 28 May 2020 11:29:32 +0200 (CEST)

> Il 26/05/2020 12:02 Eliot Lear <lear=[email-masked]> ha scritto:
> 

Sorry for missing this thread in the last couple of days. I made this same objection a year ago or so. This pretty maximalist definition of censorship (by the way, sourced from Wikipedia) is IMHO still a big problem with this document. 

Almost no one outside of digital rights activism circles would say that blocking a DDoS attack or taking down a botnet-infected server is censorship. Many would also not say that removing an unlicensed online pharmacy or an illegal gambling website is censorship. Censorship is when communication is blocked based on the opinions it carries - and even in that case, many people actually find some instances of censorship justified, such as blocking terrorist or Nazi propaganda, even in democratic countries. 

I think that the document conflates two things: one is a technical analysis of communication-blocking mechanisms, which can be used for "censorship in the narrow sense" or for other purposes that require interference with communications. Another one is an ethical stance on the fact that these mechanisms are always bad and are to be considered "censorship" in any case. 

The first thing is fine, but the second is not, as then values come into play and there are different views on the subject; and I'm not even sure that deciding whether censorship is good or bad, or what censorship is or is not, fits the charter of this group.

So, I think that the document should use other terms than "censorship" and "censors" everywhere, and add an initial discussion on the fact that there are different purposes for which these techniques are used, and while some people think that they are always bad, and some people (i.e. authoritarian regimes) think that they are always good, the broad majority of the planet would say that they are sometimes bad and sometimes good, requiring a more specific assessment before taking a decision on whether a protocol should support, circumvent or ignore them.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 28 May 2020 11:56:19 +0200

> So, I think that the document should use other terms than "censorship" and "censors" everywhere, and add an initial discussion on the fact that there are different purposes for which these techniqu…

The draft is not a discussion of what is censorship and what is not, it is an overview of censorship techniques. The document clearly defines what definition is uses for censorship, and then uses it to provide an overviews of techniques that are used for it. Seems like a flawless research design. I don't think this draft is the place for a literature review for different defintions and conceptions of censorship.

The draft makes no statements about when or where censorship is appropriate, legitimate, or proportionate. And I don't think it should. We have had the discussion about DDoS etc many times in hrpc, so if people enjoy that discussion, perhaps they can read those archives.

This draft gives an excellent overview of techniques that are used for censorship, which it tremendously helpful. That does not mean that every time an actor engages in censorship these techniques are used, nor that when these techniques are used, it is automatically censorship. 

I am tempted to repreat everything Mallory said before, but I for now I will refrain and just say that I agree with her :)

Cheers,

Niels

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488  
                   643A 0ED8 3F3A 468A C8B3

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 28 May 2020 12:15:34 +0200 (CEST)

> Il 28/05/2020 11:56 Niels ten Oever <[email-masked]> ha scritto:
> 
> The draft makes no statements about when or where censorship is appropriate, legitimate, or proportionate. And I don't think it should.

Except that it calls "censorship" - which is a strongly pejorative term - things that according to many are not, and by doing so, implicitly and without discussion takes a stance that these practices are inappropriate, which is even worse than stating it explicitly with proper supporting arguments.

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 28 May 2020 12:23:10 +0200

> Except that it calls "censorship" - which is a strongly pejorative term - things that according to many are not, and by doing so, implicitly and without discussion takes a stance that these practic…

I don't think it is, it is a descriptive term. The study of censorship regimes is a whole field in political science and communication. With 'censorship regimes' one does not mean authoritarian regimes, but every authority that sets rules, cultural or social norms on the limitation of the dissemination of information. 'Good taste', for example, is also a censorship regime.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 28 May 2020 16:11:56 +0000

On May 27, 2020, at 5:47 AM, Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:
Also, it seems to me that a reference check is in order.  If we look at Sections 6.2 and 6.3 the authors are discussing various forms of takedowns, and a reference is made to [Anderson-2011].  To begin with, as a nit, the first person on that work is Murdoch, not Anderson.  Second, the chapter referenced doesn’t go into any detail about take downs.  There are better more specific references such as Moore and Clayton, and specifically “The Impact of Incentives on Notice and Take-down”, WEIS 2008, although I would imagine that there is even later work available.

I’ve fixed the reference and made sure the text acknowledges it’s an in-passing mention and it now calls out cloud-like situations. See if this works or send edits?

https://github.com/IRTF-PEARG/rfc-censorship-tech/commit/61202f9346876ba8d311c178e632d9333b70ce3c

Ok, that was quite a rabbit hole. I’ve been fascinating by domain seizures for a while now (ever since a legal case called, “The State of Kentucky vs. 141 domain names” where the US state of Kentucky used its own anti-gambling laws to seize the domains of 141 online gambling websites).

I agree that the draft should mention this. Here is my proposal and I’m interested in your (and others’) feedback:

* I’ll add domain registries and registrars as a “point of control” in Section 3.1.
* I’ll add a paragraph to Section 4.1.1 (on DNS Interference) pointing to domain seizures in malware/botnet/spam, anti-fraud, and intellectual property cases.

I wanted to summarize that before actually changing the text and see what folks think.

best, Joe

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 May 2020 18:26:49 +0200

Hi Joe,

> https://github.com/IRTF-PEARG/rfc-censorship-tech/commit/61202f9346876ba8d311c178e632d9333b70ce3c <https://github.com/IRTF-PEARG/rfc-censorship-tech/commit/61202f9346876ba8d311c178e632d9333b70ce3c>

I think that’s fine.

I think there’s a bigger threat that you should probably mention from a non-technical perspective: liability laws.  I don’t know where I came up with that idea!!!

;-)

> I wanted to summarize that before actually changing the text and see what folks think.

It would strengthen your case if you can identify a domain name seizure that is based on what we commonly view as censorship.  Otherwise skip the purpose.

And I would add that we are not quite done with the definition of “censorship”.  I’ve asked for an independent opinion about whether I really am off, but I don’t see a need to continue arguing until I get that view (and I’m sure you don’t see a need to read such an argument!).

Eliot

---

From: Mallory Knodel <[email-masked]>
Date: Thu, 28 May 2020 13:48:23 -0400

On 5/28/20 12:26 PM, Eliot Lear wrote:

> I think there’s a bigger threat that you should probably mention from 
> a non-technical perspective: liability laws.  I don’t know where I 
> came up with that idea!!!

Out of scope for this doc, but yes holy shit.

-M

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 May 2020 19:49:57 +0200

Ah- ok.  Then probably a section title change in Section 6 to clarify.

> On 28 May 2020, at 19:48, Mallory Knodel <[email-masked]> wrote:
>

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 28 May 2020 18:34:27 +0000

Nope.

--
Joseph Lorenzo Hall, Senior Vice President, Strong Internet
[email-masked] | +1-703-483-9504
internetsociety.org | @internetsociety
pgp: https://josephhall.org/gpg-key
3CA28D7B9F6DDBD34B1016075F86698740A9A871
________________________________
From: Eliot Lear <[email-masked]>
Sent: Thursday, May 28, 2020 1:49:57 PM
To: Mallory Knodel <[email-masked]>
Cc: Joseph Lorenzo Hall <[email-masked]>; [email-masked] <[email-masked]>; Christopher Wood <[email-masked]>
Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques"

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 28 May 2020 19:32:16 +0000

We're not going to describe all the non-technical methods of suppressing flows of data and information. Even a comma-separated list would not be terribly useful. I can find some sort of review article but it's bound to be incomplete or have some other default. We felt the need to point out that there is other nuance and pressure points but as the document says it's primarily focused on technical network censorship.

If you brought text, we would is course consider it.

--
Joseph Lorenzo Hall, Senior Vice President, Strong Internet
[email-masked] | +1-703-483-9504
internetsociety.org | @internetsociety
pgp: https://josephhall.org/gpg-key
3CA28D7B9F6DDBD34B1016075F86698740A9A871
________________________________
From: Eliot Lear (elear) <[email-masked]>
Sent: Thursday, May 28, 2020 3:28:56 PM
To: Joseph Lorenzo Hall <[email-masked]>
Cc: Eliot Lear <[email-masked]>; Mallory Knodel <[email-masked]>; [email-masked] <[email-masked]>; Christopher Wood <[email-masked]>
Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques"

Ok so now the use of the term ”non-technical“ is confusing.  If physical seizures are in scope but Legal/economic jeopardy isn’t...

Eliot

On May 28, 2020, at 20:34, Joseph Lorenzo Hall <[email-masked]> wrote:

Nope.

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 28 May 2020 13:21:19 -0700

On Thu, May 28, 2020, at 12:32 PM, Joseph Lorenzo Hall wrote:
>  
> We're not going to describe all the non-technical methods of 
> suppressing flows of data and information. Even a comma-separated list 
> would not be terribly useful. I can find some sort of review article 
> but it's bound to be incomplete or have some other default. We felt the 
> need to point out that there is other nuance and pressure points but as 
> the document says it's primarily focused on technical network 
> censorship.
> 

To try and sharpen this point a bit: this document will certainly have gaps, and it's not a goal to fill all those gaps. This field moves quickly enough that trying to doing so would likely be futile. The chair decision to begin RGLC was based on the document's content and history, which was deemed sufficiently thorough with respect to relevant issues that protocol designers might consider going forward. That said, concrete suggestions to fill in those gaps are welcome! The authors and RG should certainly review them if provided, though we won't block progress waiting for additional content that doesn't substantially change the document's purpose.

Best,
Chris (chair hat on)

---

From: Eliot Lear <[email-masked]>
Date: Fri, 29 May 2020 10:34:13 +0200

Hi Chris,

> To try and sharpen this point a bit: this document will certainly have gaps, and it's not a goal to fill all those gaps. This field moves quickly enough that trying to doing so would likely be futile.

I agree, and I am not suggesting that all gaps be covered.  That was a straw man put forth by the author.

> The chair decision to begin RGLC was based on the document's content and history, which was deemed sufficiently thorough with respect to relevant issues that protocol designers might consider going forward. That said, concrete suggestions to fill in those gaps are welcome! The authors and RG should certainly review them if provided, though we won't block progress waiting for additional content that doesn't substantially change the document's purpose.

I am sorry I didn’t catch this earlier, but I presumed that last call was meant to address these sorts of matters.  I would ask that it be noted that there is not a firm consensus on the document as it stands, as several of us have raised substantial issues.  Were I to explore them outside of this group in the broader IETF or research communities, I feel certain that you would not find consensus over the terminology.  You needn’t take my word for this.

To restate my concerns, there are three major points and one further down that may or may not be a major point:

The definition of censorship itself does not match common usage.
There is no definition of “censorship regime”.
The one reference I checked was clearly not appropriate in its usage, leading me to wonder about the others.

On terminology

It seems that it is being claimed that these are terms of art.  Regardless, a properly justified definition with an appropriate reference is in order.  This has not happened here.  There are two specific problems with the first sentence and its reference.  First, the text doesn’t match the reference given.  It is never appropriate to mislead the reader in this way.  Second, Wikipedia is not a primary source.  It is especially important to get the definition right in interdisciplinary work, especially when we are talking about defining a very politically charged term that the rest of the document is dedicated to ameliorating.  Beyond the academic matter, as I have previously alluded, by not setting that context, the authors risk offending many practitioners dedicated to infrastructure protection in the very first sentence of the first section.

Unless you find fault with my reasoning above, and I readily allow for such a possibility, we must agree that this is an issue.  If you place the onus on me to solve it and I refuse, the issue would remain.  Of course I am happy to be a part of solving the problem.  As it happens, Joe himself put forth a perfectly fine way to put the work into context, to which I readily agreed, but then he himself rejected, even though what he proposed is a close variant of what appears in the document’s abstract.  The substance here is the difference between “content" and “information” and perhaps motivation.  I am not suggesting a full exploration of what censorship is, but some justification for the language.  Same for “censorship regime”, given its similar negative connotations.

On references

We have previously seen sloppy use of references in at least one other RG.  By chance, I have spotted two errors, one to the WP reference and the other only because I know one of the authors of the referenced work.  I have not checked the others, but the pass rate right now is 0/2.  I would strongly suggest that the other references be checked through broader review.

Adding the additional non-technical example

On “Non-Technical [Prescription/Interference]”.  As I wrote above, I don’t expect the authors to be exhaustive, but I am told that the topic is out of scope, and yet the text remains.  I would suggest an add, perhaps around “swaying public thought”, to include something like “adding financial liability”.  The reason I think the point is important enough to raise is that from a scale perspective, the financial attack may be the most effective attack of all against profit-based platforms.  Is it major or minor?  I don’t know.  I lean toward “minor” only because the document might stand up without its mention, even though I would view it as an opportunity lost.

Eliot

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 29 May 2020 11:01:35 +0200

On 5/29/20 10:34 AM, Eliot Lear wrote:
>   * The definition of censorship itself does not match common usage.

I disagree. Saying something doesn't match common usage, or common sense, it easy to say but very hard to show. To define what censorship is, is not what the authors set out to do, and I don't think we can reasonably ask it of them. 

>   * There is no definition of “censorship regime”.

I don't think that is needed because this is not a literature review on censorship. The study provides a definition and implements it. Very typical for a survey study. Else you will have a chicken and egg situation: should the definition depend on empirical evidence, but how to do case selection without a definition?

>   * The one reference I checked was clearly not appropriate in its usage, leading me to wonder about the others.

We should not depend on it, but this is also fully checked in the RFC editor process.

Best,

Niels

---

From: Lars Eggert <[email-masked]>
Date: Fri, 29 May 2020 13:14:52 +0300

Hi,

> It would strengthen your case if you can identify a domain name seizure that is based on what we commonly view as censorship.  Otherwise skip the purpose.

I don't know who "we" here is, but there are certainly many cases where domain names have been seized that *some* consider censorship. For example: https://www.eff.org/deeplinks/2017/09/cat-domain-casualty-catalonian-independence-crackdown

Lars

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 29 May 2020 12:48:20 +0200 (CEST)

> Il 28/05/2020 12:23 Niels ten Oever <[email-masked]> ha scritto:
> 

Unfortunately, this is not how the word "censorship" is used outside of that small circle, and it is not how it will be perceived by people in the broader Internet governance environment when reading this document. There seems to be a clear disconnect in the perception of these terms between different audiences. So, to avoid misunderstandings, the document could rather just focus on describing techniques for content access control and removal without calling them names.

> Il 29/05/2020 12:14 Lars Eggert <[email-masked]> ha scritto:
> 

That's exactly the problem: mention that in this document as "censorship", and the document will (or, at least, will appear to) be a declaration of support for those that think that that behaviour is censorship, against those that think that it is not censorship (which include the national Spanish government and the European Union). We can try to tell the Spanish government that we are using "censorship" in the strictly academic sense of "enforcement of court rulings on online content", but I don't know how well this would fly.

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 29 May 2020 13:08:11 +0200

On 5/29/20 12:48 PM, Vittorio Bertola wrote:
> Unfortunately, this is not how the word "censorship" is used outside of that small circle, and it is not how it will be perceived by people in the broader Internet governance environment when reading this document. 

What is you method of knowing how the term is understood in 'the Internet governance environment'? Are the authors not part of that as well? Seem quite a big claim to make.

There seems to be a clear disconnect in the perception of these terms between different audiences. So, to avoid misunderstandings, the document could rather just focus on describing techniques for content access control and removal without calling them names.
> That's exactly the problem: mention that in this document as "censorship", and the document will (or, at least, will appear to) be a declaration of support for those that think that that behaviour…

This document does not say that every time such a technique is used, it is called censorship. It also does not say whether it is right or wrong.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 29 May 2020 15:23:27 +0200

Hi Lars,

> I don't know who "we" here is, but there are certainly many cases where domain names have been seized that *some* consider censorship. For example: https://www.eff.org/deeplinks/2017/09/cat-domain-…

That, to me, is a far better reference for several reasons:

It’s a clear attempt to interfere with information exchange by a government (that really ticks all the boxes for all the definitions I’ve seen).
It demonstrates both a physical seizure and a domain seizure.

Nice one!

Eliot

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 29 May 2020 07:30:03 -0700

Hi Eliot,

Please see inline below.

> straw man put forth by the author.

Great!

> I am sorry I didn’t catch this earlier, but I presumed that last call 
> was meant to address these sorts of matters. 

Indeed it is! I didn't mean to imply that other comments raised were not up for discussion. On the contrary, I think they're helpful contributions that can help improve the document. 

> I would ask that it be 
> noted that there is not a firm consensus on the document as it stands, 
> as several of us have raised substantial issues. Were I to explore them 
> outside of this group in the broader IETF or research communities, I 
> feel certain that you would not find consensus over the terminology. 
> You needn’t take my word for this.
> 
> To restate my concerns, there are three major points and one further 
> down that may or may not be a major point:
> 
>  * The one reference I checked was clearly not appropriate in its 
> usage, leading me to wonder about the others.
> 
> On terminology
> 
> It seems that it is being claimed that these are terms of art. 
> Regardless, a properly justified definition with an appropriate 
> reference is in order. This has not happened here. There are two 
> specific problems with the first sentence and its reference. First, the 
> text doesn’t match the reference given. It is never appropriate to 
> mislead the reader in this way. Second, Wikipedia is not a primary 
> source. It is especially important to get the definition right in 
> interdisciplinary work, especially when we are talking about defining a 
> very politically charged term that the rest of the document is 
> dedicated to ameliorating. Beyond the academic matter, as I have 
> previously alluded, by not setting that context, the authors risk 
> offending many practitioners dedicated to infrastructure protection in 
> the very first sentence of the first section.
> 
> Unless you find fault with my reasoning above, and I readily allow for 
> such a possibility, we must agree that this is an issue.  If you place 
> the onus on me to solve it and I refuse, the issue would remain. Of 
> course I am happy to be a part of solving the problem. As it happens, 
> Joe himself put forth a perfectly fine way to put the work into 
> context, to which I readily agreed, but then he himself rejected, even 
> though what he proposed is a close variant of what appears in the 
> document’s abstract. The substance here is the difference between 
> “content" and “information” and perhaps motivation. I am not suggesting 
> a full exploration of what censorship is, but some justification for 
> the language. Same for “censorship regime”, given its similar negative 
> connotations.

With no hat on, I mostly agree. I'll take a stab at addressing this in a PR and share it on the list. We can iterate on the details there. :-)

> On references
> 
> We have previously seen sloppy use of references in at least one other 
> RG. By chance, I have spotted two errors, one to the WP reference and 
> the other only because I know one of the authors of the referenced 
> work. I have not checked the others, but the pass rate right now is 
> 0/2. I would strongly suggest that the other references be checked 
> through broader review.

Yep, these too are good issues to raise now. I'll file an issue to review all references carefully before progressing. 

> On “Non-Technical [Prescription/Interference]”. As I wrote above, I 
> don’t expect the authors to be exhaustive, but I am told that the topic 
> is out of scope, and yet the text remains. I would suggest an add, 
> perhaps around “swaying public thought”, to include something like 
> “adding financial liability”. The reason I think the point is important 
> enough to raise is that from a scale perspective, the financial attack 
> may be the most effective attack of all against profit-based platforms. 
> Is it major or minor? I don’t know. I lean toward “minor” only because 
> the document might stand up without its mention, even though I would 
> view it as an opportunity lost.

If you have time, could you please suggest concrete text (ideally in the form of a PR)? I think that'll make this discussion easier. 

Thanks again for your review, feedback, and help improving the document!

Best,
Chris

---

From: Eliot Lear <[email-masked]>
Date: Fri, 29 May 2020 16:52:27 +0200

Chris,

Thanks for your response.  I appreciate it.  With regard to this:

> On 29 May 2020, at 16:30, Christopher Wood <[email-masked]> wrote:
> 

I will try to do this by mid-next week (it’s a holiday weekend here in Switzerland).

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 May 2020 08:38:40 -0700

On Tue, May 26, 2020 at 3:02 AM Eliot Lear <lear=[email-masked]>
wrote:

> Hi Chris,
>
> Several points.
>
> I have a concern about the use of the term “censorship”.  Is removal of
> fraudulent material censorship?  How about taking down a system that part
> of a DOS attack?  Is taking down a system that is attacking critical
> infrastructure censorship?  Is botnet disruption censorship?  Are FCC
> frequency rules against harmful interference censorship?  By the sweeping
> definition given, they are.  This  immediately diminishes the credibility
> of the work because it flies in the face of what normal people think
> censorship is.
>

Ignoring the term "censorship" for a moment, it seems to me that there are
two broad content-neutral categories:

- Preventing two (or more entities) who want to communicate from doing so
- Preventing an entity who wants to communicate with an unwilling peer or
peers

A number of the examples you cite (DoS, attacks) fall into the second
category and I don't think that they should be swept in here, not only
because they are different from a political economy perspective but because
they often, though not always, involve different technical mechanisms.

You cite two other examples which seem like they might be more difficult:
(1) fraudulent material and (2) frequency regulations. In both cases,
whether they are censorship actually depends on how they are executed. To
take the frequency regulations example first, if the government sets up
frequency regulations that prevent people from communicating *at all* then
potentially that is censorship. In the US this often gets framed as "time
place and manner" versus "content" restrictions. However, I don't think
this definition would necessarily sweep that in.

Fraudulent material (and malware downloads, etc.) seem like more
interesting cases, but i think there's a way to think of them as the
receiver of the communication not really wanting to receive them if they
were fully informed. And I think there's a pretty strong argument that if
it is made impossible to access this data (as opposed to preventing it from
being automatically processed) than that is in fact an example of
censorship.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 May 2020 10:28:59 -0700

Document: draft-irtf-pearg-censorship-03.txt

S 2.
    We describe three elements of Internet censorship: prescription,
    identification, and interference.  The document contains three major
    sections, each corresponding to one of these elements.  Prescription
    is the process by which censors determine what types of material they
    should block, i.e., deciding to block a list of pornographic
    websites.  Identification is the process by which censors classify
    specific traffic to be blocked or impaired, i.e., blocking or
    impairing all webpages containing "sex" in the title or traffic to
    www.sex.example.  Interference is the process by which censors

I'm not finding this distinction super clear. It seems to me like
deciding to block www.sex.example and "impairing...traffic to
www.sex.example" are pretty similar.

Not trying to force a new model on you, but I tend to think of this
process as:

1. Decide what kind of material you want to block (e.g., material about
   sex). [This is what I expected prescription to be]

2. Determine what the conceptual indicia of that material are (this might
   be "contains the string sex" or "is one of these websites A, B, C")

3. Determine precisely how you identify the indicia on the network
   (DNS, SNI, etc.)

4. Determine how to block the communications once identified.

S 3.1.
   Internet censorship necessarily takes place over a network.  Network

You say this but then later you give an example of endpoint censorship.

I feel like this section might be better if it tried to impose some
hierarchy here. From my perspective, there are four main categories
of control points:

- The network itself [ISPs, Backbone, Institutional ISPs]
- The services side of communications [hosting providers, cloud
  providers, CDNs, etc.]
- Services which are necessary to communicate but not really
  part of it [CAs, DNS, etc.]
- The client endpoint side

That might make this easier to read

    o  Certificate Authorities for Public-Key Infrastructures (PKIs):
       Authorities that issue cryptographically secured resources can be
       a significant point of control.  Certificate Authorities that
       issue certificates to domain holders for TLS/HTTPS (the Web PKI)
       or Regional/Local Internet Registries (RIRs) that issue Route
       Origination Authorizations (ROAs) to BGP operators can be forced
       to issue rogue certificates that may allow compromise, i.e., by
       allowing censorship software to engage in identification and
       interference where not possible before.  This may allow, for
       example, adversarial traffic routing or TLS interception.

This is true, though CT is intended to make this much harder. I would
add that CAs can be forced to revoke certificates, which is a threat
that CT does not attempt to prevent.

    o  Services: Application service providers can be pressured, coerced,
       or legally required to censor specific content or data flows.
       Service providers naturally face incentives to maximize their
       potential customer base and potential service shutdowns or legal
       liability due to censorship efforts may seem much less attractive
       than potentially excluding content, users, or uses of their
       service.  Services have increasingly become focal points of
       censorship discussions, as well as the focus of discussions of
       moral imperatives to use censorship tools.

It's a little hard to know if this text is talking about Facebook
or AWS. Maybe split?

      At all levels of the network hierarchy, the filtration mechanisms
      used to detect undesirable traffic are essentially the same: a censor
      either directly sniffs transmitting packets and identifies
      undesirable content, and then uses a blocking or shaping mechanism to
      prevent or impair access, or requests that an actor ancillary to the
      censor, such as a private entity, perform these functions.

I don't think this claim is right. For instance where do registry
takedowns or DNS blacklists fit in. Neither of them "directly sniffs
transmitting packets" (a weird phrase as-is).

S 3.2.1.
   Tradeoffs: Request Identification is a technically straight-forward
   identification method that can be easily implemented at the Backbone
   or ISP level.  The hardware needed for this sort of identification is
   cheap and easy-to-acquire, making it desirable when budget and scope
   are a concern.  HTTPS will encrypt the relevant request and response
   fields, so pairing with transport identification (see Section 3.3.1)
   is necessary for HTTPS filtering.  However, some countermeasures such

I think you just want to remove "such"

   can trivially defeat simple forms of HTTP Request Header
   Identification.  For example, two cooperating endpoints - an
   instrumented web server and client - could encrypt or otherwise
   obfuscate the "host" header in a request, potentially thwarting
   techniques that match against "host" header values.

This is true, but seems kinda limited.

3.2.4.1.

   In encrypted connections using Transport Layer Security (TLS), there
   may be servers that host multiple "virtual servers" at a given
   network address, and the client will need to specify in the
   (unencrypted) Client Hello message which domain name it seeks to
   connect to (so that the server can respond with the appropriate TLS
   certificate) using the Server Name Indication (SNI) TLS extension
   [RFC6066].  Since SNI is often sent in the clear, censors and

I understand that the cert field is also used for blocking.

   Domain fronting has been one popular way to avoid identification by
   censors [Fifield-2015].  To avoid identification by censors,
   applications using domain fronting put a different domain name in the
   SNI extension than the one encrypted by HTTPS.  The visible SNI would
   indicate an unblocked domain, while the blocked domain remains hidden

I would say "than in the Host: header, which is protected by HTTPS"

S 3.3.1.

   Of the various shallow packet inspection methods, Transport Header
   Identification is the most pervasive, reliable, and predictable type
   of identification.  Transport headers in TCP/IP or QUIC contain a few
   invaluable pieces of information that must be transparent for traffic
   to be successfully routed: destination and source IP address and
   port.  Destination and Source IP are doubly useful, as not only does
   it allow a censor to block undesirable content via IP blocklisting,

Saying "TCP/IP or QUIC" is weird as QUIC runs over UDP. And of course
UDP has its own headers, as does RTP. I would just say "Transport headers"

   Header identification is trivial to implement, but is difficult to
   implement in backbone or ISP routers at scale, and is therefore
   typically implemented with DPI.  Blocklisting an IP is equivalent to

Does this mean "using DPI" or "along with DPI"

   Header identification is trivial to implement, but is difficult to
   implement in backbone or ISP routers at scale, and is therefore
   typically implemented with DPI.  Blocklisting an IP is equivalent to
   installing a /32 route on a router.  However, due to limited flow

The IPv6 people will be mad.

   Port-blocking is generally not useful because many types of content
   share the same port and it is possible for censored applications to
   change their port.  For example, most HTTP traffic goes over port 80,
   so the censor cannot differentiate between restricted and allowed web
   content solely on the basis of port.  Another example is HTTPS port
   443, which in addition to handling secure web traffic now also
   carries DNS-over-HTTPS [RFC8484] traffic; this can frustrate
   techniques that rely on cleartext DNS over port 53 for censorship,
   parental control, and other uses [SSAC-109-2020].  Port allowlisting

True, but I feel like this is actually a different category of thing,
because *this* section is about shallow blocking, whereas DNS-based
blocking of specific domains is definitely not shallow.

   conjunction with other identification mechanisms.  For example, a
   censor could block the default HTTPS port, port 443, thereby forcing
   most users to fall back to HTTP.  An important counter-example is
   that port 25 (SMTP) has long been blocked on residential ISPs'
   networks, ostensibly to reduce the potential for email spam, but also
   prohibiting residential ISP customers to run their own email servers.

This "ostensibly" seems unnecessarily sarcastic. It's not clear
why ISPs would care that much (price discrimination?). Anyway,
if you want to make this point, I think you could say something
more netural which had the same impact.

S 3.3.2.
I'm having trouble with your taxonomy here because a lot of the
protocol identification work seems like it's more application
layer than transport layer, but you have it in 3.3.

S 4.1.1.
There is some good text in this section, but I feel like it's
not doing a good job of distinguishing three attack modalities:

- Lying by the nameserver
- On-path interception by an attacker
- off-path cache poisoning

This has been such a persistent point of confusion with DoH that
I think it's worth clarifying.

>   than ideal censorship mechanism.  Additionally, the above mechanisms
>   rely on DNSSEC not being deployed or DNSSEC validation not being
>   active on the client or recursive resolver (neither of which are hard
>   to imagine given limited deployment of DNSSEC and limited client
>   support for DNSSEC validation).

This is not quite correct. If you want to redirect a user then you
need to content with DNSSEC, but if you just want to block them,
then you can just provide a record which won't validate and that
will have the same effect.

S 4.2.2.
I note that packet dropping is often how you implement traffic
shaping.

S 4.2.3.
   Packet injection, generally, refers to a man-in-the-middle (MITM)
   network interference technique that spoofs packets in an established
   traffic stream.  RST packets are normally used to let one side of TCP
   connection know the other side has stopped sending information, and
   thus the receiver should close the connection.  RST Packet Injection
   is a specific type of packet injection attack that is used to
   interrupt an established stream by sending RST packets to both sides
   of a TCP connection; as each receiver thinks the other has dropped
   the connection, the session is terminated.  QUIC is not vulnerable to
   these types of injection attacks (See [I-D.ietf-quic-transport] for
   more details).

This isn't totally true. QUIC is not vulnerable to this once the
connection is set up, but it *is* vulnerable during setup.

The two paragraphs in Trade-offs are confusing because you don't
start out with the threat model. There are three threat models
here:

- On-path and fast
- On-path and slow
- Off-path

In general, the argument you seem to be making is that on-path
and fast is expensive but on-path and slow is cheap. I'm not
sure the Blind injection stuff is that relevant: you would
need to know the host/port coordinates which are fairly expensive
to obtain. Do we know if anyone uses totally blind RSTs
for censorship? My impression is that it's primarily useful
for long running connectons like BGP.

S 4.3.2.

   Trade-offs: The impact to a network disconnection in a region is huge
   and absolute; the censor pays for absolute control over digital
   information with all the benefits the Internet brings;

This seems backwards. You pay by losing all the benefits.

   this is never
   a long-term solution for any rational censor and is normally only
   used as a last resort in times of substantial unrest.

This seems unnecessarily judgemental. What's rational depends on
incentives.

Also, this section seems weird because it doesn't talk about
fake BGP announcements for *other* sites, which we know is
common and doesn't have anywhere near the impact yoou discuss
here.

S 6.
I would remove this entirely. I don't think it really belongs

-Ekr

On Wed, May 20, 2020 at 10:00 AM Christopher Wood <[email-masked]>
wrote:

> This is the research group last call for the "A Survey of Worldwide
> Censorship Techniques" (draft-irtf-pearg-censorship) draft available here:
>
> Please review the document and send your comments to the list by June 5,
> 2020. Feedback may also be sent to the GitHub repository located here:
>
> [email-masked]

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 29 May 2020 17:36:58 +0000

Thank you for the review, EKR. I'll work through these and put them in issues in the repo as I do, likely not until next week.

--
Joseph Lorenzo Hall, Senior Vice President, Strong Internet
[email-masked] | +1-703-483-9504
internetsociety.org | @internetsociety
pgp: https://josephhall.org/gpg-key
3CA28D7B9F6DDBD34B1016075F86698740A9A871
________________________________
From: Pearg <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Sent: Friday, May 29, 2020 1:28:59 PM
To: Christopher Wood <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Pearg] Research Group Last Call for "A Survey of Worldwide Censorship Techniques"

S 2.

S 3.1.

       to issue rogue certificates that may allow compromise, i.e.., by

S 3.2.1.

3.2.4.1.

S 3.3.1.

S 3.3.2.

S 4.1.1.

S 4.2.2.

S 4.2.3.

- On-path and fast
- On-path and slow
- Off-path

S 4.3.2.

   this is never

S 6.

-Ekr

On Wed, May 20, 2020 at 10:00 AM Christopher Wood <[email-masked]<mailto:[email-masked]>> wrote:
This is the research group last call for the "A Survey of Worldwide Censorship Techniques" (draft-irtf-pearg-censorship) draft available here:

Thanks,

---

From: Mallory Knodel <[email-masked]>
Date: Fri, 29 May 2020 13:42:53 -0400

Hi,

> I would remove this entirely. I don't think it really belongs

I would disagree that it should be removed. It doesn't entirely fit with 
everything else, but it's correctly signposted as such, and omitting the 
concepts treated in this section would leave gaps difficult to bear if 
this draft is meant to be comprehensive for the IETF/IRTF audience.

-Mallory

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 May 2020 10:52:42 -0700

Sorry, I meant that we should remove 6.1. I agree that 6.2 and 6.3 continue
to belong. To be clear, i agree that self-censorship is a thing, I just
don't think it really makes that much sense in this doc

-Ekr

---

From: Mallory Knodel <[email-masked]>
Date: Fri, 29 May 2020 14:00:28 -0400

That's better, thanks for clarifying.

I would still advocate for it to stay, simply because "self" can be 
broadly interpreted. In short, self-censorship is a knock-on effect of 
more direct forms of censorship, or a cumulative context of censorship, 
and relates to this community in two ways: helps understand what's 
called "the chilling effect," and somehow relates to the maxim of 
"be[ing] conservative in what you send".

-Mallory

On 5/29/20 1:52 PM, Eric Rescorla wrote:
> Sorry, I meant that we should remove 6.1. I agree that 6.2 and 6.3 
> continue to belong. To be clear, i agree that self-censorship is a 
> thing, I just don't think it really makes that much sense in this doc
>
> -Ekr
>
>
> On Fri, May 29, 2020 at 10:43 AM Mallory Knodel <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     <https://www.irtf.org/mailman/listinfo/pearg>
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 May 2020 11:06:04 -0700

Thanks for your response. I'm not going to lie down in the road over this,
but let me make one more attempt.

First let me say that I strongly agree that this is a real effect and that
it's a commonly used form of controlling speech. My concern about having it
here is merely that it seems like there are a wide variety of social
controls on behavior and thought of which this is just one. I think it
would be cleaner to focus this draft on the technical side of how
governments prevent people who are trying to speak from being able to,
rather than to get into the myriad ways in which people are discouraged
from speaking.

However, if this isn't persuasive then that's fine. I leave it to the
chairs and authors to manage this feedback.

-Ekr

On Fri, May 29, 2020 at 11:00 AM Mallory Knodel <[email-masked]> wrote:

> broadly interpreted. In short, self-censorship is a knock-on effect of more
> direct forms of censorship, or a cumulative context of censorship, and
> relates to this community in two ways: helps understand what's called "the
> chilling effect," and somehow relates to the maxim of "be[ing] conservative
> in what you send".
>
> -Mallory
> continue to belong. To be clear, i agree that self-censorship is a thing, I
> just don't think it really makes that much sense in this doc
>
> -Ekr
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 30 May 2020 09:41:11 +0200

On 2020-05-29, at 13:08, Niels ten Oever <[email-masked]> wrote:
> 
> This document does not say that every time such a technique is used, it is called censorship.

That’s not what the title suggests.

“Censorship techniques” to me strongly suggests it is about techniques specifically applied for censorship.  Maybe that misunderstanding is easily fixed, e.g. “techniques employed for censorship”.

> It also does not say whether it is right or wrong. 

Outside of a small set of people who have really thought about the problem (and probably even among those), “censorship” is a rather pejorative term; it always applies wrongdoing in common usage.

That is why it usually is reserved for state-controlled suppression of information, and typically only for those cases where that suppression is not necessitated by violation of other basic rights.

On 2020-05-27, at 01:56, Joseph Lorenzo Hall <[email-masked]> wrote:
> 
> entities adversarially messing with information flows is censorship

That is certainly not a definition that comes to mind among intellectuals in my country, many of which would have a hard time with categorizing, e.g., privacy laws under censorship (unless they are actually also employed for censorship, but I don’t want to open the whole can here).

I’m writing this because I think such a document is very useful, and I don’t want to see it devalued by terminology that will be seen by many as distorted beyond recognition by mindless activism.

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Sat, 30 May 2020 17:52:20 +0200

Mallory,

I wanted to come back to something you wrote:

> Because while there are indeed recognized legal, legitimate and proportional reasons why the rights to free expression and to access information should be violated, censorship measures should not be taken without careful consideration as it is a human rights matter.

Regardless of the terminology, it seems to me that there is another aspect that the document could capture that is related to the IETF.  In the introduction, the authors write:

   There is also a growing field of
   academic study of censorship circumvention (see the review article of
   [Tschantz-2016]), results from which we seek to make relevant here
   for protocol designers and implementers.
I wonder if it would be good to elaborate this.  Be a bit more explicit as to what the relevancies are.  Are these cautionary tales for instance, wherein some cases the use of the technology for censorship was not what the engineers had in mind?  How would you like engineers to evaluate technology tradeoffs?
This allows us to address one additional point that I’d suggest the RG to consider:  the document motivation could be strengthened.  Why is this document important?  Who is it relevant to?  This might also explain why there is no conclusion or desired next steps.  Good that they've enumerated various mechanisms.  Would they like the IETF to review those points with an eye toward avoiding inadvertent avenues to additional censorship?  What if anything would be good for PEARG to follow up?  I’m not suggesting many paragraphs, but one or two wouldn’t be out of line.
Eliot

---

From: David Oliver <[email-masked]>
Date: Sat, 30 May 2020 15:11:30 -0400

> Be a bit more explicit as to what the relevancies are.

I was actually wondering the opposite: Why *are* circumvention methods
mentioned in this document?  Should I work on the assumption that "why" was
hashed out in discussion of earlier drafts?

David

David M. Oliver | david@g <[email-masked]>uardianproject.info |
http://g <http://olivercoady.com>uardianproject.info | @davidmoliver | +1
970 368 2366

On Sat, May 30, 2020 at 11:52 AM Eliot Lear <lear=[email-masked]>
wrote:

> Because while there are indeed recognized legal, legitimate and
> proportional reasons why the rights to free expression and to access
> information should be violated, censorship measures should not be taken
> without careful consideration as it is a human rights matter.
>
>
> Regardless of the terminology, it seems to me that there is another aspect
> that the document could capture that is related to the IETF.  In the
> introduction, the authors write:
>