[tor-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 antonela):

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

 I have some questions:

 Replying to [comment:10 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. [https://simplysecure.org/blog/noscript-case-study,
 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?

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