On Wed, 15 May 2013 20:26:36 +0200, Dimitri Glazkov
<[email protected]> wrote:
On Tue, May 14, 2013 at 2:21 PM, Simon Pieters <[email protected]> wrote:
That seems to be an argument based on aesthetics. That's worth
considering,
of course, but I think is a relatively weak argument. In particular I
care
about the first bullet point above. <link> is not capable of executing
script from an external resource today. What are the implications if it
suddenly gains that ability?
Given that WebAppSec peeps suggested that CSP treats <link rel=import>
as script-src, I am pretty sure we're okay here. Are there any other
things that we should worry about?
That by itself doesn't make me confident that there are no security
problems. If this has been reviewed by the security team at one or several
browser vendors, that would inspire more confidence. Has it?
I don't have a specific attack scenario to present right now. I'm just
presenting my knee-jerk reaction to making an existing element capable of
executing script from an external file.
Case study: <img> was historically not capable of executing script from an
external file. This lead to sites expecting <img> to be safe (e.g. allow
untrusted comments to use <img>). When browsers wanted to support SVG in
<img>, scripting had to be disabled in order to not break the assumption
that <img> is safe.
There's one more ditty that seems valuable: HTML Imports
scripts-blocking behavior is much closer to how <link rel=stylesheet>
works
(https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/imports/index.html#dfn-import-ready-flag
and thereabouts)
I'm not familiar with the code for this in browsers, but it seems to me
that it shouldn't be much harder to reuse the mechanism for this if we use
<script import> rather than <link rel=import>.
--
Simon Pieters
Opera Software
