The Risks of WebAssembly
fermyon.com
fermyon.com
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
[2] https://www.assemblyscript.org/standards-objections.html
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.
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
Perhaps you don’t see it that way, but we have to respect when others do.
From the way I understand things, because JS strings (DOMString [1]) are already represented as UTF-16/WTF-16 internally, making the component model strings only UTF-8 puts certain languages in disadvantage against others specially regarding speed (because they’ll need to do extra effort when processing strings in order to be fully compliant, while the UTF-8 ones wouldn’t need to do it). This was the case for AssemblyScript, Javascript, Java and other JVM-related languages (Kotlin, Scala, ...).
Specifically for a language such as AssemblyScript, for which its aim is to be completely complaint with JS, tiny and fast to execute I can certainly understand why that was a concern and why being dismissed could cause certain frustration.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Since some languages use UTF-8 and some use UTF-16 you're always going to have some languages doing conversions so it makes sense just to pick the best option surely?
That's why, in such mixed systems, https://simonsapin.github.io/wtf-8/ is typically used. Not UTF-8. And Wasm is such a mixed system.
FWIW, here's the presentation I wanted to give to the Wasm CG that explains the details and pitfalls in an easier to digest way: https://www.youtube.com/watch?v=Ri2NMnSQo4o
It's fine to disagree with me or the committee, but your grand gesturing and your overstatements about how tightening a single bolt on strings will break web compatibility forever is exhausting to listen to, especially when you claim large-scale political conspiracy and use words like "fundamentally incompatible with JavaScript". I don't see any of it.
Your behavior in those threads are absurd, unnecessary, and alarmist, and I really don't have any sympathy for you. Even this reply doubles down on the over-exaggeration.
I think large parts of WebAssembly are mismanaged. I have major complaints about the velocity, instability, and web APIs, I spend a lot of time in them, I'm grumpy, and I'm not usually one to go to bat for any of this. Even within the WebAssembly/JavaScript/WASI interop, there are 20 things I'd put on the list ahead of this. If I have any advice for you, it's to pick a new battle, because this is maybe this is the highest complaint to lowest impact ratio I've ever seen. You lost, just move on.
The problem is when you say things like people that prefer the latter approach "can only be either dishonest, or incompetent". Putting it kindly, you're basically only making enemies at that point, and you seem unwilling to consider other points of view, at best. You seem absolutely baffled about why your tone, phrasing, and language are making others uncomfortable, even as you continue to insult those you're trying to influence.
I have never met you before this conversation, and I came away with a very negative impression. There are reasons you aren't being listened to, and they are problems with you and your behavior, not grand conspiracies.
There are battles worth staking your entire professional reputation over -- the GC repo is full of people doing that -- but this is definitely not one of them.
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?
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.
Eh, that's sure one way to describe the situation. Another one being that it's only Chrome left. Sure, W3C completely and utterly fucked up, but I thought we were beyond regurgitating 2009ish "HTML5 rocks" propaganda and genesis myths.
I remember having to deal with xhtml, html 4, Netscape, Opera, Internet Explorer, etc. a world of pain.
Even by 2009, things were already massively improved (with the exception of IE of course). WhatWg was founded in 2004 and that's when work started on HTML5. That's before Chrome was a thing. That didn't happen until 2008 and would have not been possible without decent specifications provided by WhatWg. Apple and Mozilla were working together on that one.
Chrome happened because of HTML 5; not the other way around.
FWIW, that mirrors my experience entirely. i primarily develop with FF and test with Chrome/Chromium as a sanity check. Safari, once the app is out the wild, is always the outlier (and i don't use it, so can't fix its shortcomings except via trial and error).
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.
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.
- 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)
Another thing WASM adds is cross language calling capabilities, i.e. calling Rust code from Go in a standard way. All methods are hidden behind a severely limited runtime interface so all have to comply with the respective standards.
This all comes at the cost of performance and efficiency just like on the regular "cloud".
Individually, you'll have a much easier time running your payload on bare metal, especially if you write code in a language that doesn't already compile to bytecode or gets interpreted and JIT'ed.
In a multi tenant system, the free sandbox means you'll have rather little work to safely run arbitrary payloads. If they can get enough customers, they'll be able to provide services cheaper by leveraging their economy of scale and low cost security mechanisms.
A WASM executable can do nothing but allocate memory and change the contents of such memory. There's no I/O, no socket state machines, no kernel communication, it's all just numbers in, numbers out. Even something "simple" like entering a string into a WASM program involves treating that string as arbitrary memory to be operated on by the WASM runtime and things like structs, pointers and classes must go through several layers of abstraction before they can be used.
From this numbers-in-numbers-out mechanism further standards are currently evolving, standards that allow exposing callbacks and other such APIs into the WASM code. There's still an abstraction layer between the two, but the runtime can now allow the code to do a bit more.
I'm not too fond of the way these APIs are turning WASM into "Java but Javascript" but it's still good to see the security first approach to WASM runtimes that won't allow the code to do anything they don't provide rather than to allow everything except for a subset of functionality. The default model of modern operating systems is "you have all permissions, except these" rather than "you have these permissions and may ask for more". Trying to use seccomp and syscall filtering in Linux is a terrible experience because it's hard to know for sure that you've set up every possible limit you can in order to neuter exploits.
To see the benefit of this approach, look at the sandboxing in mobile operating systems like Android. Earlier permissions weren't a good fit for application developers and over time they've evolved. Google has had to patch in more and more limitations to prevent malicious behaviour like tracking (except for their own tracking, because Google). They've lifted some restrictions, like the INTERNET permission being granted by default in practice, but most of their API changes have been centered around taking away application functionality and providing a more restricted alternative.
Now, I very much like the option to root my phone and do whatever the hell I want on it, but I don't want the random crap the local weather app's advertisers try to force down my throat to have too much of an impact on my phone.
Personally, I tend to install PWA versions of web apps rather than download stuff from the Play Store if I can because I don't want these websites to have that much access to my phone (and often they're just wrappers around websites anyway).
With WASM, C's problematic memory management isn't as much of a problem. Your program can crash, show weird text, do anything weird you can think of, but it can't jump to kernel mode or escape the sandbox without a very significant flaw in the runtime whitelisting code. Redirect the control flow of a WASM program that can only serve web pages and control the files in two specific paths and you're practically nowhere. You can probably read some files but there isn't even a guarantee that you can upload the contents of the database anywhere, because networking is opt-in!
For most people in most cases I would very much prefer to keep running on bare metal myself. Safe programming languages are great and much more capable of being optimized because WASM itself is two compatibility hacks stacked on top of a Javascript library; it'll take a while for the format to be competitive and even then it won't compete with Rust in terms of performance.
However, the inexplicable urge to move to vendor lock-in through stuff like Amazon Lambda and the mistaken idea that every application needs the complexity of Kubernetes for some reason are undeniable. Within these contexts, I can see the benefits of what WASM people are trying to achieve.
Android for example runs everything as a separate user with very restricted abilities, and require IPC for any “elevated permission” operations, which are checked by a separate daemon process before being allowed on its behalf.
And I think heap corruptions should not be taken lightly - I was thinking that you mostly mean server processes before, as in these cases a memory corruption can lead to exposing other user’s data, which is a huge step back from the predominantly used Java/C#/etc backends. The concept of well-defined failure is very important and for example a Java program will never get into such an undecidable state an “unsafe” language can.
(personally I am going to invest heavily in wasm)
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...