Per site security settings?

added component::applications/tor browser owner::tbb-team parent::20843 priority::medium severity::normal status::new type::defect labels

Trac:
Cc: N/A to yawning

Trac:
Cc: yawning to yawning, brade, mcs

Trac:
Cc: yawning, brade, mcs to yawning, brade, mcs, gk

I think this falls under the "encourage people to actually change the slider off the default" ticket.

Trac:
Parent: N/A to #20843 (moved)

There should be a way for the user to keep the security level at High for all sites except for a few specific sites, and to set the latter to Medium.

In Tor Browser 6.5, this does not seem to be possible. In particular, there does not seem to be a way to choose per-site security settings.

In a ideal world, users would be able to use the "High" setting, and this would just work on all sites. (Onion > Security Settings > High.)

However, some websites (e.g. some bug trackers and some webmail clients) are built in a way that requires the user to execute some JavaScript. For such websites and webmail clients, the only two options seem to be:

Change the browser security settings (Onion > Security Settings > Medium).
Click NoScript icon > "Temporarily allow all this page".

These both have disadvantages. Respectively:

If the user subsequently opens a new tab to visit a different website, this will now only be at the Medium security setting instead of the High setting, even if this latter website would work fine with the High setting. So the user's security gets reduced on the new site, unnecessarily. Alternatively, if the user is keeping one or more tabs open for the first site, while using other tabs to browse other sites that are less trusted or don't require the Medium setting, then the user has to keep adjusting the browser security level each time they want to interact with the first site in one of those tabs. TL;DR: switching tabs shouldn't require changing security settings to make the contents of those tabs function.
"Temporarily allow all this page" seems to be less secure than the Medium security setting. A user might trust a website (or need to use it) just enough to be willing to reduce the security level to Medium in order to make it function, but no lower than that. "Temporarily allow all this page" seems to be more like reducing the security level for that site to Low.

So, to reiterate, there should be a way for the user to set the default security level to High, and then to make exceptions on a per-site basis.

N.B. I have not yet encountered any websites that require the security level to be set to Low, but perhaps such websites do exist. If so, then please consider my request to extend to allowing a per-site setting of Low for those websites.

(Original discussion: https://lists.torproject.org/pipermail/tor-talk/2017-March/042982.html )

Trac:
Username: jonathanfemideer

Replying to yawning:

I think this falls under the "encourage people to actually change the slider off the default" ticket.

That is a separate problem, IMO. However, letting the user choose per-site security settings (i.e. addressing this ticket) could well be the best way to solve it, or at least an important part of the solution.

Trac:
Username: jonathanfemideer

Trac:
Username: jonathanfemideer
Cc: yawning, brade, mcs, gk to yawning, brade, mcs, gk, jonathanfemideer

Trac:
Cc: yawning, brade, mcs, gk, jonathanfemideer to yawning, brade, mcs, gk, jonathanfemideer, intrigeri

Trac:
Username: tokotoko
Cc: yawning, brade, mcs, gk, jonathanfemideer, intrigeri to yawning, brade, mcs, gk, jonathanfemideer, intrigeri, fdsfgs@krutt.org

Replying to jonathanfemideer:

N.B. I have not yet encountered any websites that require the security level to be set to Low, but perhaps such websites do exist. If so, then please consider my request to extend to allowing a per-site setting of Low for those websites.

HTTPS sites that use JavaScript.

Replying to teor:

Replying to jonathanfemideer:

N.B. I have not yet encountered any websites that require the security level to be set to Low, but perhaps such websites do exist. If so, then please consider my request to extend to allowing a per-site setting of Low for those websites.

HTTPS sites that use JavaScript.

There are plenty of HTTPS sites that use JavaScript and work just fine without the security level needing to be set to Low. This Trac instance, for example! And GitHub, and many others.

Trac:
Username: jonathanfemideer

Replying to jonathanfemideer:

Replying to teor:

Replying to jonathanfemideer:

N.B. I have not yet encountered any websites that require the security level to be set to Low, but perhaps such websites do exist. If so, then please consider my request to extend to allowing a per-site setting of Low for those websites.

HTTPS sites that use JavaScript.

There are plenty of HTTPS sites that use JavaScript and work just fine without the security level needing to be set to Low. This Trac instance, for example! And GitHub, and many others.

Sorry, that was a typo, I meant to write: HTTP sites that use JavaScript.

(But, of course, I type HTTPS by default now.)

So, I am inclined to resolve this as WONTFIX due to the UX nightmare at least. But for now let's assume we implement this indeed how is the implementation supposed to behave in the following scenario:

By default the user is in "medium" mode.
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.
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? Is it "high" because one said in 1) for foo.com the rule is "high"? 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?

Replying to gk:

So, I am inclined to resolve this as WONTFIX due to the UX nightmare at least. But for now let's assume we implement this indeed how is the implementation supposed to behave in the following scenario:

By default the user is in "medium" mode.

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.

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? Is it "high" because one said in 1) for foo.com the rule is "high"? 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?

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".

Already, a first-party domain is ultimately responsible for everything loaded in a page, including third-party scripts and iframes. And some first-party domains are more trustworthy than others.

For example, I sometimes keep Tor Browser on the "high security" setting by default. Sometimes I need to lower the security level for a particular HTTPS site because it is otherwise unusable. In that case, I have determined that I trust the site not to embed a shady third-party iframe. Unfortunately, currently, in order to lower the security setting of that site, I need to lower the security setting for all sites. This is obviously dangerous and also potentially risks cross-site linking.

As far as UX is considered, my thinking would be to have security setting button next to the URL bar, similar to the NoScript button. The button's dropdown menu would have the title "Security setting for this page" with the three options (Low, Medium, High). In fact, it might be possible to hide the NoScript button altogether, because the "Temporarily allow all this page" menu option is more or less redundant in this situation.

Having a separate content process for each first-party not only would make this possibly feasible, but it would also reduce the risk that exploits can link one tab to another. So if lowering defenses on one tab turns out to have been a mistake, at least we have some hope of containing the damage.

Replying to arthuredelstein:

Replying to gk:

So, I am inclined to resolve this as WONTFIX due to the UX nightmare at least. But for now let's assume we implement this indeed how is the implementation supposed to behave in the following scenario:

By default the user is in "medium" mode.

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.

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? Is it "high" because one said in 1) for foo.com the rule is "high"? 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?

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.

Replying to 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:

By default the user is in "medium" mode.

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.

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.~~

The answer here is, "Yes." (See comment [comment:20].)

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:

which subdomain it arrived from; and
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 Security Slider manual.

What I am describing here is much like the functionality provided by NoScript or by 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 and its "dirty" flag should be cleared. Any JavaScript present in such content, that reached the browser via https:!//foo.com, should now run, albeit with JavaScript optimizations disabled, as per the Medium setting.

I hope this makes sense :)

Trac:
Username: jonathanfemideer

Replying to gk:

Replying to 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 (moved).

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.

Replying to jonathanfemideer:

Replying to 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:

By default the user is in "medium" mode.

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.

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.

I am confused about that one because reading the other parts of your response leads me to assume you meant "Yes". The context of the quote you took is the iframe and not the whole site. Or did I misunderstand your position?

I attended a session during the recent Tor meeting where similar issues were discussed. For reference, the session notes are here: Security Slider Usability Session Notes.

Per site security settings?

Child items ...

Activity

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.