Add a Torbutton pref to disable local tor check
[ Re: discussion with Mike at #11384 (closed) ]
The Torbutton icon and about:tor page indicate that Tor is not working when Torbutton does not have full access to the control port (when not using the 'Transparent Torification' option in Torbutton preferences), even if the browser is properly configured to use Tor. This can be dangerous when something does go wrong (e.g. bug #11384 (closed)) because there is then no visible difference to the user.
If Transparent Torification is selected Torbutton skips the local check and instead performs a remote check, which gives a correct indication of whether the browser is torified. However, there are cases, other than transparent torification, that the remote check is desirable over the local check. These include:
A) Connecting TorBrowser to system-wide Tor instance, which you do not want the browser to be able to manipulate (e.g. tor-launcher automatically stopping Tor process on closing the browser) B) Preventing TorBrowser access to control port so that it cannot retrieve/leak circuit information C) Tails
Tails encountered this problem (they only allow NEWNYM requests from the browser to the control port), but at the time remote Tor check was broken (#10189 (closed)) so they opted to patch Torbutton to completely disable Tor check, both local and remote (http://git.tails.boum.org/torbutton/commit/?id=7b7aba560dadb0299212a47971d08ac937672868). This is arguably unsatisfactory and is only safe because Tails has strict firewall rules preventing leaks.
I propose we add a user pref which tells Torbutton to use the remote check instead of local check, so TorBrowser only shouts when it isn't connecting over Tor. The default behavior would be unchanged. A (two-line) patch is attached.
If Tails devs are happy with this solution this could also close #10216 (moved).
Trac:
Username: scissors
Activity
Trac:
Username: scissors-
Looking back at the discussion at #11384 (closed) I realize that maybe the patch Mike was looking for was one to improve the process of setting a nonstandard ControlPort/Password (instead of environment variables), rather than one to improve the state of the browser when ControlPort access is restricted. I'd be happy to write something along those lines if that's the case.
Trac:
Username: scissors 
Replying to scissors:
Looking back at the discussion at #11384 (closed) I realize that maybe the patch Mike was looking for was one to improve the process of setting a nonstandard ControlPort/Password (instead of environment variables), rather than one to improve the state of the browser when ControlPort access is restricted. I'd be happy to write something along those lines if that's the case.
Yeah, I was thinking more along those lines. I think this patch can be acceptable though as a hidden pref. However, other users may have use for improved control port+password config, too. Someone else just filed #11751 (moved), for example.
-
Replying to mikeperry:
Yeah, I was thinking more along those lines. I think this patch can be acceptable though as a hidden pref. However, other users may have use for improved control port+password config, too. Someone else just filed #11751 (moved), for example.
Great, I'd love to see this feature. And it looks like #11751 (moved) would too (unless they are trying to connect to the ControlPort, I'll ask).
I'll file a separate bug for improving control port+pass config. I would really appreciate your input on how these options should be presented to the user i.e. something in the gui (with suitable warning/disclaimer), keep it all in about:config or just improve the usability of the environment variable interface.
Trac:
Username: scissors I'm #11751 (moved), actually all I need is the default behavior of Tor Browser.
Maybe off-topic but can I also whitelist tor control commands to NEWNYM?
mentioned in issue #11751 (moved)
mentioned in issue #13079 (moved)