Opened 9 months ago

Last modified 3 days ago

#25658 assigned project

Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

Reported by: isabela Owned by: antonela
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ux-team, TorBrowserTeam201812, GeorgKoppen201812
Cc: tbb-team, dmr, isnaiter, arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor17

Description (last modified by isabela)

This work is related to the following proposal:

https://lists.torproject.org/pipermail/tbb-dev/2018-March/000799.html

There should also be an experience for Android. (maybe create a child ticket to track that?)

Child Tickets

TicketStatusOwnerSummaryComponent
#28628assigneddunqanIntroduce New Security Settings to usersApplications/Tor Browser

Attachments (24)

25658.png (1.0 MB) - added by antonela 9 months ago.
25658-exploration.png (204.0 KB) - added by antonela 9 months ago.
25658 - Settings Radio.png (576.1 KB) - added by antonela 8 months ago.
25658 - 2.png (768.1 KB) - added by antonela 8 months ago.
25658-exploration 2.png (224.4 KB) - added by antonela 8 months ago.
Image-1.jpg (76.6 KB) - added by hiro 8 months ago.
firefox focus
brave-shield-1.png (1.2 MB) - added by antonela 8 months ago.
brave-shield-2.png (347.3 KB) - added by antonela 8 months ago.
25658 - 3.png (472.3 KB) - added by antonela 8 months ago.
25658 - 4.png (628.9 KB) - added by antonela 8 months ago.
25658 - 5.png (1.0 MB) - added by antonela 8 months ago.
TBB8-UI-Security-Settings.png (771.8 KB) - added by antonela 6 months ago.
25658 - 6.0.png (296.6 KB) - added by antonela 7 weeks ago.
25658 - 6.1.png (304.4 KB) - added by antonela 7 weeks ago.
25658 - 6.2.png (291.0 KB) - added by antonela 7 weeks ago.
25658 - 6.3.png (194.2 KB) - added by antonela 7 weeks ago.
25658 - 6.4.png (260.9 KB) - added by antonela 7 weeks ago.
25658-preferences.png (442.0 KB) - added by antonela 7 weeks ago.
25658 - 7.png (229.3 KB) - added by antonela 7 weeks ago.
25658 - 8.png (1.2 MB) - added by antonela 6 weeks ago.
25658 - 9.png (159.2 KB) - added by antonela 5 weeks ago.
25658 - 10.png (158.6 KB) - added by antonela 4 weeks ago.
onions-security.png (100.2 KB) - added by pili 4 weeks ago.
TB 8.0.3 custom prefs.png (55.7 KB) - added by mcs 4 weeks ago.
Tor Browser 8.0.x security dialog after a pref governed by the slider has been flipped via about:config

Change History (98)

comment:1 Changed 9 months ago by isabela

Description: modified (diff)

comment:2 Changed 9 months ago by arma

Summary: Actity 2.1: Improve user understanding and user control by clarifying Tor Browser's security featuresActivity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

Changed 9 months ago by antonela

Attachment: 25658.png added

Changed 9 months ago by antonela

Attachment: 25658-exploration.png added

comment:3 Changed 9 months ago by gk

Cc: tbb-team added

comment:4 Changed 9 months ago by cypherpunks

@antonela Great prototypes! (love how you designed them with FF60's UX :) ) Concerning colors it would be great if you could make modifications so that they won't pose a problem for color blind users, see for example https://medium.theuxblog.com/how-to-design-for-color-blindness-a6f083b08e12 Another option would be to offer an option for enabling color blind friendly colors just like the extension uMatrix does in its options (here's a link for it to try out: https://addons.mozilla.org/en-US/firefox/addon/umatrix/ then go to its preferences)

comment:5 Changed 8 months ago by antonela

I've made a first approach based on latest https://lists.torproject.org/pipermail/tbb-dev/2018-February/000756.html and updates.

https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658.png

So far, what is changing is:

  • NoScript + https everywhere icons are going to be removed
  • Tor Button is going to be placed on the right side

what we need to think about is:

  • Finding a way to offer visual feedback about
    1. the current status of the security setting
    2. the site/content changes once the slider change

Some comments:

  • If we don't want people to change security easily or by error and also if it's changed carries a lot of security problems between sites, do you think the slider is the best UI artifact?.
  • I believe that it is an outstanding feature and I'd like to expose it in our main UI. Could we show the status of the security with a visual indicator and move the settings to the settings right place? Something like this we discussed in Rome.
  • On this proposal, when the user clicks on the security indicator a door hanger appears. The door hanger includes a] The security status b] a description with an expected behavior c] a link to settings
  • I'm proposing to have settings inside about:preferences#security but it might change to a specific section with general Tor Browser settings, like about:preferences#torbrowser
  • I'm using firefox's tracking protection icon. Despite the fact that seems to be the proper icon, it will confuse users about each feature? In that case, aren't both features protecting users?

I included on attachment some another option I explored, but I don't think they work as we aimed.

https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658-exploration.png

Last edited 8 months ago by antonela (previous) (diff)

comment:6 in reply to:  4 Changed 8 months ago by antonela

Replying to cypherpunks:

@antonela Great prototypes! (love how you designed them with FF60's UX :) )

Thanks, glad you like it (:

Concerning colors it would be great if you could make modifications so that they won't pose a problem for color blind users, see for example https://medium.theuxblog.com/how-to-design-for-color-blindness-a6f083b08e12 Another option would be to offer an option for enabling color blind friendly colors just like the extension uMatrix does in its options (here's a link for it to try out: https://addons.mozilla.org/en-US/firefox/addon/umatrix/ then go to its preferences)

Yes, accessibility is a priority and we will make sure that the colors we are using works for most of the users. The selection of colors is based on a metaphor and we really want people to understand it. So, despite the fact that the color could be representative or not, we should have labels or text anchor that reinforce the meaning of the icon.

comment:7 Changed 8 months ago by gk

Keywords: TorBrowserTeam201804 added
Priority: MediumHigh

comment:8 Changed 8 months ago by cypherpunks

https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658-exploration.png

Another option instead of showing colors to convey the security level one can show a number badge from 1 to 3 (more security => bigger number, Standard => 1, Safe => 2, ...etc). setBadgeTest can also show a text but one would need to see if it will fit in that space https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/browserAction/setBadgeText

(Also a note on the about:preferences changes: I think they're unnecessary since the functionality would already be offered by the security button, so there's no need for duplicate effort)

comment:9 in reply to:  8 ; Changed 8 months ago by antonela

Replying to cypherpunks:

Another option instead of showing colors to convey the security level one can show a number badge from 1 to 3 (more security => bigger number, Standard => 1, Safe => 2, ...etc). setBadgeTest can also show a text but one would need to see if it will fit in that space https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/browserAction/setBadgeText

This is a good option to test, yes. I don't know how normal people will understand the number, but it worth an exploration for sure. Thinking about incremental numbers = more security is tricky. If I get an A grade is better than a C grade. But if I get 3 is better than 1? How intuitive is it? IDK. I'll prepare mocks to see how it feels. Thanks :)

(Also a note on the about:preferences changes: I think they're unnecessary since the functionality would already be offered by the security button, so there's no need for duplicate effort)

Well, we don't want to have the slider on the Top bar UI. The doorhanger is just showing the security setting description + a call to action in the case the user wants to change it. So if the user wants to change the security setting, they should go to about:preferences to upgrade or downgrade their setup.

comment:10 Changed 8 months ago by mcs

I like the idea of moving the UI for changing the security level into about:preferences. However, nearly everything in about:preferences is "instant apply" (changes take effect immediately) which may make it more difficult for people to learn about the different security levels before they decide to change their level.

In the existing dialog-based UI users can learn what the different levels do via two methods: (1) tooltips and (2) they can move the slider to the different positions to reveal descriptive text (since the actual security level is not changed until they dismiss the dialog). We could use tooltips in about:preferences, but maybe we can also come up with a more obvious way for people to learn about the different security level choices. For example, if we use three radio buttons instead of a slider control we might be able to simply include the descriptive text nearby (that might be crowded though).

Changed 8 months ago by antonela

Attachment: 25658 - Settings Radio.png added

comment:11 in reply to:  10 Changed 8 months ago by antonela

Thanks for the comment @mcs!

Replying to mcs:

I like the idea of moving the UI for changing the security level into about:preferences. However, nearly everything in about:preferences is "instant apply" (changes take effect immediately) which may make it more difficult for people to learn about the different security levels before they decide to change their level.

Yes, indeed.

In the existing dialog-based UI users can learn what the different levels do via two methods: (1) tooltips and (2) they can move the slider to the different positions to reveal descriptive text (since the actual security level is not changed until they dismiss the dialog). We could use tooltips in about:preferences, but maybe we can also come up with a more obvious way for people to learn about the different security level choices. For example, if we use three radio buttons instead of a slider control we might be able to simply include the descriptive text nearby (that might be crowded though).

To be honest, and as I said before, I think the slider is not the best solution for this UX at the moment. But, I know that people have been calling this feature security-slider for a while and I'm not sure about how hard could be this change for them.

That said, I love the idea about to have three simply radio buttons with each description. In that case, we will continue having the confirmation step before seeing the changes.

I made a mockup to see how it looks :) See here

https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658%20-%20Settings%20Radio.png

Changed 8 months ago by antonela

Attachment: 25658 - 2.png added

comment:12 Changed 8 months ago by dmr

Cc: dmr added

Changed 8 months ago by antonela

Attachment: 25658-exploration 2.png added

comment:13 Changed 8 months ago by antonela

Hi! I have been working on creating an icon set that allows us to show visual feedback for our three levels of security.
I tried hard the ideas we talked about last week.
You can lurk them here

https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658-exploration%202.png

But nothing seems working.

So, I did an exercise, and I started to walk the user journey to understand what are the user expectations when they downgrade or upgrade their security settings.

Let's walk through this user journey:

  • User wants to visit a risky site or a shared URL from an unknown source
  • User slide up the Security Slider and set up the security at Safer or Safest
  • User types the URL and waits until the content load
  • The content is not loading correctly because of settings.
  • User can

a) downgrade their security level to make things work
b) use the website as it is because the nonloaded content is not critical (e.g., fonts change, or an ad at sidebar blocked with js)

In both cases, probably an update of security won't fix the problem. In the best situation, it will create a new content display problem. But in the worst, users are exposed to leak information.

Also, seems like users don't even need to understand how the security engine works, but how it benefits them[0]. We may make the decision easier for them. And we can work with their expectations.

The slider UI was selected before for being a familiar pattern to set up a stepped security level, pretty similar to Security Slider configuration on Microsoft's IE. But now, we are experimenting the downsides of it.

So, can we simplify the choices? What if we have two levels of security instead of three? Activated and Deactivated.

Maybe, we can increase TorBrowser default security by moving some medium settings to default.

You can see the concept here

https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658%20-%202.png

What do you think? Can we re-think this feature, so it works proactively with user expectations? Can we offer a UX that is intuitive and straightforward for regular users?

And for heavy users, can we allow them to set up specific content through a granular configuration? How technically possible it is?

Is any tradeoff on removing medium security setting? Is it a lot of development effort?

Will people downgrade their security because something is not working/loading properly? If yes, is it not what users are doing right now everytime they want to see a video, and someone is tracking them, and the resistance app is blocking the content, and the content is not working?

[0] https://www.freehaven.net/anonbib/cache/usableTor.pdf

comment:14 Changed 8 months ago by tom

Hm. Perhaps I'm focusing on the wrong part of your comment;, but as I was looking through https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658-exploration%202.png I was in agreement that none of them really illustrated the visual feedback.

The one with the words Standard / Safer / Safest did of course; because it's making it explicit.

The rest of them had no indicator to me that
a) This state was 'partial' - e.g. that there was a better state to be in.
b) That this state was 'the best'.

Okay 3 dots is better than 1 dot. How do I know that there is something better than 1 dot? How do I know there is not a four-dot setting?

Shield, half-shield... and the checkerboard shield... these could both be stylist choices. I don't know the shield is supposed to be full.

Until I saw the grey shield on the far right. Th one where it looks like it's filling a progress bar. That one immediately resonated with me (personally at least.) It's a progress bar. It fills up.

If you make the full shield have the small white lines so it's indicative of three 'bars' that filled up it's more apparent. It might be even more apparent if you render it in stark color (black or purple, with the unfilled boxes being light grey.

Heck, if we want to animate it, we could blink the filled or unfilled progress bars.

Anyway, I just wanted to point out that that one in particular jumped out to me and felt the most right of the icons you had initially explored.

comment:15 in reply to:  14 ; Changed 8 months ago by antonela

Replying to tom:

Anyway, I just wanted to point out that that one in particular jumped out to me and felt the most right of the icons you had initially explored.

Thanks for jumping here tom! What do you think about to have just two options?
https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658%20-%202.png

comment:16 in reply to:  15 Changed 8 months ago by cypherpunks

Replying to antonela:

https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658%20-%202.png

It wouldn't be possible to replicate the "Safer" - "Medium" setting with that proposal (block JS just for non-encrypted websites, ...etc).

comment:17 Changed 8 months ago by hiro

I wanted to leave a comment that is less about ux and more about what the security slider communicates.

Lately I have been thinking about the security slider and how it somehow represent (or doesn't) how we describe concepts like privacy and security in the Tor Browser design document (https://www.torproject.org/projects/torbrowser/design).

We say that when we talk about security we mean ensuring that the Tor network is used properly without compromising the user anonymity, and when we talk about privacy we consider other properties like fingerprinting protection and linkability. Maybe we need a way to relate this to the security slider so that it is also easier to explain users the settings they are choosing.

For example when making a decision about the preferred security level in the slider, we can assume the user might think that more security also means more privacy. In the read more paragraph in the slider itself we communicate the idea that that the lowest level is the closest thing to a firefox browser using Tor (more or less), if I increase the slider I have less features available while I surf the web, but also more protection against browser fingerprinting and linkability, therefore more privacy and security.

I don't know if is there an easier way to present this. An example I have in my mind is firefox focus. If I open firefox focus on mobile I have a setting that says tracking protection (on or off). It also tells me how many trackers the page implements.

Last edited 8 months ago by hiro (previous) (diff)

Changed 8 months ago by hiro

Attachment: Image-1.jpg added

firefox focus

comment:18 Changed 8 months ago by tom

Yea. Talking about the slider settings gets confusing because different words mean different things to different people, and there are a lot of things I think we're trying to roll up into a single slider.

Privacy: We've previously, and I agree, that we should not encourage or support the slider being interpreted as improving privacy. A user's privacy should be respected whether it's at Low or High; and by that I mean Fingerprinting Protection, FPI, and Circuit Isolation should always be in effect. If for whatever reason we want to loosen privacy restrictions to support web functionality - we should probably pursue well-working, useful, and informative permission choices. Like Canvas and Audio/Video.

Security from Exit Nodes: I imagine this as 'None', 'Medium', and 'High'. 'Medium' blocks all Javascript, audio, video, svg, web fonts, and maybe a few other things from HTTP. High blocks all HTTP. I think we admit this is a goal of the slider by having the 'Block JS from HTTP' feature. I don't think there is any other reason to have this feature except to protect from malicious exit nodes. I would be curious to see how much of the web breaks if we broke this out, and defaulted to Medium.

Security from the Web Site itself: This encompasses most of the rest of the slider features. Blocking JS from HTTPS sites. JS Engine optimizations are disabled. MathML disabled. SVG disabled, audio/video formats are disabled. This is generally what we think of as the goal of the slider, I think.

Given this, I think two settings for the slider can make sense. "Do I trust this website or not?" The pain point is that the usability of disabling javascript is often so harsh that it makes it untenable... I wonder if there's anything that can be done to split that atom....


I think one of the pain points we have with Tor Browser is the lack of persistent storage. We are so deathly scared of storing anything to disk that we can't save user's per-site exceptions to things. Perhaps we should reconsider this (opt-in of course.) I'd be curious to brainstorm if we could divine a storage mechanism we actually felt some measure of confident in. For example: What if we used something like Argon2 combined with a TPM-backed value? This is bypassable, but it requires on-machine brute forcing. If we developed something akin to 'Firefox Accounts', we could enable users the ability to store data on a Hidden Service and revoke authorization to it. These ideas are very 'out there'.

comment:19 in reply to:  18 Changed 8 months ago by cypherpunks

Replying to tom:

I think one of the pain points we have with Tor Browser is the lack of persistent storage. We are so deathly scared of storing anything to disk that we can't save user's per-site exceptions to things. Perhaps we should reconsider this (opt-in of course.) I'd be curious to brainstorm if we could divine a storage mechanism we actually felt some measure of confident in. For example: What if we used something like Argon2 combined with a TPM-backed value? This is bypassable, but it requires on-machine brute forcing. If we developed something akin to 'Firefox Accounts', we could enable users the ability to store data on a Hidden Service and revoke authorization to it. These ideas are very 'out there'.

Or just allow to assign different security slider setting to different temporary containers (each different container has a new identity, so to speak)? If the Project Fission thing gets going then there's a different process for different container and that would solve a lot of security problems and the UX with containers wouldn't require much work or difficulty to setup.

comment:20 in reply to:  18 Changed 8 months ago by hiro

Replying to tom:

Yea. Talking about the slider settings gets confusing because different words mean different things to different people, and there are a lot of things I think we're trying to roll up into a single slider.

The problem I see is exactly that and what we communicate to users. If I click on the learn more link on the slider I am taken to the Tor Browser Manual.
The first sentence I see is the following:

"Tor Browser includes a “Security Slider” that lets you increase your security by disabling certain web features that can be used to attack your security and anonymity. Increasing Tor Browser’s security level will stop some web pages from functioning properly, so you should weigh your security needs against the degree of usability you require."

If I had not read the design document I would think of the security slider as mainly an increased privacy protection.
I understand maybe the slider is not the place to talk about de-anonymisation in the Tor network and go into details, so maybe we should do that in the Tor Browser manual to make it more clear?

Also, I think that, as a user I'd be able to better understand this if we would at least explain why we disable certain features and what I am loosing if I enable them.

It is also worth to consider that it might be a risk to give the user the habit of lowering their security every time a website doesn't work. What if it is the website that is broken (or malicious) and not Tor Browser just too strict?

A few of these considerations I suppose could also be included in the styleguide as a reference of how a page would work in the various Tor Browser modes. Also as some "tracking-blocking" features become used by other browser, this reasoning could be used to make pages generally more privacy friendly.

Last edited 8 months ago by hiro (previous) (diff)

Changed 8 months ago by antonela

Attachment: brave-shield-1.png added

Changed 8 months ago by antonela

Attachment: brave-shield-2.png added

Changed 8 months ago by antonela

Attachment: 25658 - 3.png added

Changed 8 months ago by antonela

Attachment: 25658 - 4.png added

comment:21 Changed 8 months ago by antonela

Thank people for jumping on this ticket! For sure, privacy and security concepts have diffuse borders for user's interpretation.

Last week we talked about which icon/image/metaphor represents "security" better, and the lock seems to be the most robust option.

I tried to avoid empty states, or the idea of something is wrong when the setting is at the default level.

I worked on two ideas:

This option shows some progress which I know is not exactly what the configuration represents but in some way it shows the status of the security level.

Talking with Hiro about this came up the idea about more circles, more security. And it also works as a representation of a layer of protection. So, adding layers/circles, we add security. Does it look like an abstract onion? :)

Open to discuss all these ideas during our meeting today!

Changed 8 months ago by antonela

Attachment: 25658 - 5.png added

comment:22 Changed 8 months ago by antonela

Hi folks!

Based on our last meeting, this round of icons is focused on Shields.

I made three options. We can discuss them during our meeting this week.

https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658%20-%205.png

Feel free to leave comments!

comment:23 Changed 8 months ago by brade

I like the middle set best. The top set is good but at a small size I have a hard time distinguishing the two icons on the right (safer/safest). The bottom set reminds me of jewelry / diamonds more than shields.

comment:24 Changed 8 months ago by pospeselr

Stylistically, I prefer Option A, as that's basically exactly what I was imagining when we first started brainstorming this. I can see how Option B works better for accessibility though. Agree with brade regarding the Option C gem icon.

comment:25 Changed 7 months ago by gk

Keywords: TorBrowserTeam201805 added; TorBrowserTeam201804 removed

Move our roadmap tickets to May.

Changed 6 months ago by antonela

comment:26 Changed 6 months ago by antonela

Hi! Based on latest comments, I updated the UI

https://trac.torproject.org/projects/tor/attachment/ticket/25658/TBB8-UI-Security-Settings.png

I also made a prototype -> https://marvelapp.com/383eaa9/screen/44007368

I used Photon for the settings UI -> https://design.firefox.com/photon/components/radio-buttons.html

We still need to work on informing users that NoScript and HTTSEverywhere icons are available to be placed at the Top Nav via Menu/Customize. We could include a step/card explaining it at the new onboarding.

Also, current about:preferences at FF60 doesn't have a [SAVE] button to confirm the action. Do you think we need to add an intermediate step for users to verify their radio option pick? May we need it for anything else?

I think we are pretty close to moving this forward. Am I missing anything else?

comment:27 in reply to:  26 Changed 6 months ago by cypherpunks

Replying to antonela:

Also, current about:preferences at FF60 doesn't have a [SAVE] button to confirm the action. Do you think we need to add an intermediate step for users to verify their radio option pick? May we need it for anything else?

Isn't it possible to emulate the current Torbutton behavior by launching a popup window instead of opening a new tab with about:preferences (and therefore exposing those other options that users shouldn't change to them)?

comment:28 Changed 6 months ago by arthuredelstein

As part of this work, we could consider the phrasing for the security options. Ideas at the Mozilla All Hands included the changing the settings names to "strict, stricter, strictest" and using "feature filter" instead of "security slider". Further discussion may be needed!

(I personally lean toward "safe" over "strict" and keeping the word "security" but agree there might be a better terminology.)

comment:29 Changed 5 months ago by arma

I like the new phrasing "Feature filter". Calling it a security slider sure is confusing about what we might mean by security, and I think with that name we will forever have people messing with it thinking that it does something that it doesn't actually do.

comment:30 in reply to:  29 Changed 5 months ago by tyjuWZpTkvxwTGkEcvXFx4Smg83jC3

Replying to arma:

I like the new phrasing "Feature filter". Calling it a security slider sure is confusing about what we might mean by security, and I think with that name we will forever have people messing with it thinking that it does something that it doesn't actually do.

But then one should also convey the key idea "less features ⇒ less attack surface ⇒ "more" secure" with as much clarity as before--at least.

comment:31 Changed 3 months ago by gk

Cc: isnaiter added

#27511 is a duplicate (for the "New Identity" on the toolbar part).

comment:32 Changed 8 weeks ago by gk

Keywords: TorBrowserTeam201810 added; TorBrowserTeam201805 removed

Changed 7 weeks ago by antonela

Attachment: 25658 - 6.0.png added

Changed 7 weeks ago by antonela

Attachment: 25658 - 6.1.png added

Changed 7 weeks ago by antonela

Attachment: 25658 - 6.2.png added

Changed 7 weeks ago by antonela

Attachment: 25658 - 6.3.png added

Changed 7 weeks ago by antonela

Attachment: 25658 - 6.4.png added

comment:33 Changed 7 weeks ago by antonela

back to game - from Geko's proposal

https://lists.torproject.org/pipermail/tbb-dev/2018-March/000799.html

2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar

Agreed. Wondering how we will handle HTTPSE for .onion improvements. But I know, is further problem. Let's stick to this idea for now.

2.1.2 Adding a Security Settings Button to the Toolbar

As discussed previously, expose the security settings to the toolbar is a good addition, but it does not solve the real problem. I've tried a couple of options before in this thread.

Also, in order to keep the cohesion between the UI components behavior, we agreed that global settings would live at about:preferences.

2.2 Dealing with Per-Site Security Settings

We agreed to move site-specific settings to the Control Center (url bar's doorhanger). I made a mockup to illustrate this iteration.

Unfortunately, Firefox is using a shield icon to illustrate the Block Content aka Tracking Protection feature. This is cool, too. But, I agreed that could be confusing for users using the same kind of icon to show our Tor Browser protections. Perhaps a lock icon, which is also related to security topics, would help us.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/25658/25658%20-%206.0.png

Again: I think that the best way to improve the security slider is removing the slider component. As mentioned before, the slider is a UI artifact that doesn't add any value to this settings. Instead, it confuses users about their benefits on upgrade or downgrade.

If we could simplify the security settings into a boolean option, we will follow the current Firefox approach on settings both in desktop and in mobile, and we will help users by making it easier to understand the trade-off: "Do I trust in this site?"

My idea is to have our Security Protection ON by default on HTTP sites and OFF by default on HTTPS sites. For sure, it could be easy changed via global settings at about:preferences. I'm happy to hear your thoughts about it.

With the boolean option, this will look more like

ON: HTTP protected, HTTPS protected
OFF: HTTP protected, HTTPS unprotected

https://trac.torproject.org/projects/tor/raw-attachment/ticket/25658/25658%20-%206.1.png

With this scenario, we are increasing Tor Browser security by default. The Control Center will contain the settings that affect the current tab. When the Security Protection is ON, as mentioned in the proposal, the user could be able to temporary enable JS or any other item to improve the website performance.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/25658/25658%20-%206.2.png

Also, following Firefox behavior, the small gear icon at the right side will move users to the general settings about:preferences.

General Settings - about:preferences#security

The settings which affects all tabs are global. Global settings live under about:preferences. Naturally, Security settings must go under about:preferences#security. We need to define which options we will expose to users here. A quick approach here (copy up to review/creation)

https://trac.torproject.org/projects/tor/raw-attachment/ticket/25658/25658%20-%206.4.png

Report breakage of sites

We need a secure way for tor browser users to report breakage of sites. It is important to securely measure how much we are degrading users browsing performance and also to have better suggestions for websites owners on how to improve it for their visitant's security. We could include an item at the hamburger menu, as shown here. It deserves their own proposal, tho. I'm opening it to a discussion, and I'll be happy if Metric's team folks join us on it.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/25658/25658%20-%206.3.png


If we are solid with this approach, next steps are:

  • Define about:preferences#security items
  • Define a name for the feature that can recall on users about it benefits. Options I explored: Security Shield, Security Protection, Tor Security
  • Make a clickeable prototype so we can explore and test different user flows
  • Discover, plan and review all different user scenarios for each disabled feature
Last edited 7 weeks ago by antonela (previous) (diff)

comment:34 in reply to:  33 Changed 7 weeks ago by gk

Replying to antonela:

back to game - from Geko's proposal

https://lists.torproject.org/pipermail/tbb-dev/2018-March/000799.html

It seems you did not use the latest iteration of it. It is now in our tor-browser-spec repo: https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101-security-controls-redesign.txt.

2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar

Agreed. Wondering how we will handle HTTPSE for .onion improvements. But I know, is further problem. Let's stick to this idea for now.

2.1.2 Adding a Security Settings Button to the Toolbar

As discussed previously, expose the security settings to the toolbar is a good addition, but it does not solve the real problem. I've tried a couple of options before in this thread.

Also, in order to keep the cohesion between the UI components behavior, we agreed that global settings would live at about:preferences.

See the latest proposal here about what we planned.

2.2 Dealing with Per-Site Security Settings

We agreed to move site-specific settings to the Control Center (url bar's doorhanger). I made a mockup to illustrate this iteration.

Unfortunately, Firefox is using a shield icon to illustrate the Block Content aka Tracking Protection feature. This is cool, too. But, I agreed that could be confusing for users using the same kind of icon to show our Tor Browser protections. Perhaps a lock icon, which is also related to security topics, would help us.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/25658/25658%20-%206.0.png

Again: I think that the best way to improve the security slider is removing the slider component. As mentioned before, the slider is a UI artifact that doesn't add any value to this settings. Instead, it confuses users about their benefits on upgrade or downgrade.

What do you mean about removing the slider component? And what is "this settings"?

If we could simplify the security settings into a boolean option, we will follow the current Firefox approach on settings both in desktop and in mobile, and we will help users by making it easier to understand the trade-off: "Do I trust in this site?"

My idea is to have our Security Protection ON by default on HTTP sites and OFF by default on HTTPS sites. For sure, it could be easy changed via global settings at about:preferences. I'm happy to hear your thoughts about it.

With the boolean option, this will look more like

ON: HTTP protected, HTTPS protected
OFF: HTTP protected, HTTPS unprotected

The security risks don't map the the underlying transport (or its security) being used. The security risks we try to tackle are to a large part due to the *content* that gets transferred. Someone injecting this content on the path from server to user is an important risk but just one of those we need to defend against. Thus, binding the security state to HTTP/HTTPS is not sufficient. Moreover, the strongest security we want to provide is something like the current "safest" option we have. We won't be able to enable this by default probably forever as the breakage is too high, irrespective of the transport being used.

Additionally, see section 3.3 of the design proposal linked to above.

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

Changed 7 weeks ago by antonela

Attachment: 25658-preferences.png added

Changed 7 weeks ago by antonela

Attachment: 25658 - 7.png added

comment:35 Changed 7 weeks ago by antonela

Hi geko, thanks for the heads-up; already read the diff. Seems like you have a strong opinion for keeping the slider.

Let's do it again:

2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar

OK

2.1.2 Showing Security Slider State

We tried this before and this is the latest prototype I have: ​

https://marvelapp.com/383eaa9/screen/44007368

Should we iterate over it again? Are we happy with the icon? Do we want a different icon?

To mitigate that problem we could at least warn users about the possible danger and provide the option to acquire a New Identity right after changing the security slider level.

Suggest a New Identity after the global setting change, seems smart. We can do that right after the user change about:preferences#security. A message that says "You may need a New Identity to apply changes safely. Your tabs will reload, and some information could be missed" will help.

We'll add a security settings button to the toolbar which shows the current slider state but, once clicked on, opens an about:preferences panel in a new tab which contains the security slider.

Something like this?
https://trac.torproject.org/projects/tor/raw-attachment/ticket/25658/25658-preferences.png

2.1.3 Reorganizing the Toolbar

OK

2.2 Dealing with Per-Site Security Settings

One way to do that would be to use the Permissions section which opens after clicking on the "i" icon in the URL bar.

Ok. It should look similar to

https://trac.torproject.org/projects/tor/raw-attachment/ticket/25658/25658%20-%207.png

We should refrain from exposing icons for every single "active content" in the URL bar, though. Rather, besides the button for temporarily allowing JavaScript we would only add one additional, which is responsible for manipulating and showing the state of "active content" (like WebGL, SVG, fonts etc.).

Where do you think it should have place? At the Control Center doorhanger?

Last edited 7 weeks ago by antonela (previous) (diff)

comment:36 in reply to:  35 ; Changed 7 weeks ago by gk

Replying to antonela:

Hi geko, thanks for the heads-up; already read the diff. Seems like you have a strong opinion for keeping the slider.

Not at all. I do want, though, not lower the security guarantees AND the usability we currently offer. So, the redesign we currently have in mind should provide the same guarantees + better usability. If we get to that then that's a good result for this iteration with hopefully other iterations to come.

comment:37 in reply to:  36 ; Changed 7 weeks ago by arthuredelstein

Replying to gk:

The security risks don't map the the underlying transport ot its security being used. The security risks we try to tackle are to a large part due to the *content* that gets transferred. Someone injecting this content on the path from server to user is an important risk but just one of those we need to defend against. This binding the security state to HTTP/HTTPS is not sufficient. Moreover, the strongest security we want to provide is something like the current "safest" option we have. We won't be able to enable this by default probably forever as the breakage is too high, irrespective of the transport being used.

We have discussed this issue previously, but I wanted to try laying it out in more detail and see if that helps to clarify the different approaches. :)

We already have a "Safest" setting that maximizes security guarantees. I agree we shouldn't lower those guarantees. We also have a "Standard" (Low) setting which maximizes usability and already has the lowest possible security guarantees. That probably shouldn't change for now.

So the question is: what should the "Safer" (Medium) level be? Given that the three levels are implementing a tradeoff between security and website usability, I think we should be willing to consider any Pareto-optimal choice, even if it reduces security somewhat. What is important is that the "Safer" level is sufficiently distinct from both "Safest" and "Standard" so that it is worthwhile to make it available.

Let's compare two possible "Safer" (Medium) Security designs:

Design (1), the status quo (Tor Browser 8.0.x):

Unblocked Blocked
HTTP WebFont, blob, SVG scripts, WebGL, Video, Audio, WebAudio, MathML, JIT
HTTPS WebFont, blob, SVG, scripts, WebGL Video, Audio, WebAudio, MathML, JIT

Design (2), proposed in comment:33:

Unblocked Blocked
HTTP WebFont, blob, SVG, scripts, WebGL, Video, Audio, WebAudio, MathML, JIT
HTTPS WebFont, blob, SVG, scripts, WebGL, Video, Audio, WebAudio, MathML, JIT

So, which of these two options is more secure? (1) has better security for HTTPS and (2) has better security for HTTP. Overall security depends on one's threat model.

Consider the two main potential threats:
(A) Hostile content injected at exit nodes, or between server and exit node. To combat this threat, it seems that Design (2) is somewhat better because it blocks the most content in HTTP.
(B) Hostile content from the website itself, or subresources. Which design is safer depends on whether the hostile site is HTTP or HTTPS. If an HTTP site is hostile, Design (2) is preferred. If an HTTPS site is hostile, Design (1) is preferred.

The next question: which of the two threats are dominant in a real user's threat model? I think there are different categories of users:

(I) Users who are unconcerned about threats or unable to handle broken websites. For these users, "Standard" (Low) security is the (default) choice.
(II) Users who only visit "trustworthy" sites. (I define "trustworthy" as websites the user expects will not send malicious code.) For these users, Threat (A) is the dominant threat and in this case, "Safer" security seems appropriate, and Design (2) is better.
(III) Users who visit "untrustworthy" sites. For these users, Threat (B) can be the dominant threat. (But Threat (A) still exists for these users to the same extent as for Category (II) users. The total risk of being exploited is higher.) Assuming they are using the "Safer" level, these users may prefer Design (1), at least for HTTPS.

Perhaps, up to this point, my description is fairly uncontroversial. ;) I hope this kind of analysis is useful regardless of our final decision for the "Safer" level.


But now I want to think further about Category (III) users. These users are visiting untrustworthy websites; they are high-risk users. Why would the user want to leave SVG, WebFonts, or scripts unblocked if they think a site is untrustworthy? While it's true that some websites will work better, it seems dangerous to assume we know which type of content will be exploited by a malicious website. (I'm open to being convinced that there is a much greater risk from video than from scripts, say, but I haven't seen evidence for that.) So it seems to me that Category (III) users should generally use the "Safest" setting instead of "Safer" Design (1).

What about relative usability of these two designs for the "Safer" level? I think Design (2) is clearly more usable because:

  • Design (2) is simpler for users to understand than Design (1). For every website, we either have initial protection "on" or "off", corresponding to whether the site is high risk or low risk.
  • In Design (2), HTTPS websites (such as https://youtube.com) will work correctly by default.

To sum up, my feeling is that "Safer" level with Design (2) offers better security and better usability to users who habitually visit "trustworthy" sites only. And the "Safest" level already provides the comprehensive protections needed for high-risk users who visit "untrustworthy" sites.

Edit: Corrected my references to the lowest safety level to "Standard".

Last edited 7 weeks ago by arthuredelstein (previous) (diff)

comment:38 in reply to:  37 ; Changed 7 weeks ago by gk

Replying to arthuredelstein:

Replying to gk:

The security risks don't map the the underlying transport ot its security being used. The security risks we try to tackle are to a large part due to the *content* that gets transferred. Someone injecting this content on the path from server to user is an important risk but just one of those we need to defend against. This binding the security state to HTTP/HTTPS is not sufficient. Moreover, the strongest security we want to provide is something like the current "safest" option we have. We won't be able to enable this by default probably forever as the breakage is too high, irrespective of the transport being used.

We have discussed this issue previously, but I wanted to try laying it out in more detail and see if that helps to clarify the different approaches. :)

Design (2), proposed in comment:33:

Unblocked Blocked
HTTP WebFont, blob, SVG, scripts, WebGL, Video, Audio, WebAudio, MathML, JIT
HTTPS WebFont, blob, SVG, scripts, WebGL, Video, Audio, WebAudio, MathML, JIT

Just to reply to this item: That's not proposed in comment:33. Here is what antonela wrote:

 Again: I think that the best way to improve the security slider is removing the slider component. As mentioned before, the slider is a UI artifact that doesn't add any value to this settings. Instead, it confuses users about their benefits on upgrade or downgrade.

If we could simplify the security settings into a boolean option, we will follow the current Firefox approach on settings both in desktop and in mobile, and we will help users by making it easier to understand the trade-off: "Do I trust in this site?"

So, comment:33 proposes to reduce the slider from three options to two *in general* and bind all the security features to the transport. But you want to keep "safest", "safer", and "standard" but redo the "safer" option. So, these are different things.

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

comment:39 in reply to:  38 ; Changed 7 weeks ago by arthuredelstein

Replying to gk:

Just to reply to this item: That's not proposed in comment:33. Here is what antonela wrote:

 Again: I think that the best way to improve the security slider is removing the slider component. As mentioned before, the slider is a UI artifact that doesn't add any value to this settings. Instead, it confuses users about their benefits on upgrade or downgrade.

If we could simplify the security settings into a boolean option, we will follow the current Firefox approach on settings both in desktop and in mobile, and we will help users by making it easier to understand the trade-off: "Do I trust in this site?"

So, comment:33 proposes to reduce the slider from three options to two *in general* and bind all the security features to the transport. But you want to keep "safest", "safer", and "standard" but redo the "safer" option. So, these are different things.

My interpretation of antonela's proposal in comment:33 is that there are three global levels. See the image under "General Settings - about:preferences#security". The three radio buttons correspond to "safest", "safer" and "standard". Then each site would have two possible states: protected or unprotected.

comment:40 in reply to:  38 Changed 7 weeks ago by antonela

So, comment:33 proposes to reduce the slider from three options to two *in general* and bind all the security features to the transport.

Not really. I think that having an ON/OFF option is more natural for users to understand that having three options and we also can improve websites performance by suggesting allow or not specific permissions. I also believe that Tor Browser could be proactive on raising the security shield if the user is visiting an untrustworthy site, which could or not be an HTTP site but could be a site which has dangerous content. With this scenario, Arthur's heuristics showed that seems like Design (2) will have a better experience for users.

This feature should aim to protect users from trustworthy and untrustworthy sites while having better performance with sites breakage. If we don't improve site breakage on top security mode, then nobody uses it.

That said, my idea about having our security protection feature at the control center allows users to have a better understanding of how the security tool behavior is. It is related to one of the problems we want to solve with this ticket: users need visual feedback on which level of the slider they are.

In my proposal, we still have three options at about:preferences#security as detailed here. But the label/name of the options now is not more related to which kind of security users think they need.

comment:41 in reply to:  39 Changed 7 weeks ago by gk

Replying to arthuredelstein:

Replying to gk:

Just to reply to this item: That's not proposed in comment:33. Here is what antonela wrote:

 Again: I think that the best way to improve the security slider is removing the slider component. As mentioned before, the slider is a UI artifact that doesn't add any value to this settings. Instead, it confuses users about their benefits on upgrade or downgrade.

If we could simplify the security settings into a boolean option, we will follow the current Firefox approach on settings both in desktop and in mobile, and we will help users by making it easier to understand the trade-off: "Do I trust in this site?"

So, comment:33 proposes to reduce the slider from three options to two *in general* and bind all the security features to the transport. But you want to keep "safest", "safer", and "standard" but redo the "safer" option. So, these are different things.

My interpretation of antonela's proposal in comment:33 is that there are three global levels. See the image under "General Settings - about:preferences#security". The three radio buttons correspond to "safest", "safer" and "standard". Then each site would have two possible states: protected or unprotected.

I don't understand that. That dialog is only talking about *where* our so-called protections are applied (on all sites/only on unsecure sites/never), not *which* kind of protections. And we have two sets of protections ("safest" and "safer" however we want to structure the latter). Thus, this does not map to an on/off option: It does not say which protections apply to all sites ("safer" or "safest") and it does not say which protections apply to only unsecure ones. The dialog is only talking about "Security Protection" indicating the same group of restrictions applies to all three options given (in the first case to all sites, in the second one to unsecure ones and in the third case to none)

comment:42 Changed 7 weeks ago by gk

As a more generic comment: it seems those new proposals that showed up in the previous comments are concerned with a different bug (maybe #21034?). This bug is about implementing the proposal the description of this ticket linked to. In particular, it is concerned with the *clarification* and simplification of what we currently *have* not with a next step of how we could redesign particular slider levels or security protections we provide. While this is important it seems it requires more thinking and some data helping us decide what to do.

comment:43 in reply to:  42 ; Changed 7 weeks ago by arthuredelstein

Replying to gk:

I don't understand that. That dialog is only talking about *where* our so-called protections are applied (on all sites/only on unsecure sites/never), not *which* kind of protections. And we have two sets of protections ("safest" and "safer" however we want to structure the latter). Thus, this does not map to an on/off option: It does not say which protections apply to all sites ("safer" or "safest") and it does not say which protections apply to only unsecure ones. The dialog is only talking about "Security Protection" indicating the same group of restrictions applies to all three options given (in the first case to all sites, in the second one to unsecure ones and in the third case to none)

What I'm saying is, if we change the "Safer" (Medium) level to Design (2), then we have the same 3 levels that are in Antonela's dialog:

  • "All"
  • "Only in 'insecure' sites"
  • "None"

The "All" and "None" levels are identical to "Standard" and "Safest" in our existing 3-level security slider. So that dialog would *replace* the security slider, not supplement it.

Replying to gk:

As a more generic comment: it seems those new proposals that showed up in the previous comments are concerned with a different bug (maybe #21034?). This bug is about implementing the proposal the description of this ticket linked to. In particular, it is concerned with the *clarification* and simplification of what we currently *have* not with a next step of how we could redesign particular slider levels or security protections we provide. While this is important it seems it requires more thinking and some data helping us decide what to do.

It seemed to me this was a good time to discuss the issue because the user interface design is closely connected to the behavior of the global and per-site safety levels. If we redesign the behavior of the security levels after a UI redesign, then it will mean we have to redesign the UI yet once more.

comment:44 in reply to:  43 ; Changed 7 weeks ago by gk

Replying to arthuredelstein:

Replying to gk:
It seemed to me this was a good time to discuss the issue because the user interface design is closely connected to the behavior of the global and per-site safety levels. If we redesign the behavior of the security levels after a UI redesign, then it will mean we have to redesign the UI yet once more.

Well, maybe. I guess it depends on what new behavior we come up with. E.g. if the medium settings just change their semantics and all things stay equal then it's not that much of a change (maybe some labels would need to get adjusted) as the medium level is just a small part of the slider. But, yes, maybe there is more to change. Regardless, a bunch of things come to mind here:

1) UI design like general design and development is an iterative process. It's not finished. So, yes, we might need to redesign the UI again but that's part of the process and not necessarily something which is a bad thing per se.

2) I am not convinced the concept of a user trusting a site should play a role in defining our security slider settings. First of all, how is a user making an informed decision here and what does it mean at all "that a user expects a website will not sending malicious code" to a normal user? Secondly, we hardly want to redesign our slider every time our user live through a big change in trustworthiness, say, because of recent events in news. Rather, I think we as experts should take the burden off of users to decide "Is foo.com trustworthy right now" providing security settings based on hard data and a threat model. Thirdly, the recent security release made by Firefox is still vivid in my mind. It fixed two RCEs in JIT code. There would be no protections against those on the new "medium" level for HTTPS users. I think that's the wrong trade-off given our list of adversaries and their capabilities (e.g. compromising ad servers to serve malware which happened in the past) and the high amount of exploitability in that component and that not allowing JIT is to a very large extent not something that comes with functionality loss. (There is more to say to your proposal, of course. A good place for that would be on our mailing list, once we discuss a concrete proposal for redesigning the semantics of our slider settings, which brings me to my third point)

3) It's not clear to me that we actually need the compromise you are envisioning in comment:37. Maybe we can fix up the vast majority of the medium level shortcomings, as said in section 3.3 in the proposal we discussed, and that would already be enough to make the medium level usable? Maybe we could even set it as the default mode then given the Tor Browser context? Or even just ship two possible settings which would correspond to "safer" and "safest" as we have them today? So, it seems smart to me to revisit the semantics of the slider once we solved the low-hanging fruits.

comment:45 in reply to:  35 ; Changed 7 weeks ago by gk

Replying to antonela:

Hi geko, thanks for the heads-up; already read the diff. Seems like you have a strong opinion for keeping the slider.

Let's do it again:

2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar

OK

2.1.2 Showing Security Slider State

We tried this before and this is the latest prototype I have: ​

https://marvelapp.com/383eaa9/screen/44007368

Should we iterate over it again? Are we happy with the icon? Do we want a different icon?

Works for me.

To mitigate that problem we could at least warn users about the possible danger and provide the option to acquire a New Identity right after changing the security slider level.

Suggest a New Identity after the global setting change, seems smart. We can do that right after the user change about:preferences#security. A message that says "You may need a New Identity to apply changes safely. Your tabs will reload, and some information could be missed" will help.

Well, New Identity means that tabs won't reload: the browser will close and reopen as a blank slate. But, yes, we should provide that option with a similar wording.

We'll add a security settings button to the toolbar which shows the current slider state but, once clicked on, opens an about:preferences panel in a new tab which contains the security slider.

Something like this?

Well, as I said I am not clinging to the slider element, if we think we can transport our ideas better with, say, bullets as outlined in your prototype that's fine with me. One thing we should think about, though, is the amount of space our redesign should occupy. It seems to me the (horizontal) slider has some benefits here but I am sure we could come up with a similar "small" proposal if bullets are used instead (e.g. by collapsing text of security levels not being used currently).

2.1.3 Reorganizing the Toolbar

OK

2.2 Dealing with Per-Site Security Settings

One way to do that would be to use the Permissions section which opens after clicking on the "i" icon in the URL bar.

Ok. It should look similar to

Works for me. We could think about as well showing little icons directly in the URL bar but I am not sure how much energy and time we should spend on the per-site security settings anyway. My feeling is not so much, especially compared to making the overall experience better.

We should refrain from exposing icons for every single "active content" in the URL bar, though. Rather, besides the button for temporarily allowing JavaScript we would only add one additional, which is responsible for manipulating and showing the state of "active content" (like WebGL, SVG, fonts etc.).

Where do you think it should have place? At the Control Center doorhanger?

Yes, that would be one place. But as I said above, maybe URL bar icons would be smart as well? Or maybe we should not spend time optimizing for that corner case?

Open things we still need to solve/discuss from comment:26:

 We still need to work on informing users that NoScript and HTTSEverywhere icons are available to be placed at the Top Nav via Menu/Customize. We could include a step/card explaining it at the new onboarding.

Also, current about:preferences at FF60 doesn't have a [SAVE] button to confirm the action. Do you think we need to add an intermediate step for users to verify their radio option pick? May we need it for anything else?

EDIT: There is actually another item brought up in comment:29 to rename what we have to "Feature filter" while we are at it.

One final thought: What do we do in the new design once a user flips a preference that is governed by our security controls essentially kicking themselves off that security level to something custom? Right now our UI gives the hint with the option to restore the default state. It seems to me we should keep that in the new UI as well.


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

comment:46 in reply to:  44 Changed 7 weeks ago by arthuredelstein

Replying to gk:

1) UI design like general design and development is an iterative process. It's not finished. So, yes, we might need to redesign the UI again but that's part of the process and not necessarily something which is a bad thing per se.

I completely agree. But I think it makes sense to fully analyze the problem and proposed solution as much as we can, as early as possible. In particular I think the per-site security UI may depend on the semantics we choose.

2) I am not convinced the concept of a user trusting a site should play a role in defining our security slider settings.

I can say, personally, my security slider setting choice depends in part on my perception of the overall trustworthiness of the kinds of sites I tend to visit, but it's possible I may be an exception. What is your model for how the user will interpret the security levels and make this security/usability tradeoff?

More broadly, I think we should explicitly answer: what problem are we trying to solve with the security levels? Are we trying to defend against Threat (A) or (B) or both? How is our design intended to solve that problem? If users are not equipped to make security assessments, then why are we giving them a choice of different security levels? I feel these first-principle questions haven't been concretely addressed to guide our design.

I think we as experts should take the burden off of users to decide "Is foo.com trustworthy right now" providing security settings based on hard data and a threat model.

I agree, that would be ideal. To me it suggests a sort of "Google Safe Browsing"-style blocklist rather than a security slider. Now, it may be such a blocklist is impractical for us, but we should decide what the security slider is offering instead.

Thirdly, the recent security release made by Firefox is still vivid in my mind. It fixed two RCEs in JIT code. There would be no protections against those on the new "medium" level for HTTPS users. I think that's the wrong trade-off given our list of adversaries and their capabilities (e.g. compromising ad servers to serve malware which happened in the past) and the high amount of exploitability in that component and that not allowing JIT is to a very large extent not something that comes with functionality loss.

Good point. Maybe we could even disable the JIT always (for every security level), if it isn't a usability concern.

3) It's not clear to me that we actually need the compromise you are envisioning in comment:37. Maybe we can fix up the vast majority of the medium level shortcomings, as said in section 3.3 in the proposal we discussed, and that would already be enough to make the medium level usable?

Maybe! But to me an important part of usability for Medium is to allow HTML5 videos to work without hassle on HTTPS. Our existing poor usability in that area means, I think, that some users will downgrade to Standard security. I don't think getting click-to-play video to work smoothly is going to be easy, though I might be wrong. In any case at least we should try to make this design decision explicit.

comment:47 Changed 6 weeks ago by antonela

Replying to gk:

Well, New Identity means that tabs won't reload: the browser will close and reopen as a blank slate. But, yes, we should provide that option with a similar wording.

I that case "Restart to apply changes" is the safest suggestion we can do.

Well, as I said I am not clinging to the slider element, if we think we can transport our ideas better with, say, bullets as outlined in your prototype that's fine with me. One thing we should think about, though, is the amount of space our redesign should occupy. It seems to me the (horizontal) slider has some benefits here but I am sure we could come up with a similar "small" proposal if bullets are used instead (e.g. by collapsing text of security levels not being used currently).

Cool. I think the radio button options will work better at the preferences section. Yes, we can collapse the details in the future.

Works for me. We could think about as well showing little icons directly in the URL bar but I am not sure how much energy and time we should spend on the per-site security settings anyway. My feeling is not so much, especially compared to making the overall experience better.[...] Yes, that would be one place. But as I said above, maybe URL bar icons would be smart as well? Or maybe we should not spend time optimizing for that corner case?

Ok. I made a mockup for it. If we want to have the same userflow the Block Content feature have, then we will need an icon for "Javascript" and "Active Content." I'm using the permissions icon at the URL bar now to show that some permission have been granted. Two icons are not too much. Firefox has this scenario when you block the microphone and the camera at the same time, for example.

We still need to work on informing users that NoScript and HTTSEverywhere icons are available to be placed at the Top Nav via Menu/Customize. We could include a step/card explaining it at the new onboarding.

Yep. Once the previous items are ready and approved, I'll move to the onboarding card.

Also, current about:preferences at FF60 doesn't have a [SAVE] button to confirm the action. Do you think we need to add an intermediate step for users to verify their radio option pick? May we need it for anything else?

Yes, we need users to confirm the Restart to apply changes.

There is actually another item brought up in comment:29 to rename what we have to "Feature filter" while we are at it.

I agree with roger about the behavior of the tool. But, I don't think this renaming improves user comprehension on what is happening.

One final thought: What do we do in the new design once a user flips a preference that is governed by our security controls essentially kicking themselves off that security level to something custom? Right now our UI gives the hint with the option to restore the default state. It seems to me we should keep that in the new UI as well.

Yes, the next comment includes a 3.X section that contemplates that user story. Both, global and per-site settings.

Changed 6 weeks ago by antonela

Attachment: 25658 - 8.png added

comment:48 Changed 6 weeks ago by antonela

2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar - Done

2.1.2 Showing Security Slider State

Since the shield icon is being used by Firefox for the Content Blocking feature, I made a new one for the Tor Security Settings.

I think is better if when users click to the icon, they go directly to about:preferences#security page.

Both Safer and Safest levels will have the firefox violet active color once active.
Both Safer and Safest levels will have permissions per-site.

2.1.2.X Change Security Level and Restart to Apply Changes

As we discussed, once a user changes the security level Tor Browser needs to restart to apply changes. The safest way to do it is restarting with a new identity.

2.1.3 Reorganizing the Toolbar - Done

2.2 Dealing with Per-Site Security Settings

Safer level will allow enabling javascript per session.
Safest level will allow enabling javascript and active content per session.

3.x Restore Default Security Settings

When a user wants to have their current per-site Preference back to default (javascript nor active content allowed), it can use the [x] at the control center and a message will appear, as current firefox, "You may need to reload to apply changes."

When a user wants to have the global Security Settings back to default, then they can click to "Default" in about:preferences#security and a prompt will appear to confirm the Restart with new identity.

Here is the concept. If all the details above are ok, I'll update the prototype.

https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658%20-%208.png

Last edited 6 weeks ago by antonela (previous) (diff)

comment:49 in reply to:  9 ; Changed 6 weeks ago by cypherpunks3

Replying to antonela:

Replying to cypherpunks:

(Also a note on the about:preferences changes: I think they're unnecessary since the functionality would already be offered by the security button, so there's no need for duplicate effort)

Well, we don't want to have the slider on the Top bar UI. The doorhanger is just showing the security setting description + a call to action in the case the user wants to change it. So if the user wants to change the security setting, they should go to about:preferences to upgrade or downgrade their setup.

This makes it much more impractical, you have to go to a new tab with about:preferences just to change the security slider and it has the unintended side effect of making the user think that it's 'okay' to mess with stuff on about:preferences.

comment:50 in reply to:  49 Changed 6 weeks ago by antonela

Replying to cypherpunks3:

Replying to antonela:

Replying to cypherpunks:

(Also a note on the about:preferences changes: I think they're unnecessary since the functionality would already be offered by the security button, so there's no need for duplicate effort)

Well, we don't want to have the slider on the Top bar UI. The doorhanger is just showing the security setting description + a call to action in the case the user wants to change it. So if the user wants to change the security setting, they should go to about:preferences to upgrade or downgrade their setup.

This makes it much more impractical, you have to go to a new tab with about:preferences just to change the security slider and it has the unintended side effect of making the user think that it's 'okay' to mess with stuff on about:preferences.

Yes. The security slider settings apply globally. You can start to think this user flow making a question: When do users upgrade or downgrade their security? Then you will realize that the *trigger* usually comes from the current site/tab there are visiting, or they are willing to attend.

The best part now is that we are planning to allow per-site permissions. So, if you are a user in the highest security mode and some site you are visiting have bad performance (gets broken), but you trust in that site, and you are okay with javascript running there, then you can allow it temporary. With this scenario, you don't need to change your global setting, but a temporary feature is enabled in the current tab.

That is cool. We are avoiding this common user pattern when users downgrade their security because they want to visit an specific site and then they never go up again.

There are no reasons for you as a non-technical user to mess stuff in about:preferences because you will have there the same three options without global granular settings. You can downgrade or upgrade your overall security, and your browser will restart to apply changes.

comment:51 in reply to:  48 ; Changed 6 weeks ago by kevun

I love the way this looks. The only thing I see here that might be a bit confusing is that Safer and Safest have the same icon on the UI.

As someone who is a little on the paranoid sign, being able to verify my security settings at a glance would be super appreciated! It also makes sure that others who are expecting Safest security settings aren't accidentally downgraded.

Maybe the only difference should be that the onion is fully colored purple?

Replying to antonela:

2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar - Done

2.1.2 Showing Security Slider State

Since the shield icon is being used by Firefox for the Content Blocking feature, I made a new one for the Tor Security Settings.

I think is better if when users click to the icon, they go directly to about:preferences#security page.

Both Safer and Safest levels will have the firefox violet active color once active.
Both Safer and Safest levels will have permissions per-site.

2.1.2.X Change Security Level and Restart to Apply Changes

As we discussed, once a user changes the security level Tor Browser needs to restart to apply changes. The safest way to do it is restarting with a new identity.

2.1.3 Reorganizing the Toolbar - Done

2.2 Dealing with Per-Site Security Settings

Safer level will allow enabling javascript per session.
Safest level will allow enabling javascript and active content per session.

3.x Restore Default Security Settings

When a user wants to have their current per-site Preference back to default (javascript nor active content allowed), it can use the [x] at the control center and a message will appear, as current firefox, "You may need to reload to apply changes."

When a user wants to have the global Security Settings back to default, then they can click to "Default" in about:preferences#security and a prompt will appear to confirm the Restart with new identity.

Here is the concept. If all the details above are ok, I'll update the prototype.

https://trac.torproject.org/projects/tor/attachment/ticket/25658/25658%20-%208.png

Last edited 6 weeks ago by kevun (previous) (diff)

comment:52 in reply to:  51 ; Changed 6 weeks ago by pili

Replying to kevun:

I love the way this looks. The only thing I see here that might be a bit confusing is that Safer and Safest have the same icon on the UI.

Maybe we can have the safest onion be green? Plus points for using the styleguide colours :)

comment:53 Changed 6 weeks ago by gk

Keywords: TorBrowserTeam201811 added; TorBrowserTeam201810 removed

Moving our tickets to November.

comment:54 in reply to:  52 Changed 6 weeks ago by mcs

Replying to pili:

Replying to kevun:

I love the way this looks. The only thing I see here that might be a bit confusing is that Safer and Safest have the same icon on the UI.

Maybe we can have the safest onion be green? Plus points for using the styleguide colours :)

As someone who is red/green color impaired, I don't think it is a good idea to rely on color as the only distinguishing trait. I like the idea of having three icons (for Default, Safer, and Safest) that differ in some way even if we were to render them without color (but using color is good too).

Last edited 5 weeks ago by mcs (previous) (diff)

comment:55 Changed 5 weeks ago by antonela

Based on last meeting discussions:

2.1.2 Showing Security Slider State
Doorhanger, icon and about:preferences#privacy
https://marvelapp.com/a66fg97/screen/50307815

2.1.2.X Change Security Level and Restart to Apply Changes
I made two options for this, and i think we may need to consider a third one too.

If a user is downgrading their security level, then we can have one of this options:

  • a] a micro button
  • b] a top stripe alert

If a user is upgrading, I'm not sure if the previous options are strong enough to encourage users to restart. If jumping the restart will put users in risk, then we can consider having a full-page warning.

a] downgrade, safest → safer https://marvelapp.com/a66fg97/screen/50342988
b] downgrade, safest → safer https://marvelapp.com/a66fg97/screen/50342987

2.2 Dealing with Per-Site Security Settings - only safer and safest mode
Users will be able to enable javascript and active content per site, only on safer and safest mode. They can easily switch them at the Control Center.
https://marvelapp.com/a66fg97/screen/50307825

3.x Restore Default Security Settings
All features in firefox:preferences have a short (two lines) description about how they work. I included a draft copy there and also the default Restore Defaults button.
https://marvelapp.com/a66fg97/screen/50343707

comment:56 in reply to:  55 ; Changed 5 weeks ago by gk

Replying to antonela:

Based on last meeting discussions:

2.1.2 Showing Security Slider State
Doorhanger, icon and about:preferences#privacy
https://marvelapp.com/a66fg97/screen/50307815

What about mcs's comment:54 which seems like a good thing to do to me.

comment:57 in reply to:  56 ; Changed 5 weeks ago by antonela

Replying to gk:

What about mcs's comment:54 which seems like a good thing to do to me.

Yes, is a good thing. But we have been trying to have a different icon for each state since March. The iterations I made were 8 and nothing seems to convince us.

This idea aims to have *one* icon that people can rely upon to refer to security settings and as a plus, we have the doorhanger, one click far, to have more information. Pretty similar on what Firefox is doing with their privacy features.

If you think that having a number solves this requirement, like what you have cited in your proposal, I'm in. Despite the fact that is hard for non-technical users to define if the security is incremental and defer it by numbers, is ok if you think that this is the way to indicate users their security level. 1 is the default? 2 is safer? 3 is safest?

Mockup:

https://trac.torproject.org/projects/tor/raw-attachment/ticket/25658/25658%20-%209.png

Last edited 5 weeks ago by antonela (previous) (diff)

Changed 5 weeks ago by antonela

Attachment: 25658 - 9.png added

comment:58 in reply to:  57 ; Changed 5 weeks ago by gk

Replying to antonela:

Replying to gk:

What about mcs's comment:54 which seems like a good thing to do to me.

Yes, is a good thing. But we have been trying to have a different icon for each state since March. The iterations I made were 8 and nothing seems to convince us.

What happened to those suggestions in comment:26?

comment:59 in reply to:  58 Changed 5 weeks ago by pili

Replying to gk:

Replying to antonela:

Replying to gk:

What about mcs's comment:54 which seems like a good thing to do to me.

Yes, is a good thing. But we have been trying to have a different icon for each state since March. The iterations I made were 8 and nothing seems to convince us.

What happened to those suggestions in comment:26?

That could be interesting to explore with the onion analogy you have safe which shows all the layers of the onion, safer which shows half the layers (similar to what we have for the tor browser icon) and safest which shows no onion layers...

Last edited 5 weeks ago by pili (previous) (diff)

comment:60 in reply to:  58 Changed 5 weeks ago by antonela

Replying to gk:

What happened to those suggestions in comment:26?

As i said in comment:48, the shield icon is being used by firefox for the content blocking feature.

https://support.mozilla.org/en-US/kb/control-center-site-privacy-and-security-firefox#w_content-blocking

If this is not relevant for our browser, then we can use a shield icon.

comment:61 Changed 5 weeks ago by brade

If we need to stick with the padlock, I think it would be clearer if state "1" was an unlocked padlock vs. 2 and 3 with the locked padlock. Do you have space to "open" the padlock for state 1?

Changed 4 weeks ago by antonela

Attachment: 25658 - 10.png added

comment:62 in reply to:  61 Changed 4 weeks ago by antonela

Replying to brade:

If we need to stick with the padlock, I think it would be clearer if state "1" was an unlocked padlock vs. 2 and 3 with the locked padlock. Do you have space to "open" the padlock for state 1?

At the first iterations of this ticket, the initial feedback I received was to don't show the first state as insecure because using Tor Browser on default mode is safer than regular browsers. What is true.

That said, I gave a try
https://trac.torproject.org/projects/tor/raw-attachment/ticket/25658/25658%20-%2010.png

Changed 4 weeks ago by pili

Attachment: onions-security.png added

comment:63 Changed 4 weeks ago by pili

If the shield doesn't work out, I made this up out of antonela's tor browser icon:

https://trac.torproject.org/projects/tor/raw-attachment/ticket/25658/onions-security.png

Changed 4 weeks ago by mcs

Attachment: TB 8.0.3 custom prefs.png added

Tor Browser 8.0.x security dialog after a pref governed by the slider has been flipped via about:config

comment:64 in reply to:  45 ; Changed 4 weeks ago by mcs

Replying to gk:

One final thought: What do we do in the new design once a user flips a preference that is governed by our security controls essentially kicking themselves off that security level to something custom? Right now our UI gives the hint with the option to restore the default state. It seems to me we should keep that in the new UI as well.

For reference, the following screenshot shows how that looks in the current design (Tor Browser 8.0.x):

Tor Browser 8.0.x security dialog after a pref governed by the slider has been flipped via about:config

comment:65 in reply to:  64 ; Changed 4 weeks ago by antonela

Replying to mcs:

Replying to gk:

One final thought: What do we do in the new design once a user flips a preference that is governed by our security controls essentially kicking themselves off that security level to something custom? Right now our UI gives the hint with the option to restore the default state. It seems to me we should keep that in the new UI as well.

To be on the same page about this specific user story:
I'm a technical user at the safest mode and I cannot see a .svg content. I go to about:config and I enable .svg support. Then I'm back to my tab, I reload and see the blocked content now.

How do we want this kind of Restore Defaults work? per tab or global?
How thisRestore Defaults works now? Does it put the current security setting level at default? or does it put the general settings to default?

For both cases, I'd add an alert at the doorhanger and lead the user restore defaults at about:preferences#security, as illustrated in comment:55
https://marvelapp.com/a66fg97/screen/50343707

comment:66 Changed 4 weeks ago by antonela

As we signed yesterday, the prototype is updated with the shield icon.
https://marvelapp.com/a66fg97/screen/50307815

comment:67 in reply to:  65 ; Changed 4 weeks ago by gk

Replying to antonela:

Replying to mcs:

Replying to gk:

One final thought: What do we do in the new design once a user flips a preference that is governed by our security controls essentially kicking themselves off that security level to something custom? Right now our UI gives the hint with the option to restore the default state. It seems to me we should keep that in the new UI as well.

To be on the same page about this specific user story:
I'm a technical user at the safest mode and I cannot see a .svg content. I go to about:config and I enable .svg support. Then I'm back to my tab, I reload and see the blocked content now.

Yes.

How do we want this kind of Restore Defaults work? per tab or global?

Gobal. The preferences that are governed by the slider and causing the "custom" mode are global as well.

How thisRestore Defaults works now? Does it put the current security setting level at default? or does it put the general settings to default?

It keeps all prefs from the current level and which did not get flipped as they are the dialog and button mcs included above is shown. If defaults are restored the users goes back to the security level they were on before flipping prefs in about:config.

For both cases, I'd add an alert at the doorhanger and lead the user restore defaults at about:preferences#security, as illustrated in comment:55
https://marvelapp.com/a66fg97/screen/50343707

Sounds good. We probably should grey out the security settings on the about:preferences page indicating additionally that the user is in custom mode until they restored reset they settings to one of the three defaults.

comment:68 in reply to:  66 ; Changed 4 weeks ago by gk

Replying to antonela:

As we signed yesterday, the prototype is updated with the shield icon.
https://marvelapp.com/a66fg97/screen/50307815

We did not talk about the restart "options" yesterday. Are those two you have included in the prototype two options for the same thing or are they supposed to show up at the same time or...?

I am wondering whether we should just strongly encourage to restart after the slider level change or indeed require a restart before the new settings are applied. I am inclined to do the former as this feels more natural on that preference pane given that all the other options "go live" once the users selects them. But I don't feel too strongly about it.

comment:69 in reply to:  67 Changed 4 weeks ago by antonela

Replying to gk:

Sounds good. We probably should grey out the security settings on the about:preferences page indicating additionally that the user is in custom mode until they restored reset they settings to one of the three defaults.

Great. I'm using default Firefox Photon warnings and I made a quick prototype to see how it works. Grey out is a good option, not sure if strong enough, but the change is visible when users go back to a tab or open a new one. We have a redundant link to about:preferences#security. Not bad, tho.

https://marvelapp.com/a66fg97/screen/50307825 - open a new tab to start the flow
https://design.firefox.com/photon/patterns/warnings.html

comment:70 in reply to:  68 Changed 4 weeks ago by antonela

Replying to gk:

We did not talk about the restart "options" yesterday. Are those two you have included in the prototype two options for the same thing or are they supposed to show up at the same time or...?

yes, two options for the same intent.

I am wondering whether we should just strongly encourage to restart after the slider level change or indeed require a restart before the new settings are applied. I am inclined to do the former as this feels more natural on that preference pane given that all the other options "go live" once the users selects them. But I don't feel too strongly about it.

Agreed. The option a] is a typical pattern in Chrome70. It is great because the button pill shows up right close to the cursor pointer. The user attention is already there. The option b] is using a Firefox warning approach.

a] downgrade, safest → safer ​https://marvelapp.com/a66fg97/screen/50342988
b] downgrade, safest → safer ​https://marvelapp.com/a66fg97/screen/50342987

Which one do you prefer?

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

comment:71 Changed 13 days ago by gk

Keywords: TorBrowserTeam201812 GeorgKoppen201812 added; TorBrowserTeam201811 removed

comment:72 Changed 6 days ago by gk

Cc: arthuredelstein added

#22980 is a duplicate.

comment:73 in reply to:  31 Changed 6 days ago by gk

Replying to gk:

#27511 is a duplicate (for the "New Identity" on the toolbar part).

Thinking more about it that's the wrong decision. Let's have this idea in an own ticket and do not clutter this bug more with orthogonal features. I reopened #27511.

comment:74 Changed 3 days ago by gk

Note to self: we need to adapt the onboarding here as well, pointing to the new place of the settings.

Note: See TracTickets for help on using tickets.