Using Radio Buttons to Combat Form Spam

There has been a lot of talk lately (and rightly so) about the disadvantages of using captcha to stop comment spam.

I’m not a big fan. They’re often hard to read even for someone with reasonably normal vision.

“Is that a zero or the letter O?”

“Upper case C or lower case c?”

Others have suggested some sort of simple logic question, like asking “What’s 1+1” and having the user enter a ‘2’ in a text box.

That might be better, but it also requires some thought.

So I noticed that on Slideshare they prefix a captcha device with the question, “Are you human?”

And it got me thinking, can bots deal with radio buttons? Can we ask a question like this?

[syntax,human_form.htm,html4strict]

Human Radio Buttons

I must admit I haven’t done any research, but I’m thinking:

  1. If a bot doesn’t understand radio buttons it will skip the question and fail
  2. If it does understand radio buttons, it will probably choose the first option and fail
  3. It’s an extremely simple question for a human to answer and should be completely accessible.

Point 2 is probably the most contentious. I’m making a big assumption there.

Has anyone else tried this? Can anyone spot any obvious disadvantages?

Advertisements

5 thoughts on “Using Radio Buttons to Combat Form Spam

  1. I can’t spot any obvious disadvantages with your example, but I was listening to the 94th boagworld podcast and they mentioned something called a honeypot captcha. This works by including a hidden field in your form and give it an id or class of “body.” The spam bots would then go crazy and fill it out.

    It would then be easy to check if the comment was genuine or not by checking to see if that field had been filled in.

  2. Haven’t heard of that one before – but that’s a pretty good idea. As long as you’re careful what you name it, it’s an unobtrusive method. Good call.

  3. Actually, the more I think about it, the Google Toolbar Autofill could be a problem. (Refer this comment)

    If the honeypot field is automatically filled in by a 3rd party tool like that, how do you deal with that error? Explaining what happened to the average user would be hard enough, but what steps could we reasonably expect them to take to rectify it?

    Something else I stumbled upon tonight is the use of a confirmation page.

    That might work too…

  4. I suppose for the Google Toolbar problem you’d just have to name it something that the Toolbar doesn’t fill in automatically. An id (or class) of “email” or “name” would probably trigger the toolbar, as would any other class with these words contained in it.

    The confirmation page is probably the safest way to go, but you would risk losing genuinue comments because people may close the window as soon as it reloads again or something else like that.

  5. This is funny, I just ran into some problems with spam bots posting one of my client’s forms, and thought of this same solution after researching other methods.

    Have you had any success with this?

    Regardless I’m going to try it out as it seems the absolute simplest solution. The forms only get posted to me and my client (since that is all I allow server-side!), but they are still annoying.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s