Canvasblocker: Block Data URL Pages interfering with uBlock Origin

[ghost]

I use uBlock Origin as a JS blocker from the advanced users' matrix. With today's updates (both a&b), the block data URL pages setting is preventing uBO from blocking inline-scripts.

Currently using latest releases: FF61.01 on Win10x64, uBO 1.16.14, and CB 0.5.1.1b.
Tried fresh profile with only uBO and CB installed. Only the uBO script blocking enabled/changed and got the same result. Disabling Block Data URL Pages enables uBO to correctly block inline-scripts.

Edit: This only seems to be the case when CB is installed/loaded after uBO.

[kkapsner]

I'm not able to reproduce your problem. Please post your exact changes to uBO.
Where do you see the posted test matrix?

[ghost]

From a new FF profile, I installed uBO and then CB. In uBO settings, I enabled the advanced user mode (I am an advanced user). After that, click on the browser action of uBO and it'll show the matrix in addition to the usual # of blocked items info. Block scripts by choosing the red box in the left column (for global setting) as shown in the picture. Saving the config to preserve settings between sessions (the lock icon) is optional. That's all.

Now, all sites (except privileged ones like AMO) have JS disabled until you allow them from the same matrix on a per-site basis. However, with the latest version of CB, inline scripts are not being blocked.

[kkapsner]

Ah... I was trying the cosmetic script filters (https://github.com/gorhill/uBlock/wiki/Inline-script-tag-filtering).

If you install the addons in other order (CB first and the uBO) the blocking of inline-scripts work, but the blocking of data-URL pages does not work.

Let's see if I sort this out.

[kkapsner]

It seems that it's a Firefox bug...

[kkapsner]

Same interference between NoScript and uBO (and CB).

[kkapsner]

This is quite bad and I do not know how to fix this.
But first I have to compress my findings and file a bug for Firefox.

[ghost]

The installation order mattering suggests that both are trying to listen to the same event with the newest one overriding the first. As a last resort, one extension may need to inherit functionality of the other.

[kkapsner]

I found the piece of code in the WebExtension that causes the problem.

And yes, you are right. They both listen to the same event. But the
WebExtensions have no clue that they are overwriting the actions of
others as they do not see them. The overwriting is implicit and hidden
from the extension.

[kkapsner]

The funny thing is that it works if the page itself contains CSP-headers.

PS: here the code with the problem: https://dxr.mozilla.org/mozilla-central/source/toolkit/modules/addons/WebRequest.jsm#101

[kkapsner]

Bug filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1477696

[crssi]

Voted at bugzilla. At least I can do.

Thank you for your hard work to make our life on Internet less miserable.
Cheers

[kkapsner]

You're welcome. One thing that I noticed is that if you browse a page that serves CSP-headers by itself (which every major page should do) the addons do not interfere...

[crssi]

What if you inject some general CSP on the pages without CSP?
Is this plausible for meanwhile workaround?
Just brainstorming here, maybe what I say/ask is total BS. ;)

[kkapsner]

It's not BS, but the header modification is the problem. Not the CSP specific.
Therefore I cannot inject something general because it's also just a header modification.

[Thorin-Oakenpants]

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1417249

from the lengthy issue at https://github.com/ghacksuserjs/ghacks-user.js/issues/265

earthlng said

Looks like they're not gonna fix this and instead will just change the documentation:
https://bugzilla.mozilla.org/show_bug.cgi?id=1421725#c1

That means it will always be like rolling a dice, and every time you start FF you'll roll the dice again. Expect the unexpected if, for example, NoScript, uBlock Origin (in advanced mode!) and uMatrix are all used together because afaik they all work by changing the CSP header.

Roll the dice and hope for the best, I guess :man_facepalming:

earthlng said

It really sucks that they refuse to fix this, especially since their only argument is performance!

@fmarier could you maybe take this up internally to get fixed, please? I'd imagine you agree that sacrificing extension inter-compatibility, functionality and consistency for a slight performance improvement is not ideal, to say the least. I'm pretty sure most users with 2 or more potentially interfering extensions would be more than happy to sacrifice a little bit of a performance for the guarantee that their extensions work nicely together. Atm it's totally unreliable and unpredictable and you might get one outcome once and a completely different outcome the next time (like after an update for one extension or after a restart). Even the guys in charge at mozilla say it's like rolling a dice! ...

• "If multiple listeners try to change the same header, one of them will succeed, but there's no guarantee which."
• "its rolling the dice to see if you'll win."
• "The entire header change API is always a game of rolling dice."

It's a sad state of affairs for a privacy-respecting browser like FF when it makes using privacy and security enhancing extension like NoScript, uBlock Origin, uMatrix, etc "a game of rolling dice" IMHO

Anyone want a game a craps?

[kkapsner]

Thanks for the cross-references. I did not find them.

I suggested a solution - let's see how they react to it.

[earthlng]

on a related note, it would be better performance-wise to only add the listener for browser.webRequest.onHeadersReceived if (settings.blockDataURLs).
Like instead of init() once, add or remove the listener when the setting changes

[kkapsner]

Could do that. It will change the order of the listeners on onHeadersReceived from installation/activation order, but this is kind of random anyways. (And NoScript tries to be last anyways with the next version.)

I actually never thought much about performance here...

[Thorin-Oakenpants]

You can probably resolve 1477696 (kkapsner's bugzilla) as worksforme or as a duplicate of 1462989 which landed in 77

[kkapsner]

Thanks for the ping. The fix seems to work in Firefox 78 - Firefox 77 is kind of broken at the moment...

So I can finally close this issue!

[kkapsner]

Restarting fixed 77...

[Thorin-Oakenpants]

pro tip .. on bugzilla you can just type bug number and it hyperlinks (and also comment number and that hyperlinks that comment in the same bugzilla). The nice thing about bug number hyperlinks is that mousing over them gives you some details