Wednesday, December 3, 2008

Substituting CAPTCHA

Jeff Cohen recently wrote an article on implementing CAPTCHA in an agile manner. I love his story about practicing “Do the simplest thing that could possibly work.” In this blog post here, I would like to raise a point, in the same context but in a bit different perspective, on CAPTCHA. The argument below is originally made by one of my friends, Kenn Ejima, the creator of Rejaw and Lingr, in his blog post (it is unfortunately written in Japanese, thus I am writing this post).

CAPTCHA seems widely used to avoid spammers on the web. When I signed up a Google account, Google forced me to decipher almost unreadable characters in an image to go through the sign up process, something like below.

Google Accounts

It is really hard to read, at least for me. Presumably harder for bots. That way, Google have been avoiding signing up from bots. Good for Google. However, they force me to feel a pain. The problem is that if Google, like the above example, tries to strengthen CAPTCHA, it will become more difficult for users to read the characters in a CAPTCHA image. It is not user friendly at all. As an agile developer, I would love to make users happier as time goes. Here is Kenn's idea to tackle the problem. Since the context is "Do the simplest thing that could possibly work,” I would just mention about one of the simplest examples in his blog post.

First, introduce a hidden field whose id is token:


<input id="token" type="hidden">


Then, add a simple javascript to the page:


<script type="text/javascript">
document.getElementById('token').value = 'Thu Feb 28 00:06:14 -0800 2008'
</script>


On the server's side, we can verify if the token value is reasonable. In Rails, it could be like:


def verify_token
t = Time.parse(params[:token]) rescue Time.gm(0)
Time.now.between?(t, t + 2.hours)
end


Simple enough. While drastically reducing users' pain, the strength of this implementation against bots is equivalent to Jeff's simple CAPTCHA implementation, isn't it? One step closer to the goal of Agile Development, making users happier.

Thanks Jeff and Kenn for their posts.

No comments:

Post a Comment