W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: [integrity] The noncanonical-src attribute

From: Simon Pieters <simonp@opera.com>
Date: Mon, 16 Jun 2014 20:05:54 +0200
To: public-webappsec@w3.org
Message-ID: <op.xhj674bnidj3kv@simons-mbp>
On Fri, 13 Jun 2014 08:37:24 +0200, Simon Pieters <simonp@opera.com> wrote:

> http://w3c.github.io/webappsec/specs/subresourceintegrity/#the-noncanonical-src-attribute-todo
>
> I think the noncanonical-src feature is going to be insanely complicated  
> to get right. Please remove it. If authors want fallback, they can do so  
> in an imperative fashion, e.g.:
>
> <script src="https://example.com/script.js"
>          integrity="ni:///sha-256;jsdfhiuwergn...vaaetgoifq?ct=application/javascript"
>          onerror="var s = document.createElement('script');
>                   s.src = 'https://cdn.example.com/script.js';
>                   this.after(s);"></script>
>
> cheers

To elaborate, the <script> processing model is already insanely  
complicated as it is. Adding a fallback mechanism doesn't seem like it  
makes it any less complicated. The specification doesn't say what the  
processing model is, so it's a bit difficult to comment on it. Is it  
supposed to reset some state on the <script> element and start a new  
instance of the fetch algorithm? Is it supposed to hook into the existing  
fetch and make it act like it made a redirect? When exactly does this  
happen?

Why is the imperative fallback solution given above not sufficient?

P.S. Please cc me on replies since I'm not subscribed to the list.
-- 
Simon Pieters
Opera Software
Received on Monday, 16 June 2014 18:06:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC