Tor Launcher/Torbutton should provide a "Security Slider"

A large number of our users seem to be confused about the state of JavaScript in TBB. We leave it enabled for usability reasons, but ship with NoScript in the toolbar to make it easy to disable. This might not be enough for people who start TBB with incorrect assumptions/word-of-mouth rumors about its defaults.

Roger suggested a possible way forward is to create a Security Slider on the Tor Launcher first launch page and the Torbutton settings that allows people to trade off between "Most Usable" on one end, and "Most Secure" on the other end. We want to minimize the number of positions on this slider to avoid fingerprinting, but a small number of slider positions (3-4) that set several settings underneath shouldn't be too bad:

• Position 0: Current TBB defaults (Most usable)
• Position 1: Javascript is disabled for all non-https URLS
• Position 2: HTML5 media and fonts click-to-play/disabled
• Position 3: All scripts and media are disabled (Most secure)

We might even want to combine positions 1+2. Unclear.

added TorBrowserTeam201503 component::applications/tor launcher extdev-interview owner::gk priority::high resolution::fixed status::closed tbb-3.0 tbb-4.5-alpha tbb-isec-report tbb-linkability tbb-security tbb-usability type::enhancement labels

We could possibly add a position to also disable all image loading too (preferences.default.image), but that may be too extreme for anyone to actually use.

I think I want only 4 positions max, too, so if we added this image blocking option to the slider, we would have to combine positions 1+2 from the description.

SVG should also be disabled at some point, perhaps under position 3.

Replying to mikeperry:

• Position 0: Current TBB defaults (Most usable)
• Position 1: Javascript is disabled for all non-https URLS

If I'm worried about js as an attack vector, my worries aren't really resolved by the website I'm going to getting an ssl cert from somewhere. It helps with an attacker in the middle injecting js into http, sure, but it doesn't help with similar cases like an attacker modifying http to make me fetch some other resource over https and then run its javascript.

Are you imagining this as a usability improvement, rather than a security thing? Or is there some further trick where we actually only run js from an https website when it's the url in our url bar?

• Position 2: HTML5 media and fonts click-to-play/disabled

If we can get the interface on this one right, it shouldn't be too much of a usability impact, yes? If so I agree that we can/should do it on the 'more commonly chosen' end of the spectrum.

(What is a font click-to-play?)

Replying to arma:

Replying to mikeperry:

• Position 0: Current TBB defaults (Most usable)
• Position 1: Javascript is disabled for all non-https URLS

If I'm worried about js as an attack vector, my worries aren't really resolved by the website I'm going to getting an ssl cert from somewhere. It helps with an attacker in the middle injecting js into http, sure, but it doesn't help with similar cases like an attacker modifying http to make me fetch some other resource over https and then run its javascript.

Are you imagining this as a usability improvement, rather than a security thing? Or is there some further trick where we actually only run js from an https website when it's the url in our url bar?

Yes, long-term I want to do the "only load scripts if the url bar is https" version of this, but it requires use of APIs we wrote that not yet available to NoScript in stock Firefox.

Shorter term, I still think it's an improvement because it creates an additional audit trail of sorts for people who are attacking users.

• Position 2: HTML5 media and fonts click-to-play/disabled

If we can get the interface on this one right, it shouldn't be too much of a usability impact, yes? If so I agree that we can/should do it on the 'more commonly chosen' end of the spectrum.

(What is a font click-to-play?)

"WebFonts" (fonts provided by the web server) will be blocked by NoScript, and it will tell you so in its icon so you can enable them.

I'm not sure a slider will work. If a user chooses a slider position during "first run" but later changes one of the underlying prefs (via about:config), how would the slider reflect the partial settings?

How should the choices be described in the UI?

Also, do you envision this prompt being displayed on its own "wizard" panel? (e.g., before the Connect/Configure prompt)?

I have used PrefBar for several years. This add-on provides the features you ask for. It is also easy to configure your own functions. I recently added a dom.storage.enabled toggle for an offline FF copy that I use for HTML5 development.

I have been meaning to ask of you regular Tor-devs to properly vet this addon, and now seems to be a good time to do it.

As far as I can tell there is only one button that might require removal from a customized install, the prefbar:button:executedemo2 found in the 'prefbar.json' settings file.

The original author of this addon might cooperate with you, just ask him.

References: https://addons.mozilla.org/en-US/firefox/addon/prefbar/ http://prefbar.tuxfamily.org/

Original author: Manuel Reimer <manuel.reimer AT gmx.de>

Replying to brade:

I'm not sure a slider will work. If a user chooses a slider position during "first run" but later changes one of the underlying prefs (via about:config), how would the slider reflect the partial settings?

Good question. How about having a slider with a few points on it, but also a "custom" point? If the user chooses a point on the slider, it sets her configuration to be what that point does. If she later changes some pref to not match that point in the slider, then TorbrowserButton could notice and change her slider setting to Custom. Now users have an easy way to say "give me that level of protection please", but they can also do more advanced things if they prefer.

How should the choices be described in the UI?

In clear language that helps the user make the decision of course. ;) I think we first need to figure out what the choices should do.

Also, do you envision this prompt being displayed on its own "wizard" panel? (e.g., before the Connect/Configure prompt)?

Hm. Is it too much to hope that they would both go on the same screen?

Given the oracle attacks (BEAST and more recently BREACH) using compression, should the slider also deactivate any kind of compression in the “most secure” position?

Do we have enough Tor Browser Bundle users now that we can happily split the anonymity set with such slider?

Replying to lunar:

Do we have enough Tor Browser Bundle users now that we can happily split the anonymity set with such slider?

Maybe not happily, but I think we have enough users who genuinely have different security / anonymity / usability priorities that we have to.

To be clear, I'm currently believing that the default position for the slider should be somewhere in the middle, and not on the "totally open" side.

Ok, it looks like we're starting to avalanche down the slippery slope here. Time to reign this back in to something reasonable in scope and purpose.

First, I am not sure how we can easily disable compression short of some header filter that asks the server not to do it (which may or may not actually work against an active attacker, since the browser still actually does support it and likely will still decompress any compressed data it does receive). Also, we should wait to see if the browser vendors come up with a real solution to such attacks instead of trying to jump the gun on them and proactively disable shit as if it were an actual fix. I'm still as against that as I ever was. In fact, such temporary hacks definitely do not belong under this mechanism.

Second, as for "somewhere in the middle" as a default, I'm also against that. If you have no idea what the slider does because you just clicked "Connect" without reading anything, you should not be subjected to a broken experience by default. The user will have no idea why or how to fix it, and their reaction will be to stop using the browser.

Third, especially in its first revision, the slider should exist only to disable a few key items that already have prefs in either about:config or NoScript. It should have no more than 3 or 4 positions to avoid fragmentation of the anonymity set. This means several things will be grouped together under each tick.

This ticket is solely about giving users in specific situations advanced opportunity to configure some security defaults in a way that does not damage their anonymity set too much, and also gives them advanced notice and opportunity to alter what some may perceive as permissive defaults. Everything else, including hijacking this ticket to alter defaults to re-disable a bunch of features we were just funded fix to make HTML5 usability better, is out of scope.

Trac:
Cc: arma, mcs, brade, ioerror to arma, mcs, brade, ioerror, g.koppen@jondos.de

Replying to mikeperry:

Second, as for "somewhere in the middle" as a default, I'm also against that. If you have no idea what the slider does because you just clicked "Connect" without reading anything, you should not be subjected to a broken experience by default. The user will have no idea why or how to fix it, and their reaction will be to stop using the browser.

Or they come bothering you. And having more than 4 years experience with explaining users e.g. which scripts on a page they have to allow to get that page to work as they expect I can assure you that this binds a lot of resources.

Please consider my idea for adding a smart referer spoofing feature by default for hidden services and as a preference to be included in this slider to enable this feature for all websites (hidden + clearnet) which may cause some issues but will provide better protection against tracking.

#9623#comment:5

Camilo is working on a similar slider for security-related prefs: https://bitbucket.org/cviecco/simple-security-and-privacy-addon/src

Jesse Ruderman pointed out that there are actually several JS options we can disable before entirely disabling javascript: {{{
javascript.options.ion.content javascript.options.baselinejit.content javascript.options.asmjs javascript.options.typeinference.content }}}

These should only degrade performance and not functionality. Also, they have historically had very high vulnerability counts to date, perhaps more so than all of the rest of JS itself.

Mozilla is discussing additional high-vulnerability/low-adoption features that can be disabled in this thread: https://groups.google.com/forum/#!topic/mozilla.dev.platform/BKa6rzcKvdo

Many of these don't have prefs yet, but I suppose we could add some for them..

Trac:
Keywords: N/A deleted, tbb-security added