Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • C censorship-analysis
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 29
    • Issues 29
    • List
    • Boards
    • Service Desk
    • Milestones
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Anti-censorship
  • censorship-analysis
  • Issues
  • #30872
Closed
Open
Issue created Jun 12, 2019 by Philipp Winter@phw

Test BridgeDB's distribution channels in controlled experiment

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.

Assignee
Assign to
Time tracking