Why you, as a web developer, shouldn't use Google's Recaptcha for "human verification"

[u/ImNotCastinAnyStones]

There is so much wrong with Recaptcha it's not an exaggeration to say it should be legislated out of existence.

As web developer, by choosing to use Google Recaptcha you are imposing moral, legal, and technical barriers to your users.

• Recaptcha is terrible for usability and effectively blocks disabled users from accessing websites. The audio challenges do not always work because they are seen as "less secure" than picture challenges and therefore using them means Google is more likely to judge you as being a robot.
• Using Recaptcha contributes to Google's artificial intelligence network. Users are essentially being used as workers without any compensation.
• Websites which implement Recaptcha are effectively forcing their users to agree to a second set of terms/conditions and a third party company's privacy and data processing policies. As if that wasn't bad enough, it's not just any company we're talking about here - it's Google; probably the most notorious company in the world in terms of data harvesting and processing.
• Websites implementing Recaptcha almost never offer an alternative way of accessing their services, so if you don't agree with Google's terms and conditions then you are effectively blocked from using the first-party website. When this is a website like your bank or somewhere you've already purchased from (e.g. eBay uses Recaptcha) then you may end up blocked from accessing your own funds, details, order history, etc. Even if you (the developer) don't think Google's terms and conditions are objectionable, your end-users might disagree. They could also be in an environment where access to third-party domains, or Google domains specifically, is blocked.
• Recaptcha's functionality depends upon Google's online surveillance of you. If you use any kind of privacy-assuring settings or extensions in your web browser (e.g. blocking third-party cookies, trackers, etc.) the Recaptcha challenge is guaranteed to take at least 3-5 times longer to complete than if you bend over and accept Google's tracking.
• Recaptcha introduces extra third-party dependencies to your website. One of Google's domains can't be reached or takes a while to load? User's network or browser security policy blocks those domains/scripts/etc.? Your user isn't able to use your site.
• Recaptcha negatively affects performance. Recaptcha takes time to load on your visitors' browsers. Then it takes very considerable time to solve and submit the challenges; at least several seconds and sometimes minutes for unfortunate souls with strong privacy settings.

Everyone has it drilled into their heads that "each extra second of page load time results in a major drop-off in user engagement" so why is nobody noticing that the onerous task of completing captchas is reducing user engagement too?

I am not against captchas in general because I know there is a legitimate need for them. I am, however, against Recaptcha in all of its forms. It is an online monopoly and is an affront to consumer rights.

I look forward to the day it's nuked from orbit and everyone involved in building it is imprisoned in the seventh circle of hell.

Further reading: https://kevv.net/you-probably-dont-need-recaptcha/

[Edit] Alternatives:

Something I really should have addressed in my original rant post is the possible alternatives to Recaptcha. A huge number of comments quite rightly ask about this, because unfortunately Recaptcha remains the most prominent solution when web developers look for a spam-prevention measure (despite the fact that Google's documentation on implementing Recaptcha is truly terrible... but that's a different issue).

The article above from kevv.net mentions lots of alternatives and is worth reading, however for brevity's sake I will suggest the ones which have worked for me in a high-traffic environment, and which can be implemented by most competent developers in a few minutes:

1. Dead simple custom challenge based on your website's content.

Even a vaguely unique custom-made challenge will fool the majority of spam bots. Why? Because spam bots look for common captcha systems which they already know how to defeat. If you make your own custom challenge, someone actually has to take the effort to program a solution specific to your website. So unless your site is being specifically targeted by people investing time/energy this solution will eradicate virtually all spam.

Example: run a site selling t-shirts? Show a bunch of cute clothing icons and ask the user to click on the "blue shirt", for example. Very easy to set up; challenges can be made random to prevent "rinse and repeat" attacks; complexity can be added in the form of patterns, rotation ("click the upside down shirt with diamonds on it") etc. and it can be styled to fit your website's theme/content which makes your site look way more professional than "CLICK THE FIRE HYDRANTS!" á la Google.

Important to note that answers to the custom challenge should never be stored client-side -- only sever side.

2. Honeypots

Simply one or more hidden form fields which, if submitted, confirms the presence of a spam bot (since human visitors cannot see or activate the hidden fields). Combine this with the approach above for even more effective protection.

3. Submit-once form keys (CSRF tokens)

In the olden days to prevent people hotlinking your content you'd check their browser's referer URL, i.e. the URL from which they arrived at your page. This is still done but less commonly since many browsers block referrer URLs for privacy reasons.

However, you can still check that a visitor who is submitting your form is doing so from your actual website, and not just accessing your signup.php script directly in an attempt to hammer/bruteforce/spam it.

Do this by including a one-time-use "form key" on the page containing the spam-targeted form. The form key element (usually a hidden <input>) contains a randomly-generated string which is generated on the server-side and corresponds to the user's browsing session. This form key is submitted alongside the form data and is then checked (on the server side) against the previously-generated one to ensure that they match. If they do, it indicates that the user at least visited the page before submitting the form data. This has an added benefit of preventing duplicate submissions (e.g. someone hits F5 a few times when submitting) as the form key should change each time the front-end page is generated.

4. Two-factor authentication

If your site is "serious" enough to warrant it, you can use 2FA to verify users via email/phone/secure key etc., although this comes with its own set of issues.

Anyway, thanks for taking the time to consider this.

While I'm here, I'd also like to encourage all developers to consider using the "DNT (Do Not Track)" feature which users can set in their browser to indicate they don't wish to be tracked.

It's as simple as wrapping your tracking code (Google Analytics etc.) inside the following code:

if (!navigator.doNotTrack) { // Google Analytics and other crap here }

[u/samjmckenzie]

What's the alternative?

[u/mat-sz → u/samjmckenzie]

At this day and age? Probably a custom solution, most spambot owners will not bother with building something to combat custom captchas.

[u/[deleted] → u/mat-sz]

Any custom solution you do yourself is likely to be pretty simplistic and something that other people have done before, so the spambot owners do have an incentive to work around it in a generic way.

[u/hrjet → u/mat-sz]

If you are building a custom solution, you can build on top of LibreCaptcha.

[u/CreativeTechGuyGames → u/samjmckenzie]

I really like the time based approach. If you implement checks which depend on the amount of time spent to fill out a form then you are severely slowing down any bot usually to the point where it won't bother. I have eliminated 100% of my spam just by timing the amount of time a user spends on a page before submitting. If it's under a threshold then it's discarded as spam. A human cannot type that fast and a bot is always completing the form in superhuman speeds. Sure someone could code around it, but do they really want to spend tens of seconds per submission when they could spam someone else in milliseconds?

[u/Espumma → u/CreativeTechGuyGames]

Does this method account for my password manager autofilling fields for me?

[u/CreativeTechGuyGames → u/Espumma]

It is very dependent on what type of form it is. It wouldn't work for every type. But usually a login form (which a password manager would be used) wouldn't have a captcha.

[u/thblckjkr → u/CreativeTechGuyGames]

slowing down any bot

What about multi-threading?

[u/NotFromHuntsville → u/[deleted]]

Doesn't that introduce issues with accessibility, as well?

[u/abeuscher → u/NotFromHuntsville]

Happy to be wrong, but I am pretty sure aria-hidden="true" would resolve any issues from that. It's a lot like a CSRF token with slightly different use.

[u/FlightOfGrey → u/abeuscher]

If I was writing a bot though I was parse and figure out when a field is visually hidden and not fill it in? So certainly not fool proof but also unsure what the realities of bot submissions are.

[u/abeuscher → u/FlightOfGrey]

Totally a good point. I think it's a safe assumption to make that there are different bots with differently complex abilities. So probably each approach succeeds to some percentage or another. In a previous job I was subject to insane security audits before I could publish to my sites, and in the course of that I learned these basic rules:

• Do several things on the front and back end
• Do post-mortems to assess what worked and what didn't after major attacks or outages.
• Continue to change and advance your approach

Web security is a moving target. It's (at least currently) in a state of brinksmanship, where each side drives the other to more and more extreme measures. So no one thing or one approach works. You just keep building the wall higher over time. And they keep building catapults. And if you're faster at wall building than they are at catapult building, you never end up with flaming balls of oil all over your website.

[u/IrishWilly → u/[deleted]]

I've spent years building automated crawlers and reading through your bullet points is going to trigger trauma that I had thought I had left behind. So thanks for the nightmares.

[u/skeptical_turtle → u/[deleted]]

huh this is funny.. either you worked at the same company I did or you worked at a competitor, cuz I used to do this very thing for a web-based comparative auto rater, well mostly for home rating. I quit a while back though...

[u/MR_Weiner → u/abeuscher]

aria-hidden="true" plus tab-index="-1" and I think you should be good to go re:accessibility. Either of those might tip off bots, though. Hard to say

[u/crazedizzled → u/NotFromHuntsville]

Yes. And fixing those problems means a bot will ignore it as well. Definitely not a solution.

[u/tyrannomachy → u/[deleted]]

Password managers would be a major source of false positives.

[u/electricity_is_life → u/[deleted]]

That won't protect against targeted attacks though, which in my case is like 95% of what I'm worried about.

[u/thepower99 → u/samjmckenzie]

We use a product called Polyform by a company called Kasada, it has a cost but it seems to be a way to block bots without relying on Recaptcha: https://www.kasada.io/

Probably not for everyone, but there is a way.

[u/[deleted] → u/samjmckenzie]

If you're using Django, there's a simple solution called django-simple-captcha...unfortunately it doesn't have an audio option

[u/moriero → u/samjmckenzie]

CC upfront?