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 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.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 11.04.13 21: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. Please expand on "except port 25, which is reasonable to block", or point me to an explanation. Regards, Jorge-León ___ 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 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? -- 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
> 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
In some work I've done, limitations would follow as such... a) Advertising non-desire for traffic (exit policy) is the same as packet filtering with the same rules locally. b) You can filter whatever you want at any inspection level you want, for whatever reason, or random/no reason, ***so long as you are doing it in a user agnostic global policy fashion.*** ie: - you may block torproject IP address or any other place for everyone because you think spacemen live there. You may not block it for just user X unless provided for under other policy. - you may scrape email content and block all viruses and even all talk of puppy dogs, so long as it is as a global policy and not just for user X. - you may sink all bittorrent for bandwidth. - you may sink content/protocol you think is too hot/unproven legally, or just whatever you want as global policy. - you may place bandwidth caps, block protocols, throttle, reset, cache, analyze, report, aggregate, rank, etc as matter of global policy and operations. It was not what you block or permit or where or why or how, but when you delve into the affairs of a particular user with singular intent. That is the hot area. Most particularly concerning the written content of their traffic, consumer profile, etc. Best example of this is locking an account because you took a ticket that it was 'abusing' something somewhere somehow in a protocol/traffic fashion, leeching, spam, etc... but you have no global policy for it, and you still sunk them. That would get you in trouble customer contract wise. That's why TOU's are so broad. But touching any ticket involving humanity ... hatemail, threats, bickering, chatroom, trolling, assholeness, crime, etc would be *strictly and always* returned with 'contact your authorities' and zero inspection or blocking in such regard. It's an anecdote, and certainly common best practice in many areas. Consult your area experts as needed. ___ 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
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
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 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 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 09/04/13 20:46, krishna e bera wrote: > On Tue, 9 Apr 2013 22:59:06 +0600 > Roman Mamedov wrote: > >> On Tue, 9 Apr 2013 12:50:09 -0400 >> krishna e bera 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 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 12.04.2013 11:00, 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? (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 (5) the material is transmitted through the system or network without modification of its content. One could argue that dropping packets is "modification of content", as well as "selection of material". By specifying an exit policy, you don't get to see the data in the first place, so no modification or selection happens. -- 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 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/11/2013 08:56 PM, Moritz Bartl wrote: 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. Okay, I get your point. By the way, I am not arguing, just trying to understand. Rejecting via Exit Policy is fine; disturbing the network concept is not necessary. 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). - 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.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. -- 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 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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
Moritz Bartl schreef op 2013-04-11 09:48: On 10.04.2013 23:42, t...@caber.nl wrote: It sounds very handy to use the Reduced Exit Policy. But if we _all_ do that there will be too little exits for users who want to connect to 'strainge' ports. That way they get less anonyimity because they can't choose from hundreds of exits. In general it is best practice to block/reduce as little traffic as possible. Than we can guarantee enough diversity for everyone, even those people using exotic applications/protocols. 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). Ok. I can also agree with that it is unwanted to drop 'random' packages. But if it is sufficient to stop the Bittorrent complaints I myself would prefer that above setting the Reduced Exit Policy. I am not an expert on the legal part of the packet dropping - I don't think you can get any RL trouble by it. But it is true that if we block certain sites/IP-addresses we don't have an excuse anymore why we did/will not do the same for some other 'unwanted' sites. 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) ___ 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/11/2013 09:48 AM, Moritz Bartl wrote: On 10.04.2013 23:42, t...@caber.nl wrote: It sounds very handy to use the Reduced Exit Policy. But if we _all_ do that there will be too little exits for users who want to connect to 'strainge' ports. That way they get less anonyimity because they can't choose from hundreds of exits. In general it is best practice to block/reduce as little traffic as possible. Than we can guarantee enough diversity for everyone, even those people using exotic applications/protocols. 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? It seems to me that the bittorrent and other abuse is hurting the tor network. Has it been considered to integrate abuse prevention policies into tor? 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. - 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 10.04.2013 23:42, t...@caber.nl wrote: > It sounds very handy to use the Reduced Exit Policy. But if we _all_ do > that there will be too little exits for users who want to connect to > 'strainge' ports. That way they get less anonyimity because they can't > choose from hundreds of exits. > In general it is best practice to block/reduce as little traffic as > possible. Than we can guarantee enough diversity for everyone, even > those people using exotic applications/protocols. 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). -- 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
Steve Snyder schreef op 2013-04-10 22:35: On Wednesday, April 10, 2013 3:42pm, "Jorge-Leon" said: [snip] Oh! I too use the filter as in "BlockingBittorrent". I did not want to restrict my relay to the "ReducedExitPolicy". Almost all complaints were Bittorrent related. So I hoped "BlockingBittorent" would be the right ting to do. - should the "BlockingBittorrent" recipe be changed in a way, that it changes the exit policy of the relay instead of the firewall? - How to block torrents from ThePirateBay anyway? - Is there a way to block any bittorrent traffic? I would advise, again, just to use the Reduced Exit Policy. I never get DCMA/copyright complaints. Most of the complaints I get are due to morons port-scanning through Tor, or from webmail spamming. It sounds very handy to use the Reduced Exit Policy. But if we _all_ do that there will be too little exits for users who want to connect to 'strainge' ports. That way they get less anonyimity because they can't choose from hundreds of exits. In general it is best practice to block/reduce as little traffic as possible. Than we can guarantee enough diversity for everyone, even those people using exotic applications/protocols. -- Theo Caber ___ 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 Wednesday, April 10, 2013 3:42pm, "Jorge-Leon" said: [snip] > Oh! I too use the filter as in "BlockingBittorrent". > > I did not want to restrict my relay to the "ReducedExitPolicy". Almost all > complaints were Bittorrent related. So I hoped "BlockingBittorent" would be > the right ting to do. > > - should the "BlockingBittorrent" recipe be changed in a way, that it > changes > the exit policy of the relay instead of the firewall? > > - How to block torrents from ThePirateBay anyway? > > - Is there a way to block any bittorrent traffic? I would advise, again, just to use the Reduced Exit Policy. I never get DCMA/copyright complaints. Most of the complaints I get are due to morons port-scanning through Tor, or from webmail spamming. ___ 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 10.04.13 12:35, Moritz Bartl wrote: ... 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. ... Oh! I too use the filter as in "BlockingBittorrent". I did not want to restrict my relay to the "ReducedExitPolicy". Almost all complaints were Bittorrent related. So I hoped "BlockingBittorent" would be the right ting to do. - should the "BlockingBittorrent" recipe be changed in a way, that it changes the exit policy of the relay instead of the firewall? - How to block torrents from ThePirateBay anyway? - Is there a way to block any bittorrent traffic? Regards, Jorge-León ___ 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/10/2013 12:35 PM, Moritz Bartl wrote: Spending time on "legal issues" is part of the job of an exit operator. Sorry. Thanks for educating me. As a C programmer, I can probably contribute in other ways. - 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 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
On Tue, 9 Apr 2013 22:59:06 +0600 Roman Mamedov wrote: > On Tue, 9 Apr 2013 12:50:09 -0400 > krishna e bera 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
Re: [tor-relays] BitTorrent complaint
On Tue, 9 Apr 2013 18:01:40 +0100 mick 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 04/09/2013 07:01 PM, mick wrote: Though personally I'm with Romanov here. Just relay with no exit until you have a better feel for tor. Mick I guess you are right. Thanks for the tips. - 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 Tue, 09 Apr 2013 18:33:26 +0200 bartels allegedly wrote: > On 04/09/2013 06:24 PM, Steve Snyder wrote: > > Just make life easy for yourself and use the Reduced Exit Policy: > > > >https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy > Good advice. Had not seen that. > > 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. Or if you really feel you /must/ run an exit at this stage, try limiting yourself to just http and https. ExitPolicy accept *:80 ExitPolicy accept *:443 ExitPolicy reject *.* Though personally I'm with Romanov here. Just relay with no exit until you have a better feel for tor. 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 12:50:09 -0400 krishna e bera 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. -- 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 Tue, 09 Apr 2013 18:04:53 +0200 bartels 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 04/09/2013 06:24 PM, Steve Snyder wrote: Just make life easy for yourself and use the Reduced Exit Policy: https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy Good advice. Had not seen that. 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. - 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 Tuesday, April 9, 2013 12:04pm, "bartels" 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 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
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
39585
BitTorrent
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
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 39585 BitTorrent 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
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 > > 39585 > BitTorrent > > > 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
[tor-relays] BitTorrent complaint
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 39585 BitTorrent 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
