Re: webcomponents: <import> instead of <link>

On Wed, 15 May 2013 20:26:36 +0200, Dimitri Glazkov  
<dglazkov@chromium.org> wrote:

> On Tue, May 14, 2013 at 2:21 PM, Simon Pieters <simonp@opera.com> 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

Received on Wednesday, 15 May 2013 20:08:46 UTC