Tor Browser (TBB) profile with custom about:config settings

One day in the future if we want to ship with zeronet and/or I2P they need to be readily useful without asking the user to go through and play with about:config settings.

The obvious way to get around the fingerprint-ability of allowing localhost access is to enable it only in a custom profile that the user runs at their discretion when needing this functionality.

Open question:

Is there a mechanism like TBB variables we ca use to readily set these custom options?

3 Likes

Then the question is how we’d set the environment variables. Globally
would be bad since then it would apply to all instances of TB. Perhaps
another starter. But one thing at a time.

HulaHoop:

Is there a mechanism like TBB variables we ca use to readily set these custom options?

I am not aware of any. Worthwhile to ask. Worthwhile feature request for
both Firefox and TBB.

2 Likes

Posted on tor dev mail list.

Meanwhile I did some research and answers our question

Following are 3 main files which are used by Firefox:

prefs.js
userChrome.css
userContent.css

All these 3 files are plain text files and are stored in your Firefox profile folder. You can edit them using any standard text editor like Notepad in Windows and gedit in Linux.

Now the question comes what is this Firefox profile folder and where is it stored? Firefox saves all your personalized settings in profile folder and you can find the folder in following location:

Location of Firefox Profile Folder:

~/.mozilla/firefox/xxxxxxxx.default/

More details on making and delelting firefox profiles from the command line

2 Likes

In the case of I2P only, privoxy may be needed to forward the .i2p TLD transparently. Other proxies like Freenet’s freesites are readily accessible from the console interface which is used to browse their networks.

https://wiki.archlinux.org/index.php/privoxy#i2p

https://www.privoxy.org/user-manual/quickstart.html
https://www.privoxy.org/user-manual/configuration.html

Changes/exceptions are defined in the user.action file which is Privoxy’s version of config.d

Multiple actions files may be defined in config. These are processed in the order they are defined. Local customizations and locally preferred exceptions to the default policies as defined in match-all.action (which you will most probably want to define sooner or later) are best applied in user.action, where you can preserve them across upgrades. The file isn’t installed by all installers, but you can easily create it yourself with a text editor.

No environment variables unless - maybe - if we submit patches. ([Feature Request] Environment Variable to set security slider level (#25391) ¡ Issues ¡ Legacy / Trac ¡ GitLab)


In times of Tor Browser SocksSocket, why do localhost connections still work anyhow? Hasn’t TCP been removed from Tor Browser yet so it can only talk to Tor socks unix domain socket file?


I was wondering if tb-updater should support multiple installation folders. Technically the easiest to have fully separate tor-browser folders (copies). But that would also duplicate, triple or quadruple the used disk space. And time to run tb-updater.

Using multiple user profiles within the same tor-browser folder seems better?


How many profiles are we going for?

  • localhost no + javascript
  • localhost no + no javascript
  • localhost yes + javascript
  • localhost yes + no javascript
  • more in future?

It’s a bit much?

Usability wise, the more, the more messy. That many desktop icons? That many start menu favorites? That many start menu entries?


Are we going to use Firefox profile manager?

I am worried about usability. Does Create Profile work or create a plain profile without Tor Browser settings? I wouldn’t be surprised about that at all.


Can the localhost setting be undone and the original Tor Browser fingerprint be restored? That would simplify some things.

Can multiple Tor Browser profiles be run at the same time?

Are multiple Tor Browser profiles run at the same time visually distinguishable?

Maybe we shouldn’t ship that many profiles? Maybe “just” two or only one? But develop a firefox (Tor Browser specific) profile generator and add it to the tb-starter package? A gui application wizard that runs at first start of Tor Browser and asks these questions?

Maybe just 1 Tor Browser starter, and the tb-starter first run wizard would only ask the javascript yes/no question and advice to use a separate VM if an both are desired at the same time?

And perhaps a separate Tor Browser starter start menu entry for local web interfaces

  • i2p
  • ZeroNet

Which would

  • enable localhost settings
  • then deactivate the normal Tor Browser starter, let it show something like “Tor Browser was configured for localhost connections which affects the web fingerprint.”
    • do not show this warning again
    • delete and recreate browser profile button
  • start daemon (i2p or ZeroNet)
  • open web interface url (i2p or ZeroNet)
1 Like

Hm. using 127.0.0.1 requires a TCP socket on a loopback device. I feel this is an unavoidable exception. The whole unix socket transition was concerning how it communicates with Tor and not generally AFAIK.

Yes probably. There is also precedent for running custom Firefox for a long time.

Lets forget about the no-JS idea. It would only have made sense as a safer default rather than an optional thing that will be ignored by users who don’t know what it is.

Probably just the one profile for localhost, for the forseeable future. Restricting JS would break many usecases like zeronet for instance.

One should be manageable?

No. It doesn’t work with Tor Browser on purpose and so we must go the multi TBB folder route as per:

This won’t work, given that Tor Browser ships with a specific default profile which it uses, and needs to use to operate properly, creating and utilising different profiles will cause issues.

Instead, have multiple installations of Tor Browser (each extracted to a distinct folder) which will provide superior isolation between identities and profiles for each.

See above

Yes its just a matter of enabling it with a “1”

Multi TBB’s should run at the same time

With this ruby script you should be able to arbitrarily change a window title on X

https://forum.kde.org/viewtopic.php?f=111&t=121428

1 custom profile, 2 TBB folders, no need to complicate tb-starter or ask questions. The shortcut links to the second TBB should have a self explanatory name.

I like it. With its own TBB folder though, the implementation is simpler as you won’t be asking them to delete anything but merely notifying them of the properties of the special profile. The whole auto-start/shutdown of daemons is pretty neat and essential for a smooth experience. Good ideas.

2 Likes

HulaHoop:

Hm. using 127.0.0.1 requires a TCP socket on a loopback device. I feel this is an unavoidable exception. The whole unix socket transition was concerning how it communicates with Tor and not generally AFAIK.

Ripping TCP out of Tor Browser for better leak protection is a general
plan by Tor Project. Could you please look up if they have a ticket for
that and/or ask if localhost connections will break in near/mid term
future anyhow since TCP is going to be ripped out of Tor Browser?

(If that is so, we’d ask another question. Perhaps we could connect to
another unix domain socket file and then redirect that to localhost TCP
using socat or systemd or so.)

One should be manageable?

Yes. Even more so when it is properly named.

No. It doesn’t work with Tor Browser on purpose and so we must go the multi TBB folder route as per:

configuration - How to use multiple profiles with Tor? - Tor Stack Exchange

I see. Not eager to use Firefox profile manager anyhow.

HulaHoop:

[quote=“Patrick, post:6, topic:4888”]
Using multiple user profiles within the same tor-browser folder seems
better?
[/quote]

Yes probably. There is also precedent for running custom Firefox for a
long time.

Well, as per your own link,

says mmultiple profiles within the same tor-browser folder is unsupported.

Yes its just a matter of enabling it with a “1”

That’s good. So we have option:
We could have only one Tor Browser installation with only one profile.
Depending on which launcher is used, this settings could be set or
unset. Disadvantage: no localhost-by-tbb-default-forbidden and
localhost-allowed instances of Tor Browser running at the same time.
Good enough or not good enough?

1 profile, 2 TBB folders, no need to complicate tb-starter or ask questions. The shortcut links to the second TBB should have a self explanatory name.

Then tb-updater would need a multi installation feature. It’s doable.
But since this is an afterthought, not easy to do the migration from the
current folder and code structure to a new one.

1 Like

The sockssocket work is already implemented AFAICT with no further deprecation in progress:

But I opened a ticket to ask just in case:

That was part of the old reply I forgot to remove when I found the new info.

That’s quite limiting. I imagine most users want to be able to browse the web normally while keeping something something like zeromail running in the background waiting for messages. Limiting them to “either or” will cause them to just use the localhost friendly profile everywhere which isn’t good.

Good to know. Also if its not a big task, its better if the package is renamed into tbb-manager to reflect that it does much more than update TBB at the moment.

1 Like

Not necessarily. Porting to SocksSocket is a necessary first step but not the full solution. A separate ticket might be to actually rip TCP out of Tor Browser. Pretty sure that is the case.

Not sure you lost them at hello.

Does Tor Browser communicate with localhost via TCP sockets or Unix sockets?

It doesn’t matter what it does now. It’s in question if TCP is already ripped out of Tor Browser or if that is still TODO, if they have a ticket for that and if that is still the plan (probably is).

Trac component is essential. Otherwise nobody notices the ticket.

They told me how it works though using the bugtracker for such questions is frowned upon.

The answer to your question is: TCP for most platforms, Unix for some, moving to Unix eventually depending on platform support.

AF_LOCAL for none. The support was implemented but isn’t actually used on anything. Maybe now that #22794 is fixed there will be revised interest, since it’s no longer totally pointless.

1 Like

Hi
can you tell me where i can find this setting?

1 Like

Hi Goldstein

I believe that is in reference to a custom profile. If you would like to edit the default Tor Browser profile the location is:

/home/user/.tb/tor-browser/Browser/TorBrowser/Data/Browser/profile.default/prefs.js

You can also find the profiles using Tor Browser by typing about:support in the address bar. Scroll down and click about:profiles and you can see/create profiles and can set the desired profile as the default.

1 Like

Hi Goldstein. Here is the original thread:

In Tor Browser go to

about:config → search “network.proxy.no_proxies_on” → Set boolean to ‘0’

2 Likes

Thank you @HulaHoop & @0brand

Wouldn’t that still apply to two TBBs? I imagine most Users would use only one and forget about the second TBB or am I missing something ?

Does the localhost setting really change the Fingerprint ? Maybe we should block non I2P/Zeronet/Locahost access in the Second TBB ? So the User would use the “clean” TBB to access Tor etc and the second TBB for I2P/Zeronet.

That would work with Zeronet and similar things, I2P needs more Time to build Tunnels so i would say to have the best experience I2P needs to start at Boot.

I guess this won’t work that easy with Qubes ?

1 Like

So with two TBBs a user can run one instance with the fingerprint intact and the other that is compatible with I2P simultaneously.

Yes any site can remotely scan for listening daemons on localhost which sticks out like a sore thumb compared to majority of Tor Browser users.

I think we are both saying the same thing. Yes one of them will have the original intact preferences that disallow localhost while a second custom one will allow localhost. You can’t have multiple profiles in one TBB by design.

I guess this won’t work that easy with Qubes ?

As far as Qubes or any Virtualizer is concerned. Noone of these changes affect the GUI window titles of other programs running in other VMs or that of the VM/domain window itself so it shouldn’t conflict.

1 Like

Should the Localhost TBB be able to connect to Tor too ? I think this would encourage users to only use one TBB for everything.

Right, i was thinking about colored Windows, my mistake.

I’m not familiar with tb-updater, do user settings in prefs.js persist after an Update ?

How are we going to handle the creation of the second tbb folder?Should tb-updater ask the user or are we going to use a config file or a new tb-updater cmdline argument ?

URandom:

I’m not familiar with tb-updater, do user settings in prefs.js persist after an Update ?

  • tb-updater: not as of Whonix 13/14
  • Tor Browser internal updater: probably yes (depends on Tor Browser,
    Whonix does not interfere)

How are we going to handle the creation of the second tbb folder?

  • $tb_user_home/default/as-usual
  • $tb_user_home/localhost-allowed/as-usual

?

Extract twice rather than once.

Should tb-updater ask the user

No user questions. Too complicated.

or are we going to use a config file or a new tb-updater cmdline argument ?

Config probably. But rather indirectly. Since all is nicely put into
variables anyhow, config can overwrite anything. But not as a very
advertised feature.

Default just always update both to keep things simple for users.

1 Like

It shouldn’t. good point. I am sure there is a way to go about doing this? @Patrick

1 Like

Good window titles? A window title including Use this for localhost connections only!?