Per T241921: Fix Wikimedia captchas, Wikimedia captchas are badly broken and need fixing. @TheDJ pointed out that there is an opensource captcha called mCaptcha that does not require user interaction (it's based on proof-of-work, ie. making the browser do a lot of work to make registration uneconomical for spambots), which would fix at least some of our captcha woes. There are also some other PoW capctha effort such as forest/pow-captcha and xenohunter/lapti-pow-captcha. We should look into whether one of those is an acceptable captcha replacement.
Some questions to consider:
- mCapctha is AGPL, is that an acceptable license for us? (See T76158: Pitfalls checklist for software using AGPL for past discussions on the issue.) pow-captcha and lapti-pow-captcha are GPLv3 and MIT respectively so no issue there.
- are these capcthas actually accessible? From the user POW, you only need to check a checkbox, but will common screen reader software handle the JS code required for proof of work? (mCaptcha uses WASM and provides a polyfill; pow-captcha uses WASM and Web Workers; lapti-pow-captcha is largely undocumented but seems to use Web Workers) Will they cause problems on cheap devices with slow CPU? Will they make the browser unresponsible? Is the slowdown in signups that they cause a problem?
- we'd probably want to self-host for privacy reasons (mCaptcha has a SaaS service, for the other two it's not even an option), are there any operations concerns? mCaptcha is rust/Postgres/Redis and comes with a Docker container; pow-captcha is in go; lapti-pow-captcha is node.js (and largely undocumented but also very simple)
- are they easy to fit into our login form in terms of UI style and i18n?
- most importantly, do they actually stop spambots? Even if it is uneconomical for a spambot to do expensive proof of work tasks, it might not be clever enough to bail out, in which case all we added was a few seconds delay during spambot registration.