It seems a little unlikely that the browser manufacturers would enable threads in wasm without (being comfortable with) re-enabling SharedArrayBuffers in JS.
WebAssembly isn't some outside force, it's basically the same people working on WebAssembly integration and what JS features are permitted in browsers. I think they know that these are the same in terms of security risk.
Use of SharedArrayBuffer in timing attacks was widely predicted and there were working examples showing how it could be used to extract information from browsers long before vendors enabled it by default. It's hard to have faith that the people who ignored all those risks won't do so again.
It would be an existential crisis for several of the browser vendors if they can't add things like threads with shared memory to javascript/webassembly. The existence of those organisations is based on the idea of the browser being a replacement for native platforms, and if they can't include basic and vital features like threads then they will always be at a huge disadvantage to native platforms.
Do you think Mozilla will admit the entire browser-as-platform project is flawed and disband the organisation? Or will they push ahead with these new features despite the risks?
Mozilla is the same organization behind Rust. "Unsteuctured shared-memory concurrency is inherently unsafe, and also not necessary for performance; here's how some structure permits a compiler to make it safe" would be a huge ideological win for certain parts of the company.
(Also, meanwhile, none of the native platforms that Mozilla is trying to replace have disabled threads.... so by that standard, Mozilla is already miles more credible here.)
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.
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)?
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.
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.
> 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 ...
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
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.
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...
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?
Everyone knows that anything high performance kills battery, or they will the effect right after they enable it and choose accordingly next time. If they're on laptops or mobile and a simple news page asks them that to mine crypto (assuming that it's not going to be usual at least for a few next years), it's fishy and they're not going to allow it.
> Everyone knows that anything high performance kills battery
Not everyone is on a battery-powered device, and also, it's often true that "high performance" means "it completes faster and therefore spends less energy." Certainly if saying no often triggers a polyfill in actual web apps, people will quickly learn that high performance means less battery.
Agree about news pages but I wish we'd prevent them from using any serious amount of CPU, whether in wasm or JS.
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.
18 comments
[ 3.2 ms ] story [ 46.9 ms ] threadWebAssembly isn't some outside force, it's basically the same people working on WebAssembly integration and what JS features are permitted in browsers. I think they know that these are the same in terms of security risk.
It would be an existential crisis for several of the browser vendors if they can't add things like threads with shared memory to javascript/webassembly. The existence of those organisations is based on the idea of the browser being a replacement for native platforms, and if they can't include basic and vital features like threads then they will always be at a huge disadvantage to native platforms.
Do you think Mozilla will admit the entire browser-as-platform project is flawed and disband the organisation? Or will they push ahead with these new features despite the risks?
(Also, meanwhile, none of the native platforms that Mozilla is trying to replace have disabled threads.... so by that standard, Mozilla is already miles more credible here.)
---
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/m...
Seems like disabling the feature is a difficult task in all browsers that have WebAssembly except Firefox.
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)?
---
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 and 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.
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 ...
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
* I'm aware it's incorrect. It's just an illustrative example.
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.
[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...
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?
Not everyone is on a battery-powered device, and also, it's often true that "high performance" means "it completes faster and therefore spends less energy." Certainly if saying no often triggers a polyfill in actual web apps, people will quickly learn that high performance means less battery.
Agree about news pages but I wish we'd prevent them from using any serious amount of CPU, whether in wasm or JS.
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.