[tbb-bugs] #30570 [Applications/Tor Browser]: Implement per-site security settings support

[Tor Bug Tracker & Wiki]

#30570: Implement per-site security settings support
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:
                                                 |  pospeselr
     Type:  enhancement                          |         Status:
                                                 |  assigned
 Priority:  High                                 |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  ux-team, TorBrowserTeam201911,       |  Actual Points:
  tbb-9.5                                        |
Parent ID:  #25658                               |         Points:  10
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor9
-------------------------------------------------+-------------------------

Comment (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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30570#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online