[SR] Include Honeypot module in Backdrop by default for public forms.

[sutibun]

The comment module is included in core. That's fine BUT...

Normal users aren't savvy enough to know that by enabling forms, they're exposing their sites to spammers and the likes.

And, even if they are, they might not be aware of the different options to protect themselves. (Like me recently. I didn't know there were plugins in Wordpress that helped against this. Yes, the monkey is slow. Quit your giggling)

Soon, users will encounter the barrage of spam comments and, frankly, that's just not a nice experience to subject users to. They'll get frustrated they aren't getting any real comments and managing tons of spam will become a headache.

Knowing what comes along with comments, is this the UX we want to expose Backdrop users to by default? Shouldn't we provide minimal help given comments are on by default.

I think Backdrop should go the extra mile and enable the Honeypot module by default (users can deactivate them in the config if they so choose).

It'll show the world some thought went behind this instead of letting users fend for themselves, alone.

Backdrop shouldn't be a CMS with just modules slapped together.

Got the idea while thinking through this issue #1168

[quicksketch]

I think this is a great idea.

There may be other alternatives to help with spam, such as loading the comments via AJAX rather than being inline on the page at load time. That would really cut down on spam as bots would need to execute the JS on the page to access the comment addition form.

Honeypot in some basic implementation is still a good idea in any case, as there will always be forms that are accessible to anonymous users that could use some basic spam protection (like the Contact form).

[klonos]

The monkey might be slow, but it beat me to filing this issue :wink: :+1:

I was also thinking about this + some other things while putting my thoughts together in #1168 (still draft that needs to be structured a bit better, but the main idea is there).

As a general concept, I would like to see little "connect-the-dots" elements implemented throughout the UI instead of having people pogo-sticking around in search of features. For example, a "Protect this form from spam" checkbox in this case that would enable the honeypot module + a "what's this?" link with a balloon explaining that a module needs to be enabled and link to documentation (use modal for confirmation, "magic" for enabling the module without leaving the form edit UI). For #1168, the respective element would be a "Enable site-wide contact form" checkbox, again with modal + a "what's this?" link. UX++

[sutibun]

Loading comments via AJAX is a better idea. Anything using JS is a better implementation because bots have a harder time with them.

Personally, ever since discovering the Antibot module, I've seen no spam. This may be another method to consider. I liked the premise ever since reading it. I'm surprised it's not more popular.

Antibot aims to:

• Prevent automatic spam submissions on your site's forms (like comments).
• Be as lightweight as any module could possibly be.
• Protect forms while still being able the cache the page.
• Avoid any end-user interaction or annoying CAPTCHA codes.
• Be more reliable than a honeypot trap.

How does it work?

1. Admins choose which forms to enable protection for by specifying the form IDs.
2. CSS is used to hide the form and display a message that the form requires Javascript in order to be used.
3. The form's action path is switched to /antibot.
4. When the page is loaded, if the user has Javascript enabled, the form is revealed and the message is removed.
5. After the page is loaded, Antibot waits for a mouse to move or an enter or tab key to be pressed before the action of the form is switched back to the path that it was originally set to be. This indicates that the person behind the controls is a human and not a robot.
6. Since there is no dynamic code generated for each form, pages with Antibot can be cached safely.

Basically, the page needs to scroll for the real action path to be set and submit comment to the right place. Love it.

I'm definitely not set with the Honeypot module. I only suggest it since it's popular and I figure there'd be less resistant to the idea.

I am, however, against any form of captchas as it bothers users but still allows spam through. It's just stupid all around.

Anything that implements some way to combat spam and help normal users by default, I'm all for it.

Klonos, you could say this was your idea. Your incomplete draft got my head thinking along this way. I didn't have this idea from the start.

[mikemccaffrey]

Include Honeypot module in Backdrop by default

I think that it would be great to have this functionality in core, but it might not need to be its own module. Rather, we might want to consider including security functions like this as part of the core Forms API, and just provide a setting for whether it is enabled or not for public forms.

Loading comments via AJAX is a better idea. Anything using JS is a better implementation because bots have a harder time with them.

Again, this could perhaps be a core security setting asking if public forms should be loaded using AJAX.

[klonos]

Loading comments via AJAX is a better idea...

I filed a separate issue for that idea, so that it does not slip out without being evaluated.

[stpaultim]

We were just discussing this issue in development meeting and @quicksketch was making the point that SPAM prevention is a moving target and hard to keep up with. Putting a specific solution into core might only be a temporary solution and if it is not kept up to date, we end up with useless cruft in core.

I have this same concerns about picking a specific solution in core for SPAM.

[jenlampton]

based on today's conversation, removing the milestone label and adding a candidate tag.

[klonos]

I still think that having some sort of basic protection for the login form and the contact form in core would be better than nothing. Solutions like Akismet/Mollom may work better/smarter, but they require subscription to a 3rd party service (even if free), so they would never get into core.

Another thing to consider is the usage stats of the module, with ~130k Drupal installations, there must be a reason.

[jenlampton]

Yep, I have it on all of my Backdrop sites. Most of my Drupal ones too.

On Fri, May 10, 2019, 1:06 AM Gregory Netsas notifications@github.com wrote:

I still think that having some sort of basic protection for the login form and the contact form in core would be better than nothing. Solutions like Akismet/Mollom may work better/smarter, but they require subscription to a 3rd party service (even if free), so they would never get into core.

Another thing to consider is the usage stats of the module, with ~130k Drupal installations https://www.drupal.org/project/usage/honeypot, there must be a reason.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/backdrop/backdrop-issues/issues/1169#issuecomment-491199175, or mute the thread https://github.com/notifications/unsubscribe-auth/AADBERZDLDPFVVW55HP3Z53PUUUIVANCNFSM4BPR5CPA .

[ghost]

I'd like to see non-invasive anti-spam functionality in core (separate module or otherwise). I personally like Antibot over Honeypot as it uses javascript (which Backdrop uses anyway) and doesn't require extra fields or timers (I've been stung a few times by submitting a form 'too quickly').

[klonos]

...between May last year and now, the Honeypot usage stats jumped from 130k to 150+k! :astonished:

https://www.drupal.org/project/usage/honeypot

The usage of the module on Backdrop is ~175: https://backdropcms.org/project/usage/honeypot (with Backdrop sites being ~1250)