Anyone who has a form on their website has seen their fair share of spam. Spam is a huge problem for site owners. It can cost businesses time and money. To fight spam, many sites put captchas on their forms. These captchas can stop spambots from spamming. But they can also stop users from filling out your form. That’s the last thing you want when you’re running a business.

Captchas force users to type random words that don’t make sense. Not only that, but the letters are so warped and distorted they’re hard for anyone to read. Users often have to try captchas many times to get it right. That’s why most users avoid filling out the form when they see one. It’s good that captchas stop spam, but it shouldn’t come at the cost of losing users. The perfect captcha is one that not only stops spambots, but does it without hurting your form conversion rate.

Checkbox Captcha

The checkbox catpcha can stop some spambots, but not all. What’s good about this one is that it’s smaller and less intrusive than traditional captchas. All it takes is putting a checkbox generated with client-side Javascript on your form. All the user has to do is tick it. No typing necessary.

Most spambots won’t be able to tick the checkbox because they don’t parse client-side javascript shown to users. But some spambots that can detect client-side javascript through training. Although it’s less intimidating to users, it’s not 100% effective in stopping spambots.

Honeypot Captcha

Another captcha that’s less intrusive than traditional captchas are honeypots. They can stop some spambots, but not all. They may also create accessibility issues for some users.

Honeypot captchas work by hiding a text field from users through CSS. It’ll only accept entries that leave the field blank. Users can’t fill out this field because they can’t see it. But spambots will see and fill it in. The form will then reject the spambot’s entry.

Some spambots have learned to avoid honeypot text fields if they’re labeled in a way that tells users to avoid it. This presents accessibility issues for screen reader users who have CSS disabled. If the label on the honeypot field doesn’t tell them not fill out the honeypot, they won’t know to avoid it.

You could give the honeypot field a common label, such as “name”, to trick the spambot into filling it in. But it would also trick screen reader users to fill it in too. Honeypot captchas are not 100% effective at stopping spambots, nor are they accessible to all users. But they are far better than traditional captchas.

Slider Captcha

The slider captcha separates itself from the rest of the pack. It stops 99% of spambots because most can’t interact with the slider. It’s also user-friendly because all users need to do is slide the knob across to verify they’re not a spambot. All mobile users need to do is swipe. One potential drawback is that keyboard-only users might not be able to activate the slider if you don’t make it accessible.

Final Thoughts

Traditional captchas are the worst. Stopping spam should not come at the cost of stopping users from filling out your form. In the battle of captchas versus spambots, the slider captcha is the most effective. It’s not only easy for users to use, but it fights spam without hurting form conversion rates. The war on spambots is far from over. But this is the best of what’s out there for sites who don’t want to lose users.

I think more screen reader users have CSS disabled more than Javascript. Not having Javascript degrades the functional experience of a site. Not having CSS peels away the aesthetics of a site. Which do you think a screen reader user would rather have?

Not sure what the point is in “worrying” about the blind but airliy stating that “users just have Javascript enabled”. I care about both groups.

I use the honeypot, and it’s clearly labled. Fronteers.nl uses something similar: a final question (which is hidden with Javascript I believe, so those who *do* have it on don’t see it, don’t fill it in) asks if you’re a spammer. On the other side of the field, there’s some hint text “fill in No”. So if you don’t have JS, fine: you’re told not to leave it blank, but what you should fill in.

Users without JS do a hair more work, and unlike the javascript-created checkbox, allows ALL human users access.

When using a honeypot, you generally hide the blank field with CSS so the human users that have CSS turned on don’t even see it.

Both solutions are completely valid.

My only concern with the checkbox is that to someone who isn’t paying attention, it could look like you’re trying to get them to sign up for something.

Gambler

Jul 21st, 2011

JavaScript should not be required for performing trivial actions, such as commenting. There are many, many architectural reasons for that. Besides, many people browse with JS disable for security and privacy purposes.

How about adding two checkboxes? “I am not a spambot” and “I am a spambot”. Both are unchecked by default. The second one is hidden via CSS. This would thwart bots that check everything and fill every field.

Don’t think that’ll won’t work. If the checkbox is already checked, the spambot doesn’t have to do anything but fill in the remaining fields. Also, making the user uncheck a checkbox to submit the form, is an odd and confusing request in and of itself.

Do spam bots even run JavaScript? It seems to me that simply inserting a hidden field via JavaScript is enough to combat spam if the bots don’t run JavaScript. The checkbox itself is unnecessary.

And the argument that people surf the web with CSS disabled is no different from the argument that people surf the web with JavaScript disabled. Besides, you can still target screen readers with CSS using the “media” attribute.

I was thinking the same thing: if the assumption is that the bot is not parsing javascript, a hidden field or a modification to the submit value should be enough to do the do the test without a normal user ever seeing a prompt.

So, if no spam bot can execute client side code, why don’t you just insert a hidden field client side that has a value that needs to be there in order for the form to validate? Google bot executes JavaScript, so i suppose spam bots will too.

The traditional Captchas are mainly used because they don’t require javascript.

If you decide to use javascript (I do) then there is no point in having a checkbox at all as you can easily generate a hidden field with an obfuscated string. No spam – no checkbox – no (visible) captcha 🙂

If you have a simple comments section that you’re trying to avoid the majority of generic spambots spamming, then this will work fine, as will any javascript approach (using jQuery to capture the onSubmit event and adding a hidden field prior to the http post would also do the trick), providing, as Stéphane points out, javascript is enabled.

However, if you’ve a site which you’re trying to prevent automated sign-ups, and there is any value to someone writing a specific bot for your site (which is really very little work to do), then it is trivial for them to bypass this. You could randomise the field name and match it to a session variable (CSRF token style) which would make their life harder, but there’s a good reason why Google et. al. have fallen back to the captcha, despite its very real issues.

If people are really targeting your site, captchas do not protect against spam signups either. They can use services like decaptcha which hire cheap typers to “solve” these images in bulk. If your site is worth targetting against, a signup will probably be worth more than 1/10 of a cent.

It doesn’t work. If the spambot simply records the submit request sent to the server, it will include the checkbox tick and it can repeat it as often as it wants. captchas work because the server sends a coded message and only a human can return the message. Any solution involving javascript will not work. Even if you get javascript to generate a captcha, you will have to give javascript the unencoded word to generate. The spambot will be able to get the unencrypted word to pass back.

Although current spam bots couldn’t get around these captchas on your website, it is super trivial to write one that can. They will only work to stop spam until someone writes a spam bot specifically for the site, which won’t take a whole lot of effort. All it needs to do is submit the same information in the form that a valid form would have.

This stuff does my head in. What about generating a random string and random string index to be used as the session index for the token ($_SESSION[$_SESSION[‘index’]]), stored in a server side session for each page load, then ajax posting the index and string to receive a psudeo random token based on the previous random string (only if $_SESSION[$_SESSION[‘index’]] is set and equal to the random requested index/string) which is stored in a server side session variable then injected into the form in a hidden field that is generated on the fly (so cannot be detected on a page load, as it is injected into the DOM when the doc is loaded) which is posted at submit time and compared to the token that was generated and stored server side?

I made some css hidden fields with the name website and a hidden field with the name url. If one of those fields are filled in IP comes in a database of blocked ip’s. Nothing for the user to be required. Thats the perfect user experience :).

I believe JS must be supported. But not because of screen reader users; same percentage of those user have JS enable as “regular” users. Remember 1% or so of 100,000 is still 1,000 users you’re blocking. Cases includes low-end mobile devices, corporate firewalls, broken JS, very old browsers, and text-only browsers.

This method doesn’t work… if someone wants to register 1000 users in your site, he programs the bot to send a checkbox, or to not complete the “hidden field”… in that case you have to use traditional captcha

But it does work. I have proved it on my own site. Using Akismet I was often getting hundreds of spam a day. Now using Growmap Anti-Spambot Plugin (GASP) with the checkbox I get a big fat ZERO amount of spam.

I love this alternative to the ugly captcha. How about if javascript is turned on show checkbox, if not show the ugly captcha? Seems like the number of people with javascript turned off would be minimal so this should work…and still stops the spammers. I also think like everything else, the method used depends on your audience. If you have a lot of people with JS turned off this is not for you.

Seems a lot of people in prevous comments are critical of the checkbox type setup. I hate having to type out captchas. If they are hard to read you have to keep clicking the refresh to get one you can read. I use GASP with the checkbox & it works so well I have uninstalled Akismet completely. Every time I check my Spam folder the amunt is always ZERO… Easy to criticize something if you haven’t tried it. GASP is the ultimate in anti-spambot defence.

Both CAPTCHAs have their advantages and shortcomings, but when it comes to the ordinary user, who is not going to spam your website, he should have some solution which would help him complete CAPTCHA verifications.

An interesting concept and a great solution for smaller websites, however, this wouldn’t work for high-volume websites (traffic or revenue or both) because hackers would spend the time to develop a bespoke solution as the reward is worth the effort.

I am looking to incorporate captcha for our registration page. Because we also have a TOS that needs to be agreed to before sign-up occurs, I am considering using the checkbox as an agreement to the TOS. This way, we subvert spambot submissions while also not displaying an obvious captcha to the user.

There is something I’m not getting with this somewhat popular technique. Since this technique forces the user to have Javascript enabled, why bother with a checkbox? Why not have a Javascript function that will put an obfuscated value in a hidden field, and you check the value of that field on the server. It’s as safe (or should I say unsafe) as the checkbox technique, but you won’t need the user to click on anything.

A safer technique would be to use an Ajax call to set a random value in a hidden field, a value that was also saved in the user’s session on the server. This way, the spammer would actually have to simulate sessions and call the Ajax script. Doable, but more work for them.

Stating that the Javascript solution is better than the honeypot one is just stupid. There are enough people who have Javascript turned off, or their smartphone/mobile computer just doesn’t support it.

Anything that is pure client-side is useless. It will stop the lousy random bots, but it will not stop someone who decides to attack your website – post comments, register users, try sql injection etc etc. I can write from the scratch a bot that posts multiple times in under 15 minutes.

DIM error_message error_message = “Double Authentication Required: You have been detected as a Spam Bot.” error_message = error_message & “If you received this message in error and would like to submit your e-mail: ” error_message = error_message & “Please Click Here To Continue Sending E-mail >> ” error_message = error_message & “An e-mail will be sent to “& customers_email &”. Please click on the link in the e-mail to verify you are human. Thank-You!”

I’m wondering what happens if the end user is physically disabled, cannot use a mouse, and has to rely on keyboard commands to facilitate use on a web page: unless you can select the element and use the arrow keys to nudge the button across, this is an enormous usability fail.

I’m wondering what happens if the end user is physically disabled, cannot use a mouse, and has to rely on keyboard commands to facilitate use on a web page: unless you can select the element and use the arrow keys to nudge the button across, this is an enormous usability fail.