Tips for Running an Exit Node with Minimal Harassment

The rationale here is understandable, but #1 & 2 appear to have the undesirable side effect of making exit point surveillance by Government Organizations easier, assuming that the ISP in question is colluding with them (frequently the case, and in many nations, mandated by law or regulation). Is my conclusion in error? This might be less of a problem if a TOR user could whitelist or blacklist specific exit point countries (this rests on a presumption that authorities in Venezuela, for example, would likely be relatively uninterested in issues that are locally "sensitive" in Iran, for another example, and vice versa). Is there any tool in TOR that allows this? I do understand that the trade-off for wide use of such a capability would be a potential net reduction of bandwidth in an already constrained network.

Another useful tactic might be to register your reverse DNS domain name with a top level country code that is not the same as the jurisdiction for your IP address. It might be the case that the "copyright cartels" (lol) and others will give up if they see a .se domain name, or similar :)

Excessively simple perhaps, but arguably effective, for parties at both ends of the pipe. Now if there was a mechanism for clients in a given location to select an exit node that only exited to IP space in some defined elsewhere, a user in that location could have a little bit more comfort (never guaranties!) in his or her privacy.from the snooping noses of das Heimatland Sicherheit and ilk.

>We had an excessively simple strategy for reducing entanglements: being based in the >US, we only allowed exit to IP space delegated to Europe, Asia, etc.

Our non-US exit strategy was the outgrowth of an idea that seems to have been largely ignored by Tor developers.

IPv4 space is largely (not completely reliably) delegated to entities called Regional Internet Registries (RIR's) in large swaths. The RIR is then responsible for passing out space to the entities in its region. There are entanglements, such as multinationals, or legacy delegations, but in large part, you can wave your hands a bit and know that any IP address between 77.0.0.0 and 95.255.255.255 is handled by the European RIR, RIPE, IP addresses between 110.0.0.0 and 126.255.255.255 are handled by Asia Pacific's APNIC, etc. You can fairly readily break down large chunks of space by RIR based on the first octet, sorting unknown or mixed use stuff into a different category.

This means that it would be fairly easy to generate "buckets" that roughly categorize IP space. Tor nodes could be separated into each of these buckets, and you could have a rough idea that you'd likely be crossing political boundaries anytime you went from one bucket to another, simply because most countries do not exist in multiple geographic regions.

So you categorize Tor nodes into buckets while indexing them: this is a 256-entry database plus a half page of code.

Now, you can do things with that data. Rather than just "randomly" picking Tor nodes for a circuit, you could prefer a first hop outside your own bucket, a second hop in neither of those buckets, and a completely random third hop. So when your US-based PC goes to Amsterdam for the first hop, Taiwan for the second, and ends up exiting in Canada, you've done a lot to make it more difficult for any one country to track back to you.

Perhaps we don't have to worry about this in the US, but looks like the Iranians do.

Getting back to the previous comment, however ----

For those of you who would like to allow exit to non-local space, I suggest looking at

http://www.iana.org/assignments/ipv4-address-space/

Determine your own RIR (ARIN, APNIC, etc) and then generate a list of prefixes that are served by *other* RIR's. Allow exit to those prefixes. For example, a host in America can probably more safely offer exit to 41.*, 51.*, 58-62.*, etc.

hi there,
is it possible to have a special build only allowing my exit node for clients originating in china, iran etc.? unfortunately i don´t know very much about this software but am unwilling to hassle with problems from my isp. right now i´m running only in bridge mode.
i think there might be a lot more people out there like me that would install a special iran package without having to think about it anymore

ftd

Despite the local CableOne tech telling me in the morning that Tor wasn't a problem and that bandwidth wasn't an issue (especially between midnight and noon), that afternoon I came home after work to a nasty DMCA take-down notice and a frozen ISP account. I could receive mail, but that was it, and so perforce had to deal with the sanction by phone... Apparently someone had sent a bit torrent through my machine. Some game... I'm no gamer.

Well! I steered everyone and their dog to the EFF's legal boilerplate, but it was only today that I finally reached someone who knew what they were talking about, Tech No. 2, and he informed me that Tor on a residential account was in itself a no-no. And by then I no longer had the nous to contest the matter. I had acted in good faith & received bad information, and that was that. Time to move on. (He was very interested in the identity of Tech No. 1!)

You learn by doing. Knowing then what I know now, I probably would have stuck with a humble relay or bridge node and stayed under the radar. Parse your TOS's and AUP's well!

I truely believe what you did say here because I read most of the things you write.
But sometimes it just doesn't work for me.

IP and firewall in a manner that puts on the the Tor service on that IP and disallow anything else.
DiskOnModule
2.5” IDE Flash

Another useful tactic might be to register your reverse DNS domain name with a top level country code that is not the same as the jurisdiction for your IP address. It might be the case that the "copyright cartels" (lol) and others will give up if they see a .se domain name, or similar :)

auto insurance