Tampermonkey: Scripts fail on FF because of CSP errors

[alexolog]

Scripts fail to operate and console shows CSP errors

Expected Behavior

Scripts work.

Actual Behavior

Scripts fail.

Specifications

• Firefox developer edition 77.0b9 (64-bit) [Firefox Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0]
• TM beta v4.10.6112
• OS: Windows 10 1903

Script

(Please give an example of the script if applicable.)

https://greasyfork.org/en/scripts/401432-google-image-search-show-image-dimensions
https://greasyfork.org/en/scripts/398189-google-image-direct-view

Test on: https://www.google.com/search?tbm=isch&q=cat&tbs=imgo:1

[alexolog]

Some of the scripts I tested run OK on Greasemonkey or Violentmonkey

[alexolog]

The same as #700 ?

[derjanb]

Can you please check whether this works with the experimental options "Add Tampermonkey to the site's content CSP" enabled. Thanks.

[alexolog]

1) Doesn't help
2) Breaks the page ( https://www.google.com/search?tbm=isch&q=cat&tbs=imgo:1 )

[derjanb]

I've published Tampermonkey BETA 4.11.6113 with a new option at the "Modify existing content security policy (CSP) headers" setting which is called "Remove entirely (possibly unsecure)" to workaround the issue.
The default value is still "Yes", which should relax the CSP to make Tampermonkey work, but since FF 77 setting a new CSP has no effect anymore, while removing works fine.
This modification is done only if scripts are supposed to run, so there is no need to disable CSP via security.csp.enable in general anymore.

You can get the beta version from here: https://www.tampermonkey.net/index.php?browser=firefox

Note: "Config Mode" needs to be set to "Advanced" first.

[Bl4Cc4t]

This is a neat feature! However, I have trouble setting this option, it does not save the selected option for some reason.

[derjanb]

Just to be sure, you pressed the save button at the bottom of the section? 🥺

[Bl4Cc4t]

Oh, I did completely overlook those, sorry about that.
The experimental section does not have that, so I thought the other sections automatically save changes too :V

Although with it actually being set, it does not seem to work on twitter.com for me...
The script gets denied after 1-2 refreshs (doing a hard refresh lets it work again)

[derjanb]

Your twitter issue is most likely caused by #773

[Bl4Cc4t]

Yeah, disabling dom.caches.enabled fixes it.

I guess I have to stick with disabling security.csp.enable for now.
Thank you nonetheless!

[alexolog]

Works on google.com for me.

Still, questions remain:

but since FF 77 setting a new CSP has no effect anymore, while removing works fine.

According to the blog, "we now properly merge the CSP headers when two add-ons modify them via webRequest. This is especially important for content blockers leveraging the CSP to block resources such as scripts and images."

If it is not working correctly, maybe need to let Mozilla know?

[vaporwave9]

This modification is done only if scripts are supposed to run, so there is no need to disable CSP via security.csp.enable in general anymore.

Yes this worked well on Twitter for me after hitting "Save" in Advanced > Security.

However, can you implement a CSP-removal-whitelist instead? It would be neat to have a seperate TextArea field to define otherwise broken sites like *twitter.com/* and thus preventing the settings from being applied globally.

Disabling CSP entirely or removing it on every site is not a good idea and the existing TextArea fields have a different purpose than controlling CSP-removal. Thanks anyway, I have a feeling you'll solve the problem eventually! (How does Violentmonkey handle CSP anyway?)

If it is not working correctly, maybe need to let Mozilla know?

It could take years, or worse, they break it further.

[alexolog]

Some of the scripts I tested seem to work with GreaseMonkey without issues:
https://greasyfork.org/en/scripts/401432-google-image-search-show-image-dimensions
https://greasyfork.org/en/scripts/398802-google-images-direct-links-2
https://greasyfork.org/en/scripts/398189-google-image-direct-view

Several comments in #700 indicate that GM does not have this problem:
https://github.com/Tampermonkey/tampermonkey/issues/700#issuecomment-520220898
https://github.com/Tampermonkey/tampermonkey/issues/700#issuecomment-539395990

Since GM's latest release was a year ago and was not affected by the CSP change, it must be doing something differently. Maybe @derjanb can snoop in the code (MIT license) to compare.

[alexolog]

Also, please comment in the following:
https://bugzilla.mozilla.org/show_bug.cgi?id=1177968
https://bugzilla.mozilla.org/show_bug.cgi?id=1643405

[derjanb]

Also, please comment in the following:
https://bugzilla.mozilla.org/show_bug.cgi?id=1643405

Done.

Maybe @derjanb can snoop in the code (MIT license) to compare.

They execute userscripts within the extension's content script. This has the downside that the userscripts do have the same powers like the extension itself. I decided against this 8 or 9 years ago.

[alexolog]

Thanks!

Out of curiosity, what's wrong with having the userscripts have the same powers as TM? We are assuming the user knows what they are doing, no?

I just want scripts to work seamlessly with minimal side effects, and I really prefer to use TM over GM or VM on FF.

[Owyn]

"Remove entirely (possibly unsecure)"

I wish you could reach out to FF devs to say they're just making it worse for end users (if it's working as intended)...

This modification is done only if scripts are supposed to run, so there is no need to disable CSP via security.csp.enable in general anymore.

Many scripts I use run on all pages and disable themselves when not needed, so it'd just disable CSP on 100% of sites and pages entirely :-(

[alexolog]

I wish you could reach out to FF devs to say they're just making it worse for end users (if it's working as intended)...

My suspicion is that the FF devs will just point to GM and claim that TM is just doing it wrong.

[derjanb]

Should be fixed at 4.11.6114

[Bl4Cc4t]

Thank you so much, this is very appreciated!

[ran-sama]

Thanks and donated for this as bug bounty.
Have some dark drink of choice on me!

[jerone]

Beta 4.11.6114 fixed the similar issue for me with userscripts run on GitHub.

[LurkerHub]

Still having the issue with 6114:

Security Error: Content at https://elliquiy.com/forums/index.php?action=profile;area=showposts;sa=topics;u=41454 may not load data from blob:moz-extension://eb61ac3e-ed19-4b96-93b1-d906591e63a5/a40e6b10-48d2-4b30-81c4-4bc3f2ee2c84.

[LurkerHub]

Also scripts break on Github because of CSP

[derjanb]

Still having the issue with 6114:

Security Error: Content at https://elliquiy.com/forums/index.php?action=profile;area=showposts;sa=topics;u=41454 may not load data from blob:moz-extension://eb61ac3e-ed19-4b96-93b1-d906591e63a5/a40e6b10-48d2-4b30-81c4-4bc3f2ee2c84.

This is handled in #963

Also scripts break on Github because of CSP

Also in "normal" injection mode?

[LurkerHub]

"Default" seems to work

[derjanb]

Out of curiosity, what's wrong with having the userscripts have the same powers as TM? We are assuming the user knows what they are doing, no?

@alexolog
https://bugzilla.mozilla.org/show_bug.cgi?id=1594234 -> "Developers can no longer use CSP directives that enable remotely hosted code (code that is not bundled with the extension). Manifests that include such directives will error at parse time."
https://blog.mozilla.org/addons/2019/12/12/test-the-new-csp-for-content-scripts/ -> "Please do not loosen the CSP to allow remote code, as we are working on upcoming changes to disallow remote scripts."

[alexolog]

Aren't we talking about locally hosted user scripts?

[alexolog]

FF dev updated itself to 78.0b6 and now the problem is back with a vengeance. None of my scripts run on Google unless I disable CSP globally.

I am running the 4.11.6114 beta

Example page:
https://www.google.com/search?tbm=isch&q=cat&tbs=imgo:1

Sample scripts that fail to run:

• https://greasyfork.org/scripts/401432-google-image-search-show-image-dimensions/code/Google%20Image%20Search%20-%20Show%20Image%20Dimensions.user.js
• https://greasyfork.org/scripts/19210-google-direct-links-for-pages-and-images/code/Google:%20Direct%20Links%20for%20Pages%20and%20Images.user.js
• https://greasyfork.org/scripts/404103-google-image-search-show-image-dimensions/code/%11Google%20Image%20Search%20%7C%20Show%20image%20dimensions%11.user.js
• https://greasyfork.org/scripts/398802-google-images-direct-links-2/code/Google%20Images%20direct%20links%202.user.js
• https://greasyfork.org/scripts/398189-google-image-direct-view/code/Google%20Image%20Direct%20View.user.js

Errors in the log:

Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified

GreaseMonkey works.

[alexolog]

Any ideas?

[derjanb]

FF dev updated itself to 78.0b6 and now the problem is back with a vengeance. None of my scripts run on Google unless I disable CSP globally.

Hmm, this works fine here with both FF beta 78.0b6 and FF beta 78.0. Tested with an own script and "Google Image Search - Show Image Dimensions" at your example page. I've also created a new profile to make sure no FF setting was modified. 🤔 Do you have other extensions installed? I've tested with uBlock Origin and uMatrix and in both cases it still worked.

Note: I've also created a issue at Mozilla's bug tracker about the issue, but it was set to duplicate of another issue. Nevertheless, feel free to star or comment.
https://bugzilla.mozilla.org/show_bug.cgi?id=1645614

[alexolog]

I think I found the culprit, and it was another extension: https://github.com/Sainan/Universal-Bypass/issues/1342
I disabled it for now. Too bad though, since it is a useful one.

Your bug report was marked as a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1591983
Regardless, I voted for both (although it seems I can only give a single vote to each so it does not amount to much)

With that extension disabled, scripts appear to work on Google.com without the need to globally disable CSP.

Interestingly, setting "Modify existing content security policy (CSP) headers" to "yes" still works. Is the "disable" option only used for "instant" mode?

[alexolog]

Could you please comment on https://github.com/Sainan/Universal-Bypass/issues/1342 ?
It looks like an incompatibility between the extensions