Just for anyone curious, I know that SRI and CORS are different. SRI negates the need for CORS in some situations because we're saying that we only care about t

Just for anyone curious, I know that SRI and CORS are different. SRI negates the need for CORS in some situations because we're saying that we only care about the file content, not where it came from. For the web, we could have been sourcing all of our javascript files from a central CDN and used the hashes to prove that they weren't tampered with this whole time. Instead, we went down the rabbit hole of build systems and endless local hosting. For this Node.js use case, they could have allowed remote includes, with the understanding that it's only secure when the hash is specified. Verifying only the location is like CORS, it's security theater based on trust instead of a mathematical level of confidence about the contents. Good point about dynamic responses not being compatible with SRI though. I hadn't thought about that use case, but you might be onto something about its lack of adoption. It may be a red herring however, because to make SRI dynamic, we'd need some kind of trust process that tells us that a new version's hash is safe, more like a BitTorrent tracker, but the file would still be requested through ordinary SRI. Also it doesn't apply to what we're talking about here, because package versioning means that the files are always static anyway.