First DMCA takedown notice (part 3)
Posted by David Zaslavsky on — Edited — CommentsSince the posting of part 2 of this story, I’ve been involved in an email conversation with an agent — actually that sounds kind of evil, so let’s say representative — of Rackspace’s AUP (acceptable use policy) division. Basically my position has been that I’m willing to take reasonable security measures to impede illegal downloading, but if we couldn’t come up with an acceptable way for me to continue running the relay, I’d be moving to another hosting company.
For one thing, I’ve gotten clarification on exactly why Slicehost’s terms of service prohibit the transfer of copyrighted material:
Section 2 of our TOS states that “You agree that you are responsible for the conduct of all users of your account and any Content that is created, transmitted, stored, or displayed by, from, or within your account while using Slicehost services and for any consequences thereof.” While the use of TOR is not against the TOS, the sharing of copy written material is. The fact that BayTSP was able to download their material from your slice is the violation.
So evidently I’m responsible for the copyrighted content that was downloaded from my server. As far as I can tell, their argument is that, when the content was downloaded from my slice, that was an illegal act, and since the ToS states that I bear responsibility for the content, I’m responsible for the violation of the law… or something like that. I’m not fully convinced by this, but it’s close enough to making sense that I’m willing to play along with it. (Not to mention, it’s risky to pick a fight with a company that reserves the right to terminate your services at any time, for any reason — or no reason — without prior notice ;-)
The DMCA, in several places (17 U.S.C. § 512(c)(1)(C) and 17 U.S.C. § 512(i)(1)(A), notably) requires that an ISP, in order to protect themselves from legal liability, take some action in response to prevent the further sharing of the copyrighted material. In my case, the representative from Rackspace AUP suggested that I block the port from which the material was downloaded, and that that should be enough to allow me to restart my Tor relay. Apparently it “has worked in the past” for other customers.
Well hmm… sorry, but I have to call B.S. on that one. The nature of BitTorrent is that it can use any port at all for the actual peer-to-peer transfer. The ports actually used are determined on the fly, somewhat unpredictably, so blocking one single port isn’t going to do much of anything to stem the tide of copyright infringement. I’d have to block a whole range of ports — indeed, most of the 65536 possible choices — to really reduce the chance of copyrighted material being accessed through my server, and leaving just one port open (even the HTTP port, 80) technically provides a loophole for BitTorrent traffic to come through.
I’m willing to compromise on that point, though, and here’s why: as I wrote on my IPTables tutorial, it’s just good practice from a security standpoint to have a “reject-by-default” policy, to allow through only the traffic that you explicitly know is going to be necessary. It’s the same reason I set up a firewall on my server that restricts most outbound traffic. Given that the primary reason I set up the Tor relay is to aid free communication in Iran, “necessary” traffic encompasses things like Twitter, probably Facebook, maybe Gmail or other web-based email clients… the point being, all websites. Ports 80 and 443 are enough for that kind of access. So I can conceivably block every port other than 80 and 443, and while that won’t disrupt web access, it should stop nearly all BitTorrent traffic. The chances of the BT client choosing an open port would be 1 in 32768 — in fact, probably less, because BitTorrent usually favors the high-numbered ports that aren’t really used for anything else.
I had a look through the list of assigned port numbers and picked out the ones that people would most likely want to anonymize. Here’s the exit policy right out of my Tor configuration file:
ExitPolicy accept *:21-23,accept *:53,accept *:80,accept *:110,accept *:143,accept *:443,accept *:992-993,accept *:995,reject *:*
That allows FTP, SSH, Telnet, DNS, HTTP, POP3, IMAP, HTTPS, secure Telnet, IMAPS, and POP3S, basically allowing people to control servers, transfer files over direct connections, access websites, and check email. Should be enough for any revolutionaries.