By DanZ on

As I prepared to turn on comments and forums, I researched the anti-spam techniques out there for Drupal. There are a lot of great tools, but then it occurred to me: There is a lot of redundancy, and no coordination. See the wonderful list of anti-spam modules.

Would it be a good idea to have a module to coordinate all of these modules, and bind them?

It seems that all of these modules do some or all of the same basic five things:

  • Detect spammy behavior (especially bots).
  • Block spammy behavior.
  • Cache information about potential sources of spam.
  • Report sources of spam to a central repository.
  • Clean up spammy accounts and content.

Now, they all do this in different ways, particularly the detection part.

However, it seems to me that there could be some sort of "Grand Central Bad Behavior Blocker" (GCBBB) module. It would coordinate all of the actions above amongst different modules. Individual modules would provide one or some of the above services, but wouldn't need to provide all of them.

For instance, stopforumspam.com provides both HTTP and DNS lookup of potential spam sources, and an API for reporting spam. A module could provide interfaces to just these three services. The GCBBB could actually call those services at the appropriate time and use it to block or clean up bad behavior.

Note: The Spambot module currently interfaces with stopforumspam.com. It offers account/content cleanup, but that feature isn't available to other modules.

Another idea: Many bot-detection techniques involve injecting additional fields, CSS, and submit functions into forms. A GCBBB could make it easy to choose which forms to use and, in the case of multiple techniques, the priority of the submit functions.

A common unified admin GUI would be a blessing, too.

Done right, this would allow Webmasters to mix-and-match or tune different services and customize their anti-spam to exactly what they need.

While spam is certainly the most prominent, there is other behavior that ought to be blocked. If some bot tries a cross-site scripting attack, you probably want to block it right away, even if the attack failed. Why wait for that attack script to succeed? A flexible GCBBB would make it easy to add protection for new attacks without having to develop a whole new framework.

Frankly, the Internet is a dangerous enough place that I'd like to see this sort of thing built into Core, just to make it easy to protect your site. That probably won't happen any time soon, but it's something to think about.

Thoughts?

⋅ Categories: Drupal 6.x, Drupal 7.x, Drupal 8.x

Comments

nevets’s picture

nevets commented

My first thought is no. The modules use different approaches and not all of them are likely to work together. And there are always newer (and hopefully better) approaches that I would rather see as a new module and not part of something monolithic.

DanZ’s picture

DanZ commented

And there are always newer (and hopefully better) approaches that I would rather see as a new module and not part of something monolithic.

Hmm. It wouldn't be monolithic (as I understand that word). Rather, the opposite. It would be the sum of many small, independent parts.

Maybe I didn't explain it well enough, but the point of the proposal is to make it easier to develop new methods. Each new method would just go into a "plugin" module that would add functionality to the GCBBB.

So, if you come up with a new way to detect spam, you write a module that only detects the spam. Your module doesn't have to duplicate all the functionality for reporting, blocking, or erasing the junk, because that's already done in other modules, and the GCBBB lets them all work together.

Think of it as shared infrastructure. If you want a way for people to vote on their favorite pop music tunes, you don't start by re-inventing the Internet.

--
www.ztwistbooks.com. Math books that are actually fun.

jrwilson’s picture

jrwilson commented

+1

Veerendra Darakh’s picture

Veerendra Darakh commented

I do not know the practicality of the proposition but conceptually you are right. One grand anti spam module is the need of the hour.

It can have sub modules which can be invoked as per need.

Hope somebody make it.

Regards,

Veeren

john_b’s picture

john_b commented

Anyone interested in this topic should be aware of some issues discussed in the Botcha,module issue queue e.g.
http://drupal.org/node/1847632
http://drupal.org/node/1880300

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

geerlingguy’s picture

geerlingguy commented

Honeypot maintainer here.

I think this sounds like a good idea, kind of a 'Spam API' module, or something along those lines. However, I think it would end up being quite an undertaking. BOTCHA already has a 'pick your flavor' approach (though all the 'flavors' are built in), and it's a good option for site builders who want to try some different vectors quickly.

For Drupal 8+, it might even be time to consider trying to use/develop external components for spam prevention, to whatever extent that's possible. Spam is a universal problem, so anything we could do to make it so our work syncs up with the webdev and PHP community at large is a major win.

With Symfony components landing soon, maybe this will offer this ability somewhat out of the box. For D6 and D7, I definitely don't see the current spam prevention module landscape changing. Probably not D8 either.

__________________
Personal site: www.jeffgeerling.com