In a browser's current usage model, this is vulnerable to a 'cache origin confusion attack'. See this thread [1]. It's a bit hard to follow, so perhaps see these posts [2][3], which state the problem succinctly. Let me adapt the text from [3]:

The problem is that www.victim.com/evil.js doesn't exist, and never did, but your browser won't know that if it's in the cache -- this gives you a way of faking files existing on other servers at the URL of your choice, and as long as they're in the cache you'll get away with it.

[1] https://news.ycombinator.com/item?id=10310594 [2] https://news.ycombinator.com/item?id=10311555 [3] https://news.ycombinator.com/item?id=10312333

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

And then using bit torrent to do colaborative transfer. If we are in the same LAN and I have a part of the file you are requesting, I'll feed it to you... so decrease network traffic in 90%

Putting my devil's-advocate hat on:

What sort of failure modes are there when something inevitably goes wrong, either through malice, incompetence or sheer plain accident, and you end up serving different content from the same hash?

If you've discovered a way to generate hash collisions with a modern crypto hashing algorithm, there is more glory to be had than screwing with people's browser caches.

So lets skip the malice condition and go to the plain accident one; there are more chunks of content in the world than there are bits in any of the hashes we could use. We are eventually going to run into collisions.

Arbitrary example: If you're using SHA256 you're emitting 256bit hashes. Hopefully the distribution of SHA256 outputs is indistinguishable from random (or close enough) or else we've got big problems in other domains.

If you're drawing at random from a pool of size k you need approximately sqrt(k) draws until you reach a ~50% chance of a collision[0].

With 256 bits, there are 2^256 possibilities, so following the rule-of-thumb you'd need 2^128 draws until you had a 50% chance of a collision.

2^128 > # of atoms in the universe.

If you adjust your risk tolerance you'll have different numbers come out, but the chance of a collision in any realistic scenario is negligible.

[0]: https://en.wikipedia.org/wiki/Birthday_problem

> there are more chunks of content in the world than there are bits in any of the hashes we could use

The probability of collision is still negligible.

Come on, you must know that hashes are astronomical, unpredictable and collision-free for any earthly purpose. If not, just add a bit.