Opened 9 months ago

Last modified 4 weeks ago

#9387 new enhancement

Tor Launcher/Torbutton should provide a "Security Slider"

Reported by: mikeperry Owned by: brade
Priority: major Milestone:
Component: Tor Launcher Version:
Keywords: tbb-security, tbb-usability, tbb-linkability, tbb-3.0, extdev-interview Cc: arma, mcs, brade, ioerror, gk, intrigeri
Actual Points: Parent ID:
Points:

Description

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.

Child Tickets

Change History (31)

comment:1 Changed 9 months ago by mikeperry

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.

comment:2 Changed 9 months ago by mikeperry

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

comment:3 in reply to: ↑ description ; follow-up: Changed 9 months ago by 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?

  • 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?)

comment:4 in reply to: ↑ 3 Changed 9 months ago by mikeperry

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.

comment:5 follow-up: Changed 9 months ago by 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?

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)?

comment:6 Changed 9 months ago by cypherpunks

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>

comment:7 in reply to: ↑ 5 Changed 9 months ago by arma

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?

comment:8 Changed 8 months ago by lunar

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?

comment:9 follow-up: Changed 8 months ago by lunar

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

comment:10 in reply to: ↑ 9 Changed 8 months ago by arma

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.

comment:11 Changed 8 months ago by arma

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.

comment:12 follow-up: Changed 8 months ago by mikeperry

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.

comment:13 Changed 8 months ago by gk

  • Cc g.koppen@… added

comment:14 in reply to: ↑ 12 Changed 8 months ago by gk

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.

comment:15 Changed 8 months ago by cypherpunks

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

comment:16 Changed 7 months ago by mikeperry

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

comment:17 Changed 6 months ago by 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.

comment:18 Changed 6 months ago by mikeperry

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..

comment:19 Changed 5 months ago by mikeperry

  • Keywords tbb-security added

comment:20 follow-up: Changed 5 months ago by 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).

comment:21 Changed 5 months ago by mikeperry

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 #10281.

comment:22 in reply to: ↑ 20 Changed 5 months ago by gk

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.

comment:23 follow-up: Changed 4 months ago by 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.)

comment:24 in reply to: ↑ 23 ; follow-up: Changed 4 months ago by arma

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.

comment:25 in reply to: ↑ 24 Changed 4 months ago by cypherpunks

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.

comment:26 Changed 3 months ago by proper

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.

comment:27 follow-up: Changed 3 months ago by brade

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.

comment:28 in reply to: ↑ 27 Changed 3 months ago by arma

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.)

comment:29 Changed 3 months ago by mikeperry

  • Keywords extdev-interview added

comment:30 Changed 4 weeks ago by intrigeri

  • Cc intrigeri@… added

comment:31 Changed 4 weeks ago by arma

  • Cc gk intrigeri added; g.koppen@… intrigeri@… removed
Note: See TracTickets for help on using tickets.