JSSpamBlock and ImageScaler were both originally one-day projects that turned out to be a bit more popular than I expected. Recently I have neglected to update them at all, but with reports of ImageScaler not working on WordPress 2.3, I decided to put a day aside and make some changes I had been meaning to make for a while.
A new version of ImageScaler was released last week (thanks to David Karlsson for doing most if not all of the work). I still got comments that it didn’t work with WordPress 2.3, so I installed WordPress 2.3 myself to see what the problem is. I didn’t have any issues, but I made some changes to ImageScaler that might make it more likely to work. If you still have problems with WordPress 2.3, let me know. I also made another major change - images hosted on other servers were previously ignored by ImageScaler and left as-is. Now they are mirrored on the server and can be re-sized properly. Also, images are now always resized so that the aspect ratio is preserved. You can download ImageScaler 1.1 from WordPress.
The new version of JSSpamBlock doesn’t need a database. It uses sessions instead. I also cleaned up the code a bit and tested it with WordPress 2.3. You can download JSSpamBlock 2.0 from WordPress.
I just noticed a trackback from Brandon Cheketts about a PHP script he has released that lets you incorperate functionality similar to JSSpamBlock in any website, called bcSpamBlock. He also released a WordPress plugin based on JSSpamBlock that uses the script.
Although both plugins take advantage of the same limitation of spam bots - that they ignore JavaScript, the way they verify the codes is different. While JSSpamBlock uses a database, bcSpamBlock uses one-way encryption to verify the codes. Although this is a clever way to do it, I chose not to do it in JSSpamBlock for a reason: Storing the code in a database ensures that, even if a spammer were to write a bot targeting sites with JSSpamBlock, each comment posted would require the bot to parse another page from the server. Each code sent to the browser can only be used once. The problem with not using a database is that you have no way to verify that the codes sent from the browser are being used for the first time, and not the 10th.
Georg Kaindl made similar comments about the database being unnecessary, and I wrote a more lengthy response explaining why it was. He then came up with a clever solution - including the post’s ID in the hash. It still isn’t quite as secure as JSSpamBlock (I hate to use the word “secure” to describe what I admit is “security-by-inconvenience”, but I can’t think of another word that fits), but for all practical purposes it should be just as good. The only difference is that spammers could post multiple comments to any given post while only parsing the page once, while JSSpamBlock would require the page to be parsed once for each comment. The other advantage is that I do not have to rely on the JSSpamBlock user to come up with a unique salt in order for the protection to be secure. bcSpamBlock gets around this in a clever way, by using unchanging environment variables to generate the salt.
Another way to look at it is that generating a random code for each page view does not actually increase security (over using the same code for each page view) unless you use a database. So for a plugin that doesn’t use a database, this only gives the illusion of security. You might as well use the code “4422″ for everything, and it would be just as secure. This might sound bad, but any bot that is currently blocked by JSSpamBlock would be blocked by this as well. The only reason JSSpamBlock does more is to make it harder to write a bot that specifically targets JSSpamBlock. It may sound egotistical to suggest that a spammer would ever bother to write a bot specifically targeting the plugin, but for the extra cost (milliseconds of CPU time), I think it is worth making the plugin future-proof.
The way JSSpamBlock has evolved since I first released it has reminded me why I love open-source. From day one, I had users pointing out bugs and features they would like added, sometimes even submitting a fix for the bug or adding a new feature in themselves. Here are some modifications I have come across on other blogs:
After Georg Kaindl and I had a discussion on whether a database was really neccesary (he made some excellent points on why this is not the case, though I still maintain that the extra protection is worth the small cost of time), he released a JSSpamBlock modification as a new plugin called simpleAntiSpam. He also came up with a clever way to require that the form be parsed once by the bot for each post (although the bot can make unlimited comments to a post once it has parsed the form). I have considered making this functionality the default in an upcoming version of JSSpamBlock, since it will be more than enough protection for the average user.
More recently, I got a comment from Brandon Checketts, who had modified JSSpamBlock so that the comment field names were different than the defaults. The reason was that even if spam bots adapt to JSSpamBlock, modified field names will throw them off. Although I can’t see anyone modifying their spam bots to specifically get around my plugin, I have always tried to design it as if they eventually would, so this will likely be a feature in future versions as well.
Kevin Pendleton, another user, has ported JSSpamBlock to Perl. His version is a bit simpler; it uses a hard-coded value instead of a randomly generated one. In my experience with bots, this should be enough to block out the vast majority of spam bots.
It must look like JSSpamBlock is all I have been working on these days, which is the opposite of true. I have a couple cool projects coming along that I hope to post soon, but I fixed another oversight in JSSpamBlock. Basically, if you installed JSSpamBlock in a folder called /jsspamblock/ in the plugins directory (rather than putting the file directly in the plugins directory), the activate hook was not called, so the database tables were not created. This is now fixed. Thanks to david_kw of exfer network for discovering the problem and the solution. You can find the new JSSpamBlock 1.4 in the WordPress plugin directory.
A user of JSSpamBlock found a bug which is rather undesirable; it incorrectly assumes that comments are spam if a new comment hash has since been generated. Versions up to 1.2 have this bug. The new version 1.3 does not, and can be found here: http://wordpress.org/extend/plugins/jsspamblock/ . Sorry for any inconvenience. This will be the last JSSpamBlock for a while, I promise ;).
Thanks to Stephen Darlington for finding this bug.
I have made a few small changes to JSSpamBlock, my WordPress spam detection plugin. I found that the plugin had some problems with custom WordPress themes, since some theme developers apparently don’t include the comment form hook. I have added instructions on how to call JSSpamBlock manually from the template file. I have also fixed the plugin for older versions of WordPress which did not have the wp_die() function.
The plugin is now hosted at the WordPress Plugin Directory. You can find it’s page here: JSSpamBlock 1.2. If you have a working installation, there is no reason to upgrade.
I got my first comment spam on this blog the other day. It inspired me to try an idea I got a few months back. My theory was that these bots aren’t very smart - they are programmed to post as many comments as possible on as many sites as possible, hoping that a handful of these comments would get past whatever system the blogger was using to prevent spam. I hypothesized that these bots did not execute JavaScript, and that by requiring some JavaScript to run in the browser I would be able to check with reasonable accuracy weather the comment was submitted by a human or a bot.
I wrote up a simple plugin to test the theory. I checked the logs to find that I was right. In fact, most of the bots that were spamming my blog did not even include the hidden element, which indicates that they were posting to the wp-comments-post.php file directly rather than accessing the form first. The bots that did access the form did not execute the JavaScript and therefore their comments were blocked. Since the trick only involves JavaScript, most users will not even notice the difference. Users without JavaScript simply need to follow the given instructions to copy a number to a text box in order to prove they are human. This is what users without JavaScript will see:
If you are interested in using JSSpamBlock on your own blog, here are the download links:
RSS Feed