Many ad and content blockers work (or will work in FF57) by modifying / injecting CSP that blocks sources of script, video, etc. they don't want to load. Although this works great for preventing their loading in the first place, it keeps content blockers from implementing any kind of "click-to-play" functionality. In order to unblock a source that wasn't blocked in the CSP, it has to reload the webpage and inject a new CSP header. This is a proposal for an experiment that would allow two things: 1) Allow a WebExtension to modify a site's currently enforced CSP policy -- for example, by adding youtube.com to video-src. 2) Allow a WebExtension to subscribe to more detailed information about what was blocked by CSP #1 is relatively straightforward, especially if there's some way to access the data structure that represents the current CSP as applied to a page #2 is a bit more tricky, but is needed to make things work. Currently when CSP blocks resource from loading, the only way to discover what was blocked is by intercepting the CSP reports that were sent out. However, this only contains the line of code where the offending piece of code was, and some tiny amount of information about it. To truly do this well, WebExtensions would need to know: a) what was blocked (as a DOM node), and b) where in the DOM it was supposed to be, and probably also c) the box information for the offending node, if it had been there (this is probably in the DOM node itself) This would allow them to insert a "click to play" box where the DOM node was going to be and replace it with the actual correct DOM if a user decides to do something.

#2 might be served by the CSP security violation events we're supposed to be sending (bug 1037335). Some of the CSP-next proposals have been for a scriptable interface to at least inspect the CSP, if not modify it on the fly. I'm fairly concerned about letting a page modify the policy, but I long ago filed a bug proposing that we let add-ons do so (can't find it at the moment).