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?
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.
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.cssAll 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
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://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?
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
Which would
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.
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.
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.
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.
Hi
can you tell me where i can find this setting?
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.
Hi Goldstein. Here is the original thread:
In Tor Browser go to
about:config â search ânetwork.proxy.no_proxies_onâ â Set boolean to â0â
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 ?
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.
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 ?
How are we going to handle the creation of the second tbb folder?
?
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.
It shouldnât. good point. I am sure there is a way to go about doing this? @Patrick
Good window titles? A window title including Use this for localhost connections only!?