I doubt this would be done just for Whonix devs/users. This would somehow have to benefit everyone.
Most requests are denied because they somehow degrade anonymity for everyone. Since they hardcoded these prefs(?) they don’t want Tor Browser users changing them around. Maybe the best approach is to upfront with them on the reason for doing this. Take Whonix out of the equation. While non for anonymity make sure they know Whonix devs have already completed a lot of work on this.
SecBrowser
Would be useful to everyone (everyone needs an security focused clearnet browser)
Its a good start. It will take some time to get it just right.
When SecBrowser is started, the about:tor tab opens and the focus is taken off the SecBrowser landing page. I restarted SecBrowser and the same thing happened.There has to be a way to fix this.
I have a new branding idea. Currently there is SecBrowser, Hardended Debian based OS and maybe more apps hardened by Whonix developers. We could use “Sec” as the brand for the OS and apps that are hardened. For example:
Ive been experimenting with pass-qubes in SecBrowser. I don’t think it would be an worse for fingerprinting than the current method (passwords stored in SecBrowser) but would be less attack surface.
Configuring lock_pref() , lockPref()might be a workaround for these two issues. I think thats’ what TBB devs use to keep users from changing prefs such as the security slider default. it will likely break Tor Browser but cant hurt to try.
Another idea to block JavaScript by default at SecBrowser start might be QuickJS. Its mentioned in the Tor Project docs/FAQ. Not sure how easy it would be to install QuickJs by scipt when SecBrowser is configured the first time by tb-updater tb-starter.
There is also a very simple addon available at addons.mozilla.org called QuickJS, which provides a toolbar toggle for the javascript.enabled about:config control. There are no configuration options for the addon, it just switches the javascript.enabled entry between true and false and provides a button for it.
From: gk
Why is it not enough to just set the desired slider level in a prefs file that you ship in the browser profile (anyway)?
I think using the prefs approach is the one you should pursue right now. Shipping an own profile with customizations won’t go away in the forseeable future.
If the above is true, maybe the security slider not honoring the custom profile pref is a bug? Or perhaps we are missing something (not setting the correct pref?).
Regardless thats’ the solution imo. Lets lead off by asking why the security slider is not honoring the pref that we set. No reason to say anything about Whonix or SecBrowser.
Yes. We need to ask for how to set the pref. We can say that we know
there will be no environment variable and have to go the profile route.
It could be in form of a bug report “setting this pref does not work as
expected” or as enhancement request “please document how to do…” or it
could be asked on the mailing list as a question. Dunno what’s best but
anything can work, I guess.
I was using either to many user_prefs (
extensions.torbutton.security_custom) or they were in the wrong order when setting the security slider, which was breaking SecBrowser.
It looked sane but I should have added one at a time.
It might set the slider to highest but does it also do the action that
slider would apply when it is manually being set to highest? I.e. would
it actually disable scripts globally when started in this configuration?
