[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:           
Component:  Pluggable transport  |        Version:           
 Keywords:  MikePerry201203      |         Parent:  #5010    
   Points:                       |   Actualpoints:           
---------------------------------+------------------------------------------

Comment(by mikeperry):

 Ok, I've thought about this, and I propose we create two IPC channels.

 IPC 1: BridgeFinder manages its own IPC over a separate control
 port/socket that is totally independent of tor. This is where it receives
 its strings. This IPC channel should be simple, unauthenticated, robust to
 arbitrary input, and available at a predictable endpoint. All it does is
 listen for BridgeFinder's magic strings to get dumped into it.

 IPC 2: BridgeFinder and Vidalia (and maybe TorButton) would all subscribe
 to a separate IPC channel created through Tor's actual control port. The
 new control port command "POSTMESSAGE" would add arbitrary quoted messages
 onto a queue destined for all other controllers, to allow general
 controller coordination.  Other controllers would have the option of doing
 "SETEVENTS POSTMESSAGE" to get these messages in real time, or of
 retrieving individual messages from their queue via "GETMESSAGE". We could
 re-use such a communications channel for all sorts of stuff, but we'll use
 it in this case for prompting the user if we really want to accept the
 BridgeFinder bridges.


 Here's a quick usage story of how the web-scraping usage interaction
 should work for TBB and OrBot with these two IPC channels:

 User starts TBB/OrBot. TBB/OrBot launches BridgeFinder, which starts
 listening on its string port.

 If Vidalia/Orbot want to provide the user confirmation before adding
 BridgeFinder bridges and if the current Tor client supports POSTMESSAGE,
 during BridgeFinder startup the negotiation would look like:

 Vidalia/OrBot: POSTMESSAGE @all "Plz POSTMESSAGE ur Bridge lines kthx"
 BridgeFinder: POSTMESSAGE @all "OK"
 Vidalia/Orbot: POSTMESSAGE @all "OKOK"

 If BridgeFinder successfully receives the "OKOK" message back from
 Vidalia/Orbot, BridgeFinder should from then on send bridge-adding control
 port commands wrapped in POSTMESSAGEs. If BridgeFinder does not see said
 POSTMESSAGE request from Vidalia/Orbot, or if POSTMESSAGE support is not
 supported by the Tor client, it should send its control port commands
 directly.

 To continue on with the usage story, the user then chooses from one of N
 ways to get bridgefinder strings. Let's examine the Web Scraping one.

 The user uses their normal web browser with the BridgeFinderHelper addon
 installed. When BridgeFinderHelper sees a magic string, it posts it to
 BridgeFinder's simple IPC channel. BridgeFinder does its magic, extracts
 the bridges/pluggable transport lines, and either SETCONFS them to Tor, or
 wraps them in POSTMESSAGE for Vidalia/Orbot to confirm.

 This design should keep BridgeFinder's helper apps/scrapers from needing
 undue access to Tor's control port. It should also give us the
 confirmation prompting n8fr8 wants. It is also incrementally deployable.
 We don't need to get the POSTMESSAGE confirmation box thing working right
 away, nor do all controllers need to support it. Once POSTMESSAGE is
 deployed, I bet we'll find it useful for solving all sorts of multi-
 controller coordination problems. Finally, the dumb IPC for BridgeFinder
 allows quick rollout of multiple ways of getting bridge strings into
 BridgeFinder. Vidalia/Orbot can even send them directly to the
 BridgeFinder port from a paste, if need be (or we could create a
 POSTMESSAGE way of doing it, too, but that would be redundant).


 So how does it sound? Does it minimize overall development effort?

 n8fr8: does it sound like this would work with Intents?

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