See https://en.wikipedia.org/wiki/Wikipedia:Perennial_proposals#Use_reCAPTCHA and T34695: Implement, Review and Deploy Wikicaptcha

I instead think that WMF should develop a better (preferred standalone) CAPTCHA service which can be used by Wikimedia sites, external MediaWiki sites and tools hosted in Cloud VPS and Toolforge (currently some tools uses reCAPTCHA which is not consistent with T133919).

I assume, that you ask, that Wikimedia wikis should use reCaptcha, right? I remove the ConfirmEdit tag, as ConfirmEdit already supports the reCaptcha service, and it just has to be included in the configuration (instead of using another CAPTCHA module), so there's nothing to do in the ConfirmEdit extension :)

My understanding is that it was considered not an option in 2008 for reasons that AFAIK have not changed, so this is probably a duplicate of a wontfix.

As someone who has locked thousands of spambots, and continue to do so, any help in stopping the registration of that crap would certainly help. I can understand however the privacy concerns on using an external service like Google reCaptcha.

1- That captcha is not accessible, is annoying (all captchas are to some point, though), slow to solve, sometimes ambiguous, and generally a pain to pass (even in the best case).

2- It would be a gross violation of WMF current Privacy Policy.

I have instead posted my idea at T174874: Create a standalone Wikimedia CAPTCHA service.

Currently there's discussion on using another external Captcha service, see T250227: Investigate and evaluate hCaptcha to replace Wikimedia's Fancy Captcha.

Also @Legoktm and @Tgr for notice.