It is simple. Too many malicious and privacy-violating JavaScript abounds, especially after being boiled down to seemingly-indecipherable WebAssembly bytecode.

And a typical enterprise NIDS would not be able to see beyond those encrypted packet containing JS over 2-way-signed TLS/SSL, or HTTPv3 (QUIC) (or a few other E2E protocols).

Since JavaScript won't be banned (unlike Adobe Flash/ActionScript, BTW Adobe's JavaScript is still being used within PDF files) anytime soon, this is another example of seeing a void and rushing to fill its need for the betterment of Internet citizens.

Just yesterday, another "this is it and how" moment came to me: this Python PDF guy (and a few PDF experts) got me thinking "this is how to remove or make inert the JavaScript inside PDF": https://news.ycombinator.com/item?id=33646951

My understanding is that JS/WASM is sandboxed within the browser environment. It does have some access (say Camera) but only if you allow it.

Care to develop more on the potential attacks here?

too many to count.

Most recently,

https://www.sciencedirect.com/science/article/abs/pii/S09505...

Quick and dirty cleanup - convert to, then from postscript.

I absolutely love your thinking. What you propose does is defang the programmability aspect into an inert (but safer) "text-based" form.

But which side should assume the responsibility of this JS-defanging effort into text-based? Client or server? Postal said "be liberal in what you receive and conservative in what you send". So, being conservative (in this respect), server has to be minimalistic (including denial of programmability).

Real problem remains, too much accessibility of programming is being made available to let client-side take it in ... in a gullible way.

And no amount of Sideshow Barker (not a dig on HN's Sideshow Barker) can fix this, until one of the MAANG decides "enough".

Meanwhile, the wild Wild West shall continue.