Microsoft joins Bytecode Alliance to advance WebAssembly – aka the thing that lets you run compiled C/C++/Rust code in browsers

The Bytecode Alliance, formed by Fastly, Intel, Mozilla, and Red Hat to move WebAssembly beyond the browser, has created a non-profit organization with the help of Microsoft to further their cause. The gang has also added six more member organizations to advance its mission to make software more modular, secure, and fast. In …

[Mike 137]

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.

[hoola]

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.

[Mike 137]

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.

[Aquineas]

Re: Once upon a time...

"(basic security principle: never be an early adopter, so others find the bugs first)"

I *strongly* disagree. Those "bugs" that others "find first" are usually zero-day exploits that you seem to be suggesting it's okay to wait on installing. If a patch is being issued, it's for a reason.

[Mike 137]

Re: Once upon a time...

Of course you're entitled to diagree Aquineas, but I didn't say "don't patch". I said - wait until a new service or product has been in service for a while before you deploy it, so you don't succumb to the initial round of vunerabilities i.e. "let others find them first".

And BTW for all the hype, a "zero day" is just an attackable vulnerability the bad guys found and exploited before the good guys found it. It's not a special case - it's statistically inevitable that it occurs quite often, ands it's one good reason for not being an early adopter.

[Aquineas]

Re: Once upon a time...

Okay, I acknowledge that it's not always good to be an early adopter when it comes to newly released software. But the second I know about a patch, I'm applying it.

As for the zero day being a good reason not to be an early adopter, most zero days have existedfor many years before they're discovered, many times in "trusted" libraries that everyone relies on because we're all relying on open source.

[Missing Semicolon]

Re: Once upon a time...

Becuz munneee! of course.

Only by ensuring you have JS enabled will the ad and tracking scripts run.

[karlkarl]

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.

[ssokolow]

Re: Once upon a time...

That assumes it's even *possible* to implement a new browser engine anymore.

Drew DeVault may be inflammatory at times, but this is one area where I agree with his take.

https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html

[yowl00]

Re: Once upon a time...

WebAssembly runs on the server also, it about a secure environment where you want it.

[James 47]

Re: Once upon a time...

> it results in exclusion of those who don't keep their browser "up to date" with the latest execution capabilities.

Indeed, yesterday there was a submission to HackerNews about some scandal in the Scala community. Every browser I used on my admittedly old iPad to view the medium.com article would show the text for a few seconds before rendering a completely white screen.

[Throatwarbler Mangrove]

Re: Once upon a time...

That would be the seemingly-ubiquitous pop-over window that so many sites now employ exhorting you to subscribe to their page or newsletter. Be grateful your old version of Safari doesn't compel you to see it!

[Anonymous Coward]

Re: Once upon a time...

Yeah, the "It's not a paywall" message that says, sorry, you seem to have any privacy settings turned on in your browser, so we're blocking the access to this site until you agree to turn them all off, or sign into a free account that requires giving up even more information so we can track you from the server side.

I don't love ads, and sadly the screen crawling horrors have reappeared thak kill the user experience. So if sites like WaPost were like "Hey, whitelist the Ads on our site if you want to read free articles" that at least has a clear motive and cause effect relationship.

Instead they frame it in terms that sound more like "abandon secure browsing mode, all ye who wish to view content" forcing people submit to ad tracking even if the ads aren't being displayed. And they have started selling their "Not-A-Paywall" as a service to other media companies. So increasingly people are getting cut off from decent quality news content.

Of course their is a tier of unencumbered "conservative" news sites like fox, and newsmax that are happy to serve you all the misinformed misinformation you can eat. So pushing people to that probably won't have consequences. Oh wait, I forgot about that whole capitol thing. Oops.

[Aquineas]

Re: Once upon a time...

That's because no one can read highly optimized Scala.

[bombastic bob]

Re: Once upon a time...

It's also in principle the most insecure mode of operation for users

apparently, THEY don't care. They can't properly run their tracker-scripts and ad-slinger-ware without client-side scripting, and the more we try to BLOCK the privacy violations, the more COMPLEX and SOPHISTICATED and IMPOSSIBLE NOT TO HAVE they'll make the "requirements" to "support client-side whatever" to EMPOWER THEMSELVES. And, conversely, to DIS-empower those who would DARE to write their OWN browser, or hang onto an older one that can be de-fanged...

[Lee D]

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.

[ssokolow]

As someone who really wants nanoprocess isolation for my dependencies and WebAssembly as an easy way to write a plugin/modding API, I have to throw a little cold water on that.

"WebAssembly doesn’t make unsafe languages safe (yet)"

https://00f.net/2018/11/25/webassembly-doesnt-make-unsafe-languages-safe/

"Everything Old is New Again: Binary Security of WebAssembly"

https://www.usenix.org/system/files/sec20-lehmann.pdf

TL;DR: WASM hasn't yet spec'd the stuff needed to port various standard intra-process protections, including things like making an attempt to dereference 0x0 an access violation to catch various common null pointer bugs, and, setting guard pages so wandering from one allocation to another within the same application has a chance of getting caught.

Thankfully, WebAssembly was intentionally released as a minimum viable product and a work in progress, so it doesn't have to stay that way.

[Ozan]

ffmpeg in browser? Why?

[karlkarl]

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

[Dan 55]

You don't need to reinvent the wheel with web assembly, the browser's already got a video decoder built-in.

[karlkarl]

It has some video encoders. But not the *exact* encoder they want.

God forbid a developer changes the format to suit what the client can provide! XD

[bombastic bob]

that's right, with NO FLASH, the GIF animated ads just aren't animated ENOUGH. You need FULL BLOWN STREAMING VIDEO in the ad-slinger panels.

One step closer to that TV they showed in Idiocracy, with 1/4 of the screen in the middle with your show, and 3/4 of the screen around the edges with ADS. Constant ADS.

Got, Brawndo? It's good for plants!!!

[Anonymous Coward]

Not ffmpeg, but we (when I worked at Movi - movi.ai) evaluated porting our video player to the web for browser support. Without access to any decoder hardware through the browser we would basically have needed to write our own software decoder.

While it's not an impossible task, and I had some cool ideas to improve performance and greatly reduce memory requirements ultimately it never happened while I was there.

[Anonymous Coward]

Not just why

WHY GOD! WHY!

[Dan 55]

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?

[karlkarl]

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

;)

[thosrtanner]

runs c++ code - tha'ts code with all the unsafe unchecked memory accesses, the cause of most vulnerabilities, right?

[karlkarl]

You are probably thinking of C.

C++ has checked memory access (i.e in std::vector<T>::at(idx)). The problem is some C++ developers don't seem to know about it.

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.

[bombastic bob]

The problem is some C++ developers don't seem to know about it do not want to write inefficient code

fixed it for ya. Properly written code uses #define constants and code that checks limits so they do NOT need to be re-re-re-checked and/or have inefficient "iteration+insert safe" bloat-code slow things down FOR you.

(the real problems are fixed-sized buffers without using 'sizeof()' later, hard-coded magic numbers, unsanitized input, and lack of proper testing before deploying)

[karlkarl]

Hah. Efficient all the way to the segfault ;)

std::vector<T>::at() isn't to replace fast pre-checked array access. It is to replace the work typically done by a "safe" language like Java.

Just because you are using C++, doesn't mean you need to be efficient for everything. Safety probably takes priority for 99% of the program.

[bombastic bob]

Just because you are using C++, doesn't mean you need to be efficient for everything.

yeah, but unfortunately the effect of that philosophy tends to multiply, and then you have WINDOWS 8/10.

I do a lot with kernel code, microcontrollers, and things like that. Must be 100% reliable _AND_ efficient. It's possible to do both.

[Aquineas]

Microsoft's implementation of some of their bonehead APIs is not because of C++. It's because of Microsoft. That being said, if you want to write some really obscure, hard-to-debug code, C++ does make it very easy to do that.

[Anonymous Coward]

> probably because those developers don't know about at(idx) in std::vector haha

std::vector<T>::at(size_type pos) doesn't check for memory access. It only checks that the value of the pos argument passed to std::vector<T>::at() is smaller than the value returned by std::vector<T>::size().

For all we know, std::vector<T> has allocated more memory than its current std::vector<T>::size() reports. That's because the library implementation wants to avoid reallocating, copying and then free'ing memory very often. The algorithm used for this technique is usually new_memory_size = old_memory_size + old_memory_size / 2.

As such, std::vector<T>::at() only checks for the number of elements in the vector, not for memory access. The type of the pos argument is an unsigned integer type, not a memory address (i.e. pointer).

It's not clear to me at all what any of this has to do with any hypothetical memory usage constraints of a virtual machine implementation. A virtual machine implementation that has hardcoded memory constraints doesn't sound very useful, or portable.

[Potemkine!]

The problem is some C++ developers don't seem to know about it.

The problem is some C++ developers don"t know how to manage memory correctly without a helper.

It just requires knowledge, rigour and competency.

C++ is for responsible people, aware of what they do, it isn't for kiddies who require a garbage collector.

[dajames]

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

[Paul Herber]

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

[Aquineas]

Re: And so the cycle turns ...

I feel as though I could have written this comment myself.

[bombastic bob]

Re: And so the cycle turns ...

I wonder what the next turn of the cycle will bring ...

except for the OBVIOUS BANDWIDTH HELL, how about K8's on the client?

/me ducks and grabs coat on the way out

[ssokolow]

Re: And so the cycle turns ...

One big problem with Java Applets is that Java started from more Desktop-y APIs and then locked things down.

WebAssembly is descended from Mozilla's asm.js and Google's Native Client and follows the JavaScript approach of aiming to approach "make evil commands unrepresentable" at the API level, and it does two things to avoid the applet outcome:

1. Like JavaScript (and thus, like asm.js), all its APIs are based on permission tokens passed in by the sandbox host. (eg. The WASI API for writing command-line applications doesn't let you ask to open "/etc/passwd" because WASI only provides a system call to open paths that are children of an FD the sandbox host passed in (basically, a secured wrapper around openat(2)), so, like with JavaScript in the browser, even the non-browser uses of WebAssembly need something that allows you to achieve arbitrary code execution in the sandbox host to break out.)

2. Like the Native Client loader's machine code checker, the WebAssembly loader restricts what machine instructions can be generated, requiring a vulnerability to be found in the loader to craft fully arbitrary input to the sandbox host APIs.

If you want to poke at WASI, the Wasmer runtime includes an NPM-like package system named WAPM and an npx analogue called wax and the default behaviour when running a command is to balance convenience and security by granting access to $PWD and nothing else and to use SSH-like "pin the first signature we see" behaviour if a package is signed.

[Claptrap314]

You don't have any security.

Get over it.

[Aquineas]

I can't in any way see why this is a good idea

Here, let us run this code on your machine. Not that many people analyze the legions of Javascript code that are already executing on their machines when they are even just loading a browser, but WebAssembly will obscure that even further. What could possibly go wrong?

[ssokolow]

Re: I can't in any way see why this is a good idea

WebAssembly has a canonical text form that you can losslessly transform back and forth from and the browser vendors have plans to incorporate support for it in the developer tools so you can get an experience comparable to running arbitrary minified JavaScript through a code beautifier.

It's a LISPy S-expression grammar and, in my experience, it's about as easy to read as de-minified JavaScript. Take a look at the examples on the WebAssembly Wikipedia page.

(You have to remember that WebAssembly has to be high-enough level that the final compilation to cached machine code by the browser can produce fast code, regardless of whether it's x86, ARM, MIPS, PPC, etc. that you're targeting.)

[Howard Sway]

The first web assembly library is out!

It has 2 functions : trackUserLocation() and serveAdvert(), and also some hidden thing called kybrdlggr()

I think I'll definitely install it and see what it does, even though it wants lots of permissions!

[vtcodger]

Re: The first web assembly library is out!

Sure, sure ... but can it tinker with your filesystems or insert keystrokes via the keyboard driver? Sounds like there's still work to be done before it can claim to be the perfect malware vector.

[Dan 55]

Re: The first web assembly library is out!

Don't worry, it's all under control, have a look at WebUSB and the Native File System API.

[Dave 15]

With Microsoft involved it will be bloated, impossible to understand, slow and full of holes

[Anonymous Coward]

With Google involved it'll never get out of beta.

[Paul Herber]

Are you saying Alphabet and Betaware are the same outfit?

[bombastic bob]

you made me think of a Henny Youngman joke

[Anonymous Coward]

Oh f❄︎❄︎k, they're reinventing ActiveX!

% cat lessons_of_history >/dev/null

/dev/null: device full

[Brian Miller]

Re: Oh f❄︎❄︎k, they're reinventing ActiveX!

"This is a bad idea." "Yeah, let's do it differently!" (later) "This is a bad idea." "Yeah, let's do it differently!"

Etc.

[BobLon]

Another name that won't make sense in the long run?

We've had to put up with the meaningless naming of JavaScript for years now (named after Java because it was cool at the time?) and now we've got what could be a useful general-purpose virtual machine spec but it's got the word "Web" at the front, because, like, web is cool at the moment? If we end up running desktop and server apps written in WebAssembly, with no "web" in sight, it'll sound just as silly as JavaScript. I guess we're just lucky that we're past time when "iAssembly" might have been a popular option...

[ecofeco]

The Internet is dead

Long live the Internet.

I'll be over here with my old HTML and CGI BIN laughing at 30MB webpages-------------->

[Dan 55]

Re: The Internet is dead

FrogFind FTW. Not just for retro computers, it strips out all the nonsense.

[Libertarian Voice]

Re: The Internet is dead

There are others out there then; I feel less alone. Mind you my CGI is written in C++ so that I can reuse my back office codebase so perhaps I am still more alone than I might think.

[Henry Wertz 1]

Essentially webassembly *is* Javascript

Webassembly at it's base uses tokenized versions (i.e. few-byte opcodes rather than full names) of a very limited set of Javascript functionality, I assume on a big byte array, using assembly-language-level Javascript instructions (i.e. probably huge amounts of use of 8-bit, 32-bit and 64-bit values, and no use of strings and other data types, object oriented anything, and so on). So, with some Javascript compatibility wrapper (to de-tokenize the webassembly) it can actually run in a straight Javascript interpreter (probably rather slowly).

Any modern browser (Firefox and Chrome for quite a while at least) handles the webassembly as actual bytecode (not a series of tokenized Javascript instructions); instead of the a compiler front end breaking C or C++ down into bytecode and using LLVM (or backend of gcc) or custom JIT compiler or whatever to optimize and compile, it pulls in the webassembly and LLVM or custom JIT or whatever optimizes and compiles it, so you essentially get native performance if you have a good webassembly compiler.

If you want to see a fun demo of this, go around on archive.org and find the stuff on there for like DOS games, C64 games, Atari 8-bit games, etc. -- instead of like "here's the disk images to download", a lot of these pages are like "here's the disk images to download, or click on this box to boot up the game and play it", click the box and an Atari 800XL powers up, boots off the floppy and there's your game.

[Anonymous Coward]

Re: Essentially webassembly *is* Javascript

Anything that replaces JavaScript is welcome.

[Paul Crawford]

Re: Essentially webassembly *is* Javascript

Be careful what you wish for...

[Anonymous Coward]

Re: Essentially webassembly *is* Javascript

It's really hard to imagine there could be worse.

[werdsmith]

Re: Essentially webassembly *is* Javascript

Bu it doesent replace it. Just does some of the heavy work.

You'll love how the (current) arrangement allows for exchanging information between the javascript and the webassembly. Needs improving a lot.

[Anonymous Coward]

It's really hard to imagine there could be worse.

VBScript.

Please send £5 to the usual address.

[Tom Graham]

Fastly

Where to tech companies come up with these stupid names?

Why do they behave like sheep in following this naming fashion?

[bombastic bob]

Re: Fastly

Where to tech companies come up with these stupid names?

blame marketing.

As someone else mentioned, "Web" is the new "Java" which was the new "Visual" ... yotta yotta .. the new "Space" - etc.

and now I'm thinking.. "PIGS! IN! Web?"

[ssokolow]

Re: Fastly

They named it before they realized how useful it could be outside the browser and then they didn't change the name.

[Warm Braw]

Memory-efficient isolated sandboxes

I've heard that one before. Several times.

[ssokolow]

Re: Memory-efficient isolated sandboxes

This isn't exactly traditional isolation though.

It's more like a bytecode-level version of how embedded Lua or JavaScript runtimes keep you from calling privileged APIs.

Uncaught ReferenceError: system is not defined

Each dependency is given a restricted lexicon of APIs to call and the bytecode and loader are designed to use that trick Google Native Client pioneered to prevent calls outside the defined set from being synthesized at runtime.

(ie. The loader refuses anything it can't prove to be a "valid instruction" and the set of valid instructions only contains calls that manipulate memory in provably safe ways and interact with the outside world through handles passed in by the host application.)

For example, WASI (the interface for writing command-line applications) doesn't have APIs for opening arbitrary paths... just secure openat(2) analogues for opening paths that are children of the FDs passed in by the sandbox host.

[Shawn Eary]

Haskell Support

Now, can we please add support to compile Haskell to WASM?

[A.P. Veening]

Re: Haskell Support

While we're at it, please also include Brainfuck.

[Libertarian Voice]

Thanks but no thanks

For my web applications I use SQL, Javascript HTML and C++ (cgi). I have written a handful of helper libraries in C to put it all together and it works absolutely fine. It absolutely must be server side for security reasons as the user ends up receiving no more data than is displayed on their screen anyway so there is much less chance of an attacker knowing where to begin.

I wouldn't use a web assembler even if there were one available and I certainly would not want to use one as an end user as it may be doing just about anything in the background without my knowledge. XMLHttpRequests are bad enough as a consumer and more than enough as a developer.