Images, videos opened directly in a tab are bypassing respective block rules

[theWalkingDuck]

@gorhill
In uMatrix 1.3.15b2 local scripts are now blocked by injecting a CSP directive through a <meta http-equiv...> in the DOM at document start. --Thank you !

Is it possible to apply the same method to STOP the browser from rendering blocked image and media files which are downloaded as main_frame ?

I know it's not a cross browser solution but that would be a great enhancement for those of us who are using uMatrix with Firefox and Tor-browser.

[gorhill]

Is it possible to apply the same method to STOP the browser from rendering blocked image and media files which are downloaded as main_frame ?

Please provide steps to reproduce -- it's not clear to me what you are asking. Exact steps to reproduce make everything clear.

[theWalkingDuck]

let's say we have these rules:

* * image block
* * media block

and these requests:

• image file: https://avatars0.githubusercontent.com/u/585534
• media file: http://dl3.webmfiles.org/big-buck-bunny_trailer.webm

In this case the browser creates the DOM and injects the img, video, audio ... in it.
The idea is to use the same CSP directive to stop Firefox from rendering those blocked elements.

[uBlock-user]

* * media block works as expected(on Chromium) and the video is never loaded on direct access. Same cannot be said for the image though. On Firefox, both load regardless.

Fyi, it's * * image block

[gorhill]

In this case the browser creates the DOM and injects the img, video, audio ... in it.

DOM-based CSP has nothing to do with this issue -- I prefer that issues are opened as their own thing, then I will decide whether it can be fixed, whether I want to fix it, and if so what is the fix -- which in the current case "using CSP in http meta header" is completely not the way to go.

[uBlock-user]

Actually when you make direct connection to that image and media, both of them are loaded as document, which is why both of those rules have no effect, to block that document, you will have to block the domain and no direct connection will be established.

Look at the logger if you want to see for yourself.

[uBlock-user]

same thing happens when making direct connection to css, script and other type(manifest.json for example), they all get loaded succesfully.

[gorhill]

same thing happens when making direct connection to css, script

These are opened as text file, so I won't be putting in code to block mere text resources.

As for opening images/media as top document, I have this fixed locally, but I am unsure that there is really a point for blocking root documents because of generic block rules:

[uBlock-user]

These are opened as text file

Yes I know, but a successful connection is still made regardless that was my point.

[gorhill]

a successful connection is still made regardless that was my point.

When downloading a root document, a successful connection is always made to whatever domain is not explicitly blacklisted -- why is this suddenly becoming an issue at all?

[uBlock-user]

why is this suddenly becoming an issue at all?

Not an issue, but rather a matter of principle, when a user makes use of a rule such as * * script block he expects all connections to javascript sources be blocked(direct or indirect regardless) unless he decides to whitelist some specifically, which is the not the case when direct connections to those javascript sources are still possible despite having * * script block in place.

I can only speak for myself, so this is not sudden change or an argument and neither it's becoming any issue, but rather always a philosophy of mine, if I'm going to use default-deny rules, then default-deny should be seen and experienced everywhere and not limited to when resources being fetched first or third-party. Direct connection has always been possible since the beggining and I didn't brought it up because I thought it was by-design. You may be right technically, but my argument lies in the principle. Again it's not becoming any issue, but rather a justifiable argument on my end, for my beliefs regarding the direct connection issue.

[theWalkingDuck]

why is this suddenly becoming an issue at all?

See it as a backdoor to bypass the content filter.

Even if no html document was downloaded,

• the browser creates the DOM out of nothing,
• creats an img, video or audio tag, injects that junk file in it
• and renders a self created document

But that same image or video content embeded in html document, has no chance to be downloaded.

If a backdoor is used to download a junk, then the only solution left is to stop the browser from excuting it.

[gorhill]

See it as a backdoor to bypass the content filter.

My comment was in reference of to the blocking of plain text resources -- which is an absurd proposition.

My reservation here is because I worry this will be unclear that one of the block rules for specific type is causing the blocking of whole document -- but I do agree with you, hence why I labeled as "bug". Note that the fix requires uMatrix to still perform a connection in order to get access to the Content-Type header.