Hi there ,
i am currently working on this ticket and got some questions.
How much control do you want on those options ?

new circuit (do we want to build custom circuits , extend circuits and so on or just create some ?) (either way already done)
see Tor status (connected, problem, etc.) (isnt this handled by arm?)
First Time Connection Wizard (Why do we need this when we already got whonixcheck etc ?)
view Tor logs (working on that)
restart Tor (done)
run TimeSync (is this still needed ?)
newnym (done)
get notified about events from Whonix-Gateway (working on that)

do we want to aim this tool for advanced and novice users ?

the Cli part is almost done , so please stop me if some of this is not needed anymore

In T90#6754, @goldstein wrote:

i am currently working on this ticket and got some questions.

How much control do you want on those options ?

new circuit (do we want to build custom circuits , extend circuits and so on or just create some ?) (either way already done)

Just signal newnym. No custom circuits. No extend circuits. Easy.

see Tor status (connected, problem, etc.) (isnt this handled by arm?)

arm causes loads of confusion. (https://www.whonix.org/wiki/Tor_Controller#Arm_FAQ)

First Time Connection Wizard (Why do we need this when we already got whonixcheck etc ?)

Right. whonix-setup-wizard does this already. So we don't need this in Whonix Tor Controller. This ticket is already very old and has not been updated since.

view Tor logs (working on that)

Useful.

run TimeSync (is this still needed ?)

No. We get sdwdate-gui (tray icon).

get notified about events from Whonix-Gateway (working on that)

do we want to aim this tool for advanced and novice users ?

novice users.

the Cli part is almost done , so please stop me if some of this is not needed anymore

Good question. @bnvk is an UI designer. I don't know if he is ready yet to suggest what will be useful and how.

I am also wondering now if it should become a "Whonix Tor Controller" or general "Tor Controller".

A lot has changed since this ticket has been created. So I disagree with "not to implement the functions already being done by arm".

Whonix-Gateway

• setting up (private) (obfuscated) bridges

Seems difficult. Maintenance intensive. Not sure if you would be up to maintain this?

The real long term plan for the time being was:
https://phabricator.whonix.org/T118

• setting up flash bridges

Even more difficult.

• torify Windows (textual feature)
• torify Other Operating System (textual feature)

Differers per per supported platform. Doable.

Whonix-Workstation

• check if Whoinx-Gateway is reachable
• advise to start on Whonix-Gateway, in case it's not running

Perhaps useful alternative diagnosis tool as alternative to whonixcheck. Not really sure we need this since it's probably hard to provide better advice than whonixcheck.

• check Tor status on Whonix-Gateway
• get notified about events from Whonix-Gateway

Not good.

• newnym

Hm.

All in all, this ticket is a disaster. Not actionable. We need an updated proposal on what we're trying to accomplish without stretching it too much. For example if we want a Tor Controller, we should leave Whonix-Workstation out.

I hope you're not deterred by that @goldstein.

Is there anyway we can chat ? (got some more questions)

Im currently rewriting the whole thing as im still learning the stem api so its no big deal to implement/remove stuff
I just need some pointers where the whole thing needs to go or if theres even a need for something like this

setting up (private) (obfuscated) bridges
Seems difficult. Maintenance intensive. Not sure if you would be up to maintain this?

looking into it , but i doubt this could be useful for novice users (but i like it)

Perhaps useful alternative diagnosis tool as alternative to whonixcheck. Not really sure we need this since it's probably hard to provide better advice than whonixcheck.

I need to check the whonixcheck source but theres some useful stuff stem could provide there

setting up flash bridges
Even more difficult.

looking into it

arm causes loads of confusion. (https://www.whonix.org/wiki/Tor_Controller#Arm_FAQ)

i see, found some good to have features for arm : https://trac.torproject.org/projects/tor/wiki/doc/arm#ClientModeUseCases
This is the purpose why i started developing this tool , arm kinda sucks for novice users

I am also wondering now if it should become a "Whonix Tor Controller" or general "Tor Controller".

Whonix Tor Controller would be better i think.

I hope you're not deterred by that @goldstein.

nah, im glad to help

Just back from the Tor summer dev meeting. Idea T118 has been abandoned. (T118#6811) Pluggable transports will not change that often.

Therefore, now there is some useful work to do. Implementing a Tor Bridge (circumvention) wizard.

Do you know tor-launcher (screenshots)? Could you look at the latest version that comes with TBB please? And then copy/re-implement its GUI design? I.e. work on whonix-setup-wizard?

(No Tor Project logo. Initially, only obfs3 and obfs4 bridge support. Later, once meek has been packaged, also meek.)

Implementing a Tor Bridge (circumvention) wizard.

to add Bridges to the torrc or to setup a bridge ?

Do you know tor-launcher (screenshots)?

yes

Could you look at the latest version that comes with TBB please? And then copy/re-implement its GUI design?

going to look at it , what do you mean by re-implement / copy its design ?

I.e. work on whonix-setup-wizard?

you want to add the bridge feature to whonix-setup-wizard and to look like the tor-launcher (im kinda confused here)

(No Tor Project logo. Initially, only obfs3 and obfs4 bridge support. Later, once meek has been packaged, also meek.)

k

In T90#6816, @goldstein wrote:

Implementing a Tor Bridge (circumvention) wizard.

to add Bridges to the torrc or to setup a bridge ?

A setup wizard (similar to tor-launcher) adding a bridge to torrc.

what do you mean by re-implement / copy its design ?

By design I meant here, how tor-launcher GUI is looking. How its windows are looking. The UX, user experience. Using the same or very similar textual strings.

Using tor-launcher's style and then improving whonix-setup-wizard doing this.

you want to add the bridge feature to whonix-setup-wizard and to look like the tor-launcher

Yes.

(At the moment, whonix-setup-wizard bridges feature is only a textual help. Cannot actually add/remove something to/from torrc.) (Back then, the bridge feature seemed daunting and a T118 seemed to be the way to go. But now it got clear, that a T118 is no option and that re-implementing the bridge wizard is the way forward to improve bridge/circumvention usability.)

Using tor-launcher's style and then improving whonix-setup-wizard doing this

K, going to work on that

Should I create a new Issue for that ?

I still think a Whonix-Tor-Controller would be nice to manage all tor/whonix related stuff in one place

The bridge options were tested (obs2, obfs3 and scramblesuit at the time, if I remember correctly) when we had the discussion about including them or not in whonix-setup-wizard, and decided to go for T118.

It would be a matter of retesting first, then enabling the option "Tor is censored in my area" and add a page to the wizard that could look like the one in tor-launcher, including the custom brige option (if it's judged necessary).

A note about T118. Been on and off on that one. It looks like tor-launcher is merely settings variables, and that the actual work (like editing torrc or starting meek-client) is done downstream, in firefox or wherever. So I'm not sure it's even possible achieve the bridges settings that way, without starting Tor browser.

A note about T118. Been on and off on that one. It looks like tor-launcher is merely settings variables, and that the actual work (like editing torrc or starting meek-client) is done downstream, in firefox or wherever. So I'm not sure it's even possible achieve the bridges settings that way, without starting Tor browser.

I took a brief look at tor-launcher and think your right

It would be a matter of retesting first, then enabling the option "Tor is censored in my area" and add a page to the wizard that could look like the one in tor-launcher, including the custom brige option (if it's judged necessary).

I think thats the best option (want to go for that ? )

In T90#6837, @troubadour wrote:

A note about T118. Been on and off on that one. It looks like tor-launcher is merely settings variables, and that the actual work (like editing torrc or starting meek-client) is done downstream, in firefox or wherever. So I'm not sure it's even possible achieve the bridges settings that way, without starting Tor browser.

Copied here:
T118#6841

I think thats the best option (want to go for that ? )

Yes.

I think we should replace the current connection wizard page with the text by tor-launcher as much as possible. Because they did actual usability testing.

Combine the option "Tor is censored or dangerous in my area" with option "I use a proxy or firewall settings to connect to the internet". Use the same text that tor-launcher uses.

I am not sure if we should keep the "disable Tor" option?

History: I guess it's only 4 options, because whonix-setup-wizard (graphical desktop gui) originally was a rewrite of whonixsetup (cli gui, not very appropriate for a graphical desktop). I didn't know better. Tools were limited. Not sure tor-launcher already existed [in Tor Browser stable].

I am not sure if we should keep the "disable Tor" option?

I dont think the user would want/need that (why would you disable Tor when you have just started the Whonix VM to Route your traffic trough tor ?)

I'm at the moment busy with another Project , I can maybe work on this at the Weekend . Its gonna take some time untill i can work on this.

Alright.

why would you disable Tor when you have just started the Whonix VM to Route your traffic trough tor ?

A reason I could see is if you want to travel somewhere. Switch from
public Tor network to bridges. Or a different set of bridges. Or vice versa.

Probably a minority and insufficient reason to add the extra option that
makes it more difficult for most users.

So unless someone has an argument why we should keep it, let's remove
the disable Tor feature.

Please keep the Disable Tor option. Its a minority use case but very important IMO for high risk users who need to avoid guard fingerprinting.

It shouldn't be that confusing to anyone

Its a minority use case but very important IMO for high risk users who need to avoid guard fingerprinting.

Maybe a "advanced settings" checkbox at the first page that enables the disable Tor option . This would come handy when we want to implement more stuff like Hidden Service Auth , or custom Guard / Circuit selection
@HulaHoop
How does that sound to you ?

Yes, let's keep the default that most (first time) (linux) users see to the minimum. And all the advanced stuff can be burred under an "advanced settings" button. Does that sound cool? @bnvk

@goldstein Sounds great. Can't wait to see what you are working on :)

Related: tor-monitor - T422

Started Tor Launcher clone interface.

I'm not sure where the disclaimer pages fit in that scheme. They are not used in Qubes, do we want to keep them for VirtualBox / KVM?

troubadour (troubadour):

I'm not sure where the disclaimer pages fit in that scheme.

They don't.

They are not used in Qubes, do we have to keep them for VirtualBox / KVM?

They're real awful, but we need to keep them for VirtualBox / KVM as
long no one else builds and redistributes these images.

the first page (Connect or Configure) should be a separate GUI

It can be in the wizard, and it seems a logical place where to put the Disable Tor option.

Do we want the Whonix logo in the wizard? I guess no.

No. Keeping it super simple.

I am also wondering if we need the disable Tor option. For this minority use case, wouldn't it make more sense if users disabled the (virtual) network interface then?

Perhaps Whonix Setup Wizard -> Whonix Connection Wizard?

I am also wondering if we need the disable Tor option. For this minority use case, wouldn't it make more sense if users disabled the (virtual) network interface then?

Will remove it, unless someone has a strong advice against it.

Perhaps Whonix Setup Wizard -> Whonix Connection Wizard?

Yes, but we still have the disclaimer pages and the repository wizard. I'll be able to create a new branch soon enough. Or perhaps a new package "Whonix Connection Wizard" and a separate "Whonix Repository Wizard" package?

Will remove it, unless someone has a strong advice against it.

Please leave it in. Its useful to have and doesn't clutter up the wizard ui.

troubadour (troubadour):

Perhaps Whonix Setup Wizard -> Whonix Connection Wizard?

Yes, but we still have the disclaimer pages and the repository
wizard. I'll be able to create a new branch soon enough. Or perhaps a
new package "Whonix Connection Wizard" and a separate "Whonix
Repository Wizard" package?

I was only referring to the window title.

We can have all these GUI in the same package.

OK.

For the Disable Tor option, implementing the "Advanced" button may satisfy everyone.

Looks good.

Created a new branch tor-launcher-clone. It's for review only, showing the new pages.

Progress update.

The default bridges are implemented. When the wizard restarts tor, it shows the bootstrap progress in a progress bar.

The default bridges file is in /etc/bridges for not finding a better place. It's in json format, so it could be difficult to have a proper .d configuration mechanism. That should not be a big issue since the choice for custom bridges will be given.

The AppArmor denied message popping when using scramblesuit has gone after disabling and re-enabling the obfsproxy profile. Will look into that.

troubadour (troubadour):

The default bridges file is in /etc/bridges for not finding a
better place. It's in json format, so it could be difficult to have a
proper .d configuration mechanism. That should not be a big issue
since the choice for custom bridges will be given.

I guess introducing /etc/bridges would lead to confusion.
/usr/share/whonix-setup-wizard/bridges_default or something like this
seems better. A .d configuration mechanism isn't required. Users are
either using the default bridges (let's see if we can find someone
interested to host others than TBB ones) or their own ones. No need to
have a .d mechanism to extend the default ones.

In T90#7030, @troubadour wrote:

Created a new branch tor-launcher-clone. It's for review only, showing the new pages.

• Can https://github.com/troubadoour/whonix-setup-wizard/blob/tor-launcher-clone/etc/apparmor.d/local/usr.bin.obfsproxy be moved to https://github.com/Whonix/anon-gw-anonymizer-config/tree/master/etc/apparmor.d/local please?
• What is...

shutil.copy('/etc/tor/torrc', '/etc/tor/torrc.orig')
shutil.copy('/etc/tor/torrc.anondist', '/etc/tor/torrc')

For? I don't understand why we should use the anondist file for anything. It should just be a symlink.

• When rerenning kdesudo whonix-setup-wizard setup (or quick) I just keep getting the finish screen. Not the connection setup again.

Pushed a batch of commits.

Could you review https://github.com/troubadoour/whonix-setup-wizard/commit/ca9e0f977dd6ca5d8fd5d556cfb159e49db21b10.

In tor 0.2.7.5, tor.service is a one shot service. When restarted, it returns immediately status 0, regardless of tor status. If used directly, we have to add a time.sleep in order to get the control port ready.

Using service tor@default instead.

Merged https://github.com/Whonix/anon-gw-anonymizer-config/commit/8ff911fcdc27ec9e34a08ed4efee70ef38411d3e also.

Using service tor@default instead.

Seems okay.

Could you review https://github.com/troubadoour/whonix-setup-wizard/commit/ca9e0f977dd6ca5d8fd5d556cfb159e49db21b10.

kdesudo whonix-setup-wizard quick works great. A totally missing DisableNetwork 0 in /etc/tor/torrc doesn't break it.

obfs3, obfs4, scramblesuit all working.

kdesudo whonix-setup-wizard quick -> Disable is broken.

It's great for debugging that we see the output of Tor service restarts when start from command line.

Please remove the grayed out transports. I guess the grayed out ones would generate more support requests than not showing them at all.

During the bootstrap phase, the back and next buttons don't work. The next button probably would not make sense either way. And the back button, I don't know if we need it. Would fixing the back button be difficult?

This is the ClientTransportPlugin that TBB adds when choosing obfs4.

ClientTransportPlugin obfs2,obfs3,obfs4,scramblesuit exec ./TorBrowser/Tor/PluggableTransports/obfs4proxy

To simplify the code a bit, I am wondering if when using bridges, if we should always add all ClientTransportPlugin lines that Whonix supports. I.e.

ClientTransportPlugin obfs2,obfs3,obfs4,scramblesuit exec /usr/bin/obfs4proxy

man obfs4proxy indicates this should work. However, it does not work for me, unless I remove ,scramblesuit.

Perhaps, in bridge mode, we could always add the following two options?

ClientTransportPlugin obfs2,obfs3,scramblesuit exec /usr/bin/obfsproxy managed
ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy managed

Perhaps that would make later user manual configurations easier? And always adding all ClientTransportPlugin in bridge mode would perhaps also simplify the code a bit?

Had some doubts about obfsproxy AppArmor lines working in system_tor profile. They don't.

Explanation [attempt, it's a nasty one]. The AppArmor denied messages generated by scramblesuit or obfs3 are one shot errors. For example, after /var/lib/tor/pt_state/scramblesuit has been read once , it seems that subsequent uses of scramblesuit don't check for it any longer. The extra lines can then be commented or removed without any effect.

It was working on your system (like mine) most likely because you tested earlier with the local/usr.bin.obfsproxy profile.

The messages did show up after a fresh whonix-gw / sys-whonix installation (wanted to remove obfsproxy package, but it would remove whonix-gateway too).

Created usr.bin.obfsproxy.anondist
https://github.com/troubadoour/anon-gw-anonymizer-config/commit/4f1c421ef23b08d7fdb52f3cb3787b93d2dd3e1f

(wanted to remove obfsproxy package, but it would remove whonix-gateway too).

Could have used apt-get install --reinstall...

In T90#7352, @troubadour wrote:

(wanted to remove obfsproxy package, but it would remove whonix-gateway too).

Could have used apt-get install --reinstall...

Unfortunately, removing such packages is currently difficult. The technical background and workarounds are documented here:
https://www.whonix.org/wiki/Whonix_Debian_Packages

In T90#7353, @Patrick wrote:

In T90#7352, @troubadour wrote:

(wanted to remove obfsproxy package, but it would remove whonix-gateway too).

Could have used apt-get install --reinstall...

Unfortunately, removing such packages is currently difficult. The technical background and workarounds are documented here:
https://www.whonix.org/wiki/Whonix_Debian_Packages

Alternatively you could modify the anon-gateway-packages-recommended package. Remove obfsproxy from its dependencies. Then rebuild anon-meta-packages usual the usual make deb-pkg. Use dpkg -i to install the newly build anon-gateway-packages-recommended deb. Then the dependency would be gone and you could uninstall the obfsproxy package.

In T90#7351, @troubadour wrote:

Created usr.bin.obfsproxy.anondist
https://github.com/troubadoour/anon-gw-anonymizer-config/commit/4f1c421ef23b08d7fdb52f3cb3787b93d2dd3e1f

Merged.

In T90#7349, @Patrick wrote:

During the bootstrap phase, the back and next buttons don't work. The next button probably would not make sense either way. And the back button, I don't know if we need it. Would fixing the back button be difficult?

Made the back button as well as a cancel button available even during the bootstrap phase. For this, a bootstrapping thread is running beside the qt loop. And that brings me to a point I wanted to raise for some time.

We cannot afford a sys.exit(0) in the middle of a secondary thread. Which means that the wizard would be the same for VirtuaBox/KVM and Qubes (an improvement maintenance-wise) starting with a Next button, ending with a Finish button.

At this stage, adding the proposed code to the existing whonix-setup-wizard is getting difficult. This piece of software is already overly complicated in my opinion (not mentioning someone else, I can project myself a few years forward, if for any reason I have to find my way in that maze).

That's why I suggest to split the wizard in two pieces [packages] at least.

• whonix-connection-wizard: a clone of Tor Launcher, in Whonix Gateway/whonix-gw.
• whonix-setup-wizard: locale settings, disclaimer, whonix-repository, first use notice, in both gateway and workstation.

It would imply a re-work of the initializer, autostart, status files... Doable.

Created a temporary package whonix-connection-wizard. It installs the files in /usr/share/whonix-connection-wizard. To run it

kdesudo python whonix_connection_wizard.py

from the directory.

https://github.com/troubadoour/whonix-connection-wizard

I am fine with the split. Sure, let's make the code simpler and maintainable.

Instead of whonix-connection-wizard, we can even make this even a generic package, anon-connection-wizard?

Yes, let's go for anon-connection-wizard.

Bug fix.
https://github.com/troubadoour/whonix-connection-wizard/commit/652c4edc51ed2c096846bbc73a1d71b737e6fa20

On the design... I've slightly updated:
https://www.whonix.org/wiki/Dev/whonixsetup

Don't take it as face value. And it may look more difficult than it is. A lot has already been sorted out.

Yes, and it will make the wizard simpler. There is some work in https://github.com/troubadoour/whonix-setup-wizard. The discussion is continued in https://forums.whonix.org/t/whonix-setup-wizard-graphical-technical-discussion/650/202

anon-connection-wizard is functional with the bridges, and the Disable Tor option is implemented.
https://github.com/troubadoour/anon-connection-wizard

Now, I'll have to digest https://www.whonix.org/pipermail/whonix-devel/2015-December/000467.html before I can reply. That may influence the development.

Some changes to come in Tor Launcher.
https://trac.torproject.org/projects/tor/ticket/11773#comment:5

There is a new warning page when trying to connect directly and a bridge/proxy configuration exists.

Will implement that, as well the new text.

Interesting!

Btw I don't think we should wait for TPO to finish revamping
tor-launcher. I wouldn't be surprised if they go back and forth changing
the interface design over the next few months. We can take it once it
stabilized. It's of course up to you. Just want to spare you from extra
work going back and forth together with them.

Yes, that sounds sensible. Remembering previous experience with TPO, it's probably better to wait and see what it will look like eventually. I'll try to finish the current version in Whonix with the architecture defined so far. We can redesign when Tor Launcher comes with new features. I'll use the new text though, aware that that will change too, but can be easily updated.

Sounds good!