Microsoft joins Bytecode Alliance to advance WebAssembly – aka the thing that lets you run compiled C/C++/Rust code in browsers
- Reference: 1619614809
- News link: https://www.theregister.co.uk/2021/04/28/microsoft_bytecode_alliance/
- Source link:
The gang has also added six more member organizations to advance its mission to make software more modular, secure, and fast.
In addition to Microsoft, the new members are: Arm, DFINITY Foundation, Embark Studios, Google, Shopify, and University of California San Diego.
[1]
In a statement, Bobby Holley, distinguished engineer at Mozilla and a Bytecode Alliance board member, described software development today as a set of vexing trade-offs.
"If you want to build something big, it’s not realistic to build each component from scratch," Holley said. "But relying on a complex supply chain of components from other parties allows a defect anywhere in that chain to compromise the security and stability of the entire program.
"Tools like containers can provide some degree of isolation, but they add substantial overhead and are impractical to use at per-supplier granularity. And all of these dynamics entrench the advantages of big companies with the resources to carefully manage and audit their supply chains."
'It's where the industry is heading': LibreOffice team working on WebAssembly port [2]READ MORE
The [3]Bytecode Alliance , founded [4]in 2019 , sees WebAssembly as a way to make code composable, safe, and speedy without sacrifices.
WebAssembly is a low-level byte code generated by higher level languages like C/C++ or better yet, because of its memory safety, Rust. It's an assembly-like programming language or [5]structured stack machine , as opposed to a general stack machine like the JVM.
As a compilation target for higher level code, WebAssembly or wasm libraries are often added to web-based applications to handle computationally intensive operations.
[6]
Feross Aboukhadijeh, an open-source developer and co-creator of [7]Wormhole , told The Register in an email that WebAssembly has two main benefits.
"WebAssembly allows developers to take existing C and C++ codebases and run them on the web, with little to no modifications," said Aboukhadijeh. "This is great for reusing old code like ffmpeg — it means it doesn’t need to be rewritten in JavaScript."
"WebAssembly also allows performance-critical components to be written in Rust and then run with near-native performance. WebAssembly can perform faster or more predictably than JavaScript since it’s lower level."
Code for the future
The Bytecode Alliance sees WebAssembly, and various related code infrastructure projects like [8]WebAssembly System Interface (WASI) , WebAssembly Micro Runtime (WAMR), and Lucet, as a way to deal with difficult-to-secure package registries like npm, PyPI, and crates.io that form the foundation of modern software development.
[9]The JavaScript ecosystem is 'hopelessly fragmented'... so here is another runtime: Deno is now a company
[10]Internet Archive to preserve Flash content for posterity with Ruffle emulator
[11]Your web browser running remotely in Cloudflare's cloud. That's it. That's the story
[12]The W3C steers the way the World Wide Web works. Yet it is reluctant to record crucial meetings – and its minutes are incomplete
Package registries are essentially databases of previously written code that developers can import into their own projects so they don't have to solve problems already solved by existing programs. This saves an enormous amount of time but can lead to security problems if the imported modules have inadvertent or deliberate flaws.
As Lin Clark, Fastly senior principal software engineer, wrote in 2019 while at Mozilla, 80 per cent of code bases come from these package registries. So there's much to be gained by limiting the potential harm from any buggy or malicious libraries in an application.
WebAssembly aims to do so through nanoprocesses, which create memory-efficient isolated sandboxes for each wasm module or library. It has the potential to replace microservices with quarantined, wasm-based nanoprocesses. And that's more or less [13]the mission of the Bytecode Alliance.
[14]
With its incorporation as a 501(C)(6) organization and its membership expansion, the Bytecode Alliance is looking to extend its vision of more modular, secure, performant applications to a broader set of environments, like the cloud and the network edge.
"WebAssembly and the emerging WebAssembly System Interface (WASI) specification enable cloud-native solutions to become more secure by default and help solve computing challenges across a variety of environments, including the 'tiny edge' of systems-on-a-chip (SoCs) and microcontroller units (MCUs)," said Ralph Squillace, principal program manager, Azure Core Upstream, at Microsoft and Bytecode Alliance board member in a statement.
Holley said the technical community has a chance to change the way software is built in a way that will empower small teams to develop big projects that manage to be both secure and speedy.
"Achieving the elusive trifecta — easy composition, defect isolation, and high performance — requires both the right technology and a coordinated effort across the ecosystem to deploy it in the right way," he said.
Maybe wasm is that technology. ®
Get our [15]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YImGnGNaJD@XWKd1GOullQAAAMY&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://www.theregister.com/2021/02/16/libreoffice_team_working_on_port/
[3] https://bytecodealliance.org/
[4] https://www.theregister.com/2019/11/13/webassembly_buildup_group/
[5] https://github.com/WebAssembly/design/blob/master/Semantics.md
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YImGnGNaJD@XWKd1GOullQAAAMY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://wormhole.app/
[8] https://wasi.dev/
[9] http://www.theregister.com/2021/04/06/deno_is_now_a_company/
[10] http://www.theregister.com/2020/11/20/internet_archive_flash_emulation/
[11] http://www.theregister.com/2020/10/15/cloudflare_browser_isolation/
[12] http://www.theregister.com/2020/07/22/w3c_minutes/
[13] https://bytecodealliance.org/mission
[14] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YImGnGNaJD@XWKd1GOullQAAAMY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[15] https://whitepapers.theregister.com/
Re: Once upon a time...
And that final sentence is all that matters.
It is in the interests of the big data harvesting culprits to push as much as possible to the client so that they can suck in even more data.
Re: Once upon a time...
" And that final sentence is all that matters. "
Actually, it's not. Many security conscious folks (a tiny proportion of the public, to be sure) avoid new versions because they're fraught with hazard (basic security principle: never be an early adopter, so others find the bugs first). But as a result they can find they lose access to services.
An international organisation's portal I need for work ceased progressively to allow me access a month or so ago. It had worked perfectly well until then, but when I queried it the help desk just said "you must upgrade your browser". The Streetmap mapping service worked perfectly with javascript disabled until a few days back. Then suddenly it didn't display the maps even with javascript turned on.
I have to ask why it's necessary to modify a service that currently works fine in a way that prevents security conscious folks accessing it any more.
Re: Once upon a time...
Agreed.
I would add that it also makes the browser ridiculously complex meaning that new contenders will be few and far between.
It would be a duanting task just implementing HTML 5 from scratch, let alone keeping on playing catchup with all the new daily non-features..
The idea that in the future the only choice will be Google's Chrome engine or (if we are lucky), Mozilla Firefox, makes me shudder a little.
Re: Once upon a time...
WebAssembly runs on the server also, it about a secure environment where you want it.
It's pretty cool. I love being able to target C99 and OpenGL at a browser target, with deep pointer arithmetic and tricks, and yet little code modification, you can do some amazing things with it.
But what will happen is that they'll "accelerate" it by removing the memory safety, or exposing devices or DMA to it, or something else stupid in order to gain on a benchmark, and then we'll all be back to square one where we might as well all be running Flash again.
ffmpeg in browser? Why?
Because unfortunately a video decoder in pure Javascript would be much worse.
Obviously the solution of not having a video decoder in the browser is not an option to "modern" websites apparently. ;)
You don't need to reinvent the wheel with web assembly, the browser's already got a video decoder built-in.
If you liked JavaScript code from anywhere in the world running on your browser...
... after clicking on the wrong link, you're going to love WebAssembly.
What could possibly go wrong?
Re: If you liked JavaScript code from anywhere in the world running on your browser...
To be fair, the whole setup of C compiler -> Q3VM bytecode worked very well with Quake III Arena. So why can't it work with a web browser and important things like online banking...
;)
runs c++ code - tha'ts code with all the unsafe unchecked memory accesses, the cause of most vulnerabilities, right?
You are probably thinking of C.
C++ has checked memory access (i.e in std::vector
But either way, your idea of the issue is potentially misguided. The C++ when compiled to WebAssembly can't access any more than the underlying WebAssembly VM allows it. I.e this would be exactly the same as JavaScript implemented into WebAssembly.
However your overall concern is not misguided. There is zero chance the WebAssembly VM will be implemented bug free!!! (probably because those developers don't know about at(idx) in std::vector haha.
And so the cycle turns ...
Every few years someone comes up with a 'new' way of running code in the browser.
Microsoft did it with ActiveX, which was just a way of running unverified native code from a browser with no sandboxing at all -- what could possibly go wrong?
Sun did it with Java, which allowed running interpreted bytecode 'applets' (with limited API access to the native environment) in a sandbox in a browser ... which was certainly a better approach, but the sandbox provided by the runtime was invariably leaky, in practice (partly through incompetence, and partly in the name of speed), and the security was deplorable. JIT-compiling the code and running it natively made it faster, but had further impact on the security.
The current trend is to use Javascript (or, recently, something that compiles to Javascript) which may be interpreted by the browser but is more usually JIT-compiled and run natively. This is regarded by many as being better than Java, but actually sucks less only because the quality of implementation is a little higher. Javascript itself is a nightmare of a language ("strongly untyped") that's barely as readable as Perl, but has become popular because it's the only game in Browser-town (though the things that compile to Javascript do mitigate its underlying nastiness to some extent and relegate Javascript to the status of "the assembly language of the web").
Now we are being told that the next turn of the cycle will actually be called "WebAssembly", and that it will allow us to write web apps in our favourite languages (so, no Javascript, at least) and compile them to the bytecode for an abstract virtual machine hosted by the browser (isn't that what Java was supposed to do?) As with Java, the browser will then either interpret the bytecode or JIT-compile it and run it natively on the host -- in some sort of sandbox if we're lucky. Maybe it will done well and the security won't be awful, that was never achieved with Java, though.
On the one hand I really do hope that this is going to turn out to be Java done properly and not Javascript done even worse ... but on the other hand despair that this is just going to encourage more and more code running in the browser for no fathomable reason.
I wonder what the next turn of the cycle will bring ...?
Re: And so the cycle turns ...
I've just invented Cobolnetes, runs Cobol source code via an interpreter in a sandbox. The only security problem is when the cat needs to use the sandbox at the same time, you get resource sharing conflicts. Data can escape via LCOTB accesses (Letting Cat Out The Bag).
Once upon a time...
There was a time when the bulk of processing was done server side, so access to services was pretty independent of the web client being used. This of course fulfilled the key intent of the WWW on inception - client agnosticism.
For too long now, processing has been progressively devolved to the client side, with servers merely delivering code for local execution. While this reduces provider side cost and complexity, it results in exclusion of those who don't keep their browser "up to date" with the latest execution capabilities.
It's also in principle the most insecure mode of operation for users - running unverifiable code from unknown sources on their local machine.