Add a honeypot to help detecting bots

Per our call we also need to rename 'post_honeypot' to just 'honeypot'.

Some reading:

• http://ploum.net/post/150-the-invisible-captcha-mechanism-icm-against-fo... suggests that one should randomize the names of all form fields, including the one from the hidden field. If you don't randomize the names of the form fields, bots will by-pass the CAPTCHA as they use a record-replay technique. Needless to say, this is really hard to do properly given that it impacts CSS/theming. Plus, if we simply use the 'element-invisible' class, spammers can easily identify the hidden form field.
• http://csswizardry.com/2010/10/in-response-to-invisible-captcha-to-preve... suggests that it creates accessibility problems. That seems to make sense because the 'element-invisible' is usually used to show things to visually impaired users. In other words, we should assume that screen readers will present the hidden CAPTCHA field to visually impaired users. Users that don't use CSS will be exposed to all of the honeypot fields. Best to label the fields so that these users will leave them untouched. As long as no text is entered into them, the form will submit just fine.
• http://nedbatchelder.com/text/stopbots.html provides a great summary of the 'space'. It also describes a mechanism to build a bot-proof form. The field names on the form are all randomized.
• Most people that don't randomize fields seem to use an 'email' field. I think that make sense -- it is more universal than 'homepage'.
• All blog posts that I read on this subject seem to be from the 2007-2008 time frame. Haven't read any recent success stories using this trick. It might be worth trying this on a test site to see if it actually would work. As a first step, we could leave out the server communication and do the verification step locally. That should allow us to make progress.

A few comments from an accessibility perspective.

1. Can we omit .element-invisible completely and just go with display:none ? This has the benefit of only presenting the form field to users with CSS disabled. Do spam bots use CSS?
2. Using .element-invisible means that screen-readers will have access to the fields, not that big of an issue if labeled appropriately.
3. Using .element-invisible on a focusable element causes a focus black hole for keyboard only users, which is why .element-invisible.element-focusable was added recently to D7 system.base.css. Of course doing this we need to somehow make the label (currently not using a label) appear when the input field appears.

+ // @todo Ping accessibility team to confirm that this is correct.
+ '#title' => t('Leave this field blank'),

This seems like good text, but I question if it will in fact be confusing, despite its simplicity. E.g. my first question is "why?" and "am I understanding this correctly? surely they don't want me to leave it blank".

+ // @todo #title_display 'attribute' does not work for #type textfield... grumble.
+ '#title_display' => 'attribute',

Nor will it in D7, already an open issue for D8 to ensure that attribute can apply to all native form input fields

Applied on buytaert.net for testing.

For insight on why #title_display cannot be used with types other than radio and checkbox see #558928-182: Form element labeling is inconsistent, inflexible and bad for accessibility

Looks great! I think we're really close to getting this committed.

+++ mollom.module	15 Oct 2010 13:01:41 -0000
@@ -1676,6 +1703,26 @@ function mollom_pre_render_mollom($eleme
 /**
+ * Form submit handler to clean up internal Mollom values from $form_state['values'].
+ *
+ * Various forms happen to blatantly take over $form_state['values'] and save
+ * that into the database. This form submit handler is prepended to the stack of
+ * $form['#submit'] handlers of protected forms to remove all of Mollom's
+ * additional values to prevent them from being mistakenly stored elsewhere.
+ *
+ * @see http://drupal.org/node/939510
+ */
+function mollom_form_pre_submit($form, &$form_state) {
+  // Some modules are implementing multi-step forms without separate form
+  // submit handlers. In case we reach here and the form will be rebuilt, we
+  // need to defer our submit handling until final submission.
+  if (!empty($form_state['rebuild'])) {
+    return;
+  }
+  unset($form_state['values']['mollom']);
+}

I'd update the phpDoc to make it less dramatic. Let's get rid of words like 'blatantly' and be a bit more explanatory. Personally, I think it is appropriate for the Mollom module to clean up some of its data. At the same time, I'm not convinced we need to fix this. If we remove this code, where do things go wrong? Can we fix the other modules? I know this is a bit of a bi-polar review. We should probably keep this code in the Mollom module, I guess.

+++ mollom.module	15 Oct 2010 13:01:41 -0000
@@ -1685,6 +1732,7 @@ function mollom_form_submit($form, &$for
+  dsm($form_state['values']);

Still debug code.

+++ mollom.module	16 Oct 2010 19:19:39 -0000
@@ -1127,6 +1132,15 @@ function mollom_form_get_values($form_va
+  // Capture the actually submitted value to allow to manually double-check the
+  // honeypot processing. The Mollom backend does not use this value, but merely

I'm not sure I understand the first sentence. Also, I think the second sentence can be removed. Seems like these code comments need to be simplified, or removed even?

+++ mollom.module	16 Oct 2010 19:19:39 -0000
@@ -1721,6 +1756,32 @@ function mollom_validate_post(&$form, &$
+ * Various forms happen to take over and save all data in $form_state['values']

Maybe start with "Various forms outside the Drupal module blindly save all data ..." ?

Maybe one more re-roll and than it can be committed. You can commit it.

@Sun

Correct, screen-readers will ignore content if it is set to display: none, or if it inherits display: none.

Not sure which is the most recent patch on http://buytaert.net/want-to-grow-drupal-put-on-a-drupalcamp

When I look at the page with JAWS it reads "Leave blank, used to catch spammers". The field itself isn't visible to JAWS. If we are doing display: none on the field we need to do display: non on the label too. if element-invisible is currently being applied to the label it will override the display:none that may be set on the container.

<div class="form-item" id="edit-mollom-homepage-wrapper">
 <input type="text" maxlength="128" name="mollom[homepage]" id="edit-mollom-homepage" size="60" value="" title="Leave blank, used to catch spammers" style="display:
none;" class="form-text" />
</div>

Ok, here is the code, I'm not sure why JAWS would read the title from an element marked with style="display: none;". I'll need to do some more research on this, since JAWS is reading the title, but not reading the form field (the text field is invisible to JAWS.

Further testing on Dries's site showed that VO/Safari, NVDA/IE and FF and JAWS/IE all worked as expected. Only JAWS/FF read the title of the input field with when style="display: none;".

I will test the most recent patch when it is applied somewhere for testing, but it looks good to me.

I'm not really sold on the no label / title, some users do have CSS disabled and whill have no idea what the field is for. This might be an acceptable trade-off.

Looks great now. Committed to DRUPAL-6--1. Thanks!

My personal site ran an older version when Everett tested it. I've upgraded my site to use the latest and greatest DRUPAL-6--1 branch.

Seems to hide the @title attribute properly with JAWS / FF now, didn't re-test anything else.