Comment Spam is a thing of the past. That method I’ve found to be 100% effective in stopping bot-based spam, but you still need some sort of content moderation for manually-entered spam. A version of Stopgap Extreme called WP Hashcash is in the new plugin repository and undergoing shared development. The repository has over 55 plugins already and it hasn’t even been officially announced. 🙂 (And this doesn’t count.)
Manually-entered spam is the real issue because it is rarely picked up by filters like Spaminator. I don’t think that it is possible to stop that type of spam (logically speaking). There are always ‘geniuses’ around offering us the magic product that can eliminate all inevitable evil, so let’s give up that hope.
I love the ‘100% effective in stopping bot-based spam’ bit though!
Well, for now at least. I can imagine in the future the bots will have full javascript parsers. Then we’ll have Flash-based forms or something.
It’s a shame it’s inaccessible, though – try to comment with javascript disabled and you (inexplicably) get sent on to Google News. I would recommend the Three Strikes plugin for a server-side solution.
“Accessible” is the wrong term to use there. It’s perfectly accessible to people using screen readers, it doesn’t degrade the usability of the form any, it doesn’t have any visual or aural elements. The only type of browser it blocks is one that doesn’t use javascript, which is an acceptable tradeoff in this case.
The WP-Hashcash version I linked doesn’t redirect people to Google news.
I’ve been doing something similar for a couple of months now.
Do you have a fallback for users without Javascript turned on? Mine is to provide a mailto: URL for them to email me their comment.
My method has also encountered some bugs in the DOM-scripting of forms in early versions of Mozilla/Netscape7.0. DOM manipulations of form elements are not necessarily reflected in the POSTed form. Upgrading to Netscape 7.1 solved the problem for my user … after I un-banned him.
Actually, your implementation suggests some nice improvements …
Jacques, Hashcash/Stopgap doesn’t, but Spam Karma allows email or image verification if a comment doesn’t make it through. That’s the neatest part of the system, IMO. It would be nice to abstract it out perhaps as a separate plugin.
I’m glad the WP-Hashcash version you linked to doesn’t do that redirect – I was looking at the version linked to in the ‘Comment spam is a thing of the past’ post, which does that. Admittedly, the three-strikes plugin also does a redirect, to fbi.gov, which I’m not entirely happy about.
I’m curious, though; why do you say that blocking browsers with javascript disabled (or entirely unavailable) is acceptable? If it’s acceptable to block a small group of Lynx users, for instance, why is it not acceptable to block a similarly small group of people by using a captcha? It amounts to the same thing; both solutions prevent a minority of users from being able to post a comment.
Personally, I prefer to have the risk of some spam get through and allow all users, no matter how they’re browsing, the ability to post a comment than to make sure no spam gets through and block some valid users. But then, I’ve not received any spam at all since I switched from MT to WordPress and installed the three-strikes plugin.
Because people choose to use Lynx; they generally don’t choose to be blind or partially sighted.
Wouldn’t it be better to have it this way?
1) The HTML explains why you can’t comment, and provides an email fallback.
2) The javascript replaces the relevant section of the HTML with the comment form (and auto-generated hash).
?
The hash time-out is an accessibility issue. People using assistive technology take more time (sometimes much more time) to fill out the form. Timing out their hash, and then “assaulting” them with GoogleNews is a very unfriendly way to go about things. (I don’t understand this “assault” thing anyway, a spambot couldn’t care less; it only serves to bother humans.)
Also, text-mode browsers (Lynx et al) are used by some disabled user. EmacsSpeak (the only open-source screen reader) runs on top of a text-mode browser. Now, you could say, “Only a tiny number of blind users use EmacsSpeak. Screw ’em! If they want to surf the web, they should invest thousands in a “real” screen reader that runs on top of Internet Explorer.” But I think that would be a bad attitude to take.
Finally, warning people that Javascript is required should be … umh … required.
While I generally like the idea, the problem remains. I, for example, surf with JavaScript completely disabled. Same with animated gifs. Well, ok, in Firefox that’s merely a simple button that switches JavaScript on again but still. It pisses people off.
There has been a very interesting article (http://www.maccessibility.com/archive/001359.php) which basically claims it’s impossible to tell a human from a computer if you don’t want to exclude some groups (disabled, poor eyesight, …)
I will still rely on manual approving of entries and tools like MT-Blacklist and IP banning, URL filters and stuff like that.
I like the improvements to the logging system–I diff’ed your WP-hashcash with the Spam Stopgap Extreme and saw that the server log (which is actually an email notification system, ideally), redirects, and a (possibly) extraneous check have been removed from the code. Good work!
Elliott, awesome, I can set you up with direct access to the repository too. The next thing I’m working on is having it log to the DB to remove the file permission issues people run into.
Yeah, repository access would be nice. I just upgraded the Spam Stopgap to a new version to make the field elements less predictable, and log based on permission to use fopen, etc. You have my email address here if you want to set me up with access–and I’d be more than happy to try and use subversion!
Could somebody please say how to disable wp-blacklist? Or does the new stopgap plugin bypass it?
Bob, why not ask where you got the wp-blacklist plugin from?
Could somebody tell me, what was wrong here?
Onno. You probably host your site at 1&1? Just make sure the script has write/read access to /blog/wp-content/plugins/spam-stopgap-extreme.log. Use an FTP client that supports CHMOD and just set the permissions to 755. Enjoy!