Comment Spam is a thing of the past

Roy Schestowitz | December 27th, 2004 @ 11:29 pm

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!

Matt | December 27th, 2004 @ 11:37 pm

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.

paul haine | December 28th, 2004 @ 1:22 am

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.

Matt | December 28th, 2004 @ 1:38 am

“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.

Jacques Distler | December 28th, 2004 @ 3:30 am

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 …

Matt | December 28th, 2004 @ 3:42 am

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.

paul haine | December 28th, 2004 @ 3:45 am

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.

the absent student | December 28th, 2004 @ 10:44 am

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?

Because people choose to use Lynx; they generally don’t choose to be blind or partially sighted.

David Barrett | December 28th, 2004 @ 11:46 am

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).

?

Jacques Distler | December 28th, 2004 @ 12:13 pm

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.

kitten | December 28th, 2004 @ 2:04 pm

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.

Elliott Back | December 28th, 2004 @ 8:11 pm

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!

Matt | December 28th, 2004 @ 8:24 pm

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.

Elliott Back | December 29th, 2004 @ 1:15 pm

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!

Rev. Bob | December 29th, 2004 @ 5:58 pm

Could somebody please say how to disable wp-blacklist? Or does the new stopgap plugin bypass it?

Matt | December 29th, 2004 @ 6:03 pm

Bob, why not ask where you got the wp-blacklist plugin from?

Onno | December 30th, 2004 @ 9:02 am

Could somebody tell me, what was wrong here?

Warning: fopen(/home/www/htdocs/domain.de/blog/wp-content/plugins/spam-stopgap-extreme.log) [function.fopen]: failed to create stream: Permission denied in /home/www/htdocs/domain.de/blog/wp-content/plugins/spam-stopgap-extreme.php on line 82 File “/home/www/htdocs/domain.de/blog/wp-content/plugins/spam-stopgap-extreme.log” failed to open

kitten | January 1st, 2005 @ 4:13 pm

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!