Build a bridge censorship measurement system for Salmon
Salmon needs to know if and when a bridge is blocked, so it can update client reputation scores. Let's use this issue to build that censorship measurement mechanism. There are several ways to go about this:
-
We could set up bridgestrap instances in censored networks and design a control channel between our central rdsys instance and the various bridgestrap instances. wolpertinger was originally designed for that and we may be able to reuse some ideas and code. See censorship-analysis#34258 for more details.
-
We can outsource the problem to OONI. That was the original plan but OONI probes are run by untrusted strangers, some of which could be censors that try to find and block bridges. OONI, at least in its current form, is therefore not a good choice.
-
We could incorporate passively-gathered data like the countries from which bridges have recently seen clients.
Option 1) strikes me as a good way forward because we already have a lot of the necessary code in place. Essentially, we still need a low-bandwidth, low-latency, censorship-resistant communication channel between bridgestrap instances in various countries and rdsys. If we go down that route, a few more questions emerge:
- Should the bridgestrap instances periodically poll for new bridges to test? Or should rdsys push these bridges to bridgestrap?
- What should the censorship-resistant communication channel look like? A domain-fronted API like moat may be good enough.
- How should rdsys communicate with these bridgestrap instances? Should it implement a new distributor like wolpertinger? Or should this functionality live in the backend? For what it's worth, rdsys's bridge testing mechanism lives in the backend.