New Release: BridgeDB 0.9.3

by phw | February 11, 2020

When ISPs or governments block access to the Tor network, our users rely on bridges to connect. With BridgeDB, we tackle the problem of how to get bridges to censored users while making it difficult for censors to get all bridges.

A lot has changed since our last blog post, which introduced BridgeDB version 0.7.1. We recently released BridgeDB version 0.9.3, which comes with the following bug fixes and new features:

  • Ticket 24607: We recently made BridgeDB's CAPTCHAs easier to solve by reducing the amount of noise in images. Our usage metrics reveal that the success rate increased from ~50% to ~80%. How is your experience with BridgeDB's CAPTCHAs? Let us know in the comments!
  • Ticket 9316: BridgeDB is now reporting privacy-preserving usage metrics every 24 hours. These metrics help us understand how users interact with BridgeDB. For example, these metrics reveal that Moat is our most popular distributor and obfs4 is our most requested transport protocol. The raw metrics are archived on CollecTor but you can also take a look at the number of requests per transport and requests per distributor on Tor Metrics.
  • Ticket 31252: BridgeDB sees many automated requests from bots. This patch makes it possible to detect and block bots based on their HTTP parameters.
  • Ticket 26543: We added a language switcher menu to the top right corner of BridgeDB's user interface.
  • Ticket 32203: We fixed a bug that resulted in missing requests for vanilla bridges.
  • Ticket 32134: Request another translation and update BridgeDB's documentation on how to request translations.
  • Ticket 32105: We debugged and fixed an email responder issue that emerged after upgrading BridgeDB's underlying operating system to Debian buster.
  • Ticket 31903: We updated existing translations and published translation requests for new strings.
  • Ticket 31780: This patch adds a specification for the metrics we implemented as part of ticket 9316.
  • Ticket 29484: We updated BridgeDB's requirements to their latest respective versions.
  • Ticket 17626: We helped BridgeDB's email responder deal with quoted email responses. This should make the email responder more pleasant to interact with.
  • Ticket 28533: We added links to our Support Portal and our Tor Browser Manual to BridgeDB's landing page and we removed the front desk's email address, which greatly reduced the number of automated email requests.
  • Ticket 26542: We fixed a bug that prevented BridgeDB from handing out vanilla IPv6 bridges.
  • Ticket 22755: Some of BridgeDB's unit tests require bridge descriptors to work. We have been using the tool leekspin to create fake descriptors before unit tests are run. This patch replaced leekspin with a script that uses stem to create fake descriptors. This simplifies our unit tests and reduces the number of BridgeDB's dependencies.

Several other bug fixes and features are already in development. You can expect the following changes in the near future:

  • BridgeDB was originally implemented in Python 2, which is no longer supported since January 1, 2020. We have been busy porting BridgeDB's code base to Python 3 and we're almost done.
  • As part of Sponsor 30, we are working on several UX improvements. For example, we will build a feedback loop between BridgeDB and OONI: BridgeDB will learn from OONI what bridges are blocked where, and use this knowledge to be smarter about bridge distribution. For example, if a user from Turkey is requesting bridges, BridgeDB will no longer hand this user bridges that are blocked in Turkey.

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

February 11, 2020

Permalink

The reduction in the amount of noise in BridgeDB CAPTCHA images is excellent. Thanks for the tasty improvement.

Anonymous (not verified) said:

February 12, 2020

Permalink

Great work! I hope translators are informed to participate. I'm interested in BridgeDB learning from OONI.

I don't think I've ever had issues with BridgeDB's CAPTCHAs. Although, please don't make them so easy that AI bots can solve them. Thanks for implementing ticket 31252 at the same time.

Anonymous (not verified) said:

February 23, 2020

Permalink

If you're using obfs4, couldn't an eavesdropper between you and the hidden bridge deduce that it's obfs4 and therefore that it's to Tor very simply by realizing it doesn't look like any standard protocols and watching your idle connection predictably make a new connection every 10 minutes?

Obfs4 gets its censorship resistance properties by trying not to look like any standard protocols. It turns out that there's a lot of Internet traffic already that is hard to classify as something known and obfs4 attempts to hide in that "long tail" of unclassifiable traffic. This is the subject of ongoing research, and right now the answer seems to be "no". However, see some interesting recent research on the subject.

We've also done some small-scale tests to see whether our unpublished bridges have been detected, and so they haven't. See https://bugs.torproject.org/29279 for more details.

Anonymous (not verified) said:

February 24, 2020

Permalink

Some great work here, and especially including it in Tor Metrics.

On that note I was curious to find out about Tor's overall bridge usage, it seems Tor had a few noticeable spikes in bridge users, up to 4x normal within the past few years since metrics began logging, but always seems to revert back to minimum levels of around 50k users (if anyone might deduce a reason for this odd behavior beyond standard censorship its appreciated)

I'd like to see the Tor Blog continue to hold periodic public discussion as to ways both to connect more censored users to bridges, and encouraging others to themselves run bridges. As the best way to grow Tor is to get the word out.

Apologies if this is the wrong place, but the rest of the blog generally locks discussion after about a week, so discussing Tor related topics can prove difficult for the public.

Anonymous (not verified) said:

March 01, 2020

Permalink

I got three bridges today from BridgeDB's http onion service. I then hashed their fingerprints and went to metrics' Relay Search to make sure they were good, and it told me one of the three is "Not Recommended". So 1/3 of my activity would go first through a bridge that isn't recommended. Any relay, including bridges, that is deemed necessary to be flagged as not recommended should not be allowed on the network much less given out by BridgeDB.

Here is its hashed fingerprint, not the sensitive fingerprint in its bridge line.
EB822E8EEDDD047D93F3E580023A30FED9C090A4
"version":"0.2.9.16" (possibly Debian stretch (oldstable))
"version_status":"obsolete"
"recommended_version":false

Speaking of Tor's relay fingerprints, all of them, hashed and not, are in SHA1 which was recently reported to have vulnerabilities as well.