back to article Aw, all grown up: Mozilla moves WebAssembly into sparsely furnished Studio apartment

Mozilla has released a preview version of WebAssembly Studio, its browser-based integrated development environment (IDE) for creating code touted to be the future of internet software. WebAssembly is a low-level assembly language that can be written as text (.wat) and converted to binary (.wasm) or can be a compilation target …

  1. Anonymous Coward
    Anonymous Coward

    May be a real step towards better web applications, fingers crossed

    Based on the intended operation of the sand-boxing and profiling features this will have benefits beyond speed/performance enhancements. It does not resolve issues with the rest of the HTML/Browser/JavaScript Engine/plugin stack, but it may allow migration of features from less protected parts of the stack to the webassembly system to harden them up.

    Still, it looks like a minimum of the DOM/Javascript/Webassembly to use it, so still a TON of attack surface and complexity vs a native application + updater.

    1. AMBxx Silver badge

      Re: May be a real step towards better web applications, fingers crossed

      Or a step back to the bad old days of ActiveX.

      Time will tell.

  2. Bob Ajob

    Hypervisor?

    What are the major functional differences between running native assembly code in a browser and running it on any other application, say something like Virtualbox? Any application that lets you run binary executables on a virtual machine inside your current OS is just another hypervisor. If the VM guest ever has any access to the host hypervisor then it may be possible to exploit that and escape the sandbox. A bit like the hidden OS that runs in microcode on your CPU with privilege levels below zero...

    1. Anonymous Coward
      Anonymous Coward

      Re: Hypervisor?

      http://wiki.c2.com/?TheKenThompsonHack

      Paranoid much?

    2. thames

      Re: Hypervisor?

      WebAssembly isn't a binary executable. It's a language which the browser runs through it's normal JIT compiler before executing it. It is fundamentally no different from how all major web browsers currently run Javascript, except the browser doesn't have to do as much parsing before being able to use it.

      To put it in simple terms, it's a development of Mozilla's ASM.js. ASM.js is a subset of Javascript which browsers can more easily analyse in order to execute it efficiently. It does this largely by jettisoning the dynamic features of Javascript in favour of using only those features which can be subjected to static analysis (everything can be resolved at compile time, nothing about how to run it has to be figured out at run time). As a result, C and C++ programs can be compiled to this subset of Javascript, which is then sent to the web browser to go through its normal parse, interpret, optimise, JIT compile phases.

      WebAssembly is simply a more low level representation of the same sort of compiler output code that is ASM.js. It's not native executable code, but it does cut out a number of steps in the parse and JIT compile process. That means the web browser has to do less work before running the resulting code. Every web browser already had something analogous to WebAssembly in its Javascript compiler subsystem. However each browser had a different one with a different representation which wasn't compatible with how every other browser did it. WebAssembly provides a standard intermediate representation which is implemented in a compatible manner by every vendor.

      Now instead of sending a browser normal Javascript source code (which may itself be the output of a compiler), they send WebAssembly and can cut out some of the intermediate steps. How the web browser handles it from there is up to each vendor. It could be interpreted, it could be JIT compiled immediately, or whatever. This should be chip architecture independent by the way.

      Sending native x86 binaries over the web to execute in a sandbox on the other hand is what Google Chrome did with NaCl. That went over with developers like a lead balloon, and Google pulled the life support on it last year in favour of joining Mozilla in using WebAssembly.

      1. Charles 9 Silver badge

        Re: Hypervisor?

        "Sending native x86 binaries over the web to execute in a sandbox on the other hand is what Google Chrome did with NaCl. That went over with developers like a lead balloon, and Google pulled the life support on it last year in favour of joining Mozilla in using WebAssembly."

        Because Google's strongest platform, Android, runs on ARM, as does Apple's iOS the #2 mobile platform.

        1. thames

          Re: Hypervisor?

          @Charles 9 said: "Because Google's strongest platform, Android, runs on ARM, as does Apple's iOS the #2 mobile platform."

          Google's response to that was PNaCl, which was supposed to be a portable form of NaCl based on LLVM intermediate code. That wasn't any more successful because LLVM intermediate code isn't really suited to that.

          By that point everyone had decided that ASM.js was a much better solution from a technical and practical perspective so Google threw in their (P)NaCl cards.

    3. A Non e-mouse Silver badge
      Coat

      Re: Hypervisor?

      It's turtles all the way down...

      1. vtcodger Silver badge

        Re: Hypervisor?

        I'm not worried much about the turtles under me. The turtles I am under worry me a bit at times.

  3. tp2

    my view to webassembly

    check http://meshpage.org

    it has some wasm modules for opengl stuff

  4. vtcodger Silver badge

    Insecure by design

    Pretty much everyone acknowledges that there are widespread and serious security problems with computers and especially with computers attached to the internet. Our response is to continually expand our internet attack surface by adding stuff like Web Assembly. Is that really a good idea?

    1. Charles 9 Silver badge

      Re: Insecure by design

      Pretty much everyone acknowledges that there will always be a need for speed. Code efficiency has driven computing technology from its beginnings and will never go away. In a decision between fast and right, fast wins because you can BS a wrong answer but can't BS a missed deadline.

  5. steelpillow Silver badge
    Trollface

    Sandboxing

    Why don't we pour EVERYTHING into the sandbox? Stand up the whole OS, add a hardware virtualization layer, give it its own non-volatile memory allocation and stuff. You could then boot straight into the browser on a secure platform architecture.

    Oh, wait...

    1. Charles 9 Silver badge

      Re: Sandboxing

      Java uses sandboxed, recall? And code's been able to ESCAPE the sandbox. It's like a hypervisor attack. As long as a way to communicate exists, there will likely be a way to exploit it to escape.

  6. Lee D Silver badge

    WebAssembly is great.

    But I wouldn't want to code inside a browser IDE... for a start, once you start a project you can't close it or start another (that I could see!) - and I'd worry about what's being saved where.

    But WebAssembly is amazing - you can do things like pull an old C99/SDL/OpenGL project out of the woodwork, tweak it minimally, and run it through a compiler like emscripten to generate a web page that just runs it. Graphics, fonts, sound, network, 3D, etc. all work within the browser environment, using just a standard webpage and the browser abilities.

    Sure, it applies the browser security to it (so you have to break out a websockets proxy to send actual packets over the network, but that's no big deal for internal projects, and actually what you want for anything else), and you have to tweak little things but I find it amazing that you can go from pointer-manipulation-based low-level language with decades of libraries accessing all kinds of hardware, run it through a compiler and come up with something that loads in a HTML/Javascript page on a modern browser and runs more than fast enough to be useful.

    In fact, since using such things myself, I can't understand why people are bothering with desktop applications for anything other than high-end, performance-critical things any more. You can do Sketchup in a browser, you can play games in a browser, you can watch movies in a browser, you can code business apps in a browser, etc. For the end-user experience, there's no reason that your code can't be brought across to the web even if it was written before that era.

    Honestly, if I was a business requiring an in-house app nowadays, I'd just give people Chromebooks and locked-down browsers and a programmed interface using something like WebAssembly.

    1. PerlyKing

      Re: SketchUp in a browser

      @Lee D, having moved from the SketchUp desktop app to SketchUp in the browser, there's still some work to do. Partly on performance, because in the browser it's noticeably laggy, and partly on experience because opening and saving files is much more painful.

  7. jelleebean

    Fun naming files

    This is purely childish but I am looking forward to naming a .wat file to t.wat

    1. Robigus

      Re: Fun naming files

      and a TypeScript file to ti.ts?

  8. Robigus
    Pint

    Ooh look

    TypeScript too.

    Jolly good.

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