Should ISP block child pornography?

Sat Dec 8 19:05:37 UTC 2018

As everyone has stated, blocking/filtering is a rabbit hole that we dare
not go down or we set ourselves on the same path as oppressive regimes.

For a similar situation that's far less depressing, see the numbers of
threads about whether or not enterprises should block certain sites. This
is an employee behavior problem, so it ought to fall under HR, not IT. But
IT should be happy to provide data about what employees visit prohibited
sites to HR so that discipline can be administered accordingly. Blocking
doesn't stop the problem, it just forces employees to use more cell phone
data.

Personally, I prefer a policy of direct cooperation with authorities to put
these folks where they should be, behind bars (and hopefully) with general
population where they have to lie about why they're locked up out of fear
of being torn apart for what they've been a part of and the children
they've hurt.

These animals have always found ways to satisfy their horrid urges. Before
the internet was popular, they used sneakernets; we have the opportunity to
use the data we have available to make the job of the authorities easier,
and we should all strive to contribute to the elimination of child
exploitation.

If you think cooperation with authorities is also a rabbit hole or violates
customer privacy, then know that your AUP should always include a special
clause about this specific scenario and you don't "have" to cooperate if
you don't think there is sufficient evidence, you can leave that up to a
judge to decide. (In the USA at least).

If your company refuses to cooperate, all you can do is politely remind
them of the reprocussions of obstructing any investigation of this nature,
like how when Uncle Sam brings a warrant to the table, it's usually WAY
wider reaching than you could have imagined and almost always comes with a
free gag order so you can't defend yourself to your customers. This could
have unintended consequences the business.

We'll never eliminate this problem, even if we shut down all TOR nodes and
block all known endpoint IPs/domains. But we can help catch some of them
and I take pride whenever I feel like I'm directly contributing to that.

-Matt

P.S. opening discussion about whether or not null routing on-sight is a
good idea because yes, it makes the content inaccessible, which is the end
goal, but it also alerts the offender that they've been caught and could
initiate a scorched Earth strategy, thus impeeding any investigation by
authorities.

On Fri, Dec 7, 2018, 01:07 Lotia, Pratik M <Pratik.Lotia at charter.com wrote:

> Hello all, was curious to know the community’s opinion on whether an ISP
> should block domains hosting CPE (child pornography exploitation) content?
> Interpol has a ‘worst-of’ list which contains such domains and it wants
> ISPs to block it.
>
> On one side we want the ISP to not do any kind of censorship or inspection
> of customer traffic (customers are paying for pipes – not for filtered
> pipes), on the other side morals/ethics come into play. Keep in mind that
> if an ISP is blocking it would mean that it is also logging the information
> (source IP) and law agencies might be wanting access to it.
>
>
>
> Wondering if any operator is actively doing it or has ever considered
> doing it?
>
>
>
> Thanks.
>
>
>
>
>
> With Gratitude,
>
>
>
> *Pratik Lotia*
>
>
>
> “Information is not knowledge.”
> The contents of this e-mail message and
> any attachments are intended solely for the
> addressee(s) and may contain confidential
> and/or legally privileged information. If you
> are not the intended recipient of this message
> or if this message has been addressed to you
> in error, please immediately alert the sender
> by reply e-mail and then delete this message
> and any attachments. If you are not the
> intended recipient, you are notified that
> any use, dissemination, distribution, copying,
> or storage of this message or any attachment
> is strictly prohibited.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20181208/627e388a/attachment.html>