Hi. I write sandboxes for a living. > Also, sandboxing helps only until it doesn't. It's a futile task, It really isn't futile. How many major security holes

Hi. I write sandboxes for a living. > Also, sandboxing helps only until it doesn't. It's a futile task, It really isn't futile. How many major security holes in Chrome's sandbox have actually done serious damage? Yes, they happen from time to time, but not that often, and they are automatically patched shortly after (or before) disclosure, making them really uninteresting for attackers to try to exploit. Realistically, the biggest security threat to real users is phishing or similar deception. Many users can be fooled by a page that looks like an error from their operating system telling them that their computer has a virus and they should download a tool to fix it. You don't need JavaScript for that. Realistically, the highest-impact non-user-error security problems are logic flaws in complicated server code that never intended to run attacker-supplied code in the first place. Think SQL injection, confused deputies, missing access control checks, buffer overruns, SMB (Windows file sharing) bugs exploited by worms, etc. Ironically, modern JavaScript sandboxing is so good -- with so much careful scrutiny by really smart security researchers -- that realistically it's not remotely the easiest target on your system these days. The easy targets are the software that isn't written with security in mind, and the users themselves (phishing). > especially when we don't have complete control of the hardware, which we don't, because the chip developers don't tell us complete specificiations and functionality. JavaScript and WebAssembly don't have direct access to hardware. WebAssembly is not assembly, it's a platform-neutral bytecode that gets recompiled for the host after download.