
The Bytecode Alliance: Building a secure, composable future for WebAssembly - markdog12
https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/
======
JoshTriplett
I'm one of the folks working with the Alliance, and I'm incredibly excited
about WebAssembly outside the browser. Happy to answer questions.

Imagine extensions for applications or databases, written in any language you
want, with no ability to exfiltrate data. Imagine supporting a safe plugin API
that isn't just for C and languages that FFI to C, but works natively with
safe datatypes.

Today, if you want to be extensible, you typically expose a C API for people
to link to, or you embed a specific language like Lua or Python. Imagine
embedding a WebAssembly runtime like wasmtime, and telling people they can
write their extensions in any language they want.

~~~
Narishma
> Imagine embedding a WebAssembly runtime like wasmtime, and telling people
> they can write their extensions in any language they want.

Is that desirable? Won't it lead to a bloated mess with every extension
dragging in a different language runtime with it?

~~~
kaetemi
Web developers don't seem to have any concern about using gigantic quantities
of memory. Don't hire a web developer to develop for games. :)

~~~
StavrosK
It's almost as if spending time optimizing memory usage isn't worth it because
server RAM is cheap!

~~~
bpt3
What does server RAM have to do with modern web development, where the vast
majority of the work is done on the frontend?

------
vanderZwan
I was talking with a colleague today who mentioned that he had looked at WASM
for a particular use-case (file-verification IIRC) and had concluded that for
now the overhead of copying memory made it run worse than well-written
JavaScript. It is also my experience that the overhead of memory copying can
really put a damper on performance improvements.

Now, I get that sharing memory is a huge safety issue - it kind of inherently
breaks the sandbox, but when I see the "nanoprocesses" bit in the article I
worry about death by a thousand paper cuts (lots of tiny WASM module spending
more time copying data than processing it). Are there ways/plans to minimize
memory copies that don't conflict with the safety concerns?

~~~
JoshTriplett
There will be ways to memory-map files, share memory between modules, and
otherwise avoid copying memory unnecessarily.

Shared memory doesn't break the sandbox. Sharing all memory by default would,
but controlled sharing of specific memory doesn't. Think of it like inter-
process shared memory, rather than threads sharing an entire address space.

~~~
lambda
Reading through this, this sounds like mostly a capability based architecture,
with process isolation replaced with a statically typed bytecode in which you
can verify that each module can only use capabilities passed to it.

I was wondering why the focus on copying memory between the processes. It
should be possible to make capabilities which represent a pointer and a length
(and maybe an access mode), which could be used to give a process direct
access to shared memory safely. I don't know if that could be done with low
enough overhead for small objects, it's possible that there would need to be a
threshold below which you would just copy values to be efficient, but it seems
like exploring fat pointer capabilities would be worthwhile.

Memory mapping files or inter-process shared memory is the very coarse-grained
version of this, using hardware protection. I feel like it should be possible
to do something more efficient and finer grained with pointer capabilities and
the static type checking that is done to verify WASM during compilation, but
it may be a significant research project of its own.

~~~
tschneidereit
What you're describing will indeed be introduced with the WebAssembly GC
proposal:
[https://github.com/WebAssembly/gc](https://github.com/WebAssembly/gc)

For languages that can express unforgeable pointers as first-class concept,
that is indeed a very attractive, fine-grained approach. Unfortunately
bringing that to languages like C/C++/Rust is a different matter altogether.

Since we want to support those languages as first-class citizens, we can't
require GC support as a base concept, so we have to treat a nanoprocess as the
unit of isolation from the outside.

Once we have GC support, nothing will prevent languages that can use it from
expressing finer-grained capabilities even within a nanoprocess, and that
seems highly desirable indeed.

(full disclosure: I'm a Mozilla employee and one of the people who set up the
Bytecode Alliance.)

~~~
danielearwicker
That future possibiilty reminds me of
[https://en.wikipedia.org/wiki/Singularity_(operating_system)](https://en.wikipedia.org/wiki/Singularity_\(operating_system\))
\- where process/address-space isolation was replaced with fine-grained static
verification of high-level code (presumably not the first experiment in this
area).

~~~
tschneidereit
Indeed: that and many other things are prior art in this space. And there is a
lot of prior art for what we're working on—this is not meant as an academic
research project! :)

~~~
lambda
Yes, one of the answers I want to give any time someone asks "why will WASM
succeed when the JVM didn't" is that there is 25 years more experience and
research to draw upon.

~~~
pjmlp
And yet bounds checking access validation was left out of the design,
something that most of previous research projects took care to taint as unsafe
packages when present.

------
azakai
In my opinion this is a fascinating approach, and it may end up transforming
our industry.

But the main question I've had is how big the overhead is, specifically since
modules don't share their wasm Memory. That means data will be constantly
copied between them. Compared to regular static or even dynamic linking, that
may be a noticeable slowdown.

~~~
JoshTriplett
> specifically since modules don't share their wasm Memory. That means data
> will be constantly copied between them.

We're working on that. We want to make it possible for modules to share memory
in a controlled way, without giving access to their entire address space.

~~~
azakai
Interesting! Is that written up somewhere public?

~~~
JoshTriplett
Some of it; see [https://hacks.mozilla.org/2019/08/webassembly-interface-
type...](https://hacks.mozilla.org/2019/08/webassembly-interface-types/) for
the starting point that this will be based on.

~~~
azakai
Oh, where? I don't think I see anything about controlled memory sharing there,
but I guess I missed it. Which section is it in?

~~~
JoshTriplett
It isn't yet, that work is still in progress. WIT is just the starting point
that this would be based on.

(Sorry for the lack of more concrete information, documentation is still in
progress.)

~~~
azakai
I see, thanks. Curious to learn more when it is public.

------
Ajedi32
This is great. I've been waiting for a module-level permissions system for a
while now; it definitely seems like the best approach to mitigate supply chain
attacks.

Hopefully once WASM has demonstrated the principle other languages will
follow. This seems like it'd be especially useful in the JS ecosystem, where
many modules are already small enough that they'd likely be able to run with
no permissions at all.

------
nabla9
JVM was supposed to be this. Gosling said publicly that JVM is more important
than Java. .

Many things went wrong. Microsoft was actively sabotaging JVM. They
implemented very fast JVM for Explorer and their operating system that
intentionally broke the JVM 1.1 standard. See Sun vs Microsoft 1997. Microsoft
lost and paid damages. .NET was created to do more damage.

~~~
jdance
I like the JVM and have done lots of code for it, but the java
download&install / setting up PATH / non native gui-look / no exe-files /
should i get se/ee/jre/sdk etc etc must be a big contributing factor to its
lack of being more popular (client side). A lot of the experience has been
clumsy, ugly and unintuitive from the start

~~~
pjmlp
WebAssembly developer experience is also not the most friendly one, with its
mix of toolchains, specially if one is on Windows.

Oh, and debugging is still at printf level style and reading raw bytecodes.

~~~
callahad
> _debugging is still at printf level style and reading raw bytecodes_

Wasmtime has had support for source-level debugging via lldb or gdb for a few
months [https://hacks.mozilla.org/2019/09/debugging-webassembly-
outs...](https://hacks.mozilla.org/2019/09/debugging-webassembly-outside-of-
the-browser/)

~~~
pjmlp
That doesn't look like production ready, nor integrated into browser developer
tools.

------
devwastaken
There should not be a 'browser wasm' and a 'non browser' wasm.

The wasm committee made many mistakes by treating it as an idea on paper, and
not writing the actual implimenting software.

This has resulted in significant fragmenting of implimentation, each less
trustworthy than the last.

If any software is going to advertise safety, it must prove it. That's done
through the feedback cycle and careful development. The only ones that have
this are in browsers.

Yet browsers have their own dubious implimentation, integrated with their
JavaScript environment.

Unless wasm decides on a set of standard runtimes that become trustworthy
there will not be a wasm outside the browser.

For example, when I search for python, I get python. There's still other
pythons, but there's _the_ python. This is true of all other software used.
Wasm is failing to do that.

~~~
dgellow
Try searching for C, C++, or even SQL or Javascript. You will quickly see that
you don’t have “the official implementation”, because that’s not how things
work in practice when considering well standardized and widely used software.

~~~
devwastaken
You're mistaking written standard for implimentation standard. You only need a
standard in practice.

All of those things you've listed have only a few big players, with enough use
and feedback cycle that there can be multiple different implimentations.

Those different implimentations are very similar. There is not a different C
to compilers, they have their own quirks, benefits, and target different
systems.

JavaScript is the least selective of any language, you will only find runtimes
for it's modern versions in browsers Typically V8 or safari. V8 has become the
effective standard.

SQL has multiple big implimentations that deviate completely. This has a lot
to do with marketing, and the fact data storage/retrieval is a significantly
diverse section of computer science.

In each of these known technologies there is a well known, well backed, named
software project that people use it's name synonymous with it's supposed
standard.

Wasm doesn't have this, and that's because the implimentations took place in
browser, which afaik did not impliment a unique engine to it. It just
integrates wasm instructions to their js instructions.

Which then led to there being dozens of different self called 'safe'
implimentations. None of these have the users, time, and open source community
necessary to know this. Which will inevitably lead to exploits.

Given that situation, the only way wasm is going to live up to its goal of
safety is backing a well made runtime.

The problem of safety is what makes this very different from other software.
Your own code with bugs is an annoyance, and maybe you can't do what you
wanted. But code that is meant to be safe that instead allows for damage to
you, your company - that deserves a much higher level of scrutiny.

------
sparker72678
Super cynical, I realize, but whenever I see the description “secure by
default” for something computer related, and they don’t mean, “we unplugged
it,” I assume what they really mean is, “we made the code so complex we can’t
find the problems.”

~~~
naasking
Instead, they mean something sensible: that permission has been linked with
designation as per capability security. Adding feature extensions are thus
linked with the authorities required to implement those features, and the
modules implementing those features can't do anything behind the scenes.

So you would no longer be able to amplify a string value into a file
descriptor as you can in systems with ambient authority (which is nearly every
system in widespread use today).

So "secure by default" here means, "programs conform to least privilege".

------
bestouff
Don't take it bad, but it looks like the java launch a (long) while ago. What
makes wasm better than java ?

~~~
JoshTriplett
The toolchains for building WebAssembly from numerous languages, for one
thing. The existence of an LLVM WebAssembly backend helps. (While eventually
there were other languages that targeted the JVM, for a long time if you
wanted the JVM sandbox you _had_ to write Java.)

WebAssembly also provides a fine-grained API surface area; you can run a
WebAssembly sandbox with no external functions provided, or just a few.

WebAssembly's sandboxing isn't tied to the web; we're keeping all the same
security properties when running code locally, and we're protecting modules
from each other too.

Also, the WebAssembly bytecode format is designed from the beginning to
support many different kinds of languages, including languages that directly
store types in memory, rather than keeping everything as garbage-collected or
reference-counted objects on the heap.

~~~
beefhash
> The existence of an LLVM WebAssembly backend helps.

So why aren't people just shipping straight up LLVM intermediate language VMs
and instead go through wasm?

Incidentally, would you consider wasm as a destination language for virtual
machines for _obfuscation_? I.e. is it reasonable enough to implement it all
in about a week? Plus I fear like the decompilation/disassembly tooling might
be there too soon for it to be a real viable option, but maybe nobody's been
working on that yet.

~~~
est31
LLVM IR is an unstable format, changes a lot and only has one
implementation.So it's not well suited for a standard. Google actually did use
it for PNaCl but fortunately Mozilla prevailed when wasm was created. "Do what
LLVM does" is not a valid strategy. On a related note, I'm glad that Firefox
doesn't support the "Do what sqlite does" WebSQL api either, but Chrome
(sadly) does.

~~~
saagarjha
Plus it’s not really portable.

~~~
afiori
It is intentionally not portable.

------
pasttense01
And a key point: "Our founding members are Mozilla, Fastly, Intel, and Red
Hat"

Where are Google, Microsoft and the other big names you would expect?

~~~
big_chungus
> Where are Google, Microsoft and the other big names you would expect?

Those folks are the incumbents. What do they have to gain from joining? Google
especially has developed a colossal amount of tooling in-house that gives it
an edge over others; new tech may make the lives of competition easier. Ditto
to an extent for MS, though there, I suspect it's more bureaucracy and not
seeing anything to gain.

~~~
pjmlp
After all MSIL already supported multiple languages, including C++, back in
2001.

------
syrusakbary
First of all, congrats on forming the alliance!

> Imagine extensions for applications or databases, written in any language
> you want, with no ability to exfiltrate data

That's what we are working towards on Wasmer, the server side WebAssembly
runtime -
[https://github.com/wasmerio/wasmer](https://github.com/wasmerio/wasmer)

In fact, we already have a lot of different language integrations (maintained
by us and the community) and our software is the pioneer on the space.

Is there any reason on why you think is a good idea to do a side-alliance
instead of collaborating with us and the community so users and developers can
be the ultimate beneficiaries? (it's good, it just seems is not an alliance
made for the users, which it's a bit weird from my perspective)

~~~
npmccallum
Disclaimer: I'm from the Enarx project ([https://enarx.io](https://enarx.io))
which is associated with the BytecodeAlliance.

I think a good analogy is: wasmer is to qemu as BytecodeAlliance is to rust-
vmm.

Wasmer is a general purpose WASM runtime. But BytecodeAlliance is a place to
build tooling for the construction of runtimes (WASM or otherwise), including
special purpose runtimes. I think there is a lot of space for both in the
growing non-browser WASM market.

~~~
syrusakbary
Agreed! (regarding the non-browser WASM market)

Not sure if I got the analogy, but all I can say is that I'm very excited
about the Enarx initiative :)

------
AaronFriel
Does this mean we'll also have a mechanism like pledge(2) to assert that the
root nanoprocess or any privileged brokers only needs access to certain APIs,
and permanently close them?

¹ - [https://man.openbsd.org/pledge.2](https://man.openbsd.org/pledge.2)

~~~
JoshTriplett
The WASI and Bytecode Alliance approach is based on capability-based security,
granting only the access needed for a module to do its job.

~~~
tschneidereit
To expand on this, capabilities allow us to go further than pledge(2): it
enables selective forwarding of capabilities to other nanoprocesses, such as
only forwarding a handle to a single file out of a directory, or a read-only
handle from a read-write one, etc...

~~~
jedisct1
Capabilities are also more complicated.

I fear that at the end of the day, capabilities will have the same fate as
other sandboxing mechanisms: nobody will use them. And, just so that their
application works and avoid support burden, developers will tell people to use
a setup that enables access to everything.

pledge(2) and unveil(2) learned from the past and are way simpler. I really
wish WebAssembly had adopted similar mechanisms.

~~~
tschneidereit
Agreed, and there are a lot of UX questions to sort out. Many security
concepts took many attempts to figure out in full (or to the extent that they
have been figured out :))

One important aspect here is that this doesn't just target whole apps. It also
targets developers using dependencies: while it's desirable to restrict an
application's capabilities, there's a lot of value in developers only giving
packages they depend on very limited sets of capabilities. And that seems much
more tractable, given that kitchen-sink packages aren't what most people want
to use anyway.

------
gatestone
This is getting complicated. OS process management, threads and lightweight
pocesses, green field process control, virtual machines, containers,
sandboxing in n browsers with m different technologies, now this WASM
stuff..and orchestrating this all across the cloud and the global internet,
ending in homes and corporate machine rooms.

Enverywhere you have to think: who can load/run a module/process and from
where, how to authenticate and authorize, which API to give to it, etc...

A historical note:

Bell Labs Plan 9 had a universal OS level solution, that Linux has somewhat
adopted, but could not make general enough, partly due to the higher lever
ecosystem being stuck to old ways:

\- per process name spaces with mountable/inheritable/stackable union
directories and optionally sharebale memory (Linux light-weight process, LWP,
comes close, it was also historically copied from Plan 9)

\- Almosty all APIs (even "system calls") as synthetic file systems (Where do
you think /proc came from?)

\- which you could mount and access (efficiently) locally or through a secure
unified network protocol (9P)

On Plan 9 you could just run different parts of the browser (JavaScript
engine, WASM or anything) in a tailored limited LWP with limited mounts as
synthetic file system APIs...

Note that Docker kind of retro-fits Plan 9 ideas in Linux kernel to embrace
and extend the original ideas of Plan 9...

~~~
wahern
> Where do you think /proc came from?

UNIX 8th Edition ([http://lucasvr.gobolinux.org/etc/Killian84-Procfs-
USENIX.pdf](http://lucasvr.gobolinux.org/etc/Killian84-Procfs-USENIX.pdf)) and
SRV4
([https://www.usenix.org/sites/default/files/usenix_winter91_f...](https://www.usenix.org/sites/default/files/usenix_winter91_faulkner.pdf))

A better analogy would be /dev, but that was already part of Unix from the
beginning. Plan 9 is really about per process, user mountable namespaces
implemented by 9P-speaking user processes; basically what you said, sans the
origin of synthetic file systems and file-like objects.

------
Animats
The primary use case for WebAssembly is malware.[1] We're probably going to
regret letting WebAssembly into the browser. Because vendors won't let it be
locked down so much that it can't be used for ads and tracking. Which means it
has to allow malware.

[1] [https://www.tu-braunschweig.de/Medien-
DB/ias/pubs/2019-dimva...](https://www.tu-braunschweig.de/Medien-
DB/ias/pubs/2019-dimva.pdf)

~~~
shmolyneaux
Thanks for the reference.

Just so it's clear, the definition of "malware" used here is in-browser crypto
mining and obfuscation. Only 1 in 600 of the top 1 million sites use
WebAssembly. WebAssembly doesn't actually provide a new vector for malware.

~~~
mantap
WebAssembly is still very immature. It unsurprising that it has such a low
adoption right now.

I think the real problem with webassembly would be if it becomes _too_ popular
and starts to become a JS competitor rather than a complement to JS.

~~~
pjmlp
WebAssembly is the revenge of Flash/Java/ActiveX, but this time everything
will turn out perfect, as per WebAssembly advocacy.

~~~
mantap
Honestly, given the lack of tooling they have now, it is pretty much perfect
from a user's perspective. You are only going to use WASM if you absolutely
need the performance. It's just too painful otherwise.

~~~
pjmlp
Well, better take care which sites you visit.

[https://www.infoq.com/news/2019/10/WebAssembly-wasm-
maliciou...](https://www.infoq.com/news/2019/10/WebAssembly-wasm-malicious-
usage/?itm_source=presentations_about_WebAssembly)

~~~
BubRoss
Your link basically says that less than 0.01 _percent_ of the top one million
websites have webasm cryptocurrency mining. There is no mention of any
security flaws. A webasm miner would just eat up a single core while the page
is open.

This doesn't seem like much of a red flag to me. If one out of every ten
thousand unique sites I visit uses one hypercore while it is opened that isn't
going to keep anyone up at night.

On the other hand full video editors, image editors, CAD, 3D content creation
programs, silky smooth 3D games, custom video codecs and more have already
been made possible due to webasm. Not bad huh?

~~~
pjmlp
Not bad at all, for something that has been possible in Java, Flash, ActiveX,
PNaCL before.

Thanks to service workers, the miner won't go away when you close the browser,
as by default settings (which normal users don't even know they exist) service
workers run on their own processes.

------
rkeene2
One of my next projects is to create a Tcl package for webassembly that will
let other extension authors compile their packages targeting WebAssembly and
be able to use those compiled binaries on any platform.

~~~
JoshTriplett
That sounds great! I'd love to hear more about that. Are you looking to
support extension of Tcl with WebAssembly, or using Tcl inside WebAssembly?

I think wasmtime would likely be a good fit for your use case; you could
either use the wasmtime C API, or use Rust to bind to Tcl and to the wasmtime-
api Rust crate.

I've found it quite easy to embed wasmtime and run a simple WebAssembly
module.

See [https://github.com/bytecodealliance/wasmtime-
demos](https://github.com/bytecodealliance/wasmtime-demos) for some samples of
how to do so.

~~~
rkeene2
This is going to be a Tcl extension named "webassembly" that then allows you
to load other Tcl extensions that are compiled to WebAssembly.

Right now Tcl loads binary extensions using the "load" command, this will load
a shared object (.so, .dylib, .shlib, .dll, .a, whatever your OS supports for
runtime loading) and call <ExtensionName>_Init.

My plan is to create a new command named "webassembly::load" that will open a
WebAssembly module and provide ... some way ... to call <ExtensionName>_Init
as well as some way for the extension to make calls back the ~200 Tcl API
functions and some selected other APIs per platform (Solaris, AIX, FreeBSD,
Linux, Windows, macOS, HP-UX, etc).

Additionally, a mechanism (probably in the form of an SDK) for Tcl Extension
maintainers to compile their extension targeting being loaded by
"webassembly::load" with the APIs mentioned above being available. Most Tcl
extensions right now are written in C or C++.

~~~
JoshTriplett
Makes perfect sense. I look forward to seeing your work when it's ready!
Please feel free to ask if there's anything we can do to help, or if you run
into any areas where the APIs could be easier to use.

You may find the witx project
([https://github.com/WebAssembly/WASI/tree/master/tools/witx](https://github.com/WebAssembly/WASI/tree/master/tools/witx))
useful when writing the bindings from WebAssembly to the Tcl APIs.

------
maxk42
Real worried when I see phrases like "secure by default" that this will
involve some sort of security certificate or formal verification process which
a government or other malicious actor can use as a weapon against its enemies.

Is the security limited to sandboxing of the code itself or is there some sort
of verification process involved?

~~~
JoshTriplett
The security here is based on sandboxing code and providing limited
capabilities. If you're embedding wasm, you choose what capabilities to give
the sandbox. For instance, if a game wants to support mods via wasm, it could
give the mods APIs to the game world but not to the network or filesystem. A
database plugin might have access to interpret a database object handed to it
but not exfiltrate data over the network.

We're providing mechanisms here, not identity-based policies.

~~~
pjmlp
What about fixing the lack of bounds checking when multiple data elements are
mapped into the same linear memory block?

This leaves the door open for trying to influence behaviour of C and C++
generated WebAssembly modules, by corrupting their internal state via invalid
data.

~~~
saagarjha
If you give a sandbox a capability and then there’s a bug in it, there’s
always a chance that it will maliciously access those privileged resources.
The only way I can see of protecting against logic bugs like these is better
tooling.

~~~
pjmlp
Yeah, but then one should acknowledge those issues, and not advocate
WebAssembly as if there weren't hundreds of other attempts since the late
50's.

~~~
saagarjha
They don't mention them because their focus is on other aspects of safety.

~~~
pjmlp
Either one is actually serious about security across the whole stack, or not.

------
Hitton
>So how can you protect your users against these threats in today’s software
ecosystem?

>You could subscribe to a monitoring service that alerts you when a
vulnerability is found one of your dependencies. But this only works for those
that have been found. _And even once a vulnerability has been found, there’s a
good chance the maintainer won’t be able to fix it quickly. For example, Snyk
found in the npm ecosystem that for the top 6 packages, the median time-to-fix
(measured starting at the vulnerability’s inclusion) was 2.5 years._

Sometimes it looks like writers think that the average reader is complete
idiot. How is that supposed to be example? First they say that it takes long
time fix once the bug is found and as illustration they give period starting
with introduction of vulnerability?

~~~
hinkley
We can't even get software developers to use sane metrics. Good luck getting
Masters of Fine Arts people to use them property to describe software.
Especially when we've provided such a stellar example.

------
giancarlostoro
I saw a comment about this on HN before, forgot who it was by. But it was
interesting, someone mentioned the spec for WebAssembly is generic enough to
apply outside of the web. I'm suspecting we'll see languages converting on
node.js a la web assembly for back-end logic in your preferred language, but
in any runtime this includes NodeJS but also excludes it as we see future
runtimes. What's your view on this? Also, Aside from WebAssembly being in
every modern browser what do you think will be the next killer feature for
WebAssembly?

It would also be interesting to have an embedded WebAssembly plugin runtime,
much like Lua is used all over now that you mention all those examples.

~~~
JoshTriplett
> someone mentioned the spec for WebAssembly is generic enough to apply
> outside of the web

Absolutely. The spec provides a set of instructions and their semantics.
Browsers provide a set of common runtime APIs. Non-browser environments can
provide the sandbox with any API surface area they want.

> in any runtime this includes NodeJS but also excludes it as we see future
> runtimes

node.js is working on WASI support, and I'd also expect to see versions of
JavaScript that run _inside_ the WebAssembly sandbox. When we say "any
language", that includes people who want to run JavaScript.

> Aside from WebAssembly being in every modern browser what do you think will
> be the next killer feature for WebAssembly?

Shared-nothing linking; libraries that don't have to trust each other with
their entire address space. I see WebAssembly as the future plugin interface
for any software that wants to be extensible.

> It would also be interesting to have an embedded WebAssembly plugin runtime,
> much like Lua is used all over now that you mention all those examples.

wasmtime is easy to embed; it only takes a handful of lines to load a
WebAssembly file, hand it a few functions of your choice, and run it.

See [https://github.com/bytecodealliance/wasmtime-
demos](https://github.com/bytecodealliance/wasmtime-demos) for various demos
of how to embed wasmtime.

~~~
syrusakbary
Following up from your comment, if you want to start running WASI modules on
Node.js (or in the Browser) today, you can use this npm package! (same API as
future Node WASI integration)

[https://www.npmjs.com/package/@wasmer/wasi](https://www.npmjs.com/package/@wasmer/wasi)

------
muricula
How can I learn more about how nanoprocesses and the wasmtime sandbox work
under the hood? Searching the repo on github for common keywords doesn't turn
up much. Are nanoprocesses like Windows picoprocesses somehow, or are multiple
"processes" running in the same address space? If so, you can probably
exfiltrate data between nanoprocesses with spectre. Additionally, if you get
RCE in the wasm JIT (this happens all the time in javascript JITs), there's
nothing to stop you from ropping to gadgets to open your own sockets without
going through any in-process checks.

~~~
saagarjha
> or are multiple "processes" running in the same address space

Yes.

> If so, you can probably exfiltrate data between nanoprocesses with spectre.

Right, this is mentioned in the article. (TL;DR if this is a concern for you
don’t use the sandbox, at least not until someone’s figured out how to
implement timing protection.

------
seph-reed
Been working with web tech since 2000... something about WASM rubs me the
wrong way, at least for use in the web. It's probably the lack of human
readable source code (I'm not a big fan of minified code for the same reason).

If it wasn't so impossible to work with W3C, I think it would probably make
more sense for the web to work towards something like more strict, compilable
typescript. Then sites could download the source, compile, and cache.

------
cm2187
Stupid question from a non specialist. I see Intel in the list of parties.
Does that mean hardware acceleration for wasm?

~~~
JoshTriplett
Among other things, yes; we're contributing to the SIMD support, for instance.

~~~
markdog12
Anything beyond just the 128-bit SIMD yet? Last thing I seen on that was "Long
SIMD" from here: [https://webassembly.org/docs/future-
features/](https://webassembly.org/docs/future-features/)

And that was years ago.

Seems like an awful waste to have many millions of cpus with avx for instance,
wasted.

------
stefan_
This is historically the kind of thing that people think is very cool and
important, but has turned out to not matter at all. "Languages matter" must be
the biggest enduring fallacy of computer programming. It has an obvious
corollary in believing processor architectures are important.

~~~
weberc2
It matters a whole lot. There's lots of code written in various languages and
it's often prohibitive to use it in your own project because making the
languages speak with each other (especially if you have performance concerns)
is a lot of work. I don't expect WASM to make this trivial, but to say that it
doesn't matter is patently wrong.

~~~
gridlockd
I think the point is that your laundry list of features in your language of
choice does not really matter when it comes to adoption.

For instance, memory safety does not really matter so much that people would
stop using unsafe languages.

------
gwbas1c
Wait... I thought the CLR was supposed to do this? Or was it the JVM?

What's old is new again!

~~~
pjmlp
Or UNCOL, or Xerox Pilot and Dorado microcoded CPUs, or IBM z/OS and OS/400
language environments, or VMS multi-language backends, or PNaCL, or ....

~~~
dboreham
You forgot the UCSD P-System.

~~~
pjmlp
It is included on the .... :)

~~~
DonHopkins
...That reminds me of a cartoon I saw in an old Apple ][ magazine:

(One kid talking to another, with dad in the background hunched over an Apple
][.)

"Daddy's playing UCSD Pascal. That's the game where you try and see how many
dots you can get before it beeps and you say nasty words."

[http://bitsavers.trailing-
edge.com/pdf/ti/professional/p-sys...](http://bitsavers.trailing-
edge.com/pdf/ti/professional/p-system/2232399-0001_UCSD_p-
System_Program_Development_Software_Library_Apr1983.pdf)

UCSD p-System Program Development (p. 2-4)

While the compiler is running, it displays a report of its progress on the
screen in this manner:

    
    
        Pascal compiler - release level VERSION
        <   0> ...................
        INITIALIZE
        <  19> .......................................
        AROUTINE
        <  61> .......................................
        < 111> .......
        MYPROG
        < 119> ......................................
    
        237 lines compiled
        INITIALI .
        MYPROG ..
    

During the first pass, the compiler displays the name of each routine. In this
example, INITIALIZE, AROUTINE, and MYPROG are the routines. The numbers
enclosed within angle brackets, < >, are the current line numbers and each dot
on the screen represents one source line compiled.

------
rb808
Can you use wasm instead of regular js/html? I'm thinking for rich GUIs it
would be great, even just for company internal sites. I can't find any good
examples though.

~~~
code_code
I have a recent note that says (from HN id=21495338), try
makepad.github.io/makepad . My recollection is that this is such an example.

~~~
rb808
Nice! though confusingly its an editor that run JavaScript pages.
[https://makepad.github.io/makepad.html](https://makepad.github.io/makepad.html)

------
jeltz
One pretty annoying thing with WASM is that it is pretty hard to generate due
to requiring a structured control flow so anyone generating it must implement
relooper och stackifier. Is there any work on solving this issue?

[http://troubles.md/posts/why-do-we-need-the-relooper-
algorit...](http://troubles.md/posts/why-do-we-need-the-relooper-algorithm-
again/)

------
xvilka
Radare2[1] supports WebAssembly disassembling if anyone is curious about
compiled code analysis.

[1]
[https://github.com/radareorg/radare2](https://github.com/radareorg/radare2)

------
Narishma
Are those drawings supposed to be clickable? When I do so, it just opens and
immediately closes a new tab or window. Firefox 70 on Windows if it makes a
difference.

~~~
arendtio
Works for me. Opens a new tab with an image, e.g.:

[https://2r4s9p1yi1fa2jd7j43zph8r-wpengine.netdna-
ssl.com/fil...](https://2r4s9p1yi1fa2jd7j43zph8r-wpengine.netdna-
ssl.com/files/2019/11/featured-image.png)

FF 70 on Arch Linux.

~~~
Narishma
That's weird. In fact it does the same with your link, though I can open it in
the same tab. If I try to open it in a new tab or window, it just closes
immediately.

------
pjmlp
WebAssembly keeps trying to be the next UNCOL, it seems.

------
lone_haxx0r
What's the main difference between this and the Java Virtual Machine?

------
FpUser
Not in a mood of diving deep into technical details but forgive me for being
skeptical. This "secure by design" execution mantra makes me somewhat sick
after hearing it so many times over the decades.

