Opened 2 years ago

Closed 2 years ago

#20347 closed defect (fixed)

Put "custom" option on security slider?

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-usability, tbb-security-slider, TorBrowserTeam201611R
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (17)

comment:1 Changed 2 years ago by arthuredelstein

Component: - Select a componentApplications/Tor Browser
Keywords: tbb-usability added
Owner: set to tbb-team

comment:2 Changed 2 years ago by arthuredelstein

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!

Last edited 2 years ago by arthuredelstein (previous) (diff)

comment:3 Changed 2 years ago by gk

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.

comment:4 in reply to:  2 Changed 2 years ago by bugzilla

Replying to arthuredelstein:
Finally you've found the right place for Restore Defaults button ;)

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.

comment:5 Changed 2 years ago by arthuredelstein

Status: newneeds_review

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

comment:6 Changed 2 years ago by arthuredelstein

Keywords: tbb-security-slider TorBrowserTeam201610R added

comment:7 Changed 2 years ago by gk

Keywords: TorBrowserTeam201610 added; TorBrowserTeam201610R removed
Status: needs_reviewneeds_revision

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.

comment:8 in reply to:  7 Changed 2 years ago by bugzilla

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

comment:9 Changed 2 years ago by gk

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.

comment:10 in reply to:  7 Changed 2 years ago by arthuredelstein

Status: needs_revisionneeds_review

Replying to gk, 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:

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

comment:11 Changed 2 years ago by mcs

Kathy and I reviewed the 20347+1 patch and it looks good to us. We also did a little testing on OSX.

comment:12 Changed 2 years ago by gk

Keywords: TorBrowserTeam201611R added; TorBrowserTeam201610 removed
Resolution: fixed
Status: needs_reviewclosed

Applied to master with commit e59f6df84dcfde500f41eefb608dd878a7fc9d6b.

comment:13 Changed 2 years ago by boklm

In the new nightly build (in which this change has been merged), I see that when changing the extensions.torbutton.security_slider preference from outside the browser (by editing Browser/TorBrowser/Data/Browser/profile.default/preferences/extension-overrides.js while 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.

comment:14 Changed 2 years ago by gk

Keywords: TorBrowserTeam201611 added; TorBrowserTeam201611R removed
Resolution: fixed
Status: closedreopened

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.

comment:15 in reply to:  13 Changed 2 years ago by arthuredelstein

Replying to boklm:

In the new nightly build (in which this change has been merged), I see that when changing the extensions.torbutton.security_slider preference from outside the browser (by editing Browser/TorBrowser/Data/Browser/profile.default/preferences/extension-overrides.js while 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

comment:16 Changed 2 years ago by arthuredelstein

Status: reopenedneeds_review

comment:17 Changed 2 years ago by gk

Keywords: TorBrowserTeam201611R added; TorBrowserTeam201611 removed
Resolution: fixed
Status: needs_reviewclosed

Yay, for having tests! Applied to master (commit 595b01456eaa3b0759f1f80d562ebf6520c8c182).

Note: See TracTickets for help on using tickets.