[tor-bugs] #6396 [BridgeDB]: Reachability tests for obfuscated bridges

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Jun 22 11:08:20 UTC 2013


#6396: Reachability tests for obfuscated bridges
---------------------------+------------------------------------------------
 Reporter:  asn            |          Owner:       
     Type:  task           |         Status:  new  
 Priority:  major          |      Milestone:       
Component:  BridgeDB       |        Version:       
 Keywords:  pt tor-bridge  |         Parent:  #8615
   Points:                 |   Actualpoints:       
---------------------------+------------------------------------------------

Comment(by asn):

 Replying to [comment:14 sysrqb]:
 > (Not having looked at the current version of bridget: )
 >
 > 1) From which host do we want to run it? From the same host as BridgeDB?
 Can we assume, initially, that we're not extremely bothered by the fact
 that a few bridges may be blocked because we probe them and they are
 within a censoring zone?
 >

 Running the tests from BridgeDB seems easier to deploy. In the future, we
 might want to consider some kind of decentralized system (similar to
 #6414), but I wouldn't worry too much about this in the beginning.

 > 2) Are we only testing ORPort reachability or are we aiming to test all
 PTs that a bridge's extra-info line lists? If we're doing the former then
 there isn't much to do for this ticket, the latter if more interesting.
 >

 Yeah, we probably want to take the latter approach here. That's why we
 were thinking of using BridgeT.
 I think Arturo's latest BridgeDB branch is:
 https://github.com/hellais/ooni-probe/tree/feature/bridget

 > 3) If we choose the latter option in (2) and if some ports are reachable
 and others are not, do we not list it as running or just remove the
 transports for which their ports are not reachable? The second option
 sounds much more reasonable.
 >

 Yeah, going with the second behavior seems fine. If that ends up reporting
 too many broken bridges (for whatever reason), we can start doing the
 first behavior.

 > 4) If we track which bridges we distribute, can we use geoip stats to
 help determine a bridge's blocked status *and* its reachability?

 You mean by using the GeoIP stats of the bridge? Have you seen George
 Danezis' work on an automatic censorship-detection system?
 https://lists.torproject.org/pipermail/tor-dev/2011-September/002923.html
 https://lists.torproject.org/pipermail/tor-dev/2013-May/004802.html
 https://metrics.torproject.org/users.html?graph=direct-
 users&start=2013-03-20&end=2013-06-17&country=ir&events=on&dpi=72#direct-
 users

 Even though the system's results are not too bad, we probably shouldn't
 rely on an anomaly detection system too much, except if we greatly improve
 the model we use.

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


More information about the tor-bugs mailing list