bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.
This will prevent us to turn on the speccompliant csp for 2.0.
Naive question (I have't looked enough yet at WC to know how they work) but do we have to use import inside an inline style here? Can we use <link> instead?
Oh ok its not in the source of web components - its something to do with the way web components get embedded by the looks of it?
Oh.. blind (in an airport in between flights is my excuse). So you mean stuff like this I guess: template.innerHTML = '<style scoped>' + '@import url(' + stylesheet + ');</style>' + '<content select=".icons"></content>'; I'll test on the flight and see I can figure out a replacement.
We need scoped stylesheets, and unfortunately there is currently no speced way to have a scoped stylesheet form a <link> element. I think what we need here is to whitelist @import rules for for scoped styles. You may be able to restrict it further to same-origin/relative path policies, but I don't think this is a good idea as it may hamper engineering efforts in the future (I see potential issues with theming for example).
(In reply to Kevin Grandon :kgrandon from comment #5) > We need scoped stylesheets, and unfortunately there is currently no speced > way to have a scoped stylesheet form a <link> element. I think what we need > here is to whitelist @import rules for for scoped styles. @import already works with a CSP that prevents inline styles - its the dynamic creation of the style tag that causes the CSP violation. Is there no way we can achieve the effect of scoped some other way (a class/id etc?)? Or the comment in the code seems to suggest that if we fix bug 992249 (:content selector) we won't need this hack at all. Maybe that is the long term solution. > You may be able to restrict it further to same-origin/relative path > policies, but I don't think this is a good idea as it may hamper engineering > efforts in the future (I see potential issues with theming for example). The CSP for Gaia has explicitly forbidden inline styles for 18 months (bug 768029) - it was only a bug in the CSP implementation that allowed this at all. History aside, preventing inline styles provides mitigation to the impact of HTML injection issues, of which we have seen many in Gaia to date. Ultimately I think we need to find a solution which does not rely on inline styles. Re. Theming - as it is currently proposed, theming poses significant security risks if we were to allow third parties to create themes, see bug 1011738 comment 30 .
Actually other comments reference HTML imports as being the solution (bug 877072).
HTMLImports have landed, so we should do an experiment to see if we should leverage them in gaia. I'm a little bit concerned about the possible performance impact of having to use imports though, so we should also figure out a way to have dynamically scoped stylesheets along with CSP. This may take web component standardization work.
(In reply to Kevin Grandon :kgrandon from comment #9) > HTMLImports have landed, so we should do an experiment to see if we should > leverage them in gaia. I'm a little bit concerned about the possible > performance impact of having to use imports though, so we should also figure > out a way to have dynamically scoped stylesheets along with CSP. This may > take web component standardization work. Freddy can you have a test of this - this might help as a starting point: https://github.com/pauljt/csptest
It seems the app manager has supper powers and bypasses all CSP checks (which makes some sense to me). Testing this seems non-trivial.
Hey Freddy, we are triaging CSP bugs right now. How much of an issue is this bug? Can you assign an 'importance'?
I think this is a problem inherent to CSP, when you disallow inline styles. And not related not our implementation. CSP is not smart enough to judge about the inner workings of "<style> @import url(foo.css) </style>", when in fact this specific line could be safe as long as the import is targeting a whitelisted source.
let's investigate if that really still is an issue - assigning to myself.
Assignee: nobody → mozilla
Priority: -- → P3
I don't have time to work on this right now, let's put it in the backlog.
Assignee: mozilla → nobody
Status: ASSIGNED → NEW
Whiteboard: [domsecurity-backlog] → [domsecurity-backlog3]
You need to log in before you can comment on or make changes to this bug.