Four go wild for wasm: Corporate quartet come together to build safe WebAssembly sandbox On Tuesday Fastly, Intel, Mozilla, and Red Hat teamed up to form the Bytecode Alliance, an industry group intent on making WebAssembly work more consistently and securely outside of web browsers. WebAssembly is a form of low-level bytecode that can be created by passing code in higher-level languages, like C/C++ and Rust, …
Not convinced of the need for this tech.
Wasm allows delivering code the browser that is a bugger to decompile, unlike obfuscated javascript. I suspect there is a niche there for the technology.
Does not work on our Android platform which prevents its deployment where I work.
JavaScript is generally fast enough for browser work and you can write lower level langs for apps. Anyone know if in browser gaming is a big thing? I cant imagine it is: given the app market.
Bitcoin miners wil probably like it :)
Perhaps someone could write a flash replacement that compiles to wasm and is faster than html5? I dont realy see the benefit over writing native rust in the datacenter.
"I agree I don't really see much need for WASM outside the browser"
For a real world example outside the browser you can see the implementation of EOS blockchain (https://github.com/EOSIO/eos). The blockchain (coded in native C++17) has a webassembly virtual machine in which the smart contracts run. The smart contracts are written in standard C++17. The compiler is clang 8 that targets wasm (see the SDK: https://github.com/EOSIO/eosio.cdt). The upcoming EOS 2.0 will feature a new optimized wasm VM (12x faster than binarygen, 6x faster than WABT).
So we have byte-code, machine code for a virtual machine, that can be interpreted by S/W because it's easier to sandbox the interpreter than real machine code running on real hardware. And then somebody comes along to compile the byte-code to the H/W machine code or builds a H/W implementation of the byte-code machine, all to speed up execution.
And then someone finds a way to optimise those hardware implementations with branch prediction, shared caches and out-of-order execution which undo all of the assumptions on which the original sandbox was predicated.
I can see the virtue in being able to compile the byte-code with knowledge of the flaws in the underlying hardware so that you can take account of those flaws as they are discovered without changing the "source", but it seems a poor way to compensate for the fact that contemporary processors don't have the right architecture to adequately sandbox untrusted code in the first place.
It might make a little sense to use a Java JIT but without a ton of libraries that are difficult to use and secure. Adoption would be much easier than a new start. The downside is that Java still sucks at certain types of data crunching due to lack of contiguous structure allocation and native support for selecting signed or unsigned integer math. Graphics rendering and codecs seems like something browser apps would want to do. It's definitely possible in Java, but the extra array math and bit shuffling is the last thing you want added to algorithms that are already complex.
Read about WASM as much as you can. It is the future of mobile devices. Look at this bit from the article:
"Without Apple, Google, and Microsoft on board yet, it's difficult to guess whether wasm will soar or sink for lack of support."
They all make proprietary mobile operating systems, or pretend they are open source, or failed to make a dent in the market. They know that a micro-environment is a replacement for their OS. And WASM is safer than the dominant mobile device makers telling us they are policing their app stores.
"WASM is safer than the dominant mobile device makers telling us they are policing their app stores."
Why is this? Surely what you police in an app is that the application is not accessing resources it is not meant to, e.g. camera, or call logs or location. I don't see that WASM helps with that? If an app is to be of use it needs access to these features, inc a WASM based app, someone needs to police how and when. In terms of sandboxing I don't think mobiles have a particular problem do they? I think most policing of the app stores is at least nominally to ensure quality of the applications features and logic not the quality or security of the code.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
