The Fallacy of Captcha
I’m sure we’ve all had a lot of experience with captchas. They are the annoying test websites use to decide if you are a human or a bot. They started off fairly simply as an obscured word or phrase written in swimming letters or having other obscuring features that make them hard to read. For example:
And that seemed like a fair trade off to many people. I type in these hard to read characters, and you believe I’m a person, so I can enter your site or post on your blog. They had their challenges to be sure. Accessibility was a real issue. Many sighted people had a hard enough time reading the words, but if you were blind or visually impaired, forget about it! And if you were trying to solve an English word captcha on a non-English site where Latin characters were a rather foreign concept, it could be quite a nightmare.
There was another problem with captcha that Luis von Ahn, one of the original creators of captcha realized: “he had unwittingly created a system that was frittering away, in ten-second increments, millions of hours of a most precious resource: human brain cycles.” And so, reCaptcha was born:
The great advancement of reCapthca was that you were looking at distorted images of random words scanned in from books. As enough people decoded the images, and agreed on what they said, the books were slowly being turned into digital versions of the original. And suddenly, people felt a whole lot better about wasting 10 seconds, because they were helping bring old, out of print books back into the digital world.
But even this went out of fashion, and now we have a check box:
Much of the time it can detect how you click the check box and determine if you are a bot or not. If it can’t make up it’s mind, you get to select all the pictures in a set that contain a car, or some other non-texty sort of test. So, for most people, we aren’t wasting 10 seconds, it’s down to 4 or 5.
And, is that so bad? Short answer: yes. Each of these interruptions creates an unnecessary cognitive load for the site visitor. Whatever they were doing on the site, they have to stop and answer a question that is wholly unrelated to whatever it is they were doing a moment before. Unless, perhaps, you happen to be the one person blogging about AI methods for solving captcha tests, the captcha is a distraction.
Let’s put that in some context. If you run a website of any kind, load time is probably a concern. Depending your level of technical proficiency, you may not know if there is a lot you can do about it. But, if there was a setting in the admin tool for your site that said “click here to make your site load 5 or 10 seconds slower,” you would absolutely not turn on that setting at any cost. Well, that’s what captcha is, at least from your user’s perspective.
Luis von Ahn summed it up, that captcha was “frittering away, in ten-second increments…” site visitor’s time. Unfortunately, he didn’t see the taking up of 10 seconds as the problem, he saw the problem as not putting that time to good use. But time is a precious commodity. I remember in the early days of the web on my 28.8kbps modem when you might give up on a website if it took more than 20–30 seconds to load. Today, studies show that user tolerance for load time is more like 2–3 seconds before visitors start bailing.
There are a couple of reasons why this is significant. First, wasting your visitor’s time is just plain rude. They are taking the time to visit your site, and you should respect and appreciate that, not squander it. And second, you have competition. If you are wasting too much of your visitors time, they won’t feel respected, and they have choices. Google showed them 27,000 results when they searched and found your site, they can move on to the next blogger/vendor/whatever site and you’ll never see them again.
Let’s get back to why captcha was created in the first place: to tell apart humans from bots. It’s a real problem that needs to be solved. You don’t want tons of spam comments on your blog, or the feedback section of your site. And frankly, neither do your site visitors. But, when programmers were faced with solving this problem, the answer they landed on was to make the human visitors do all the work to solve the problem. This seems rather backwards to me as our site visitors are our customers. They are the ones we care about, not the bots. We want the bots to go away, but we are taxing the site visitors in the attempt to solve the problem. This is simply wrong. We need to respect our human visitors, and make the bots pay the price.
So, how can we do this? I have a method I’ve been using for at least a decade that my friend phillip barnhart introduced me to. I am so far unaware of it failing to work, but there are many sites I’ve implemented it on over the years that I’m no longer in contact with, so I can’t promise it’s perfect. Your mileage my vary, but hey, it could be worth a try.
The trick, quite simply, is to have a hidden field called “email”, which, if filled out, you throw the submission out on the server side. So, if you need an email field, call it something different, like “email_address”, which will probably be close enough to email that browser auto-complete will still work.
There are a couple of gotchas with this. The first, as I alluded to, is browser auto-complete. You have to turn that off for this field. The second is accessibility. You should include the aria-hidden attribute to indicate that screen readers should skip the content. But, your hidden field may still show up for some older screen readers, so you have to include a label that tells the visually impaired not to fill it out.
Here’s an example:
<style>
.email-field {
left: -9999em;
position: absolute;
}
</style><div class="email-field" aria-hidden="true">
<label for="special_field">Spam catcher, don't fill out</label>
<input type="email" name="email" id="special_field" autocomplete="off">
</div>
That’s all there is to it. If a bot sees the field, they should insert an email address. Then, on the server side, you check to see if the “email” field has a value. If so, throw away the submission. If not, let it pass. You might return an error message that looks like the submission worked, but tells a human user there was a problem, something like “Thanks for your submission. We are unable to accept automated postings at this time.”
It’s a complicated dance with spammers and bots. If this does work, but looks successful to the bots, you may get thousands of form submissions you are throwing away. Then you have to start blocking IP addresses, or put in place rate limiting, for example. So, this will likely not be the end of the story for you. But, it could be the beginning of an exciting chapter that puts your site visitor’s experience first.
