You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 21, 2021. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: