Opened 7 months ago

Last modified 4 days ago

#30570 assigned enhancement

Implement per-site security settings support

Reported by: gk Owned by: pospeselr
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ux-team, tbb-9.5, TorBrowserTeam201912
Cc: tbb-team, dmr, isnaiter, arthuredelstein, mcs, brade, intrigeri, ma1 Actual Points:
Parent ID: #25658 Points: 10
Reviewer: Sponsor: Sponsor9

Description (last modified by gk)

The native (without messing with the NoScript menu) per-site security settings support mentioned in proposal 101 (https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101-security-controls-redesign.txt) is still missing. This ticket is for implementing it.

Child Tickets

Change History (14)

comment:1 Changed 6 months ago by pili

Sponsor: Sponsor9

comment:2 Changed 5 months ago by torlove

Thanks for opening this ticket, gk. Good to see that there is a sponsor for this.

The document referred to above:
https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101-security-controls-redesign.txt

As I have said in another ticket:

"It is a good document, whatever we can do to make things easier for beginners is good.

There are two items discussed in the resource above that have not been done.

1) Educating the user about the changes.

Although it was not part of the scope of the document the author clearly states that this is an area that requires attention. It is important to tell users of impending changes, and to inform a user when a change is implemented. The home screen is the best place to do that.

2) Moving per-site js permissions (NoScript) too the URL bar:

In my opinion, NoScript should be moved to the URL bar to the right of the "Toggle Reader View" button. The icon should be one that suggests code or scripting, either:

a) a tiny backslash inside angled brackets, or
b) the standby/power symbol (​https://www.symbols.com/symbol/standby-symbol), or
c) a gear icon with JS written lightly inside.

Alongside the icon should be a small tag with the number of js domains blocked having a strike-though. The number of approved js domains used by the page would not have a strike-though.

NoScript needs to continue being one click away because when a page/document loads and the JS is blocked there is no way to re-trigger the page load event. So there are times when the user must access NoScript after multiple page load events. Typically two page loads are needed, but I have seen websites where five page loads are needed. The user needs to repeat this process for a domain every time they restart Tor browser.

In the interests of educating the user, after restarting the browser we might inform the user that editing the permissions may make fingerprinting easier. Especially if you repeatedly use the same settings.

Furthermore, in terms of simplifying the toolbar, the 'three dot icon' is redundant. The three options a user gets is:

  • Bookmark this page (the user already has a bookmark button)
  • Copy link.
  • Email link.

None of these options add value, I'd much rather dedicate the space to the NoScript icon and subsequent tag.

comment:3 Changed 5 months ago by cypherpunks

Can we get something like Firefox Containers type UX?

comment:4 Changed 5 months ago by torlove

Not to stray too far off topic here (ie. skip this comment if you are wanting to read about the topic of this thread) but as I understand it, presently Tor Browser isolates all tabs, so the need for Containers is redundant. Am I mistaken?

If you really wish to isolate say, one search from the next search, wouldn't it be better to provide an option on long-pressing the refresh button to not only refresh but to visit the site at the top level and clear/reset all cookies?

So for example if I searched at duckduckgo for "foo" and then I want to search for "bar" after, but I don't want DDG to know that I, as a single anonymous entity, searched for both "foo" and "bar", is the only option to click new identity and basically wipe reset the entire browser? I basically want to perform two operations at once;
a) strip everything from the URL that comes after the slash (to access the top level or index page of the domain, and
b) click the "New Circuit for this Site" button, which I assumed also clears cookies but on second thought I'm not 100% certain about that.
c) Clear cookies, (if cookies are not cleared by b) )
d) Wipe away ALL history from that tab such that the Back button won't work.
e) Close all other tabs that are accessing that page.

This button could be labelled "Fire Reload"?

Presently there is no way to do this without pressing New Identity and clearing everything. I understand that after 10 minutes a new circuit is created for all sites, but cookies are not deleted. Which opens a person up to fingerprinting? Is that correct?

Also, on the topic of fingerprinting, if a person accidentally resizes the window there should be a button to reset the size back to a size for their display? I suggest a flashing caution icon, over the onion. The user clicks the onion icon and there is a menu item "Reset Window Size"? (Note: I just did a search on this and it's been asked a bunch of times.
See https://trac.torproject.org/projects/tor/ticket/16364

To further mix things up, on startup, there should probably be an "Immitate a random screen size" button, for user that want to use it. To view a website on a random smaller screen size that is standard (ie. popular laptops, tablet size, phones, etc.). Importantly a user should be encouraged to keep that screen size for the duration of the session, if they want a different screen size they need to select "New Identity" in the onion menu.

Regardless we should not stray from the important topic above, and should create a new topic to discuss isolation/anti-fingerprinting/randomisation strategies.

comment:5 Changed 3 months ago by intrigeri

Cc: intrigeri added

comment:6 Changed 2 months ago by pili

Keywords: TorBrowserTeam201910 added

comment:7 Changed 2 months ago by gk

Description: modified (diff)
Points: 10

comment:8 Changed 7 weeks ago by gk

Owner: changed from tbb-team to pospeselr
Status: newassigned

comment:9 Changed 7 weeks ago by sysrqb

Keywords: TorBrowserTeam201911 tbb-9.5 added; TorBrowserTeam201910 removed

comment:10 Changed 4 weeks ago by pospeselr

Here is a mockup from last year of what per-site permissions could look like: https://marvelapp.com/a66fg97/screen/50307973

Current Settings

Here's a summary of the settings affected by the Security Level by both NoScript and our general prefs.

Default:
Safer:

TorButton

JavaScript JIT (slower JS speed)
SVG
MathML
WebAudio

NoScript (Default HTTP)

Fetch
Media
Script
WebGL

NoScript

Media
WebGL

Safest:

TorButton

JavaScript JIT (slower JS speed)
SVG
SVG OpenType Fonts
MathML
WebAudio

NoScript (HTTP and HTTPS)

Fetch
Font
Media
Object
Script
WebGL

Without having delved too deeply into the prefs set by torbutton, I think we can safely assume that it will not be easy to modify Firefox to have per-tab scope for these globals, so for this ticket they can probably be safely ignored for now.

The remaining settings are controlled by NoScript and already have some level of per-domain scope. We should in theory be able to access whatever functionality exists in NoScript (or modify it to export said functionality) to set the 'custom' permissions.

The combined list of NoScript capabilities that we potentially block are:

  • fetch (XMLHttpRequests and similar)
  • font (Web Fonts)
  • media (HTML5 audio/video)
  • object (Plugins)
  • script (JavaScript)
  • webgl (WebGL)

I think that 'Fetch' and 'JavaScript' could probably be joined together as a meta capability for the purposes of our UX, which would bring us down to 5:

  • JavaScript + Fetch
  • Web Fonts
  • Media
  • Plugins
  • WebGL

Per Domain Control

One big conflict between UX and security here is that NoScript provides very fine-grained control over each domain, so users can pick and choose which domains get which capabilities (for instance enabling scripts from website.com but not from tracker.com).

However, if we're going the permissions route via the info (i) icon we will need to decide which domain that a custom setting would apply to. To 'just make a website work' and enable JavaScript for example, we would probably have to enable it for every domain used in a page, otherwise we end up with frustrated users.

We could split up each of the NoScript capabilities to differentiate between the first-party domain (youtube.com) and all of the 3rd party domains (gstatic.com, google-tracker.com, etc) to give users some fine-grained control, without going crazy and listing every single 3rd party domain like the NoScript menu currently does.

The worse case scenario here of course is a web-page with 10 different possible permissions to toggle. In reality I suspect most websites would have a requested permissions list something like this:

  • JavaScript (1st Party)
  • JavaScript (3rd Party)
  • Web Fonts (3rd Party)
  • Media (3rd Party)

No First-Party Isolation

One downside of this fine-grained control is that NoScript's per-domain settings have no concept of first-party isolation. If I enable scripts from gstatic.com while visiting youtube.com, they are automatically enabled when visiting other google properties. This problem would quickly balloon if we go the route mentioned above in enabling a capability for all domains in a page. For instance, a user enabling 'JavaScript' on facebook.com would mean whitelisting Facebook's tracking domains everywhere.

My hunch here is that double-keying domain permissions with the first-party domain is a good idea so that enabling a 3rd party script necessary for some first-party does not automatically load them everywhere.

Typical-User and Power-User Segregation / Conflict

Regardless of what we end up doing here technically, we are going to end up with two different places to modify these new permissions: in the (i) dialog (or in about:preferences#privacy) and in the NoScript drop down panel. Our implementation will necessarily be simpler and less powerful than NoScript's, which means there will inevitably be a conflict between what our per-site permissions UI will say and what NoScript's UI will say, especially if a user modifies their preferences with both UIs.

comment:11 Changed 4 weeks ago by pili

#32433 is a duplicate

comment:12 in reply to:  10 Changed 11 days ago by antonela

hi pospeselr! thanks for your deep research on the technical side of this.

I have some questions:

Replying to pospeselr:

Without having delved too deeply into the prefs set by torbutton, I think we can safely assume that it will not be easy to modify Firefox to have per-tab scope for these globals, so for this ticket they can probably be safely ignored for now.

Does it mean that we are going to control just NoScript existing sources?

I think that 'Fetch' and 'JavaScript' could probably be joined together as a meta capability for the purposes of our UX, which would bring us down to 5:

  • JavaScript + Fetch
  • Web Fonts
  • Media
  • Plugins
  • WebGL

This seems a good list. I think that something we did well in the past was sorting not JS elements under the Active Content label. Advanced settings could allow granular customization, but for the control center doorhanger, I think the two items are enough.

However, if we're going the permissions route via the info (i) icon we will need to decide which domain that a custom setting would apply to. To 'just make a website work' and enable JavaScript for example, we would probably have to enable it for every domain used in a page, otherwise we end up with frustrated users.

Fair point. I think we will need to go deep on first-party domains vs third party domains allowance.

We could split up each of the NoScript capabilities to differentiate between the first-party domain (youtube.com) and all of the 3rd party domains (gstatic.com, google-tracker.com, etc) to give users some fine-grained control, without going crazy and listing every single 3rd party domain like the NoScript menu currently does.

The worse case scenario here of course is a web-page with 10 different possible permissions to toggle. In reality I suspect most websites would have a requested permissions list something like this:

  • JavaScript (1st Party)
  • JavaScript (3rd Party)
  • Web Fonts (3rd Party)
  • Media (3rd Party)

Here we go. Web Fonts and Media can live under active content. And, then we have two js sources. Works for me.

No First-Party Isolation

One downside of this fine-grained control is that NoScript's per-domain settings have no concept of first-party isolation. If I enable scripts from gstatic.com while visiting youtube.com, they are automatically enabled when visiting other google properties. This problem would quickly balloon if we go the route mentioned above in enabling a capability for all domains in a page. For instance, a user enabling 'JavaScript' on facebook.com would mean whitelisting Facebook's tracking domains everywhere.

My hunch here is that double-keying domain permissions with the first-party domain is a good idea so that enabling a 3rd party script necessary for some first-party does not automatically load them everywhere.

I like us to work on this feature. Maybe is something we can discuss with NS folks.

Typical-User and Power-User Segregation / Conflict

Regardless of what we end up doing here technically, we are going to end up with two different places to modify these new permissions: in the (i) dialog (or in about:preferences#privacy) and in the NoScript drop down panel. Our implementation will necessarily be simpler and less powerful than NoScript's, which means there will inevitably be a conflict between what our per-site permissions UI will say and what NoScript's UI will say, especially if a user modifies their preferences with both UIs.

You are right. SimplySecure has been working on redesigning NoScript with a special focus in per-site settings. My question here is: If we are going with NS settings to define our per-site, should we go minimal with our settings management and focus *especially* on 1. improving site breakage 2. collect real feedback on-site breakage (like Site not working link in Firefox) and let NS manage granular settings for advanced users in their UI?

comment:13 Changed 5 days ago by pospeselr

Cc: ma1 added

From what I understand having looked a bit into NoScript's source, we would need to make some not insignificant changes to how NoScript works (both in technical terms and probably from a design/UX perspective as well) if we were to build our proposed system on top of NoScript.

Alternatively, we can integrate these new things into Firefox directly and have it enabled/disabled via pref so that users who prefer the power and customization of NoScript to use that instead. This avoids the mismatch in UX and functionality between our systems and NoScript but obviously more work for us in the short-term and the long-term.

ma1: do you have any thoughts on any of this?

comment:14 Changed 4 days ago by pili

Keywords: TorBrowserTeam201912 added; TorBrowserTeam201911 removed

Moving tickets to December

Note: See TracTickets for help on using tickets.