1. Perhaps, but we already have JavaScript, and WASM has much less access than JavaScript at the moment. It's definitely something to watch as WASM gets more in

1. Perhaps, but we already have JavaScript, and WASM has much less access than JavaScript at the moment. It's definitely something to watch as WASM gets more integrated. 2. Sure, it is intended for native-type development in the browser. In fact, the easiest languages to get started with are C, Rust, and Go IMO. 3. If it's being sent over TLS, you know that it hasn't been tampered with in flight, no? So it is functionally equivalent in this regard to JavaScript. 4. Have you tried to audit obfuscated JavaScript? If that's acceptable, you can do the same with the tools provided for WASM. 5. Yup. However, as I mentioned earlier, TLS removes the ability for things to be tampered with in flight, which means you'll need to trust the server (and the browser). Since that's always the case, I'm not sure what you want to see different here. 6. So don't use HTTP and only use HTTPS? Browsers are moving toward making that look more scary to the user, so it's a browser problem, not a WASM one. 7. No, it assumes the sandbox can prevent security issues. The language subset stuff is to help developers write more reliable code. It won't eliminate crashes from faulty code, it'll just make those easier to spot. Those CVEs mostly look like problems in the sandbox, which will mature as WASM gets used more. Those types of things point to immaturity in implementation, not design AFAICT.