task: update wiki [CSP clashes eg 1xCB setting & uM]

[theWalkingDuck]

Is it possible to block the Canvas API with FF prefs ?

[Atavic]

Canvas Blocker: https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.1-Extensions

[theWalkingDuck]

RFP is always on so I have to rely on it.
Unfortunately I can't use CanvasBlocker becouse I'm using uMatrix which is indispensable for me.

[theWalkingDuck]

CanvasBlocker like uMatrix, uses CSP-Headers to filter contents.
In cases where both extensions add there own CSP-Headers, only one extension works properly.
There is no way to aggregate those CSP headers. This is the downside of WebExtensions.
Modifications made by one extension can be overwritten by other extensions which is dumb by design.

[earthlng]

CSP in CanvasBlocker is only used for blocking data: URIs.
You can disable that part and still have the canvas blocking functionality.

[earthlng]

No, I'm talking about "Block data URL pages" under "Misc" - uncheck that and CB doesn't interfere with other CSP modifying extensions like uBO, uMatrix, NoScript etc

[theWalkingDuck]

CSP in CanvasBlocker is only used for blocking data: URIs.

That's weird.
I made some tests in the past and I found out that CanvasBlocker uses CSP Header if the document contains inline-scripts. That's why I came to the conclusion not to use it with uMatrix.

but I will run some tests and get back to you.

[theWalkingDuck]

@earthlng
let's take this simple inline script. uMatrix is set to block scripts and CanvasBlocker is set to default.

<script>
	document.write(window.navigator.userAgent);
</script>

result: CanvasBlocker interferes with uMatrix.

WebExtension                              Script
---------------------------------------------------
uMatrix                                   blocked
uMatrix(reload page)                      blocked
        ... clear cache ...
uMatrix + CanvasBlocker                   not blocked
uMatrix + CanvasBlocker(reload page)      blocked
        ... clear cache ...
uMatrix + CanvasBlocker                   not blocked
uMatrix + CanvasBlocker(reload page)      blocked
.
.

uMatrix 1.3.14
CanvasBlocker 0.5.3
FF 61.0.1 Linux

[earthlng]

and CanvasBlocker is set to default.

that's the problem. see #497 (comment)

[theWalkingDuck]

Indeed, that's the solution but correct me if I am wrong ... I thought that setting is for data URIs like

data:text/html,<script>document.write(window.navigator.userAgent);</script>

Why is that setting propagate to inline scripts ?
maybe I'm simply wrong.

[Atavic]

Is it possible to block the Canvas API with FF prefs ?

No, but More than one extension does it. And this raises issues that Mozilla folks will never solve IMHO.

In cases where both extensions add there own CSP-Headers, only one extension works properly.

Both extensions do work properly, but the outcome respects the 2nd extension (that overwrites the modification of the 1st one).

[earthlng]

Is it possible to block the Canvas API with FF prefs ?

contrary to what @Atavic claims, AFAIK no it's not possible to block Canvas API with FF prefs.
Maybe he can enlighten us with what those prefs are ... ?

Both extensions do work properly

well, if uBO for example suddenly allows inline javascript when it should actually block it, I wouldn't say "Both extensions do work properly" but maybe that's just me

I thought that setting is for data URIs like data:text/html,...

it is.

Why is that setting propagate to inline scripts ?

it's not. 1 extension uses CSP to block inline scripts and the other uses CSP to block data URIs - only 1 can win

[Atavic]

Edited the previous reply.

To me these are chained issues e.g. the last extension wins, while both extensions do work.

[theWalkingDuck]

That means CanvasBlocker adds the CSP header by default, without scanning the document for data URIs . That makes sense ... why wasting time..? I guess that was my blind spot.

I'm sure that many of those who are using CanvasBlocker are also using some sort of content filters like uMatrix. So using Block data URL pages as a default setting is really a bad idea.

Isn't that a case for the Wiki ?

[earthlng]

Well it's not that easy and I don't think you can explain the issue in 2 sentences. And a lot of people will have no idea which addons can interfere with each other. Do we really want to go there and risk getting tons of questions from people about which of their addons might interfere?
In some cases it also depends on addon settings. Even uBO + uMatrix interfere with each other. I use a customized version of uBO to make sure the 2 work nicely together but that only works with the way I use them

[earthlng]

disable then enable CB, and suddenly uM will win

AFAIK you need to disable and enable the one you want to win, not the other way around.
btw NoScript has some code to make sure it always wins which is nice but if other extensions start using similar code the issue will only get worse. It's not great atm to say the least and hopefully mozilla will do something about it but I won't hold my breath

[Atavic]

The order is

• install time
• updates change that order
• heavy webext (or webext that have issues like uBo while loading blocklists) are queued on the bottom of the chain.

So, if you have an ESR version with updates disabled the order is static.
If you update, the last updates webext goes on the bottom of the chain (overwriting previous modifications).
If uBo has issues while loading blacklists, it is available at a later time and is queued on bottom.

[earthlng]

I don't know if the order is fixed. AFAIK all extensions are started in parallel and whichever takes the longest to load will win. Unless of course they use some workaround to make sure they always win like NoScript does for example.

[Atavic]

Order varies with updates and is set by install time.

[earthlng]

try https://1337x.to/home/ - if you see the content, chances are inline script wasn't blocked.

If you block everything in uBO AND uMatrix then it's probably not an issue but I prefer to do all my JS blocking with uMatrix only for simplicity because I don't want to unblock everything twice.

Font blocking is better done with Request Control for example - that eliminates one of the potential CSP interferences that uBO can cause. But again, if you want to allow fonts on a bunch of sites it's getting a bit annoying to configure that with RC. Since I don't do that it's fine for me.

and the whole issue is not just affecting CSP. fe blocking cookies with uM or something else will also interfere with WebAPI Manager. I'm sure there are countless other problematic combinations as well

[theWalkingDuck]

Font blocking is better done with Request Control

Why don't you use uBlocks static filter ?

block third party font
*$font,third-party

block third party fonts / exclude aaa.com, bbb.com...etc
*$font,third-party,domain=~aaa.com|~bbb.com|~ccc.com

[earthlng]

Why don't you use uBlocks static filter ?

yeah that should work as well.
I said "Font blocking is better done with Request Control for example" :)

blocking fonts with RC also seems to block fonts embedded as data: URIs. Don't know if a uBO static filter also does that. I guess it depends what one prefers. Since I already used RC for other things as well I just went with that.

I'm interested in this Request Policy used to block fonts. I only allow about 7 or 8 site exceptions in uM - that should be easy to set up (and I don't mind the hassle of maintaining it)

It's probably not worth the hassle tbh. If you don't block 1st party (inline) scripts with uBO you might not run into too many problems. But uBO also supports csp-overwriting rules and if uBO "wins" against uM then it can lead to JS being allowed in some cases. That's why I use a customized version of uBO that makes sure the CSP is never touched by uBO. But since I most likely won't be able to get it signed and you can't use unsigned addons in FF Release there's no point in discussing my custom uBO any further.

[earthlng]

yes you can repeat the line. The rule only blocks third-party fonts though, IDK if that's what you want.

[earthlng]

if you want to block all fonts, 1st- + 3rd-party, except for a few chosen sites I'd add the important parameter and remove third-party:

*$font,important,domain=~bugzilla.mozilla.org|~developer.mozilla.org|~dxr.mozilla.org

[earthlng]

Do I wipe all those rules and replace with a single line as per your example?

just change no-remote-fonts: * true to false and remove the domain-specific no-remote-fonts rules

[uBlock-user]

$important is only required if there is an exception filter..

[uBlock-user]

in order to lessen the chances of rolling the dice with extensions and CSP

CSP is not used for blocking fonts with that switch, CSP in uBO is used for blocking inline-scripts and for CSP-esque filters.

That could be added to the uBO wiki

It's already there

If you want to allow third-party fonts for some specific sites you can add them by modifying the above filter:
*$font,third-party,domain=~example.com|~other.example.net|~different.example.org

[uBlock-user]

Sure, you can use $important regardless as it gives you impunity.

font blocking does not use CSP in both rules and filters?

Yes, they're blocked by types, font is a category of network request which uBO listens through webRequest API, just like script, xhr etc... Also whenever CSP is enforced the policy will be mentioned in the console, you can look it up in dev tools on a website where CSP is enforced.

do CSP-esque filters exist in subscribed lists? what on earth does a CSP-esque filter look like

Filters with $csp directive? uBO Filters uses it and so does Easylist.

[uBlock-user]

If you want to allow first-party and block third-party you will need to use filters, the switch blocks all or allows all only.

Dynamic Filtering takes precendence over Static filtering, you're using both, don't do that.

[uBlock-user]

*$font,important,domain=~~amiunique.org|~imgur.com|~gitlab.com
*$font,important,domain=~mozilla.org|~netmarketshare.com|~whotracks.me

Combine those two in one with

*$font,important,domain=~mozilla.org|~netmarketshare.com|~whotracks.me|~amiunique.org|~imgur.com|~gitlab.com and don't use dynamic filtering.

[uBlock-user]

but the idea was to get away from CSP. But since you said font blocking in rules is not handled by CSP, then I should be OK. Man I'm confused now.

Yes stick with rules, there's no CSP involved here.

[gwarser]

CSP is used to block inline (data:) fonts when no-remote-fonts switch is used:
gorhill/uBlock#1539

---

I checked this briefly two weeks ago and uMatrix uses CSP for blocking inline script and workers, uBO for no-scripting, inline scripts, (inline) fonts and network filters with $csp=... option.

[uBlock-user]

CSP is used to block inline (data:) fonts when no-remote-fonts switch

So why isn't the policy mentioned in the console like it does when you block inline-scripts ?

[earthlng]

*$font,important,domain=~amiunique.org|~imgur.com|~gitlab.com
*$font,important,domain=~mozilla.org|~netmarketshare.com|~whotracks.me

sorry I was wrong, you can't use multiple lines with filters like that. It only uses the last one ie the exceptions in the 1st rule won't work and fonts will be blocked on amiunique.org, imgur and gitlab.

since the big E didn't want to share his Request Policy info grin (probably so he doesn't have to babysit me)

1. Request Control not Request Policy
2. if you'd actually look you'd see that it's super simple. New Rule > Pattern=Any URL; Types=Font; Action=Block. For allows just define the match pattern for the domain, Types=Font again and Action=Whitelist.

@gwarser & @uBlock-user
there are other CSP-esque filters in some lists like blob.
IMHO it's a pretty bad idea to allow list managers to overwrite the CSP like that.

[gwarser]

Ouch, "console". Do you have any test page? font-src * is used, so any remote fonts are blocked only by WebRequest.

Wildcard, allows any URL except data: blob: filesystem: schemes.

---

Interesting. I see entry for inline scripts in console even if no script exists in page. Nothing for fonts.

---

Dirty profile - message is shown only when something is really blocked.

[earthlng]

I see entry for inline scripts in console even if no script exists in page

could be content scripts and/or possibly userscripts injected by extensions

[uBlock-user]

@earthlng I agree about the overwriting part, Easylist and some others like Fanboy has been pain in the ass ever since gorhill introduced CSP as those maintainers started writing policies without testing thoroughly, I have to use $badfilter to mitigate that shit.

[uBlock-user]

Ouch, "console". Do you have any test page? font-src * is used, so any remote fonts are blocked only by WebRequest.

Nevermind, I tested on https://getbootstrap.com/docs/3.3/css/ and it tried to load an inline-font and CSP was enforced as below

Actually everything that is loaded inline can only be blocked by CSP.

[uBlock-user]

@gwarser $inline-font hasn't been documented.

[earthlng]

@earthlng I agree about the overwriting part

I'm glad you agree. I think there should be a setting (maybe under Advanced) to disable these CSP-esque filters or they should just be ignored in 3rd-party lists and only allowed in "My Filters" and if necessary in uBlock's own lists (maintained by gorhill and you guys?).

If that's too much to ask or too hard to implement then maybe it would be better to at least let built-in policies (like script and/or font-blocking) take precedence over filter-based policies

Additionally to that it would also be nice to have another setting to completely disable CSP modifications, possibly with a strong warning not to use it unless someone understands exactly what that means. @gorhill mentioned in another issue here that he's willing to do it but just didn't have the time to do it yet.
I think the 2nd part is easy to implement with a simple check before running injectCSP() plus whatever is necessary to add a new setting in the UI.
Since you guys, @uBlock-user & @gwarser, are contributors to uBO (I believe, right?) maybe you could push this a bit?
Anyhow that's just my 2 cents

[uBlock-user]

I think there should be a setting (maybe under Advanced) to disable these CSP-esque filters or they should just be ignored in 3rd-party lists and only allowed in "My Filters" and if necessary in uBlock's own lists (maintained by gorhill and you guys?).

If you already have an well thought idea, then suggest it on the tracker. Make sure to detail it though.

maybe it would be better to at least let built-in policies (like script and/or font-blocking) take precedence over filter-based policies

It already does, all dynamic rules take precendence over static filters.

maybe you could push this a bit?

Can't push any further when he already said he would, it's on his mind along with numerous other tasks for this extension.