Extend SRI to apply to <link rel=preload>

[metromoxie]

This could allow a developer to put an integrity on a preload such that they don't need to markup every instance of the resource in the DOM. For example, place the integrity on the preload at the top of the page and allow resources to be programmatically added without any need to add an integrity attribute. @yoavweiss @igrigorik

[fmarier]

This could allow a developer to put an integrity on a preload such that they don't need to markup every instance of the resource in the DOM.

What if a user has disabled preload / prefetch? They effectively be disabling SRI?

[metromoxie]

Is that a thing? Why can users disable ? I'll have to let @yoavweiss and @igrigorik comment on that, as I know almost nothing about that spec.

[igrigorik]

The user can't disable declarative prefetch/preload - e.g. if you were able to, the developer can just fallback to injecting an img/xhr, etc, so this is a noop setting. The user may be able to disable speculative prefetch - e.g. fetches initiated by the browser based on navigation history or other signals.

What we're talking about here is declarative prefetch/preload.

[yoavweiss]

We're currently hitting this in the wild in https://lodash.com/
font-awesome.min.css has an integrity attribute, which prevents it from being reused.

/cc @jdalton

[shekyan]

Presence of integrity metadata discards preloaded resources. In practice, it actually causing requests happen twice, giving you a choice of security vs performance :(

What is the status of this? Can I help?

[yoavweiss]

I guess the big question here is whether we can/should verify integrity for resources taken from memory cache (and avoid the need to add integrity attribute on link preloads).

My main concern there (implementation-wise) is what to do when the preloaded resource is still in flight at the time it's requested by the SRIed element.

/cc @mikewest

[mikewest]

IMO: We should verify integrity of a resource we're executing on a page (that is <script src=... integrity=...> should not load unverified code). I don't particularly care if we do that by adding integrity to <link rel=preload> or by teaching browsers to verify the integrity of data loaded out of the memory cache.

Honestly, this sounds like a weird outcome of Chrome's implementation rather than an intentional decision in the spec.

[annevk]

This sounds like another stupid bug caused by not specifying how preload actually works. I wonder when it's enough to convince someone to actually standardize the feature...

[shekyan]

My main concern there (implementation-wise) is what to do when the preloaded resource is still in flight at the time it's requested by the SRIed element.

There is another implication at least in Chrome implementation, where preload as="script" will be blocked no matter what, if there is require-sri-for script present in the CSP.