[tor-bugs] #21034 [Applications/Tor Browser]: Per site security settings?
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Mar 28 16:05:36 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 jonathanfemideer):
Replying to [comment:13 gk]:
> So, I am inclined to resolve this as `WONTFIX` due to the UX nightmare
at least.
Please don't close this as `WONTFIX`. Let us instead use this bug report
(or feature request) to figure out how best to meet the desired security
improvements.
Your question below is a great start. Thank you for asing it!
> But for now let's assume we implement this indeed how is the
implementation supposed to behave in the following scenario:
>
> 0) By default the user is in "medium" mode.
> 1) In tab 1 one has foo.com open. A user does not like to have "medium"
mode here but says: "For this site I want to have high security because I
am scared" and adapts that accordingly.
> 2) In tab 2 bar.com is open which is per default (see 0)) above in
"medium" mode. But bar.com includes an iframe pointing to foo.com.
>
> Now the question is: what are the security settings for stuff loaded in
the iframe? Is it "medium" because it is embedded in bar.com and bar.com
is the site you are in contact with?
The answer here is, "No," because of the false premise, "''bar.com is
'''the''' site you are in contact with''". This premise is false because
the user in your example is viewing, within one tab, content from ''both''
sites.
> Is it "high" because one said in 1) for foo.com the rule is "high"?
Again, the answer here is, "No," and again this is because the user is
viewing, within one tab, content from ''both'' sites.
> If the latter how does one cope with broken sites and the problem that
one is actually dealing with *sites* and not particular elements embedded
in it? If the former why do we have per site security settings at all?
I believe that this feature request is, strictly speaking, wanting Tor
Browser to have ''per-subdomain'' security settings. The term "site" is
not well-defined, but subdomain is. (I should have been clearer about this
in my comment above. Mea culpa.)
Once that is understood, the rest starts to fall into place. Content
should be treated according to:
1. which subdomain it arrived from; and
1. what the security slider setting is for that subdomain.
In your example, all content from foo.com (i.e. the stuff that is coming
into the browser via the iframe, assuming it is all from foo.com) should
be treated with the "High" setting, meaning that e.g. no JavaScript in
''that'' content will be run at all. Likewise, all content from bar.com
(i.e. the rest of the stuff in that page, assuming it is all from bar.com)
should be treated with the "Medium" setting, meaning that e.g. any
JavaScript in there will only be run if it arrived over HTTPS, but even
so, it will have JavaScript performance optimizations disabled.
''Mutatis mutandis'' for all the other criteria that are relevant to the
High and Medium settings, per the [https://tb-manual.torproject.org/ar
/security-slider.html Security Slider manual].
What I am describing here is much like the functionality provided by
[https://en.wikipedia.org/wiki/NoScript NoScript] or by
[https://en.wikipedia.org/wiki/UBlock_Origin uBlock Origin]. These both
allow JavaScript to be blocked by default, and then enabled per-domain by
the user. These settings apply globally across the browser's tabs.
(N.B. uBlock Origin also allows the user to select per-subdomain
''contexts'' in which to allow a(nother) given subdomain to execute
scripts, but this complicates the UI somewhat. E.g. I could choose to
allow `google-analytics.com` to execute within pages from `foo.com` but
not within pages from `bar.com`. I propose we forget about such fine-
grained contextual rules for now, to keep the complexity low.)
Those two add-ons could be a source of inspiration (and code) for Tor
Browser UX/UI elements with which to implement the desired functionality.
Probably, the Tor Browser should keep things a bit simpler than those two
add-ons do, though, to reduce the risk of a user becoming confused and
misconfiguring their Tor Browser in a way that undermines their security.
I would suggest that clicking the Torbutton should show, in addition to
the "Tor circuit for this site" pane, etc, a column of sliders, one for
each origin subdomain that the page in the current tab is attempting to
load content from. Using ASCII art with "@" instead of an onion:
{{{
-----
| @ |
-----
|----------------------------------------------------------------------------
| New Identity Ctrl+Shift+U | Tor circuit for this site
|
| New Tor Circuit for this Site Ctrl+Shift+L | (torproject.org)
|
| --------------------------------------------| o This browser
|
| Tor Network Settings... | o Germany (xx.xx.xx.xx)
|
| --------------------------------------------| o Russia (xx.xx.xx.xx)
|
| Check for Tor Browser Update... | o New Zealand
(xx.xx.xx.xx) |
| | o Internet
|
|---------------------------------------------------------------------------|
| Security settings for subdomains in use
|
|
|
| Low Medium
High |
|
|
| bar.com
|
|
|----------------------------------[]-----------------------------------|
|
|
|
| foo.com
|
|
|-----------------------------------|----------------------------------[]
|
|
|
-----------------------------------------------------------------------------
}}}
There might be a better phrase to use than "Security settings for
subdomains in use", but it will do for illustrative purposes.
Here's a variation on your example use-case.
Suppose bar.com embeds foo.com in an iframe as per your example. Suppose
also that the user has https://foo.com open in their first tab, and
https://bar.com open in a second tab, and that they are presently viewing
the second tab. Suppose they then click the Torbutton, yielding the menu
illustrated above. Suppose they adjust the foo.com slider from High to
Medium, and then click in some whitespace on the page to return focus to
the page. What should happen?
I believe what should happen is this: all tabs that call content from
foo.com should be marked as "dirty". Upon viewing any "dirty" tab (e.g.
the present tab), its content should be refreshed. Any JavaScript present
in such content, that reached the browser via http**s**:!//foo.com, should
now run, albeit with JavaScript optimizations disabled, as per the Medium
setting.
I hope this make sense :)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21034#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list