Hi,
synthe:
> I've been giving a little thought to issue #9700,
Woohoo!
> and while enabling full persistence
> for those user_pref parameters that relate to Torbutton settings may be workable, and
> replicates the behaviour one would normally expect of a TBB installation on
> a 'normal' OS, it does go against the spirit and principle of an amnesic live-OS.
> Any undesirable, inadvertently chosen settings would then persist across reboots,
> a scenario I feel would be best avoided.
IMO the ideal solution for #9700 requires an opt-in persistence
setting that fully persists Tor Browser security slider settings
across reboots and user configuration i.e. "replicates the behaviour
one would normally expect of a TBB installation on a 'normal' OS".
As long as it's opt-in, I see no reason to make it any harder to use,
nor to make it behave differently from all the other persistent
settings we have.
E.g.:
1. Add a persistence setting in Tails Persistence Setup, called e.g.
"Tor Browser Security Settings" (just like the corresponding dialog
is titled). This would make some file persist.
2. Then we have two options:
a) Directly save low-level Tor Browser settings in .js format in
the persistent file, and ensure that 1. this persistent file is
loaded when Tor Browser starts (rather easy, as your research
shows); 2. any change applied by the user to the security slider
settings is persisted in that file (a bit harder, probably this
would require adding code to our tor-browser wrapper script).
b) Save the desired security slider settings in a higher-level way,
in non-JS format, e.g. TOR_BROWSER_SECURITY_SLIDER=$level.
Then our tor-browser wrapper script could set
extensions.torbutton.security_slider accordingly on Tor Browser
startup, and after Tor Browser has exited it could persist the
updated settings to that persistent config file.
I'm not sure which is best.
Now, a documentation-only approach would be a pretty good start :)
> The dotfiles persistence feature would be used to pregenerate
> ~/.tor-browser/profile.default/prefs.js as follows:
> #prefs.js file to apply initial Torbutton settings
> user_pref("extensions.torbutton.security_slider", 1);
AFAICT that's enough: depending on this value, Torbutton automatically
sets all the other prefs it's about.
So that should not be needed:
> user_pref("gfx.font_rendering.opentype_svg.enabled", false);
> user_pref("javascript.options.baselinejit", false);
> user_pref("javascript.options.ion", false);
> user_pref("javascript.options.native_regexp", false);
> user_pref("mathml.disabled", true);
> user_pref("noscript.forbidFonts", true);
> user_pref("noscript.forbidMedia", true);
> user_pref("noscript.global", false);
> user_pref("svg.in-content.enabled", false);
> user_pref("media.webaudio.enabled", false);
> 2. Similar to option 1, except the 11 settings are not used to create prefs.js, but
> a ~/.tor-browser/profile.default/preferences/torbutton-high.js . The result is the
> same as 1, except the Torbutton slider is reset every time a new *instance of Tor
> Browser* is started. This is more secure/foolproof still, but not particularly
> user-friendly, and only probably makes sense to those who can tolerate Javascript
> (and more) being disabled almost all the time.
I think any change done in the GUI should be applied on next restart
of Tor Browser. And if the opt-in "Tor Browser Security Settings"
persistence preset is enabled, then it should also be persisted.
So let's not do that.
> 3. Similar to option 1, but with the proposed prefs.js being present in the squashfs
> live environment. This is perhaps the most radical option, in that any Tails CD would
> have Torbutton set to High by default, as opposed to Low.
That's not an option at the moment IMO: High by default just breaks
too many websites, and there's no feedback to the user when it does
break stuff. There's been some thinking put into improving the UX
in the Tor Browser team but we're not there yet. For the curious,
start there:
https://trac.torproject.org/projects/tor/ticket/21034
https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/Notes/SecuritySliderUsability
Cheers,
--
intrigeri
