Re: [tor-relays] BitTorrent complaint

[Moritz Bartl <moritz@xxxxxxxxxxxxxx>]

On 11.04.2013 11:56, bartels wrote:
>> I totally agree. That's why our relays allow every port except 25. But,
>> in the event that DMCA complaints scare away the ISP (or the exit
>> operator), they should go for the reduced exit policy (and look for a
>> better ISP), instead of randomly dropping packets or otherwise filtering
>> traffic, which is just mean (and probably illegal).
> Illegal? Why would it be illegal? Or mean?

Mean: Tor specifically has the exit policy to be able to select an exit
that allows that outgoing connection. If an exit relay then drops that
connection silently, Tor (and the user) cannot know it needs to select a
different exit. The connections simply fail. That is totally mean.

What you do with that iptables rule (or similar rules) is block a bunch
of URLs. Even worse: If I control your DNS server, I can make you block
random sites. In general, you are censoring the user, and following the
argumentation of mig media monopolies: "everyting on PirateBay must be
illegal", or, worse, "everything using the Bittorrent protocol must be
illegal". The Bittorrent protocol is in fact a very efficient and good
protocol to spread information.

Illegal: As an exit operator, you should know about the relevant laws
that protect you from liability. I've started a list, and many other
added the ones they think might be relevant in their country (thanks!),
at https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines
-- a document every Tor exit operator should read.

Let me quote the full paragraph DMCA 512(a) here, then you should
understand why interference with connections might not be a good idea
from a legal standpoint. As far as I am aware, other ("western")
countries have similar provisions.

(a) Transitory Digital Network Communications.— A service provider shall
not be liable for monetary relief, or, except as provided in subsection
(j), for injunctive or other equitable relief, for infringement of
copyright by reason of the provider’s transmitting, routing, or
providing connections for, material through a system or network
controlled or operated by or for the service provider, or by reason of
the intermediate and transient storage of that material in the course of
such transmitting, routing, or providing connections, if—
(1) the transmission of the material was initiated by or at the
direction of a person other than the service provider;
(2) the transmission, routing, provision of connections, or storage is
carried out through an automatic technical process without selection of
the material by the service provider;
(3) the service provider does not select the recipients of the material
except as an automatic response to the request of another person;
(4) no copy of the material made by the service provider in the course
of such intermediate or transient storage is maintained on the system or
network in a manner ordinarily accessible to anyone other than
anticipated recipients, and no such copy is maintained on the system or
network in a manner ordinarily accessible to such anticipated recipients
for a longer period than is reasonably necessary for the transmission,
routing, or provision of connections; and
(5) the material is transmitted through the system or network without
modification of its content.

http://www.law.cornell.edu/uscode/text/17/512

> I can see some drawbacks, sure, but what seems to happen now is that
> each exit relay makes up their own mind about what is the way to go.

In a perfect world we would still need Tor, but it would automatically
assign a BadExit flag to any exit that censors. I will suggest to add
such a check specifically for Bittorrent trackers to the next generation
of exit scanners.

If you don't want to allow Bittorrent tracker connections (again, this
does NOT block the actual Bittorrent transfers, and is useless for
torrenting via DHT!), do it via Exit Policy.

-- 
Moritz Bartl
https://www.torservers.net/
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays