[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] A proposal to phase out CAPTCHAs for BridgeDB
On Thu, Jul 29, 2021 at 04:46:37PM -0400, Cecylia Bocovich wrote:
> Hi everyone,
>
> We've been working on improving the usability of BridgeDB lately, and
> our CAPTCHAs have been a constant thorny problem. They are not
> accessible for blind users [0]. We've gotten many complaints over the
> years that they are hard to use [1], I'm sure Gus and the community team
> members can vent about the impact they've had on users.
Yeah :/
>
> We even have some evidence that bots have been able to enumerate our
> CAPTCHAs just fine [2].
Many moons ago, BridgeDB proxied CAPTCHA challenges from ReCAPTCHA [7],
instead of creating and serving its own. Eventually, Isis implemented
the current custom (GIMP) CAPTCHA system themselves because ReCAPTCHA
served impossible challenges [8].
> There are other anti-enumeration defences on
> BridgeDB that are perhaps more useful including:
[snip]
> I would like to propose that we remove the CAPTCHAs from BridgeDB
> entirely, but I'd like to know whether there is research out there
> *specifically that fits with the anti-censorship context* showing that
> these CAPTCHAs are actually doing useful work to prevent Bridge
> enumeration. But, even if the CAPTCHAs are preventing a small number of
> censors from enumerating more bridges, is the usability impact worth
> what marginal benefit we get from it?
>
> Options for how to move forward:
>
> Option 1: Just remove the CAPTCHAs already!
>
> We're tired of waiting and just want our bridges.
For mostly obvious reasons, this option worries me.
>
> Option 2: Do some science?
>
> We could make a new distribution bucket in BridgeDB that distributes
> bridges through Moat without a CAPTCHA and have new versions of Tor
> Browser pull from this bucket. We can watch and perform measurements in
> places we know enumeration attempts have occurred in the past and see
> whether these bridges are enumerated more quickly and more completely
> than the old-school Moat bucket.
I like this idea.
>
> Option 3: Keep doing what we're doing but try to make the CAPTCHAs more
> usable.
>
> This is the work we've had planned, but will only get us so far.
>
I'd be interested in this one, too, with a bit of (2) and some science.
We could conduct an(other) experiment where the current CAPTCHA system
is the control, and BridgeDB serves challenges from e.g., hCAPTCHA, 50%
of the time, and that new experimental CAPTCHA system protects a new,
independent, bridge bucket (like in 2).
There could be three outcomes:
1. Success/Failure rates of challenges per connection (summarized by
quartiles?)
2. How many new bridges are blocked from within the countries
identified in (2) after some time period?
3. How quickly new bridges are blocked from within the countries
identified in (2)?
At the end of the day, my primary concern is whether *people* have
access to the resources they need. I appreciate the the difficulty of
this situation and running a service like this (and I don't envy you :)).
>
> Endpoint enumeration is a tricky topic and we do have some other
> alternatives in the pipeline. Conjure is more of a "blocking resistance
> through collateral damage" approach that's somewhat similar to domain
> fronting [5]. We've been looking at and hope to do more work in the
> future on reputation-based bridge distribution [6]. I see these as more
> promising than CAPTCHAs in the long run, and CAPTCHA-less BridgeDB
> bridges seem to still fill a need that built-in bridges and private
> bridges don't fill.
I agree, and this sounds good to me.
Thanks!
>
> I'd appreciate any thoughts, comments, or experiences others have!
>
> Cecylia
>
> [0]
> https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10831
> [1]
> https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/24607
> [2]
> https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/32117
> [3]
> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs4/-/issues/31701
> [4]
> https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/blob/main/reports/2020/belarus/2020-belarus-report.md
> [5] https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/9
> [6]
> https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31873
[7]
https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/5481
[9]
https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10809
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev