Re: [HTML imports]: Imports and Content Security Policy

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
<gkrizsanits@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