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.
Activity
added TorBrowserTeam201503 in Legacy / Trac component::applications/tor launcher in Legacy / Trac extdev-interview in Legacy / Trac owner::gk in Legacy / Trac priority::high in Legacy / Trac resolution::fixed in Legacy / Trac status::closed in Legacy / Trac tbb-3.0 in Legacy / Trac tbb-4.5-alpha in Legacy / Trac tbb-isec-report in Legacy / Trac tbb-linkability in Legacy / Trac tbb-security in Legacy / Trac tbb-usability in Legacy / Trac type::enhancement in Legacy / Trac 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.
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.enabledtoggle 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:executedemo2found 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?
-
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.
-
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.
-
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..
-
We could also include RequestPolicy but leave it disabled until the user selects "High Security", though this will be complicated because by default its UI will be present and users will likely tweak it under lower security modes (which will cause the interaction problems with the slider that brade pointed out and cause most people to end up in the 'custom' position).
-
We may also be able to tweak the memory allocator to use smaller free lists by tweaking prefs or exposing various jemalloc cleanup functions and calling them periodically, at the cost of performance. See also legacy/trac#10281 (moved).
-
Replying to mikeperry:
We could also include RequestPolicy but leave it disabled until the user selects "High Security", though this will be complicated because by default its UI will be present and users will likely tweak it under lower security modes (which will cause the interaction problems with the slider that brade pointed out and cause most people to end up in the 'custom' position).
Don't forget the need for thorough review of RequestPolicy code on an on-going basis. That extension is not trivial and the expectations when using the high security mode are ... high. That currently sounds to me like a lot of additional work (not looking at the additional support requests or weird bugs due to interaction with other extensions) for little gain.
Why don't you check out PrefBar?
It has a checkbox to enable/disable JavaScript.
PrefBar hasn't anything to do with HTML5. Unless you want to.
I've suggested this solution 5 months ago. It's sad to see that the torproject blog is full of posts that requests an easy way of disabling JavaScript, while the solution awaits your blessing (and expert vetting of privacy and security issues.)
-
Replying to cypherpunks:
Why don't you check out PrefBar?
It has a checkbox to enable/disable JavaScript.
PrefBar hasn't anything to do with HTML5. Unless you want to.
I've suggested this solution 5 months ago. It's sad to see that the torproject blog is full of posts that requests an easy way of disabling JavaScript, while the solution awaits your blessing (and expert vetting of privacy and security issues.)
No, that's a different issue.
There is already an easy way to disable javascript in TBB 3.5: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowserBundle3FAQ#HowdoIdisableJavaScript
The goal of this ticket is to let the user select a security posture, which would affect multiple settings, before any pages are even loaded.
Replying to arma:
The goal of this ticket is to let the user select a security posture, which would affect multiple settings, before any pages are even loaded.
Yes, I get that. I already change multiple settings with PrefBar, but I need to toggle each checkbox or button instead of "sliding". And sometimes I need to add or modify buttons. (Changes made with PrefBar also takes effect before any pages are loaded.)
There is a different user experience between a slider and the row of checkboxes that PrefBar offers. In time, the users will decide which is better.
But I find PrefBar useful, and have not found anything suspicious about it. I would welcome your, brade or Mikes opinion on this addon, after it has been examined. It may not replace the slider, but it could be added to the recommended list.
I don't think this belongs into Tor Launcher. Does the design goal, do one thing and do it well apply here? Since Tor Launcher might become a standalone XUL app or also being used in Tails some day (having it in Whonix some day would be interesting as well), I think having such a security slider is better in TorButton or even better in a separate add-on.
Having a separate Firefox add-on has another advantage: Other users, non-Tor, security concerned users could use it as well. Websites owners would have to think twice if they are going to add features, which are blocked by a popular security add-on.
-
I agree that the security slider is more appropriate in Torbutton or a separate add-on. The challenge here is coming up with the right UI and user experience (in addition to determining what settings are used in which slider positions).
In TBB, we want to prompt the user for their choices as part of the tor configuration dialogs (presented by Tor Launcher when TBB is opened for the first time). Maybe the add-on that includes the security slider can make a XUL panel available that Tor Launcher can present as part of the first run experience. If that can't be done, the security logic (setting of preferences, etc.) should be placed in Torbutton or another add-on where it can be used by Tor Launcher and other add-ons that need to allow users to change the settings.
-
Replying to brade:
In TBB, we want to prompt the user for their choices as part of the tor configuration dialogs (presented by Tor Launcher when TBB is opened for the first time). Maybe the add-on that includes the security slider can make a XUL panel available that Tor Launcher can present as part of the first run experience. If that can't be done, the security logic (setting of preferences, etc.) should be placed in Torbutton or another add-on where it can be used by Tor Launcher and other add-ons that need to allow users to change the settings.
I like the intuition behind this division -- Tor Launcher asks the user what she wants, and then sets some config option that instructs Torbutton about what the user asked for. Then Torbutton actually does it.
(I'm ok with your 'torbutton makes a xul panel' approach too, if that is actually simpler -- it sounds complexer to me. But I am not one with xul.)
Trac:
Cc: arma, mcs, brade, ioerror, g.koppen@jondos.de to arma, mcs, brade, ioerror, g.koppen@jondos.de, intrigeri@boum.org-
Trac:
Cc: arma, mcs, brade, ioerror, g.koppen@jondos.de, intrigeri@boum.org to arma, mcs, brade, ioerror, gk, intrigeri 
Replying to mikeperry:
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.
Turning off these options degrade performance up to the point where some JavaScript heavy websites are unusable (e.g. mega.co.nz). This might be a source of confusion. Not working at all is easier to understand than “appears to be working but so slow that it'll never work”.
-
javascript.options.baselinejit.content seems to help with simple JS benchmarks around the net, but according to https://octane-benchmark.googlecode.com/svn/latest/index.html and http://dromaeo.com/, the additional perf benefit from ion and typeinference is substantial.
I am still not sure what we should do by default. Has the helpdesk seen mail about this yet? If so, how much?
-
Replying to mikeperry:
I am still not sure what we should do by default. Has the helpdesk seen mail about this yet? If so, how much?
At least one on my side reporting that it made mega.co.nz unusable (as reported earlier).
Trac:
Cc: arma, mcs, brade, ioerror, gk, intrigeri to arma, mcs, brade, ioerror, gk, intrigeri, tom@ritter.vgReplying to T(A)ILS developers:
We at Tails would like to do the same, and it would be great to know if we can include these JS security improvements into our browser for Tails 1.1 (freezes around May 25), or if we should skip it.
Actually our freeze is on May 28, so there's still two more days left...
Replying to mikeperry:
I am still not sure what we should do by default. Has the helpdesk seen mail about this yet? If so, how much?
Anything new on this front?
-
On slow sites, you get a script popup if it tries to do something extremely intensive and stalls out. This can be improved by raising http://kb.mozillazine.org/Dom.max_script_run_time, but it's already at 10 seconds. The browser UI is also unresponsive during this entire time.
This is pretty bad for usability, in my opinion. Given that we almost have ASAN builds (legacy/trac#10599 (moved)) and those are only 2X slower (instead of like 10X as we see for the JIT), I think that the better option is to turn these JIT optimizations back on, and provide the ASAN-hardened builds for people who want hardening.
-
Replying to mikeperry:
On slow sites, you get a script popup if it tries to do something extremely intensive and stalls out. This can be improved by raising http://kb.mozillazine.org/Dom.max_script_run_time, but it's already at 10 seconds. The browser UI is also unresponsive during this entire time.
This is pretty bad for usability, in my opinion.
Yes, but do you have some hard data that the JIT options are the culprit here? So far I have seen exactly one complaint, maybe two about the TBB >= 3.6 being slow that we might want to relate to the JIT options. That seems IMO not enough to disable the security gain. At least not until we have hardened builds available regularly.
-
Replying to gk:
Replying to mikeperry:
On slow sites, you get a script popup if it tries to do something extremely intensive and stalls out. This can be improved by raising http://kb.mozillazine.org/Dom.max_script_run_time, but it's already at 10 seconds. The browser UI is also unresponsive during this entire time.
This is pretty bad for usability, in my opinion.
Yes, but do you have some hard data that the JIT options are the culprit here? So far I have seen exactly one complaint, maybe two about the TBB >= 3.6 being slow that we might want to relate to the JIT options. That seems IMO not enough to disable the security gain. At least not until we have hardened builds available regularly.
I have seen a couple instances of this popup personally on some sites. You can also notice the ~5 to 10X performance degradation on https://octane-benchmark.googlecode.com/svn/latest/index.html and http://dromaeo.com/, and these benchmark sites will also trigger the popup.
Replying to mikeperry:
I have seen a couple instances of this popup personally on some sites. You can also notice the ~5 to 10X performance degradation on https://octane-benchmark.googlecode.com/svn/latest/index.html and http://dromaeo.com/, and these benchmark sites will also trigger the popup.
For what it's worth, I can confirm the "~5 to 10X performance degradation" on http://dromaeo.com/:
- JIT/etc disabled: http://dromaeo.com/?id=221958
- JIT/etc enabled: http://dromaeo.com/?id=221959
I never got the "popup", but with JIT/etc enabled the responsiveness was noticeably better, although still quite bad.
Replying to mikeperry:
I am still not sure what we should do by default. Has the helpdesk seen mail about this yet? If so, how much?
The Tails help desk received at least one complain about that. On blockchain.info:
- Login, go to send money, select shared coin, put in a amount, address, etc.
- Then hit send payment.
- It will pop up a window within that window that will process the javascript functions.
This triggers a warning that the script is unresponsive but checking the checkbox to not show it again and selecting "continue" will continue without further errors.
Just selecting continue will prompt it to load the error box again and again and again and it will not complete the process.
-
Hrmm. Ok, well we filed legacy/trac#12653 (moved) as the parent ticket for the JIT options. To get this ticket back on track, here's my current thoughts on the security slider based on iSec's input and our current contract with Giorgio for NoScript:
Low (default) - gfx.font_rendering.opentype_svg.enabled -> false Medium-Low - javascript.options.ion.content -> false - javascript.options.typeinference -> false - javascript.options.asmjs -> false - noscript.forbidMedia -> true - media.webaudio.enabled -> false - network.jar.block-remote-files -> true - mathml.disabled -> true Medium-High - javascript.options.baselinejit.content -> false - Disable JS for non HTTPS URL Bars - noscript.globalHttpsWhitelist -> true - noscript.global -> false - Disable SVG (requires new patch + pref) - gfx.font_rendering.graphite.enabled -> false High - Block remote fonts - noscript.forbidFonts -> true - Disable all JS - noscript.globalHttpsWhitelist -> false - noscript.global -> false - Disable all codecs except WebM (which is still click-to-play) - media.ogg.enabled -> false - media.opus.enabled -> false - media.wave.enabled -> false - media.apple.mp3.enabled -> false -
In terms of UI, we want this to appear in the Torbutton "Security Preferences" pane, but also possibly in the initial Tor Launcher startup dialog. Perhaps it should be a XUL binding of the same XML for each place?
Also, we need some logic that causes this UI to grey out and select a "Custom Values" radiobutton if the user changes any of these prefs from their specified values manually.
Trac:
Keywords: N/A deleted, TorBrowserTeam201408D added -
Replying to mikeperry:
In terms of UI, we want this to appear in the Torbutton "Security Preferences" pane, but also possibly in the initial Tor Launcher startup dialog.
Just in case you change your mind at some point, and want to show this only in Tor Launcher: Tails needs to have these settings available in the Torbutton prefs dialog, as we're not using Tor Launcher in the general case. Thanks!