Why would it matter? Surely if the Chinese government was able to MITM the JS to do bad stuff, they could also MITM the HTML to serve Javascript even if you originally weren't?

So don't serve any content from China, is what I am hearing.

We'll, you can't host from mainland - big distinction, mainland HK is far more liberal and long let that be supported - without an ICP licence.

An ICP licence is issued according to mainland policy, requirements bot exclusive to including having legal entity/people and agreeing to be part of the Golden Shield which extends far from China's firewall but also personal information tracking, both online and offline.

I trust the chinese government less than western governments.

And I don't trust them much either but at least they answer to corporations if not the people.

They just let someone die in prison for fighting for human rights.

Very true. Heck, China could also modify images to take advantage of vulnerable libraries.

I feel like this is just another reason to use subresource integrity on your includes. If you are only pulling javascript and your HTML is served outside of China you can ensure the correctness of the response.

Doesn't the resource still need to be requested to perform the integrity check? If I recall correctly the script was being redirected to a github gist which is why it was effectively a DDOS on github... so yes sub-resource integrity is great but wouldn't protect against this type of attack since the requester was the target of the attack but rather the source...

This particular attack had China inserting a javascript reloader into Baidu's javascript file to hit the two github projects they didn't like to perpetrate the DDoS. So, it wasn't just a redirect.

Since then, Baidu has been serving most of their assets through https to prevent hijacking.

How confident are you that the Chinese government does not have the SSL keys for Baidu? Because I am 0% confident.

Worth pointing out that it was not GFW which performed the man-in-the-middle, it was a separate system: https://citizenlab.ca/2015/04/chinas-great-cannon/

This is why there needs to be a system where hashes for JS files can be securely installed in browsers for verification.

I want to see native support for content-level cryptographic signatures in browsers. I also want it to be able to use a local GPG keyring, so I can validate against my chosen web of trust. JavaScript programs are just that---programs. When I use my package manager, or when I download a package online, I have a signature to verify against---either automatically (former) or manually (latter); https does not solve that.

This is different than the CA system, which verifies the _server_, not the content being served. A compromised server or successful MitM allows an attacker to modify data undetected.

This is also different from subresource integrity---it's a step in the right direction, but that only helps with third-party resources being loaded, and it doesn't at all help with cryptographic signatures.

Having signatures also helps with the case of programs constantly being updated outside the users' control. JavaScript programs are almost always ephemeral---they load with a webpage, and disappear when you leave, barring certain caching. "Updates" aren't really updates---you are re-downloading the program every time. So, hashes will change, and without cryptographic signatures, you can't be sure whether the new hash should even be trusted.

As a separate benefit, this support would also be useful for authentication online and asserting one's identity on e.g. social media, especially decentralized/federated services.

It exists, is called SSL

It's https.