Project

General

Profile

Feature #9700

Persistence preset: Tor Browser security slider setting

Added by DanOver over 4 years ago. Updated over 1 year ago.

Status:
In Progress
Priority:
Low
Assignee:
Category:
Persistence
Target version:
-
Start date:
07/07/2015
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:
Browser

Related issues

Related to Tails - Bug #10481: Disable JavaScript by default Rejected 11/04/2015
Related to Tails - Feature #11417: Default torbutton security slider to "Medium-High" Rejected 05/14/2016
Related to Tails - Feature #15013: Consider setting Security Slider to "High" by default Resolved 12/03/2017

History

#1 Updated by intrigeri over 4 years ago

  • Category set to Persistence
  • Status changed from New to Confirmed
  • Priority changed from Normal to Low
  • Type of work changed from User interface design to Research
  • Affected tool set to Browser

Subject: Persistence preset: Tor Browser security slider setting

A way to persist the extensions.torbutton.security_slider pref would address this request and more. It would also make Tails' UX closer to the Tor Browser's one, so I'm triaging this ticket as a valuable feature request. Would be awesome if somebody worked on it :)

#2 Updated by DanOver over 4 years ago

Forgetting enable NoScript can compromise user security and we are all vulnerable to this. Forcing users to perform this action every initialization increases the chances for this problem from occurring.

#3 Updated by intrigeri over 4 years ago

  • Subject changed from NoScript enabled in persistence to Persistence preset: Tor Browser security slider setting
  • Description updated (diff)

#4 Updated by sajolida about 4 years ago

  • Related to Bug #10481: Disable JavaScript by default added

#5 Updated by sajolida over 3 years ago

  • Related to Feature #11417: Default torbutton security slider to "Medium-High" added

#6 Updated by synthe about 2 years ago

I would like to, very respectfully, propose that this issue be given higher priority. Nearly all of the most egregious, deanonymizing, 0-days against the TBB have required Javascript to be enabled. And even as we speak, exploits targeting javascript-enabled TBB are considered far less worthy of a 6-figure bounty than any capable of compromising Tails with Torbutton set to 'High' (https://www.deepdotweb.com/2017/09/28/government-contractor-offers-million-dollar-bounty-tor-0-days/)

In this respect, Tails (whose default settings are otherwise wisely chosen), is currently diverging from a default installation of TBB on, say, Debian, by reverting to the default, 'Low' Torbutton setting after each reboot. Having to double check that one has correctly changed the Torbutton slider every time Tails is started doesn't lead to a comfortable user experience.

While I understand the desire to keep Tails accessible to novice users, and the extra work, and testing, required to implement fully automatised persistence for such a feature, I was thinking that perhaps a verified, tested, foolproof method to use Dotfiles persistence to persist one's desired Torbutton settings (via prefs.js) be added to the documentation on tails.boum.org.

If the developers agree, I'd be honored to be able to help out :)

#7 Updated by intrigeri about 2 years ago

If the developers agree, I'd be honored to be able to help out :)

Cool! What "Low" priority means on our Redmine, as per https://tails.boum.org/contribute/working_together/Redmine/, is "It would be good to have it, but nobody is volunteering to do it", so by all means, please go ahead :)

Next steps:

  1. read https://tails.boum.org/contribute/how/code/
  2. think about how you think this should be implemented
  3. share your initial design/implementation plans on (and then it might be that the UX part of the discussion will be moved to the dedicated mailing list)

#8 Updated by synthe about 2 years ago

Dear intrigeri,

Thanks for the prompt response!

I've posted a few considerations and proposals in my third mail (the first two mails were really just test reports) to tails-dev: https://mailman.boum.org/pipermail/tails-dev/2017-October/011742.html

#9 Updated by intrigeri about 2 years ago

  • Status changed from Confirmed to In Progress
  • Assignee set to synthe

#10 Updated by synthe about 2 years ago

Dear Intrigeri,

Thanks for your responses and input over on tails-dev. You were absolutely right - I see that a single user_pref ("extensions.torbutton.security_slider", 1) is sufficient for Torbutton to set all its necessary parameters as prefs.js is parsed at tor-browser's startup - thanks for the tip!

An entirely new separate persistence.conf entry (via a 'Tor Browser Security Settings' via the GUI) would indeed be the most elegant in the long term. It would also allow one to reliably persist Torbutton settings across reboots, thus faithfully replicating the behaviour of a normal, non-amnesic, TBB installation. As long the security_slider parameter alone is persisted from tor-browser, it should protect users against any other (possibly insecure) configuration choices from surviving reboot.

I'll start by preparing a very simple, dotfiles-based, documentation-only suggestion, which would only require inclusion on the Tails' website documentation and no changes to code for now. If that proves popular I'll work on a feature branch which, if approved and merged, should reliably deal with the whole issue via a new 'Configure Persistence' GUI option.

Synthe

#11 Updated by synthe about 2 years ago

I've posted a git diff of my proposed commit to the Tails documentation, for a first, opt-in approach at dealing with this matter: https://mailman.boum.org/pipermail/tails-dev/2017-October/011783.html

It's relatively predictable, but I've tested it on both the original stretch-based Tails 3.0, and the latest development build too to be sure.

Let me know what you think.

#12 Updated by u almost 2 years ago

  • Related to Feature #15013: Consider setting Security Slider to "High" by default added

#13 Updated by u over 1 year ago

  • Assignee changed from synthe to intrigeri
  • QA Check set to Ready for QA

It seems synthe wanted a review of their approach.

#14 Updated by intrigeri over 1 year ago

  • Assignee changed from intrigeri to synthe
  • QA Check deleted (Ready for QA)

u wrote:

It seems synthe wanted a review of their approach.

I did that review and then we had a good discussion but AFAIK no merge-ready patch was submitted yet.

Also available in: Atom PDF