Opened 21 months ago

Closed 4 weeks ago

#9387 closed enhancement (fixed)

Tor Launcher/Torbutton should provide a "Security Slider"

Reported by: mikeperry Owned by: gk
Priority: major Milestone:
Component: Tor Launcher Version:
Keywords: tbb-security, tbb-usability, tbb-linkability, tbb-3.0, extdev-interview, tbb-isec-report, tbb-4.5-alpha, TorBrowserTeam201503 Cc: arma, mcs, brade, ioerror, gk, intrigeri, tom@…, isis
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

TicketTypeStatusOwnerSummary
#12430enhancementclosedtbb-teamDisable the jar: protocol for external resources via preference
#12827enhancementclosedmcsCreate preference to disable SVG
#13053taskclosedboklmWrite regression tests for new NoScript options
#13548enhancementclosedmcsCreate preference to disable MathML
#13682taskclosedtbb-teamWrite test for security slider
#15225taskclosedtbb-teamInvestigate why Atlas does not work with the medium-high security slider setting

Attachments (2)

bug9387-patch.txt (3.0 KB) - added by mcs 4 weeks ago.
misc fixes
torbutton-1.9.1.0-dev.xpi (1.2 MB) - added by mikeperry 4 weeks ago.
Torbutton with Security Slider v0.9 (from git commit 430ccaa1596e03e3ea0a36c51c4623fe8ff67d52) - English Only

Download all attachments as: .zip

Change History (105)

comment:1 Changed 21 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 21 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 21 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 21 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 21 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 21 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 21 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 21 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 21 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 20 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 20 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 20 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 20 months ago by gk

  • Cc g.koppen@… added

comment:14 in reply to: ↑ 12 Changed 20 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 20 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 19 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 follow-up: Changed 18 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 18 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 17 months ago by mikeperry

  • Keywords tbb-security added

comment:20 follow-up: Changed 17 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 17 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 17 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 16 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 16 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 16 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 15 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 15 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 15 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 15 months ago by mikeperry

  • Keywords extdev-interview added

comment:30 Changed 13 months ago by intrigeri

  • Cc intrigeri@… added

comment:31 Changed 13 months ago by arma

  • Cc gk intrigeri added; g.koppen@… intrigeri@… removed

comment:32 in reply to: ↑ 17 Changed 12 months ago by lunar

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

comment:33 follow-up: Changed 11 months ago by T(A)ILS developers

Dear TBB team, what are your plans for the next stable release regarding these issues?

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.

comment:34 follow-ups: Changed 11 months ago by mikeperry

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?

comment:35 in reply to: ↑ 34 Changed 11 months ago by lunar

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

comment:36 Changed 11 months ago by tom

  • Cc tom@… added

comment:37 in reply to: ↑ 33 Changed 11 months ago by T(A)ILS developers

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

comment:38 follow-up: Changed 11 months ago by 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. Given that we almost have ASAN builds (#10599) 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.

comment:39 in reply to: ↑ 38 ; follow-up: Changed 11 months ago by 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.

comment:40 in reply to: ↑ 39 ; follow-up: Changed 11 months ago by mikeperry

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.

comment:41 in reply to: ↑ 40 Changed 11 months ago by T(A)ILS developers

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/:

I never got the "popup", but with JIT/etc enabled the responsiveness was noticeably better, although still quite bad.

comment:42 in reply to: ↑ 34 Changed 10 months ago by T(A)ILS developers

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.

comment:43 Changed 9 months ago by mikeperry

Hrmm. Ok, well we filed #12653 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 
Last edited 4 weeks ago by gk (previous) (diff)

comment:44 follow-ups: Changed 9 months ago by mikeperry

  • Keywords TorBrowserTeam201408D added

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.

comment:45 Changed 9 months ago by mikeperry

  • Owner changed from brade to gk
  • Status changed from new to assigned

comment:46 Changed 8 months ago by mikeperry

  • Keywords isec-audit added

comment:47 Changed 8 months ago by mikeperry

  • Keywords tbb-isec-report added; isec-audit removed

comment:48 in reply to: ↑ 44 Changed 8 months ago by intrigeri

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!

comment:49 Changed 8 months ago by cypherpunks

It might be a good idea to block iframes as well since they also are a security risk. One way to do this is to set noscript.forbidIFramesContext to 0 and noscript.forbidIFrames to true in about:config. This preference could then be placed in the high setting.

comment:50 Changed 8 months ago by mikeperry

mttp notes that this UI should contain a brief description for each position. Perhaps a textbox below the slider that tries to explain what the slider disables at that position, any why it reduces risk/vulnerability count?

comment:51 Changed 8 months ago by mikeperry

  • Keywords TorBrowserTeam201410D added; TorBrowserTeam201408D removed

gk - Setting this as October, but don't let that stop you from working on it if you are bored/compelled/obsessed with working on it while you wait for builds or whatever.

comment:52 in reply to: ↑ 44 ; follow-up: Changed 6 months ago by gk

  • Keywords MikePerry2010R added
  • Status changed from assigned to needs_information

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. Perhaps it should be a XUL binding of the same XML for each place?

I am not convinced yet that we want the UI in the (initial) startup dialog, too given that we already have three dialogs and this is already confusing to users. I have therefore put the slider into the Torbutton preferences pane. I renamed it slightly to make the distinction between the now different types of settings on that pane more clear (we have now privacy and security (in a narrower sense) related settings there).

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.

Yes, I think a custom values checkbox is good. I already added one (which is hidden by default as the slider is active) but am still thinking about its exact behavior. E.g. do we already have custom settings if the user changes a slider-related preference belonging to a security level which is currently *not* chosen? I am a bit torn here and am not sure what users are expecting.

That said the slider should be working with the following pieces still missing:

-functioning custom checkbox
-tooltips/help buttons explaining the security levels
-preferences for disabling SVG and MathML (#12827 and #13548)

I have not checked yet how hard it is to whip up preferences for #12827 and #13548. Anyway, the code is in my public Torbutton repo in bug_9387_test_01. Feedback is much appreciated.

comment:53 in reply to: ↑ 52 Changed 6 months ago by gk

Replying to gk:

Yes, I think a custom values checkbox is good. I already added one (which is hidden by default as the slider is active) but am still thinking about its exact behavior. E.g. do we already have custom settings if the user changes a slider-related preference belonging to a security level which is currently *not* chosen? I am a bit torn here and am not sure what users are expecting.

To answer my own question: "Yes, we do." as the user is even then not anymore in one of the 4 user partitions made by the security slider. Thus, this means we need to take all preferences governed by the security slider into account when determining whether the user is in the "custom settings" group. I think showing a warning dialog might be good as well (with the option to turn it off) if a user changes one of these preferences just in case this happened accidentally.

comment:54 Changed 6 months ago by gk

  • Keywords MikePerry201410R added; MikePerry2010R removed

comment:55 Changed 6 months ago by mikeperry

  • Keywords tbb-4.5-alpha added

comment:56 follow-up: Changed 6 months ago by mikeperry

gk - I noticed a bug with noscript.globalHTTPSWhitelist. It seems that it improperly blocks some elements in https pages unless https: is also added to the NoScript whitelist. I notified Giorgio about this bug, but he has not fixed it yet. We may want to add "https:" to the NoScript pref capability.policy.maonoscript.sites as a workaround until this is fixed.

I think that with noscript.cascadePermissions and noscript.cascadePermissions, having https: in the whitelist still does not allow scripts if the url bar is http, but we should also verify this.

comment:57 in reply to: ↑ 56 ; follow-up: Changed 6 months ago by gk

Replying to mikeperry:

gk - I noticed a bug with noscript.globalHTTPSWhitelist. It seems that it improperly blocks some elements in https pages unless https: is also added to the NoScript whitelist. I notified Giorgio about this bug, but he has not fixed it yet. We may want to add "https:" to the NoScript pref capability.policy.maonoscript.sites as a workaround until this is fixed.

Ok. This actually means adding " https:" just to case 1-3? The first two levels leave the NoScript JS related prefs alone but are affected by this bug, too, and the fourth level is locking down all JS, so this isn't needed there. I am in fact quite confused about these related NoScript JS prefs: noscript.globalHTTPSWhitelist is supposed to be noscript.globalHttpsWhitelist, right? And

Disable JS for non HTTPS URL Bars -> noscript.globalHTTPSWhitelist

in comment:43 is supposed to be

Disable JS for non HTTPS URL Bars -> noscript.allowHttpsOnly

or am I missing something? How is noscript.globalHttpsWhitelist set in mode 1-3? Assuming we only disable it in mode 4 I guess we enable it in them?

I think that with noscript.cascadePermissions and noscript.cascadePermissions, having https: in the whitelist still does not allow scripts if the url bar is http, but we should also verify this.

Okay, needs still to be done.

Last edited 6 months ago by gk (previous) (diff)

comment:58 in reply to: ↑ 57 ; follow-up: Changed 6 months ago by mikeperry

Replying to gk:

Replying to mikeperry:

gk - I noticed a bug with noscript.globalHTTPSWhitelist. It seems that it improperly blocks some elements in https pages unless https: is also added to the NoScript whitelist. I notified Giorgio about this bug, but he has not fixed it yet. We may want to add "https:" to the NoScript pref capability.policy.maonoscript.sites as a workaround until this is fixed.

Ok. This actually means adding " https:" just to case 1-3? The first two levels leave the NoScript JS related prefs alone but are affected by this bug, too, and the fourth level is locking down all JS, so this isn't needed there. I am in fact quite confused about these related NoScript JS prefs: noscript.globalHTTPSWhitelist is supposed to be noscript.globalHttpsWhitelist, right? And

Disable JS for non HTTPS URL Bars -> noscript.globalHTTPSWhitelist

in comment:43 is supposed to be

Disable JS for non HTTPS URL Bars -> noscript.allowHttpsOnly

or am I missing something? How is noscript.globalHttpsWhitelist set in mode 1-3? Assuming we only disable it in mode 4 I guess we enable it in them?

Well, I don't think noscript.allowHttpsOnly exists. We want noscript.globalHttpsWhitelist to be set only in mode 3. In that mode, we also want https: in the whitelist (capability.policy.maonoscript.sites).

In modes 1, 2, and 4 we want noscript.globalHttpsWhitelist unset. We also want 'https:' removed from capability.policy.maonoscript.sites in these modes.

I will update the summary in comment:43.

comment:59 in reply to: ↑ 58 Changed 6 months ago by gk

Replying to mikeperry:

Well, I don't think noscript.allowHttpsOnly exists.

Well, take a look at a vanilla NoScript .xpi and you'll find it in the preferences file which it includes.

We want noscript.globalHttpsWhitelist to be set only in mode 3. In that mode, we also want https: in the whitelist (capability.policy.maonoscript.sites).

In modes 1, 2, and 4 we want noscript.globalHttpsWhitelist unset. We also want 'https:' removed from capability.policy.maonoscript.sites in these modes.

I will update the summary in comment:43.

Okay, I think I've addressed this issue and a working checkbox/custom mode is contained in bug_9387_test_02 as well. What is still missing is:

-tooltips/help buttons explaining the security levels
-preferences for disabling SVG and MathML (#12827 and #13548)
-the test mentioned in comment:57
-thinking about some custom settings corner cases (Should they be preserved during New Identity? Should they be reset during start-up?)

comment:60 Changed 6 months ago by isis

  • Cc isis added

comment:61 follow-up: Changed 5 months ago by mcs

Nice work! A few UI comments based on my experience with 4.5-alpha-1 (build 1) on Mac OS:

  • We need to make this easier to find. At a minimum, the "Privacy and Security Settings" should be selected when the Torbutton Preferences window is first opened. But I still think this should be presented at first run of the browser.
  • The slider UI is nice. Hints as to what the settings actually do are definitely a "must have"; otherwise, users have no idea what the tradeoffs are among the different settings. Maybe provide a very short explanation next to each slider position and place a larger text box below that displays a fuller explanation that changes as you change positions? Experimentation is needed.
  • I want to be able to click the text to switch slider positions. I'd categorize this as "nice to have."

That's all for now.

comment:62 Changed 5 months ago by gk

ln5 noted that greying the checkbox out instead of making it disappear might be preferable from a UX point .

comment:63 Changed 5 months ago by T(A)ILS developers

  • Cc tails@… added

comment:64 Changed 5 months ago by T(A)ILS developers

  • Cc tails@… removed

comment:65 in reply to: ↑ 61 Changed 5 months ago by gk

Replying to mcs:

Nice work! A few UI comments based on my experience with 4.5-alpha-1 (build 1) on Mac OS:

  • We need to make this easier to find. At a minimum, the "Privacy and Security Settings" should be selected when the Torbutton Preferences window is first opened. But I still think this should be presented at first run of the browser.

Selecting it first sounds good to me. But I am still torn wrt showing this on start-up and how. E.g. if we show the slider and maybe explaining things I bet users get scared as the slider is by default on "Low" (and, honestly, who wants to have LOW security, everybody wants to have HIGH security). So, what I expect to happen is a lot of people putting the slider to "High" forget about it and start complaining why the web is broken. This might, of course, just indicate that our wording is bad regardless where the slider gets shown but having sane defaults and having the slider for people who want to "tune" their experience while not exposing themselves too much wrt fingerprintability seems to me a good way to go. And for this model we might not need yet another dialog on start-up.

  • The slider UI is nice. Hints as to what the settings actually do are definitely a "must have"; otherwise, users have no idea what the tradeoffs are among the different settings. Maybe provide a very short explanation next to each slider position and place a larger text box below that displays a fuller explanation that changes as you change positions? Experimentation is needed.

Yes, we need definitely add something along these lines.

  • I want to be able to click the text to switch slider positions. I'd categorize this as "nice to have."

Good idea.

comment:66 Changed 5 months ago by gk

  • Keywords TorBrowserTeam201412R added; MikePerry201410R removed
  • Status changed from needs_information to needs_review

bug_9387_test_03 has some of the feedback included. mcs, brade: it would be nice if you could have a look at it so we get it into 4.5-alpha-2, too.

comment:67 follow-up: Changed 5 months ago by mcs

Kathy and I reviewed these changes. They look good. One more idea for the future: disable (show as gray text) the descriptions when the slider itself is disabled.

comment:68 in reply to: ↑ 67 Changed 4 months ago by gk

  • Status changed from needs_review to new

Replying to mcs:

Kathy and I reviewed these changes. They look good. One more idea for the future: disable (show as gray text) the descriptions when the slider itself is disabled.

Thanks. So, what is still needed for the next iteration(s) is:

-tooltips/help buttons explaining the security levels
-preferences for disabling SVG and MathML (#12827 and #13548)
-the test mentioned in comment:57
-disable descriptions if the slider itself is disabled
-think about ways to get the slider found easier
-think about ways to warn the user about messing with slider related preferences directly (maybe a dialog with a checkbox to turn it off?)

comment:69 Changed 4 months ago by gk

  • Keywords TorBrowserTeam201412R removed

comment:70 Changed 4 months ago by mikeperry

While testing 4.5-alpha-2 in various security levels, I noticed a few issues:

  1. The Medium-High security level causes "Custom settings" to get checked if you do "New Identity" and have disk records disabled (ie the default TBB). It doesn't seem to do this if you allow disk records (which may be why you missed this bug).
  2. Unchecking "Custom settings" doesn't seem to take effect until "New Identity", especially if you change NoScript state manually.
  3. The Medium-High security level seems to fail to disable javascript for HTTP sites (it should set set noscript.global to false and rely on noscript.globalHttpsWhiteList).
  4. We probably should move our new JIT defaults into the TBB repo.
  5. NoScript 2.6.9.8rc1 was just released which fixes the need for the https: whitelist injection. We should remove this injection as soon as we switch to this NoScript.

I also have the following UI/UX comments:

  1. We should hint somewhere that this is a tradeoff between features and security. Perhaps changing "Security Level" to "Security Level (Disables high-risk web features to improve security)" or similar?
  2. Alternatively, or in addition, we could have the levels also include "(Most Usable)" down to "(Least Usable)", or perhaps "(Full Features)" down to "(Least Features)"
  3. I think the slider should be horizontal. It's taking up a lot of window real estate in a way that only makes sense if we have huge volumes of text describing the positions. I think tooltips will suffice instead of a side-bar, which means we can make this more compact.
  4. If it were horizontal, we can maybe also include it in one of the Tor Launcher windows without overload.
  5. If we stay with a vertical slider, why is "High" on the bottom? This ordering only makes sense if we also say "(Most Usable)" or "(Most Features)" I think.

comment:71 Changed 4 months ago by SpencerOne

Hey y'all, here are some of my thoughts. I used my own terms here, made up on the spot, but please make me use yours if mine complicate the discussion.

After reading the ongoing discussion, here are my two Satoshi:

  1. Splitting the JavaScript allowances between allowance setting positions on the slider could be confusing for people. It requires explaining what JavaScript is and what it does in detail, that is, presuming that explaining the settings in detail is necessary, and I think we are on the same page in thinking that it is. Alternatively, we can not explain the settings in detail, though that leaves people unclear as to what is actually happening, e.g., some JS is disabled/all JS is disabled, doesn't explain much.
  1. However, whatever the number of allowance settings, and four seems to be the path forward from here, the details [what people see] should be written in human, not computer. Though maybe that could be toggled for those who prefer one or the other.
  1. Regarding a 'Custom' allowance setting on the slider itself, that makes things a bit confusing. The slider could be the foremost front-end allowance settings option, inherently likening 'Custom' to 'Advanced'.
  1. I agree that the allowance settings interface just after install should be the allowance settings interface in 'Preferences', as an attempt to lessen visual and mental fragmentation.
  1. The tool tips for allowance setting positions are cool, but are hidden for most people. The always-on text for descriptions is better for full understanding of options/decisions, but takes up space. The always-on text for descriptions that is only visible at each allowance setting position fits in the middle of these two options but requires work, clicking and whatnot. Maybe, in addition to this middle option, the other unselected allowance setting position descriptions appear on hover, or in place, of the always-on text, as an alternative to grayed-out.

After reviewing TB 4.5 Alpha 2 [Mac]:

  1. Setting security preferences could be a prompt in the second dialog, considering the first is the drag-to install dialog. I see benefit in not forcing people to make such decisions right away, but people are using TB for a reason, so maybe it can be expected.
  1. 'Cookie Protections' seems like a preference. What is cookie protection, IDK, so maybe this is an advanced setting.
  1. 'Proxy Settings' could be second after 'Privacy and Security Settings', however, 'Proxy Settings' seems like an advanced setting, maybe simplifying the experience for many people.
  1. 'Privacy Settings' and 'Security Level' could use some explaining. I would like to think that I am securing my data with the security settings, or, in other words, securing my privacy. Semantics could be important here. Are we only securing our anonymity?
  1. I am all for the vertical slider, given the varying lengths in allowance setting position labels. We could move allowance setting position labels to the left of the slider with descriptions to the right. If we're only showing the current/selected allowance setting position description, this provides plenty of space for a more detailed explanation.

Questions:

  1. Is there a visual flow of the dialogs and what they contain, or is it all in development text archives?
  1. Is there an outlet for visuals, like wireframes?
  1. Does there have to be a "tradeoff between features and security"? It is a big bite to take, but, can alternatives be written as stand-ins to replace the vulnerable features?
Last edited 4 months ago by SpencerOne (previous) (diff)

comment:72 follow-up: Changed 3 months ago by arma

Here's another vote for making the slider easier to find -- in particular, if the user wants to not run javascript, then we need to make it likely that she will be able to set this before loading any pages.

My original vision had been for it to be on the "connect or configure" screen -- I thought of it less as a configuration option and more of a "what type of user are you" option. But I grant that the tradeoff there is that soon we'll want to put everything on that initial screen.

While I'm at it: I wonder if we should have a phrase like "better usability" go with "low security", and a phrase like "lower usability" or "breaks some browser functionality" to go with "high security". As it is now, of course we all should want higher security, since there's no downside, right?

comment:73 Changed 2 months ago by mikeperry

  • Keywords TorBrowserTeam201502 added; TorBrowserTeam201410D removed

comment:74 follow-up: Changed 2 months ago by gk

mikeperry: This is the comment to commit 7975b2023d5dc9bc0437cb5d5fbfe539448900e4: Originally, I had a similar idea but just looking at the particular security level and binding the custom pref to it is wrong I think. We need to think about the custom setting being bound to the *whole* slider instead. And here is why: Level 4 (or "high") is not only about setting the preferences in the High section in comment:43 but rather all the preferences in Low-Medium/Low-Medium/High must be set accordingly as well in order to guarantee the full protection AND making sure there are only 4 partitions of users if they stick to the slider and don't prefer custom settings. Or take the default mode: if one selects the default mode but disables JavaScript then first of all this is no default mode anymore even if no particular preference in that mode is changed. Doing this is pretty dangerous as we could easily get some users that are in default mode but have JavaScript disabled and some that are in that mode but have it enabled. And then maybe some that have media.audio.enabled and some not, leading to a much larger partition than is good for our users.

Hence just the check if any of the security slider related preferences got touched. If so, AND we are not in custom mode, set the custom checkbox. The only way to set it back currently is via the Torbutton menu. We could think about an additional option: if the user manages it to manually set all the security slider related preferences back to their respective values (which is depending on the current slider level) then uncheck the custom checkbox as well.

Still guessing at the meaning of the comment a bit: m_tb_sliderUpdate is only set if we set the slider level on the Torbutton dialog which is only possible if the custom checkbox is unchecked. Thus, the reasoning was if we get the notification AND m_tb_sliderUpdate is not set AND we are not in custom mode we can just set it without checking the value of any pref.

Last edited 2 months ago by gk (previous) (diff)

comment:75 in reply to: ↑ 72 Changed 2 months ago by gk

Replying to arma:

Here's another vote for making the slider easier to find -- in particular, if the user wants to not run javascript, then we need to make it likely that she will be able to set this before loading any pages.

My original vision had been for it to be on the "connect or configure" screen -- I thought of it less as a configuration option and more of a "what type of user are you" option. But I grant that the tradeoff there is that soon we'll want to put everything on that initial screen.

Yes, I think we want to expose the slider more prominently. I am still not sure how and am concentrating meanwhile on the one in the Torbutton settings. Mike's idea of having a horizontal slider is probably not working as the slider labels are not fitting there without overlapping which gives a crappy user experience. Apart from that do I have the feeling that a slider is somehow tied to something being vertically (but that might be just me)...

While I'm at it: I wonder if we should have a phrase like "better usability" go with "low security", and a phrase like "lower usability" or "breaks some browser functionality" to go with "high security".

Yes, that part will be available in one of the next slider revisions.

comment:76 in reply to: ↑ 74 ; follow-up: Changed 2 months ago by mikeperry

Replying to gk:

mikeperry: This is the comment to commit 7975b2023d5dc9bc0437cb5d5fbfe539448900e4: Originally, I had a similar idea but just looking at the particular security level and binding the custom pref to it is wrong I think. We need to think about the custom setting being bound to the *whole* slider instead. And here is why: Level 4 (or "high") is not only about setting the preferences in the High section in comment:43 but rather all the preferences in Low-Medium/Low-Medium/High must be set accordingly as well in order to guarantee the full protection AND making sure there are only 4 partitions of users if they stick to the slider and don't prefer custom settings. Or take the default mode: if one selects the default mode but disables JavaScript then first of all this is no default mode anymore even if no particular preference in that mode is changed. Doing this is pretty dangerous as we could easily get some users that are in default mode but have JavaScript disabled and some that are in that mode but have it enabled. And then maybe some that have media.audio.enabled and some not, leading to a much larger partition than is good for our users.

Hence just the check if any of the security slider related preferences got touched. If so, AND we are not in custom mode, set the custom checkbox. The only way to set it back currently is via the Torbutton menu. We could think about an additional option: if the user manages it to manually set all the security slider related preferences back to their respective values (which is depending on the current slider level) then uncheck the custom checkbox as well.

Still guessing at the meaning of the comment a bit: m_tb_sliderUpdate is only set if we set the slider level on the Torbutton dialog which is only possible if the custom checkbox is unchecked. Thus, the reasoning was if we get the notification AND m_tb_sliderUpdate is not set AND we are not in custom mode we can just set it without checking the value of any pref.

Well, the way I use the slider in the high position is as a default state. I frequently temporarily allow many sites via NoScript, and sometimes if a site needs to perform many redirects, I globally enable script permissions for a bit, and then disable them later. I think it is this global script enable that is causing my slider to get stuck in the "Custom" position.

So, in my opinion, this means two things:

  1. I think that the slider should recognize that when I globally disable scripts again, "Custom" should become unchecked. Really, I think this should be the case for all of our prefs, but globally enabling/disabling JS is facilitated by our NoScript UI (for good reason) and may be common.
  2. I think the slider shouldn't actually become locked if "Custom" is set. I should be able to drag it and go back to one of the official positions, which would uncheck "Custom" and reset all the prefs appropriately.

comment:77 in reply to: ↑ 76 Changed 2 months ago by gk

Replying to mikeperry:

Well, the way I use the slider in the high position is as a default state. I frequently temporarily allow many sites via NoScript, and sometimes if a site needs to perform many redirects, I globally enable script permissions for a bit, and then disable them later. I think it is this global script enable that is causing my slider to get stuck in the "Custom" position.

So, in my opinion, this means two things:

  1. I think that the slider should recognize that when I globally disable scripts again, "Custom" should become unchecked. Really, I think this should be the case for all of our prefs, but globally enabling/disabling JS is facilitated by our NoScript UI (for good reason) and may be common.
  2. I think the slider shouldn't actually become locked if "Custom" is set. I should be able to drag it and go back to one of the official positions, which would uncheck "Custom" and reset all the prefs appropriately.

Okay, bug_9387_13998 in my Torbutton repo has the fix for both of your issues while still taking my concerns into account. An updated Mozmill test for it is needed and coming.

comment:78 Changed 2 months ago by mikeperry

  • Keywords MikePerry201502R added

comment:79 Changed 2 months ago by mikeperry

Ok, I tested and merged bug_9387_13998. It seems good for now. Though, I would prefer to nail down this UI (especially the strings) before the 4.5a4, but that may be unlikely at this point.

comment:80 Changed 2 months ago by mikeperry

  • Keywords MikePerry201502R removed

comment:81 Changed 7 weeks ago by mikeperry

  • Keywords TorBrowserTeam201503 added; TorBrowserTeam201502 removed

comment:82 Changed 6 weeks ago by mikeperry

GK and I spent some time discussing strings for each position. Our plan is to create a set of vbox's, one for each position, and hide all of them except for the relevant one. Each vbox will have some set of DTD elements describing the features of that position of the slider, as well as tooltips to describe technical details for some options. Tooltips are in brackets. Roughly each line/bullet point will correspond to a separate DTD element.

======= Low ===========

At this security level, all browser features are enabled.

This is the most usable experience.

======= Medium-Low ===========

At this security level, the following changes apply:

* HTML5 video and audio media become click-to-play via NoScript.
* Some Javacript performance optimizations are disabled.
  Scripts on some sites may run slower.
  [ION JIT, Type Inference, ASM.JS]
* Some mechanisms of displaying math equations are disabled.
  [MathML]

======= Medium-High ===============

At this security level, the following changes apply:

* HTML5 video and audio media become click-to-play via NoScript.
* All Javacript performance optimizations are disabled.
  Scripts on some sites may run slower.
* Some mechanisms of displaying math equations are disabled.
  [MathML]
* Some font rendering features are disabled.
  [The Graphite font rendering mechanism is disabled]
* Some types of images will be disabled.
  [SVG images fonts are disabled]
* Javascript is disabled by default on all non-HTTPS sites.
  (Javascript can be enabled on a per-site basis via the NoScript toolbar button).

======= High ==========

At this security level, the following changes apply:

* HTML5 video and audio media become click-to-play via NoScript.
* All Javacript performance optimizations are disabled.
  Scripts on some sites may run slower.
* Some mechanisms of displaying math equations are disabled.
  [MathML]
* Some font rendering features are disabled.
  [The Graphite font rendering mechanism is disabled]
* Some types of images will be disabled.
  [SVG images fonts are disabled]
* Javascript is disabled by default on all sites.
  (Javascript can be enabled on a per-site basis via the NoScript toolbar button).
* Most audio and video formats are disabled.
  [WebM is the only codec that remains enabled]
* Some fonts and icons may display incorrectly.
  [Website-provided font files are blocked]

comment:83 follow-up: Changed 6 weeks ago by mcs

The text will be very helpful. Maybe we can also display the text (minus the tooltips) as a tooltip or popup when the user mouses over the labels. That way they can see what a setting will do without actually moving the slider.

comment:84 in reply to: ↑ 83 Changed 4 weeks ago by gk

  • Status changed from new to needs_review

Replying to mcs:

The text will be very helpful. Maybe we can also display the text (minus the tooltips) as a tooltip or popup when the user mouses over the labels. That way they can see what a setting will do without actually moving the slider.

Good idea. I implemented it as tooltips.

bug_9387_v7 (https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_9387_v7&id=856de1a377ab4e1c63b2605f04cbffaff25c83d5) in my public Torbutton repo has the fix for the lacking slider settings descriptions. One small thing I am not happy about is the possible tiny misalignment of the slider position label and the slider thumb. Mozilla did not implement a natural way of showing a label yet (see: https://wiki.mozilla.org/XUL:Slider_Tag for the idea). I tested on different Windows and Linux systems and OS X 10.6.8 and I think we can live with that for now especially as getting that properly done from extension land might be not easy.

It turned out we forgot some strings in our descriptions in comment:82. I adjusted the things in comment:43 which reflects the implementation in bug_9387_v7 now. I folded the MathML related work done in #13548 into it. Let me know if anything does not make sense.

Last edited 4 weeks ago by gk (previous) (diff)

comment:85 Changed 4 weeks ago by gk

Lunar came up with the idea to show the user on first start a notification (just when the browser window came up and no modal dialog) that there is the option now to choose between different security levels. I think I am implementing this idea as we don't want to hide the slider away from non-expert users that are not familiar working with deeply buried settings.

Last edited 4 weeks ago by gk (previous) (diff)

comment:86 follow-up: Changed 4 weeks ago by lunar

The vision I had was to add something on the “about:tor” page. E.g.

Current security level: low (compatible with most websites)
          What is it?

Clicking “current security level” would bring you to the slider panel where the level can be adjusted. Clicking “what is it?” would open a page from the manual.

comment:87 in reply to: ↑ 86 ; follow-up: Changed 4 weeks ago by gk

Replying to lunar:

The vision I had was to add something on the “about:tor” page. E.g.

Current security level: low (compatible with most websites)
          What is it?

Clicking “current security level” would bring you to the slider panel where the level can be adjusted. Clicking “what is it?” would open a page from the manual.

Ah, then I misunderstood you. I like the idea but still think we might want to give users some more obvious hints about the new feature (in addition) (and I don't want to have things flashing on about:tor). I fear they are just overlooking the links you have in mind otherwise. But I don't have a strong opinion and could live with both ideas. Thoughts?

comment:88 Changed 4 weeks ago by mikeperry

Instead of doing a revision request and burning a day or more on the round trips for that, I made some changes to this in https://gitweb.torproject.org/mikeperry/torbutton.git/log/?h=bug_9387_v8.

That branch has one commit per logical change and I tried to explain and motivate each change in the commit message. Let me know if anything is unclear or you disagree with any of those changes.

comment:89 follow-up: Changed 4 weeks ago by mikeperry

Two more things that I may or may not have time to fix in that branch today:

  1. If you change the slider position using the keyboard (ie the up/down keys), the description text doesn't update.
  2. It would be nice if we could indicate which items have tooltips somehow. Maybe we can put the tooltip on some kind of "?" icon instead of on the actual description field.

If I fix either of these, I will add commits to that bug_9387_v8 branch in my remote.

comment:90 in reply to: ↑ 87 ; follow-up: Changed 4 weeks ago by mikeperry

Replying to gk:

Replying to lunar:

The vision I had was to add something on the “about:tor” page. E.g.

Current security level: low (compatible with most websites)
          What is it?

Clicking “current security level” would bring you to the slider panel where the level can be adjusted. Clicking “what is it?” would open a page from the manual.

Ah, then I misunderstood you. I like the idea but still think we might want to give users some more obvious hints about the new feature (in addition) (and I don't want to have things flashing on about:tor). I fear they are just overlooking the links you have in mind otherwise. But I don't have a strong opinion and could live with both ideas. Thoughts?

I think about:tor is an OK place to show the current security level, but we want to avoid making about:tor too busy. It's already getting pretty densely packed with stuff.

How about this in addition/instead: A lot of stuff has changed in the Torbutton menu. Perhaps it would be good to display a one-time ribbon (as in under the URL toolbar) that tells people that the green onion menu has lots of new features, including new security settings, and a new Tor Circuit Status display while websites are live.

The one challenging bit about a ribbon notification that describes the new Torbutton menu is that the circuit status display won't be active until the user navigates to a website. So perhaps we don't display the ribbon until a site loads? But then, at that point, they may already be occupied with what they are trying to accomplish, and may ignore the ribbon...

comment:91 in reply to: ↑ 90 Changed 4 weeks ago by intrigeri

Replying to mikeperry:

Perhaps it would be good to display a one-time ribbon (as in under the URL toolbar) that tells people that the green onion menu has lots of new features, including new security settings, and a new Tor Circuit Status display while websites are live.

I agree a one-time ribbon is the best way to notify users about it. Better, it's in line with current GNOME HIG.

Now, I would appreciate it if a pref allowed to disable this one-time ribbon, or if it was only displayed post-upgrades: otherwise, Tails users will see it every time they boot Tails and start Tor Browser, which would be a bit annoying.

comment:92 follow-up: Changed 4 weeks ago by mcs

Kathy and I experimented with the code on Mike's branch. This is looking quite good! Here are a few things we observed:

  1. Clicking a label sets the wrong slider position (fallout from reversing the positions).
  1. We found that the alignment of the labels to the slider positions can be improved by removing flex from the first <description> hbox (to get more of a 1/3, 1/3, 1/3 split).
  1. On a Ubuntu 14.04 system, the height of the preferences window and slider changed when we switched to the Medium-High and High slider positions (the help text is too tall and/or the area for it is too narrow). It is OK but kind of a weird experience (and maybe it only happens on some systems).

We have a patch for issues 1 and 2 which I will attach in a moment.

comment:93 in reply to: ↑ 89 Changed 4 weeks ago by gk

Replying to mikeperry:

Two more things that I may or may not have time to fix in that branch today:

  1. If you change the slider position using the keyboard (ie the up/down keys), the description text doesn't update.
  2. It would be nice if we could indicate which items have tooltips somehow. Maybe we can put the tooltip on some kind of "?" icon instead of on the actual description field.

If I fix either of these, I will add commits to that bug_9387_v8 branch in my remote.

I think I've fixed both of these issues in my bug_9387_v9 (see: https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_9387_v9). Maybe we want to have something better for issue 2, though (I can live with my "solution"). I just added a blue "?" within the description tag which gives the user the hint there is more information. Showing the tooltip *only* while hovering over the question mark seems to be a bit trickier than thought: Having a separate box for the "?" breaks the line-wrapping of the description text and using title in the HTML tag does not work within XUL. I *could* overcome this problem following http://www.texsoft.it/index.php?c=software&m=sw.js.htmltooltip (I remember going this road for a different project) but that seemed a bit too heavyweight to me.

Changed 4 weeks ago by mcs

misc fixes

comment:94 in reply to: ↑ 92 ; follow-up: Changed 4 weeks ago by gk

Replying to mcs:

Kathy and I experimented with the code on Mike's branch. This is looking quite good! Here are a few things we observed:

  1. Clicking a label sets the wrong slider position (fallout from reversing the positions).
  1. We found that the alignment of the labels to the slider positions can be improved by removing flex from the first <description> hbox (to get more of a 1/3, 1/3, 1/3 split).
  1. On a Ubuntu 14.04 system, the height of the preferences window and slider changed when we switched to the Medium-High and High slider positions (the help text is too tall and/or the area for it is too narrow). It is OK but kind of a weird experience (and maybe it only happens on some systems).

We have a patch for issues 1 and 2 which I will attach in a moment.

Thanks, 1) is fixed in v9. I tried the fix for 2) and it has actually only negative effects on all my Linux boxes I tested. As I said originally, there is probably not much we can do without having a patch in Mozilla itself. Re 3): Yes, but fixing the size risks that some translation strings are not properly visible which is why I chose this way. If there is something better we can do I am all for it.

Last edited 4 weeks ago by gk (previous) (diff)

comment:95 in reply to: ↑ 94 Changed 4 weeks ago by mcs

Replying to gk:

Thanks, 1) is fixed in v9. I tried the fix for 2) and it has actually only negative effects on all my Linux boxes I tested. As I said originally, there is probably not much we can do without having a patch in Mozilla itself.

Thanks for trying our patch. It is a shame that platform differences make it unusable, but the slider is OK as-is; the alignment issue is just a visual annoyance.

Re 3): Yes, but fixing the size risks that some translation strings are not properly visible which is why I chose this way. If there is something better we can do I am all for it.

We will think about it and maybe experiment more if we have time. But this is also not a show stopper.

comment:96 follow-up: Changed 4 weeks ago by mikeperry

Hrmm. I think the blue question marks as text without an icon were just making us look confused, as if we didn't know what our own UI was supposed to be doing. :/

In mikeperry/bug_9387_v10, I removed them and changed the bold sentence at the top to encourage mouseover instead, and made sure every option has a mouseover: https://gitweb.torproject.org/mikeperry/torbutton.git/log/?h=bug_9387_v10

If you like this version, or even if you make some minor tweaks, I think you should just push it to master ASAP, so that the strings are available for translation for the weekend.

comment:97 in reply to: ↑ 96 Changed 4 weeks ago by gk

Replying to mikeperry:

If you like this version, or even if you make some minor tweaks, I think you should just push it to master ASAP, so that the strings are available for translation for the weekend.

Commit 35970c68d6af10fdec19189aae64d76e048acc4e has basically your version.

comment:98 Changed 4 weeks ago by gk

I could not convince myself yet to advertize the whole new menu structure due to the issues you mentioned in comment:90. Thus, I started with just pointing to the new security slider via a notification box (frankly, I was not sure what "ribbon" means in this context). I could imagine using a doorhanger notification as well here but feel not very strongly about that. See: bug_9387_v11 for things to review (https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_9387_v11).

comment:99 Changed 4 weeks ago by mikeperry

This is fantastic! I pushed that branch to master. Very exciting to see this in what looks like a shippable form to me! I think now all we have to do is add the svg pref, and we can call this 1.0 and close this bug!

intregeri - there is also a pref for you: extensions.torbutton.show_slider_notification.

Incidentally, the use of the "ribbon" term was my braindamage. I meant a notification box, just like this. I simply was unaware that notification box meant exactly this style of notification. After looking at the code, it's now clear that it does. Again, nice job, and sorry for the miscommunication.

Changed 4 weeks ago by mikeperry

Torbutton with Security Slider v0.9 (from git commit 430ccaa1596e03e3ea0a36c51c4623fe8ff67d52) - English Only

comment:100 follow-up: Changed 4 weeks ago by mikeperry

Btw, pfmbot reported that on osx yosemite, the medium-low position didn't line up with the label text. Not sure how far it was off.

comment:101 in reply to: ↑ 100 ; follow-up: Changed 4 weeks ago by gk

Replying to mikeperry:

Btw, pfmbot reported that on osx yosemite, the medium-low position didn't line up with the label text. Not sure how far it was off.

Yes, see comment:84. In bug_9387_v12 I implemented the missing SVG preference into the slider which should make it ready for prime time.

One thing arma noted on IRC is that we might want to think about really having "Low" as a slider label: "Look, the Tor folks are shipping their Tor Browser by default with low security!!1!1". I am inclined to keep it the way it currently is, though.

comment:102 in reply to: ↑ 101 Changed 4 weeks ago by lunar

Replying to gk:

One thing arma noted on IRC is that we might want to think about really having "Low" as a slider label: "Look, the Tor folks are shipping their Tor Browser by default with low security!!1!1". I am inclined to keep it the way it currently is, though.

I strongly agree. That's why I was suggesting to write “Most compatible” or something similar earlier on.

comment:103 Changed 4 weeks ago by mikeperry

  • Resolution set to fixed
  • Status changed from needs_review to closed

Ok, this is pushed! Everything should be good to go for TBB 4.5a5 here.

Also, as far as I can tell, the "Medium Low" position of the security slider would have prevented one pwn2own bug (https://www.mozilla.org/en-US/security/advisories/mfsa2015-29/), and "Medium High" would have prevented non-https pages from exploiting the second (https://www.mozilla.org/en-US/security/advisories/mfsa2015-28/). The "High" position would have prevented https://www.mozilla.org/en-US/security/advisories/mfsa2015-28/ entirely (both by disabling JS, and by disabling SVG).

So good work, everybody!

Note: See TracTickets for help on using tickets.