Hi all!
Below is the updated version taking the feedback I got so far into account. If you think it did not address the points you brought up, please say so (and do so as well in case new issues popped up since the first draft got sent).
We had quite some discussion about doing First Party Isolation (FPI) on top of the security slider. I think that idea is sufficiently complex that it merits an own proposal, especially as I still don't see how we can get it right. See bug 21034 for the context where at least one example is shown that the security provided by the slider gets actually worse with FPI. So, we seem to be in a situation that FPI both enhances and decreases the security benefits promised by the slider depending on the context and on users expectations which seems tricky to resolve.
Regarding the all-features-enabled-button idea Arthur had it seems to me we should think about that one more as well, taking the different blocked content into account and, above all, its different treatment by NoScript: it is possible to enable/disable scripts right now by web site while e.g. WebGL premissions are session-wide. Providing one button and allowing to blow away big parts of the slider protections for the whole session that way seems not like a thing we should do lightly. We might want to make a distinction between JavaScript which is what users need to have enabled most of the time to interact with a site and "active content" and expose just two buttons for that for the time being. That's what I propose in the proposal update while we think more about it. I agree that we should not bother users with concepts like WebGL, Fonts, SVG etc.
I've attached a diff to the original proposal for those following along and not wanting to read the full one again in order to spot the updates.
Filename: XXX-redesign-security-controls.txt Title: Redesign of Tor Browser's Security Controls Author: Georg Koppen Created: 6-March-2018 Status: Open
1 Introduction
Tor Browser is well-known for its defenses against web tracking and fingerprinting. However, providing Tor users just a privacy-enhanced browser is often not enough to safeguard against deanonymization attacks as those protections might simply get bypassed by exploiting browser vulnerabilities. Tor Browser therefore offers several security enhancements as well to reduce that risk. Most of those features are provided by extensions which Tor Browser includes, namely Torbutton, NoScript, and HTTPS Everywhere.
1.1 Motivation
By default Torbutton, NoScript, and HTTPS Everywhere are visible on the toolbar in Tor Browser and there is no hint about possible security enhancements, with the exception of a notification bar shown on first start and pointing to our security slider. This has a number of suboptimal outcomes which this proposal seeks to address:
a) Security controls are scattered over and within different extensions. That makes it hard to understand which knobs a user could turn to improve their security settings while not being exposed to additional fingerprinting risks. b) The toolbar gets cluttered with three additional icons that provide access to both per-site and global security settings. This is confusing to users. Part of the confusion stems from mixing non-global with global security controls on the toolbar not indicating which of them just affect a particular website while others affect the whole browser session. Another part is that users feel the need to navigate through different levels of extension menus to make basic adjustments to their security level. c) There is the security vs. usability trade-off and little incentives to change the default which comes with Tor Browser. That results in users just staying on the lowest security level while at least some of them could get convinced to raise that level if we managed to provide an improved experience around our security controls, both functionality- and UX-wise.
1.2 The State of the Security Controls
That is how the toolbar in Tor Browser looks like currently:
---------------------------------------------------------------------- | --- --- ------------------------- --------------- --- --- | | |N| |T| | URL bar | | Search bar | |H| |M| | | --- --- ------------------------- --------------- --- --- | ----------------------------------------------------------------------
N = NoScript button T = Torbutton button H = HTTPS Everywhere button M = (Hamburger) Menu button
We include HTTPS Everywhere to help against potential Tor Exit node eavesdroppers and active attackers. To provide users with optional defense-in-depth against JavaScript and other potential exploit vectors, we use NoScript modifying some of its defaults[1]. Torbutton includes the security slider which is meant to give users an easy way to adjust their security level from Standard to Safest, depending on their perceived needs.
2 Proposal
Generally, items on the toolbar serve two important purposes: they are shortcuts to features often used and they inform about current state. With that in mind we can think about redoing our toolbar helping that way with issues outlined in 1.1 a) and b). The remaining problems (part of 1.1 b) and 1.1 c)) will be addressed in section 2.2, 3.3, and follow-up proposals.
2.1 Restructuring the Toolbar
2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar
I'd propose we remove both NoScript and HTTPS Everywhere from the toolbar and leave Torbutton on it for now:
Torbutton serves a number of purposes and access to security settings is just one of them. Moreover, we are in the process of restructuring at least part of its functionality right now[2] and more will likely happen in the future in this area. We can think about whether Torbutton should remain on the toolbar after that transition is done.
HTTPS Everywhere has the option to block all unencrypted requests and apart from that is just enforcing HTTPS connections according to the rulesets it ships, which is our default. There is not much gain security-wise leaving it on the toolbar and users might just be confused by the "Block all unencrypted requests" option. I'd argue as well that the status indicator is not important enough to justify precious space on the toolbar either.
NoScript comes with a myriad of configuration options. We try to abstract that away by shipping a list of defaults for Tor Browser[1]. But still having NoScript easily accessible makes it dangerous to choose the wrong option, especially as the majority of its functionality does not need to be exposed for Tor Browser users. Moreover, the scary warning icon which is visible when NoScript allows JavaScript is highly confusing to users as we ship this configuration as our default. Removing the icon from the toolbar should solve those two problems. We might want to think about exposing the small amount of functionality which especially users with the security slider set to "Safest" might need: managing finer-grained script control. See section 2.2 for that.
2.1.2 Adding a Security Settings Button to the Toolbar
I'd like to propose a new button on the toolbar giving easy access to what is essentially the tool that we want to promote: the security slider. We could use an icon similar to the one suggested by ninavizz[3] or come up with a different solution. The button would open the security slider menu with a right-click. With a left-click, keyboard shortcuts, and mouse-wheel scrolling one can adjust the security level directly.
However, easily adjusting the slider settings just for a single tab is risky as it affects all the other tabs and windows in the session as well. We should therefore at least warn the users about the possible danger and provide the option to acquire a New Identity right after changing the security slider level.
The new toolbar would look like:
---------------------------------------------------------------------- | --- --- ------------------------------- --------------- --- | | |T| |S| | URL bar | | Search bar | |M| | | --- --- ------------------------------- --------------- --- | ----------------------------------------------------------------------
T = Torbutton button S = Security Settings button M = (Hamburger) Menu button
Note: The reorganized toolbar has the additional benefit that no per-site state is shown anymore on it, which should lead to less confusion about whether the settings visible there apply globally or not.
2.2 Dealing with Per-Site Security Settings
There are a number of features disabled on higher security settings as they are potentially dangerous, yet sometimes users need or want to allow them anyway. So far, these options were exposed by click-to-play buttons or directly in the NoScript user interface accessible over the toolbar button.
With NoScript gone from the toolbar the click-to-play options remain, but easily allowing JavaScript per site and making the status of NoScript related settings visible is not available anymore. To solve this I'd propose to follow the path we are currently taking with our circuit display redesign[2]: we are moving site specific settings into the URL bar.
One way to do that would be to use the Permissions section which opens after clicking on the "i" icon in the URL bar. However, while showing the security permissions the user has granted there (too) is a good idea, it does not solve the problem of easily allowing e.g. JavaScript on a website, and seeing its status without the need to click on any button. We could have small icons on the right side of the URL bar accomplishing that, though. That way, users could easily see if they had JavaScript, or WebGL, or ... enabled on that particular website in case they are on higher security levels. Moreover, they would be able to adjust those permissions quickly without the need to deal with any NoScript user interface or additional menus just by toggling those icons.
By default only the option to temporarily allow JavaScript would be visible. All the click-to-play features could show up once there is a respective object embedded on a website. 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 additionally, which is responsible for manipulating and showing the state of "active content" (like WebGL, SVG, fonts etc.).
3 Additional Considerations
3.1 Where Are My Extensions Gone?
Some users might be confused and think NoScript and HTTPS Everywhere are gone now, plus they want to have their "old" way of setting their per-site settings back. That's okay and they can easily add NoScript and HTTPS Everywhere back to their toolbar if they wish. It would be good to point this out in the transition phase to the new interface at least.
3.2 How Do We Inform Users about the New Interface?
I don't know yet how we ideally inform users about the new interface. That is not part of this proposal but might merit an own one.
3.3 Should We Change the Default Security Level?
As much as I wished to change the default security level, to e.g. "Safer", right now I think we are not there yet. Part of the security control redesign should be fixing bugs that make the current and new interface less effective and painful to use[4][5][6][7]. We could revisit that discussion, though, once we have solved the low hanging bugs.
[1] https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/t... [2] https://trac.torproject.org/projects/tor/ticket/24309 [3] https://trac.torproject.org/projects/tor/ticket/21183 [4] https://trac.torproject.org/projects/tor/ticket/22981 [5] https://trac.torproject.org/projects/tor/ticket/22985 [6] https://trac.torproject.org/projects/tor/ticket/20314 [7] https://trac.torproject.org/projects/tor/ticket/21805
Georg
Hello Georg,
On mar., mars 06, 2018, Georg Koppen wrote:
Below is the updated version taking the feedback I got so far into account. If you think it did not address the points you brought up, please say so (and do so as well in case new issues popped up since the first draft got sent).
Nice work, quite impressive. The proposal seems to take into account my dislike of having the two security areas (Mozilla and Tor) labeled almost identically, which can be confusing.
Cheers, Michael
On 3/6/18 6:25 AM, Georg Koppen wrote:
Hi all!
Below is the updated version taking the feedback I got so far into account. If you think it did not address the points you brought up, please say so (and do so as well in case new issues popped up since the first draft got sent).
Should we schedule a session on our team day (or another day) to talk about this proposal? Or maybe it is already on the schedule and I did not see it? An in-person session with a whiteboard might be productive.
Mark Smith:
On 3/6/18 6:25 AM, Georg Koppen wrote:
Hi all!
Below is the updated version taking the feedback I got so far into account. If you think it did not address the points you brought up, please say so (and do so as well in case new issues popped up since the first draft got sent).
Should we schedule a session on our team day (or another day) to talk about this proposal? Or maybe it is already on the schedule and I did not see it? An in-person session with a whiteboard might be productive.
I agree. I think the team day is already fully booked with other meetings but we could a session on any of the others days. Please, add it to a time slot if you think that would be useful. I can be the facilitator if that sounds like a good idea.
Georg
On 3/6/18 12:12 PM, Georg Koppen wrote:
I think the team day is already fully booked with other meetings but we could a session on any of the others days. Please, add it to a time slot if you think that would be useful. I can be the facilitator if that sounds like a good idea.
Sounds good to me. I added it at 13:00 on March 13 (one of the open/unstructured days). If you think a different time would work better, please adjust.
-Mark
Mark Smith:
On 3/6/18 12:12 PM, Georg Koppen wrote:
I think the team day is already fully booked with other meetings but we could a session on any of the others days. Please, add it to a time slot if you think that would be useful. I can be the facilitator if that sounds like a good idea.
Sounds good to me. I added it at 13:00 on March 13 (one of the open/unstructured days). If you think a different time would work better, please adjust.
Alright, I tried to incorporate feedback from that meeting into the proposal. I recalled two changes we wanted to make which are accounted for in the updated proposal (which is below):
1) We want to move the toolbar buttons Tor Browser adds to the right between the search bar and the menu button.
2) We were not overly happy with having an own button for the slider on the toolbar due to the risks if clicking it accidentally or because one does not know what one is doing being still confused about global vs. tab-related settings.
Let me know if the changes are not good enough or if something else showed up meanwhile. Attached is the diff between v2 and v3 (this version) of the proposal to see easily what has changed between both revisions.
Filename: XXX-redesign-security-controls.txt Title: Redesign of Tor Browser's Security Controls Author: Georg Koppen Created: 3-April-2018 Status: Open
1 Introduction
Tor Browser is well-known for its defenses against web tracking and fingerprinting. However, providing Tor users just a privacy-enhanced browser is often not enough to safeguard against deanonymization attacks as those protections might simply get bypassed by exploiting browser vulnerabilities. Tor Browser therefore offers several security enhancements as well to reduce that risk. Most of those features are provided by extensions which Tor Browser includes, namely Torbutton, NoScript, and HTTPS Everywhere.
1.1 Motivation
By default Torbutton, NoScript, and HTTPS Everywhere are visible on the toolbar in Tor Browser and there is no hint about possible security enhancements, with the exception of a notification bar shown on first start and pointing to our security slider. This has a number of suboptimal outcomes which this proposal seeks to address:
a) Security controls are scattered over and within different extensions. That makes it hard to understand which knobs a user could turn to improve their security settings while not being exposed to additional fingerprinting risks. b) The toolbar gets cluttered with three additional icons that provide access to both per-site and global security settings. This is confusing to users. Part of the confusion stems from mixing non-global with global security controls on the toolbar not indicating which of them just affect a particular website while others affect the whole browser session. Another part is that users feel the need to navigate through different levels of extension menus to make basic adjustments to their security level. c) There is the security vs. usability trade-off and little incentives to change the default which comes with Tor Browser. That results in users just staying on the lowest security level while at least some of them could get convinced to raise that level if we managed to provide an improved experience around our security controls, both functionality- and UX-wise.
1.2 The State of the Security Controls
That is how the toolbar in Tor Browser looks like currently:
---------------------------------------------------------------------- | --- --- ------------------------- --------------- --- --- | | |N| |T| | URL bar | | Search bar | |H| |M| | | --- --- ------------------------- --------------- --- --- | ----------------------------------------------------------------------
N = NoScript button T = Torbutton button H = HTTPS Everywhere button M = (Hamburger) Menu button
We include HTTPS Everywhere to help against potential Tor Exit node eavesdroppers and active attackers. To provide users with optional defense-in-depth against JavaScript and other potential exploit vectors, we use NoScript modifying some of its defaults[1]. Torbutton includes the security slider which is meant to give users an easy way to adjust their security level from Standard to Safest, depending on their perceived needs.
2 Proposal
Generally, items on the toolbar serve two important purposes: they are shortcuts to features often used and they inform about current state. With that in mind we can think about redoing our toolbar helping that way with issues outlined in 1.1 a) and b). The remaining problems (part of 1.1 b) and 1.1 c)) will be addressed in section 2.2, 3.3, and follow-up proposals.
2.1 Restructuring the Toolbar
2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar
I'd propose we remove both NoScript and HTTPS Everywhere from the toolbar and leave Torbutton on it for now:
Torbutton serves a number of purposes and access to security settings is just one of them. Moreover, we are in the process of restructuring at least part of its functionality right now[2] and more will likely happen in the future in this area. We can think about whether Torbutton should remain on the toolbar after that transition is done.
HTTPS Everywhere has the option to block all unencrypted requests and apart from that is just enforcing HTTPS connections according to the rulesets it ships, which is our default. There is not much gain security-wise leaving it on the toolbar and users might just be confused by the "Block all unencrypted requests" option. I'd argue as well that the status indicator is not important enough to justify precious space on the toolbar either.
NoScript comes with a myriad of configuration options. We try to abstract that away by shipping a list of defaults for Tor Browser[1]. But still having NoScript easily accessible makes it dangerous to choose the wrong option, especially as the majority of its functionality does not need to be exposed for Tor Browser users. Moreover, the scary warning icon which is visible when NoScript allows JavaScript is highly confusing to users as we ship this configuration as our default. Removing the icon from the toolbar should solve those two problems. We might want to think about exposing the small amount of functionality which especially users with the security slider set to "Safest" might need: managing finer-grained script control. See section 2.2 for that.
2.1.2 Showing Security Slider State
We essentially have one tool we want to promote to deal with security settings: the security slider. Keeping in mind that icons on the toolbar serve as well the purpose of showing state of important settings, we could think about providing an own toolbar item for the security slider. We could use an icon similar to the one suggested by ninavizz[3] or come up with a different solution. The button would open the security slider menu with a right-click. With a left-click, keyboard shortcuts, and mouse-wheel scrolling one can adjust the security level directly.
However, being able to easily adjust the slider settings is risky as it affects all the tabs and windows in the session. It might lead to confusion as to whether the settings are applied globally or just for the tab in question which is error-prone. 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. Doing so is a good idea anyway, but might not be enough to justify a security slider toolbar button. We'll therefore try to come up with other means of showing the current slider level (e.g. by color-coding the browser chrome) and leave the slider settings within the Torbutton menu for now.
2.1.3 Reorganizing the Toolbar
Taking the preceding chapters into account this leaves us with a single toolbar button for the Tor Browser toolbar: the one from the Torbutton extension. Following the toolbar layout of Firefox we should move that toolbar button to the right between the search bar and the menu button.
Now, the new toolbar would look like:
---------------------------------------------------------------------- | ------------------------------------ --------------- --- --- | | | URL bar | | Search bar | |T| |M| | | ------------------------------------ --------------- --- --- | ----------------------------------------------------------------------
T = Torbutton button M = (Hamburger) Menu button
Note: The reorganized toolbar has the additional benefit that no per-site state is shown anymore on it, which should lead to less confusion about whether the settings visible there apply globally or not.
2.2 Dealing with Per-Site Security Settings
There are a number of features disabled on higher security settings as they are potentially dangerous, yet sometimes users need or want to allow them anyway. So far, these options were exposed by click-to-play buttons or directly in the NoScript user interface accessible over the toolbar button.
With NoScript gone from the toolbar the click-to-play options remain, but easily allowing JavaScript per site and making the status of NoScript related settings visible is not available anymore. To solve this I'd propose to follow the path we are currently taking with our circuit display redesign[2]: we are moving site specific settings into the URL bar.
One way to do that would be to use the Permissions section which opens after clicking on the "i" icon in the URL bar. However, while showing the security permissions the user has granted there (too) is a good idea, it does not solve the problem of easily allowing e.g. JavaScript on a website, and seeing its status without the need to click on any button. We could have small icons on the right side of the URL bar accomplishing that, though. That way, users could easily see if they had JavaScript, or WebGL, or ... enabled on that particular website in case they are on higher security levels. Moreover, they would be able to adjust those permissions quickly without the need to deal with any NoScript user interface or additional menus just by toggling those icons.
By default only the option to temporarily allow JavaScript would be visible. All the click-to-play features could show up once there is a respective object embedded on a website. 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 additionally, which is responsible for manipulating and showing the state of "active content" (like WebGL, SVG, fonts etc.).
3 Additional Considerations
3.1 Where Are My Extensions Gone?
Some users might be confused and think NoScript and HTTPS Everywhere are gone now, plus they want to have their "old" way of setting their per-site settings back. That's okay and they can easily add NoScript and HTTPS Everywhere back to their toolbar if they wish. It would be good to point this out in the transition phase to the new interface at least.
3.2 How Do We Inform Users about the New Interface?
I don't know yet how we ideally inform users about the new interface. That is not part of this proposal but might merit an own one.
3.3 Should We Change the Default Security Level?
As much as I wished to change the default security level, to e.g. "Safer", right now I think we are not there yet. Part of the security control redesign should be fixing bugs that make the current and new interface less effective and painful to use[4][5][6][7]. We could revisit that discussion, though, once we have solved the low hanging bugs.
[1] https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/t... [2] https://trac.torproject.org/projects/tor/ticket/24309 [3] https://trac.torproject.org/projects/tor/ticket/21183 [4] https://trac.torproject.org/projects/tor/ticket/22981 [5] https://trac.torproject.org/projects/tor/ticket/22985 [6] https://trac.torproject.org/projects/tor/ticket/20314 [7] https://trac.torproject.org/projects/tor/ticket/21805
Georg
Hi again!
Georg Koppen:
Mark Smith:
On 3/6/18 12:12 PM, Georg Koppen wrote:
I think the team day is already fully booked with other meetings but we could a session on any of the others days. Please, add it to a time slot if you think that would be useful. I can be the facilitator if that sounds like a good idea.
Sounds good to me. I added it at 13:00 on March 13 (one of the open/unstructured days). If you think a different time would work better, please adjust.
Alright, I tried to incorporate feedback from that meeting into the proposal. I recalled two changes we wanted to make which are accounted for in the updated proposal (which is below):
- We want to move the toolbar buttons Tor Browser adds to the right
between the search bar and the menu button.
- We were not overly happy with having an own button for the slider on
the toolbar due to the risks if clicking it accidentally or because one does not know what one is doing being still confused about global vs. tab-related settings.
We had a pretty productive sync with the UX team yesterday (see: http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-04-04-19.01.log.... for the meeting log) and came up with a better idea for 2) which is incorporated in the updated proposal below. As usual, I've attached a diff to the previous version as well.
Filename: XXX-redesign-security-controls.txt Title: Redesign of Tor Browser's Security Controls Author: Georg Koppen Created: 5-April-2018 Status: Open
1 Introduction
Tor Browser is well-known for its defenses against web tracking and fingerprinting. However, providing Tor users just a privacy-enhanced browser is often not enough to safeguard against deanonymization attacks as those protections might simply get bypassed by exploiting browser vulnerabilities. Tor Browser therefore offers several security enhancements as well to reduce that risk. Most of those features are provided by extensions which Tor Browser includes, namely Torbutton, NoScript, and HTTPS Everywhere.
1.1 Motivation
By default Torbutton, NoScript, and HTTPS Everywhere are visible on the toolbar in Tor Browser and there is no hint about possible security enhancements, with the exception of a notification bar shown on first start and pointing to our security slider. This has a number of suboptimal outcomes which this proposal seeks to address:
a) Security controls are scattered over and within different extensions. That makes it hard to understand which knobs a user could turn to improve their security settings while not being exposed to additional fingerprinting risks. b) The toolbar gets cluttered with three additional icons that provide access to both per-site and global security settings. This is confusing to users. Part of the confusion stems from mixing non-global with global security controls on the toolbar not indicating which of them just affect a particular website while others affect the whole browser session. Another part is that users feel the need to navigate through different levels of extension menus to make basic adjustments to their security level. c) There is the security vs. usability trade-off and little incentives to change the default which comes with Tor Browser. That results in users just staying on the lowest security level while at least some of them could get convinced to raise that level if we managed to provide an improved experience around our security controls, both functionality- and UX-wise.
1.2 The State of the Security Controls
That is how the toolbar in Tor Browser looks like currently:
---------------------------------------------------------------------- | --- --- ------------------------- --------------- --- --- | | |N| |T| | URL bar | | Search bar | |H| |M| | | --- --- ------------------------- --------------- --- --- | ----------------------------------------------------------------------
N = NoScript button T = Torbutton button H = HTTPS Everywhere button M = (Hamburger) Menu button
We include HTTPS Everywhere to help against potential Tor Exit node eavesdroppers and active attackers. To provide users with optional defense-in-depth against JavaScript and other potential exploit vectors, we use NoScript modifying some of its defaults[1]. Torbutton includes the security slider which is meant to give users an easy way to adjust their security level from Standard to Safest, depending on their perceived needs.
2 Proposal
Generally, items on the toolbar serve two important purposes: they are shortcuts to features often used and they inform about current state. With that in mind we can think about redoing our toolbar helping that way with issues outlined in 1.1 a) and b). The remaining problems (part of 1.1 b) and 1.1 c)) will be addressed in section 2.2, 3.3, and follow-up proposals.
2.1 Restructuring the Toolbar
2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar
I'd propose we remove both NoScript and HTTPS Everywhere from the toolbar and leave Torbutton on it for now:
Torbutton serves a number of purposes and access to security settings is just one of them. Moreover, we are in the process of restructuring at least part of its functionality right now[2] and more will likely happen in the future in this area. We can think about whether Torbutton should remain on the toolbar after that transition is done.
HTTPS Everywhere has the option to block all unencrypted requests and apart from that is just enforcing HTTPS connections according to the rulesets it ships, which is our default. There is not much gain security-wise leaving it on the toolbar and users might just be confused by the "Block all unencrypted requests" option. I'd argue as well that the status indicator is not important enough to justify precious space on the toolbar either.
NoScript comes with a myriad of configuration options. We try to abstract that away by shipping a list of defaults for Tor Browser[1]. But still having NoScript easily accessible makes it dangerous to choose the wrong option, especially as the majority of its functionality does not need to be exposed for Tor Browser users. Moreover, the scary warning icon which is visible when NoScript allows JavaScript is highly confusing to users as we ship this configuration as our default. Removing the icon from the toolbar should solve those two problems. We might want to think about exposing the small amount of functionality which especially users with the security slider set to "Safest" might need: managing finer-grained script control. See section 2.2 for that.
2.1.2 Showing Security Slider State
We essentially have one tool we want to promote to deal with security settings: the security slider. Keeping in mind that icons on the toolbar serve as well the purpose of showing state of important settings, we could think about providing an own toolbar button for the security slider. We could use an icon similar to the one suggested by ninavizz[3] or come up with a different solution.
However, being able to easily adjust the slider level is risky as it affects all the tabs and windows in a session. It might lead to confusion as to whether the settings are applied globally or just for a tab in question, which is error-prone. 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. Doing so is a good idea anyway, but might not be enough to justify exposing security slider functionality on the toolbar.
We'll add a security settings button to the toolbar which shows the current slider state but, once clicked on, opens an about:preferences pane in a new tab which contains the security slider. That way we make the current slider state easily visible while avoiding the risk of accidentally changing it. Moreover, having it as an option on Firefox's preferences pane reinforces the idea of slider settings being applied to the whole session and not just to a particular tab or window.
2.1.3 Reorganizing the Toolbar
Taking the preceding chapters into account this leaves us with two toolbar buttons for the Tor Browser toolbar: the one from the Torbutton extension and the button for the security settings. Following the toolbar layout of Firefox we should move both buttons to the right, between the search bar and the menu button.
Now, the new toolbar would look like:
---------------------------------------------------------------------- | -------------------------------- -------------- --- --- --- | | | URL bar | | Search bar | |T| |S| |M| | | -------------------------------- -------------- --- --- --- | ----------------------------------------------------------------------
T = Torbutton button S = Security Settings button M = (Hamburger) Menu button
Note: The reorganized toolbar has the additional benefit that no per-site state is shown anymore on it, which should lead to less confusion about whether the settings visible there apply globally or not.
2.2 Dealing with Per-Site Security Settings
There are a number of features disabled on higher security settings as they are potentially dangerous, yet sometimes users need or want to allow them anyway. So far, these options were exposed by click-to-play buttons or directly in the NoScript user interface accessible over the toolbar button.
With NoScript gone from the toolbar the click-to-play options remain, but easily allowing JavaScript per site and making the status of NoScript related settings visible is not available anymore. To solve this I'd propose to follow the path we are currently taking with our circuit display redesign[2]: we are moving site specific settings into the URL bar.
One way to do that would be to use the Permissions section which opens after clicking on the "i" icon in the URL bar. However, while showing the security permissions the user has granted there (too) is a good idea, it does not solve the problem of easily allowing e.g. JavaScript on a website, and seeing its status without the need to click on any button. We could have small icons on the right side of the URL bar accomplishing that, though. That way, users could easily see if they had JavaScript, or WebGL, or ... enabled on that particular website in case they are on higher security levels. Moreover, they would be able to adjust those permissions quickly without the need to deal with any NoScript user interface or additional menus just by toggling those icons.
By default only the option to temporarily allow JavaScript would be visible. All the click-to-play features could show up once there is a respective object embedded on a website. 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 additionally, which is responsible for manipulating and showing the state of "active content" (like WebGL, SVG, fonts etc.).
3 Additional Considerations
3.1 Where Are My Extensions Gone?
Some users might be confused and think NoScript and HTTPS Everywhere are gone now, plus they want to have their "old" way of setting their per-site settings back. That's okay and they can easily add NoScript and HTTPS Everywhere back to their toolbar if they wish. It would be good to point this out in the transition phase to the new interface at least.
3.2 How Do We Inform Users about the New Interface?
I don't know yet how we ideally inform users about the new interface. That is not part of this proposal but might merit an own one.
3.3 Should We Change the Default Security Level?
As much as I wished to change the default security level, to e.g. "Safer", right now I think we are not there yet. Part of the security control redesign should be fixing bugs that make the current and new interface less effective and painful to use[4][5][6][7]. We could revisit that discussion, though, once we have solved the low hanging bugs.
[1] https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/t... [2] https://trac.torproject.org/projects/tor/ticket/24309 [3] https://trac.torproject.org/projects/tor/ticket/21183 [4] https://trac.torproject.org/projects/tor/ticket/22981 [5] https://trac.torproject.org/projects/tor/ticket/22985 [6] https://trac.torproject.org/projects/tor/ticket/20314 [7] https://trac.torproject.org/projects/tor/ticket/21805
Georg
Georg Koppen:
Hi all!
Below is the updated version taking the feedback I got so far into account. If you think it did not address the points you brought up, please say so (and do so as well in case new issues popped up since the first draft got sent).
We had quite some discussion about doing First Party Isolation (FPI) on top of the security slider. I think that idea is sufficiently complex that it merits an own proposal, especially as I still don't see how we can get it right. See bug 21034 for the context where at least one example is shown that the security provided by the slider gets actually worse with FPI. So, we seem to be in a situation that FPI both enhances and decreases the security benefits promised by the slider depending on the context and on users expectations which seems tricky to resolve.
After rethinking my example in #21034 I think I am not really convinced that it is a good one for showing that FPI makes things worse. Additionally, it seems to me the discussion we had so far about FPI for security settings seems to have shifted from having '"Safe", "Safer", and "Safest"'-per site (as in the bug) to "exceptions to Safer and Safest"-per site. That might be a useful distinction for the discussion of the slider and FPI.
Georg
-
Georg Koppen -
Mark Smith -
Michael Schloh von Bennewitz