[tbb-dev] Proposal for redesigning the security controls
Arthur D. Edelstein
arthuredelstein at gmail.com
Fri Feb 2 01:33:05 UTC 2018
Thanks for sharing this proposal, Georg. I think it's a really good
approach for simplifying the UI. I definitely agree it would be good
to hide the NoScript toolbar button, and of course we would need to
re-surface some of its functionality so it's easier to understand. I
want to mention a couple of issues I think we discussed in Montreal
but I think might be useful in the discussion here.
1. A current problem we have with NoScript is that it does not respect
first-party isolation (FPI), which is both a security and privacy
issue. For example, if I set the Security Settings to Medium, and
visit youtube.com, and click on the NoScript button to unblock media
from YouTube.com, then embedded YouTube videos are now unblocked on
all other websites. The same goes for more subtle things like Google
Analytics scripts. So I'd propose we try to get FPI working for
NoScript unblocking, similar to our enforcement of FPI for Permissions
from #21569. That's especially important if we emphasize that controls
in the URL bar or the Permissions door-hanger are intended for
per-site use.
2. The Security Slider is also quite dangerous if used for per-site
purposes. If a user decides they want to visit A.com at "Low" Security
and B.com at "High" Security, they have to be very careful not to
accidentally expose B.com to "Low" Security. A simple click of the
back button could result in a mistake. Or, if the user has multiple
tabs or windows open, and they switch the Security Slider, because of
the current tab, they apply the new security setting to all open tabs,
which could result in accidental unwanted exposure to dangerous
content in background tabs.
Therefore, I'm wondering if putting the Security Slider on the toolbar
might actually increase the danger for some users by encouraging its
frequent use. A possibly safer approach could be to display the global
Security Slider either embedded in the about:tor page, or in a prompt
at startup. That way we can force users to make a one-time decision
for the global setting and discourage them from changing it repeatedly
while they browse.
Yet another approach could be to invoke "New Identity" whenever
Security Settings are changed, such that all tabs are closed and a new
empty window is opened before the new global setting takes effect. (Of
course users would need to be warned and given the option to cancel.)
3. I don't think it's feasible to make scripts, Fonts, MathML, some
audio, etc., click-to-play. And while it's true that video, SVG and
WebGL can be click-to-play, in practice it may be challenging to make
the click-to-play behavior work smoothly given the interactions with
scripts. So one issue we'll have to consider is how many different
per-site options we expose to users in the Permissions doorhanger. I
think it would be confusing to ask users to decide which content
features (scripts vs. fonts vs videos vs ...) are safe to enable;
rather, they should be answering the question: do I consider this
website to be dangerous or not? So, my suggestion would be to expose a
single toggle option: namely, [all-features-disabled |
all-features-enabled].
On Thu, Feb 1, 2018 at 12:27 AM, Georg Koppen <gk at torproject.org> wrote:
> Hi!
>
> I managed to come up with a proposal for redesigning the security
> controls (see below). As always feedback and discussion is very welcome.
>
>
> Filename: XXX-redesign-security-controls.txt
> Title: Redesign of Tor Browser's Security Controls
> Author: Georg Koppen
> Created: 1-February-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 Bowser 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 and 3.3.
>
> 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.
>
> 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 be made visible once there is a
> respective object embedded in a website or, even better, once the user
> actually chose to unblock any of them.
>
> 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/tor-browser/Bundle-Data/linux/Data/Browser/profile.default/preferences/extension-overrides.js
> [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
>
>
> _______________________________________________
> tbb-dev mailing list
> tbb-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
>
More information about the tbb-dev
mailing list