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
Care to develop more on the potential attacks here?
Most recently,
https://www.sciencedirect.com/science/article/abs/pii/S09505...
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.
