Opened 8 years ago

Closed 8 years ago

#3203 closed defect (fixed)

obfsproxy will probably need a GUI on Windows

Reported by: asn Owned by: asn
Priority: Medium Milestone:
Component: Archived/Obfsproxy Version:
Severity: Keywords:
Cc: nickm, rransom Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

So, looking at my GSoC proposal I see:

c) Play with TBB to allow it to launch external proxies, so that
non-technical Windows users can use external proxies.

that was quite easy to type, but now that I actually think of it it starts to seem quite painful.
The problem is that we will probably need a GUI that allows some minimal configuration and outputs the status to the Windows user.

I brought this issue up on IRC some weeks ago and rransom said that we will indeed probably need a GUI hack.

Thing is I don't know anything about 'Windows' or 'GUIs'. I don't even know the absolute basics behind GUI coding.

This trac ticket is for ideas and advices on the interface of obfsproxy on the Windows platform.
Is there a super-quick and "correct" way of doing that?

Don't forget that the "launch obfsproxy through TBB" operation is part of the 'quick-n-dirty' plan, so that we can ship obfsproxy to a few bridge users that can beta test it.
It's not the final release and it's not a clean way of using obfsproxy on Windows. Maybe the GUI doesn't have to be uber-clean either.

[cc:ing rransom and nickm.
nick if you want me to stop ccing you, do say.]

Child Tickets

Attachments (2)

mockup.jpg (12.9 KB) - added by asn 8 years ago.
gui mockup
obfs_gui.jpg (30.3 KB) - added by asn 8 years ago.
GUI

Download all attachments as: .zip

Change History (13)

comment:1 Changed 8 years ago by arma

I suggest you make friends with chiiph and see if you can get him to add what you need to Vidalia.

(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.)

comment:2 Changed 8 years ago by arma

Or ask him to help you do a quick-and-dirty qt gui. Ultimately, it sounds like you're going to have to decide between targetting non-technical people for your "first test deployment" or targetting people who know how to edit a text file. You'll learn a lot even if you just choose the latter.

Another piece of general (vague) advice: don't get too distracted with a proof of concept. Or at least, don't get too distracted with the components of your proof of concept that aren't reusable / adaptable for the later stages of your plans too.

comment:3 Changed 8 years ago by 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.

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?).

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

I'm not sure what exactly needs to be done, so I can't say how hard it will be to code. But you should decide what approach you are taking, and we can discuss this in more depth.

comment:4 Changed 8 years ago by rransom

Tcl/Tk seems less bad than I thought it was last month. Just make sure you put catch {rename send {}} in your script soon after package require Tk. (That line turns off a code-exec backdoor in Tk.)

comment:5 in reply to:  3 ; Changed 8 years ago by asn

Status: newassigned

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 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 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 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.

comment:6 in reply to:  5 ; Changed 8 years ago by chiiph

Replying to asn:

The original ETA of this - looking at my application - was "June 17th

  • July 1st".

Replying to chiiph:

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!

It shouldn't be really hard. But I guess it depends, if it terrifies you then you could say it's really hard :)

So, today I've pre-finished the structure to support plugins in Vidalia. It's not ready for comments yet though, but it should be by this weekend or so.
The idea for the API is to provide the exact same interface to widgets like Qt does in C++.
Since Qt is really big, I've got to prioritize certain parts, so what I could do is to think what you'd need according to what you wrote, and code that part first.
You'd have to have in mind that you'll be coding over something that hasn't been really really tested yet. If you are ok with that, then we should sync in terms of deadlines.

Otherwise, a standalone Qt app would be almost as straight forward (in terms of coding) as the plugin, so that shouldn't be a problem either.
You'd have to work with something like qmake, and stuff like that (which you wouldn't need as a plugin), and it won't be integrated with Vidalia. But you could do the plugin equivalent later on.

comment:7 in reply to:  6 Changed 8 years ago by asn

Replying to chiiph:

Replying to asn:

The original ETA of this - looking at my application - was "June 17th

  • July 1st".

Replying to chiiph:

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!

It shouldn't be really hard. But I guess it depends, if it terrifies you then you could say it's really hard :)

So, today I've pre-finished the structure to support plugins in Vidalia. It's not ready for comments yet though, but it should be by this weekend or so.
The idea for the API is to provide the exact same interface to widgets like Qt does in C++.
Since Qt is really big, I've got to prioritize certain parts, so what I could do is to think what you'd need according to what you wrote, and code that part first.
You'd have to have in mind that you'll be coding over something that hasn't been really really tested yet. If you are ok with that, then we should sync in terms of deadlines.

Hi!
I still think I prefer doing it with the experimental plugin API.
Since I'm gonna get my feet wet with Qt/C++ I might as well go the whole way and integrate it cleanly with Vidalia; it might also help the plugin API mature.

I can't predict my deadline with great precision, but I'll probably start coding for this somewhere around 17th of June and have the very first days of July as my deadline.

Otherwise, a standalone Qt app would be almost as straight forward (in terms of coding) as the plugin, so that shouldn't be a problem either.
You'd have to work with something like qmake, and stuff like that (which you wouldn't need as a plugin), and it won't be integrated with Vidalia. But you could do the plugin equivalent later on.

comment:8 Changed 8 years ago by asn

I made a sketchy mockup.
I'm thinking of a button in the central Vidalia menu saying "Set up a pluggable transport." which shows something like my mockup when clicked.
Of course, this is stupidly basic and I completely disregard essential improvements but I think it should fit our testing purposes.

Possible improvements:

  • Obviously, an obfsproxy monitor which shows whether it's up or down, active connections, etc.
  • "Shared secret:" picked up from file.
  • "Set up a pluggable transport" icon only available when the user is a bridge/client.
  • A way to select other transports instead of obfs2.

Changed 8 years ago by asn

Attachment: mockup.jpg added

gui mockup

comment:9 Changed 8 years ago by asn

Status: assignedneeds_review

Okay I have something ready on this front.

Check out: git://gitorious.org/obfs_gui/obfs_gui.git

I'll put this in needs_review.

Changed 8 years ago by asn

Attachment: obfs_gui.jpg added

GUI

comment:10 Changed 8 years ago by arma

Component: Pluggable transportObfsproxy

comment:11 Changed 8 years ago by asn

Resolution: fixed
Status: needs_reviewclosed

This is old and is probably not going to be used since we implemented managed mode.

Note: See TracTickets for help on using tickets.