That doesn't really solve this problem, it just slows down both the rollout of the subverted version and the rollout of the fix. People aren't auditing the (minified) javascript they put onto their sites.
SRI is good for use with a CDN, where the same entity controls both the HTML that references the JS and the JS being referenced. In that case it keeps someone who subverts the CDN from being able to XSS the site.
That depends on what "this problem" is -- lots of people here would say that the problem is websites that depend on unaudited, untested 3rd party resources. I can tell from your other comments that you think it's safe to trust 3rd party resources from places like Google. So there's a disagreement that is worth talking about explicitly.
Most sites are built on lots of unaudited untested (by them) third party code sever side. Adding some client side isn't great, but also isn't a fundamental change to the dynamic.
Uh, so that's terrible added to terrible, but it doesn't really address what I just said!
If I was the mean person at IBM that buys startups and makes them "right", it's a lot more work to fix terrible added to terrible than plain terrible. And my last startup got bought by IBM, so I've experienced that pain personally.
If there’s a version in the path, then the website referencing the script can include a hash, secure in the knowledge that the resource they reference should never change.
