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.
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.
> 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.
- After version X we are displaying a prominent popup if a script isn't loaded with a hash
- After version Y we blocking scripts loaded without hashes
They could solve this problem in a year or so, and if devs are too lazy to specify a hash when loading scripts then their site will break.
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.
https://dev.to/benregenspan/the-state-of-jsonp-and-jsonp-vul...
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.
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.
