Tor-launcher - Better Circumvention User Interface

Prerequisite knowledge:



[quote=“troubadour, post:447, topic:108”][quote author=Patrick link=topic=97.msg5328#msg5328 date=1415400889]
Working on at the moment.

Getting this.

Nov  7 22:51:47 host kernel: [ 2923.658653] type=1400 audit(1415400707.346:32): apparmor="DENIED" operation="rename_src" parent=1 profile="system_tor" name="/etc/tor/torrc" pid=12507 comm="tor" requested_mask="wd" denied_mask="wd" fsuid=106 ouid=0

What must I add to fix it? Trying like crazy…

  /etc/tor/torrc rwmixkl,
  /etc/tor/torrc.anondist rwmixkl,

Restarted Tor…

Doesn’t help.

Most likely, the problem does not come from system-tor profile. Could you check that tor-launcher (what did you install, by the way?) has not installed its own profile. There is a bug in Vidalia.[/quote]
TBB for Linux from The Tor Project does not ship its own AppArmor profile. Throughly searched for any signs of AppArmor. And it makes sense. Otherwise Micah Lee wouldn’t have developed AppArmor profiles for torbrowser-launcher.

I am very certain it’s causes by system_tor, because when I set in /etc/default/tor

# USE_AA_EXEC="yes" # default USE_AA_EXEC="no"

then the AppArmor denied messages vanished.

I downloaded TBB using tb-updater using these instructions:

Then started experimenting. Put a script named “a” (any name would work) into ~/tor-browser_en-US.

Credits go to Tails.
(Original source:


## This file is part of Whonix.
## Copyright (C) Amnesia <amnesia at boum dot org>
## Copyright (C) 2012 - 2014 Patrick Schleizer <>
## See the file COPYING for copying conditions.

## Original source from Tails:

set -x
set -e


#if echo "$@" | grep -qw -- --force-net-config; then

#. /etc/live/config.d/username.conf

# Get LANG
. /etc/default/locale

#until pgrep -u "${LIVE_USERNAME}" nm-applet >/dev/null ; do
#   sleep 5

export LANG
#export DISPLAY=':0.0'
#export XAUTHORITY="`echo /var/run/gdm3/auth-for-${LIVE_USERNAME}-*/database`"
#sudo -u ${LIVE_USERNAME} xhost +SI:localuser:user
#gksudo -u user /usr/bin/tor-launcher
#sudo -u ${LIVE_USERNAME} xhost -SI:localuser:user

# Save ~10 RAM (due to the tmpfs) by removing this unused file
#rm -f /usr/Data/Browser/*.default/places.sqlite

exit ${RET}

(Still need to pretty that up. IF we can go that route. Just an experiment for now.)

Got that message when running.


Looks like reboot was required. Stopping/starting Tor didn’t do.

Then I got another denied message.

type=1400 audit(1415567983.905:23): apparmor="DENIED" operation="rename_dest" parent=1 profile="system_tor" name="/etc/tor/torrc.orig.1" pid=18142 comm="tor" requested_mask="wc" denied_mask="wc" fsuid=106 ouid=0

Fixed by using /etc/apparmor.d/local/system_tor with.

  /etc/tor rwmixkl,
  /etc/tor/** rwmixkl,

Reboot required again. Why?

No more AppArmor issues after reboot.

After relaxing file permissions.

sudo chmod o+rw /etc/tor
sudo chmod o+rw /etc/tor/**

Using the above script, tor-launcher was able to manipulate /etc/tor/torrc.

It doesn’t work yet. And I don’t know it’s a sane idea yet. Discussion about that should probably go into a separate thread.

Good news, linostar might contribute a patch for tor-launcher to add this feature!

We need to start a discussion with upstream (TPO) about this first. Here is a draft. Please comment on it and/or rewrite.



= TLDR =

We would like to use TBB as "system Tor".

= Long =

== Why? ==

* Most, latest technology for censorship circumvention, i.e. pluggable transports such as meek, scamblesuite, fte, etc. will not be packaged for Debian anytime soon.
* Pluggable transports are due to their nature too dynamically evolving. There is a giant gap between availability of a pluggable transports and installability from stable distributions such as Debian.
* Vidalia has been deprecated. There is no nicely looking, maintained way to easily configure Tor and bridges anymore besides the tor-launcher add-on.
* TBB comes with the tor-launcher add-on, which is a well maintained GUI for configuration and troubleshooting of Tor and all sorts of the latest and greatest pluggable transports.
* TBB comes with recent versions of Tor.
* TBB is built reproducibly.

== Current Problem ==

At the moment, TBB is an integrated browser package. It does not integrate well for use with other applications, with the general system. Because,

* once you close the browser window, no other application can connect.
* it's not possible to just configure and start Tor without opening the browser window
* once Tor is configured, you cannot start Tor without running X server

== Related ==

It's still an open task how to "Make TIMB and TBB/PTTBB cooperate in a smarter way.":

Maybe we can think of something to solve both at once.

== Solution ==
This is one solution that might work. Not necessarily the ultimate one. A rough plan.

A combination of new start scripts + environment variables obeyed by tor-launcher.

* keep ~/tor-browser_en-US/start-tor-browser as is
* add other launcher scripts to the Browser (or so) sub directory to keep your main directory simple
* add ~/tor-browser_en-US/Browser/start-tor-only
* add ~/tor-browser_en-US/Browser/stop-tor-only
* add ~/tor-browser_en-US/Browser/configure-and-start-tor
* add ~/tor-browser_en-US/Browser/configure-tor-only (if that is possible)
* add ~/tor-browser_en-US/Browser/start-browser-only (connect to previously started Tor)

That should suffice making TBB usable as "system Tor".

What do you think?

= Feedback =
What do you think about this proposal in general?

Linostar and I have some other solutions involving xul launcher in mind. Maybe you have some other possible solution in mind?

Depending on how much, complex, difficult this task is, linostar might provide a patch to add this feature.
1 Like

Talked about this with linostar on IRC. We agreed on the modified draft.


A sub task:
add environment variable to hide TBB’s logo:

As a reminder, we can use obfs3 and scramblesuit just by editing /etc/tor/torrc. Perhaps a temporary implementation in the wizard would be better than nothing?

Hm. Good question. I don’t know. I am torn. If you want. We could always refer to it as an alternative. Have a separate menu entry just for it perhaps.

Although I really think if you would help us sorting out the hopefully robust and long term solution, i.e. tor-launcher, that would be a much better use of time.

Certainly, for a long term solution. Has anybody really started on it yet? Had a quick look, and… where to look first? tor-launcher - tor-launcher component of TBB (archived to GitLab: ? Somewhere else?

Yeah. That’s it basically. You can also do “live” edits within TBB source folder. I am going to write some instructions on how to do this now. To help you get started with debugging and stuff.

Clone link here tor-launcher - tor-launcher component of TBB (archived to GitLab: at the bottom:

Here it is:

tor-launcher already has some standalone support.



This is somewhat what Tails is/was doing.

/usr/bin/iceweasel -app /usr/share/tor-launcher-standalone/application.ini


Although apparently they do something quite different. Looks like they somehow limited tor-launcher to only support obfs3 and not meek and others. And their version of tor-launcher apparently uses system Tor instead of using the Tor that comes with the TBB folder as system Tor.


One way that won’t work. Would have been way too simple. :wink:

iceweasel --app /home/user/tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/extensions/
Error: App:Name not specified in

Tails design documentation mentioning tor-launcher:

Links to Tails implementation:


Linostar and I figured out some interesting stuff:
tor-launcher’s makefile contains a standalone target, i.e. “make standalone”:

Differences of “make standalone”:

  • creates a tarball instead of xpi (which is a zip)
  • adds application.ini


  • We might suggest to TPO to add the application.ini by default to tor-launcher. The file would be unnecessary for browser users, but useful for application.ini users. Doesn’t seem to affect normal TBB use. (Tested by me.)

  • We might suggest to TPO, to ship folders rather than shipping xpi’s. Example xpi:


Example folder:



This could be a way to proceed:

iceweasel --app /home/user/tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/extensions/

Getting an error for now.

Unable to start Tor.

The Tor executable is missing.

But that’s the part linostar might be able to help with.

To resolve this problem:

Unable to start Tor.

The Tor executable is missing.

we need to provide tor paths. Tor paths are part of TBB preference (which are not so clear to me yet) but they can also be set in tor-luncher preferences.

if you open this file:


what you see:

pref("extensions.torlauncher.loglevel", 4);  // 1=verbose, 2=debug, 3=info, 4=note, 5=warn
pref("extensions.torlauncher.logmethod", 1);  // 0=stdout, 1=errorconsole, 2=debuglog
pref("extensions.torlauncher.max_tor_log_entries", 1000);

pref("extensions.torlauncher.control_host", "");
pref("extensions.torlauncher.control_port", 9151);

pref("extensions.torlauncher.start_tor", true);
pref("extensions.torlauncher.prompt_at_startup", true);

// All path prefs. are relative to the firefox executable's directory
pref("extensions.torlauncher.tor_path", "");
pref("extensions.torlauncher.torrc_path", "");
pref("extensions.torlauncher.tordatadir_path", "");
pref("extensions.torlauncher.transportproxy_path", "");

// Recommended default bridge type (can be set per localized bundle).
// pref("extensions.torlauncher.default_bridge_recommended_type", "obfs3");

// Default bridges.
// pref("extensions.torlauncher.default_bridge.TYPE.1", "TYPE x.x.x.x:yy");
// pref("extensions.torlauncher.default_bridge.TYPE.2", "TYPE x.x.x.x:yy");

i know it’s bad practice but for test purposes if you fill ‘tor_path’, ‘torrc_path’, ‘tordatadir_path’ like this:

pref("extensions.torlauncher.tor_path", "/home/user/tor-browser_en-US/Browser/TorBrowser/Tor/tor");
pref("extensions.torlauncher.torrc_path", "/home/user/tor-browser_en-US/Browser/TorBrowser/Data/Tor/tor");
pref("extensions.torlauncher.tordatadir_path", "/home/user/tor-browser_en-US/Browser/TorBrowser/Data/Tor");

the tor path would be resolved and if you run it again (like how @Patrick said before):

iceweasel --app /home/user/tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/extensions/

it would run without error. yet it won’t completley work. it has no default-bridge.

the thing is it seems that TBB is overriding this preference file with some other options and values, for example some of option are in:


for example all default_bridges are defined in this file but eventually will override the tor-luncher preference file. if you copy this part of it:

// Default bridges.
pref("extensions.torlauncher.default_bridge.obfs3.1", "obfs3 A09D536DD1752D542E1FBB3C9CE4449D51298239");
pref("extensions.torlauncher.default_bridge.obfs3.2", "obfs3 AF9F66B7B04F8FF6F32D455F05135250A16543C9");
pref("extensions.torlauncher.default_bridge.obfs3.3", "obfs3 AF9F66B7B04F8FF6F32D455F05135250A16543C9");
pref("extensions.torlauncher.default_bridge.obfs3.4", "obfs3 1E05F577A0EC0213F971D81BF4D86A9E4E8229ED");
pref("extensions.torlauncher.default_bridge.obfs3.5", "obfs3 4C331FA9B3D1D6D8FB0D8FBBF0C259C360D97E6A");

pref("extensions.torlauncher.default_bridge.flashproxy.1", "flashproxy");
pref("extensions.torlauncher.default_bridge.flashproxy.2", "flashproxy");
pref("extensions.torlauncher.default_bridge.flashproxy.3", "flashproxy");
pref("extensions.torlauncher.default_bridge.flashproxy.4", "flashproxy");
pref("extensions.torlauncher.default_bridge.flashproxy.5", "flashproxy");

pref("extensions.torlauncher.default_bridge.fte.1", "fte B629B0B607C8AC9349B5646C24E9D242184F5B6E");
pref("extensions.torlauncher.default_bridge.fte.2", "fte 2BD466989944867075E872310EBAD65BC88C8AEF");
pref("extensions.torlauncher.default_bridge.fte.3", "fte 0E858AC201BF0F3FA3C462F64844CBFFC7297A42");
pref("extensions.torlauncher.default_bridge.fte.4", "fte 1E326AAFB3FCB515015250D8FCCC8E37F91A153B");
pref("extensions.torlauncher.default_bridge.fte.5", "fte FC562097E1951DCC41B7D7F324D88157119BB56D");
pref("extensions.torlauncher.default_bridge.fte.6", "fte A17A40775FBD2CA1184BF80BFC330A77ECF9D0E9");

pref("extensions.torlauncher.default_bridge.fte-ipv6.1", "fte [2001:49f0:d002:1::2]:80 B629B0B607C8AC9349B5646C24E9D242184F5B6E");
pref("extensions.torlauncher.default_bridge.fte-ipv6.2", "fte [2001:49f0:d00a:1::c]:80 2BD466989944867075E872310EBAD65BC88C8AEF");

pref("extensions.torlauncher.default_bridge.scramblesuit.1", "scramblesuit AA5A86C1490296EF4FACA946CC5A182FCD1C5B1E password=MD2VRP7WXAMSG7MKIGMHI4CB4BMSNO7T");
pref("extensions.torlauncher.default_bridge.scramblesuit.2", "scramblesuit A09D536DD1752D542E1FBB3C9CE4449D51298239 password=XTCXLG2JAMJKZW2POLBAOWOQETQSMASH");

pref("extensions.torlauncher.default_bridge.meek-google.1", "meek url=");
pref("extensions.torlauncher.default_bridge.meek-amazon.1", "meek url=");
pref("extensions.torlauncher.default_bridge.meek-azure.1", "meek url=");

(I don’t know if it’s the same for all of us or it differs, so fill free to check your machine setting too) and append it to tor-luncher preference file, and then run it again, it would contain the bridge config options too.

however, after all this, it’s not working smoothly yet (however i didn’t test it without bridge, because i can’t), it gives the following error:

Jan 12 16:01:22.000 [warn] Could not launch managed proxy executable at './TorBrowser/Tor/PluggableTransports/obfsproxy.bin' ('No such file or directory').

I checked torrc and it doesn’t seem to have any error, so i’m still working on it.

Thanks neo13, that will move us a big step further.


Small comment on the folder


Apparently is a .d style alike(?) folder.

(“.d style” concept explained for something else: Configuration Files - Kicksecure)

Unrelated: In next version of tb-updater / Whonix 10, we will be creating a file. (Whonix Forum)


My critical point here: for testing purposes we could try to just create a file




and populate it.

(I don’t know yet if those are processed in lexical order.)

Any updates?

Posted on tor-talk mailing list:

No more progress so far. This isn’t the most simple task. There is a political / upstream discussion part involved.

make TBB usable as "system Tor" (#14121) · Issues · Legacy / Trac · GitLab still hasn’t received any feedback.

[quote=“Patrick, post:17, topic:665”]Posted on tor-talk mailing list:[/quote]
TODO: The post needs to be improved. The initial confusion that the above post generated needs to be prevented. And then it should be reposted on tbb-dev

Both neo123 and linostar are inactive.

Someone needs to take the lead here, otherwise I don’t know if it ever gets implemented.

Some (may be) good news here.

In TBB 5.0a1, there is a new option in tor-launcher preferences ( extracted from TBB.

pref("extensions.torlauncher.prompt_at_startup", [boolean]);

The default (as per today) is set to true. It means that tor-launcher is started before tor browser and we have access to the buttons “Connect” and “Congigure”.

The pereference, like all the other in tor-launcher, can be overridden in [TBB-directory]/Browser/TorBrowser/Data/Browser/profile.default/preferences/extension-overrides.js. When set to false, it behaves as before (you have try and catch the “Open Settings” button before the browser is loaded).

Started to play with some settings (for torrc especially) without much progress, but at least we have a starting point.

In ⚓ T386 meek Pluggable Transport, @HulaHoop wrote:

* The problems discussed in can be solved even if the features requested are never developed. Running TBB Tor headlessly is possible thru using xvfb (pkg that tricks a gui application into thinking its connected to a X-server) and something like selenium.

GitHub - isislovecruft/tor-browser-selenium: Selenium-2.0 WebDriver classes for controlling a Tor Browser.

I don’t know. Likely by default when you run it through xvfb, not only the Tor Browser window will be hidden, but also the tor-launcher gui. TODO: research if it is possible to distinguish these two windows. Hide browser window, keep tor-launcher visible.

Even when we can run TBB headlessly and still take advanatge of torlauncher-gui I forsee problems that will make the entire idea a non-starter. We cannot redistribute TBB binaries.

On the gateway this is less problematic. Likely will not be an issue. Just now updated reasoning why:

They must be downloaded. Imagine users in censored areas where they can't connect with Tor how will they be able to fetch TBB when connections to TPO are censored? Downloading from alternative distribution channels using GetTor will leave all kinds of network fingerprints.
Therefore does not apply.
The only sane solution is for TPO to spin off torlauncher-gui into its own independent package along with all pluggable transports, all in their repo so we can redistribute them freely and generate builds that include them without problems.
Would be a very good solution, but I guess TPO is unlikely to go this route anytime soon.