This email introduces our plans for BridgeDB's future. I attached a diagram that illustrates how these plans integrate into BridgeDB's existing design. Red components in the diagram (Salmon, bridgestrap, and wolpertinger) are new, and in the process of being built. I introduce these components below.
The Salmon social distributor ---------------------------------
A PETS'16 paper introduced the Salmon social proxy distributor: https://censorbib.nymity.ch/#Douglas2016a
In a nutshell, Salmon hands out bridges to users while maintaining per-user reputation scores. Alice's reputation goes up if her bridge remains unblocked after she got it, and it goes down if the bridge is blocked after Alice got it. Users can invite each other, which results in an invitation graph. Eventually, we will hopefully have a Salmon distributor which will live alongside our Moat, HTTPS, and Email distributors.
If this interests you, consider attending our anti-censorship meeting on May 14 because we will be discussing the Salmon paper as part of our reading group: https://trac.torproject.org/projects/tor/wiki/org/teams/AntiCensorshipTeam#IRCmeetingsschedule
We are only just starting to think about Salmon, so I have no code or design to share at this point. All that matters for now is that Salmon needs to know where bridges are blocked. BridgeDB does not have this information but the following software components seek to fix that.
Bridgestrap -----------
Bridgestrap exposes an API that takes as input a bridge line and responds by telling you if it could establish a Tor circuit over the given bridge. BridgeDB will check with bridgestrap if the bridges it's about to hand out actually work. This isn't always the case as the following ticket shows: https://bugs.torproject.org/30441
We have a working prototype of bridgestrap: https://gitlab.torproject.org/phw/bridgestrap
We coordinate development in this ticket: https://bugs.torproject.org/31874
Wolpertinger ------------
Wolpertinger exposes an API that lets censorship measurement platforms like OONI request bridges to measure. Wolpertinger later fetches OONI's test results and feeds them back into BridgeDB's bridge database. This allows BridgeDB to take into account a user's location when distributing bridges: a user in Turkey won't be given bridges that are known to be blocked in Turkey.
In addition to OONI, we could repurpose bridgestrap as another censorship measurement tool by setting it up on a VPS in, say, Turkey and have wolpertinger periodically feed it bridges to test.
Wolpertinger is work in progress but we already have some code: https://gitlab.torproject.org/torproject/anti-censorship/wolpertinger
We coordinate development in this ticket: https://bugs.torproject.org/32740
A practical example -------------------
To illustrate how these pieces fit together, let us consider the example in the attached diagram. Imagine that the bridge 1.2.3.4:1234 was just set up and reported itself to Serge, our bridge authority. Serge syncs its bridge descriptors to BridgeDB every 30 minutes and BridgeDB reloads those descriptors every 30 minutes, so it takes a maximum of 60 minutes until BridgeDB knows about this new bridge.
Now, a user from Turkey requests a bridge over HTTPS. Since BridgeDB sees the user's IP address, it knows that the request is coming from Turkey.
First, BridgeDB will ask a local instance of bridgestrap if the bridge it intends to hand to the user is working. This is important because the only testing we currently have in place is done by the bridge authority, which makes sure that a bridge's OR port is reachable. Nothing is testing a bridge's obfs4 port, which means that a user may end up with a bridge whose obfs4 port is firewalled.
Bridgestrap can tell BridgeDB if a bridge is functional but it doesn't know if the bridge is blocked in Turkey. This is where wolpertinger comes in. Wolpertinger works in an asynchronous manner to BridgeDB and 1) hands out bridges to OONI probes, 2) collects OONI's test results, and 3) writes these results back to BridgeDB's bridge database, allowing BridgeDB to learn if a given bridge is blocked in Turkey.
If everything works out, our user will receive bridges that are functional and unblocked in Turkey.
Please let me know if you have questions or feedback.
Cheers, Philipp