[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5011 [Pluggable transport]: Discuss possible designs for an external program that discovers bridge addresses to tell Tor about them
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs