[tor-bugs] #5011 [Pluggable transport]: Discuss possible designs for an external program that discovers bridge addresses to tell Tor about them

[Tor Bug Tracker & Wiki]

#5011: Discuss possible designs for an external program that discovers bridge
addresses to tell Tor about them
---------------------------------+------------------------------------------
 Reporter:  karsten              |          Owner:  mikeperry                
     Type:  task                 |         Status:  new                      
 Priority:  normal               |      Milestone:  Sponsor F: March 15, 2012
Component:  Pluggable transport  |        Version:                           
 Keywords:                       |         Parent:  #5010                    
   Points:                       |   Actualpoints:                           
---------------------------------+------------------------------------------
Changes (by arma):

 * cc: n8fr8 (added)


Comment:

 Here's a concrete example that needs to be solved. Let's make sure we can
 solve this one well before generalizing the problem too far.

 One of our partners is writing a program, probably in C, that takes in a
 string that's too long to type, and outputs some bridge addresses. Let's
 call it BridgeFinder. The user starts with the string in a web browser
 page. BridgeFinder will do its own network interactions to learn its
 answers (so it's doing more than just parsing the string into answers).

 So *something* needs to A) get that long string from the web browser to
 BridgeFinder, and B) get the bridge strings from BridgeFinder to Tor.

 Option 1 is to make a configuration page in Vidalia where the user can
 paste the string in. Then Vidalia launches BridgeFinder, parses its
 answers through some sort of IPC, adds the new bridges to its bridge
 resource list, and setconfs them to Tor.

 Option 2 is that Vidalia learns the long string, instructs Tor to launch
 BridgeFinder, and instructs Tor about the long string. Then Tor learns
 about the bridges through some sort of IPC, and Vidalia discovers them
 through controller events and syncs its view of what Tor is doing.

 Option 1 seems more intuitive, but it puts more load on the controllers,
 meaning ultimately more work since Orbot, Vidalia, etc etc each have to
 implement it. But in both of these cases the controller needs a way to
 learn the long string, and to give the long string to something, and to
 learn which bridges were found, so we're going to need controller support
 either way.

 Option 3 is that BridgeFinder learns to be a Tor controller (e.g. Vidalia
 passes it the credentials when it starts), and then it can setconf the
 bridges on its own. That doesn't seem worth it.

 Option 4 is that Torbutton launches BridgeFinder, and hands it the long
 string from the browser page. Either the user right-clicks on it, or heck,
 maybe Torbutton just automatically recognizes it, and knows to do a
 checksum on it to verify that it's correctly formed and turn it into a
 bridge address in the background. BridgeFinder either gets credentials
 from Torbutton and is a Tor controller in its own right, or it IPCs its
 answers back to Torbutton which setconfs them. That removes the klunky
 "figure out what to paste and how to paste it" step. The downsides are a)
 Torbutton needs to learn how to launch external apps, b) Vidalia still
 needs to learn how to notice when bridges get added, c) it ties us even
 closer to Torbutton and (for now) Firefox, in the sense that the data flow
 for Orbot users is going to be way different than for TBB users.

 Option 5 is a combination of Options 2 and 4: Torbutton recognizes the
 string and gets it to Vidalia, which launches BridgeFinder and handles its
 answers. Then other bundles like Orbot can do the 'option 2' side without
 needing to do the 'option 4' side. This also allows for incremental
 deployment and testing, since we can do option 2 first and bolt on option
 4 later.

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