From a quick search, there's apparently already a way to have the browser verify the cryptographic hash of a resource loaded from an external source: Subresource Integrity (SRI). [0]
Can anyone comment on whether it's practical, and whether it could help here?
SRI now solves the problem of ensuring a third-party resource doesn't unexpectedly change its contents, but it can't address the security issues of being able to time how long a request takes to tell if you already have it in your cache.
AIUI it is less practical than you'd like, for several reasons that work together to greatly mitigate its impact: 1. The remote content most vulnerable to hostile change is also remote content already being loaded precisely because it changes; ad scripts, etc. Protecting your jQuery load is nice, and if someone did compromise a CDN's jQuery it would be a big issue, but it's also not what has been happening in the field. If the content has to change you can't SRI it. 2. If you have a piece of remote content that you rigidly want to never change, it's much safer to copy it to a location you control, and it's almost as easy as SRI. 3. If a subresource fails SRI there's no fallback other than simply not loading it, so it has a very graceless failure mode. This combines with #2 to make it even more important to put it in a locally-controlled area. Once local, SRI is more-or-less redundant to what SSL already gives you.
Basically, it's one of those things that looks kinda cool at first and makes you think maybe you should SRI everything, but the real use cases turn out to be much smaller than that.
SRI solves a real problem if you want to use a CDN without opening yourself up to compromise if the CDN is compromised. But yes, there are lots of other problems that it doesn't solve.
Define "help". With the new caching rules, there is just no way two sites with different TLDs can share asset caches, so it wouldn't help in the sense that double downloads could be avoided.
True, but the "avoid multiple downloads" part is most likely more significant than the "avoid multiple copies on disk" part. Storage is comparatively plentiful while network bandwidth is often quite scarce, and 3 seconds longer loading time are going to be more visible than a 10 MiB larger disk usage.
I think that the developers of it have argued there's a security concern with using it to avoid looking up libraries. I know it's come up here on HN before if you can find it.
AIUI it is less practical than you'd like, for several reasons that work together to greatly mitigate its impact: 1. The remote content most vulnerable to hostile change is also remote content already being loaded precisely because it changes; ad scripts, etc. Protecting your jQuery load is nice, and if someone did compromise a CDN's jQuery it would be a big issue, but it's also not what has been happening in the field. If the content has to change you can't SRI it. 2. If you have a piece of remote content that you rigidly want to never change, it's much safer to copy it to a location you control, and it's almost as easy as SRI. 3. If a subresource fails SRI there's no fallback other than simply not loading it, so it has a very graceless failure mode. This combines with #2 to make it even more important to put it in a locally-controlled area. Once local, SRI is more-or-less redundant to what SSL already gives you.
Basically, it's one of those things that looks kinda cool at first and makes you think maybe you should SRI everything, but the real use cases turn out to be much smaller than that.