Re: [SRI] require-sri-for: missing integrity metadata? same-origin loads?

On 09/09/16 02:54 AM, Mike West wrote:
> On Fri, Sep 9, 2016 at 9:19 AM, Frederik Braun <fbraun@mozilla.com
> <mailto:fbraun@mozilla.com>> wrote:
>
>     re 1) I don't think there's anything we can do besides blocking, if we
>     want require-sri-for to be a security feature that websites rely on.
> 
> Right. The conclusion we came to when adding the feature was that we
> should fail these scenarios, and treat it as a good forcing function for
> SRI 2 to define such mechanisms.
> See https://github.com/w3c/webappsec-subresource-integrity/pull/32#issuecomment-223490845
> for that discussion. :)

This decision "require-sri" makes more-or-less unusable until SRI
supports these extra mechanisms. That's OK given that nobody is using it
now and that they can just wait until it's ready.

It does however mean that we need to be careful before blocking new
sources of scripts in the future. Otherwise, we could end up with
something like:

1. Developer adds require-sri to their site and SRI to all scripts.
2. Browser 50 introduces MegaWorkers.
3. Developer takes advantage of MegaWorkers on their site.
4. Browser 51 adds MegaWorkers to require-sri.
5. Site breaks and there's no way to fix it w/o removing require-sri.
6. Browser 52 adds SRI support for MegaWorkers.
7. Developer adds integrity attribute to their MegaWorker scripts.
8. Site works again.

Our options will be to either block block MegaWorkers via require-sri:

(a) as soon as we add MegaWorkers to the Web Platform (i.e. Browser 50
above), or
(b) only once we add MegaWorkers to SRI (i.e. Browser 52 above).

Option (a) seems preferable from a forward-compatibility point of view
(see GitHub thread linked above), but there's no guarantee that all
browsers will choose to implement APIs in the "right" order.

Francois

Received on Friday, 9 September 2016 23:24:05 UTC