Opened 2 years ago

Last modified 14 months ago

#21034 new defect

Per site security settings?

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: yawning, brade, mcs, gk, jonathanfemideer, intrigeri, fdsfgs@…, i139 Actual Points:
Parent ID: #20843 Points:
Reviewer: Sponsor:

Description

It would be useful (and perhaps safer) to have per-site security settings rather than browser-wide security settings. Also we might want to enforce different security settings for http vs https.

In Firefox 52, with e10s enabled, perhaps we can use separate content processes for every first-party and apply different security settings prefs separately to each one.

Child Tickets

Change History (24)

comment:1 Changed 2 years ago by yawning

Cc: yawning added

comment:2 Changed 2 years ago by mcs

Cc: brade mcs added

comment:3 Changed 2 years ago by gk

Cc: gk added

comment:4 Changed 2 years ago by yawning

Parent ID: #20843

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

comment:5 Changed 2 years ago by jonathanfemideer

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:

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

These both have disadvantages. Respectively:

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

Last edited 2 years ago by jonathanfemideer (previous) (diff)

comment:6 in reply to:  4 Changed 2 years ago by 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.

Last edited 2 years ago by jonathanfemideer (previous) (diff)

comment:7 Changed 2 years ago by jonathanfemideer

Cc: jonathanfemideer added

comment:8 Changed 2 years ago by intrigeri

Cc: intrigeri added

comment:9 Changed 2 years ago by tokotoko

Cc: fdsfgs@… added

comment:10 in reply to:  5 ; Changed 2 years ago by 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.

comment:11 in reply to:  10 ; Changed 2 years ago by 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.

comment:12 in reply to:  11 Changed 2 years ago by teor

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

comment:13 Changed 2 years ago by 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:

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

comment:14 in reply to:  13 ; Changed 2 years ago by 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:

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

Last edited 2 years ago by arthuredelstein (previous) (diff)

comment:15 in reply to:  14 ; Changed 2 years ago by gk

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:

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

comment:16 in reply to:  13 ; Changed 2 years ago by 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:

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.

The answer here is, "Yes." (See 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:

  1. which subdomain it arrived from; and
  2. 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 :)

Last edited 2 years ago by jonathanfemideer (previous) (diff)

comment:17 in reply to:  15 Changed 2 years ago by arthuredelstein

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:

If we add a patch that allows per-first-party security setting, the user does this:

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:

In a browser with proposed patch:

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.

comment:18 in reply to:  16 ; Changed 2 years ago by gk

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:

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.

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?

comment:19 Changed 2 years ago by mcs

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.

comment:20 in reply to:  18 Changed 2 years ago by jonathanfemideer

Replying to gk:

Replying to jonathanfemideer:

Replying to gk:

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?

Good catch! You are absolutely right. Sorry for my mistake, and thanks for taking the time to make emphasize to me that the context you were asking about in the portion of your question that I quoted was the iframe in that tab, not the whole site, the whole page, or the whole content of the tab.

So, instead of saying, 'Again, the answer here is, "No,"...' I should have said, 'The answer here is, "Yes."'

I have amended comment 16 accordingly. I hope it makes sense now :)

Version 1, edited 2 years ago by jonathanfemideer (previous) (next) (diff)

comment:21 Changed 22 months ago by gk

Cc: i139 added

#22344 has some ideas how to visualize this on an Android phone. (marking that one as duplicate)

comment:22 Changed 20 months ago by tom

I haven't seen any comment about setting persistence, unless I've missed it.

If you set custom settings for a domain, to persist those settings we'll have to record that you visited that domain, persist that to disk, and keep it there forever essentially. That's pretty horrible from a privacy perspective.

The alternative is just as bad from the user experience side. Every time you open tor Browser, you're going to have to reset your slider settings as you visit each of your frequently visited sites.

comment:23 in reply to:  22 Changed 20 months ago by arthuredelstein

Replying to tom:

I haven't seen any comment about setting persistence, unless I've missed it.

If you set custom settings for a domain, to persist those settings we'll have to record that you visited that domain, persist that to disk, and keep it there forever essentially. That's pretty horrible from a privacy perspective.

You're right -- in terms of disk hygiene, that is very undesirable.

The alternative is just as bad from the user experience side. Every time you open tor Browser, you're going to have to reset your slider settings as you visit each of your frequently visited sites.

Unfortunately, the current deployed UX is already akin to that, but worse. Namely, that users on Medium or High security have to whitelist multiple scripts or video/audio every time they visit a favorite site. It's more complex than a per-site slider.

But lately I'm inclined to think that #22981, #22982, and #22985 would largely mitigate the problems this ticket was intended to address.

comment:24 Changed 14 months ago by cypherpunks

For those interested, gk posted a proposal that seeks to change how security controls are shown to the user and that addresses per-site security settings: https://lists.torproject.org/pipermail/tbb-dev/2018-February/000756.html

Note: See TracTickets for help on using tickets.