[tbb-bugs] #21034 [Applications/Tor Browser]: Per site security settings?

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Mar 29 02:34:41 UTC 2017

#21034: Per site security settings?
 Reporter:  arthuredelstein           |          Owner:  tbb-team
     Type:  defect                    |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:                            |  Actual Points:
Parent ID:  #20843                    |         Points:
 Reviewer:                            |        Sponsor:

Comment (by arthuredelstein):

 Replying to [comment:15 gk]:
 > Replying to [comment:14 arthuredelstein]:

 > > When I opened this ticket, I was envisioning the former (sorry this
 wasn't clearly stated). So maybe, strictly speaking, the proposed feature
 should be called "per-first-party security settings" instead of "per-site
 security settings".
 > But the user in my example clearly indicated they want to have foo.com
 in "high" mode. Like clearly, clearly, because they are scared about that
 particular domain. That wish is not dependent on any other site embedding
 foo.com nor on any other site doing so on any security level. What I am
 trying to say is: making security decisions based on the URL bar domain
 does not work. The malware from foo.com you are afraid of does not care if
 there is first-party isolation on or off. It just needs *one way* to get
 to you. I believe users are aware of that and expecting that a security
 slider that defends them against that takes this into account.

 TLDR: I think there are serious problems with the current security slider
 behavior, but I tend to agree that the proposed behavior (per-first-party
 settings) is perhaps too difficult to make clear to the user.

 I now realize that, implicit in my model is that the user should start in
 default "high" mode and then use "medium" or "low" security on specific
 sites when more usability is needed. With my proposed of a simple drop-
 down attached to the URL bar, it's impossible for the user to raise the
 security of a site before they have already visited! Very similar to
 NoScript's popup menu.

 So let's take your example, but starting in default "high" security (call
 it Example A):

 In general, users don't know, unless they inspect network requests or
 source code, that bar.com sources an evil iframe from foo.com. All they
 can see is "bar.com" in the URL bar.

 In the current Tor Browser, with a global security setting, here's what
 the user does:
 * Set security to High and visit https://foo.com/ --> protected
 * Visit https://bar.com/ and then set security to Medium --> exploited

 If we add a patch that allows per-first-party security setting, the user
 does this:
 * Set default security to high
 * Visit https://foo.com --> protected
 * Visit https://bar.com, and then set bar.com's security to Medium -->

 So in Example A, the status quo is just as bad as a per-first-party
 security setting patch. Regardless, bar.com has an undeserved "safe"
 reputation and the user was unfortunately exploited.

 Let me now propose Example B. Suppose another site, baz.com, has a well
 deserved safe reputation. The user wants to visit baz.com and the same
 dangerous foo.com.

 In the current Tor Browser:
 * Set global security to High and visit https://foo.com/ --> protected
 * Visit https://baz.com/ in the same tab, and then lower global security
 to Medium --> safe
 * Click the Back button to return to https://foo.com  --> oops! exploited

 In a browser with proposed patch:
 * Set default security to high
 * Visit https://foo.com --> protected
 * Now visit https://baz.com in the same tab, and then lower baz.com's
 security to Medium --> safe
 * Click the Back button to return to https://foo.com --> still protected

 So in Example B, in current Tor Browser it's too easy for the user to
 forget they need to set the default setting to "High" before clicking the
 back button. And I think the potential for user opsec mistakes could get
 even worse if we implement #21153.

 But despite this argument I am inclined to agree that the semantic
 problems associated with the proposed change are pretty serious. Will the
 user really understand the distinction between per-domain and per-first-
 party-domain security settings? Perhaps not. So I'm not sure how to solve
 this problem.

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

More information about the tbb-bugs mailing list