Hacker News Reader

Comment by Scott_Helme_ | Hacker News Reader

Yeah, the best way to handle this is with a version in the path and then the host can knowingly/willingly upgrade the library version and SRI hash at the same time.

View on HN

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.

(I used to make web server software)

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.

Reply on news.ycombinator.com