[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



#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 pospeselr):

 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?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30570#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs