Subject: Re: [Pearg] descriptive censorship work: draft-hall-censorship-tech

From: Shivan Sahib <[email-masked]>
Date: Thu, 16 May 2019 19:23:40 -0700

Hi Joe!

Chris, you and I have talked about this offline, but just to close that
loop, I would personally like to see this draft in PEARG. We can discuss
whether we want to keep this a regularly-updated-draft or something else in
the RG meeting at IETF 105 (we can do a short presentation, if you're
interested).

One thing that would be good to see more of in the draft would be technical
ways to get around censorship by using privacy-preserving technology. That
discussion definitely does not have to be exhaustive!

Thanks,
Shivan

On Tue, Mar 26, 2019 at 1:46 AM Joseph Lorenzo Hall <[email-masked]> wrote:

> (Bcc'ing SECDISPATCH and SAAG as an FYI; thread on PEARG)
>
> Hello, apologies for cross-posting.
>
> At IETF 91 in 2014 we presented some very early work before SAAG that
> describes how global censors use protocols to censor data flows (block,
> impair, modify, etc.). After some editing in subsequent years based on
> superb feedback from SAAG folks (Stephane B., Andrew M., thank you!) we had
> tentative AD sponsorship and some thoughts that this was better on the IETF
> side of the house rather than in a RG.
>
> We've started to work on it again* and since the original draft we now
> have SECDISPATCH to help "the misfit toys of security" find a home in terms
> of IETF process... I very briefly described this work yesterday in
> SECDISPATCH and Chris Wood, the new PEARG co-chair, suggested that PEARG
> would be a good place for this work since part of what they would like to
> do in that RG is document certain privacy-implicating things in the real
> world.
>
> We don't really have a preference where this ends up -- there's even a
> case to be made that given the dynamic nature of censorship that this will
> necessarily always be a work in progress. We have heard people find it
> useful and PEARG seems as good as anywhere, and obviously the process to
> get to an RG RFC would help it get better (at least that is my impression!).
>
> Here is the current version of the draft and the repo we're using to track
> issues and version the doc:
>
> draft: https://tools.ietf.org/html/draft-hall-censorship-tech-07
> repo: https://github.com/josephlhall/rfc-censorship-tech
>
> Would love to hear if this is something people think PEARG would like to
> work on and we have some ideas about additional documents in a series like
> this (e.g., having some real-world descriptive reference on research and
> practice in terms of traffic analysis could be really useful for IETF
> folks, I suspect.)
>
> Cheers! --Joe Hall
>
> (copying two co-authors, Stan from CDT and Nick from Princeton)
>
> * IASA2 has been a big focus of my own for the last two years.
>
> --
> Joseph Lorenzo Hall
> Chief Technologist, Center for Democracy & Technology [https://www.cdt.org
> ]
> 1401 K ST NW STE 200, Washington DC 20005-3497
> e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
> Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
>
> Don't miss out! CDT's Tech Prom is April 10, 2019, at The
> Anthem. Please join us: https://cdt.org/annual-dinner/
> --
> Pearg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/pearg
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 May 2019 08:58:01 +0100

Hiya,

On 17/05/2019 03:23, Shivan Sahib wrote:
> loop, I would personally like to see this draft in PEARG.

+1

> We can discuss

Personally, I'd prefer to see the thing just finished as
soon as possible. A presentation for that is no harm, but
not really needed IMO. My argument for that is that an
RFC on this topic could be informative for protocol
designers, whereas the draft hasn't been so far (at least
afaik). Telling someone to go read and think about RFCnnnn
is more likely to be effective than explaining the status
of draft-hall-* I reckon.

> discussion definitely does not have to be exhaustive!

-1 to extending the scope. That could be done in other
documents, each of which would likely take some time. FWIW,
personally, I'd recommend just getting this one to the
RFC editor queue, pocketing the progress, and then the RG
can move on to new documents documenting other mechanisms
for and countering censorship.

Cheers,
S.

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 17 May 2019 12:00:03 +0200 (CEST)

> Il 17 maggio 2019 09:58 Stephen Farrell <[email-masked]> ha scritto:
> 
> > We can discuss

First of all, thanks for bringing up this document again, as I had read it quickly and even promised the authors some feedback on the DNS section, which however I never did (apologies).

Now I had the time to go through it a little more in depth, and I must say I have broader issues with it.

First of all, the document assumes that any content control is censorship. By the definition in section 1, even blocking the connection from a bot to its C&C center is censorship. That's way too broad.

The basic problem is that many of these techniques are also used for positive reasons, which makes it difficult to determine how to deal with them at the technical level, as any counter-technique that makes them impossible is bound to also disrupt those positive uses, creating problems to their users (see the DoH debate). 

If this is meant as possible guidance to protocol designers, it should be clear that there are policy impact evaluations to be made when designing anything that affects these points of control in one way or the other, possibly involving non-technical stakeholders in the discussion. There is a whole set of nuances and complex tradeoffs in this field, yet I don't see this in the document - it looks like a simplified, biased view of the problem that considers any content control technique negative in itself.

Also, some wording seems to assume that only public authorities are censors. In the description in section 3.1, there are statements like "Application service providers can be pressured, coerced, or legally required to censor specific content or flows of data.", or in section 3.2.3, "In addition to censorship by the state, many governments pressure content providers to censor themselves." 

But there are also cases in which Internet platforms decide to block stuff on their own, for their own business interests or company views (example: I don't think Facebook is censoring breastfeeding images due to any legal requirement or governmental pressure). In democratic countries, this is the kind of censorship that currently creates more concerns, as any legally mandated censorship comes from the democratic process and usually has at least some degree of scrutiny and transparence, while citizens have no way of controlling or even influencing the policies of a private company operating in another jurisdiction, and these policies are usually very intransparent. This kind of practices do not seem to be considered in section 3 (and by the way, there is one more point of control, client applications, which is not even mentioned).

I also find section 3 confusing in itself, since 3.1 is a list of actors and use cases, while the other sections are about technical points where information on content could be found. Perhaps 3.1 should become a section of its own, and there should be a much more nuanced discussion of the problem, before getting into the technicalities of how control can be technically applied.

Also I'm not sure about section 6 - the document is supposed to be about technical mechanisms, so what's the meaning of a "non-technical interference" section? But if you want to keep it, then there's lots of stuff missing, starting from, for example, Internet platforms shutting down accounts of people they don't like. 

A couple of weeks ago, for example, Facebook blocked the account of a European elections candidate that happened to be a descendant of Mussolini. A couple of days ago, Facebook shut down 23 pages in Italy that supported the government parties, for spreading "fake news" that, according to those who were posting them, were not fake at all. I'm not arguing that this was bad behaviour by them, but these are indeed cases of silencing someone for their political views, yet I don't see where this kind of things are covered in this document.

So, in the end: IMHO either this is made strictly technical, only describing technologies that can be used to identify and block content without assuming whether such activity is good or bad, and giving up all the non-technical bits and judgements; or it requires broadening the viewpoints and the cases it covers.

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

---

From: Shivan Sahib <[email-masked]>
Date: Fri, 17 May 2019 14:00:42 -0700

Hi Stephen,

On Fri, May 17, 2019 at 12:58 AM Stephen Farrell <[email-masked]>
wrote:

> ...

The suggestion to include censorship-countering techniques came up because
of the concern that as the draft stands, it would not fall under PEARG's
charter. Happy to hear disagreements about that though.

Thanks,
Shivan

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 May 2019 23:36:51 +0100

Hiya,

> charter. Happy to hear disagreements about that though.

Sure. Up to you as chairs to decide of course, but ISTM that
this falls squarely into "Understanding attacks on privacy",
(this helping understanding), "Document research on new
and existing privacy assessment methodologies" (this
documenting research) and I'd consider at least some kinds
of censorship as a form of societal attack. So, FWIW, I'd
argue it's absolutely in scope of the charter. And I don't
think every RG work item needs to be proposing some new
mechanism.

Cheers,
S.

---

From: Gurshabad Grover <[email-masked]>
Date: Sat, 18 May 2019 11:43:34 +0530

[+hrpc]

On 18/05/19 2:30 AM, Shivan Sahib wrote:
> 
> The suggestion to include censorship-countering techniques came up
> because of the concern that as the draft stands, it would not fall under
> PEARG's charter. Happy to hear disagreements about that though.  
> 

I was going to suggest that this document be taken to hrpc since it
squarely falls under 2/3 charter goals [0] of that rg. A quick search
seems to suggest that this draft was not taken up as an hrpc rg document
only because it was hoped at the time that the draft will become an
AD-sponsored IETF draft. [1]

If that is not happening (hope I'm not missing some more context), I
think this draft is more suitable for the hrpc rg.

	-GG.

[0] "To expose the relation between protocols and human rights [...]";
and "[t]o increase the awareness [...] on the importance of the
technical workings of the Internet and its impact on human rights."

[1] https://mailarchive.ietf.org/arch/msg/hrpc/pon2lsx1UFjMQCtZpmLUarEZq4Q

---

From: Amelia Andersdotter <[email-masked]>
Date: Sun, 19 May 2019 03:37:50 +0200

Hey Joe,

Some additional feedback:

- Change the words "blacklisting" and "whitelisting" to "blocklisting"
and "allowlisting" as suggested in draft-knodel-terminology-00.
- EU countries are being let off a bit easily in the examples section.
DNS blocking is really common[1][2][3][4][7] (for section 4.1.1) - EU
ISPs default on DNS blocking when they are faced with legal obligations
to restrict access to content for whatever reason. On DPI (section
3.2.4), there are other resources[5] (which include the nuance Vittorio
seeks below). But of course, our friends at epicenter.works have
compiled a comprehensive list of various blocking schemes that are
commercially motivated in the EU at this time[6]. They fall under
various headings in draft-hall-censorship-tech section 3 and 4.

Like Vittorio, I have some difficulty seeing what sections 5, 6.1 and
6.4 bring to the discussion. Section 6.2 and 6.3 could have value since
there are or could be technical work-arounds for the cases where there
is no clear legal support for action (e.g., consider a contractual,
voluntary action by a root name server to delist or re-assign some name,
which could be monitored, perhaps in some way similar to Certificate
Transparency). Section 6.3 situations would be mitigated by
cloud-servers or CDNs, but not an IETF job perhaps. On section 6.2,
there is case-law from a number of EU member states on domain seizures,
and in a link below you'll see an EFF and Public Knowledge mapping of
B2B domain seizures in the US.

I can add some reflections on Vittorio's remarks (mostly for Vittorio's
benefit, but see EFF-link below all):

On 2019-05-17 12:00, Vittorio Bertola wrote:
> First of all, the document assumes that any content control is
> censorship. By the definition in section 1, even blocking the
> connection from a bot to its C&C center is censorship. That's way too
> broad.

While I disagree this necessarily applies to DoH, I am aware that
positive uses of disrupting communications (blocking port 25 for private
consumers to inhibit spam, for instance, in section 3.3.1 of the draft)
is what generally has limited regulatory action targetting the
/technical means of disrupting communications/. 

> But there are also cases in which Internet platforms decide to block stuff on their own, for their own business interests or company views (example: I don't think Facebook is censoring breastfeeding images due to any legal requirement or governmental pressure).

Yes, and no. James Boyle wrote an essay in 1997 titled "Foucault in
Cyberspace" which argues that COPPA incentivises exactly the censoring
of breastfeeding images. For an illustrative example, read the Wikipedia
article on Janet Jackson's nipple-slip during SuperBowl:
https://en.wikipedia.org/wiki/Super_Bowl_XXXVIII_halftime_show_controversy#Aftermath_and_effects

There are also issues with B2B contracts:
https://www.eff.org/deeplinks/2017/07/how-threats-against-domain-names-used-censor-content

I think this could be clarified in section 1 of draft-censorship by
adding the word "contractual": "(Although censors that engage in
censorship must do so through legal, CONTRACTUAL, military, or other means,"

> A couple of weeks ago, for example, Facebook blocked the account of a European elections candidate that happened to be a descendant of Mussolini. A couple of days ago, Facebook shut down 23 pages i…

To be fair, Facebook faces fines in the order of tens of millions of
euros if they fail to block something they should have blocked.
Over-blocking has indeed been a persistent concern among those groups
who have argued that blocking is not a good solution to any particular
content moderation problem.

References:

[1] Council of Europe, 2014: p. 72 ff, The rule of law on the Internet
and in the wider digital world, https://rm.coe.int/16806da51c

[2] European Commission (contractors), 2019: p. 31 ff, Evaluation of
regulatory tools for enforcing online gambling rules and channelling
demand towards controlled offers,
https://ec.europa.eu/growth/content/evaluation-regulatory-tools-enforcing-online-gambling-rules-and-channelling-demand-towards-1_en

[3] EDRi, 2011: p. 22 ff, The slide from self-regulation to corporate
censorship,
https://edri.org/wp-content/uploads/2010/01/selfregualation_paper_20110925_web.pdf

[4] EDRi, 2010: all the pages, Booklet On Internet Blocking.
https://edri.org/wp-content/uploads/2013/12/blocking_booklet.pdf

[5] BEREC and European Commission, 2012: A view of traffic management
and other practices resulting in restrictions to the open Internet in
Europe
http://berec.europa.eu/eng/document_register/subject_matter/berec/download/0/45-berec-findings-on-traffic-management-pra_0.pdf

[6] epicenter.works, 2019: p. 36 ff, Report: The Net Neutrality
Situation in the EU, https://epicenter.works/document/1522

[7] From ARTICLE19's CATNIP, forthcoming: "France blocked Copwatch, a
website reporting on police violence, in 2011,
https://www.laquadrature.net/fr/censure-politique-et-judiciaire-de-copwatch
"

-- 
Amelia Andersdotter
Technical Consultant, Digital Programme
Chair, RCM TIG, IEEE 802.11

ARTICLE19
www.article19.org

PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 20 May 2019 11:10:28 +0200 (CEST)

> Il 19 maggio 2019 03:37 Amelia Andersdotter <[email-masked]> ha scritto:
> 

It's true that, in the end, most independent blocking decisions by private companies derive from the fear of legal trouble, which by definition derives from a law and thus from a political/governmental decision. So I see why you could argue that most private censorship still indirectly derives from governmental pressure (the other big case I see is that of pro-intellectual-property upload filters, which until a couple of months ago were not legally mandated, but were privately adopted to avoid potential litigation with copyright owners; but one could say that this was still a consequence of a legal framework biased in favour of protecting commercial IP rights).

There are however a few cases in which it's quite hard to establish this connection; think for example of the Google Shopping case[1], which IMHO is indeed a form of private censorship. This does not derive from indirect legal pressure - on the contrary, it was ruled as illegal - but only comes as a consequence of private business interests.

In the end, I am really afraid of a future in which more and more censoring power is in the hands of private companies, so I would like the draft to cover that as well.

Ciao,

[1] https://www.beuc.eu/blog/how-google-is-eroding-consumers-freedom-to-choose/
--

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Mon, 20 May 2019 06:08:06 -0400

(A quick note that I haven't been able to keep up with this conversation as
I've been preparing to testify in the USA today on another part of my work
unrelated to this (election security). I'll be able to jump back into the
conversation tomorrow; thank you all for your patience!)

On Mon, May 20, 2019 at 05:10 Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> It's true that, in the end, most independent blocking decisions by private
> companies derive from the fear of legal trouble, which by definition
> derives from a law and thus from a political/governmental decision. So I
> see why you could argue that most private censorship still indirectly
> derives from governmental pressure (the other big case I see is that of
> pro-intellectual-property upload filters, which until a couple of months
> ago were not legally mandated, but were privately adopted to avoid
> potential litigation with copyright owners; but one could say that this was
> still a consequence of a legal framework biased in favour of protecting
> commercial IP rights).
>
> There are however a few cases in which it's quite hard to establish this
> connection; think for example of the Google Shopping case[1], which IMHO is
> indeed a form of private censorship. This does not derive from indirect
> legal pressure - on the contrary, it was ruled as illegal - but only comes
> as a consequence of private business interests.
>
> In the end, I am really afraid of a future in which more and more
> censoring power is in the hands of private companies, so I would like the
> draft to cover that as well.
>
> Ciao,
>
>
> [1]
> https://www.beuc.eu/blog/how-google-is-eroding-consumers-freedom-to-choose/
> --
>
-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 20 May 2019 13:25:39 +0300

Hi,

On 20/05/2019 12:10, Vittorio Bertola wrote:
>> To be fair, Facebook faces fines in the order of tens of millions
>> of euros if they fail to block something they should have blocked. 
>> Over-blocking has indeed been a persistent concern among those
>> groups who have argued that blocking is not a good solution to any
>> particular content moderation problem.
> 
> It's true that, in the end, most independent blocking decisions by
> private companies derive from the fear of legal trouble, which by
> definition derives from a law and thus from a political/governmental
> decision. So I see why you could argue that most private censorship
> still indirectly derives from governmental pressure (the other big
> case I see is that of pro-intellectual-property upload filters, which
> until a couple of months ago were not legally mandated, but were
> privately adopted to avoid potential litigation with copyright
> owners; but one could say that this was still a consequence of a
> legal framework biased in favour of protecting commercial IP
> rights).

I think that for the purposes of this draft it's useful to keep only the
text that is related to policy decisions enacted technically. Because:

> There are however a few cases in which it's quite hard to establish
> this connection; think for example of the Google Shopping case[1],
> which IMHO is indeed a form of private censorship. This does not
> derive from indirect legal pressure - on the contrary, it was ruled
> as illegal - but only comes as a consequence of private business
> interests.

I can imagine a lot of cases in which platforms remove content that is
benign but irrelevant. If I run a social media network that is about
parenting, I'm probably going to have a code of conduct or terms of
service that gives me the right to remove content that is extraneous to
this topic. Spam, too.

I think that we sometimes forget that some platforms are contextually
specific. But that usually these are defined by community standards.

-Mallory

-- 
Mallory Knodel
Head of Digital :: article19.org
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9  B071 0C32 A271 BD3C C780

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 23 May 2019 09:56:23 +0200 (CEST)

> Il 20 maggio 2019 12:25 Mallory Knodel <[email-masked]> ha scritto:
> 

This is also valid for security practices at the transport level (firewalls, malware/botnet filtering etc) as well as blocks for local usage policy (e.g. companies blocking access to social media from their offices during working hours). 

The basic issue is that the technological instruments used for these practices are often the same that are used for censorship. This is why you cannot just make a list of technologies (or, as in section 6, non-technical practices) and suggest that protocol designers and service operators should avoid them because they are used for censorship. It depends whether the "policy decisions enacted technically" are good or bad; so the text should at least discuss the other uses that each technology has, and perhaps elaborate on what can be done (if at all possible at the technical level) to tell censorship from other uses - though it looks pretty hard to achieve consensus on whether blocking certain things is censorship or not (e.g. fake news/hate speech), as it depends on local values.

Ciao,
--

---

From: Mallory Knodel <[email-masked]>
Date: Thu, 23 May 2019 11:51:59 +0300

On 23/05/2019 10:56, Vittorio Bertola wrote:
>> I can imagine a lot of cases in which platforms remove content that
>> is benign but irrelevant. If I run a social media network that is
>> about parenting, I'm probably going to have a code of conduct or
>> terms of service that gives me the right to remove content that is
>> extraneous to this topic. Spam, too.
> 
> This is also valid for security practices at the transport level
> (firewalls, malware/botnet filtering etc) as well as blocks for local
> usage policy (e.g. companies blocking access to social media from
> their offices during working hours).
> 
> The basic issue is that the technological instruments used for these
> practices are often the same that are used for censorship. This is
> why you cannot just make a list of technologies (or, as in section 6,
> non-technical practices) and suggest that protocol designers and
> service operators should avoid them because they are used for
> censorship.

It's absolutely fair to say some technology is dual use and to spend all
of one's time talking about the bad and undesirable of the two.
Otherwise, this document is no longer research focussed on censorship.

> It depends whether the "policy decisions enacted
> technically" are good or bad; so the text should at least discuss the
> other uses that each technology has, and perhaps elaborate on what
> can be done (if at all possible at the technical level) to tell
> censorship from other uses - though it looks pretty hard to achieve
> consensus on whether blocking certain things is censorship or not
> (e.g. fake news/hate speech), as it depends on local values.

Maybe it's the connotation or interpretation of the word "censorship"
that is getting in the way. It's all censorship, but some of it might be
legitimate (literally in accordance with law and norms).

-Mallory

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 23 May 2019 12:58:59 +0200 (CEST)

> Il 23 maggio 2019 10:51 Mallory Knodel <[email-masked]> ha scritto:
> 

You are right that the definition of "censorship" in section 1 is so broad that any suppression of any content would fall within its scope. However, most people would associate the term "censorship" with the negative use cases(*), or at least with use cases where the suppression is motivated by the opinions and information communicated through the content, rather than by its form or its pertinence to the context. In common talk, I don't think that anyone would consider stuff like (e.g.) removing off-topic posts from a discussion forum, blocking traffic from a virus trying to replicate itself, or preventing access to an online pharmacy that does not have the appropriate licenses, as censorship.

Now, if you only want to provide a survey of technologies, it could be enough to state at the beginning that there are also acceptable uses of these technologies but you will only focus on the negative ones. However, I am afraid that, coupled with the broad definition of censorship, this might still give the impression to the reader that this is a list of things that are bad in themselves, and also it will not be very useful research for subsequent application in the IETF space, as the difficult part is what should a protocol designer or implementer do when having to cope with these techniques.

Ciao,

(*) I am using moral terms such as negative and positive because I guess that in authoritarian countries political censorship is "literally legitimate" :-) though this is also one of the hot policy issues, i.e. whether the IETF should work to disrupt some country's laws when they mandate censorship-the-one-we-all-really-dislike.
--

---

From: Mallory Knodel <[email-masked]>
Date: Thu, 23 May 2019 14:14:54 +0300

Hi,

Just quickly,

On 23/05/2019 13:58, Vittorio Bertola wrote:
>> Maybe it's the connotation or interpretation of the word
>> "censorship" that is getting in the way. It's all censorship, but
>> some of it might be legitimate (literally in accordance with law
>> and norms).
> 
> (*) I am using moral terms such as negative and positive because I
> guess that in authoritarian countries political censorship is
> "literally legitimate" :-) though this is also one of the hot policy
> issues, i.e. whether the IETF should work to disrupt some country's
> laws when they mandate censorship-the-one-we-all-really-dislike.

I should have framed this as an application of international human
rights (a standard), which therefore wouldn't condone political
censorship as legitimate.

-M

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 May 2019 12:19:21 +0100

On 23/05/2019 08:56, Vittorio Bertola wrote:
> This is why you cannot just make a list of technologies (or, as in
> section 6, non-technical practices) and suggest that protocol
> designers and service operators should avoid them because they are
> used for censorship.
My understanding of this draft is that it documents the uses
of these mechanisms for censorship so that protocol designers
are aware of them, not in the hope that protocol designers
can prevent use of those mechanisms for censorship.

I think that's a good goal as perhaps not that many people are
aware of such details. It's also a good goal as it doesn't
require boiling any oceans, which would be the case if one
were to set out to document all uses of these mechanisms, add
all the pros and cons, consider GPDR issues etc and basically
take a few years for no particularly useful outcome. This
document needs none of that bolted on IMO.

Cheers,
S.