ZURBlog
ZURBplayground
ZURBword
ZURBnews
ZURBexpo
Captchas Are Bad for Business, and Your Users
Web form security can be a tricky thing—spammers don't make our jobs any easier as Web professionals. In fact, we've been exposed to so much spam that the supposed best way to deal with it is by making users suffer through a captcha. The ugly and intrusive captcha has been growing like wildfire, and while it tries to solve a valid business problem, I don't like it one bit.
A captcha—Completely Automated Public Turing test to Tell Computers and Humans Apart— is a test given to people while filling out Web forms to prove they're human. It works like so: you read a box of jibberish and re-type said jibberish into a text field. Makes sense right? Wrong.
Site security is something that should never be seen by users. Users shouldn't see another form field and be forced to read difficult boxes of nonsense. Users need to be set up for the win—they need to cruise through your form and get to the very end with flying colors. Captchas are cop outs. They're a poor solution to a larger problem that puts the problem onto users' shoulders. They make websites and companies look like amateurs who have given into the spammers at their front door. It might solve your spam problem—a mighty and admirable feat—but at what cost?
When it comes to Web forms, as designers and developers, we need to help people through to the very end. We need to encourage accurate responses, limit frustration, and set users up for success at every turn. What is the better business case: improved results and feedback from users, or a more complex form that produces less spam and more frustrated users? Captchas just make for poor business decisions; here's why.
In most sites, there are constant efforts made to convert a visitor to a new user. With every click there is marketing that speaks to the visitor, begging her to sign up because it will do this, that, and everything in between. And then, when that person finally gives in and decides to sign up for your service, you make her do all the work with a form that ends with a captcha. We need less form fields, not more of them. That's not how the Web should work, nor how your business should work. Do you force users to be responsible for knowing where their data is stored, too? Website security is a business problem, not the users' problem.
Users should never have to see, hear, or deal with any of your site's shortcomings, security least of all. Think of it this way: how much else do you want users doing instead of you? It's a bad habit to put things on users' shoulders instead of your own. Take the extra effort and make your site fun and easy to use at every turn. Don't annoy your users by making them do extra work.
24 comments
Aiden Bordner says
While I'm inclined to agree with this from a fundamental standpoint on the adversity between business requirements and security requirements, I think this perspective is limited to a lens of giving one of those requirement sets priority.
If you think about the amount of PII you request at a user registration, it's the same issue of balance: if your system has functionality requirements to be competitive that rely on robust location awareness (e.g., Facebook) you must satisfy those requirements with a user model that includes a strong location reference, such as a zipcode. Conversely, if your ultimate need is simply numbers of users and precise location identification isn't a strong requirement (e.g., MySpace) location can be an optional, open-text field where a user can be less obligated to provide personal data, reducing the ask and increasing the ease of the experience.
Similarly, if your system and/or business has the propensity to be overwhelmed by automated systems that critically reduce the quality of the experience for real users (think Ticketmaster) a captcha is a perfectly suitable solution that recognizes the balance of business priorities with system priorities.
Moreover, I think our forefathers would agree based on the proliferation of Captchas in existing products to solve this need. Your classic Nielsen/Tufte heuristic evaluators would dictate you don't violate convention and confuse the user. The question isn't the number of "clicks" (or fields in the reg form) but how much the user is required to think or give to convert. In that vein, the spam filter on this blog represents an uncommon interaction for me, and required a second or two of interface scanning to determine how I was supposed to respond. (On an unrelated note, it's also a far less secure interaction than a Captcha and likely wouldn't work on a site where economic gain can be made from spamming the system like Ticketmaster).
That said, I feel Captchas are fairly embedded in the modern user conventions for web applications, and provide a much more limited barrier than they provide benefit to the gestalt experience for the active user population.
However, in an ideal world, I agree with the sentiment. My $0.02 :)
David Sanchez says
Mark, thanks for the post, interesting point of view, but you fail to address the major advantage of using Turing test and benefits for any serious online business. Unless you have a better solution for online fraud (powered by ID Theft and there are many) and endless web bots parsing every exploitable web form or web service, captcha’s are here to stay. I think you need to disambiguate the term user which in technology terms is utterly meaningless when placed side by side a human or software are the same when accessing the infrastructure, the same TCP/IP protocol and interface.
I am actually support dynamic challenging Turing tests based on the DEMO graphics of a particular website. I doubt very much the captchas are responsible for “cart†abandonment or revenue loss. And as algorithm and technologies get more complex, we can be sure there will be other authentication technologies on the way. CAPTCHA’s are one of the best tools against spammers.
Mark (ZURB) says
I hear you David, but the point is that while we might need some kind of truth test to determine whether a bot or human is filling out a form, that shouldn't happen on the person's end. Captchas are notorious bad at letting people through and seamlessly into a secure system.
We've all been there, so frustrated by the fact that I can't seem to spell what's right in front of me! It's ridiculous to expect customers to bend over for you. As a product or service provider, you need to bend, not me.
Perhaps the right question to ask is how can we work to stop receiving spam in general, instead of just combatting it? As technologies get more advances, so likely will bots, but perhaps so will we?
Captchas are the easiest tool against spam, but they're also the worst way to do business online. They make your problem—security, spam, form abuse, etc—the user's problem. That doesn't happen anywhere else, so why should it with forms?
Jonathan (ZURB) says
Between blacklists and smart spam detection computer systems can do most of the work for us these days. Where the final hurdle lies is in provider oversight – the ability of the service provider to filter out spam by hand. For a small site this is feasible; for large ones, not so much.
At the end of the day a computer lacks the judgement to identify spam 100% of the time, but that shouldn't be the user's problem. We need to focus now on getting rid of that last, say, 5% – without aggravating our actual audience.
P.S. I found this stat on reCAPTCHA's site: "About 200 million CAPTCHAs are solved by humans around the world every day. In each case, roughly ten seconds of human time are being spent. Individually, that's not a lot of time, but in aggregate these little puzzles consume more than 150,000 hours of work each day." I know this is meant to demonstrate how many hours can be applied to reCAPTCHA's noble goal of digitizing books, but holy CRAP that is a lot of time spent on captchas.
Marnen Laibow-Koser says
Hmm. Interesting post, and I'm going to have to think about the issue some more. But at first blush, I think suitability depends on the nature of the captcha. Personally, as a user, I find some captchas annoying, but most are fine. As a Web application developer, I've never needed to implement one -- not sure why, but we've never had a problem that captchas would solve. Perhaps I just don't work on the right sort of sites.
I find it particularly ironic that your comment system for your blog -- even this very post -- has a captcha of sorts -- the box in which you have to type a letter to filter comment spam. Granted, it's not a "canonical" image-based captcha, but it is extra work of the sort that you claim the user shouldn't have to perform. I don't mind an extra 2 keystrokes, but I think the fact that it's there at all is interesting, to say the least.
Mark (ZURB) says
Thanks Marnen, appreciate the input.
I'm surprised you were the first to notice! We implemented it months ago after being pummeled with spam. At the time, Akismet wasn't doing it's job, and now, it's superfluous.
We'll be seeing it go soon enough, and hopefully Turing tests in general. It's bad business to have to do and we're not too proud of it.
Cavan Riley says
I've never had to build a site that considers these problems, nor do I have much knowledge of how spam bots work. However, I would imagine that spam bots attempt to fill out all questions in a form because they are unaware which fields are required. So, couldn't you then have a question that is visually hidden to the users filling out the form. Thus, the only thing that would answer the question would be something reading the code.
Just a thought. Doubt it's that simple.
Mark (ZURB) says
Cavan, that's actually a really great idea. Let's run with that thought a bit more...
If a spam bot were to come to the page, it'd see the source code, not what your or I as human visitors see. The spam bot sees a hidden field (via a display: none; for instance) and fills it out, but a human wouldn't see it and thus wouldn't fill it out.
The spam bot would likely fill out each field that is required or not, making it easy for us to know who is who, or who is what.
I'd love to give this a try at some point. It seems like a great and logical step towards getting away from a user-side Turing test, which is what this post is all about. This is a great potential solution to a problem, one that doesn't put the problem in the users' laps.
Jonathan (ZURB) says
It's funny, a few of us were out to dinner Friday and saw your comment Cavan...our significant others had to put up with a few minutes of geeking out about it!
It occurred to me after reading Mark's comment that this is a really ingenious solution, but maybe not for long. Building a bot that ignores a display:none; tag is easy enough - what may not be so easy is building a bot that ignored fields hidden through some other tricks, like the z-index or positioning off screen.
Mark (ZURB) says
You may notice now that we don't have our spam filter. We've removed it temporarily as we experiment with other measures.
If we have to revert to it again, we hope to try Cavan's suggested approach. Here's to doing spam battle!
Cavan Riley says
If you get around to trying it out, make sure you send me an email and let me know how the tests go. Even if it fails miserably, I'm curious of the outcome.
Mark (ZURB) says
Will do, Cavan. We pulled our little spam filter off in our latest push, and have been watching the results carefully for any sign of massive spamming.
We're looking good, but we still want to give that a try some day soon :).
Brenton says
I'm working on a survey system now that dynamically arranges/shows questions to ensure the user only sees what he needs to fill out. On the server-side, I need to check that the submitted values form a valid path through the survey before I persist them.
The idea of the CAPTCHA is to test if the respondent is human. Why not shift the burden and instead test if the respondent is a friendly robot, e.g. a real browser ostensibly powered by a human? Cavan's solution should do this, but its not the only way. In my app, the form is built as the user progresses through the survey. If the responses are out-of-sequence or too many values are submitted, I know the client-side JavaScript didn't execute, the data is invalid, and the results should not be persisted.
Web design is all about usability - we must understand the path the user will take and optimize it as much as possible for a friendly experience. If you're working on a closed-source, low-visibility form, you can implicitly test if a real user followed the expected path versus a hopefully less-discerning spambot that shotgun-blasts your form with nonsense.
Patrick Hutchinson says
There is a great Rails plugin called Negative Captcha that does this. There are some articles about the pattern as well if you google "negative captcha."
Pablo Impallari says
I love the simplicity of this captcha (Scroll to the end of the form) http://www.letterheadfonts.com/contact/ordering/form.php
Please type these numbers: 123 into this box: ____
federal street associates hedge fund says
refreshing and very informative. myself wish there were more blogs like it. Sincerly
bottle old wine says
Hello You How can start this work please tell me myself have a website aswell.
television commercials says
meself am excited already as meself know you always have pretty cool stuff. Bye
nfl odds spread says
you couldnt agree more, myself, but not everyone is as clever as you seem to be. Or as you seem to be! HA! :-p Talk Later
wireless adapters says
Nice writing style. Whats yer opinion on soft? Goodbye
condolences says
you couldnt agree more, myself, but not everyone is as clever as you seem to be. Or as you seem to be! HA! :-p i a blog owner too. Talk Later
electrical says
Me like your site design. Looking forward to reading more down teh road. Cu Soon
printers row lit fest 2010 says
Wow! thank you! my homie always wanted to write in my site something like that. Can my homie take part of your post to my blog? yours truly a blog owner too.
ZURB Photostream
The ZURBlog is where we discuss product design, business and strategy. We use design thinking to challenge businesses and designers to improve the products and services they create.
ZURB is a close-knit team of product designers who help companies design better web sites, services, and online products. We've worked with more than 150 start-ups since 1998.
Hmm, not a big talker? Email us to getstarted@zurb.com.
Get our monthly newsletter, ZURBnews.
Check out the latest news and buzz »