- From: Gabor Krizsanits <gkrizsanits@mozilla.com>
- Date: Thu, 30 Jan 2014 11:32:48 -0800 (PST)
- To: Nick Krempel <ndkrempel@google.com>
- Cc: Scott Miles <sjmiles@google.com>, public-webapps <public-webapps@w3.org>
> 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.
Received on Thursday, 30 January 2014 19:33:16 UTC