@geerlingguy Let me invite you to our dream-team of non-CAPTCHA (ie invisible to end-user) spam fighters:

Don't you think that together we could do more than each alone? We miss you, geerlingguy.

Here you are some points why you should join us:

  • Extendable and configurable protection: Each way of spam protection is a Recipe, which has its own logic of form submission handling. Recipes are bundled into Recipebooks, which are applied to the forms. The list of available recipes: http://drupal.org/project/botcha#recipes-included.
  • Selenium-tests for all major browsers (Firefox, Google Chrome, Opera, Internet Explorer plus possibility to extend): It means that JavaScripts-recipes work as expected - always, guaranteed. If you see something strange - you could just launch all Selenium-tests to see what's wrong and post an issue to Drupal.org. Brief Howto-instruction (both installation and usage of Selenium) is inside the Selenium-tests file.
  • Handy UI: UI lets you to turn on or off recipe applying per each form. It helps to avoid critical situation when one or more recipes doesn't work as you like: you should just turn them off and post an issue to Drupal.org - and your site would not be affected by any discomfort.
  • Fully test-covered: Tests covered almost every line of the code. Plus tests' structure has been unified - and now it is really simpler to maintain it.
  • OOP-style: BOTCHA is moved to OOP-architecture. It means that all "entities" that take part in BOTCHA functionality are turned into classes. That gives more flexibility to extend and freedom to modify.
  • Like MVC-application: The module's internal structure looks like real MVC-application. It gives a chance to separate logic of the application and the layer of interoperability with Drupal platform - that means that the BOTCHA is going to become more version-independent. I hope in the future we would see a Drupal-version-independent BOTCHA module. It eases maintainership of the module.
  • Module as an Application: Each hook implementation is a method of Botcha class, which extends abstract Application class. Turning a module into a class gives a lot of opportunities, such as applying "Decorators" (see http://en.wikipedia.org/wiki/Decorator_pattern) to a module as a whole. For now we have Logger decorator implemented (Logs every method call into a file - for development purposes, turned off by default), Cacher is planned. See Moopapi project page for more details: http://drupal.org/project/moopapi.

Please try BOTCHA yourself - and tell us what do you think about our offer.


geerlingguy’s picture

Status: Active » Postponed (maintainer needs more info)

I'm inclined to mark wontfix, for the following reasons:

  • As a site owner/maintainer for ~25 sites (most small/medium blog-style, but a few very large community sites), I have found this module on its own to be as effective (and sometimes more effective) than services like Mollom, not to mention CAPTCHAs and other punish-the-user types of spam prevention.
  • The honeypot + timestamp spam prevention methods are both extremely simple, and require no extra JS or the extra overhead of a do-everything module to work.
  • This module is already well-tested (full SimpleTest coverage of all important functionality), works great on Drupal 6 and Drupal 7, has a solid API which allows sites like drupal.org to implement even stronger custom spam-prevention measures, and has very few open issues/bugs.
  • This module has ~3,000 active users, and I need to make sure that any module I merge this module into has their best interests—reliability, effectiveness, simplicity, and stability—in mind.

I like the idea of having 'one spam prevention module to rule them all', but I think having some simpler, more focused options (rather than aggregating everything into one very large module) is more appealing to many site developers, especially in terms of possible performance/codebase costs and usability.

Might I be wrong? Maybe. I'd like to hear from some other people who might have more input (and experience in merging widely-used contrib projects) about the best way forward, before trying to merge Honeypot's simple spam prevention methods into (what I see as) a much more complex module with not as many users, and many more issues to suck up developer bandwidth.

Not marking this as closed, but will mark postponed for now so it's out of my 'need to do' list.

iva2k’s picture

Jeff, Thanks for good and thoughtful points, thanks for taking time to think about it.

To respond to some points:

  • Botcha is transparent to the user, so it is intended to retire Captcha. Power of Botcha is in multiple recipes. No one thinks putting 2 or more Captcha's is a good idea (users would hate your website, even 1 Captcha is pain in the butt). Botcha can have 1000 recipes on one form if needed - users are not bogged by that. Mollom is still a good addition as it works as last line of defense against human spammers with their wigs and knock-off handbag backlinks.
  • Admin gets a lot of flexibility, but out of the box the settings are very sensible, so it has small setup cost (install and forget)
  • Protection needs to evolve as spambots do evolve (they are made by very motivated and quite skilled people). I observed a full session of a person crafting a spambot script on the newly Botcha protected site (it was a nightmare - 200 posts / hr passing both Captcha and Mollom). Botcha stopped the flow to 0. He spent a whole bunch of time trying and figured it out! 1 of 10 hits were submitted (still not bad for Botcha). I simply changed the security key which broke his scripts right away. He did another debug session. I should mention that it took a good part of the day for him and 5 seconds for me. After he penetrated again, I added a new recipe. He was gone. This is a model for Botcha to be long term solution. A fixed recipe will sooner or later be broken. We need a lot of variability and that is what Botcha does. Recipes are parameterizable and you can have 1 recipe applied 10, 100 times with different parameters. Try to reverse engineer an encryption algorithm and security key - need a lot of intellect and processing power. But then the algorithm itself changes - toughest problem to solve.
  • honeypot sounds like one of Botcha's existing recipes
  • timestamp sounds like timegate recipe in Botcha

I also want to get some perspective from you:

  • how much time would it require to patch this module when there is a spambot script that breaks it and posts 200 spams/hr?
  • if this module would be used by some very high profile website (think Yahoo or Facebook or Google) - it will attract very motivated spammers. What would it take them to figure out the protection scheme and break it? How the dynamics would look like (their time to break vs. admin time to close the hole)?
  • what update model do you think your users would appreciate when they get hit with a wave of spam?
  • do you have any thoughts on monetization or business out of it? (private response is preferred).

I totally agree with the point that users are ultimate decision makers here. Their first priority is a 100% working code. Stable module has a huge advantage. Frankly, Botcha has some open issues that may raise concerns right now. But that's exactly the reason for combining forces - all non-Captcha bot protection modules need to get through the same hurdles. We can use your experience in fixing remaining issues. I'm sure you can use our help too. Migration to Botcha won't be too easy - it is not shutting down the module and leaving people with no choice. I think we should let you propose a sensible plan (including measurable gates, i.e. when next step is ready) if you decide that it is a good idea. The implementation of the plan - we have a motivated team to work on it.


geerlingguy’s picture

Title: Merge with BOTCHA » Consider consolidating Honeypot into BOTCHA
PatchRanger’s picture

Status: Postponed (maintainer needs more info) » Active

Let's continue discussion, since BOTCHA got full Selenium-tests coverage for all recipes, both for D7 and D6: see #1894478: The latest Selenium-tests launches & reports for details.

geerlingguy’s picture

Status: Active » Postponed

It looks like you're making some good progress on the module, and it does look like a great solution. I still have a few concerns, though:

  • The module is pretty far-reaching. For my purposes, I really like Honeypot's simplicity...
  • The Honeypot recipes in the BOTCHA module seem to rely on JavaScript (as do most other recipes); this module (Honeypot) doesn't use it at all, really. There are positives and downsides to that approach, but the simpler non-JS methods used by this module (Honeypot) seem to be well-validated by a variety of real-world tests, drupal.org and flocknote.com to name a couple...
  • The link to donate for issue completion on BOTCHA's project page concerns me, for two reasons:
    1. It seems to imply that the module won't be well-maintained without financial incentives for the maintainers (this grates on my open-source development ideals).
    2. It uses a solution that doesn't seem to be used by any other Drupal modules/maintainers (I've seen some people post a simple "tip jar" link to PayPal or ChipIn, but nothing more, really).

I'm still willing to entertain the idea of folding development into BOTCHA, but I am definitely not considering it for the D7 development cycle. Perhaps by the time D8 comes around.

geerlingguy’s picture

Status: Postponed » Closed (won't fix)

Staratel / iva2k: Thank you again for the offer, but I think I'm going to decline the merger at this time, mainly for the reasons I outlined above; I think there's a place for a few different spam prevention modules that do similar things, but in slightly different ways.

I'd like to keep Honeypot more nimble and focused on one method, and I think there's a value in having a few different CAPTCHA-less modules available on Drupal.org, as long as they're all well-maintained. I've added a link to BOTCHA in the 'Alternative Modules' section.

I think after Drupal 8 is fully released, and the module landscape settles down, I'll be thinking about what's next for this module, and maybe at that time it would be good to consider joining forces in some way. But for now, I'm going to mark this issue closed.

geerlingguy’s picture

Issue summary: View changes

Added Extendable protection point.

crystaldawn’s picture

Thanks for this decision to keep honeypot separate. It was the right decision and I'm glad to have selected it for integration with my own cbp module which provides honeypot integration if the honeypot module exists :) I like it's lightweightedness vs something like a one module to rule them all mentality. Linux wasnt created with the one ring mentality but windows was. Which one is more stable? IDK, debatable maybe, but I'll place my chips on Linux and it's small pieces that create the OS itself thats for sure :) Bigger isnt always better.

geerlingguy’s picture

@crystaldawn - well, hindsight is always 20/20, but BOTCHA seems to have had a lot of steam initially, but it died out relatively quickly. Don't know if that was because the 'PatchRanger' setup that was supposed to help fund ongoing development never really got off the ground, or it was something else, but I think Honeypot does everything that most sites need and isn't needlessly complicated :)