This issue is discussed here, with what I think is a workable solution: https://github.com/w3c/webappsec-subresource-integrity/issue...

I think the best way to fully quell the objections involves subresource integrity but I think the ideal way to deal would be to add a new attribute, sameas="https://canonical jquery link" or something along those lines. Then if the browser already has canonical jquery link AND the subresource integrity checks out it'll use that one. Otherwise it will load from wherever the developer specified and not be stored in a shared cache associated with the canonical jquery url in any way. Browsers can track references to sameas URLs that they keep getting cache misses on and go fetch them in the background for future use, possibly even going back and deleting the duplicates it had from before. This would allow developers to have a much greater chance that their libraries load from cache without adding more dns lookups and dependencies on cdns or servers they can't control.

From that thread, "CSP already has a mechanism for hash-based whitelisting - if this is the only limitation, it'd be just as easy to allow cache-sharing whenever CSP is absent and/or the specific hash is explicitly white-listed." <- I totally understand the attack, but fail to see why it would be a problem if CSP actually does, in fact, have the ability to whitelist hashes (and looking at the spec, it does seem to, though I have not paid attention to CSP before and admit I could be misinterpreting the spec based on this prompt).

This is fixed by relying on CORS and using a key of (domain, hash) rather than just the hash.

But then you're still downloading jQuery (or whatever) again for every unique domain

Not if it points to a CDN.

This brings us back to current status, as it defeats the purpose of normalizing arbitrary CDNs with the hash