7 ms·

The Risks of WebAssembly

66 points by 0xmohit 4y ago

lifthrasiir 4y ago
This should be linked to https://www.fermyon.com/blog/risks-of-webassembly https://www.fermyon.com/blog/risks-of-webassembly instead.
deleted 4y ago
[deleted]
syrusakbary 4y ago
> But we have been noticing an unfortunate trend that some developers have chosen to work contrary to the component model, creating strong links to their own host runtimes. Going this route results in platform lock-in on one hand, and the pointless re-authoring of the same code (tooled for slightly different hosts) on the other. Oh dear lord. This is such a twisted narrative. The Component Model is a proposal that is only supported by one runtime out of the 20 used in production, none of them in the browser (don't look for it in v8, SpiderMonkey or Javascript Core, Wazero, Wasmer, Wizard Engine, WAVM, ...). So if there's anything that actually locks you in... is probably that! Even when Wasmer tried to add support for it on wit-bindgen (precursor for the Component Model), the same people from the Bytecode Alliance who are working on the Component Model proposal rejected it [1]. Do they really want collaboration and not lock-in? One begins to wonder. It gets even more funny when you continue reading the article and you also realize that all people in the WasmDay committee that decides what get's in our out their CNCF conference are also part of the Bytecode Alliance. When the only competition they "cheer" is the one that comes from their approved friends. I would highly encourage everyone to read some of the practices of the Bytecode Alliance that the AssemblyScript community has redacted, it might be eye opening! [2] [1] https://github.com/bytecodealliance/wit-bindgen/issues/306 https://github.com/bytecodealliance/wit-bindgen/issues/306 [2] https://www.assemblyscript.org/standards-objections.html https://www.assemblyscript.org/standards-objections.html
- jillesvangurp 4y ago
  Ever since working in Nokia, I'm highly skeptical of standardization bodies being able to solve technical problems in a satisfying way. Companies use standardization bodies to play poker with their competitors. It's a complex game that involves patents, getting your pet proprietary features rubber stamped, and making sure you retain some inherent advantage over competitors. Above all, it's a very slow process. I saw Nokia play this game .. and lose. Apple and Google ignored several of the established standards to basically raise the bar and sideline the entrenched incumbents bickering over arcane details in those standards. Apple ignored MMS and most of other 3G features with the original iphone and it never became a feature any Apple user cared about. Google ignored things like J2ME. Other things they ignored were most of what operators were "standardizing" to prevent the internet being usable on their networks. All of that got shelved once Apple and Google allowed you to just use browser and internet based alternatives. Operators got demoted to routing IP packets around; the very thing they were trying to prevent by standardizing things that they controlled. The whole legacy business of charging per call minute or text message is completely dead at this point. They were trying to standardize that so they could keep the gravy train going. It failed. Not all standards are that bad of course. But resolving complex technical issues through a standardization body results in complicated solutions that are years/decades late to market and aren't necessarily very optimal. Standard bodies are very good at standardizing and normalizing the status quo though. Build something, get people to use it, and then standardize it so people can be assured about interoperability. This typically results in pragmatic standardized solutions. The more implementations are out there, the better. A lot of standards are so-called industry standards where a company or group of companies agree on doing things a certain way and then formalize their commitment by providing a specification. HTML5 is a good example. XHTML 1.0 is what happens when standards bodies go wrong. HTML5 happened because the W3C lost the plot at some point and got sucked down a path of writing/dictating increasingly less relevant standards in such a way that browser builders took it upon themselves to write a proper standard for what browsers were actually doing. Nokia was all over the W3C (I knew some people involved in various working groups). Since HTML5 happened then, things run a lot smoother on the web. WASM came out of that community and was moving relatively quickly because of that. From cute demos to being a not so visible but increasingly core part of the modern web in the space of a few years. Garbage collection to enable deep integration with e.g. the DOM in browsers, sockets to be able to do IO, threads to make better use of modern hardware are all things that are pretty fundamental to get right and they are happening. WASM isn't being standardized in a void. There are experimental flags in Chrome that you can turn on right now to explore the progress with these features. Firefox is not far behind. However, there is a worrying and growing amount of companies that are asserting themselves in the ByteCode Alliance. Too many conflicts of interest and political issues. Decision making must be getting quite hard. The way out is to move ahead with stuff that works and ask for forgiveness rather then permission. If enough people use it and it works, it will get standardized. Standardization comes at the end of that process, not at the beginning.
- Jasper_ 4y ago
  I am skeptical of WebAssembly and component-model myself, but that AssemblyScript page seems alarmist and as can be seen in several issues linked from that page, dcodeIO (from the AssemblyScript community) was definitely not behaving in good faith: https://github.com/w3ctag/design-principles/issues/322 https://github.com/w3ctag/design-principles/issues/322 It seems most of the complaints are that selecting UTF-8 as a primary string encoding is "against the practices of the web", which seems patently absurd, but also, just plain boring. I was definitely expecting more along the lines of incompatible object models integrating into component‐model, rather than mass-tagging people over string encodings.
  - zozbot234 4y ago
    > It seems most of the complaints are that selecting UTF-8 as a primary string encoding is "against the practices of the web" And by "against the practices of the web" they really mean against the practices of Java/JavaScript. But I thought that was the whole point of WASM?
  - syrusakbary 4y ago
    > dcodeIO (from the AssemblyScript community) was definitely not behaving in good faith I certainly disagree with that take. I don’t see any bad faith, I only see one person being frustrated because his concerns were being thrown under the rug as "non important", I would recommend you to read on dcode's blog to learn more about it [1]. There are always things to improve regarding how we communicate, of course, but those should not be used as a weapon to attack or dismiss someone but as means to improve. It's also important to note that a few months after, the Wasm committee realized of the mistake and actually tried to solve it with the Wasm Stringref proposal [2]. The way I see the issue is not about UTF-8 vs UTF-16 but about how valid concerns were completely dismissed in what's supposed to be an open community [1] https://dcode.io/#webassembly https://dcode.io/#webassembly [2] https://github.com/WebAssembly/stringref https://github.com/WebAssembly/stringref
    - Jasper_ 4y ago
      There are valid concerns to be had about string encodings, but I do not think a suggestion to "encourage UTF-8 for new formats and APIs" can be said to "literally breaking the Web Platform", nor does it require tagging 17 people, most of them unrelated, just because you happen to disagree the resolution of the committee.
vardump 4y ago
I just hope WASM doesn't become too complicated. Or that at least that the complicated bits are not mandatory.
fuzzc0re 4y ago
From my recent experience with WebAssembly developing a cryptographic library for Nodejs and the browser [1], I have to say that once someone needs to use memory allocation, typed arrays from JS to WASM (I did not manage to make the opposite work) etc. it quickly becomes obvious that there is lack of documentation and build system fragmentation that only hurts community growth IMO. If I was less motivated to finish the undertaking, I would just give up and go with libsodium-wrappers or tweetnacljs. I started with clang targeting wasm32-unknown-unknown-wasm as my build system but this just did not work with malloc/free, unless I was targeting WASI, but if I targeted WASI I would not be able to run the module in the browser except with a polyfill that was hard to set up with C/TS stack. I ended up with emscripten because it was importing the module with all the right helper functions but there I was getting memory errors on debug mode but not in production. I needed to pass the Uint8Arrays from JS to WASM in a very specific way (with HEAP8), otherwise the pointers were not working properly, but I was not able to find this in the documentation. I only found out from a stackoverflow comment somewhere after two weeks of brain melting (why would Uint8Array(memory.buffer, offset, len).byteOffset not work?). After I compiled the project successfully and the JS was giving the correct results, I decided to compile with -s SINGLE_FILE command in order to make the package as portable as possible, but this increased the size significantly because it translates the bytes into base64 that are then converted into WASM module from JS. A package manager of a compiled language that outputs cross-env JS that solves these problems automagically would be, IMO again, a game changer for the ecosystem. I believe this is what AssemblyScript tries to achieve but I honestly could not make it work for my project after experimenting with it for one or two days. I get that a lot of the problems come from the incompatibility of browser and Nodejs APIs and different agendas from the various stakeholders, but I would very much like to see these differences be reconciled so that we can have a good developer experience for cross-platform WASM modules, which will lead to more high-performance components for JS, which is a programming language that affects so many people. [1] https://github.com/deliberative/crypto https://github.com/deliberative/crypto
max_ 4y ago
What does one benefit from compiling and running microservices in WASM as opposed to running it in say Rust?
- yababa_y 4y ago
  you don’t run a service in rust, you compile, distribute, and run machine code on your cpu. compare to wasm where you compile to portable ISA and the runtime recompiles to real ISA. the wasm virtual environment is a gazillions of times simpler than a hardware context with all the attendant complexities.
  - hutzlibu 4y ago
    Yes, abstractions are simpler, but they are also slower. It depends what you need. (personally I am going to invest heavily in wasm)
- paulgb 4y ago
  - Strong isolation constructs. With WebAssembly, there's no access to the host system by default. Even something as simple as reading the system clock requires exposing the appropriate WASI API to the WASM module. - The ability to snapshot and later restore running state. - A cross-platform and language-agnostic way to distribute plugins (e.g. Envoy proxy allows loading WebAssembly modules as extensions)
  - pjmlp 4y ago
    A snapshot a running state of a bytecode based execution engine, where did I heard that before, https://en.wikipedia.org/wiki/Jini https://en.wikipedia.org/wiki/Jini https://dl.acm.org/doi/10.5555/867785 https://dl.acm.org/doi/10.5555/867785
    - nerpderp82 4y ago
      You can now build Jini and agent systems on top of the web!
- 4y ago
westurner 4y ago
Don't there need to be per- CPU/RAM/GPU quotas per WASM scope/tab? Or is preventing DOS with WASM out of scope for browsers? IIRC, it's possible to check resource utilization in e.g. a browser Task Manager, but there's no way to do `nice` or `docker --cpu-quota` or `systemd-nspawn --cpu-affinity` to prevent one or more WASM tabs from DOS'ing a workstation with non-costed operations. FWIU, e.g. eWASM has opcode costs in particles/gas: https://github.com/ewasm/design/blob/master/determining_wasm_gas_costs.md https://github.com/ewasm/design/blob/master/determining_wasm...
ilaksh 4y ago
Does anyone have a link to the web assembly component model, and is there any alternative? Maybe there can be some kind of universal device driver plugin or something. It's weird to me that there wasn't initially an organized effort to escape the web browser by coming up with some sort of UI system or ways to integrate other devices etc. Don't know if that has changed.
- lann 4y ago
  https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model

66 points by 0xmohit 4y ago

This should be linked to https://www.fermyon.com/blog/risks-of-webassembly https://www.fermyon.com/blog/risks-of-webassembly instead.

deleted 4y ago

[deleted]

syrusakbary 4y ago

> But we have been noticing an unfortunate trend that some developers have chosen to work contrary to the component model, creating strong links to their own host runtimes. Going this route results in platform lock-in on one hand, and the pointless re-authoring of the same code (tooled for slightly different hosts) on the other. Oh dear lord. This is such a twisted narrative. The Component Model is a proposal that is only supported by one runtime out of the 20 used in production, none of them in the browser (don't look for it in v8, SpiderMonkey or Javascript Core, Wazero, Wasmer, Wizard Engine, WAVM, ...). So if there's anything that actually locks you in... is probably that! Even when Wasmer tried to add support for it on wit-bindgen (precursor for the Component Model), the same people from the Bytecode Alliance who are working on the Component Model proposal rejected it [1]. Do they really want collaboration and not lock-in? One begins to wonder. It gets even more funny when you continue reading the article and you also realize that all people in the WasmDay committee that decides what get's in our out their CNCF conference are also part of the Bytecode Alliance. When the only competition they "cheer" is the one that comes from their approved friends. I would highly encourage everyone to read some of the practices of the Bytecode Alliance that the AssemblyScript community has redacted, it might be eye opening! [2] [1] https://github.com/bytecodealliance/wit-bindgen/issues/306 https://github.com/bytecodealliance/wit-bindgen/issues/306 [2] https://www.assemblyscript.org/standards-objections.html https://www.assemblyscript.org/standards-objections.html

jillesvangurp 4y ago
Ever since working in Nokia, I'm highly skeptical of standardization bodies being able to solve technical problems in a satisfying way. Companies use standardization bodies to play poker with their competitors. It's a complex game that involves patents, getting your pet proprietary features rubber stamped, and making sure you retain some inherent advantage over competitors. Above all, it's a very slow process. I saw Nokia play this game .. and lose. Apple and Google ignored several of the established standards to basically raise the bar and sideline the entrenched incumbents bickering over arcane details in those standards. Apple ignored MMS and most of other 3G features with the original iphone and it never became a feature any Apple user cared about. Google ignored things like J2ME. Other things they ignored were most of what operators were "standardizing" to prevent the internet being usable on their networks. All of that got shelved once Apple and Google allowed you to just use browser and internet based alternatives. Operators got demoted to routing IP packets around; the very thing they were trying to prevent by standardizing things that they controlled. The whole legacy business of charging per call minute or text message is completely dead at this point. They were trying to standardize that so they could keep the gravy train going. It failed. Not all standards are that bad of course. But resolving complex technical issues through a standardization body results in complicated solutions that are years/decades late to market and aren't necessarily very optimal. Standard bodies are very good at standardizing and normalizing the status quo though. Build something, get people to use it, and then standardize it so people can be assured about interoperability. This typically results in pragmatic standardized solutions. The more implementations are out there, the better. A lot of standards are so-called industry standards where a company or group of companies agree on doing things a certain way and then formalize their commitment by providing a specification. HTML5 is a good example. XHTML 1.0 is what happens when standards bodies go wrong. HTML5 happened because the W3C lost the plot at some point and got sucked down a path of writing/dictating increasingly less relevant standards in such a way that browser builders took it upon themselves to write a proper standard for what browsers were actually doing. Nokia was all over the W3C (I knew some people involved in various working groups). Since HTML5 happened then, things run a lot smoother on the web. WASM came out of that community and was moving relatively quickly because of that. From cute demos to being a not so visible but increasingly core part of the modern web in the space of a few years. Garbage collection to enable deep integration with e.g. the DOM in browsers, sockets to be able to do IO, threads to make better use of modern hardware are all things that are pretty fundamental to get right and they are happening. WASM isn't being standardized in a void. There are experimental flags in Chrome that you can turn on right now to explore the progress with these features. Firefox is not far behind. However, there is a worrying and growing amount of companies that are asserting themselves in the ByteCode Alliance. Too many conflicts of interest and political issues. Decision making must be getting quite hard. The way out is to move ahead with stuff that works and ask for forgiveness rather then permission. If enough people use it and it works, it will get standardized. Standardization comes at the end of that process, not at the beginning.
Jasper_ 4y ago
I am skeptical of WebAssembly and component-model myself, but that AssemblyScript page seems alarmist and as can be seen in several issues linked from that page, dcodeIO (from the AssemblyScript community) was definitely not behaving in good faith: https://github.com/w3ctag/design-principles/issues/322 https://github.com/w3ctag/design-principles/issues/322 It seems most of the complaints are that selecting UTF-8 as a primary string encoding is "against the practices of the web", which seems patently absurd, but also, just plain boring. I was definitely expecting more along the lines of incompatible object models integrating into component‐model, rather than mass-tagging people over string encodings.
- zozbot234 4y ago
  > It seems most of the complaints are that selecting UTF-8 as a primary string encoding is "against the practices of the web" And by "against the practices of the web" they really mean against the practices of Java/JavaScript. But I thought that was the whole point of WASM?
- syrusakbary 4y ago
  > dcodeIO (from the AssemblyScript community) was definitely not behaving in good faith I certainly disagree with that take. I don’t see any bad faith, I only see one person being frustrated because his concerns were being thrown under the rug as "non important", I would recommend you to read on dcode's blog to learn more about it [1]. There are always things to improve regarding how we communicate, of course, but those should not be used as a weapon to attack or dismiss someone but as means to improve. It's also important to note that a few months after, the Wasm committee realized of the mistake and actually tried to solve it with the Wasm Stringref proposal [2]. The way I see the issue is not about UTF-8 vs UTF-16 but about how valid concerns were completely dismissed in what's supposed to be an open community [1] https://dcode.io/#webassembly https://dcode.io/#webassembly [2] https://github.com/WebAssembly/stringref https://github.com/WebAssembly/stringref
  - Jasper_ 4y ago
    There are valid concerns to be had about string encodings, but I do not think a suggestion to "encourage UTF-8 for new formats and APIs" can be said to "literally breaking the Web Platform", nor does it require tagging 17 people, most of them unrelated, just because you happen to disagree the resolution of the committee.

vardump 4y ago

I just hope WASM doesn't become too complicated. Or that at least that the complicated bits are not mandatory.

fuzzc0re 4y ago

From my recent experience with WebAssembly developing a cryptographic library for Nodejs and the browser [1], I have to say that once someone needs to use memory allocation, typed arrays from JS to WASM (I did not manage to make the opposite work) etc. it quickly becomes obvious that there is lack of documentation and build system fragmentation that only hurts community growth IMO. If I was less motivated to finish the undertaking, I would just give up and go with libsodium-wrappers or tweetnacljs. I started with clang targeting wasm32-unknown-unknown-wasm as my build system but this just did not work with malloc/free, unless I was targeting WASI, but if I targeted WASI I would not be able to run the module in the browser except with a polyfill that was hard to set up with C/TS stack. I ended up with emscripten because it was importing the module with all the right helper functions but there I was getting memory errors on debug mode but not in production. I needed to pass the Uint8Arrays from JS to WASM in a very specific way (with HEAP8), otherwise the pointers were not working properly, but I was not able to find this in the documentation. I only found out from a stackoverflow comment somewhere after two weeks of brain melting (why would Uint8Array(memory.buffer, offset, len).byteOffset not work?). After I compiled the project successfully and the JS was giving the correct results, I decided to compile with -s SINGLE_FILE command in order to make the package as portable as possible, but this increased the size significantly because it translates the bytes into base64 that are then converted into WASM module from JS. A package manager of a compiled language that outputs cross-env JS that solves these problems automagically would be, IMO again, a game changer for the ecosystem. I believe this is what AssemblyScript tries to achieve but I honestly could not make it work for my project after experimenting with it for one or two days. I get that a lot of the problems come from the incompatibility of browser and Nodejs APIs and different agendas from the various stakeholders, but I would very much like to see these differences be reconciled so that we can have a good developer experience for cross-platform WASM modules, which will lead to more high-performance components for JS, which is a programming language that affects so many people. [1] https://github.com/deliberative/crypto https://github.com/deliberative/crypto

max_ 4y ago

What does one benefit from compiling and running microservices in WASM as opposed to running it in say Rust?

yababa_y 4y ago
you don’t run a service in rust, you compile, distribute, and run machine code on your cpu. compare to wasm where you compile to portable ISA and the runtime recompiles to real ISA. the wasm virtual environment is a gazillions of times simpler than a hardware context with all the attendant complexities.
- hutzlibu 4y ago
  Yes, abstractions are simpler, but they are also slower. It depends what you need. (personally I am going to invest heavily in wasm)
paulgb 4y ago
- Strong isolation constructs. With WebAssembly, there's no access to the host system by default. Even something as simple as reading the system clock requires exposing the appropriate WASI API to the WASM module. - The ability to snapshot and later restore running state. - A cross-platform and language-agnostic way to distribute plugins (e.g. Envoy proxy allows loading WebAssembly modules as extensions)
- pjmlp 4y ago
  A snapshot a running state of a bytecode based execution engine, where did I heard that before, https://en.wikipedia.org/wiki/Jini https://en.wikipedia.org/wiki/Jini https://dl.acm.org/doi/10.5555/867785 https://dl.acm.org/doi/10.5555/867785
  - nerpderp82 4y ago
    You can now build Jini and agent systems on top of the web!
4y ago

westurner 4y ago

Don't there need to be per- CPU/RAM/GPU quotas per WASM scope/tab? Or is preventing DOS with WASM out of scope for browsers? IIRC, it's possible to check resource utilization in e.g. a browser Task Manager, but there's no way to do `nice` or `docker --cpu-quota` or `systemd-nspawn --cpu-affinity` to prevent one or more WASM tabs from DOS'ing a workstation with non-costed operations. FWIU, e.g. eWASM has opcode costs in particles/gas: https://github.com/ewasm/design/blob/master/determining_wasm_gas_costs.md https://github.com/ewasm/design/blob/master/determining_wasm...

ilaksh 4y ago

Does anyone have a link to the web assembly component model, and is there any alternative? Maybe there can be some kind of universal device driver plugin or something. It's weird to me that there wasn't initially an organized effort to escape the web browser by coming up with some sort of UI system or ways to integrate other devices etc. Don't know if that has changed.

lann 4y ago
https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model