2. Because that requires you to know how to find the hash and add it.
Truthfully the burden should be on the third party that's serving the script (where did you copy that HTML in the first place?) but they aren't incentivizes to have other sites use a hash.
Well, to be honest, the browsers could super easily solve that. In dev mode, just issue a warning "loaded script that has hash X but isn't statically defined. This is a huge security risk. Read more here" and that's it. Then you can just add the script, run the site, check the logs and add the hash, done.
Of course you can. But when it comes to security, one thing is very important in practice: making the secure way of doing things as easy as possible.
So, why did you not actually post the correct shell script? Apparently that would have been more effort to get right and ensure is correct right? And also work for every OS. And there you have it: if someone first has to figure out which script to run, some percentage will give up here. And that's my point: the browser should make it as easy as possible to avoid that from happening.
> In dev mode, just issue a warning "loaded script that has hash X but isn't statically defined.
How does the browser know which files to warn you about? What about scripts that are generated dynamically and have no static hash? There's plenty of reasons why you wouldn't want this.
It just warns about all embedded non-same-origin scripts that don't have a hash.
> What about scripts that are generated dynamically and have no static hash?
Well, then the warning is still valid because this is a security risk. I guess it'd be fine to be able to suppress the warning explicitly in those cases.
> There's plenty of reasons why you wouldn't want this.
For example? Honestly curious where you would not want a warning by default.
Literally every website that uses JSONP will stop working if that happened. This would break the web in fundamental ways. If we're going to break the web in fundamental ways, resource integrity is hardly among the things that I'd be interested in changing.
There are security risks with JSONP (a hack to bypass same-origin policy), and the successor (CORS) has been around since 2009, so phasing it out may be a good thing.
I don't think it's just laziness. There's use cases where the libraries are designed to be updated automatically.
Also some of the tracking scripts I don't think are strictly static content, maybe their strategy to fingerprint browser involves sending different shit to different users.
If you are the one serving the website, then you are the one generating the hash. If you want to serve different stuff then you could dynamically generate the hash for that different stuff rather than hard code it statically.
Specifying a script hash says that you as the owner of that site agree to load the content only if it matches the hash. Presumably you trust the content enough to serve it to your users.
I don't mean to be pedantic, but not always--see the recent DigiCert delayed revocation issues. I will admit it is rare though and more often than not, you (should) know when your certs are going to expire.
2. Because that requires you to know how to find the hash and add it.
Truthfully the burden should be on the third party that's serving the script (where did you copy that HTML in the first place?) but they aren't incentivizes to have other sites use a hash.