[tbb-bugs] #25658 [Applications/Tor Browser]: Activity 2.1: Improve user understanding and user control by clarifying Tor Browser's security features

[Tor Bug Tracker & Wiki]

#25658: Activity 2.1: Improve user understanding and user control by clarifying Tor
Browser's security features
-------------------------------------------+---------------------------
 Reporter:  isabela                        |          Owner:  antonela
     Type:  project                        |         Status:  assigned
 Priority:  High                           |      Milestone:
Component:  Applications/Tor Browser       |        Version:
 Severity:  Normal                         |     Resolution:
 Keywords:  ux-team, TorBrowserTeam201810  |  Actual Points:
Parent ID:                                 |         Points:
 Reviewer:                                 |        Sponsor:  Sponsor17
-------------------------------------------+---------------------------

Comment (by gk):

 Replying to [comment:33 antonela]:
 > back to game - from Geko's proposal
 >
 > [https://lists.torproject.org/pipermail/tbb-dev/2018-March/000799.html]
 >

 It seems you did not use the latest iteration of it. It is now in our tor-
 browser-spec repo: https://gitweb.torproject.org/tor-browser-
 spec.git/tree/proposals/101-security-controls-redesign.txt.

 > **2.1.1 Removing HTTPS Everywhere and NoScript from the Toolbar**
 >
 > Agreed. Wondering how we will handle HTTPSE for .onion improvements. But
 I know, is further problem. Let's stick to this idea for now.
 >
 > **2.1.2 Adding a Security Settings Button to the Toolbar**
 >
 > As discussed previously, expose the security settings to the toolbar is
 a good addition, but it does not solve the real problem. I've tried a
 couple of options before in this thread.
 >
 > Also, in order to keep the cohesion between the UI components behavior,
 we agreed that global settings would live at `about:preferences.`

 See the latest proposal here about what we planned.

 > **2.2 Dealing with Per-Site Security Settings**
 >
 > We agreed to move site-specific settings to the Control Center (url
 bar's doorhanger). I made a mockup to illustrate this iteration.
 >
 > Unfortunately, Firefox is using a shield icon to illustrate the Block
 Content aka Tracking Protection feature. This is cool, too. But, I agreed
 that could be confusing for users using the same kind of icon to show our
 Tor Browser protections. Perhaps a lock icon, which is also related to
 security topics, would help us.
 >
 > [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/25658/25658%20-%206.0.png, 700px)]]
 >
 > Again: I think that the best way to improve the security slider is
 removing the slider component. As mentioned before, the slider is a UI
 artifact that doesn't add any value to this settings. Instead, it confuses
 users about their benefits on upgrade or downgrade.

 What do you mean about removing the slider component? And what is "this
 settings"?

 > If we could simplify the security settings into a boolean option, we
 will follow the current Firefox approach on settings both in desktop and
 in mobile, and we will help users by making it easier to understand the
 trade-off: "Do I trust in this site?"
 >
 > My idea is to have our Security Protection ON by default on `HTTP` sites
 and OFF by default on `HTTPS` sites. For sure, it could be easy changed
 via global settings at `about:preferences`.  I'm happy to hear your
 thoughts about it.
 >
 > With the boolean option, this will look more like
 >
 > ON: HTTP protected, HTTPS protected
 > OFF: HTTP protected, HTTPS unprotected

 The security risks don't map the the underlying transport 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.

 Additionally, see section 3.3 of the design proposal linked to above.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25658#comment:34>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online