#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 _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs