[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, tbb-9.5,                    |  Actual Points:
  TorBrowserTeam202001                           |
Parent ID:  #25658                               |         Points:  10
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor9
-------------------------------------------------+-------------------------

Comment (by ma1):

 Replying to [comment:18 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.

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