Opened 7 months ago

Last modified 6 weeks 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, TorBrowserTeam201805
Cc: tbb-team, dmr, isnaiter 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

Attachments (12)

25658.png (1.0 MB) - added by antonela 7 months ago.
25658-exploration.png (204.0 KB) - added by antonela 7 months ago.
25658 - Settings Radio.png (576.1 KB) - added by antonela 6 months ago.
25658 - 2.png (768.1 KB) - added by antonela 6 months ago.
25658-exploration 2.png (224.4 KB) - added by antonela 6 months ago.
Image-1.jpg (76.6 KB) - added by hiro 6 months ago.
firefox focus
brave-shield-1.png (1.2 MB) - added by antonela 6 months ago.
brave-shield-2.png (347.3 KB) - added by antonela 6 months ago.
25658 - 3.png (472.3 KB) - added by antonela 6 months ago.
25658 - 4.png (628.9 KB) - added by antonela 6 months ago.
25658 - 5.png (1.0 MB) - added by antonela 6 months ago.
TBB8-UI-Security-Settings.png (771.8 KB) - added by antonela 4 months ago.

Change History (43)

comment:1 Changed 7 months ago by isabela

Description: modified (diff)

comment:2 Changed 7 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 7 months ago by antonela

Attachment: 25658.png added

Changed 7 months ago by antonela

Attachment: 25658-exploration.png added

comment:3 Changed 7 months ago by gk

Cc: tbb-team added

comment:4 Changed 7 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 7 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 7 months ago by antonela (previous) (diff)

comment:6 in reply to:  4 Changed 7 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 6 months ago by gk

Keywords: TorBrowserTeam201804 added
Priority: MediumHigh

comment:8 Changed 6 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 6 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 6 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 6 months ago by antonela

Attachment: 25658 - Settings Radio.png added

comment:11 in reply to:  10 Changed 6 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 6 months ago by antonela

Attachment: 25658 - 2.png added

comment:12 Changed 6 months ago by dmr

Cc: dmr added

Changed 6 months ago by antonela

Attachment: 25658-exploration 2.png added

comment:13 Changed 6 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 6 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 6 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 6 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 6 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 6 months ago by hiro (previous) (diff)

Changed 6 months ago by hiro

Attachment: Image-1.jpg added

firefox focus

comment:18 Changed 6 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 6 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 6 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 6 months ago by hiro (previous) (diff)

Changed 6 months ago by antonela

Attachment: brave-shield-1.png added

Changed 6 months ago by antonela

Attachment: brave-shield-2.png added

Changed 6 months ago by antonela

Attachment: 25658 - 3.png added

Changed 6 months ago by antonela

Attachment: 25658 - 4.png added

comment:21 Changed 6 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 6 months ago by antonela

Attachment: 25658 - 5.png added

comment:22 Changed 6 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 6 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 6 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 5 months ago by gk

Keywords: TorBrowserTeam201805 added; TorBrowserTeam201804 removed

Move our roadmap tickets to May.

Changed 4 months ago by antonela

comment:26 Changed 4 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 4 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 4 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 3 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 3 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 6 weeks ago by gk

Cc: isnaiter added

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

Note: See TracTickets for help on using tickets.