I regularly have serious problems using Stack Exchange sites such as:
- not being able to see the site at all: "We're sorry... too many requests"
- not being able to log in
- not being able to post answers that I have just spent valuable time and energy writing
- enter a value into a very difficult CAPTCHA field like twenty times before realizing that I surely got it right some times by now, and so it doesn't matter whether I answer correctly or not, the site will always reject.
My crime: I'm a Tor user. (Mind you there's even a Tor Stack Exchange site; how cynical is that?)
I know programming is not easy, but the art of it is making elegant solutions, not to whack into user experience with a cleaver. Just one idea springing to my mind right now (I'm sure some Knuth-like brain can think of something a million times better):
- I'm a member for three years
- logged in
- not a single letter of spam has ever been posted from my account.
- as a human, I can only post so many things per time-unit
How could I be distinguishable from a spammer (bot or otherwise)?
What if my account gets hacked at some point in the future?
Combine 3 & 4, and making sure that a genuine user does not EVER get harassed becomes pretty trivial and low risk. (E.g. use some counters that go up on posting or on having posts flagged as spam and go down over time1, then set up some policies depending on those values.)
All that aside, even for not-logged-in users (reading the site), it must be said that blocking users based on IP address is bad practice that should stay in the early era of the internet which we've surely outlived by now.
edit for Servy, who asked what I propose:
I don't have access to specific data about the SE signal to noise ratio, but this is where I would start.
There seem to be 2 distinctive questions at hand:
- Preventing spam, ungenuine voting, flagging, ...
- Preventing abusive server load
Logged in users Much can be said, and it's surely an interesting research question, but for logged in user:
take this rule to heart: As long as no post from this user has been flagged as spam, never, ever put anything in their way when posting. Remember this: until a post gets flagged, nobody has seen it or at least been annoyed enough to bother to flag it, so not much damage done.
when a post gets flagged as spam, put every new post from this user in a waiting queue. Don't prevent the user from posting, but don't make publicly visible until approved.
use git bisect to let humans with more than xxx or probably xxxx rep determine the first spam post from this account. Now hide posts from that point on. Responsiveness is an important factor here, which you will have to evaluate as you go, and this step will at least sometimes require human intervention.
if more than x spam posts or step 3 hides genuine posts because they alternate with spam, require human intervention (password reset, reply to an email to justify what happened, etc.) before allowing any more posting.
beware that false positives will happen and take some preventive measures (someone might post a link to software they wrote, and someone else considers that spam and flags it...). It would probably be better to lower the rep requirements for step 3, but require x users to to agree on it. If you feel that this is using your users as spam filter, it is, but I'd rather volunteer to be used as spam filter than as OCR software for reCaptcha. In the end it's just the chores that need doing.
Require human interaction for making a new account, like a captcha, but it could be something else.
extras: you could probably:
be a bit more restrictive on new accounts. The fight basically is the human effort of creating a new account (privileged enough to be interesting for a spammer) vs the human effort to bisect the spam account's posts.
avoid trying to do anything smart!
Other abusive behaviour:
It would really depend on the specifics. I personally haven't got much complaints, so probably it's mostly working fine, except for poor policies like the "security" measures against tactical downvoting. Tactical downvoting seems to be a niche problem (young questions only, abuser answers themselves, ...) and locking votes everywhere for everyone is both draconian and useless to prevent it...
Preventing abusive server load
Again, it's hard to tell which problem you are trying to solve without seeing numbers, but something doesn't add up. The tor network is slow. Every request taxes 4 different machines. It's surprising that someone can wear down the Stack Exchange servers by using tor, and if I wanted to crawl, tor is definitely not what I'd use. If someone is doubling as a malicious user and a tor node, you might want to get in touch on the tor node mailing list.
A perfect solution, unless in extreme circumstances (unlikely here) is to check at least the cookie information send by the browser before rejecting the request. No need to use any IP-based system for logged in users.
On a sidenote, this seems a lot rarer than the compulsive logouts, captchas, never resolving captchas etc.
ps: In any case blocking tor won't stop any determined malicious person. A vps costs 0.005 dollar cents per hour these days. I can have as many non tor IP adresses as I want, either by renting them, or by hijacking one of the poor sods that hire one for their wordpress blog...
Asking for software not to choke, vomit at you, slap you in the face before just breaking down and keeping you from using it completely legit is not a feature request, it's a bug report.
1 Better, compare them to the current Unix timestamp; they don't need to decrement...