Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #30872

Closed (moved)
Open
Opened 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.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#30872