Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
rdsys
rdsys
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 16
    • Issues 16
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Package Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

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.

  • The Tor Project
  • Anti-censorship
  • rdsysrdsys
  • Issues
  • #36

Closed
Open
Opened Jan 22, 2021 by Philipp Winter@phwMaintainer

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:

  1. 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.

  2. 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.

  3. 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.
Assignee
Assign to
Sponsor 30 - Objective 2.3
Milestone
Sponsor 30 - Objective 2.3
Assign milestone
Time tracking
None
Due date
None
Reference: tpo/anti-censorship/rdsys#36