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