Linkoteca. ReCaptcha

Before implementing a captcha, it’s worth considering if one is necessary to begin with. To help with evaluating this proposition, consider if your threat model is concerned over customized or uncustomized spam. Uncustomized spam is pervasive across many Internet protocols, and you will encounter it quickly after enabling HTTP, SSH, or many other protocols on a server. It is generally unintelligent, cheap to execute, and easy to block, even without captchas. Customized spam, however, is spam that has been written to specifically affect a given company, service, website, or user. As customized spam is created by an actor that is able to tailor it to your service, it is more dangerous than uncustomized spam, and more effort is required to effectively limit it.

Just because someone could spend hours (or minutes) writing a program to spam your website does not mean that someone will. Your personal blog about the latest vegan bacon is not a high-priority target for anyone. Adding a ReCAPTCHA to your Contact Me page is just a great way to get no one to talk to you. I’ve ran several websites with millions of pageviews that have received zero customized abuse and have spoken to other webmasters with similar experiences. Jeff Atwood of codinghorror.com once wrote similarly:

The comment form of my blog is protected by what I refer to as “naive captcha”, where the captcha term is the same every single time. This has to be the most ineffective captcha of all time, and yet it stops 99.9% of comment spam.

This is not a suggestion to do nothing, ignore basic security, and be unprepared for attacks, but rather to realistically consider your threat model and apply only what is necessary.