Closed
Bug 821169
Opened 12 years ago
Closed 6 years ago
Consider turning off CSP for local app:// resources
Categories
(Core Graveyard :: Widget: Gonk, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: zbraniecki, Unassigned)
Details
CSP seems to bring a significant penalty to app loading (bug 820196). The question opens: why do we need CSP checks on local resources loaded from index.html of an app:// for resources from itself? That sounds like a condition which will always be enabled and thus should not require any slowdowns that come with CSP to my naive understanding. Could we consider fastpathing such calls?
CSP issues are for Sid
Comment 2•12 years ago
|
||
Apps are allowed, in their manifest, to specify a CSP; this policy may contain something that blocks (for example) all images regardless of their origin. So we have to ask CSP if it's okay. The default app CSP allows for fastpathing same-origin calls, but I don't think we can assume it will always be the case. Possibly we could determine if fastpathing is allowed at document load time and cache that info somewhere available to the content policy, but that's nontrivial and would require a bit of foundational work that will take a bit of time to accomplish. It might make more sense to go all-in and reduce the amount of xpcom involved with CSP and re-write it all in C++ (which is an even more significant effort, but would have considerable perf gains).
Reporter | ||
Comment 3•12 years ago
|
||
Even with dexpcommed CSP, being able to fastpath same-origin calls after first read sounds like a major optimization, right?
Comment 4•6 years ago
|
||
Closing as we are not working on Firefox OS anymore.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•