[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #30006 [Applications/Quality Assurance and Testing]: Monitor "aliveness" of default bridges in Tor Browser

#30006: Monitor "aliveness" of default bridges in Tor Browser
-------------------------------------------------+-------------------------
 Reporter:  phw                                  |          Owner:  phw
     Type:  defect                               |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:
Component:  Applications/Quality Assurance and   |        Version:
  Testing                                        |
 Severity:  Normal                               |     Resolution:
 Keywords:  default bridge                       |  Actual Points:
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Description changed by phw:

Old description:

> Tor 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.
>
> 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."
>
> Prometheus may be able to help here, and has an exporter that can measure
> a machine's TCP reachability. Here's what anarcat found:
>
> {{{
> $ curl
> 'http://localhost:9115/probe?target=google.com:80&module=tcp_connect'
> # HELP probe_dns_lookup_time_seconds Returns the time taken for probe dns
> lookup in seconds
> # TYPE probe_dns_lookup_time_seconds gauge
> probe_dns_lookup_time_seconds 0.046783699
> # HELP probe_duration_seconds Returns how long the probe took to complete
> in seconds
> # TYPE probe_duration_seconds gauge
> probe_duration_seconds 0.060479041
> # HELP probe_failed_due_to_regex Indicates if probe failed due to regex
> # TYPE probe_failed_due_to_regex gauge
> probe_failed_due_to_regex 0
> # HELP probe_ip_protocol Specifies whether probe ip protocol is IP4 or
> IP6
> # TYPE probe_ip_protocol gauge
> probe_ip_protocol 6
> # HELP probe_success Displays whether or not the probe was a success
> # TYPE probe_success gauge
> probe_success 1
> }}}

New description:

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

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

 Prometheus may be able to help here, and has an exporter that can measure
 a machine's TCP reachability. Here's what anarcat found:

 {{{
 $ curl
 'http://localhost:9115/probe?target=google.com:80&module=tcp_connect'
 # HELP probe_dns_lookup_time_seconds Returns the time taken for probe dns
 lookup in seconds
 # TYPE probe_dns_lookup_time_seconds gauge
 probe_dns_lookup_time_seconds 0.046783699
 # HELP probe_duration_seconds Returns how long the probe took to complete
 in seconds
 # TYPE probe_duration_seconds gauge
 probe_duration_seconds 0.060479041
 # HELP probe_failed_due_to_regex Indicates if probe failed due to regex
 # TYPE probe_failed_due_to_regex gauge
 probe_failed_due_to_regex 0
 # HELP probe_ip_protocol Specifies whether probe ip protocol is IP4 or IP6
 # TYPE probe_ip_protocol gauge
 probe_ip_protocol 6
 # HELP probe_success Displays whether or not the probe was a success
 # TYPE probe_success gauge
 probe_success 1
 }}}

--

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs