Alternatively, we could also just implement SRI verification for memcached resources if they're about to be reused by an SRI capable element with integrity data, even if the original download did not include an integrity attribute.

Yoav, letting you own this for now while the spec issues are sorted out.  Let me know if you aren't planning on implementing it and we can find another owner or make it generally available.

I can own it in the mean time. If the solution is adding an `integrity` attribute, I can easily implement. If it's just smarter SRI checks when taking resources out the memcache, I'm less familiar with that code (but might be able to give it a try)

Issue 687618 has been merged into this issue.

csharrison - do you know who currently owns SRI? If so, can you CC them?

Issue 692420 has been merged into this issue.

FYI the issue that was merged in concerns a "regular" css link tag, not a preload link tag.

Yeah, I agree that we probably need to tackle these two cases at the same time, as they share many characteristics.

hkrutzer: Sorry I should have been more clear with the merge. I mostly merged these because of what Yoav mentioned in #8: I suspect the fix for this will be similar to preloads.

jww knew sri (I think) but is no longer working on Chromium. ccing mkwst for further triage. Also ccing kouhei who complicated stylesheet SRI with [1] :)

[1] https://codereview.chromium.org/2398733003/

+1 to having link integrity attr.
We currently discard undecoded bytes aggressively, and it makes sense as undecoded bytes will not be used after CSS parse except for SRI/CSP digest computation.
If we have the CSS resource SRI-ed preload, we can simply cache the IntegrityMetadataSet at the time so MemoryCache can utilize the cached IntegrityMetadataSet.

tyoshino,toyoshim: FYI

Unlike `crossorigin` that affects the actual fetch `integrity` should only affect if resource can be used or not. It might be harder to implement, but it would be easier to use 'Link' headers if repeating `integrity` attribute wasn't required in preload `link` elements and 'in Link' headers.
Also - checksums are long are make `Link` headers hard to read ;-)

@kouhei - would an "integrity needed" signal (and corresponding hash function) be enough for us to calculate integrity for those preloaded resources, but matching calculated integrity when the resource is about to be reused?

Also, even if we do that resources in the MemoryCache may still be in flight when they're about to be used, so integrity hash might not be ready for comparison. We would need to hook this up with current SRI buffering mechanisms (which I'm not familiar with) 

Issue 698240 has been merged into this issue.

Issue 701943 has been merged into this issue.

#12 : It depends. If we knew which hash to compute, it would help.