Implement per-site security settings support
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.
Activity
Trac:
Parent Ticket: #25658 (moved)-
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.
- 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.
- 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.
Trac:
Username: 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.
Trac:
Username: torlove 
Trac:
Description: The native (without messing with the NoScript menu) per-site security settings support mentioned in proposal 101 () is still missing. This ticket is for implementing it.to
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.
Points: N/A to 10
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.
#32433 (moved) is a duplicate
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 Contentlabel. 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 workinglink in Firefox) and let NS manage granular settings for advanced users in their UI?-
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?
Trac:
Cc: tbb-team, dmr, isnaiter, arthuredelstein, mcs, brade, intrigeri to tbb-team, dmr, isnaiter, arthuredelstein, mcs, brade, intrigeri, ma1 -
Ok small update on my findings regarding using uMatrix rather than NoScript as our content blocking 'backend'.
uMatrix ( https://github.com/gorhill/uMatrix ) has a priority-based rules engine keyed on the first-party domain with various levels. IE rules can apply to anything, they can apply to the domain (cnn.com) or on a specific subdomain (badnews.cnn.com). Rules with a more specific filter override rules higher up the chain. IE if you block scripts globally (*) you can override this with an enable scripts rule for funstuff.com.
With this rules engine in place, we could implement per-site script blocking and avoid NoScript's 'rule apply globally' problem.
However, uMatrix buckets browser resources slightly differently than NoScript. For instance, with vanilla uMatrix to support blocking web fonts we would need to block css entirely. uMatrix also does not seem to support blocking WebGL at all. So while we get the rules-engine that we want, we do end up losing some security/privacy by not being able to block things by default as granularly (or at least in the same way) as the current version of Tor Browser.
I brought up this ticket with Arthur and tjr today about whether Mozilla would be interested/what the right approach would be with regards to uplifting whatever we end up building into Firefox so we don't have to carry those patches. One interesting suggestion to come out of that discussion was to build our own web-extension, since uMatrix and NoScript fundamentally can do (in the sense of capabilities/permissions) what we want, they just don't quite meet our needs on the UX side.
So, another approach could be to essentially rip out the content blocking/security bits from NoScript and uMatrix that we like, stick our own 3rd-party isolation respecting rules on top all within the web extension. Then, the only patches we would need to carry in Tor Browser itself would be much more light weight and only need to touch whatever systems the UX we land finalize on would need to touch (assuming it can't all be done in an extension).
I think this approach has the advantage of potentially being a bit faster to spin up and implement (since we could theoretically start with a NoScript or uMatrix fork), though it does run counter to our long-term goals of integrating our existing extension's (torbutton, tor-launcher) functionality into Tor Browser. That said I don't actually have any experience developing web extensions so I don't know what the difference is in developer productivity over just writing modules in /browser/modules.
I've received a private email by pospeselr and latest update to this ticket about at the same time, and realized I've missed some history and context in the past weeks
He had written:
if I enable scripts while visiting foo.com as the first party, all the child scripts would also be enabled, but only when they are in the foo.com context. A subsequent visit to baz.com should not have scripts enabled for it or any of its included 3rd parties.
This looks much like the "Cascade top document permissions to subresources" settings in NoScript classic, and it's worth implementing indeed.
I could make it even more granular by turning it into a "cascade" meta-capability (like "webgl", "fetch", "ping"...) which can be configured per-preset (e.g. for TRUSTED) or customized per-site in CUSTOM.
How does this sound?
-
So our current UX design calls for a similar flow to how webcam or location permissions work, but applied to 1st party/top document JS, 3rd party/subresource JS, and a nebulous 'Active Content' category which would include everything else: webgl, object, media, and fonts (we may split these up later).
For the backend, I think that we would need a flag for each meta-capability that allows it to cascade to subresources. Or instead of each meta-capability being a flag that indicates enabled or disabled, it becomes an enum: enabled, disabled, and enabled+cascade. This way on a per-site basis we could allow top level JS and subresource JS, but disallow subresource webgl/fonts/etc for example (rather than having cascading happen everywhere as with a global setting, or for everything as with an additional meta-capability).
We also will need some sort of mechanism for Tor Browser to get a notification, or have a callback called, etc, whenever NoScript blocks a resource via a meta-capability so that we can potentially throw up UI to allow the user to enable the blocked capability for that site.
And finally, we would need a way to send NoScript new site settings once users have interacted with the above UI. We could just send over an entire settings struct like we already do on startup and when the security slider level changes, but I am concerned that could get laggy as the number of per-site settings grows (but we can always worry about that later if it becomes a problem).
What do you think?
-
Replying to pospeselr:
For the backend, I think that we would need a flag for each meta-capability that allows it to cascade to subresources.
I like this option over the enum because it would allow even more granularity (not necessarily for the Tor Browser, if it doesn't need it) to cascade not just the permission but also the restriction on each capability (at this moment, IIRC, the Tor Browser enables NoScript's "cascade restrictions" option globally).
We also will need some sort of mechanism for Tor Browser to get a notification, or have a callback called, etc, whenever NoScript blocks a resource via a meta-capability so that we can potentially throw up UI to allow the user to enable the blocked capability for that site.
It can be done through messaging, I think. But do you need the blocked resource/message ration be 1/1? Could it be just a coarse-grained asynchronous message which coalesces a certain number of blocking events, e.g. at DOM Completion and then with a 500ms granularity, if any occurs (providing details about each blocked subresource, of course, but wholesale)?
And finally, we would need a way to send NoScript new site settings once users have interacted with the above UI. We could just send over an entire settings struct like we already do on startup and when the security slider level changes, but I am concerned that could get laggy as the number of per-site settings grows (but we can always worry about that later if it becomes a problem).
I don't believe that would have any perceivable performance impact, but a finer-grained per-site setup message can be easily arranged, yes.
-
Replying to ma1:
But do you need the blocked resource/message ration be 1/1? Could it be just a coarse-grained >asynchronous message which coalesces a certain number of blocking events, e.g. at DOM Completion and then with a 500ms granularity, if any occurs (providing details about each blocked subresource, of course, but wholesale)?
I think this sounds reasonable.
Replying to ma1:
I don't believe that would have any perceivable performance impact, but a finer-grained per-site setup message can be easily arranged, yes. I'll defer to your judgement here. If you think sending over the entire settings object is unlikely to cause noticeable perf problems then let's just go with whatever approach is easiest to do correctly. We can come back to it later if it poses an issue in the future.
Hi ma1, just FYI, we're delaying any Tor Browser work on this until June. We can still help with testing NoScript patches or providing feedback if that will be helpful until then. I'm not sure of the timeframe you planned for implementing the necessary changes in NoScript.
Trac:
Keywords: TorBrowserTeam202002 deleted, TorBrowserTeam202006 added-
Replying to sysrqb:
Hi ma1, just FYI, we're delaying any Tor Browser work on this until June. We can still help with testing NoScript patches or providing feedback if that will be helpful until then. I'm not sure of the timeframe you planned for implementing the necessary changes in NoScript.
Thank you very much for the update. I'm confident to have my side ready well before June. I'll ping here as soon as there's something to check.
mentioned in issue #30613 (closed)
mentioned in issue #30730 (moved)
mentioned in issue #32433 (moved)
mentioned in issue #33000 (moved)
moved to tpo/applications/tor-browser#30570
