Archive for October, 2005
Last week I told you all about Automattic Spam Stopper, the new anti-spam solution for WordPress from Matt Mullenweg. There’s been some new news, and you’re going to hear it here first.
First off, the plugin has been renamed to Automattic Kismet, or Akismet for short.
Second, it now requires a WordPress.com API key, which you can find on your WordPress.com Profile page. (Click My Dashboard, then Profile.) If you don’t have a WordPress.com account, you won’t be able to use Akismet at this time, until you somehow finagle yourself an account. The fastest way is probably to use Flock. You don’t actually have to blog at WordPress.com to use Akismet, you just need the account to get the API key. You can use the API key at more than one blog, too.
Matt plans to have Akismet free for personal use, and charge “pro” bloggers $5 per month for the service. He’s defined pro bloggers as anyone making over $500 per month from their blogs. He also has a program set up for large enterprise installations, though I only know of one customer for that right now. However, anyone who participated in testing Akismet prior to today will be grandfathered in and have a free enterprise account forever.
Akismet is surprisingly effective at stopping spam. After having built a sufficiently large corpus of spam to draw from, it’s killing about 99.9% of incoming spam, and has a false positive rate less than 0.1%. However, when the central service goes down, all comments go into the moderation queue. The service has had some downtime, and on the sites where I’ve been testing Akismet, I’ve had to watch the moderation queue fairly closely. Matt says he’s working on new more reliable hosting for the service.
So where does Akismet fit into the overall spam prevention picture?
Akismet has a great advantage over most anti-spam solutions: by seeing incoming spam from all over the Internet, it can identify new spam very quickly, perhaps as soon as seconds after a spam run begins, once it’s in wider usage. It also is better in spam management, having to sort through hundreds of spams to find a legitimate one that might have been blocked by mistake. It presents spam in a compact format that makes it pretty easy to scan through and spot legitimate comments.
However, Akismet has a couple of drawbacks which are common to most anti-spam solutions for WordPress, and a couple of unique drawbacks of its own. The obvious ones are that it’s a for-pay solution for many people who might want to use it. It uses a central server which is subject to downtime. Though Matt hasn’t said much about the secret sauce, it definitely analyzes the content of incoming posts. And finally, it does nothing to keep the spammers from using up your bandwidth and database space.
For most people running a personal WordPress blog, Akismet is the ideal second line of defense. It will entirely replace plugins such as wp-hashcash, Spam Karma 2, AuthImage, etc. In fact, it makes most other anti-spam plugins entirely redundant.
The one anti-spam plugin which Akismet will not make redundant is Bad Behavior. There are several reasons for this. Bad Behavior is a first line of defense, stopping spammers before they can read your site at all, waste your bandwidth, or drop junk in your database. This is especially important for self-hosted sites, or sites hosted on dedicated or virtual dedicated servers, where CPU time and bandwidth are precious. Like most other anti-spam plugins, Akismet does not and cannot conserve its users’ bandwidth, CPU and disk usage from a spam attack. Bad Behavior does, meaning it will continue to be an integral part of most people’s anti-spam arsenals.
You may not think this is important, especially if you have never received a large amount of spam at once. But the day is coming when you will, and having that first line of defense can mean the difference between your site staying up, and your Web host shutting off your site. Spammers can easily hit you so hard as to create denial-of-service conditions, and Bad Behavior has been proven to mitigate this effect. In fact, it’s even stood up to the Slashdot effect without blinking.
I should disclaim at this point. I am involved in the development of Akismet, having rewritten a significant amount of the code from the time it was known as ASS, and integrating CJD’s Spam Nuker into the plugin. I continue to remain involved with Akismet as long as there’s work to do on it (and there are a couple of bugs I need to fix).
As I said yesterday, however, I remain committed to the development of Bad Behavior. It is still sorely needed as a first line of defense for WordPress, not to mention all of the other platforms on which it now runs.
What the future holds? Nobody can say for sure, but I predict that for WordPress users wanting to remain spam-free, the combination of Akismet with Bad Behavior will prove to be a double whammy to blog spammers. For everyone else, Bad Behavior remains the first line of defense, and Matt has said that Akismet could be ported to other platforms as well. Someone else, I think, will have to take up that challenge. My hands are full already. 
P.S. Matt’s started a web site for Akismet, where you can find more information.
Update: Bad Behavior 2 development is on hold indefinitely. Find out why and how you can help.
Yesterday I said I was beginning work on Bad Behavior 2.0, the next generation of the Web’s premier link spam killer. And I did. I wrote some ten lines of code.
Before I go into the roadmap, I have to diverge a bit and explain something a lot of people may not be aware of.
Bad Behavior is open source software, released under the GNU General Public License, which you can find copies of all over the Internet, or included with the program. You don’t have to pay a cent to download or use it. However, developing it still costs me time and money, which is why it can go so long between minor releases. Unless (until) some cash comes in, it doesn’t get updated except in cases of dire emergency. Which only happens if I ship code with a typo in it, or Microsoft changes their search engine, or something like that.
I have hundreds of comments and trackback pings from users all over who have virtually eliminated their spam problems with Bad Behavior. And every so often, someone does click the nice PayPal button, to send a few bucks my way. Both are very much appreciated.
Killing blog spam has been mostly a labor of love, however, rather than cash, and as such, has to take a back seat to other more pressing concerns, like anything that generates revenue.
So what I’m going to do here is outline my roadmap for Bad Behavior 2.0, invite you to comment on it, and if you want to see it come about sooner rather than later, to vote with your dollars, pounds, euros, or whatever you have. The amount is blank, so fill in whatever you feel is appropriate.
And if you see any problems with it, or think it could be improved, you can comment on it as well.
First off, Bad Behavior needs to be even more modular than it is currently. Version 1 proved fairly easy to integrate into diverse PHP software packages with differing requirements for their plugins or modules, but it seems like each package requires something different. For version 2 I will have a structure put together to allow Bad Behavior to drop in much more easily into packages such as DotClear and Geeklog, where the plugin architecture is quite different than everything else. This will also have the side effect of opening Bad Behavior to porting to even more software packages. This will be the largest design change in version 2.
Second, Bad Behavior needs to deal with the database more intelligently. In version 1, I kept a log of requests which had been denied, expanded it to optionally include all requests, and expanded it again to include the reasons for denial. Then I started using the information in the log to make decisions. Version 2 will feature a complete redesign of the database table, and expansion into two tables, one strictly for logging (for you to stare at), one strictly for making decisions. I expect to gain significant performance improvements thereby, as well as being able to make more intelligent decisions on which requests should be allowed and which should not be.
Third, Bad Behavior’s API needs improvement. It started as a simple generic interface, and has already outgrown that interface. Version 2 will feature a completely redesigned API for integration into the host PHP program, offering more flexibility, and hopefully the ability for the host program to provide services to Bad Behavior, such as statistics and log viewing.
Fourth, that error page needs to be reworked. Most legitimate users unfortunate enough to see the page, have no idea what to do, even though the page does provide suggestions. It needs to be shortened, clarified and contain links to expanded information sources so that users can solve the problem on their own whenever possible. It should also customize the message based on the specific reasons for denial. Though the ideal is that Bad Behavior should never present the page to a legitimate user — only to spammers.
Along those lines, the 412 error code will be changed. Bad Behavior 2 will attempt to deliver the most appropriate error code to the denial circumstance. In some circumstances, version 2 will return a 403 error. In others, perhaps a 412. In one case, a 417 is appropriate.
Fifth, Bad Behavior needs to provide better tools for site administrators to search for and eliminate any false positives that may arise. While version 1 contains whitelisting capability, it’s not easy for a site owner to determine why a particular request was blocked, due to being unable to find it in the logs. Version 2 will provide a unique key to each denied request which the site owner can use to immediately find the problem, if any, and take any necessary corrective action.
Finally, Bad Behavior must continue to keep up with spammers as they attempt to adapt and find new ways to post their automated garbage. To date, this has been at most a minor issue, as there is only so much the spammers can do, while maintaining their high rates of spamming (10,000 or more posts in a single run is not unusual). Bad Behavior attempts to drive up the cost of link spamming, by blocking as many of those spammy requests as possible, forcing the spammers to resort to MUCH slower manual methods, or ideally, give up and find more honest work.
This is my vision for Bad Behavior 2. All things being as they are right now, the timeline for all this is anywhere from one to six months. How quickly it gets done depends on you.
Without any further contributions to Bad Behavior development, I’ll work on it in my limited free time, and it’ll take somewhere around six months. If I were to receive, for instance, $500 in contributions, I could devote a significant amount of time to it, and complete it within the next month. Hey, don’t laugh, that’s only a few cents per user.
If you think this roadmap looks good, and want to accelerate the development of Bad Behavior, contribute financially and I’ll be able to devote more time to it, meaning version 2 comes closer to reality sooner. And by all means, if you think I left something out that should be in version 2, please let me know. And yes, I know a lot of you are flat broke, so even if you are unable to contribute financially, leave a comment. Say hi, or suggest changes, or something, just so that I know you’re there and you think I should continue this project.
Bad Behavior 1.2.3, the latest release of the Web’s premier link spam killer, has been released.
From version 1.2.2, the following changes have been made:
- Several additional spambots, mostly causing trackback spam, have been fingerprinted and blocked.
- Bad Behavior 1.2.2 introduced a requirement that user agents present a User-Agent header. This caused quite a few unexpected things to break, and has been changed in this release. A User-Agent header will now be required only for POST requests.
There were a couple of other changes and enhancements I wanted to put in, but I decided to let them wait; I’ve begun work on version 2.0 of Bad Behavior, which will incorporate these changes. If you e-mailed me and didn’t see your change in here, this is why.
Anyways, it’s that time again, so download Bad Behavior now!
We see them every day, and usually we make fun of them.
They’re the stupid. The daft. The incompetent. The people who can’t seen to find their way out of a wet paper bag.
Some examples:
People looking for a job application for Target or Walmart (I misspelled that on purpose; if you’re really curious, ask me why, but not in comments) and can’t comprehend the simple fact that the applications simply are not online.
The people so high on methamphetamine they apparently didn’t realize they were smoking right in front of a police station.
The stupidity of government officials and the stupidity of phone companies.
I could go on and on and on and on and on and on and on and on and on and on and on and on and on and on and on and on and on and on and on and on. But I won’t.
The question of the day is: How do we make people less stupid? Is it even possible?
What’s wrong with our world, that so many people live their daily lives in a fog of stupidity?
Recently, Matt Mullenweg, creator of WordPress, had a bright idea on how to stop blog spam. He wrote up some code, distributed his new WordPress plugin to a small group of testers, and so was born the so-called Automattic Spam Stopper, or ASS.
I was able to obtain a copy of Automattic Spam Stopper for review and made a quite disturbing discovery, namely, how it works.
Whenever a user makes a comment to your WordPress blog, ASS forwards a copy of the entire comment, the metadata such as username, email address and URI, as well as your blog address and Web server environment variables, to a central server for analysis. The server then returns the response “true” if the comment is judged to be spam.
Mullenweg isn’t saying what the “secret sauce” is for the server, so as to frustrate the spammers. “By the time we’re done spammers around the world will quiver in their boots,” said Mullenweg.
So how does the server determine what’s spam? Users of the plugin submit copies of any spam they receive by marking them as spam in the WordPress administration panel. ASS then forwards copies of these to the server for analysis.
The submitted spam, however, remains in your database, but hidden from view. This could cause resource constraint (disk space) problems, and backup/restore problems, for many users, especially after time. WordPress does not automatically remove spam from its database, and does not provide any method for removing it from the database. A third-party plugin, however, does provide this function.
Right now Mullenweg inspects all comments submitted this way manually, before the server considers them to be spam. If he judges them to actually be spam, then they are added to the server’s corpus, or database of submitted spam.
He has not said, however, whether legitimate comments are kept on the server, or whether anyone else looks at the submissions. Thus, ASS may not be a good anti-spam choice for private blogs, or for blogs which frequently use password protection to limit access to their contents. In a very real sense it comes down to whether you trust Matt Mullenweg with your readers’ comments. Some people will, and others won’t.
Mullenweg envisions ASS as a service which is free for personal use, and paid for business use. “I would be more comfortable with something where it was free for regular people, and only businesses or enterprises paid (enough to support everybody),” he said.
“There may be ‘keys’ or accounts at some point to prevent abuse,” he said. “However the plugin and API are designed to be pretty easy to recreate, so if someone wanted to run their own spam [prevention] service they could easily.”
That much is true. I could create a server to do this in rather short time. And I almost did. It’s been an idea that’s been discussed before among WordPress anti-spam gurus, and ultimately rejected.
To date no one has been able to provide a centralized server solution which ensures the integrity of the database, for instance. Mullenweg ensures the integrity of his database by inspecting all comments manually, but this “solution” doesn’t scale very well, and is untenable once ASS is released to a wider audience. He has proposed that users be registered and receive keys in order to use the service, but even this doesn’t prevent spammers themselves from registering and submitting garbage to the database.
In addition, no one has been able to provide a centralized server solution which ensures the privacy of users whose comments are subject to this sort of analysis, especially with respect to private blogs and password-protected posts, where users expect their comments to be private. I’ve come up with an idea or two on how this might be done, but I’m not sharing until I’m certain it really can be done; if it were really that easy, it seems that someone would have done it already.
Now if Mullenweg can solve the problems of privacy, integrity, scalability, and those gigabytes of spam clogging up his users’ databases, he may be on to something. But everyone else who’s had this idea ultimately scaled it back or dropped it entirely. I fail to see how Matt’s ASS is any different.
In the meantime, if you’re looking to stop spam without compromising your users’ privacy, consider Bad Behavior, which is shockingly effective despite not looking at the content of comments at all, and Spam Karma, which does, but doesn’t send the whole comment, and much of your server information, off to who knows where.
Update: Some other reviews of Automattic Spam Stopper:
