W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2016

Re: Security / Technical feedback on subresource integrity specification

From: Jonathan Kingston <jonathan@jooped.co.uk>
Date: Wed, 20 Jan 2016 16:19:27 +0000
Message-ID: <CAKrjaaX0CrVoPk1-0+6q9ERJUFu5YgXZQw_ECnX9sqtPNjoPzQ@mail.gmail.com>
To: Richard Barnes <rbarnes@mozilla.com>, Francois Marier <francois@mozilla.com>
Cc: WebAppSec WG <public-webappsec@w3.org>
It should also be easy to pollyfill when all browsers implement the
integrity metadata in the fetch request:
This could be then used in a service worker to implement things like having
race loading of multiple requests to CDNs for example.
As described here:

On Wed, Jan 20, 2016 at 4:02 PM Richard Barnes <rbarnes@mozilla.com> wrote:

> On Tue, Jan 19, 2016 at 8:37 PM, Francois Marier <francois@mozilla.com>
> wrote:
>> On 18/01/16 05:36 PM, Mhano Harkness wrote:
>> > Perhaps a future version could support something like the below (or some
>> > other mechanisms to support graceful and secure fall back in case the
>> > CDN is not available, the user agent doesn't understand the new
>> > directive, etc.):
>> One thing that was pointed out to me by one of the developers of a large
>> site is that the use of a CDN is not always optional. In their case, if
>> static resources were to fall back to the main webserver, it would bring
>> it to its knees.
>> Another point that was raised is that if you have two copies of a
>> resource (one on the CDN and one local), you need to ensure that they
>> are always in sync and that you test both
> In addition to the above, I'm not sure it makes sense to bake a fallback
> strategy into the browser.  Any fallback strategy is going to have pitfalls
> of the type Francois mentions, so different ones are going to be
> appropriate for different sites.  And it's something that sites can already
> polyfill -- just check whether the resource in question loaded, and if not,
> add it to the DOM yourself.
> --Richard
Received on Wednesday, 20 January 2016 16:20:08 UTC

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