It seems that the JS implementation of CSP causes a major performance drawback for Firefox OS [1]. Also, I think we can leverage the URI parser and eliminate duplicate code necessary for parsing wildcards like '*' for CSP. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=924337

Here's a small patch that just implements the certified apps csp on the c++ side. Overall it's killing csp time to less than 10ms for all gaia apps.

Comment on attachment 815664 [details] [diff] [review] fast path for certified apps Sid, would you be horrified if we did that while we wait for the full c++ rewrite?

Fabrice: this hardcoding makes my skin crawl, but if we limit it to certified apps I think it would be tolerable given the perf win. Does the fast-path logic cause any perf hit for non-app loads?

(In reply to Sid Stamm [:geekboy or :sstamm] from comment #3) > Fabrice: this hardcoding makes my skin crawl, but if we limit it to > certified apps I think it would be tolerable given the perf win. Does the > fast-path logic cause any perf hit for non-app loads? There's no perf hit for non-app loads because getting the status for these pages is fast (we hit the early return at https://mxr.mozilla.org/mozilla-central/source/caps/src/nsPrincipal.cpp#567)

There's two parts to this work: 1. Replace the parser and policy classes with C++ counterparts. Convert unit tests to compiled code tests (CSPUtils.jsm and tests). 2. Replace tie-in to the sprawling CSP enforcement mechanism to use the new parser and policy object reps (contentSecurityPolicy.js, nsCSPService.h/cpp, and all other xpcshell tests). So I'm turning this bug into part 2 (replace old JS CSP with C++ CSP), and filed bug 951457 for writing a new parser/enforcement/test backend. Once that's done, we can complete this work.

In case anyone cares: as ckerschb, grobinson and I work on this, we'll be using this shared patch queue: http://hg.mozilla.org/users/sstamm_mozilla.com/csp-rewrite-patches/

Looks like when we flip the pref to enable this on desktop, it goes green on try: https://tbpl.mozilla.org/?tree=Try&rev=379b2c0bb3ac We'll need to enable it in the b2g/app/b2g.js prefs too. I'm planning to land bug 949533 as soon as the tree opens, then this can follow shortly thereafter.

The attached patch flips the pref to use the new backend on desktop but also explicitly flips the pref for B2G. Probably B2G inherits the pref from Desktop, but to be on the safe side we should include it in b2g.js as well.

Additional note: Pushed the pref flip to try as well: https://tbpl.mozilla.org/?tree=Try&rev=5ce5d5013d38

Comment on attachment 8446590 [details] [diff] [review] bug_925004.patch >Bug 925004 - CSP in CPP: Flipping pref to use the new backend (r=sstamm) Nit: Needs a clearer commit message: "flip pref to enable new CSP backend" I know I was the one who asked for this, but please take out the changes to b2g.js. I don't think it's necessary: b2g will pick up the prefs from all.js (just like it picks up security.csp.enable). The rest looks good. r=me with a new patch with a better commit message and no changes to b2g/app/b2g.js... and given this green try (https://tbpl.mozilla.org/?tree=Try&rev=379b2c0bb3ac).

Here we go, updated commit message and removed changes from b2g.js. This is ready to land!

Relnote mostly due to Bug 949533 but this and that bug should both be covered by a single relnote.

The new backend appears to have broken our site: URL: https://micro.cupcake.io/ Content-Security-Policy: default-src https://admin.cupcake.io https://micro.cupcake.io; connect-src *; frame-ancestors 'none'; frame-src https://appsbar.cupcake.io; img-src *; object-src 'none'; > Content Security Policy: The page's settings blocked the loading of a resource at https://user.cupcake.io/config/status ("default-src https://admin.cupcake.io https://micro.cupcake.io"). The XHR to https://user.cupcake.io/config/status should be allowed by the "connect-src *" directive (and is by the previous backend as well as Webkit/Blink).

(In reply to Jonathan Rudenberg from comment #15) > The new backend appears to have broken our site: > > URL: https://micro.cupcake.io/ > Content-Security-Policy: default-src https://admin.cupcake.io > https://micro.cupcake.io; connect-src *; frame-ancestors 'none'; frame-src > https://appsbar.cupcake.io; img-src *; object-src 'none'; > > > Content Security Policy: The page's settings blocked the loading of a resource at https://user.cupcake.io/config/status ("default-src https://admin.cupcake.io https://micro.cupcake.io"). > > The XHR to https://user.cupcake.io/config/status should be allowed by the > "connect-src *" directive (and is by the previous backend as well as > Webkit/Blink). Working on it: https://bugzilla.mozilla.org/show_bug.cgi?id=1031530

Is there a need for manual testing on this feature? If so, can you please specify how the Manual QA team can be of assistance?

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #17) > Is there a need for manual testing on this feature? If so, can you please > specify how the Manual QA team can be of assistance? At the moment, I don't think there is need for manual testing - if something comes up, I will definitely let you know. Thanks for reaching out!

Added in the release notes with "New CSP (Content Security Policy) backend" as wording. If you have a doc or a blog post about this, I would be happy to take it.

Oh, by the way, does it impact also Android?

Yes, this new CSP backend affects all Gecko-based platforms. Still working on a blog post, Sylvestre.