A workaround has been placed for a problem with the Clearswift Web Policy Engine. Users behind this proxy server are no longer blocked.

A workaround has been placed for a bug in the LiveJournal OpenID process which Six Apart refuses to fix. Logins using OpenID will no longer fail.

A workaround has been placed for bugs in some versions of Internet Explorer and Safari web browsers which caused them to be blocked after leaving a comment on WordPress. These requests are no longer blocked.

A spam prevention feature was causing users to be blocked from their own blogs when they also subscribed to their own feed, or when they accessed the site with multiple web browsers at the same time; it has been disabled for rework.

The 2.0 series of Bad Behavior will be maintained as a legacy branch, with only bug fixes, false positive fixes and security fixes applied to this branch, if any such fixes are needed. No new checks for spammers will be added.

Shortly I will introduce a “development” 2.1 series on a much shorter development cycle, with days or perhaps even hours between releases. In this branch I’ll be experimenting with new spam prevention features, rolling them out quickly and rolling back quickly in case of actual trouble. I’ll also be rolling out a new packaging method which I’ve discussed previously, that will make Bad Behavior even more platform-independent than it currently is, and allow for the “core” to be updated separately from the “glue” which connects it to your host platform.

Once features prove themselves through development and testing to be stable, they’ll be rolled forward into a “stable” 2.2 series, intended for those users who are averse to the risks of blocking legitimate users or having the occasional crash. While I work very hard to ensure that every release, however labeled, does not crash, and does not generate false positives, things occasionally happen which are outside my control.

This parallel development scheme will help balance the needs of the two primary groups of Bad Behavior users.

The first group needs enterprise-grade code which ideally never blocks a single legitimate request and can quickly be rolled into production environments with a high degree of confidence. The tradeoff is the same as it has always been: to prevent any chance of false positives, Bad Behavior’s stable branch will permit some spam, anywhere from 0.1% to 10%, to pass through, and will require a backup solution such as Akismet. Even so, it will drastically reduce the amount of time and money spent managing spam, especially for deployments of dozens or hundreds or thousands of sites.

To serve this class of users more effectively, I’m also studying the feasibility of offering support contracts for enterprise users of Bad Behavior. Services offered under such contracts might include installation assistance, on-call support, hotfix development and deployment, and per-incident support. If your organization may need such a service, stay tuned for more details in the near future.

The second group, I believe, is the majority of Web sites: those for whom a rare blocked user is merely an annoyance rather than a critical problem, and who have much lower tolerance for spam because they aren’t being paid to manage their own blogs, wikis and forums. As much as possible, Bad Behavior’s development branch will limit spam for this class of users to 0.5% missed. The tradeoff is that you will be asked to do what you already do: to report any problems you encounter, whether they be missed spam or blocked users or plain old crashes.

And for users who would like to have their cake and eat it too, the development and stable versions will be installable side-by-side on the same site, and you will be able to switch back and forth between them at the click of a button.

Finally, prior to the first stable 2.2 release, I will be reworking all of Bad Behavior’s documentation and moving Bad Behavior from its current home to a new site dedicated solely to Bad Behavior. So you all will have to update your feed URLs to the new location soon. (Mailing list readers won’t have to do anything.)

In the meantime, Bad Behavior remains a user-supported project, with all code released under the GNU General Public License. If you find Bad Behavior valuable, please consider making a financial contribution. I develop Bad Behavior in my limited spare time, and every contribution means I can devote more time to its development.

Second, it looks like I need logs from a different set of countries than those originally posted.

If your blog is hosted in any of the following countries, or has readers from these countries, then I need your verbose logs: Belarus, China, Hungary, Iran, Malaysia, Qatar, Romania, Russia, Saudi Arabia, Singapore, Sri Lanka, Switzerland, Ukraine.

All data submitted will be held in strict confidence, in encrypted storage, used solely to develop the software, not shared with anyone else, and destroyed within 90 days.

I still also need your verbose logs, regardless of country, if you have previously had problems with people unable to access your blog while at work, but who can reach your site at home when you used Bad Behavior’s strict mode.

To enable verbose logging: Go to Options > Bad Behavior, and tick Verbose logging. Let it collect data for two full business days (Monday-Friday). Then use your web host’s phpMyAdmin to export the log: Select the wp_bad_behavior table, click Export, click SQL format, and then Download to your computer. E-mail the .SQL file to badbots at ioerror dot us. You can then disable verbose logging if you wish.

Thank you for your help! This data will help stop more spammers while ensuring that legitimate readers are able to read your blog and leave comments without trouble.

“Online risks are becoming more complex and pervasive by the day,” says the home page of the Cyveillance web site.

Indeed, one of the risks is that your Web site might be targeted by Cyveillance.

The company says that it crawls the Internet looking for phishing scams, identity theft, illegal credit card numbers, trademark and copyright infringement, and more. It’s also been known to work on behalf of the government to spy on whistleblowers who expose waste, fraud and abuse. Some have even alleged that Cyveillance bots attempt to illegally hack into Web servers.

Cyveillance uses robots which crawl your Web site pretending to be a legitimate Web browser and completely ignoring your robots.txt file. Then it tries to figure out whether you’ve downloaded any illegal music, or said something bad about some company. It then sends you threatening letters ordering you to take your site down, even when you haven’t done anything wrong.

By relying on analyzing the HTTP requests themselves, rather than simply the IP address, Bad Behavior has blocked Cyveillance almost from the very first release last year, regardless of what IP address range they move to in order to hide their connections. An audit of six months worth of logs shows that Bad Behavior was able to successfully identify and block Cyveillance bots even when they used previously unknown IP address ranges.

Blocked requests will be subject to a two-second delay before a response is sent. (See below.)

Some blackhole lists previously used in Bad Behavior have been scaled back or removed.

The address for the Bad Behavior Blackhole has been added. (See below.)

Some new spambots have been identified and blocked.

In recent days spam attacks have been on the rise, with one especially obnoxious bot delivering requests so fast that some sites have been taken offline by them. While the requests aren’t especially numerous or resource-intensive, the most common software used by Web hosting providers is very inefficient at serving dynamic pages such as PHP-based Web sites. So even a moderate number of requests can take a whole server down, or lead the hosting provider to take the site down before the whole server goes down.

Bad Behavior now counters this by introducing a short two second delay to blocked requests, before the HTTP response is sent. Since most spambots wait for the response before going on to the next request, this should sufficiently slow down most of the overly aggressive spambots and give Web site operators some breathing room. While I would have liked to put in a delay of a minute or more, there remains the slight chance that an actual human being would be blocked, and they should be able to get a response back in a reasonable time.

With respect to realtime blackhole lists, all of the existing lists target e-mail spam, and since spambots who send link spam are almost always also sending e-mail spam through the same servers, these are a fairly effective means of blocking link spam. However, since they target e-mail spam, they also block legitimate users. The primary issue here is that while an IP address may be added to a blackhole list quickly, it is not removed quickly — or at all — once the spam stops. Thus, people with dynamic IP addresses are unfairly blocked because some other customer was sending spam.

Bad Behavior Blackhole, which should go online within the next few weeks, is designed specifically for link spam. It adds IP addresses to its database quickly when actual spam is received, and in addition, drops the IP addresses once the spam stops. This helps prevent dynamic IP customers from being blocked because another user’s computer was sending spam. Once Bad Behavior Blackhole is online, all other realtime blackhole lists will be dropped from Bad Behavior.

As always, if you find Bad Behavior valuable, please consider making a financial contribution. I develop Bad Behavior in my spare time, and every little bit means I have more spare time to devote to its development.

The forthcoming release of WordPress 2.1 includes internal changes which may cause some plugins to stop functioning. Such plugins will need to be upgraded along with your WordPress 2.1 upgrade.

Bad Behavior 2 has been checked against these changes and found to be ready for WordPress 2.1 without any changes required. Users upgrading to WordPress 2.1 do not need to upgrade Bad Behavior for compatibility.

Versions prior to 2.0 are unsupported, have not been checked for compatibility and will not be checked. Any remaining version 1 users are strongly urged to upgrade to a current release as soon as possible.

I’m now working on improved spam detection for certain circumstances where enabling Bad Behavior’s strict mode would block the spam, but would also block legitimate readers of your blogs.

For this work I need verbose Bad Behavior logs from some of you, in order to analyze the legitimate readers and differentiate them from spammers.

All data submitted will be held in strict confidence, in encrypted storage, used solely to develop the software, not shared with anyone else, and destroyed within 90 days.

If either you or most of your blog’s readers are from any of the following countries, then I need your verbose logs: China (not Taiwan), Qatar, Saudi Arabia, Singapore, Switzerland, United Kingdom.

I also need your verbose logs if you have previously had problems with people unable to access your blog while at work, but who can reach your site at home, regardless of country, when you used Bad Behavior’s strict mode.

To enable verbose logging: Go to Options > Bad Behavior, and tick Verbose logging. Let it collect data for two full business days (Monday-Friday). Then use your web host’s phpMyAdmin to export the log: Select the wp_bad_behavior table, click Export, click SQL format, and then Download to your computer. E-mail the .SQL file to badbots at ioerror dot us. You can then disable verbose logging if you wish.

Thank you for your help! This data will help stop more spammers while ensuring that legitimate readers are able to read your blog and leave comments without trouble.

This is wonderful news because it means I have the potential to pull in a large number of new readers to my flagship blog, increasing my revenue and freeing up more time for me to work on Bad Behavior. (A new release will be out in the next few days.)