W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

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

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>
Message-ID: <1391341505.6536288.1391110368842.JavaMail.zimbra@mozilla.com>
> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:21 UTC