Put "custom" option on security slider?
bugzilla suggested:
Hint: it's better to replace this checkbox with a new Security Slider position "Expert" above High, especially for mobile UX, which will have the same settings as High for the first time (so text to the right will be the same), and text will disappear when custom settings will have been made (and this position will preserve (!) custom settings while switching back and forth from other positions!)
I'm not sure about this approach, because it puts the custom option on the same "linear dimension" as the other security options. On the other hand, I agree it will perhaps make the semantics somewhat clearer.
Activity
Another possibility that occurs to me is to hide the security slider when we are in custom mode. Show a message that says
Browser prefs have been changed to put Tor Browser in a nonstandard security setting. This is dangerous because it helps to distinguish you from other users.
And then a button that shows "Restore to X security", where X is Low, Medium or High, depending on the current value of "extensions.torbutton.security_slider". Once that button is pressed, the security slider would re-appear in the correct setting.
I'm interested to hear opinions!
I don't think we want to have a new slider level for custom. It is hard for a user to grasp what it means. I can live with the idea in comment:2 although I am quite wary about overengineering that part. It seems to me we would implement quite some logic and would spend quite some time on what is meant to be for experts who should be able to fix this stuff for themselves. It is not by chance that this option is merely a checkbox buried deep in the menu.
Replying to arthuredelstein: Finally you've found the right place for
Restore Defaultsbutton ;)This is a general problem of creating UI for different user groups. And your solution is correct if you don't want to mix advanced options with simple.
Here's a patch that does what I described in comment:2. I also refactored the pref logic to simplify it.
https://github.com/arthuredelstein/torbutton/commit/20347
Trac:
Status: new to needs_review-
So, I played around with the patch a bit. My biggest objection to it is that buttons are missing. I was quite confused as every other dialog opening in the browser has at least a Cancel/Close button and was wondering whether I really should click on the red and dangerous "x" (it's red for a reason, right?). I finally concluded, "yes, that's obviously the intention" and pressed it anxiously. So, I think this is not going to fly with a user who is supposed to acknowledge possibly changes by clicking on a button that screams "Abort!!1! Danger!1!!". (the situation might be different for the mobile browser, though)
What about just a "Close" button? I don't know but I suspect users are starting to ask whether the changes really got applied (if they made some).
Apart from that, clicking on the slider level to adjust the slider is not working anymore. We should retain that option.
Trac:
Status: needs_review to needs_revision
Keywords: TorBrowserTeam201610R deleted, TorBrowserTeam201610 added Replying to gk:
So, I played around with :))))) My biggest objection to it is that buttons are missing. That's a violation of GUI guidelines. I was quite confused as every other dialog opening in the browser has at least a Cancel/Close button and was wondering whether I really should click on the red and dangerous "x" (it's red for a reason, right?). Yes, it's for discarding the changes. I finally concluded, "yes, that's obviously the intention" and pressed it anxiously. Booom :) So, I think this is not going to fly with a user who is supposed to acknowledge possibly changes by clicking on a button that screams "Abort!!1! Danger!1!!". (the situation might be different for the mobile browser, though) (yeah, ux team is doing something strange for mobile...) What about just a "Close" button? I don't know but I suspect users are starting to ask whether the changes really got applied (if they made some). Test the users ;)
-
Another thing that confused me (and might tie to my comments above): if I am on "low" and disable JS via the NoScript button and then click on the Restore Defaults one the NoSrcipt button does not change. It does not do so even if I close the dialog. Changes the tab or reloading the page does change it, though.
Replying to gk, [comment:7 comment 7]:
So, I played around with the patch a bit. My biggest objection to it is that buttons are missing. I was quite confused as every other dialog opening in the browser has at least a Cancel/Close button and was wondering whether I really should click on the red and dangerous "x" (it's red for a reason, right?). I finally concluded, "yes, that's obviously the intention" and pressed it anxiously. So, I think this is not going to fly with a user who is supposed to acknowledge possibly changes by clicking on a button that screams "Abort!!1! Danger!1!!". (the situation might be different for the mobile browser, though)
I think you're right, as does another user I consulted.
What about just a "Close" button? I don't know but I suspect users are starting to ask whether the changes really got applied (if they made some).
I decided to go back to using OK/Cancel instead, because makes it more clear that changes have been applied than a "Close" button. Also I guess it gives users who didn't mean to change the settings a chance to undo their mistake.
Apart from that, clicking on the slider level to adjust the slider is not working anymore. We should retain that option.
Oops, I brought that back.
Replying to gk, [comment:9 comment 9]:
Another thing that confused me (and might tie to my comments above): if I am on "low" and disable JS via the NoScript button and then click on the Restore Defaults one the NoSrcipt button does not change. It does not do so even if I close the dialog. Changes the tab or reloading the page does change it, though.
I believe I have fixed this now. Turns out we need to use setTimeout to make sure the new pref value is fully known to NoScript before we tell it to update the UI. Also, now if the user toggles "noscript.global" or "noscript.globalHttpsWhitelist" in about:config, the UI also gets updated correctly.
Here's the new version: https://github.com/arthuredelstein/torbutton/commit/20347+1
Trac:
Status: needs_revision to needs_review
In the new nightly build (in which this change has been merged), I see that when changing the
extensions.torbutton.security_sliderpreference from outside the browser (by editingBrowser/TorBrowser/Data/Browser/profile.default/preferences/extension-overrides.jswhile the browser is not running), the new slider mode is not applied when starting the browser. It is still applied correctly when changing it from about:config or from the slider dialog.-
That makes me a bit nervous. I think we should make sure that during start-up Tor Browser gets the settings applied which are specified by
extensions.torbutton.security_slider.Trac:
Resolution: fixed to N/A
Keywords: TorBrowserTeam201611R deleted, TorBrowserTeam201611 added
Status: closed to reopened Replying to boklm:
In the new nightly build (in which this change has been merged), I see that when changing the
extensions.torbutton.security_sliderpreference from outside the browser (by editingBrowser/TorBrowser/Data/Browser/profile.default/preferences/extension-overrides.jswhile the browser is not running), the new slider mode is not applied when starting the browser. It is still applied correctly when changing it from about:config or from the slider dialog.Thanks for finding this bug, boklm. Here's a patch to fix it. https://github.com/arthuredelstein/torbutton/commit/20347+2
