6 ms·

Edit: I just remembered that WebAssembly has JavaScript based polyfills. Disabling WebAssembly does not do me much good, as it will still run. I will leave my o

Edit: I just remembered that WebAssembly has JavaScript based polyfills. Disabling WebAssembly does not do me much good, as it will still run. I will leave my original comment below to remain a frame of reference for replies, but they are based on a flawed thought process of mine. --- I have yet to see a real reason for browsers to enable WebAssembly with out at least a permission dialog like location services, alerts, flash, etc. The only thing I have heard that uses the feature is the CryptoCurrency miner mentioned in the article and some random demos released by Mozilla. First thing I am doing when I get back to my laptop is finding where the hidden flag to disable WebAssembly is in Firefox and Chrome, as an ad blocker can only go so far with blocking this. I could be very wrong, but I see noting but potential for abuse. If I run across a legitimate use case, I can re-enable the feature on demand. Edit: https://github.com/stevespringett/disable-webassembly/blob/master/README.md https://github.com/stevespringett/disable-webassembly/blob/m... Seems like disabling the feature is a difficult task in all browsers that have WebAssembly except Firefox.

geofft 8y ago
How would you phrase the permission dialog? In a paranoid browser targeted at security nerds, I can see it making sense, but how would you explain what WebAssembly is and what the risks are to someone who hasn't heard of it and doesn't have a good sense of what JavaScript is? Also, what do you believe the risks are for you? (Do you find that website convincing? I don't think any of those arguments make sense, so I'm happy to argue against them if you do.) And how do those risks compare to JavaScript itself (including asm.js, or a wasm polyfill)?
- wybiral 8y ago
  Yeah, I think if you allow JS at all then WebAssembly isn't really adding much risk.
- enzanki_ars 8y ago
  Edit: I just remembered that WebAssembly has JavaScript based polyfills. Disabling WebAssembly does not do me much good, as it will still run. I will leave my original comment below to remain a frame of reference for replies, but they are based on a flawed thought process of mine. --- I understand that the page I linked to does not have a solid argument for why it should be disabled. There is a point though the author made that I do agree with, but they did not detail it well. I could be understanding what WebAssembly has and what it could bring, but the way I have read it is that WebAssembly allows users to create desktop like apps with better performance than JS. I am fine with that. The problem lies with in the sandboxing model. Sandboxes work great in principle, except that more toys that get added, the harder it is for the sandbox to keep all of the sand in. Just recently JavaScript had a small bit of that problem with WebUSB. See https://news.ycombinator.com/item?id=16501400 https://news.ycombinator.com/item?id=16501400 and https://news.ycombinator.com/item?id=17332340 https://news.ycombinator.com/item?id=17332340 In JavaScript at least, the browsers could change how the APIs respond to fix the issue. In the case of WebAssembly, I honestly do not know if they are able to shut down vulnerabilities as quickly. My understanding is that these binaries are similar to compiled apps that you can run directly on your desktop. Now it would seem that we would have to run virus scanners directly in our browser on every binary that wants to run. Am I be over reacting to all of this? Probably. But I would rather be overly cautious that be caught up in a exploit on a service that is not used much. I would prefer WebAssembly is treated in the same fashion as Flash until the standard has settled and it’s security is proven.
  - geofft 8y ago
    > The problem lies with in the sandboxing model. Sandboxes work great in principle, except that more toys that get added, the harder it is for the sandbox to keep all of the sand in. That's not really a meaningful analogy: computer sandboxes don't overflow and burst, the way that physical sandboxes do. There's no way to over-stress them and cause them to fail under load. They can have holes, but those holes are equally accessible to everything inside the sandbox, whether it's a hundred gallons of water or a single stick pointing directly at the hole. The WebAssembly and JavaScript sandboxes are the same. In fact one of the current practical problems with WebAssembly as a general-purpose JS replacement (for the "I hate JS, I want to write in $language" use case) is that every interaction with the browser has to go through JS. The DOM API is exposed to JS. So WebAssembly is very slow unless you're using it for heavy computation or something that doesn't need much DOM interaction (e.g., a video game where you create a canvas, get a reference to it, and then draw on it without bothering JS any further). The WebUSB problem was an API that was exposed to the sandbox that shouldn't have been, and was exploitable with very little code. That is, the problem was not that too much was inside the sandbox; it's that people deliberately cut a hole in the sandbox and didn't quite think through the implications of it. > In JavaScript at least, the browsers could change how the APIs respond to fix the issue. In the case of WebAssembly, I honestly do not know if they are able to shut down vulnerabilities as quickly. They can shut them down in the same way. WebAssembly uses the JS APIs. > Now it would seem that we would have to run virus scanners directly in our browser on every binary that wants to run. Virus scanners are a fundamentally broken model of security; that's why we've moved to sandboxes. Sandboxes don't care what the app does, or how it does it. They certainly don't attempt to identify malicious code, the way an antivirus does. They just limit the capabilities of the environment in which the app runs. It doesn't matter what language the app is; if it doesn't have a "delete my files" API available to it (either intentionally or unintentionally), it can't delete your files. The worst that can happen is it can spend a lot of CPU being sad about not being able to delete your files... and you can just implement a CPU consumption limit, too. > I would prefer WebAssembly is treated in the same fashion as Flash until the standard has settled and it’s security is proven. The fundamental problem with Flash is that Flash was a different sandbox; it was a browser plugin, a piece of code that embedded itself directly into the browser itself and ran with full privileges on your desktop, that was expected to implement its own sandboxing. That sandboxing was designed by one company with a specific set of market pressures in favor of "ship cool things" and not as much in favor of "keep people secure", precisely because it was code running inside the browser that wasn't from the browser vendor. WebAssembly just reuses the existing JavaScript sandbox (both the model and the specific implementation), and the model of which APIs are accessible has been hardened over time via public review and standardized development. If you haven't heard the phrase "browser plugin" in a while (in favor of "browser extension"), it's because people realized that plugins were a fundamentally bad way of doing things, and we should instead focus our efforts on exposing cool new features incrementally to JavaScript and putting anything else we're excited about in the same sandbox as JavaScript. Occasionally there are mistakes in the sandbox model, like WebUSB. I am also sure that there will be mistakes in individual sandbox implementation that are somewhat easier to exploit with WebAssembly (but would probably still be exploitable with pure JS, just a little harder). That's why I think a paranoid browser for security nerds or high-risk people should have a way to disable it (and probably also a sandbox that excessively prioritizes safety over performance and correctness...). But I don't think as a general-purpose feature it's any different from JS.
carlosdp 8y ago
Webassembly is a runtime not a feature like location services, that would make as much sense as prompting the user for whether JS should be enabled every time a page loads. Webassembly is relatively new, but expect many websites to start implementing newer client front-ends in wasm as opposed to JS in the nearish future, at least partially. Disabling it would only make sense if you also intend to disable JS, which is your choice but just makes your life harder =P
- TomMarius 8y ago
  It could be phrased as a feature. "Enable high-performance computing for this website?"* or something like that. * I'm aware it's incorrect. It's just an illustrative example.
  - skissane 8y ago
    The average user has no idea of the implications of answering "Yes" or "No", or the respective pros and cons of each option. One shouldn't ask people questions they have no hope of sensibly answering. Some highly technical users will have some idea of what the implications of each answer are, but for them you are better to use the proper name ("WebAssembly"), since then it will be much clearer what the question actually is asking about.
    - enzanki_ars 8y ago
      Browsers, except Chrome recently [1], will ask the user if they want to run Flash. I do not believe that most people even understand the risks Flash brings. [1]: Chrome stopped asking and won’t run Flash until they click though a couple menus to enable it. --- Edit: I just remembered that WebAssembly has JavaScript based polyfills. Disabling WebAssembly does not do me much good, as it will still run. No dialog can really stop that...
  - geofft 8y ago
    Why would anyone ever say no to that, though? In order for a permission prompt to be meaningful, the tradeoff must be immediately obvious. For instance, "Allow this website/app to use your camera?" is a meaningful prompt. You might want it to use features involving taking photos; you might not want the site or app to see where you are. But what is the downside of high-performance computing? And how am I supposed to meaningfully evaluate (even as a security nerd!) "Allow high performance computing that might steal secrets from your machine?" Why would I ever say yes to that?
JoshTriplett 8y ago
People who feel the need to disable JavaScript entirely will wish to disable WebAssembly as well. But we're long past the point where it was reasonable for browsers to ask permission to run JavaScript on a case-by-case or site-by-site basis. If you want that, you should run an extension. Notable applications for WebAssembly include decoding or parsing various formats, implementing games or game engines, writing portable software that targets both native and HTML5/WASM (or porting software from other platforms), or just writing normal browser client code in a non-JavaScript language. While it certainly isn't as widespread as JavaScript yet, not least of which because browsers haven't supported it for nearly as long, I regularly run into sites using it.

geofft 8y ago

How would you phrase the permission dialog? In a paranoid browser targeted at security nerds, I can see it making sense, but how would you explain what WebAssembly is and what the risks are to someone who hasn't heard of it and doesn't have a good sense of what JavaScript is? Also, what do you believe the risks are for you? (Do you find that website convincing? I don't think any of those arguments make sense, so I'm happy to argue against them if you do.) And how do those risks compare to JavaScript itself (including asm.js, or a wasm polyfill)?

wybiral 8y ago
Yeah, I think if you allow JS at all then WebAssembly isn't really adding much risk.
enzanki_ars 8y ago
Edit: I just remembered that WebAssembly has JavaScript based polyfills. Disabling WebAssembly does not do me much good, as it will still run. I will leave my original comment below to remain a frame of reference for replies, but they are based on a flawed thought process of mine. --- I understand that the page I linked to does not have a solid argument for why it should be disabled. There is a point though the author made that I do agree with, but they did not detail it well. I could be understanding what WebAssembly has and what it could bring, but the way I have read it is that WebAssembly allows users to create desktop like apps with better performance than JS. I am fine with that. The problem lies with in the sandboxing model. Sandboxes work great in principle, except that more toys that get added, the harder it is for the sandbox to keep all of the sand in. Just recently JavaScript had a small bit of that problem with WebUSB. See https://news.ycombinator.com/item?id=16501400 https://news.ycombinator.com/item?id=16501400 and https://news.ycombinator.com/item?id=17332340 https://news.ycombinator.com/item?id=17332340 In JavaScript at least, the browsers could change how the APIs respond to fix the issue. In the case of WebAssembly, I honestly do not know if they are able to shut down vulnerabilities as quickly. My understanding is that these binaries are similar to compiled apps that you can run directly on your desktop. Now it would seem that we would have to run virus scanners directly in our browser on every binary that wants to run. Am I be over reacting to all of this? Probably. But I would rather be overly cautious that be caught up in a exploit on a service that is not used much. I would prefer WebAssembly is treated in the same fashion as Flash until the standard has settled and it’s security is proven.
- geofft 8y ago
  > The problem lies with in the sandboxing model. Sandboxes work great in principle, except that more toys that get added, the harder it is for the sandbox to keep all of the sand in. That's not really a meaningful analogy: computer sandboxes don't overflow and burst, the way that physical sandboxes do. There's no way to over-stress them and cause them to fail under load. They can have holes, but those holes are equally accessible to everything inside the sandbox, whether it's a hundred gallons of water or a single stick pointing directly at the hole. The WebAssembly and JavaScript sandboxes are the same. In fact one of the current practical problems with WebAssembly as a general-purpose JS replacement (for the "I hate JS, I want to write in $language" use case) is that every interaction with the browser has to go through JS. The DOM API is exposed to JS. So WebAssembly is very slow unless you're using it for heavy computation or something that doesn't need much DOM interaction (e.g., a video game where you create a canvas, get a reference to it, and then draw on it without bothering JS any further). The WebUSB problem was an API that was exposed to the sandbox that shouldn't have been, and was exploitable with very little code. That is, the problem was not that too much was inside the sandbox; it's that people deliberately cut a hole in the sandbox and didn't quite think through the implications of it. > In JavaScript at least, the browsers could change how the APIs respond to fix the issue. In the case of WebAssembly, I honestly do not know if they are able to shut down vulnerabilities as quickly. They can shut them down in the same way. WebAssembly uses the JS APIs. > Now it would seem that we would have to run virus scanners directly in our browser on every binary that wants to run. Virus scanners are a fundamentally broken model of security; that's why we've moved to sandboxes. Sandboxes don't care what the app does, or how it does it. They certainly don't attempt to identify malicious code, the way an antivirus does. They just limit the capabilities of the environment in which the app runs. It doesn't matter what language the app is; if it doesn't have a "delete my files" API available to it (either intentionally or unintentionally), it can't delete your files. The worst that can happen is it can spend a lot of CPU being sad about not being able to delete your files... and you can just implement a CPU consumption limit, too. > I would prefer WebAssembly is treated in the same fashion as Flash until the standard has settled and it’s security is proven. The fundamental problem with Flash is that Flash was a different sandbox; it was a browser plugin, a piece of code that embedded itself directly into the browser itself and ran with full privileges on your desktop, that was expected to implement its own sandboxing. That sandboxing was designed by one company with a specific set of market pressures in favor of "ship cool things" and not as much in favor of "keep people secure", precisely because it was code running inside the browser that wasn't from the browser vendor. WebAssembly just reuses the existing JavaScript sandbox (both the model and the specific implementation), and the model of which APIs are accessible has been hardened over time via public review and standardized development. If you haven't heard the phrase "browser plugin" in a while (in favor of "browser extension"), it's because people realized that plugins were a fundamentally bad way of doing things, and we should instead focus our efforts on exposing cool new features incrementally to JavaScript and putting anything else we're excited about in the same sandbox as JavaScript. Occasionally there are mistakes in the sandbox model, like WebUSB. I am also sure that there will be mistakes in individual sandbox implementation that are somewhat easier to exploit with WebAssembly (but would probably still be exploitable with pure JS, just a little harder). That's why I think a paranoid browser for security nerds or high-risk people should have a way to disable it (and probably also a sandbox that excessively prioritizes safety over performance and correctness...). But I don't think as a general-purpose feature it's any different from JS.

carlosdp 8y ago

Webassembly is a runtime not a feature like location services, that would make as much sense as prompting the user for whether JS should be enabled every time a page loads. Webassembly is relatively new, but expect many websites to start implementing newer client front-ends in wasm as opposed to JS in the nearish future, at least partially. Disabling it would only make sense if you also intend to disable JS, which is your choice but just makes your life harder =P

TomMarius 8y ago
It could be phrased as a feature. "Enable high-performance computing for this website?"* or something like that. * I'm aware it's incorrect. It's just an illustrative example.
- skissane 8y ago
  The average user has no idea of the implications of answering "Yes" or "No", or the respective pros and cons of each option. One shouldn't ask people questions they have no hope of sensibly answering. Some highly technical users will have some idea of what the implications of each answer are, but for them you are better to use the proper name ("WebAssembly"), since then it will be much clearer what the question actually is asking about.
  - enzanki_ars 8y ago
    Browsers, except Chrome recently [1], will ask the user if they want to run Flash. I do not believe that most people even understand the risks Flash brings. [1]: Chrome stopped asking and won’t run Flash until they click though a couple menus to enable it. --- Edit: I just remembered that WebAssembly has JavaScript based polyfills. Disabling WebAssembly does not do me much good, as it will still run. No dialog can really stop that...
- geofft 8y ago
  Why would anyone ever say no to that, though? In order for a permission prompt to be meaningful, the tradeoff must be immediately obvious. For instance, "Allow this website/app to use your camera?" is a meaningful prompt. You might want it to use features involving taking photos; you might not want the site or app to see where you are. But what is the downside of high-performance computing? And how am I supposed to meaningfully evaluate (even as a security nerd!) "Allow high performance computing that might steal secrets from your machine?" Why would I ever say yes to that?

JoshTriplett 8y ago

People who feel the need to disable JavaScript entirely will wish to disable WebAssembly as well. But we're long past the point where it was reasonable for browsers to ask permission to run JavaScript on a case-by-case or site-by-site basis. If you want that, you should run an extension. Notable applications for WebAssembly include decoding or parsing various formats, implementing games or game engines, writing portable software that targets both native and HTML5/WASM (or porting software from other platforms), or just writing normal browser client code in a non-JavaScript language. While it certainly isn't as widespread as JavaScript yet, not least of which because browsers haven't supported it for nearly as long, I regularly run into sites using it.