Bytecode Alliance Expands as Microsoft, Google, Intel Promote Fast, Secure Development with WebAssembly (mozilla.org) 54
There was a big announcement this week from Mozilla. They've joined Fastly, Intel, and Microsoft "in announcing the incorporation and expansion of the Bytecode Alliance, a cross-industry partnership to advance a vision for fast, secure, and simplified software development based on WebAssembly."
Building software today means grappling with a set of vexing trade-offs. If you want to build something big, it's not realistic to build each component from scratch. 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.
Mozilla helped create WebAssembly to allow the Web to grow beyond JavaScript and run more kinds of software at faster speeds. But as it matured, it became clear that WebAssembly's technical properties — particularly memory isolation — also had the potential to transform software development beyond the browser by resolving the tension described above. Several other organizations shared this view, and we came together to launch the Bytecode Alliance as an informal industry partnership in late 2019. As part of this launch, we articulated our shared vision and called for others to join us in bringing it to life... [W]e asked prospective members to be patient and, in parallel with ongoing technical efforts, worked to incorporate the Alliance as a formal 501(c)(6) organization. That process is now complete, and we're thrilled to welcome Arm, DFINITY Foundation, Embark Studios, Google, Shopify, and University of California at San Diego as official members of the Bytecode Alliance.
We have a real opportunity to change how software is built, and in doing so, enable small teams to build big things that are both secure and fast.
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. Mozilla believes that WebAssembly has the right technical ingredients to build a better, more secure Internet, and that the Bytecode Alliance has the vision and momentum to make it happen.
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.
Mozilla helped create WebAssembly to allow the Web to grow beyond JavaScript and run more kinds of software at faster speeds. But as it matured, it became clear that WebAssembly's technical properties — particularly memory isolation — also had the potential to transform software development beyond the browser by resolving the tension described above. Several other organizations shared this view, and we came together to launch the Bytecode Alliance as an informal industry partnership in late 2019. As part of this launch, we articulated our shared vision and called for others to join us in bringing it to life... [W]e asked prospective members to be patient and, in parallel with ongoing technical efforts, worked to incorporate the Alliance as a formal 501(c)(6) organization. That process is now complete, and we're thrilled to welcome Arm, DFINITY Foundation, Embark Studios, Google, Shopify, and University of California at San Diego as official members of the Bytecode Alliance.
We have a real opportunity to change how software is built, and in doing so, enable small teams to build big things that are both secure and fast.
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. Mozilla believes that WebAssembly has the right technical ingredients to build a better, more secure Internet, and that the Bytecode Alliance has the vision and momentum to make it happen.
Silver bullet (Score:4, Insightful)
I'm sure this silver bullet will do the job. Pay no attention to the moutnain of old silver bullets discarded behind the curtain.
Re: (Score:2)
Re: (Score:2)
You wish!
It is built on the rattling upside-down pyramid shed of the batshit insane WhatWG.
And I base that judgement of a 3 hour personal conversation with those who were in control at the WhatWG some years back to find out exactly that: Their mindset, their ideologies, and their ability to obey valid logic and accept reality. You should have seen the cognitive dissonances, NIHs as big as a galaxy, and reality-defying ideologic beliefs. It would have blown your mind. The only comparisons I can think of are
Re: (Score:2)
It is about "more possibilities", not "all possibilities".
Indeed. The goal is not perfection but improvement.
WebAssembly has been around for years and should be judged not by its promise but by its track record. Wasm typically delivers 90% of the performance of native code. That is better than JVM and WAY better than JavaScript, which is what it is typically replacing.
The security model is good and has a solid history. Most exploits are malware stealing CPU cycles for activities like cryptocoin mining, which cannot be fixed at the bytecode level.
Wasm is not ti
Re: (Score:1)
This is either a cranky cynical stream-of-consciousness rant or some AI bot trying out its stuff.
Re: (Score:2)
The mods sure liked it, didn't they?
Re: Silver bullet (Score:1)
With this group involved (Score:5, Insightful)
Re: (Score:3)
Re:With this group involved (Score:4, Informative)
This is not about WebAssembly in the web browser but about safe execution server-side.
By using virtual machine code it becomes possible to have multiple server apps/instances running more safely contained from each-other with much less overhead than with hypervisors, Docker containers or even process boundaries.
In other words, it is like JVM or CLR but also for lower-level languages such as C and C++.
The system uses capability-like abstractions for containment (borrowed from CloudABI/Capsicum on FreeBSD), which should be a bit safer still than JVM/CLR. This means however, that it is also like its own operating system platform.
WASM/WASI is already in production on major sites such as Shopify.
Weirdly enough, a lot of the adoption of WebAssembly on the server has been from the Rust community, even though Rust is a worse match to WebAssembly's ISA than C is and shouldn't need WebAssembly's added safety features as much.
Re: (Score:2)
Yeah.... They forgot to include all the data slurping and the associated ads that will inevitably come with such a framework. That's what it is all about these days.
Oh, and 'secure' means that you can't stop or interrupt them (or so they hope)
Re: (Score:3)
Yeah.... They forgot to include all the data slurping and the associated ads that will inevitably come with such a framework.
WebAssembly is not a "framework". It is an open and standardized binary bytecode format. Anyone is free to write a compiler, and open-source compilers are available to generate Wasm from C++, Rust, and other languages. Anyone is free to write an interpreter/container. Wasm is already supported by nearly all browsers.
Re: (Score:2)
Well, one part of coming of age is realizing that what people say is their goal is not necessarily related to what their goal is.
The second step is realizing you get further if you don't constantly play with open cards either, and base your statements on what is most helpful to move things towards your goal, instead of basing it on what you think.
Sadly.
Re: (Score:2)
That is just the slogan they had some expensive marketing people (i.e. "professional highly-skilled liars") create for them.
1996 Called (Score:2)
Re: (Score:3)
Yeah, this sounds a lot like "java applets reimplemented with 25 years of experience". Maybe they weren't so wrong in principle, just in implementation...
Re: (Score:1)
As I mention nearby, there is still a big desire for GUI web standards, but the solution may be a GUI markup language rather than running more business logic on the client. That reduces the problem scope and thus avoids most the security and upgrade headaches that Java applets encountered. Instead of putting an entire virtual OS on the client, just put the GUI display engine on it. It's easier to upgrade ones server middle-ware than say 10,000 disbursed clients.
Re: (Score:2)
We already have it. HTML5. Sure we could start over again with 30 years experience on a complete rewrite... but like past efforts; you end up with a re-invention of the OS all over again. If you try to please all usergroups you will built-in and bolt-on everything until you end up with a general programming environment which will work around any limitations in attempts by groups to make it into an OS for their needs. Merge all groups and you end up with a recreation of an OS.
A GUI markup language even if
Re:1996 Called (Score:4, Insightful)
HTML5 did squat for GUI's. For example, it deprecated frames without a decent replacement, and date input fields are still inconsistently formatted.
I'm not proposing we END html, just don't rely on it for stateful GUI's, because it sucks at that particulare niche (a big niche, by the way).
No, just please productivity-oriented GUI uses.
Most apps are small and medium, we don't need web-scale bloat for everything. It's like obsessing on fast cars when most just want to drive to work.
Re: (Score:2)
I don't see web assembly (or applets, for that matter) as primarily being about GUIs, but about letting the client do computation the client can perfectly well do themselves. GUI responsiveness is one reason why you might want that, but far from the only one.
Of course when the client runs code from the server, there's a whole can of security worms opened, which Java tried to deal with but failed miserably.
Re: (Score:1)
Games and decent GUI response are the two primary demands for web assembly's potential speed. Are there other common needs I missed?
Replacing desktop apps altogether may be another possible target, but to do that well, a decent GUI standard is still needed (among other things), otherwise all the limitations and headaches of DOM/CSS are still there. Faster crap is still crap.
Re: (Score:2)
Privacy is the other big reason users have to want to run stuff locally.
Re: (Score:1)
One might as well use Java then. It's already a cross-platform byte-code based system, and (arguably) does GUI's better than DOM. (Although, having Oracle's fingers in it is concerning.)
Re:1996 Called (Score:5, Interesting)
No, they weren't wrong. But no, it wasn't the implementation either.
It's the platform. Or, more properly, the inner platform. The layers upon layers that re-invent the wheel, and mount it on top of the old wheel, instead of just improving the old wheel.
E.g. we got hardware memory addresses and OS ports for talking to hardware, UNIX sockets, Ethernet , IP sockets, TCP ports, and then ... webSockets... (*audible sounds of a head banging on a table*)
Just use freaking virtual memory addresses that also serve as communication channels! Map parts of memory to other computers, and be done with it! Use regular file system paths for everything, and one single service to map human-readable names to those memory addresses! Hell, IP addresses could just be replaced by bog standard pointers to chunks of a huge global virtual memory. Though for efficiency reasons, using paths of pointers, like //45949430/3854939/34935459/1 would be more efficient than one massive and inflexible pointer. But I digress, the general point should be clear: Be a real programmer: Re-use! Improve iff necessary. Do not duplicate!
Lock it down or feature creep kills it (Score:2)
Like everything before; the good ideas will be buried in years of stupid ideas bloating it up until it reminds everybody of Java Applets.
So this is different... it has a slightly different sandbox and this time it is going to work. How many times have we heard this before?
I've seen rumblings already of direct API access so it doesn't have so much overhead and limitations in bridging across it's sandboxed walls. Add in a broad market of use cases for it along with pressures to "optimize" for all the pushy u
Re: (Score:3)
Re:Lock it down or feature creep kills it (Score:4, Interesting)
WebAssembly is almost useless, and a mere proof of concept right now. It still lacks the actual APIs to talk to the browser. Everything has to go through a JS adapter you are forced to write, defeating most of its purpose.
We can lock down the *purpose*.
But locking down the half-completed single home so it doesn't become a skyscraper complex will leave you with an incomplete house.
The purpose, I think, is to remove the limitation of having to use JS. To make browsers allow any language that allows compiling to wasm. (Which, thanks to llvm, is easy.) So all browser APIs must be available to WASM, and in fact you can have JS just compile to WASM too and remove it from the browser. (yay!)
The real problem is that browsers nowadays are feature-creep monsters. Ever since Google tried to steal the power from the W3C, that previously tried to reign in the utter spaghetti code of crap that was HTML 3.2 during the IE 3/4 and NN 3/4 era, by creating the What(TheFuck)WG, to dump their spaghetti code into the "living standard" [insert pictures of The Thing], and dump as many stupid kitchen sinks ("features") in browsers as possible, so nobody else can keep up, so everyone else dies and they can rule the web.
The web should be a distributed *document*. Period.
For everything else, there's already existing better lower-level interfaces. (Think the many RPC solutions and existing bytecode standards.)
Re: (Score:2)
The web should be a distributed *document*. Period.
For everything else, there's already existing better lower-level interfaces. (Think the many RPC solutions and existing bytecode standards.)
Good luck convincing owners of iPod touch, iPhone, and iPad devices to switch to a competing brand on grounds that iOS lacks support for "the many RPC solutions and existing bytecode standards."
Lack of Oracle (Score:2)
So this is different [from Java applets]... it has a slightly different sandbox and this time it is going to work. How many times have we heard this before?
The two differences:
1. WebAssembly seeks to support conventional languages with semantics that don't closely match those of the Java language.
2. WebAssembly is not encumbered by exclusive rights owned by One Rich American Called Larry Ellison.
wrong focus (Score:3)
Rather than faster crap, how about de-crapping our standards. For many applications people still want GUI's, especially office CRUD, and JS/DOM makes for lousy buggy GUI's. How about they work together on a state-ful GUI markup language.
Yet another bytecode... but is it better? (Score:2)
In this thread: Out of all the instruction sets in existence, machine code, byte code, everything, which one do you reckon is the most universal, elegant and efficient one?
Because I have a feeling WebAssembly was completely unnecessary. (I'm not judging how good or bad it is, but imagine if they had just user JVM bytecode. Or one of the nicer proper machine code ones.
I, for one, have now half-completed my qemu-based minimalist browser. :)
----
[The CLI is the URL bar, qemu and a OS image (where HTML5 is consi
Re:Yet another bytecode... but is it better? (Score:5, Insightful)
The big difference is that WebAssembly is for lower-level languages, such as C and C++ (without having to be different like CLR's "Managed C++").
In that way it is more like ANDF than JVM.
I hate that WebAssembly was made to run in web browsers as a way to make faster, bigger web applications when the right way IMHO would have been the opposite: to use Javascript only for added value, not even being a requirement that is was enabled.
But for servers and desktop programs, something like ANDF to get traction is long overdue IMHO.
I disagree with many of the design choices though, such as how things are mapped into the single address space, how the vector/SIMD extensions are too much of a subset of a bad example and how it does not natively support all of Rust's data types.
But WebAssembly is still very young, so things could change.
BTW. My favourite machine languages are 68020, A64 and The Mill variants.
More importantly, it's legal (Score:2)
Out of all the instruction sets in existence, machine code, byte code, everything, which one do you reckon is the most universal, elegant and efficient one?
It depends on whether "efficient" includes waiting 20 years for essential patents on the instruction set to run out. One concept that's likely to run up against legal encumbrance is the "belt" of most recently used results in the Mill processor.
imagine if they had just user JVM bytecode.
First, it would have been limited to languages whose semantics closely resemble those of Java.
Second, Oracle would have sued, just as it (or its predecessor) successfully sued Microsoft for J++ and (unsuccessfully) sued Google for use of the Java language in the Andr
Another black box (Score:1)
That people will apply kludges to to make it do something.
How is this supposed to bring more security? (Score:2)
I mean a bytecode doesn't actually bring more security such as it's just an intermediate step between the source code and the binary code. If you build security concepts into the language itself which could use features of the bytecode interpreter, you could just as well compile those security checks into the binary itself.
On the other hand, a common bytecode makes it easier to ship and run software without source code. This is great news for malware authors as they can now ship malware much more easily. A
Re: (Score:1)
If it becomes a hacker magnet more so than something of practical value, people and shops will disable it like they did Java Applets, and it will die like Java Applets.
Re: (Score:2)
Yeah, but what if websites embrace it like they did with Flash and Javascript?
Re: (Score:1)
Flash is mostly dead as "default" technology. JavaScript may have survived despite also being leaky because it was either the "least evil" between JS, Flash, and Applets, or had more momentum. You can't give up all three without losing interactive web apps altogether. Thus, the marketplace appeared to pick the least evil, possibly because no one vendor fully controlled JS.
Re: (Score:2)
If you build security concepts into the language itself which could use features of the bytecode interpreter, you could just as well compile those security checks into the binary itself.
Perhaps I misunderstand you here? With a byte code interpreter you enable the user to control the security perimeter. If the security enforcement is compiled into the binary, the user does not have that control. In a web browser you want the first scenario while on servers the second scenario may be acceptable or even preferable.
Re: (Score:2)
Yes, but in environments where people care about security the source code is compiled by the user or someone trusted by the user, and that is usually not the developer.
Controlling the security perimeter without the ability to simply modify the code also opens you up to permission bribery. You either give the software the permissions it wants, or it won't run.
Security (Score:2)
The only way for this to be "secure" is to turn it off. Permitting the execution of arbitrary Remote code is inherently a bad idea.
Re: (Score:2)
Permitting the execution of arbitrary Remote code is inherently a bad idea.
I'm sympathizing with this point. However, how would you execute code that you want to execute? Would you instead prefer to have to download, compile, and install a native application that accompanies each website? And even if so, how would you go about compiling an application that uses the Cocoa API for your computer that's not a Mac?
In the Olden Days ... (Score:2)
Back in the mid 1980's this "new technology" was called p-code. It hasn't changed much (or at all, really) since then.
Big tech wet dreams (Score:1)
The trade-offs are still there (Score:2)
The problems get worse because you have even less of a clue what system you are running on and even more abstraction layers in between. Web-assembly is nice as a generalized application-level sandbox, but performance is going to be a permanent problem in anything that is real-time (i.e. user interactions).
Re: (Score:2)
User interactions are about as far from real-time as you can get. By computer standards, humans move at a glacial pace. Even a fast typist takes a couple of milliseconds per character typed, and mouse interactions are orders of magnitude slower than that. Even a slow computer running unoptimized Javascript can keep up with a human when it comes to the UI as long as it isn't completely stupid about things (eg. don't redraw the entire document every keypress, don't require a network transaction every time the
Re: (Score:2)
User interactions are about as far from real-time as you can get.
You need to look up the definition of "real-time".
50 ms vs. 1000 ms (Score:2)
A form submission followed by the ensuing full page reload and reparse delivers a remotely calculated result in 1000-2000 ms.
Script in the browser delivers a locally calculated preview in 50-100 ms.
This difference in responsiveness should be fairly obvious to the user.