3 ms·

It makes the use-case for this type of code deployment wider, it's more effective at what it's already used for, and it's also less auditable. These are three

by madez 9y ago

It makes the use-case for this type of code deployment wider, it's more effective at what it's already used for, and it's also less auditable. These are three reasons why developing and supporting WebAssembly is finally against the interest of the users. The harder, less efficient and cumbersome this type of drive-by code deployment is, the less attractive and used it'll be. Also, sandboxing helps only until it doesn't. It's a futile task, 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.

kentonv 9y ago
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.
drvdevd 9y ago
Although I take your points, I disagree that JavaScript is more auditable as-is. In either case I will need tools to unwind/flatten/de-obfuscate the code and audit it. I believe it would take me about the same amount of time in either case, depending on the scope of the audit. Regardless, it’s a trade off. Although I agree we should have a web that doesn’t need JavaScript to function - I believe that is a separate argument - I think in this case, while we already have it, I’ll take WebAssembly for the speed and new applications it helps support. I certainly wouldn’t want to see “Web Assembly” blobs in my browser that I’m not allowed to inspect, which again is another argument, IMO.

by madez 9y ago

kentonv 9y ago

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.

drvdevd 9y ago

Although I take your points, I disagree that JavaScript is more auditable as-is. In either case I will need tools to unwind/flatten/de-obfuscate the code and audit it. I believe it would take me about the same amount of time in either case, depending on the scope of the audit. Regardless, it’s a trade off. Although I agree we should have a web that doesn’t need JavaScript to function - I believe that is a separate argument - I think in this case, while we already have it, I’ll take WebAssembly for the speed and new applications it helps support. I certainly wouldn’t want to see “Web Assembly” blobs in my browser that I’m not allowed to inspect, which again is another argument, IMO.