CAPTCHAs on BridgeDB seem to be getting more difficult
I just tried to solve 12 CAPTCHAs unsuccessfully before I got to one that worked. In each, at least one or two characters was impossible to discern.
Activity
added actualpoints::1.1 in Legacy / Trac anti-censorship-roadmap-2020Q1 in Legacy / Trac component::circumvention/bridgedb in Legacy / Trac owner::phw in Legacy / Trac parent::31279 in Legacy / Trac points::5 in Legacy / Trac priority::medium in Legacy / Trac resolution::fixed in Legacy / Trac s30-o22a2 in Legacy / Trac severity::normal in Legacy / Trac sponsor::30-must in Legacy / Trac status::closed in Legacy / Trac type::defect in Legacy / Trac labels
Trac:
Parent: N/A to legacy/trac#31268 (moved)-
Trac:
Parent: legacy/trac#31268 (moved) to legacy/trac#31279 (closed) -
Let's use this ticket to coordinate the future of BridgeDB's CAPTCHA. BridgeDB currently uses gimp-captcha to generate CAPTCHAs.
-
We believe that the GFW maintains a bot (which, ironically, uses Tor) that is successfully crawling BridgeDB while maintaining a CAPTCHA success rate that easily outperforms people. Not only does our CAPTCHA harm usability (see also legacy/trac#10831 (moved)), it also fails in the face of a real-world adversary.
-
Google provides a reCAPTCHA v3 API, which returns an anomaly score in the interval [0, 1] for each request, without any kind of friction. Ignoring for now that this is a Google service, it may be an option for BridgeDB's HTTPS distributor but not for moat or email.
-
There is plenty of research on new CAPTCHA schemes, sometimes leveraging more complex domains like video or adversarial examples, which are meant to confuse classifiers. None of these systems seems likely to make a difference in the long term.
We are in a particularly difficult situation because our CAPTCHA needs to work for a highly diverse set of people.
-
