<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
The attached version 0.97 of the Manila Principles, taking into
account comments made over the last few weeks, takes us a step
closer to the version that we will approve in Manila. Most of the
areas of difference have crystallised very clearly by now. There
are a few points where further discussion is still needed, which are
worth highlighting:<br>
<br>
1. There continues to be disagreement about whether only a judicial
order can justify the restriction of content by an intermediary. In
the latest draft, we remain committed to a judicial order only - but
one option for compromise (the word "preferably") is given in square
brackets, and further discussion is invited.<br>
<br>
2. We still need to come up with a better term than "content
provider" to refer to users who upload content.<br>
<br>
3. Principle II(c) says "Intermediaries who host content may forward
compliant requests for content restriction received from
complainants ... to the content provider". It was correctly pointed
out that this can lead to abuse - although we do also say later that
"Governments may sanction content restriction requests that are
issued with no reasonable legal justification or basis" and we also
say that "Intermediaries should be allowed to charge private party
complainants on a cost recovery basis for the time and expense
associated with processing their<br>
content restriction requests", and it is suggested in the latest
draft that we add "at a rate provided by law". Are these sufficient
safeguards? Or do we need more? We don't however want to place
intermediaries in the<br>
position of judges who have to make a legal determination that a
content restriction request is prima facie valid - both because of
the burden that this places on them, and also because they are not
qualified and could make dubious judgments or come under pressure to
do so.<br>
<br>
You can also find an online version of the 0.97 draft at
<a class="moz-txt-link-freetext" href="https://docs.google.com/document/d/1xJ-jjaaSGN7ZQfjuGftgwnWaPeK5JBZeaVA3-oiNAk4/edit#heading=h.2s8eyo1">https://docs.google.com/document/d/1xJ-jjaaSGN7ZQfjuGftgwnWaPeK5JBZeaVA3-oiNAk4/edit#heading=h.2s8eyo1</a>
(but unlike the attached version, it doesn't show the amendments
since version 0.96).
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<meta charset="utf-8">
<pre class="moz-signature" cols="72">--
Jeremy Malcolm
Senior Global Policy Analyst
Electronic Frontier Foundation
<a class="moz-txt-link-freetext" href="https://eff.org">https://eff.org</a>
<a class="moz-txt-link-abbreviated" href="mailto:jmalcolm@eff.org">jmalcolm@eff.org</a>
Tel: 415.436.9333 ext 161
:: Defending Your Rights in the Digital World ::
Public key: <a class="moz-txt-link-freetext" href="https://www.eff.org/files/2014/10/09/key_jmalcolm.txt">https://www.eff.org/files/2014/10/09/key_jmalcolm.txt</a>
PGP fingerprint: FF13 C2E9 F9C3 DF54 7C4F EAC1 F675 AAE2 D2AB 2220
OTR fingerprint: 26EE FD85 3740 8228 9460 49A8 536F BCD2 536F A5BD
Learn how to encrypt your email with the Email Self Defense guide:
<a class="moz-txt-link-freetext" href="https://emailselfdefense.fsf.org/en">https://emailselfdefense.fsf.org/en</a></pre>
</body>
</html>