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

Re: [Integrity] Comments/Questions on Subresource Integrity spec

From: Mike West <mkwst@google.com>
Date: Wed, 23 Apr 2014 14:26:09 +0200
Message-ID: <CAKXHy=cG5mm4-wQKPWq4W9U2FMs=9yK2U3YU8qwdbA3FAj2-4w@mail.gmail.com>
To: Tanvi Vyas <tanvi@mozilla.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Apr 23, 2014 at 7:21 AM, Tanvi Vyas <tanvi@mozilla.com> wrote:

>  Thanks Dev and Brad for your responses!  Two things I'd still like to
> discuss (perhaps during tomorrow's call) -
> * why do we need separate fallback mode and a block modes?  If the website
> wanted to fallback, they would include a src and a noncanonical source,
> along with an integrity attribute.  If they did not want to fallback, they
> would just provide the src and the integrity attribute.

The CSP bits of the spec are certainly half-baked. I can see value in
dropping the fallback policy type in favor of an explicit fallback
possibility for individual resources.

It might be worthwhile, however, to offer authors the ability to turn off
the fallback ability entirely. That is, perhaps we should replace the
default policy with 'fallback', while allowing authors to choose the more
restrictive 'block', which would disable the noncanonical bits.

> * if the non canonical source fails the integrity check, should we require
> that the actual source be retrieved over https?

That sounds reasonable to me, but Brad and others might have opinions about
the use-cases here that would be relevant...


Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Wednesday, 23 April 2014 12:26:59 UTC

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