Re: [tor-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" <blackhole@xxxxxxxxxxxxxx>]

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

 Replying to [comment:34 gk]:
 > The security risks don't map the the underlying transport ot its
 security being used. The security risks we try to tackle are to a large
 part due to the *content* that gets transferred. Someone injecting this
 content on the path from server to user is an important risk but just one
 of those we need to defend against. This binding the security state to
 HTTP/HTTPS is not sufficient. Moreover, the strongest security we want to
 provide is something like the current "safest" option we have. We won't be
 able to enable this by default probably forever as the breakage is too
 high, irrespective of the transport being used.

 We have discussed this issue previously, but I wanted to try laying it out
 in more detail and see if that helps to clarify the different approaches.
 :)

 We already have a "Safest" setting that maximizes security guarantees. I
 agree we shouldn't lower those guarantees. We also have a "Safe" (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 "Safe"
 so that it is worthwhile to make it available.

 Let's compare two possible "Safer" (Medium) Security designs:

 Design (1), the status quo (Tor Browser 8.0.x):

 || || Unblocked || Blocked ||
 || HTTP || WebFont, blob, SVG || scripts, WebGL, Video, Audio, WebAudio,
 MathML, JIT ||
 || HTTPS || WebFont, blob, SVG, scripts, WebGL || Video, Audio, WebAudio,
 MathML, JIT ||

 Design (2), proposed in comment:33:
 || || Unblocked || Blocked ||
 || HTTP || || WebFont, blob, SVG, scripts, WebGL, Video, Audio, WebAudio,
 MathML, JIT ||
 || HTTPS || WebFont, blob, SVG, scripts, WebGL, Video, Audio, WebAudio,
 MathML, JIT || ||

 So, which of these two options is more secure? (1) has better security for
 HTTPS and (2) has better security for HTTP. Overall security depends on
 one's threat model.

 Consider the two main potential threats:
 (A) '''Hostile content injected at exit nodes, or between server and exit
 node.''' To combat this threat, it seems that Design (2) is somewhat
 better because it blocks the most content in HTTP.
 (B) '''Hostile content from the website itself, or subresources.''' Which
 design is safer depends on whether the hostile site is HTTP or HTTPS. If
 an HTTP site is hostile, Design (2) is preferred. If an HTTPS site is
 hostile, Design (1) is preferred.

 The next question: which of the two threats are dominant in a real user's
 threat model? I think there are different categories of users:

 (I) '''Users who are unconcerned about threats or unable to handle broken
 websites.''' For these users, "Safe" (Low) security is the (default)
 choice.
 (II) '''Users who only visit "trustworthy" sites.''' (I define
 "trustworthy" as websites the user expects will not send malicious code.)
 For these users, Threat (A) is the dominant threat and in this case,
 "Safer" security seems appropriate, and Design (2) is better.
 (III) '''Users who visit "untrustworthy" sites.''' For these users, Threat
 (B) can be the dominant threat. (But Threat (A) still exists for these
 users to the same extent as for Category (II) users. The total risk of
 being exploited is higher.) Assuming they are using the "Safer" level,
 these users may prefer Design (1), at least for HTTPS.

 Perhaps, up to this point, my description is fairly uncontroversial. ;) I
 hope this kind of analysis is useful regardless of our final decision for
 the "Safer" level.

 ----

 But now I want to think further about Category (III) users. These users
 are visiting untrustworthy websites; they are high-risk users. Why would
 the user want to leave SVG, WebFonts, or scripts unblocked if they think a
 site is untrustworthy? While it's true that some websites will work
 better, it seems dangerous to assume we know which type of content will be
 exploited by a malicious website. (I'm open to being convinced that there
 is a much greater risk from video than from scripts, say, but I haven't
 seen evidence for that.) So it seems to me that Category (III) users
 should generally use the "Safest" setting instead of "Safer" Design (1).

 What about relative usability of these two designs for the "Safer" level?
 I think Design (2) is clearly more usable because:
 * Design (2) is simpler for users to understand than Design (1). For every
 website, we either have initial protection "on" or "off", corresponding to
 whether the site is high risk or low risk.
 * In Design (2), HTTPS websites (such as https://youtube.com) will work
 correctly by default.

 To sum up, my feeling is that "Safer" level with Design (2) offers better
 security and better usability to users who habitually visit "trustworthy"
 sites only. And the "Safest" level already provides the comprehensive
 protections needed for high-risk users who visit "untrustworthy" sites.

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs