[tbb-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

 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''

 > 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

 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 tbb-bugs mailing list