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.

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.

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.

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

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.

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.

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?

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.

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.

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'.

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.

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.

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? :)

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.

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.

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?

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

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

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.

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.

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.

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 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.

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)

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.

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

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.

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.

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.

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?

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

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?

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.

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.

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.

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. :)

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.

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.

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.

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)

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.

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.

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.

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.

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?

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.

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.

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.

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.

(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.

(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.

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?

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.

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

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.

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

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?

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...

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.

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

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?

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.

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.

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.

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.

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.

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...

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.

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 would be nice to have a dynamic tooltip for the toolbar item so that the active level is visible, e.g., Security Level: Safer

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

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

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.

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.

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

Agree, the link is currently a placeholder. I opened #29657 to track this.

I brought this up with antonela previously, and the direction was to use Standard rather than Default

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.

This sounds reasonable, will wait for antonela to comment.

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.

This behaviour is expected as there isn't any upgrade logic in place. How is this sort of thing usually handled?

EDIT:

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.

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!

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

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

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.

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.

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.

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.

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

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.

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

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.

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.

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

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

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

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

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?

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?

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.

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)

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...

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.

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.

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 users 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?

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.

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

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.

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.

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.

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)