reCAPTCHA: what it checks and what it cannot do

« Blog · By

Almost every form on the web is protected by a captcha these days, usually Google's reCAPTCHA. We use it ourselves. It is still worth a sober look at what it actually achieves — and what it does not.

The three variants

  • v2 with a checkbox — the familiar "I'm not a robot". If in doubt, the image puzzle follows.
  • v2 invisible — no checkbox, the check runs in the background and only surfaces on suspicion.
  • v3 — no interaction at all. Returns a score between 0.0 and 1.0, and the site decides for itself where to draw the line.

What is actually being checked

Not the checkbox. The click is essentially the trigger; the real assessment happens before and around it. Among other things:

  • mouse movement, typing behaviour, timing
  • existing Google cookies, and with them the browser's history
  • reputation of the IP address
  • browser characteristics: resolution, fonts, plugins, time zone — together often unique

Which is why arriving with a fresh browser profile over a VPN and no Google cookies gets you the image puzzles far more often. That is not a fault, it is the principle: with no history there is nothing for trust to rest on.

The step many people skip

A captcha in a form is worthless unless the response is verified server side. The sequence has to be:

  1. The browser obtains a token and submits it with the form.
  2. The server sends that token together with its secret key to the provider's verification endpoint.
  3. Only when the answer says success: true is the form processed.

Skip steps two and three and it is enough to simply omit the field on submission — a script is done faster than a human. We verify server side; a missing token is rejected as well.

What it does not help against

  • Humans. Anyone willing to fill in the form by hand gets through. A captcha limits volume, not intent.
  • Paid solving services. There are providers who solve captchas for fractions of a cent. Against commercially motivated abuse that is no obstacle.
  • Abuse after submission. The captcha checks once. What happens with the account afterwards is invisible to it.

So a captcha is one layer among several, not the solution. In our case the real brake sits behind the form: outgoing messages are reviewed before delivery.

The data protection question

reCAPTCHA transmits the IP address and interaction data to Google. Anyone deploying it in the EU has to disclose that in their privacy policy and name a legal basis; the usual one is legitimate interest in preventing abuse. Whether that holds depends on whether a less intrusive means exists — and depending on the form, it often does.

Alternatives

  • Honeypot field. An input hidden by CSS that humans never fill in. If it has content, it was a script. Costs nothing, transmits nothing, and catches a surprisingly large share of the background noise.
  • Timing. A form submitted after 400 milliseconds was not filled in by a person.
  • Rate limits. A capped number of operations per IP per time window. Effective against volume, regardless of human or machine.
  • Proof of work. The browser solves a small computation. Imperceptible for one user, expensive for a thousand requests. Implementations such as Altcha or Friendly Captcha work without sending data to third parties.
  • hCaptcha. Functionally similar, different provider — the underlying privacy question remains.

Conclusion

reCAPTCHA keeps automated background noise away, and that is worth a lot. It replaces neither rate limits nor content review where abuse actually hurts. For many forms the combination of honeypot, timing and rate limiting would be the more data-frugal choice with comparable effect.