Since 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.

As the story from part 1 goes, I've received a DMCA takedown notice based on some content that was apparently sent through the Tor relay I just started running on this server. The first thing I did was to ask for advice on the Slicehost forum, thinking that maybe someone else on the forum had run across this problem before. No luck, though — it looks like I'm going to be the guinea pig (at least among Slicers) on this one, as a few other Slicehost customers have expressed interest in seeing the way the issue turns out.

As I suspected, the problem of DMCA takedown notices based on Tor activity is not without precedent, and to that end the EFF has written a template response to DMCA notifications. The template explains that Tor merely acts as a conduit for information, not as a host, and thus it falls under the "safe harbor" provisions in 17 U.S.C. § 512(a). (Before I start on the explanation, I need to make the obligatory disclaimer that I am not a lawyer!! I have no formal training, or even informal training, in legal matters. The law I'm dissecting in this post seems reasonably clear, but that's no guarantee that anything here is correct.)

The legal reference piqued my curiosity, so here's the actual text of subsection (a):

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...

Well guess what, that's exactly what Tor is. It provides a connection for routing material through a computer system controlled by me, 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—

Tor probably has some kind of (extremely) transient cache, since it's nearly impossible to do anything without one, so let's look at these conditions:

(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

It seems pretty clear to me that all five of those conditions describe Tor. They're practically the definition of an anonymizing proxy.

One thing left to check is subsection (j), to make sure I'm not liable for "injunctive or other equitable relief." It's a long one but here are the highlights:

If the service provider qualifies for the limitation on remedies described in subsection (a), the court may only grant injunctive relief in one or both of the following forms:

(i) An order restraining the service provider from providing access to a subscriber or account holder of the service provider's system or network who is using the provider's service to engage in infringing activity and is identified in the order, by terminating the accounts of the subscriber or account holder that are specified in the order.

Tor doesn't have accounts, so good luck with that...

(ii) An order restraining the service provider from providing access, by taking reasonable steps specified in the order to block access, to a specific, identified, online location outside the United States.

Presumably "specific, identified, online location" means an IP address. That's fine; I have no problem blocking access to an IP address if there's enough evidence to convince a court that it's a chronic copyright infringer. But the nature of Tor makes producing that evidence pretty difficult, if not impossible.

(2) Considerations.— The court, in considering the relevant criteria for injunctive relief under applicable law, shall consider—

(C) whether implementation of such an injunction would be technically feasible and effective, and would not interfere with access to noninfringing material at other online locations

Again, because of the nature of Tor, you can't really put in specific blocks based on what kind of traffic is passing through your relay or where it's coming from. In fact, according to the Tor legal FAQ, doing so could even be against the law.

In summary, I'm sufficiently convinced that Tor activity is not illegal. But there's another issue: a lot of ISPs have terms of service which restrict considerably more than the U.S. code does, and even though running a Tor relay may be legal, it could still be a ToS violation, which is not much better. That may, in fact, be the case here: transferring copyrighted material via Tor might be a violation of Slicehost's terms of service. I'm not really sure what the exact nature of the violation would be — the ToS carefully avoids mentioning transfer of copyrighted material as a prohibited activity in and of itself — but I'm hoping that will be cleared up shortly. I'm not trying to get away with letting this copyrighted material float around freely, I just want to keep my website up and my relay running.

As things stand now, I've replied to the original DMCA notice with a variant of the EFF's template letter (which I hope to post later on), basically stating that I haven't done anything illegal and I'm very interested in working this issue out to everyone's satisfaction. We'll see what happens with that.

— The chronology of my DMCA experience continues in part 3. —

Last night I started operating a Tor relay on my Slicehost server (the same one that runs this website). A Tor relay is an anonymizing proxy, essentially a service that allows connections between computers without revealing the identity of each one to any other. In the Tor project, there's a whole network of these relays, and what would ordinarily be a simple TCP conversation between two computers instead becomes a long chain of random, unpredictable connections in which each relay along the chain (except for the first and last) has no idea of the original source or final destination of the data it's processing. This kind of system is great for hiding your tracks from, say, government censors, since it's painstakingly difficult at best, impossible at worst, to actually follow the path that data takes from computer to computer. Obviously this is going to be very useful for a lot of people in Iran right now. (In fact, that's why I set up a Tor relay in the first place.)

Because Tor relays don't reveal information about the ultimate source of a TCP packet to its final destination, and vice versa, when you make a connection to some external server through Tor, the server doesn't know that the connection originates from your computer. (which is the whole point, of course) It only knows about the Tor exit relay that it's directly connected to. (The exit relay is just the last relay in the chain) So, for example, if someone downloads a movie file from a website through Tor, it's the exit relay that shows up in the web server's logs, not the actual downloader's computer.

This is basically what happened. Here's how the notification email started out:

We have received a notice pursuant to the Digital Millennium Copyright Act ("DMCA") from Bay TSP regarding certain content appearing at the above-referenced website (the "Website"). This company alleges that material posted on your company's website infringes on their copyright.

...which is slightly crazy, and more than slightly false. Sure, the material may be a copyright infringement, but it's not posted on my website.

Please remove the content claimed to be infringing from the Website and confirm to me in writing that you have done so by 8:00 A.M. Central Time, Friday, June 26, 2009. If the allegedly infringing content is not removed and/or I have not received your written confirmation by that time, Rackspace will suspend network access to the server(s) hosting the Website.

OK, now that's a problem. I can't remove the content because there's nothing to remove, so how's a law-abiding sysadmin to keep the server connected?

I'm certainly not the first one to encounter this problem, and there's already a lot of information out there about how to respond to a DMCA takedown request when there's nothing concrete you can do. But that will have to wait for a followup post while I hash out the details.

— The chronology of my DMCA experience continues in part 2. —

P.S. For anyone interested, here's more information about setting up a Tor relay or bridge to help Iranian activists and/or, more generally, the cause of open communication worldwide.