[tor-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 -->
exploited
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 tor-bugs
mailing list