back to article 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, …

  1. Solarflare

    The rest of the article aside...

    "...and another called strong_password v0.0.7 that was hijacked"

    People trusted a package called "strong_password" that was on version 0.0.7??

  2. teknopaul Silver badge

    closed source

    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.

    1. iron Silver badge

      Re: closed source

      I agree I don't really see much need for WASM outside the browser but I'm surprised you find it difficult to debug, especially versus the black box that is Javascript. Personally I find WASM much easier to write and debug than JS.

      1. chololennon
        Linux

        Re: closed source

        "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).

        1. Solarflare
          Angel

          Re: closed source

          So nothing of any use, then?

          1. teknopaul Silver badge

            Re: closed source

            hehe but joking aside, whats the real purpose wasm in this use case over C++ compiled to native code? Is it to sandbox the "smart contracts"?

    2. Mellipop

      Re: closed source

      WASM is a back end and has many front ends. Including Flash.

      https://medium.com/leaningtech/preserving-flash-content-with-webassembly-done-right-eb6838b7e36f

  3. Doctor Syntax Silver badge

    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.

    1. Will Godfrey Silver badge

      Yes. That bit did seem a bit daft.

    2. Warm Braw Silver badge

      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.

  4. EnviableOne Silver badge

    so Java v2.0 ?

    1. Kevin McMurtrie Silver badge

      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.

  5. Mellipop

    It's a new ecosystem

    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.

    1. teknopaul Silver badge

      Re: It's a new ecosystem

      "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.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019