Changes between Initial Version and Version 1 of Ticket #30006


Ignore:
Timestamp:
Apr 3, 2019, 7:23:59 PM (3 months ago)
Author:
phw
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #30006 – Description

    initial v1  
    11Tor Browser ships with several dozen [https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/tor-browser/Bundle-Data/PTConfigs/bridge_prefs.js default bridges]. We currently have no automated way of learning when one of these bridges disappear, e.g., because the owner cannot afford her VPS bill anymore.  If this happens, Tor Browser would then ship with dead bridges, which don't help anyone. [https://trac.torproject.org/projects/tor/ticket/29378 This has happened before]. Also, note that this ticket is ''not'' about measuring censorship.
    22
    3 We should find out when any of our default bridges disappear.  A simple way to do so would be to test its TCP reachability, i.e., see if it's possible to establish a TCP handshake with its bridge port. Ideally, we want a test like: "ping the bridge ''n'' times per week and mark it as "alive" if it responded to at least ''n - m'' SYN segments."
     3We should find out when any of our default bridges disappear.  A simple way to do so would be to test its TCP reachability, i.e., see if it's possible to establish a TCP handshake with its bridge port. Ideally, we want a test like: "ping the bridge ''n'' times per week and mark it as "alive" if it responded to at least ''n - m'' SYN segments." We should also think about how to sync a list of default bridges to test with the actual list of default bridges in Tor Browser, so we are testing what needs testing.
    44
    55Prometheus may be able to help here, and has an exporter that can measure a machine's TCP reachability. Here's what anarcat found: