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

On Fri, Sep 9, 2016 at 9:19 AM, Frederik Braun <fbraun@mozilla.com> wrote:

> 1) What should require-sri-for do for other methods that do not allow
>
fetch-options (e.g. @import and url() in CSS)?



> 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. :)


> 2) What should require-sri-for do for same-origin resources (Workers,
> importScripts etc. can not load cross-origin)?
>

re 2) I've been thinking about this myself and would consider allowing
> same-origin loads without integrity metadata. It just does not fit the
> use case of not having to trust a CDN.
>

Hrm. It seems that "require" either means "require" or not. If you're
willing to require SRI for all scripts on your page, why would it be
helpful to make exceptions for your own origin? I think I agree with you
that there's not significant risk associated with same-origin resources,
but I'd assert that the mental model for developers is simpler to
understand if it's a binary switch.

-mike