Skip to content
This repository has been archived by the owner on Jul 21, 2021. It is now read-only.

change scope & script handling #292

Closed
360up opened this issue Jul 14, 2015 · 1 comment
Closed

change scope & script handling #292

360up opened this issue Jul 14, 2015 · 1 comment

Comments

@360up
Copy link

360up commented Jul 14, 2015

There are 2 quite mayor drawbacks I wished uMatrix could handle differently:

a) Don't just prevent scopes from loading, but completely remove them (aka the RequestPolicy way)
Scopes blocked by uM are still showing up in other addons, e.g. items of blocked domains are listed in my adblocker regardless. This makes it very confusing to find out who is effectively blocking what. It'll be nice to see uM act like a true filter.

b) Don't just prevent scripts from running, but completely disable them (aka the NoScript way)
As previously discussed the browser is not aware scripts are prevented from running. This leads to noscript tags not being enforced which results in pages or parts thereof not displaying correctly (e.g. #260 )

The matrix configuration is simply ingenious and soo convenient. It's such a shame these 2 issues prevent me from replacing RequestPolicy and NoScript with uMatrix.

@gorhill
Copy link
Owner

gorhill commented Jul 22, 2015

Don't just prevent scopes from loading, but completely remove them (aka the RequestPolicy way)

"Scopes" are just a concept, uMatrix blocks network requests, not "scopes". uMatrix blocks network requests at HTTP observer's level, not at content policy level. This means that other extensions which work at content policy level will see all resources which go through shouldLoad.

Working at HTTP observer's level has many advantages: ability to handle redirects, ability to modify request/response headers, and since whole uMatrix core code is chrome process, this means no issue with CPOW overhead -- uMatrix performs excellently on e10s.

It's such a shame these 2 issues prevent me from replacing RequestPolicy and NoScript with uMatrix

I do not intend to move uMatrix's blocking to content side, so you will have to keep using these. uMatrix's contributed overhead as seen in about:performance is a small fraction[1] of the overhead introduced by these other add-ons, and for me efficiency is a primary concern, not a secondary one, and for this reason I do not intend to modify uMatrix for the sake of "who is effectively blocking what". uMatrix's logger will tell you what uMatrix is blocking.

[1] For example, about:performance (set at 1-sec poll) for cnn.com says user = low% (~10% max), system = 0%, cross-process = 0%. You will find 3-digit for same test with RequestPolicy and NoScript, each on their own, for user and cross-process, and single-digit for system.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants