[tor-bugs] #30872 [Circumvention/Censorship analysis]: Test BridgeDB's distribution channels in controlled experiment

[Tor Bug Tracker & Wiki]

#30872: Test BridgeDB's distribution channels in controlled experiment
---------------------------------------------------+-----------------
     Reporter:  phw                                |      Owner:  dcf
         Type:  project                            |     Status:  new
     Priority:  Medium                             |  Milestone:
    Component:  Circumvention/Censorship analysis  |    Version:
     Severity:  Normal                             |   Keywords:  gfw
Actual Points:                                     |  Parent ID:
       Points:  3                                  |   Reviewer:
      Sponsor:  Sponsor30-can                      |
---------------------------------------------------+-----------------
 As of June 2019, BridgeDB distributes bridges over HTTPS, email, and moat.
 We should find out which ones of these three distribution channels censors
 can break by injecting test bridges into all of them, and monitoring for
 how long these bridges continue to be reachable. For now, we should focus
 on China.

 1. Set up at least three bridges; one for each of our three distribution
 channels. The bridges can use the `BridgeDistribution` tor option to tell
 BridgeDB how they choose to be distributed.
 2. We may also want to disable the bridges' ORPort and use
 `AssumeReachable` to rule out the possibility that the censor found the
 bridge by discovering its ORPort somehow.
 3. Have a client in China continuously test these bridges at random times,
 so we can learn when (and if) they stop being reachable.
 4. Wait and keep an eye on the country code of clients who use these
 bridges. We shouldn't be collecting any more data because the bridges will
 be used by real users.

 We probably want more than one bridge per distribution channel. For
 example, if our HTTPS bridge becomes blocked, we don't know for sure that
 the GFW is able to enumerate a large fraction of the HTTPS pool.
 Theoretically, a GFW engineer could have gotten the bridge after a single
 request to bridges.torproject.org. The more bridges we have, the more
 confident can we be in our results.

 Also, we should understand how BridgeDB maintains its sub-hashrings per
 distribution channel.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30872>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online