Java: Getting Back to the Browser?
Remember applets? Remember them going away? Well, Java is attempting to make it back into the browser with WebAssembly. Is this a good thing?
Join the DZone community and get the full member experience.Join For Free
This article talks about WebAssembly and can be read to get the first glimpse of it. At the same time, I articulate my opinion and doubts. The summary is that WebAssembly is an interesting approach and we will see what it will become.
Keep in mind: Betteridge's law of headlines apply.
asm.js. But still, it is a high level, object-oriented, memory-managed language. It is nothing like machine code.
(Derail: Somebody told me that he has an advanced compression algorithm that can compress any file into one bit. There is no issue with the compression. Decompression is problematic though.)
Why can't we have some bytecode-based virtual machine in the browser? Something that the JVM was for applets. This is something that the WebAssembly people were thinking in 2015.
The assembly code is really assembly. When I started to play with it, I had some nostalgic feeling. Working with these hex codes is similar to programming the Sinclair ZX80 in Z80 assembly when we had to convert the code manually to hex on paper and then we had to "POKE" the codes from BASIC to the memory. (If you understand what I am talking about, you are seasoned. I wanted to write 'old,' but my editor told me that is rude. I am just kidding. I have no editor.)
I will not list all the features of the language. If you are interested, visit the WebAssembly page. There is a consumable documentation about the binary format.
There are, however, some interesting features that I want to talk about to later express my opinions.
The WebAssembly VM is not an object-oriented VM. It does not know objects, classes, or any similar high-level structures. It really looks like some machine language. It has some primitive types, like i32, i64, f32, and f64 — and that is it. The compiler that compiles high-level language has to use these.
The memory management is also up to the application. It is assembly. There is no garbage collector. The code works on a (virtually) continuous memory segment that can grow or shrink via system call, and it is totally up to the application to decide which code fragment uses which memory address.
There are two stacks the VM works with. One is the operation stack for arithmetic operations. The other one is the call stack. There are functions that can call each other and return to the caller. The call sequence is stored in a stack. This is a very usual approach. The only shortage is that there is no possibility to mark the call stack and purge it when an exception happens. The only possibility to handle a try/catch programming structure is to generate code before and after function calls that check for exception conditions — and if the exception is not caught on the caller function level, then the code has to return to the higher-level caller. This way, the exception handling walks through the call stack with the extra generated code around each function call. This slows down not only the exception handling but also the function calls.
There is no threading in WebAssembly.
The fact that most of the browsers support WebAssembly is only half the solution. There have to be developer tools supporting the concept to have code that can be executed.
There is an LLVM-backed compiler solution, so technically any language that is compiled to LLVM should be compilable to WebAssembly and run in the browser. There is a C compiler in the tooling, and you can also compile RUST to WebAssembly. There is also a textual format in case you want to program directly at the assembly level.
Security is at least questionable. First of all, WebAssembly is binary, therefore it is not possible, or at least complex, to look at and analyze the code. The download of the code does not require channel encryption (TLS), therefore it is vulnerable to MITM attack. Similarly, WebAssembly does not support code signatures that would assert that the code was not tampered with since being generated in the (hopefully protected) development environment.
You can read more on the security questions in this article.
WebAssembly was developed for to years to reach a Minimal Viable Product (MVP) that can be used as a PoC. There are features like garbage collection, multi-thread support, exception handling support, SIMD type instructions, and DOM access support directly from WebAssembly, which are developed after MVP.
I can say after playing with WebAssembly over the course of a weekend that it is an interesting and nice toy. But in its current state, it is a toy, nothing more. Without the features planned after MVP, I see only one viable use case: WebAssembly is the perfect tool to deploy malicious mining code on client machines. In addition to that, any implementation flaw in the engine is a security risk. Note that these security risks come from a browser functionality that gives no value to the average user. You can disable WebAssembly in some browsers. It is a little worrisome that it is enabled by default, although it is needed only for early adopters for PoC and not commercial projects. If I were paranoid, I would say that the browser vendors, like Google, have a hidden agenda with the WebAssembly engine in the browser.
I am afraid that we see no security issues currently with WebAssembly only because the technology is new and IT felons have not learned the tools yet. I am almost certain that the security holes are currently lurking in the current code waiting to be exploited. Disable WebAssembly in your browser until you want to use it. Perhaps in a few years (or decades).
But not yet.
Published at DZone with permission of Peter Verhas, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.