[CSP] Policy direction for bookmarklets/extensions augmenting page-level CSP?

Hi there,

Have read through the CSP v1.1 final draft, I’d like to clarify the medium-term direction for bookmarklets and browser extensions, and whether they can augment the page-level CSP policy.

I understand that user-agent CSP implementation for bookmarklets/extensions is outside the purview of this policy. It merits one sentence in the draft (I’ve read the associated comms..). 

However, previous comments from Mike West [1] and Daniel Veditz [2] talk about extensions being able to override/augment a page’s CSP policy. Mike talked about creating “an API that would allow extensions to add sources to the page's policy …. some sort of delegation mechanism similar to that has been proposed as an addition to the DOM feature-detection API that's currently experimentally specified in CSP 1.1.” Daniel said something similar.

Is this something that is on the horizon, and could make it into an upcoming specification?

From the description, I imagined there being a top-level ‘CSP’ object in a browser’s Javascript environment, representing the page-level CSP policy. A bookmarklet/extension running in a isolated world would have appropriate permissions to use the CSP object to augment the page-level policy with additional trusted (https?) origins. JS running as part of the original page load might not.

My concern with the current v1.1 draft is that there is nothing explicitly formalised that offers user-installed bookmarklets or extensions this augmentation capability. As you are no doubt aware, recent Firefox and Chrome CSP implementations have broken several browser extensions from running on sites with CSP. The extensions break when they inject scripts/iframes/styles into the site page, and become subject to the page-level CSP. Even through the injected scripts are from https origins, the page CSP does not whitelist the origin, so the script cannot be loaded.

Bug reports in Firefox [3] and Chrome [4] bug trackers talk about this being a bug in current CSP implementations, and that bookmarklets and extensions from ‘isolated worlds’ should not be subject to a page author’s CSP.

However, I wonder whether bookmarklets and extension _should_ be subject to a CSP: one that they define, and that augments the one supplied at the page-level. One that is defined in the spec as a ‘CSP’ Javascript core object.

The risk of not making this explicit in the specification is that there is no technical expectation that user-installed bookmarklets/extensions should not be subject to the page-level CSP - but can be subject to one defined themselves. So future CSP implementations may follow the pattern of being too stringent with applying the page-level CSP on everything, including extensions (because page-level CSP is explicitly defined in the spec), and then having to relax the CSP policy as a bug-fix or after-thought, if at all.

For reference, I’ve put a bunch of relevant links below. As CSP adoption increases, problems with bookmarklets and extensions are growing. As of today July 11 2014, I found various ‘big name’ bms/exts were broken on github.com, for both FF 30 and Chrome 35: Pinterest, Polyvore, Amazon Wishlist and Google Translate. Ironically, Pinterest.com has a CSP that breaks the Polyvore bookmarklet! [5]

Kind regards,

Greg


Augmenting page-level CSP
————————————

[1] Mike West - 25 Sep 2012
http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/0086.html
"Rather than disabling CSP for a protected resource, a less insecure idea
might be to create an API that would allow extensions to add sources to the
page's policy (of course, in a way that wouldn't show up in violation
reports). I believe some sort of delegation mechanism similar to that has
been proposed as an addition to the DOM feature-detection API that's
currently experimentally specified in CSP 1.1."

[2] Daniel Veditz - 01 Oct 2013
http://lists.w3.org/Archives/Public/public-webappsec/2013Oct/0013.html
“My eventual plan for Firefox is to let an add-on specify a CSP
whitelist. This lets the add-ons do what the user presumably want them
to do but by default means add-ons will respect CSP. The explicit steps
to override CSP can then be reviewed and won't accidentally introduce
issues. Although perhaps not as wide open as the spec implies I think
that fits with the spirit of the spec ("should not", not "must not”).”


Current bugs and broken sites
———————————————

[3]
FF: ‘Bookmarklets affected by CSP’
https://bugzilla.mozilla.org/show_bug.cgi?id=866522
FF: ‘CSP blocks content injected by add-ons’
https://bugzilla.mozilla.org/show_bug.cgi?id=615708'
FF: Discussion about bookmarklets not working:
https://groups.google.com/forum/#!topic/mozilla.dev.security/0-hQkQ3kbME

[4]
Chrome: ‘Bookmarklets should bypass pages' policies.’
https://code.google.com/p/chromium/issues/detail?id=233903
Chrome: ‘All CSP directives should be bypassed by isolated worlds’
https://code.google.com/p/chromium/issues/detail?id=390329
Chrome: ‘Strict Content Security Policy breaks Iframes inserted by Extensions.’
https://code.google.com/p/chromium/issues/detail?id=386678
Chrome: ‘Only one extension can bypass page CSP rules at once’
https://code.google.com/p/chromium/issues/detail?id=391128

Github adds CSP, and acknowledges breaking bookmarklets:
https://github.com/blog/1477-content-security-policy

[5] Polyvore doesn’t work on Pinterest:
http://blog.polyvore.com/2014/07/clipping-from-pinterest.html