Extend SRI to apply to <link rel=preload>

[joelweinberger]

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?

[joelweinberger]

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.

[guybedford]

This really does seem like the best workflow for module scripts in production. Surely a compromise can be made that:

1. Disabling preload / prefetch will still enforce the integrity information associated with it.
2. Where a resource is in the cache, its integrity is checked against any explicit tag that loads it, as well as by any integrity on a link prefetch (in case it comes up, but surely users would dedupe here themselves anyway).

[jyasskin]

As a heads-up, for signature-based SRI I'm currently contemplating an Accept-Signature header to ask the server to include its signatures. WICG/webpackage#109 (comment) mentions that preloads will need to know to send that header for resources that will eventually have integrity attributes. There are several choices there:

1. The server knows which resources will have integrity attributes and sends the signature unconditionally.
2. The browser always sends Accept-Signature for preloads that might be used with integrity
3. Devs need to attach the integrity attribute to the preload.

[guybedford]

@jyasskin thanks for the update, (2) and (3) sound like a sensible directions (and I hope both might be implemented). I'd very much like to see (3) here though acting as an opt-out of the "accept-signature" header, with future fetch calls matching the preload getting any preload integrity failure result even if they themselves don't specify integrity.

One other thing - this "Signature" header will often be exactly the same as the "ETag" header used in caching. It could be useful to propose an "Etag: Signature" or similar going with this to allow unification.

[mikewest]

@jyasskin: Why do you think we'd need to ask the server to include signatures? Naively, it seems like your (1) is a more likely outcome for servers that wish to support signatures on resources. Why would server operators choose otherwise?

[annevk]

Also, even though HTTP/2 has some header compression, let's still try to avoid introducing new headers if we can. Note also that a new request header like that would violate the same-origin policy, strictly speaking.

[littledan]

Should this be closed due to whatwg/html#4699 ?

[annevk]

Yeah, the remaining issue with preload's Fetch integration is already tracked.