<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="text-align:left; direction:ltr;">
<div>El mar, 28-09-2021 a las 11:56 -0700, Jeremy Malcolm escribió:</div>
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<div dir="ltr">Dear all,
<div><br>
</div>
<div>I am new to this list, although I am not completely new to the Internet technical community, as I am a long-time IGF (and occasionally ICANN) participant.</div>
<div><br>
</div>
<div>I am writing about a case that has been referred to my organization involving global blocking (packet dropping, apparently) of IP addresses that have been reported as hosting CSAM by the Canadian Center for Child Protection (C3P). According to public information,
the C3P runs a web crawler called Project Arachnid which searches for instances of CSAM on the clearweb, and sends automated takedown notices to providers.</div>
<br>
<div>However, in the case that was reported to me, rather than allowing the hosting provider to take down the offending image, the takedown notice was followed by global packet dropping of the hosting IP address, which took down the entire server and other
websites along with it: the hosting provider has attributed this censorship to RIPE, although I cannot verify whether or not this is true. If I am able to obtain more details from RIPE staff, I will follow up with them.</div>
<div><br>
</div>
<div>
<div>Moreover the website in question was not a CSAM website, and neither was the image reported by the C3P a CSAM image. It was a scan of a 1960s postcard of an indigenous family, sent through the mail, which was included in a detailed ethnographic blog article
about indigenous women and girls. In other words, this is an obvious false positive, and it should never have been reported as CSAM at all.</div>
<div></div>
</div>
<div>
<div><br>
</div>
<div>I'm writing to find out if anyone has more information that they can share about how this might have happened, and how it can be prevented from happening in the future. Many thanks in advance for any help that you can offer. Not sure if I should include
the RIPE Cooperation ML on this, given that it relates to the actions of the C3P? </div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Hello Jeremy</div>
<div><br>
</div>
<div>RIPE did not block your site. What I can see happening is that when C3P found some "CSAM content" on your site, it looked up on the _RIPE database_ who was the appropriate contact to notify about this, and then either</div>
<div>a) Notified both you and $someone_else</div>
<div>or</div>
<div>b) Notified just $someone_else (which would have then forwarded it to you)</div>
<div><br>
</div>
<div>with $someone_else most likely being your hosting provider.</div>
<div>Note that if you don't know to have your details in the whois database, then most likely they are not there, and the details will be to your hosting provider.</div>
<div><br>
</div>
<div>Using the RIPE database to find out the owner of an IP address and the abuse contact for it is precisely the right thing to do here (assuming this is network range was allocated by RIPE).</div>
<div><br>
</div>
<div>Finally, $someone_else filtered your site first (shutdown the machine, firewalled it…) and then asked questions. It may be harsh, but it's an understandable policy. Specially since they may not be allowed to identify what is CSAM and what isn't, and should
they misclassify it as not being CSAM, while legally fitting into that category, could lead to Real Trouble.™</div>
<div><br>
</div>
<div>It is also possible that the filtering was done by a different entity, like the upstream provider of your hosting, but I would bet it was done by the hosting itself. And it is the filtering entity you should request to remove such filtering. You may be
able to use different traceroutes to pinpoint the place where your server is being blackholed.</div>
<div><br>
</div>
<div><br>
</div>
<div>Best regards</div>
<div><br>
</div>
<div><span>
<pre><pre>-- <br></pre>INCIBE-CERT - Spanish National CSIRT
https://www.incibe-cert.es/
PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys
====================================================================
INCIBE-CERT is the Spanish National CSIRT designated for citizens,
private law entities, other entities not included in the subjective
scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen
Jurídico del Sector Público", as well as digital service providers,
operators of essential services and critical operators under the terms
of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de
las redes y sistemas de información" that transposes the Directive (EU)
2016/1148 of the European Parliament and of the Council of 6 July 2016
concerning measures for a high common level of security of network and
information systems across the Union.
====================================================================
In compliance with the General Data Protection Regulation of the EU
(Regulation EU 2016/679, of 27 April 2016) we inform you that your
personal and corporate data (as well as those included in attached
documents); and e-mail address, may be included in our records
for the purpose derived from legal, contractual or pre-contractual
obligations or in order to respond to your queries. You may exercise
your rights of access, correction, cancellation, portability,
limitationof processing and opposition under the terms established by
current legislation and free of charge by sending an e-mail to
dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de
Ciberseguridad de España, M.P., S.A. More information is available
on our website: https://www.incibe.es/proteccion-datos-personales
and https://www.incibe.es/registro-actividad.
====================================================================
</pre>
</span></div>
</body>
</html>