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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 isis):

 Replying to [comment:13 sysrqb]:
 > It might almost be better to create a file of unreachable/non-listening
 bridges. As far as I can think (right this second), with the current
 script, BridgeDB would have to parse this file occasionally (on some sort
 of schedule), determine which of the bridges are currently in a ring, add
 any bridges as unallocated if they are new, compute the non-intersecting
 set of bridges it currently has in its rings that that were not in the
 file (could not be reached) and remove them - that last step being fairly
 expensive.
 >

 As far as I know, BridgeDB currently does this, if you look here:
 https://gitweb.torproject.org/bridgedb.git/blob/HEAD:/lib/bridgedb/Bucket.py#l220

 Though, I do not know where it is determining these bridges. (or if it is
 able to)

 Replying to [comment:15 asn]:
 >  Replying to 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.

 hellais' version of bridget.py should be suitable for running ''from''
 BridgeDB. A distinction was not made in much of the discussion for #6414,
 and determining if a given bridge is blocked from a ''specific'' country
 is much more difficult than determining if it the host is online or not
 from BridgeDB. From BridgeDB, if we take as an assumption that BridgeDB is
 not under surveillance, is is simple to test if the bridge is up. hellais'
 script will do that, though when I tested it, it did not run at that
 commit -- I do not recall if this was an error in ooni-probe, perhaps due
 to all the recent changes for director.py, or if it was an error in
 bridget.py.

 Note, FWIW, my apprehension over merging hellais' script as "bridget" is
 largely due to the above confusion, as running it from a given country
 ''might'' tell you if the bridge is blocked from your country -- though it
 would likely get the bridge blocked if it was not already. Hence, putting
 it into ooni-probe labelled as a "bridge reachability test" would be an
 extreme misnomer, as it would function more as a "bridge blocker" in
 censoring countries.

 I would suggest that a non-ooni version of hellais' script go into
 BridgeDB instead of going into ooni-probe, as it would fit this function
 precisely. Some minor amount of work would need to be done to add in the
 bits of Twisted which are covered by ooni-probe, so that hellais' bridget
 would work standalone.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6396#comment:16>
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