rdsys issueshttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues2020-10-29T18:33:40Zhttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/3Reimplement and generalise BridgeDB?2020-10-29T18:33:40ZPhilipp Winterphw@torproject.orgReimplement and generalise BridgeDB?Over at legacy/trac#30946, I spent several hours trying to port BridgeDB to Python 3 but progress has been frustratingly slow. Given the port and our in-progress grant application proposing a social bridge distributor, I started thinking...Over at legacy/trac#30946, I spent several hours trying to port BridgeDB to Python 3 but progress has been frustratingly slow. Given the port and our in-progress grant application proposing a social bridge distributor, I started thinking about a rewrite of BridgeDB. Here's how I see the (dis)advantages breaking down:
Disadvantages:
* Re-implementations are never as smooth and straightforward as anticipated. It will take a lot of time.
* We won't (easily) be able to use Stem to parse bridge descriptors. We could extend [zoossh](https://gitweb.torproject.org/user/phw/zoossh.git/) though.
Advantages:
* We could re-implement the service in golang because the anti-censorship team is comfortable in the language.
* We could generalise the concept of BridgeDB: What goes in should be an abstract type of proxy (be it bridge descriptors, snowflake-style proxy registrations, or maybe even Lantern proxies) and distributors (as we already have them in BridgeDB) determine who gets these proxies.
* We would design the service with redundancy and "containerisation" in mind.
* It would make it easier to add new features, especially significant ones, like a new distributor.
* A re-implementation may be a return on investment and save us time in the long run.
Note that we don't need to abandon BridgeDB and then redirect our focus to its re-implementation. I would instead like to spend some hours experimenting with a new design in parallel to maintaining BridgeDB. We also don't need to aim for a feature-complete replacement of BridgeDB. For example, we don't need to PGP-sign emails. If all of the above proves fruitful, we can gradually transition to the new design.
Thoughts? Any other features or architectural changes we should make in a re-implementation?Sponsor 30 - Objective 2.3Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/1Implement the Salmon bridge distribution mechanism2020-10-29T18:08:40ZPhilipp Winterphw@torproject.orgImplement the Salmon bridge distribution mechanismBridgeDB currently has three bridge distribution mechanisms: Email, HTTPS, and moat. Email is problematic because its interaction mechanism is complicated, not everyone has a Gmail or Riseup address, and it's easy to crawl. HTTPS is prob...BridgeDB currently has three bridge distribution mechanisms: Email, HTTPS, and moat. Email is problematic because its interaction mechanism is complicated, not everyone has a Gmail or Riseup address, and it's easy to crawl. HTTPS is problematic because bridges.torproject.org is blocked in most places that matter and our CAPTCHA is good at keeping out users (legacy/trac#29695) but not so good at keeping out bots (legacy/trac#31252). Moat remains relatively useful because it uses domain fronting but it also relies on a CAPTCHA to fight off bots.
It's time to think about new and/or significantly improved bridge distribution methods. How can we get bridges into the hands of users while making it difficult for adversaries to get them all? How can we make BridgeDB's CAPTCHA more resistant against bots and easier for users?
The Salmon bridge distribution system (first presented in a [PETS'16 paper](https://censorbib.nymity.ch/#Douglas2016a)) is promising. Let's use this issue to build a prototype and fill in the missing pieces to get Salmon deployed.Sponsor 30 - Objective 2.3Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/52Translate GetTor messages2024-02-27T18:20:31ZtraumschuleTranslate GetTor messagesThis is the parent ticket to translate GetTor into more languages, especially for censored areas.This is the parent ticket to translate GetTor into more languages, especially for censored areas.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.org