Generally I prefer master-CSP model than the "own CSP" model due to its simplicity but I agree that unsafe-script kills the conciseness of Imports.
To make inline scripts work with imports, we might want another CSP directive like "safe-script", which allows parser-made <script> but doesn't allow dynamic ones. There is some room to talk what should be allowed as "safe-script" though. My gut feeling is A) <script>: Allowed, but B) inline event handlers: Not allowed. Does this make sense? On Fri, Jan 31, 2014 at 4:32 AM, Gabor Krizsanits <gkrizsan...@mozilla.com>wrote: > > The security objection to the original "own CSP" design was never fully > > developed - I'm not sure it's necessarily a show-stopper. > > > > Nick > > Well, consider the case when we have the following import tree: > > I1 > | | > I2 I3 > | | > I4 > > > Respectively CSP1, CSP2, CSP3. CSP2 allows I4 to be loaded but > CSP3 does not. So what should we do with I4? If I2 comes first > it will allow I4 to be loaded and then I3 will get it as well, > even though it should not. If I3 comes first then it won't be > loaded... > > But let's say we eliminate the ordering problem by loading I4 > and for I3 we just return null for the import something. > What about: > > I1 > | | > I2 I3 > | | > I4 > | | > I5 I6 > > > Now let's say CSP2 allows I5 but not I6 and CSP3 allows both > I5 and I6 (or even worse allows I6 but not I5). Now it we look > at I5 from I2 we should get a different imported document than > looking at it from I3... To fix this problem we can just completely > ignore the parents CSP when we determine if a sub import should be > loaded or not. But I think that would kind of defeat the purpose > of having CSP on the first place... > > Anyway, maybe I'm missing something but I don't see how the original > "own CSP" could work. > > -- morrita
