Dear Tails Developers,
I've been giving a little thought to issue #9700, 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.
There are a number of other approaches one can take, which would solve the whole 'problem' as far as a user is concerned, and are, from a technical point of view, all relatively trivial, and transparent, to implement.
Since this is my first contribution to this project, I'd like to put a couple of alternatives to the developers before making any suggestions, and see which would be preferable:
1. An 'opt-in' option for 'advanced' users added to the documentation on tails.boum.org, similar to that described for persisting KeepassX settings on
https://tails.boum.org/doc/encryption_and_privacy/manage_passwords/index.en.html . 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);
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);
When Tor Browser is subsequently started, prefs.js is populated as normal, albeit with the 11 predefined values taking precedence. ["media.webaudio.enabled", normally defined 'true', becomes 'false', while the other 10 are simply added to the file.] The result is a Torbutton and Tor Browser configuration (de facto) identical to that obtained when one first starts the tor-browser in Tails with no prefs.js present, and subsequently sets the Torbutton slider to High, and all its associated parameters.
In this scenario, the slider is only 'reset' to High each time the whole OS is rebooted.
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.
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. Not too much of a radical departure, since we already have 0000locale.js, 0000tails.js and extension-overrides.js, but it would require someone (I would volunteer!) to ensure that the parameters are thoroughly double-checked and tested before any release sporting a new version of tor-browser).
What do you guys think, an important hardening step for the website or even version 3.3, or a something worth keeping on the backburner?
Let me know :)
Synthe
