[tor-bugs] #3203 [Pluggable transport]: obfsproxy will probably need a GUI on Windows

[Tor Bug Tracker & Wiki]

#3203: obfsproxy will probably need a GUI on Windows
---------------------------------+------------------------------------------
 Reporter:  asn                  |          Owner:  asn     
     Type:  defect               |         Status:  assigned
 Priority:  normal               |      Milestone:          
Component:  Pluggable transport  |        Version:          
 Keywords:                       |         Parent:          
   Points:                       |   Actualpoints:          
---------------------------------+------------------------------------------
Changes (by asn):

  * status:  new => assigned


Comment:

 Hi! Thanks for the replies!

 I quite like the idea of doing this with Vidalia.

 What we will need, as I see it:
 * We will need a way for the user to configure stuff about the
 to-be-launched obfsproxy instance, like:
  * whether we are server/client.
  * the pluggable transports protocol to be used.
  * the port.
  * a pre-shared secret/password.
 * After launching the obfsproxy we will need a minimal panel saying
 "Okay, obfsproxy was launched neatly. It seems to work" or notifying
 the user of launching errors like "Ugh! The port was taken!".  Maybe
 even have it to show the stdout/stderr of obfsproxy for easier
 debugging.

 The original ETA of this - looking at my application - was "June 17th
 - July 1st".

 Replying to [comment:3 chiiph]:
 > I don't know what's the ETA for this GUI. But if the idea is to have
 this inside Vidalia there are two possibilities IMO:
 >
 > 1) Code this inside Vidalia (just like it is for apps launched by TBB).
 I don't like this idea since I'm working towards taking out these parts of
 Vidalia, but it may be the quickest path.
 >

 Hm, okay. Let's pretend we are clean for now and reject this one.

 > 2) Make a plugin for this. If the idea is to just fork another process
 with obfsproxy, and have a couple of buttons and simple lineedits for
 config, this won't be a problem as a plugin. The only thing is that I'm
 planning on putting the design behind the plugin framework for review this
 week, and from there to a usable stage, it might take a while (a month may
 be?).
 >

 Hm, alright. I'm most probably gonna start with this in at least 3
 weeks from now. Do you think I could use your plugin framework for
 this?
 How hard do you think it will be? GUIs terrify me!

 > OTOH, if the idea is to hack a separate GUI, sure, Qt behaves pretty
 good for rapid application development.
 >

 Replying to [comment:4 rransom]:
 >  Tcl/Tk seems less bad than I thought it was last month.

 I think I'm quite sure I want to do this in Vidalia. It's reusable,
 readymade, part of the TBB and it seems to me the correct™ way of
 doing it.

 Replying to [comment:1 arma]:
 > (Maybe it turns out that it's easier to launch managed proxies than to
 > launch external proxies, if they need configuration by non-technical
 > users.)

 Well, we knew this. The problem is that managed proxies have a huge
 specification and imo it would be better to make something semi-usable
 that we can ship to some people and get actual feedback on the whole
 pluggable transports idea, before spending time to implement that
 spec.
 Also, note, that the managed proxies spec is one of the two branches
 in the end of my GSoC timetable.

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