The one thing I'd point out is that the "delay" option is something one might not want. It's simple enough: call sleep(rand(0, 20)). The only problem is that

The one thing I'd point out is that the "delay" option is something one might not want. It's simple enough: call sleep(rand(0, 20)). The only problem is that it means that your Apache process is hanging there and using up memory while punishing that user. Under a prefork model, you're going to have one process per connection. Now you have "trolls" that 40% of the time take an average of 10 seconds for Apache to serve - all the while using up the process/memory. If the troll knows of this module, it would be relatively simple for them to DOS your site - and hard to protect against it. Basically, using Apache's prefork mpm, you have Apache launch a separate process for each connection. Your server can handle a limited number of connections at any given time based on the amount of RAM that your box has to handle the connections. Now, you're tying up, say, 20MB of RAM for 10 seconds 40% of the time that a troll is trying to load a page. So, you're now giving the troll the chance to take one of your Apache processes out of commission for an extended period of time simply by trying to load one of your pages. This is probably a user that doesn't like being labeled a troll and might think it nice to get retribution against your site. So, they load up 10 tabs and try loading your site. 4 of them tie up 4 Apache processes for an average of 10 seconds a piece. The user could probably set up an automated script to keep hitting your server. Usually, such a script could be killed by rate limiting. However, because they're able to (on average) tie up an Apache instance for 4 seconds (10 second average load time by the 40% chance of that being triggered), they don't have to hit your server too often to really increase the load. And something like iptables isn't going to be aware of your labeling them a "troll" user. This could also apply to a similar system implemented in, say, Rails. Basically, if you're using a multiple-process system to handle concurrency, you probably don't want to allow troll users to tie up one of your processes for multiple seconds. If they don't catch on, maybe they leave the site because performance is bad and you've accomplished your goal. However, if they catch on that you've labeled them a troll and are calling sleep() on x% of their requests, they can then tie up your server resources in retaliation. I love the idea of the module. The random white screen, wrong page, random node, 403, and 404 all make it seem like your site is flaky and might cause them to go elsewhere. The forms that don't submit (especially if what is typed is lost) would cause a huge drop in the amount of troll content. However, be very careful before giving your worst users the ability to tie up your server resources.