Re: [tor-relays] BitTorrent complaint
On 13.04.2013 09:05, Jorge-Leon wrote: 1) Allow everything (except port 25, which is reasonable to block) 2) If you don't want the DMCA spam notices, use the reduced exit policy. Please expand on except port 25, which is reasonable to block, or point me to an explanation. In short: We had port 25 (SMTP) open for a while, which results in a lot of spam directly sent to mailservers across the globe, which then immediately will get your IP blacklisted at a lot of DNSBLs. Many ISPs don't like their own ranges to contain blacklisted IPs, because that results in lower overall reputation scores, and sometimes blacklistings are extended to a whole range of IPs, which then affects other customers. -- Moritz Bartl https://www.torservers.net/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On 12/04/13 22:54, Moritz Bartl wrote: On 12.04.2013 19:16, Matt Joyce wrote: It would help a lot if we used versioning and stopped sending almost unchanged data constantly and instead only providing the changes I doubt that this is easy to do in a privacy-preserving way. You don't want to be able to discriminate relays based on what diffs/what amount of data they pull, right? That could be a valid point I hadn't considered that but yes in theory if a node used only one dir mirror or a collection of dir mirrors that all co-operated you could gain profiling info based on which version they claim to have etc. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On 13/04/13 11:49, Moritz Bartl wrote: On 13.04.2013 09:05, Jorge-Leon wrote: 1) Allow everything (except port 25, which is reasonable to block) 2) If you don't want the DMCA spam notices, use the reduced exit policy. Please expand on except port 25, which is reasonable to block, or point me to an explanation. In short: We had port 25 (SMTP) open for a while, which results in a lot of spam directly sent to mailservers across the globe, which then immediately will get your IP blacklisted at a lot of DNSBLs. Many ISPs don't like their own ranges to contain blacklisted IPs, because that results in lower overall reputation scores, and sometimes blacklistings are extended to a whole range of IPs, which then affects other customers. Also in addition to the above it's fairly few providers that only accept on 25 and it's rarely the recommended setup. Most end user facing Mail Transfer Agents (MTA's) servers intending to receive mail from Mail User Agents (MUA's ie Thunderbird, Outlook Express whatever) will accept SMTPS on 465 or Submission usually with TLS on 587 which also have other advantages SMTPS is encrypted and Submission and both are usually authenticated in fact submission is specified as such so you can't generally dump direct mail into either unless you are a legitimate user of a valid email account carried by that server. Thus when considering the two together: 1. The level of abuse of port 25 is incredibly large spam is pretty much the single most common abuse issue on the Internet. 2. Alternative options exist that are more secure. For me that makes the port 25 block reasonable. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On 11.04.2013 22:17, bartels wrote: I don't see the legal issue, though. Maybe it is there, but I don't see how rejecting sites via Exit Policy ;) would trigger any one of (1) through (5). Yes, rejecting via exit policy should not, but direct filtering/tampering via iptables might. -- Moritz Bartl https://www.torservers.net/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On 04/12/2013 10:06 AM, Moritz Bartl wrote: On 11.04.2013 22:17, bartels wrote: I don't see the legal issue, though. Maybe it is there, but I don't see how rejecting sites via Exit Policy ;) would trigger any one of (1) through (5). Yes, rejecting via exit policy should not, but direct filtering/tampering via iptables might. How do you figure that? Where's the legal difference? - bartels ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On Fri, Apr 12, 2013 at 11:00:42AM +0200, bartels wrote: On 04/12/2013 10:06 AM, Moritz Bartl wrote: On 11.04.2013 22:17, bartels wrote: I don't see the legal issue, though. Maybe it is there, but I don't see how rejecting sites via Exit Policy ;) would trigger any one of (1) through (5). Yes, rejecting via exit policy should not, but direct filtering/tampering via iptables might. How do you figure that? Where's the legal difference? Rejecting via exit policy means that those packets/traffic never reach your relay because the rest of the network won't select your relay as part of the circuit. Rejecting via iptables means those packets reach your machine but never leave. Therefor, you are making a judgement about which traffic is abusive or illegal. In some jurisdictions this has, by some twisted logic, been interpreted to mean that the operator is giving tacit approval for anything that has not been rejected. This is even more clear-cut if you are rejecting specific hosts rather than all traffic on a given set of ports. It really is spelled out in the doc that Moritz linked: https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines In any case it *is* mean to tell the network that you'll relay certain traffic but then in fact not pass it on. Nobody likes a liar :) -troy ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On 09/04/13 20:46, krishna e bera wrote: On Tue, 9 Apr 2013 22:59:06 +0600 Roman Mamedov r...@romanrm.ru wrote: On Tue, 9 Apr 2013 12:50:09 -0400 krishna e bera k...@cyblings.on.ca wrote: So at the risk of being labelled a BadExit (or at best a non-net-neutral exit) i blocked all of ThePirateBay's ip addresses from my exit node for a while. I assume you mean firewall-based blocking? You could have simply rejected those IPs via ExitPolicy (see man tor). That's a clear-cut way to tell the network you don't accept connections to those IPs, and no risk of being labeled a BadExit. The latter. I dont know if it complicates routing decisions in the Tor network to have lots of ip address exceptions at the exits... ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays It possibly does slightly but we are talking about the sort of complication that a modern CPU can resolve in timescales short enough I doubt it would make that much difference especially if hash tables were used if ipset match can handle hash table lookups containing over 20,000 CIDR ranges while processing 75,000 packets per second I suspect tor could easily be made to efficiently use a similar mechanism, if it doesn't already in order to perform the lookups to compute the answer to What is the subset of exit nodes allowing exit to IP addr X on port Y? to come close to the same volume of lookups as the above setup with just over 1k exit nodes the client would need to be building 70+ circuits per second assuming a separate lookup table was used for every node, two factors make me think it's unlikely to go anywhere near this load and if it did that it would only be for brief periods of time as opposed to constant as in the former example, those being that I don't see many exit nodes ever having policies 20k entries long and I can't see that many clients needing to connect to 70+ IP address per second at least not on any continual basis perhaps short bursts (Opening a browser and restoring a few dozen tabs at once or something similar). Bittorrent may be an exception to the above but the performance cost would be at the clients end and for one bittorrent is hardly a realtime protocol a little delay making each connection would not make much difference, two it performs poorly if you insist on running it over tor anyway and thirdly the average consumer desktop system is not exactly lacking spare CPU cycles due to the bursty nature of their workloads they statistically tend to spend the majority of their time idling. Maybe someone can correct me if I missed something glaringly obvious but I certainly don't think anyone should be reluctant to add any exit policy entries they deem necessary at least not for this reason. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On 04/12/2013 11:35 AM, Troy Arnold wrote: On Fri, Apr 12, 2013 at 11:00:42AM +0200, bartels wrote: On 04/12/2013 10:06 AM, Moritz Bartl wrote: On 11.04.2013 22:17, bartels wrote: I don't see the legal issue, though. Maybe it is there, but I don't see how rejecting sites via Exit Policy ;) would trigger any one of (1) through (5). Yes, rejecting via exit policy should not, but direct filtering/tampering via iptables might. How do you figure that? Where's the legal difference? Rejecting via exit policy means that those packets/traffic never reach your relay because the rest of the network won't select your relay as part of the circuit. Rejecting via iptables means those packets reach your machine but never leave. Therefor, you are making a judgement about which traffic is abusive or illegal. In some jurisdictions this has, by some twisted logic, been interpreted to mean that the operator is giving tacit approval for anything that has not been rejected. This is even more clear-cut if you are rejecting specific hosts rather than all traffic on a given set of ports. I find Klingon easier to understand than the perverse logic of lawyers. But there is no arguing with jurisdiction. So, how can isps get away with blocking port 25? Just curious. And/or offering a deliberately corrupted dns? It really is spelled out in the doc that Moritz linked: https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines Okay. In any case it *is* mean to tell the network that you'll relay certain traffic but then in fact not pass it on. Nobody likes a liar :) Apparently, I gave the impression that I am in favor of exit relays rejecting or dropping packets. I am not. Exit policy, or any other tor policy is good. My only concern is abuse and the best way to deal with it. Thank for the feedback. - bartels ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On 11/04/13 20:00, Moritz Bartl wrote: On 11.04.2013 12:15, t...@caber.nl wrote: If we want to avoid the packet-dropping problem: We could also reject the IP-addresses of those sites with torrc. What is your opinion about that Moritz? And, would it ok for the authorities and users with little bandwith if I reject ~100 ip-adresses? (Not that I am going to) Apart from the last section of my answer to bartels: Yes, listing 100+ IPs in the exit policy is not very nice for the Tor network either. :( I guess the simple answer would be: 1) Allow everything (except port 25, which is reasonable to block) 2) If you don't want the DMCA spam notices, use the reduced exit policy. It's not ideal if everyone does it however that's primarily due to the distribution mechanism, for now it is sending the *entire* file every time over HTTP there are however ways this could be distributed better if the community of exit operators were to decide such was necessary and the size of the descriptors thus began to increase such as versioning and distributing diffs to clients a conversation along the lines of: Client: Request descriptor for relay with $FINGERPRINT have revision X. DirMirror: Descriptor for relay $FINGERPRINT diff revision X current revision Y data follows. This would increase the necessary storage space on each mirror a little using a storage system like git, hg or svn use code from these could probably be reused, or even just use hg as a dependency and make a local repo with no daemon but unless everyone is changing their descriptors in major ways on a regular basis I suspect it would be quite small especially if older copies were expired after a reasonable period of time maybe 30 days and clients with older versions are just sent the full current version so only clients that use the network very infrequently would be actually downloading the entire policy. We are talking plain text files here too so I cant see the storage issue being a massive one given that HDD space is inexpensive now and even inexpensive VPS servers typically offer hundreds of GB of it, the main issue would be bandwidth which honestly I suspect would be lower or at worst similar if we only distributed diffs to the majority of clients. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On 12.04.2013 13:33, Matt Joyce wrote: I assume you mean firewall-based blocking? You could have simply rejected those IPs via ExitPolicy (see man tor). That's a clear-cut way to tell the network you don't accept connections to those IPs, and no risk of being labeled a BadExit. The latter. I dont know if it complicates routing decisions in the Tor network to have lots of ip address exceptions at the exits... It possibly does slightly but we are talking about the sort of complication that a modern CPU can resolve in timescales short enough I doubt it would make that much difference especially if hash tables were used That's not the issue here. You don't want to make the routing table (consensus and descriptors) that every Tor client needs to have too large. Users in developing countries, on mobile connections or generally instable connections already have issues. -- Moritz Bartl https://www.torservers.net/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On 12/04/13 15:03, Moritz Bartl wrote: On 12.04.2013 13:33, Matt Joyce wrote: I assume you mean firewall-based blocking? You could have simply rejected those IPs via ExitPolicy (see man tor). That's a clear-cut way to tell the network you don't accept connections to those IPs, and no risk of being labeled a BadExit. The latter. I dont know if it complicates routing decisions in the Tor network to have lots of ip address exceptions at the exits... It possibly does slightly but we are talking about the sort of complication that a modern CPU can resolve in timescales short enough I doubt it would make that much difference especially if hash tables were used That's not the issue here. You don't want to make the routing table (consensus and descriptors) that every Tor client needs to have too large. Users in developing countries, on mobile connections or generally instable connections already have issues. It would help a lot if we used versioning and stopped sending almost unchanged data constantly and instead only providing the changes they are after all text files and there is a whole range of open source projects out there with the functionality to manage versioning and incremental updates for text files, the tradeoff of course would be in the slightly increased disk space requirements for dirmirriors. That said I'm not arguing that we *should* do this merely that it is possible and there are technical options to accommodate it if it were required by enough of the community to pose a potential issue. Basically my point is that the it's possible the question therefore more one of whether we should, I don't particularly see the need and there are arguments against it I don't like censorship at the best of times which is why I run the exits I have I am just countering the technical arguments which I believe are potentially solvable if there was consensus that it is warranted and therefore are not good reasons to dismiss the idea. As for the unstable connections issue, yeah that I can understand that said tor uses TCP only and TCP is *known* to perform at less than optimum in the event of unstable connections with random drops, it will get the data there but it will also do it very slowly interpreting dropped packets as congestion. Radio communications frequently cause TCP to have problems which is why the FAQ for almost any high bandwidth TCP application will invariably suggest things like Use a hardwired connection if possible not wireless. I'm not dismissing it as an issue of course but no TCP application is going to work well if the underlying network infrastructure is poor and I am not sure how that is going to be solved without A) Replacing TCP with something else (But what?) or B) Major investment in those networks which is unfortunately unlikely until there is a large enough user base to create the demand to make someone with capital actually pay the slightest bit of attention because they generally are only interested when they can generate a profit. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
tor could easily be made to efficiently use a similar mechanism, if it doesn't already in order to perform the lookups to compute the answer to What is the subset of exit nodes allowing exit to IP addr X on port Y? The answer may lie with the client polling some exits and computing the answer to its needs locally. I just posted a blurb about this to tor-dev. Anyone interested may want to follow up and add on over there. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
Bittorrent may be an exception to the above but the performance cost would be at the clients end and for one bittorrent is hardly a realtime protocol a little delay making each connection would not make much difference, two it performs poorly if you insist on running it over tor anyway and thirdly the average consumer desktop system is not exactly lacking spare CPU cycles due to the bursty nature of their workloads they statistically tend to spend the majority of their time idling. As opposed to torrenting via exits, I'm amazed more people haven't moved their torrenting to operate entirely within anonymous networks. The performance of I2P and Tor (and I guess Phantom during tests) is actually quite usable so long as the user excercises content selection and patience. And regarding this thread, the freedom of operators and users from complaints regarding takedown would be invaluable. I'm not sure if these networks could scale to handle the node count and chatter, but I think the bit about spare cycles is right and might even act as a natural limiter to that sort of traffic. For instance, my tests show that establishing connections to many onions in parallel is quite costly and prone to failure without available headroom. But once connected, things are ok. Perhaps torrenters simply can't put aside their 'must download it all right now' mentality which keeps them away from our nodes. Or there is a major influx waiting to happen upon some future enlightenment whether they're misguided or not. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On 09.04.2013 18:04, bartels wrote: Personally, I cannot afford complaints and spend time on legal issues; however groundless they may be it is not what I do. Spending time on legal issues is part of the job of an exit operator. Sorry. DMCA notices are totally harmless. Another thing is filtering on bittorrent. The tor site suggests a filter: https://trac.torproject.org/projects/tor/wiki/BlockingBittorrent Just because it is in the community wiki, it is not something you should do, or an official Tor recommendation. I would advise heavily against anything that blocks connections outside of the official ExitPolicy statements. Clients will become unreliable, and have no way of knowing what happened to their connection. The quoted snippet blocks connections to trackers, but not torrenting itself. One of the most popular sites, ThePirateBay, does not even rely on trackers any more. Apart from that, blocking trackers will also hurt legal torrenting. https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy Must say it is a pretty loose list. I do not see the point in accessing a squid proxy server over tor. It sort of defeats the purpose. Maybe you don't, but other users do. The reduced exit policy blocks most random ports, which is what Bittorrent clients use for connections. This means it will drastically reduce the amount of DMCA notices you will receive. You are free to allow an even more limited amount of ports on your exits. -- Moritz Bartl https://www.torservers.net/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
Hi, Most countries have liability exemptions for passing traffic. There is no legal obligation to shut down or anything. See also https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines . What is your question exactly? --Mo On 08.04.2013 18:28, bartels wrote: Hi People, Two days ago I opened two fast tor exit relays v2.3 on debian wheezy. Now I get complaints from paramount that I have unwittingly distributed Hansel and Gretel via BitTorrent Port39585/Port TypeBitTorrent/Type Can this be linked to tor, or is that impossible? I don't want to shut down tor for no reason. - Bartels. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Moritz Bartl https://www.torservers.net/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
Hello Mo, Thanks for answering. My question was not really clear, but the issue is resolved anyway. The server was hacked and is re-installed. So, nothing to do with tor; the exit relay is up and running again. - Bartels On 04/09/2013 10:21 AM, Moritz Bartl wrote: Hi, Most countries have liability exemptions for passing traffic. There is no legal obligation to shut down or anything. See also https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines . What is your question exactly? --Mo On 08.04.2013 18:28, bartels wrote: Hi People, Two days ago I opened two fast tor exit relays v2.3 on debian wheezy. Now I get complaints from paramount that I have unwittingly distributed Hansel and Gretel via BitTorrent Port39585/Port TypeBitTorrent/Type Can this be linked to tor, or is that impossible? I don't want to shut down tor for no reason. - Bartels. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
Forgive my ignorance, I am new to tor and learning.
On closer inspection, I find that bittorrent can run over the tor network, like
any other traffic.
Personally, I cannot afford complaints and spend time on legal issues; however
groundless they may be it is not what I do.
It leaves me with a question: how do the Paramount people know that my server
carried their stuff?
Did they download it themselves, or do they have their own bittorrent servers?
They must be at either end, or am I mistaken?
Another thing is filtering on bittorrent. The tor site suggests a filter:
https://trac.torproject.org/projects/tor/wiki/BlockingBittorrent
Looking at it, I find it slightly flawed, because of the port numbers.
Instead of using this:
wget -qO- http://www.trackon.org/api/all | awk -F/ ' { print $3 }'
I would use:
wget -qO- http://www.trackon.org/api/all | awk -F: '{ print $2 }' | awk -F/
' { print $3 }'
It would explain why only most bittorrent traffic is blocked.
Can anybody confirm this? I don't want to be the newbie messing up someone
else's wiki.
- Bartels
On 04/09/2013 11:21 AM, bartels wrote:
Hello Mo,
Thanks for answering. My question was not really clear, but the issue is
resolved anyway.
The server was hacked and is re-installed.
So, nothing to do with tor; the exit relay is up and running again.
- Bartels
On 04/09/2013 10:21 AM, Moritz Bartl wrote:
Hi,
Most countries have liability exemptions for passing traffic. There is
no legal obligation to shut down or anything.
See also
https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines .
What is your question exactly?
--Mo
On 08.04.2013 18:28, bartels wrote:
Hi People,
Two days ago I opened two fast tor exit relays v2.3 on debian wheezy.
Now I get complaints from paramount that I have unwittingly distributed
Hansel and Gretel via BitTorrent
Port39585/Port
TypeBitTorrent/Type
Can this be linked to tor, or is that impossible?
I don't want to shut down tor for no reason.
- Bartels.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On Tue, 09 Apr 2013 18:04:53 +0200 bartels bart...@mailme.ath.cx wrote: Forgive my ignorance, I am new to tor and learning. On closer inspection, I find that bittorrent can run over the tor network, like any other traffic. Personally, I cannot afford complaints and spend time on legal issues; however groundless they may be it is not what I do. Why don't you just NOT run a freaking EXIT NODE, if you are new to tor and learning? Bittorrent can run over the tor network, also Child Pornography can run over the tor network, can you afford spending time on legal issues like this[1] ? I'd say disable the Exit functionality immediately and only open it cautiously much later on, for the ports that you KNOW won't get you in trouble, or will get you in the kinds of trouble you are prepared to deal with. [1]http://arstechnica.com/tech-policy/2012/11/tor-operator-charged-for-child-porn-transmitted-over-his-servers/ -- With respect, Roman signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On Tuesday, April 9, 2013 12:04pm, bartels bart...@mailme.ath.cx said: Forgive my ignorance, I am new to tor and learning. On closer inspection, I find that bittorrent can run over the tor network, like any other traffic. Personally, I cannot afford complaints and spend time on legal issues; however groundless they may be it is not what I do. Just make life easy for yourself and use the Reduced Exit Policy: https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy To use, just paste these lines into your torrc file. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On Tue, 09 Apr 2013 18:04:53 +0200 bartels bart...@mailme.ath.cx wrote: On closer inspection, I find that bittorrent can run over the tor network, like any other traffic. It doesnt run both ways because peers cannot be available for incoming connections, so users will find themselves eventually banned from servers or with lower transfer speeds for not sharing nicely. Also Tor does not (yet) carry UDP traffic. The possible exception is if the peers are entirely in onioncat space. BitTorrenters are really better off using I2P for anonymous bulk transfers though. Personally, I cannot afford complaints and spend time on legal issues; however groundless they may be it is not what I do. I had the same problem with my ISP - they had no tolerance for the DMCA complaints and were not willing to just pass them on to me. So at the risk of being labelled a BadExit (or at best a non-net-neutral exit) i blocked all of ThePirateBay's ip addresses from my exit node for a while. That reduced DMCA complaints down to about 1 a year, but because i had clients' sites also running on my server and didnt want any risks i eventually went non-exit. It really depends what jurisdiction you are in. It leaves me with a question: how do the Paramount people know that my server carried their stuff? Did they download it themselves, or do they have their own bittorrent servers? They must be at either end, or am I mistaken? They have agents who participate in BT swarms (and sometimes poison them), so they can see the ip addresses of seeders and other participants. Some government agencies such as FBI might work with them to enforce copyrights, so they may also have inside snooping info from some ISPs that are hosting torrent servers, or from machines which are those ISPs' gateways. The US Commerce Department might consider it a threat to national security if American companies intellectual property is vaguely threatened, so agencies such as NSA or CIA may be sharing info ad hoc under the table etc (remember ECHELON?). ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On Tue, 9 Apr 2013 18:01:40 +0100 mick m...@rlogin.net allegedly wrote: Though personally I'm with Romanov here. Correction. Roman (forgive me Roman). Mick - blog: baldric.net gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 - signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
On Tue, 9 Apr 2013 22:59:06 +0600 Roman Mamedov r...@romanrm.ru wrote: On Tue, 9 Apr 2013 12:50:09 -0400 krishna e bera k...@cyblings.on.ca wrote: So at the risk of being labelled a BadExit (or at best a non-net-neutral exit) i blocked all of ThePirateBay's ip addresses from my exit node for a while. I assume you mean firewall-based blocking? You could have simply rejected those IPs via ExitPolicy (see man tor). That's a clear-cut way to tell the network you don't accept connections to those IPs, and no risk of being labeled a BadExit. The latter. I dont know if it complicates routing decisions in the Tor network to have lots of ip address exceptions at the exits... signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
