Linux - NewsThis forum is for original Linux News. If you'd like to write content for LQ, feel free to contact us.
All threads in the forum need to be approved before they will appear.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have loved LQ for years and have admired all the genius behind the idea, of LQ. Thank you and yours and me. Here is the Plug... FREEGEEK. Help and get helped computing. Portland Oregon. Thank you, them, and us.
I know this is a bit of a gravedig, but I have some feedback for LQ.
Most Tor users cannot use LQ, even in a readonly capacity. If there's any way for this to be changed, I would really appreciate it. As it stands, I have specific firewall rules in place so my machine routes LQ traffic directly (not through Tor), which I feel should be unnecessary.
Ideally service providers wouldn't use services like Project Honeypot until they agree to set up their blacklists to ignore submission of the IPs of Tor exit nodes. Tor should be blocked using the methods the Tor project makes available. They're made available to reduce or remove incentive to ban individual exit nodes.
Project Honeypot blacklists IPs for 90 days after a complaint is submitted, and Tor users only use exit nodes for 30 seconds at a time. I just want to stress the massive difference and futility of blocking individual exit nodes vs. blocking some open HTTP proxy or VPN- which have a small number of IPs which are used for extended amounts of time, if not per-subscriber. It's extra work for service providers, extra work for pleasant Tor users, and does not stop the unpleasant ones.
I'd complain to Project Honeypot, but that would be like calling the complaint department of an airline for a refund. Who wants to talk to someone whos job it is to (blacklist)placate people who are (using anonymity networks)upset while doing nothing to (prevent innocent users from being affected)solve their problem?
I like LQ, and I like Tor. I hope someday I don't have to choose between the two anymore. It's the only site I currently make this concession for.
Last edited by mark_peters; 10-09-2012 at 07:22 AM.
Distribution: Debian, Red Hat, Slackware, Fedora, Ubuntu
Posts: 13,597
Original Poster
Rep:
Thanks for the feedback. The topic of TOR and LQ has come up a couple times recently. As I have mentioned, we do not explicitly block TOR (and have no plans to). We do use multiple tools to assess the traffic we do allow for members who are not logged into the site. While at times we may use Project Honeypot data as part of this, their API allows us to choose the threat level and time period since last activity, so I am not sure where the persistent "90 day blacklist" perception is coming from. That said, we'll continue to monitor the situation and if I better way to allow legitimate TOR traffic can be reasonably implemented, we'll look into doing so.
As I have mentioned, we do not explicitly block TOR (and have no plans to).
Which I have been made aware of, and happy to hear.
Quote:
Originally Posted by jeremy
We do use multiple tools to assess the traffic we do allow for members who are not logged into the site.
If an IP is being blocked because of the http:BL they get a 403 when viewing pages on LQ. This behavior is completely unrelated to whether or not logon session cookies are present in the user's browser. I just tested this myself.
Quote:
Originally Posted by jeremy
While at times we may use Project Honeypot data as part of this, their API allows us to choose the threat level and time period since last activity, so I am not sure where the persistent "90 day blacklist" perception is coming from.
If you manually select a less-than-90 day threshold, this problem is avoided to an extent. Of course, the fact remains that you are not going to block the abusive Tor user and you ARE going to block innocent bystanders for however long your threshold is.
This is why blocking a Tor user via IP-based blocklists or APIs will never work. More so than on any other network subsytem, a IP is not a person. Nothing done to that IP will even be noticed by the person.
Quote:
Originally Posted by jeremy
That said, we'll continue to monitor the situation and if I better way to allow legitimate TOR traffic can be reasonably implemented, we'll look into doing so.
Finally, my persistence in this is massively related to your last statement expressing a "better way to allow legitimate Tor traffic." You are not disallowing illegitimate Tor traffic to begin with.
You are completely misinterpreting the problems and attempting to take an approach suited for completely different socio-technological issues:
Abusive Account - Block the Account
Abusive IP Address - Block the IP Address
Abusive ISP - Block the ISP
Abusive User, Using a Tor Exit node, on the Tor network - ? (Hint: A perfect solution not already on this list, but an interim one and two useless ones are.)
I am not one of "Those complaining users that don't understand the kind of work they're expecting from us." I know work needs done, and that it's not some SMF plugin or configuration option. Until OSPs realize this need, it will never be filled. I certainly ain't sure how to fill it and I know it's there.
Distribution: Debian, Red Hat, Slackware, Fedora, Ubuntu
Posts: 13,597
Original Poster
Rep:
Quote:
If an IP is being blocked because of the http:BL they get a 403 when viewing pages on LQ. This behavior is completely unrelated to whether or not logon session cookies are present in the user's browser. I just tested this myself.
Members who are browsing with an active session do not have these checks run in any way.
Quote:
Finally, my persistence in this is massively related to your last statement expressing a "better way to allow legitimate Tor traffic." You are not disallowing illegitimate Tor traffic to begin with.
Nor are we attempting to block "illegitimate Tor traffic", we're trying to block "illegitimate traffic". FWIW, I made a small adjustment, fired up Tor and was able to browse LQ fine for an extended amount of time.
Members who are browsing with an active session do not have these checks run in any way.
As I said before, I don't know where you are getting that information from, that's incorrect. Having logon cookies (an "active session" as you put it) does not bypass these checks. It is still possible to get these 403s.
Quote:
Originally Posted by jeremy
Nor are we attempting to block "illegitimate Tor traffic", we're trying to block "illegitimate traffic". FWIW, I made a small adjustment, fired up Tor and was able to browse LQ fine for an extended amount of time.
This is most likely because the exit node you were using at the time wasn't listed in the http:BL.
Last edited by mark_peters; 10-12-2012 at 08:43 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.