Everytime I read about such constructs, it makes me realize, as a regular developer, how complex web application security is and how difficult it is to think about and cover your application against each and every such potential problem.
Array and object globals cannot be overridden now (since 2007) for literals [0] and for ambient authority problem with CORS just check the Origin header.
... except that those browsers are still out there, so it depends heavily on how much damage someone can do by abusing the data your server can emit whether you need to do the same.
The reason Google and Facebook keep this kind of stuff around is because it's there and doesn't hurt to keep it. There's a slight chance it will provide some protection if a similar attack vector is discovered.
Yes, I'm being somewhat hyperbolic. Bring on the downvotes! ;-)
All sufficiently complex ecosystems are a giant, flawed mess.
This is not a bad thing, for the simple reason that every long-lived complex system involving many humans must behave this way.
Any attempt to top-down design the perfect, universal, distributed application runtime hits fundamental social problems not unlike those in a centrally planned economy: too much information to integrate, too many stubbornly uncooperative humans with their own divergent goals and opinions.
Systems at this scale are much more like biology than like circuit design.
The idea that systems are fixed entities that have to be designed correctly up-front is wrong and is one of the reasons why the Waterfall model of software development has been superseded by Agile.
Good systems have to be designed to handle change. Change is the only constant thing in this world.
Security takes a back seat to reproductive fitness of the web as a platform. JS made the web insecure, but it also made it the world's premier application platform.
I blogged about this: http://kylebebak.github.io/post/browser-security-worse-is-be...
[0]: http://webassembly.org/docs/faq/#is-webassembly-trying-to-re...
First of all browsers are committed to backwards compatibility.
Secondly, there's huge amounts of Javascript written right now, nobody's going to throw away billions of dollars worth of investments. People complain about Cobol written in the 60's, when the programmers counted in the thousands. Javacript today is written by millions of programmers.
And thirdly, Javascript evolves, as do browsers.
It's not very hard to imagine, especially in an enteprise environment, running a browser 15-20 years from now and that browser loading the equivalent of the JVM, .NET CLR, Ruby VM, etc., on top of WASM :)
AFAIK it never went anywhere, but maybe building an entirely new OS/Browser based around WebIDL seemed less insane 10 years ago.