http://en.wikipedia.org/wiki/Content_Security_Policy

GitHub forbids scripts that don't originate from their CDN (assets-cdn.github.com, collector-cdn.github.com). Consequently, Firefox will refuse to execute inline scripts.

It certainly would be nice if Greasemonkey scripts weren't affected by CSP restrictions.

What's the issue with just executing the code or using @require for external scripts?

See https://greasyfork.org/forum/discussion/353/doesn-t-work-because-of-content-security-policy

See also #1803

AFAIK there's no way to bypass CSP for <script> tags that happened to come from a user script, without allowing them from anywhere (which is bad). So this is probably just WAI.

"AFAIK there's no way to bypass CSP for"

Your comment was cut off. Is it not possible to allow greasemonkey scripts to bypass CSP ?
@grant CSP

I hope GreaseMonkey can do something about this. Bookmarklets and addon's shouldn't be affected by CSP

Firefox does have about:config setting to turn off CSP completely but that is a security risk and userscript author's shouldn't be asking users to change browser settings for script to run correctly.

Can't GreaseMonkey addon edit response header to include GreaseMonkey scripts?

A <script> tag is a <script> tag. Can't enable one without enabling them all. I don't think I'm interested in building features with the sole purpose of defeating intentional security measures.

Aha .. don't try to type the word "script" surrounded by angle brackets when trying to refer to that kind of HTML tag. Anyway:

A script tag in the page is a script tag in the page. I'd be surprised if there was a way to force one of them to run, in violation of the CSP rules set, without forcing all of them to run. I'm also generally not interested in building features whose sole purpose is to defeat intentional/useful security mechanisms.

pdf.js apparently just turns off CSP. Unfortunately, I'm not sure how we'd do this for a script since we don't have access to the request object during injection as far as I can tell. Maybe this could be done extension-wide? If we did, would that kill CSP everywhere (or at least on any page with a script injected into it)?

This issue was added to "pony". What does that mean?

Getting to topic at hand, yes this requires changes made by extension not script. If CSP is turned off completely, then it would be defeating intentional security mechanisms against things like XSS. But greasemonkey scripts, like bookmarklets, are mostly used to make intentional changes. The security risk comes from installing the greasemonkey script, CSP doesn't help in that regard for greasemonkey.

Can't api be added "@grant CSP-inline" which would alter response header add "inline" to CSP?

The biggest issue is that greasemonkey disabled unsafeWindow and so injecting scripts into site was easiest alternative but now that's becoming a problem as sites use CSP.

I do not believe there is a way to securely disable CSP only for certain scripts. Look at the example in the original report. There is no request nor response to set a header on.

And to repeat: I do not intend to create new features whose sole purpose is to defeat intentional security measures.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=866522 .