Opened 16 months ago

Last modified 7 weeks ago

#25658 new 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, GeorgKoppen201812, TorBrowserTeam201904
Cc: tbb-team, dmr, isnaiter, arthuredelstein, mcs, brade 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
#23359closedpospeselrWebExtensions icons are not shown on first start but on restartApplications/Tor Browser
#27478closedpospeselrTorbutton in Tor Browser 8 difficult to see in dark themeApplications/Tor Browser
#28628closeddunqanIntroduce New Security Settings to usersApplications/Tor Browser
#29554closedpospeselrabout:preferences hash urls do not work properly in Tor BrowserApplications/Tor Browser
#29657closedpospeselrChange the 'Learn More' links in the securitylevel component to point to new documentationApplications/Tor Browser
#29768closedtbb-teamIntroduce new features to users in Tor BrowserApplications/Tor Browser
#29795closedemmapeelAdd new Torbutton file securityLevel.properties to the translations repoCommunity/Translations
#29825closedpospeselrIntelligently insert the Security Level button to the user's taskbar rather than resetting to default on upgradeApplications/Tor Browser
#29886newtbb-teamNoScript icon is still visible in context menu after the fix for #25658 landedApplications/Tor Browser
#29973closedtbb-teamRemove remaining stopOpenSecuritySettingsObserver() piecesApplications/Tor Browser
#30104closedtbb-teambrowser onboarding: 8.5 security level image includes English textApplications/Tor Browser
#30570newtbb-teamImplement per-site security settings supportApplications/Tor Browser

Attachments (36)

25658.png (1.0 MB) - added by antonela 16 months ago.
25658-exploration.png (204.0 KB) - added by antonela 16 months ago.
25658 - Settings Radio.png (576.1 KB) - added by antonela 15 months ago.
25658 - 2.png (768.1 KB) - added by antonela 15 months ago.
25658-exploration 2.png (224.4 KB) - added by antonela 15 months ago.
Image-1.jpg (76.6 KB) - added by hiro 15 months ago.
firefox focus
brave-shield-1.png (1.2 MB) - added by antonela 15 months ago.
brave-shield-2.png (347.3 KB) - added by antonela 15 months ago.
25658 - 3.png (472.3 KB) - added by antonela 15 months ago.
25658 - 4.png (628.9 KB) - added by antonela 15 months ago.
25658 - 5.png (1.0 MB) - added by antonela 15 months ago.
TBB8-UI-Security-Settings.png (771.8 KB) - added by antonela 13 months ago.
25658 - 6.0.png (296.6 KB) - added by antonela 9 months ago.
25658 - 6.1.png (304.4 KB) - added by antonela 9 months ago.
25658 - 6.2.png (291.0 KB) - added by antonela 9 months ago.
25658 - 6.3.png (194.2 KB) - added by antonela 9 months ago.
25658 - 6.4.png (260.9 KB) - added by antonela 9 months ago.
25658-preferences.png (442.0 KB) - added by antonela 9 months ago.
25658 - 7.png (229.3 KB) - added by antonela 9 months ago.
25658 - 8.png (1.2 MB) - added by antonela 9 months ago.
25658 - 9.png (159.2 KB) - added by antonela 8 months ago.
25658 - 10.png (158.6 KB) - added by antonela 8 months ago.
onions-security.png (100.2 KB) - added by pili 8 months ago.
TB 8.0.3 custom prefs.png (55.7 KB) - added by mcs 8 months ago.
Tor Browser 8.0.x security dialog after a pref governed by the slider has been flipped via about:config
assets.zip (9.6 KB) - added by antonela 7 months ago.
screenshot01.png (43.1 KB) - added by pospeselr 4 months ago.
screenshot02.png (98.5 KB) - added by pospeselr 4 months ago.
screenshot03.png (38.4 KB) - added by pospeselr 4 months ago.
screenshot04.png (101.9 KB) - added by pospeselr 4 months ago.
screenshot05.png (76.4 KB) - added by pospeselr 4 months ago.
about:preferences tweaks
Captura de pantalla 2019-03-07 a la(s) 12.48.15 p. m..png (794.0 KB) - added by antonela 4 months ago.
3.0.3-restore-defaults.png (50.0 KB) - added by antonela 4 months ago.
3.x-restore-defaults.png (105.8 KB) - added by antonela 4 months ago.
screenshot06.png (79.9 KB) - added by pospeselr 4 months ago.
0001-fixup-Bug-25658-Replace-security-slider-with-securit.patch (2.8 KB) - added by mcs 4 months ago.
fixup to relocate the Torbutton toolbar item
25658 - 2.2.png (476.2 KB) - added by antonela 4 months ago.

Change History (154)

comment:1 Changed 16 months ago by isabela

Description: modified (diff)

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

Attachment: 25658.png added

Changed 16 months ago by antonela

Attachment: 25658-exploration.png added

comment:3 Changed 16 months ago by gk

Cc: tbb-team added

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

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

Keywords: TorBrowserTeam201804 added
Priority: MediumHigh

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

Attachment: 25658 - Settings Radio.png added

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

Attachment: 25658 - 2.png added

comment:12 Changed 15 months ago by dmr

Cc: dmr added

Changed 15 months ago by antonela

Attachment: 25658-exploration 2.png added

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

Changed 15 months ago by hiro

Attachment: Image-1.jpg added

firefox focus

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

Changed 15 months ago by antonela

Attachment: brave-shield-1.png added

Changed 15 months ago by antonela

Attachment: brave-shield-2.png added

Changed 15 months ago by antonela

Attachment: 25658 - 3.png added

Changed 15 months ago by antonela

Attachment: 25658 - 4.png added

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

Attachment: 25658 - 5.png added

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

Keywords: TorBrowserTeam201805 added; TorBrowserTeam201804 removed

Move our roadmap tickets to May.

Changed 13 months ago by antonela

comment:26 Changed 13 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 13 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 13 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 12 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 12 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 10 months ago by gk

Cc: isnaiter added

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

comment:32 Changed 9 months ago by gk

Keywords: TorBrowserTeam201810 added; TorBrowserTeam201805 removed

Changed 9 months ago by antonela

Attachment: 25658 - 6.0.png added

Changed 9 months ago by antonela

Attachment: 25658 - 6.1.png added

Changed 9 months ago by antonela

Attachment: 25658 - 6.2.png added

Changed 9 months ago by antonela

Attachment: 25658 - 6.3.png added

Changed 9 months ago by antonela

Attachment: 25658 - 6.4.png added

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

comment:34 in reply to:  33 Changed 9 months 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 9 months ago by gk (previous) (diff)

Changed 9 months ago by antonela

Attachment: 25658-preferences.png added

Changed 9 months ago by antonela

Attachment: 25658 - 7.png added

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

comment:36 in reply to:  35 ; Changed 9 months 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 9 months 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 9 months ago by arthuredelstein (previous) (diff)

comment:38 in reply to:  37 ; Changed 9 months 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 9 months ago by gk (previous) (diff)

comment:39 in reply to:  38 ; Changed 9 months 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 9 months 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 9 months 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 9 months 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 9 months 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 9 months 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 9 months 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 9 months ago by gk (previous) (diff)

comment:46 in reply to:  44 Changed 9 months 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 9 months 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 9 months ago by antonela

Attachment: 25658 - 8.png added

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

comment:49 in reply to:  9 ; Changed 9 months 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 9 months 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 9 months 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 9 months ago by kevun (previous) (diff)

comment:52 in reply to:  51 ; Changed 8 months 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 8 months ago by gk

Keywords: TorBrowserTeam201811 added; TorBrowserTeam201810 removed

Moving our tickets to November.

comment:54 in reply to:  52 Changed 8 months 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 8 months ago by mcs (previous) (diff)

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

Changed 8 months ago by antonela

Attachment: 25658 - 9.png added

comment:58 in reply to:  57 ; Changed 8 months 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 8 months 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 8 months ago by pili (previous) (diff)

comment:60 in reply to:  58 Changed 8 months 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 8 months 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 8 months ago by antonela

Attachment: 25658 - 10.png added

comment:62 in reply to:  61 Changed 8 months 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 8 months ago by pili

Attachment: onions-security.png added

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

comment:71 Changed 7 months ago by gk

Keywords: TorBrowserTeam201812 GeorgKoppen201812 added; TorBrowserTeam201811 removed

comment:72 Changed 7 months ago by gk

Cc: arthuredelstein added

#22980 is a duplicate.

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

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

Changed 7 months ago by antonela

Attachment: assets.zip added

comment:75 Changed 6 months ago by gk

Keywords: TorBrowserTeam201901 added; TorBrowserTeam201812 removed

Moving tickets to Jan 2019.

comment:76 Changed 5 months ago by gk

Keywords: TorBrowserTeam201902 added; TorBrowserTeam201901 removed

Moving tickets to February.

Changed 4 months ago by pospeselr

Attachment: screenshot01.png added

Changed 4 months ago by pospeselr

Attachment: screenshot02.png added

Changed 4 months ago by pospeselr

Attachment: screenshot03.png added

Changed 4 months ago by pospeselr

Attachment: screenshot04.png added

comment:77 Changed 4 months ago by pospeselr

Keywords: TorBrowserTeam201902R added; TorBrowserTeam201902 removed
Status: assignedneeds_review
Last edited 4 months ago by pospeselr (previous) (diff)

comment:78 Changed 4 months ago by gk

Cc: mcs brade added
Keywords: TorBrowserTeam201903R added; TorBrowserTeam201902R removed

comment:79 Changed 4 months ago by gk

Just from a quick glance at the screenshots. Are those from a fresh Tor Browser? I am asking because one of the ideas related to this ticket was to reorganize the toolbar while we are at it, see: https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101-security-controls-redesign.txt section 2.1. At the end we would omit the HTTPS-E and NoScript icon and the Torbutton one would be at the right side next to the URL bar. Back then when I worked on this ticket I looked at that a bit and it was not obvious at least how to prevent WebExtensions from showing their icons by default on the toolbar. But maybe I just did not look deep enough...

comment:80 in reply to:  77 Changed 4 months ago by antonela

Replying to pospeselr:

Patch for torbutton hopefully later this week!

It looks awesome! Thanks for this work pospeselr!

A few minor UI details in about:preferences#

  • Let's move the Learn More link after description. It will looks like
Disable certain web features that can be used to attack your 
security and anonymity. Learn More
  • Standard, Safer and Safest titles, could we have it in bold?
  • Could we have 2x bottom padding (probably, 6px) between each option?

comment:81 Changed 4 months ago by pospeselr

gk:

No the screenshots are not from a fresh Tor Browser, rather it's a pre-built tor-browser with the new firefox bits deployed over it. If I'm understanding things correctly, I can update the 000-torbrowser.js file to remove the extension icons from the toolbar. I'll do a full tor-browser-build once my changes for torbutton are complete and fix any other issues that pop up.

antonela:

I can make all these change (:

Changed 4 months ago by pospeselr

Attachment: screenshot05.png added

about:preferences tweaks

comment:82 Changed 4 months ago by pospeselr

Amended my tor-browser commit ( https://gitweb.torproject.org/user/richard/tor-browser.git/commit/?h=bug_25658_v3 ) to include antonela's design tweaks and removed noscript from the toolbar. Also fixed the left-align issues.

Updated about:preferences screenshot: https://trac.torproject.org/projects/tor/attachment/ticket/25658/screenshot05.png

torbutton patch: https://gitweb.torproject.org/user/richard/torbutton.git/commit/?h=bug_25658

EDIT: Will see about getting a full tor-browser-build up for macos and linux64 for y'all to try out tomorrow or so.

Last edited 4 months ago by pospeselr (previous) (diff)

comment:83 Changed 4 months ago by gk

Keywords: tbb-8.5 added

Tickets on our radar for 8.5

comment:84 Changed 4 months ago by antonela

The dark theme version looks legit

https://trac.torproject.org/projects/tor/raw-attachment/ticket/25658/Captura%20de%20pantalla%202019-03-07%20a%20la(s)%2012.48.15%20p.%20m..png

comment:85 Changed 4 months ago by pospeselr

Amended the tor-browser patch with a fix for #29554 : https://gitweb.torproject.org/user/richard/tor-browser.git/diff/browser/components/preferences/in-content/preferences.js?h=bug_25658_v3

Clicking 'Advanced Security Settings...' in the hangar now properly navigates the user to the new Security Level settings.

Amended the tor-button patch with a fix for #27478 : https://gitweb.torproject.org/user/richard/torbutton.git/diff/src/chrome/skin?h=bug_25658

Uses the context-fill and context-opacity values for the fill and opacity attributes where appropriate so the torbutton icon will now take on the same color as other firefox buttons.

Last edited 4 months ago by pospeselr (previous) (diff)

comment:86 Changed 4 months ago by mcs

This is an impressive piece of work. Kathy and I finished reviewing the tor-browser changes as well as the overall behavior. We are still working on our review of the torbutton changes but hope to post our comments later today. Here are our comments on behavior (most of these are for Antonela to look at):

  1. It would be nice to have a dynamic tooltip for the toolbar item so that the active level is visible, e.g., Security Level: Safer
  2. It would be nice to eliminate "slider" everywhere, including from the Learn more link. That will require some coordination with the maintainers of tb-manual.torproject.org. Maybe use https://tb-manual.torproject.org/.../security-settings.html
  3. The Marvel app design uses the term Default instead of Standard. Am I looking at the wrong design?
  4. The Marvel app design has an disclosure arrow (>) in the panel for "Advanced Security Settings". Is that important to include in the implementation?
  5. If custom mode is triggered, it is a little confusing that there is no text in about:preferences to encourage the user to switch back to one of the default levels (new users may even think custom is a good thing). Also, there is nothing in about:preferences that associates the Restore Defaults button with fixing the "custom problem." Finally, we might want to hide the Restore Defaults button when it is not applicable instead of disabling it (I think users will wonder why it is disabled). These issues might be worth looking at in future iteration.
  6. On macOS at least, the toolbar layout does not match the proposal. With a clean profile, the Torbutton icon is on the left side of the toolbar instead of the right side and the NoScript and HTTPS-E icons are present.
  7. Related to 6., after upgrading from an 8.5a8 profile, there is one additional problem: the security settings icon is missing from the toolbar.

comment:87 Changed 4 months ago by mcs

Status: needs_reviewneeds_revision

Here are our comments on the tor-browser changes (by the way, thanks for writing code that is nicely organized and easy to read):

High level questions for Georg and others:

  1. Should we add copyright notices to the browser/components/securitylevel/ files?
  2. Should we rename the security_slider pref and migrate the old value at this time, or later, or never? Maybe use the name torbrowser.security_level and migrate to contiguous values (1-3).

Commit message:

  1. The first line is very long. Maybe shorten to Bug 25658: Replace security slider with security level UI.
  2. s/hangar/hanger/ (two occurrences).

browser/app/profile/000-tor-browser.js - there are some additional NoScript and HTTPS-E references that should be removed from the browser.uiCustomization.state value:

  • https-everywhere-button
  • https-everywhere_eff_org-browser-action
  • _73a6fe31-595d-460b-a920-fcc0f8843232_-browser-action

securityLevelPanel.css - please combine all of the margin-related rules into one within each CSS selector block, or at least put them on adjacent lines so it is easy to spot the margin things.

securityLevel.js - SecurityLevelStrings:

  1. The intialize our strings with en-US defaults... comment seems a little backwards. Maybe replace with read localized strings from Torbutton; use hard-coded en-US strings as fallback
  2. Is it worth it to rely on the getlocale() function from Torbutton?
  3. There is one / missing after https: in the URL. It still works though!

securityLevel.js - SecurityLevelPrefs:

  1. The _str suffix for the pref name constants is a little confusing. Maybe use _pref instead.

securityLevel.js - SecurityLevelButton:

  1. Consider renaming securitySlider to securityLevel (and maybe rename the pref getter too).
  2. Kathy and I think the function name _readPrefsInternal could be better, e.g., replace all occurrences with _configUIFromPrefs().

securityLevel.js - SecurityLevelPanel:

  1. In the panel getter, _panel is set but not used anywhere else. Maybe you meant to cache that value?
  2. Remove the comment inside openAdvancedSecuritySettings().
  3. For _populateXUL(): if you have time and can do it cleanly, consider adding a helper function that sets the strings within each of the three radio sections (the code is very similar for each).

securityLevel.js - SecurityLevelPreferences:

  1. _populateXUL(): remove blank line before closing brace within vboxStandard section.

securityLevel.js - miscellaneous typos:

s/abotu/about/
s/hangar/hanger/
s/lable/label/
s/re-render/re-renders/
s/scurity/security/
s/upate/update/
s/if(/if (/

securityLevel.js - remove blank lines at the beginning of function bodies:

SecurityLevelButton.init()
SecurityLevelButton.onCustomizeEnd()
SecurityLevelPreferences.init()
SecurityLevelPreferences.selectSecurityLevel()

comment:88 in reply to:  86 Changed 4 months ago by pospeselr

Thanks mcs, that's a nice thing to say :)

  1. That sounds reasonable and easily done
  2. Agree, the link is currently a placeholder. I opened #29657 to track this.
  3. I brought this up with antonela previously, and the direction was to use Standard rather than Default
  4. I took some liberty here, and opted to use the ellipsis syntax to match the existing 'Clear Cookies and Site Data...' command at the bottom of the Site Information dialog in firefox.
  5. This sounds reasonable, will wait for antonela to comment.
  6. Yeah I *believe* the version you have doesn't have my toolbar changes. A clean build (on Linux) has NoScript and HTTPS-Everywhere removed, will have to look into the torbutton issue. #23359 will need to be fixed before the icons work correctly.
  7. This behaviour is expected as there isn't any upgrade logic in place. How is this sort of thing usually handled?

EDIT:

  1. Should we rename the security_slider pref and migrate the old value at this time, or later, or never? Maybe use the name torbrowser.security_level and migrate to contiguous values (1-3).

I initially had the same thought about renaming prefs, but I would prefer to do so in a future smaller patch where we can excise all the associated logic from torbuton as well as do a name change.

I'll try and get these changes amended asap.

Last edited 4 months ago by pospeselr (previous) (diff)

comment:89 in reply to:  86 ; Changed 4 months ago by antonela

Replying to mcs:

This is an impressive piece of work. Kathy and I finished reviewing the tor-browser changes as well as the overall behavior. We are still working on our review of the torbutton changes but hope to post our comments later today. Here are our comments on behavior (most of these are for Antonela to look at):

It is! Thanks for this review mcs/brade!

  1. It would be nice to have a dynamic tooltip for the toolbar item so that the active level is visible, e.g., Security Level: Safer

Yes, it shouldn't be so hard. To be clear, do you mean a label at the toolbar? Or a good copy that replaces this Security Settings? https://share.riseup.net/#IVhf0vupZqeSezuQSBzTGg. If is the second, then your suggestion is great.

  1. It would be nice to eliminate "slider" everywhere, including from the Learn more link. That will require some coordination with the maintainers of tb-manual.torproject.org. Maybe use https://tb-manual.torproject.org/.../security-settings.html

Agreed. I'm syncing with Maggie from the community team this week to have the Manual updated as well.

  1. The Marvel app design uses the term Default instead of Standard. Am I looking at the wrong design?

You are looking at the right design, and I think we should keep the same labels we have now. Defaults are negotiable and Standard works better for this scenario.

  1. The Marvel app design has an disclosure arrow (>) in the panel for "Advanced Security Settings". Is that important to include in the implementation?

You right. We are using the ... to announce the navigation. I think we are ok. It aims to replicate the Firefox pattern we have at the Control Center doorhanger.

  1. If custom mode is triggered, it is a little confusing that there is no text in about:preferences to encourage the user to switch back to one of the default levels (new users may even think custom is a good thing). Also, there is nothing in about:preferences that associates the Restore Defaults button with fixing the "custom problem." Finally, we might want to hide the Restore Defaults button when it is not applicable instead of disabling it (I think users will wonder why it is disabled). These issues might be worth looking at in future iteration.

Good call. We included the revert action for custom settings at the doorhanger. I think we can easily add the Restore defaults blue primary link at the selected level in about:preferences too.

  1. On macOS at least, the toolbar layout does not match the proposal. With a clean profile, the Torbutton icon is on the left side of the toolbar instead of the right side and the NoScript and HTTPS-E icons are present.

I got the same issue before and I think is because somehow we are sharing profiles between stable configuration and nightly one. Since I have more than a dozen Tor Browsers installed in my computer, I cannot debug this properly.

  1. Related to 6., after upgrading from an 8.5a8 profile, there is one additional problem: the security settings icon is missing from the toolbar.

I think this one was fixed on a recent commit. pospeselr?

comment:90 Changed 4 months ago by mcs

Here are our comments on the Torbutton changes:

  1. Shorten the first line of the commit message if possible.
  1. src/chrome/content/preferences.js is no longer used and should be removed.
  1. The following entities are no longer used and should be removed from the.dtd files:
  • torbutton.context_menu.preferences
  • torbutton.context_menu.preferences.key
  • torbutton.prefs.custom_warning
  • torbutton.prefs.restore_defaults
  1. You don't need to add empty securityLevel.properties files; all of the necessary files will be added when Georg runs the trans_tools/import-translations.sh script before making a release.
  1. Related to point 4: please add support for securityLevel.properties to trans_tools/import-translations.sh. And maybe open a ticket to have emmapeel add it to Transifex.

comment:91 in reply to:  89 Changed 4 months ago by pospeselr

Replying to antonela:

Replying to mcs:

  1. If custom mode is triggered, it is a little confusing that there is no text in about:preferences to encourage the user to switch back to one of the default levels (new users may even think custom is a good thing). Also, there is nothing in about:preferences that associates the Restore Defaults button with fixing the "custom problem." Finally, we might want to hide the Restore Defaults button when it is not applicable instead of disabling it (I think users will wonder why it is disabled). These issues might be worth looking at in future iteration.

Good call. We included the revert action for custom settings at the doorhanger. I think we can easily add the Restore defaults blue primary link at the selected level in about:preferences too.

Hey antonela, could you clarify how this should look?

EDIT: Ok amended the tor-browser and torbutton commits with most of mcs+brade's suggestions. Opted to keep the 'security slider' names in the source until a future patch where we move all that functionality into the securitylevel component.

Assuming this builds correctly all that remains should be the above mentioned design change to about:preferences surrounding the Restore Defaults button and XUL/CSS changes needed for right-to-left languages.

Last edited 4 months ago by pospeselr (previous) (diff)

comment:92 Changed 4 months ago by mcs

Thanks for the updated branches. Kathy and I noticed only a few remaining things:

securityLevel.js - SecurityLevelStrings:

Is it worth it to rely on the getLocale() function from Torbutton?
(maybe your answer is "yes")

securityLevel.js - SecurityLevelPanel:

Remove the comment inside openAdvancedSecuritySettings().

securityLevelPanel.css:

Please remove the commented out margin lines.

Regarding the question you asked about how to handle the toolbar icons in an upgrade situation, I don't think there is a simple solution. You probably need to dig through browser/components/customizableui/CustomizableUI.jsm and figure out what to do. Hopefully you can do what is needed by using some combination of addWidgetToArea(), removeWidgetFromArea(), and moveWidgetWithinArea(). There is probaly also a way to get the UI to reconfigure itself after the browser.uiCustomization.state pref is modified, so you could edit that pref value via code... but we should probably avoid completely resetting everyone's toolbars to the default set of icons.

By the way, it will be easier for us to look at what you fixed during a review cycle if you adopt the practice of creating and pushing new branches instead of doing an amend commit followed by a forced push (that way, we can easily compare the old and new branches).

Changed 4 months ago by antonela

Attachment: 3.0.3-restore-defaults.png added

comment:93 Changed 4 months ago by antonela

Re: Restore Defaults for Custom Settings.

We have the right UI implementation at the Security Level doorhanger based on reviewed mocks. Comment:86 is suggesting that we can have a better revert action flow at about:preferences.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/25658/3.0.3-restore-defaults.png
https://trac.torproject.org/projects/tor/raw-attachment/ticket/25658/3.x-restore-defaults.png

Do you think is better to remove the Restore Defaults button for all cases and just add the Restore Defaults inline link when Custom is enabled? I think so.

Changed 4 months ago by antonela

Attachment: 3.x-restore-defaults.png added

Changed 4 months ago by pospeselr

Attachment: screenshot06.png added

comment:94 in reply to:  92 ; Changed 4 months ago by pospeselr

Replying to mcs:

Thanks for the updated branches. Kathy and I noticed only a few remaining things:

securityLevel.js - SecurityLevelStrings:

Is it worth it to rely on the getLocale() function from Torbutton?
(maybe your answer is "yes")

My inclination is to leave it with the torbutton implementation, since it presumably works :)

Regarding the question you asked about how to handle the toolbar icons in an upgrade situation, I don't think there is a simple solution. You probably need to dig through browser/components/customizableui/CustomizableUI.jsm and figure out what to do. Hopefully you can do what is needed by using some combination of addWidgetToArea(), removeWidgetFromArea(), and moveWidgetWithinArea(). There is probaly also a way to get the UI to reconfigure itself after the browser.uiCustomization.state pref is modified, so you could edit that pref value via code... but we should probably avoid completely resetting everyone's toolbars to the default set of icons.

I was more curious if there was a way to determine that the browser had been updated, so that we can then put the Security Level button in the toolbar. Inserting the button is just a matter of finding the right js to call.

new branch with latest tor-browser changes: https://gitweb.torproject.org/user/richard/tor-browser.git/commit/?h=bug_25658_v4

Screenshot with updated about:preferences ui: https://trac.torproject.org/projects/tor/attachment/ticket/25658/screenshot06.png

EDIT: Also in this branch is a fix for the extensions in the toolbar issue, and a fix for another issue I discovered where sometimes the Security Level button class would not get set when being added via the uiCustomization.state reset && CustomizableUI.reset() && CustomizableUI.undoReset() method used by torbutton to ensure the torbutton (and now security level) button was added to the toolabr.

I need to do a tor-browser-build with these changes tonight to make sure the upgrade code path is working right, but I think we should be good.

Last edited 4 months ago by pospeselr (previous) (diff)

comment:95 Changed 4 months ago by pospeselr

Status: needs_revisionneeds_review

comment:96 Changed 4 months ago by gk

Status: needs_reviewneeds_revision

I've been looking at commit 843976bb2f88dc08cbefc28024b4a271a5cfa92a (the Torbutton patch). Two small requests:

1) I think the Torbutton icon fixup (aka #27478) is orthogonal to the sec slider changes. It's fine having both on the same branch but could you put them into different commits (with own bug numbers etc.) and adapt the commit message? That way it's easier to keep track of the changes.

2) Looking at your new SVG icons, it seems you have added some superflous whitespace, both at the end of

+  <polygon points="5,7 9,15 1,15" fill="#414141"/>     

and at the beginning of

+       <path d="M8.27272727 5.0C8.49625435 5.67889606 9.03172133 6.21869701

Please remove them. (And, yes, not force-pushing makes reviewing at lot easier ;) )

comment:97 in reply to:  94 Changed 4 months ago by mcs

Replying to pospeselr:

I was more curious if there was a way to determine that the browser had been updated, so that we can then put the Security Level button in the toolbar. Inserting the button is just a matter of finding the right js to call.

I think you only want to add the Security Level button one time, not after every update. Usually that is handled by setting a hidden pref (similar to extensions.torbutton.inserted_button).

new branch with latest tor-browser changes: https://gitweb.torproject.org/user/richard/tor-browser.git/commit/?h=bug_25658_v4

Everything looks good except there is a trailing space on the line-height: 1em; line in browser/components/securitylevel/content/securityLevelPreferences.css.

Is there a new Torbutton patch or is that still in progress?

comment:98 Changed 4 months ago by pospeselr

Updated torbutton to handle user upgrade correctly and excises the fix for #27478 (will put that in a new branch and post to that ticket). Also rebased it against latest torbutton master. Fixed whitespace issues in tor-browser and torbutton with a git rebase --whitespace=fix HEAD~1

torbutton: https://gitweb.torproject.org/user/richard/torbutton.git/commit/?h=bug_25658_v2
torbrowser: https://gitweb.torproject.org/user/richard/tor-browser.git/commit/?h=bug_25658_v5

Last edited 4 months ago by pospeselr (previous) (diff)

comment:99 Changed 4 months ago by pospeselr

Status: needs_revisionneeds_review

comment:100 in reply to:  98 Changed 4 months ago by mcs

Replying to pospeselr:

Updated torbutton to handle user upgrade correctly and excises the fix for #27478 (will put that in a new branch and post to that ticket). Also rebased it against latest torbutton master. Fixed whitespace issues in tor-browser and torbutton with a git rebase --whitespace=fix HEAD~1

torbutton: https://gitweb.torproject.org/user/richard/torbutton.git/commit/?h=bug_25658_v2
torbrowser: https://gitweb.torproject.org/user/richard/tor-browser.git/commit/?h=bug_25658_v5

Looks good to me, except I think per comment:79 we want the Torbutton icon to be relocated to the right side of the toolbar. I will attach a fixup patch.

Changed 4 months ago by mcs

fixup to relocate the Torbutton toolbar item

comment:101 Changed 4 months ago by gk

Status: needs_reviewneeds_information

I applied the Torbutton patch to master (commit 5a3d6d26e1f8046b20e51d93ca9457a729063bfc) and added both the tor-browser patch and the fixup to tor-browser-60.5.0esr-8.5-1 (commits a7ba005d5398a29d95320a5e8c02bf050e58f08b and d76b18ccef4ba4cb5be25f8c81b5817610f4d292). I did not have a chance to look over the tor-browser patch yet but from the comments in this ticket it *seems* it fixes #29554 as well. I'll close that ticket, but please reopen if I was wrong. What about #23359? Are done here as well in the sense that the buttons are not shown anymore?

comment:102 Changed 4 months ago by gk

FWIW, we can use #24653 to tackle the mobile side of this ticket.

comment:103 Changed 4 months ago by gk

Reading

                                                       Toolbars are reset to
    the Tor Browser default when the new 'inserted_security_level' pref is
    false. Coupled with the changes in tor-browser, users which upgrade will
    have their toolbars reset to the new design.

I am wondering what happens if users had customized their toolbar, say by adding a home button or custom extension buttons. While those vanish, too?

comment:104 in reply to:  103 ; Changed 4 months ago by mcs

Replying to gk:

I am wondering what happens if users had customized their toolbar, say by adding a home button or custom extension buttons. While those vanish, too?

I think the answer is "yes." Another way to solve the upgrade issue would be to "surgically" relocate the Torbutton toolbar item and then insert the new Security Settings one in the correct place. Maybe that can be implemented in a followup ticket.

comment:105 in reply to:  104 ; Changed 4 months ago by gk

Replying to mcs:

Replying to gk:

I am wondering what happens if users had customized their toolbar, say by adding a home button or custom extension buttons. While those vanish, too?

I think the answer is "yes." Another way to solve the upgrade issue would be to "surgically" relocate the Torbutton toolbar item and then insert the new Security Settings one in the correct place. Maybe that can be implemented in a followup ticket.

Okay, that's what I expected. Looking back at the proposal it seems we might want to think about the following two items closer:

1) 2.2: What to do about per-site security settings and how to expose them to users?

2) 3.1: Where have my extensions gone? (which is essentially the point about which I brought up in my last comment)

comment:106 in reply to:  105 ; Changed 4 months ago by antonela

Replying to gk:

1) 2.2: What to do about per-site security settings and how to expose them to users?

This ticket includes a 2.2 proposal in the comment:33 and per-site security settings has been discussed at #21034.

2) 3.1: Where have my extensions gone? (which is essentially the point about which I brought up in my last comment)

It is tricky. We can anticipate users about this change, but it will not remove the question if we are stepping over the local toolbar setting.

The proposal explains why we are removing the NoScript extension icon but will be useful to have a paragraph to describe it in simple words at our release post. Maybe, why custom settings in NoScript are discouraged should be the focus of this explainer and at the end, users can customize their toolbar by Menu > Customize...

comment:107 in reply to:  106 ; Changed 4 months ago by gk

Replying to antonela:

Replying to gk:

1) 2.2: What to do about per-site security settings and how to expose them to users?

This ticket includes a 2.2 proposal in the comment:33 and per-site security settings has been discussed at #21034.

What I mean is not a redesign of how per-site security settings should work but we thought about making site-specitic settings _as they are available today_ accessible. Ideas we had were outlined in section 2.2 of the proposal. Do we still think we should do that or something similar (I am not talking about redesigning our slider as you e.g. suggested in comment:33)? Or do we think just taking the buttons of the toolbar and requiring for folks to add them manually if needed is enough?

2) 3.1: Where have my extensions gone? (which is essentially the point about which I brought up in my last comment)

It is tricky. We can anticipate users about this change, but it will not remove the question if we are stepping over the local toolbar setting.

The proposal explains why we are removing the NoScript extension icon but will be useful to have a paragraph to describe it in simple words at our release post. Maybe, why custom settings in NoScript are discouraged should be the focus of this explainer and at the end, users can customize their toolbar by Menu > Customize...

Yes, mentioning it in our release post is definitely a thing we should do. I was wondering whether there is more we could/should do here, though.

comment:108 Changed 4 months ago by gk

Keywords: TorBrowserTeam201903 added; TorBrowserTeam201903R removed

Nothing to review here, we are back at the needs_information stage.

Changed 4 months ago by antonela

Attachment: 25658 - 2.2.png added

comment:109 in reply to:  107 ; Changed 4 months ago by antonela

Replying to gk:

What I mean is not a redesign of how per-site security settings should work but we thought about making site-specific settings _as they are available today_ accessible. Ideas we had were outlined in section 2.2 of the proposal.

Got it! I approached a UI for what is described at 2.2.

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

Questions:

  • By default only the option to temporarily allow JavaScript would be visible. When? On the Default level? Or in all security levels?
  • What happens when user enable/disable JS or Active Content? Should they reload to apply effects?
  • We cannot prompt users to enable JS for each website who wants to use JS. How are we going to balance it? One option could be to not prompt users but enable it automatically and giving users visual feedback at the URL bar with the colored icon. If this is the road we are going to take, then we should expose this in global settings as an opt-in.
  • Can we save trusted sites in any safe way? Those trusted sites could have JS enabled, even if the global security level is Safest.
  • The gear icon at the Control Center goes to about:preferences#privacy Permissions. Should we incorporate JS and Active Content as an option there too?


Version 0, edited 4 months ago by antonela (next)

comment:110 Changed 4 months ago by gk

It seems there are remaining stopOpenSecuritySettingsObserver() pieces left in torbutton.js. I assume this is an oversight and we should delete them as well (in a fixup commit)? Noted on our blog: https://blog.torproject.org/comment/280343#comment-280343.

comment:111 in reply to:  109 Changed 4 months ago by gk

Replying to antonela:

Replying to gk:

What I mean is not a redesign of how per-site security settings should work but we thought about making site-specific settings _as they are available today_ accessible. Ideas we had were outlined in section 2.2 of the proposal.

Got it! I approached a UI for what is described at 2.2.

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

The control center looks good to me. For the URL bar see more below.

Questions:

  • By default only the option to temporarily allow JavaScript would be visible. When? On the Default level? Or in all security levels?

Only when a security level would block it, I think. I think the active content one should at least be visible if a user clicked on a click-to-play icon and got, e.g. WebGL going. But we could have that for a future iteration if we wanted.

  • What happens when user enable/disable JS or Active Content? Should they reload to apply effects?

Yes.

  • We cannot prompt users to enable JS for each website who wants to use JS. How are we going to balance it? One option could be to not prompt users but enable it automatically and giving users visual feedback at the URL bar with the colored icon. If this is the road we are going to take, then we should expose this in global settings as an opt-in.

It's meant to be used as a feature for power users, ideally never ever. So, no, I would not want to prompt users. I think we could have a little icon in the URL bar grayed out, and that's it as an indicator. I wonder whether we should put this icon on the right side of the URL bar, though, given that users might click on it by accident when they only wanted to see the circuit being used.

  • Can users save trusted sites in any safe way? Those trusted sites could have JS enabled, even if the global security level is Safest.

I don't know yet. We could think about saving those permissions in a future iteration. In general, I am a bit reluctant to optimize things for power users, in particular as the slider should not used that way, or only with great care.

  • The gear icon at the Control Center goes to about:preferences#privacy Permissions. Should we incorporate JS and Active Content as an option there too?

No. The permissions we give are site-specific (which is why they are in the URL bar) but do not apply to the whole browser session (which those on the preferences pane do). We should not mix that (in fact one of our big goals with the redesign was to make that distinction clearer).

comment:112 Changed 4 months ago by gk

One thing we should keep in mind when designing the exception part is doing it in a way that future iterations, which might make substantial changes to what we think should be allowed/blocked, say, on the medium level, could still make use of it.

comment:113 Changed 4 months ago by gk

Keywords: tbb-8.5-must added; tbb-8.5 removed

Adding this on our tbb-8.5-must radar at least for comment:110. We might want to tackle #29886 for that as well. And we should at least have a precise understanding about what to do with the per-site security settings.

comment:114 Changed 3 months ago by gk

Keywords: TorBrowserTeam201904 added; TorBrowserTeam201903 removed

Moving tickets to April.

comment:115 in reply to:  113 Changed 3 months ago by gk

Keywords: tbb-8.5-must removed

Replying to gk:

Adding this on our tbb-8.5-must radar at least for comment:110.

That's been done in #29973. We'll postpone site-specific permissions for 9.0. Taking this ticket off of our 8.5 radar for now.

comment:116 Changed 7 weeks ago by cypherpunks

Tor Browser 8.5 has completely broken the browsing experience. Many websites on "standard" mode still break--but with the removal of the NoScript widget from the toolbar, users have absolutely no obvious way to fix things. Further, "safer" and "safest" mode are so thoroughly broken they might as well be removed entirely. I understand design is an iterative process. I also understand the destination will be better than the status quo.

This update was botched. Many websites still break in standard mode, but there is no obvious way to un-break them. Most websites totally break in safest mode, but this essential un-breaking control is suddenly buried deep within menus and hidden from the user.

It's ironic that an issue titled, "Improve user understanding and user control by clarifying Tor Browser's security features" results in a Tor Browser release that confuses users by removing a key user control over Tor Browser security features. The icing on the cake is Georg's last comment, "We'll postpone site-specific permissions for 9.0. Taking this ticket off of our 8.5 radar for now.". Re-read the issue title for added comedic effect.

comment:117 Changed 7 weeks ago by gk

Status: needs_informationnew

Seems we got all the information we need.

comment:118 in reply to:  116 Changed 7 weeks ago by gk

Replying to cypherpunks:

Tor Browser 8.5 has completely broken the browsing experience. Many websites on "standard" mode still break--but with the removal of the NoScript widget from the toolbar, users have absolutely no obvious way to fix things. Further, "safer" and "safest" mode are so thoroughly broken they might as well be removed entirely. I understand design is an iterative process. I also understand the destination will be better than the status quo.

This update was botched. Many websites still break in standard mode, but there is no obvious way to un-break them. Most websites totally break in safest mode, but this essential un-breaking control is suddenly buried deep within menus and hidden from the user.

It's ironic that an issue titled, "Improve user understanding and user control by clarifying Tor Browser's security features" results in a Tor Browser release that confuses users by removing a key user control over Tor Browser security features. The icing on the cake is Georg's last comment, "We'll postpone site-specific permissions for 9.0. Taking this ticket off of our 8.5 radar for now.". Re-read the issue title for added comedic effect.

Thanks. It seems #30600 is the ticket you wanted to comment on. (I'd still be curious to see answers to my questions there, actually, given that those sites mentioned in that bug work on standard level in my Tor Browser and I don't have seen any website broken on standard in 8.5 yet which got then fixed by some NoScript modifications via the toolbar icon)

Note: See TracTickets for help on using tickets.