WebVM: WASM virtual machine in browser with networking via Tailscale | Hacker News Reader

WebVM: WASM virtual machine in browser with networking via Tailscale

leaningtech.com

226 pointsxrd59 comments

Makes me think of the excellent JSLinux by Bellard, https://bellard.org/jslinux/. Runs Linux / Windows 2000 in the browser with internet and file storage. Or another one which can boot a custom iso you provide, http://copy.sh/v86/

Direct link to the live version: https://webvm.io

Support/Discussion: https://discord.leaningtech.com

Lead dev of CheerpX/WebVM here. Happy to answer questions.

Very interesting demo; a couple of q's: how is it qualitatively different from Fabrice Bellard's JSLinux, apart from the speedup? and what is the use case?

I would argue that the speedup is critical for being practically useful.

In terms of use cases: education, testing, documentation, distribution of applications, safe execution of legacy applications... and there are surely many others

This is amazing. I think the virtualization engine CheerpX is closed source (https://www.reddit.com/r/programming/comments/qv75q3/cheerpx...)

I can’t help but think of Ian Malcolm.

“ so preoccupied with whether they could, they didn't stop to think if they should”

well, "nature always finds a way", as they say...

IIRC Tailscale tries to keep their cost at minimum with high NAT traversal success rate so that DERP servers are rarely required. But this approach would always require using DERP servers which would increase tailscale’s bandwidth cost a lot if widely used. I wonder how Tailscale think about this

Tailscale is currently building native wasm support into their product.

https://github.com/tailscale/tailscale/commit/6f5096fa61f36e...

so we can get back to where we started by putting another layer on top.

its unfortunate one has to result to this, but unfettered access is a lot more palatable on a private network

There is a lot of weird things I'm gonna do with this. 2023 is going to be a very weird year.

Nice work with go. There is this for python in webassembly as well : https://pyodide.org/en/stable/index.html

This is quite impressive. I've never heard of WebVM/CheerpX before. I wonder how it compares to v86[0].

[0]: https://github.com/copy/v86

Hi, lead developer of CheerpX here. The main difference is about the level of performance we can reach thanks to our sophisticated JIT engine. Feel free to try running a payload yourself in v86 vs WebVM to see the difference.

My latest talk on the topic is available here: https://www.youtube.com/watch?v=rI7opIKW_z4

That was underwhelming, not much really said about the JIT other than "we do DCE".

WASM, yes. Tailscale, yes. In the browser, sure, I'll take it.

But what I really want is a capability-based WASM sandbox runtime (like wasmtime or workerd from Cloudflare) that provides an API that lists people that it can send messages to (through Tailscale.)

I configure the runtime with my contacts, and say which apps can communicate with which people.

And then a Dynamic DNS-like system for me to have an identity key, and look up the servers to find them. In case my contacts need to migrate to a new server. Maybe Tailscale already does this?

The runtime keeps the apps updated (like Sandstorm.io).

why do you want this?

I'm supremely impressed by Sandstorm.io, but I think it was designed kind of like an old BBS. One server, letting users come to it.

What I'm describing, I think could be the basis for federated services.

I imagine implementing RSS feeds and RSS Aggregators on top of a system like this.

And lots of other services, too.

I like the idea of it being capability based and sandboxed, because then I can feel safe running a service you wrote on my machine.

And I like the idea of all of the networking being in the framework, rather than being implemented in each app. Just like Sandstorm.io takes a lot of the problems of sharing out of each app.

The way this article ended up with WASM + Tailscale in the browser seems like a great way for a client to talk to a server based on WASM + Tailscale, like I want. So then my phone can connect to my home PC, running these federated services. I can picture implementing Google Photos on top of that. With sharing, too.

Maybe it would be nice if tailscale could "peer" with other whitelisted networks that agree and share selected services/endpoints between peers. Given this plus a namespace system (DNS?) you'd be pretty close to a usable, secure, decentralized, p2p mesh network.

Edit: oh it's already a thing now? https://tailscale.com/kb/1084/sharing/

https://matrix.org/

We at the Enarx project (https://try.enarx.dev) plan to implement precisely such a network policy in the very near future.

cool idea, alien-feeling name

"Enarx": Reads like "e-narks", the "e" from email (rather dated as a prefix these days, but we're all used to it), and an intentional misspelling of the plural of "nark", as in one who reports information to the authorities, a snitch, or tattle-tale.

that’s not helping

So to speak, webvm will have at most 4gb address space and that’s bad :)

We’re bringing RAM bank swapping back!

Just open another browser tab?

We keep seeing more and more abstractions, but unfortunately they are the wrong abstractions. We need working process isolation, not endless VMs inside other VMs. We need a logical layer on top of TCP/IP, not crazy complicated VPN schemes. Etc. This is completely obvious to some people, and seems completely incomprehensible to others. Unfortunately, the companies with resources are mostly staffed with the latter.

Mind expanding on this? Why are better protocols incomprehensible? I find it hard to believe big orgs like Cloudflare, Google, etc. wouldn't be very interested in abstractions that save them or make them money, but I've been surprised before.

The problem is not that a superior abstraction exists that you can make money from, the problem is that you have to hire people who work well with that abstraction, and that is usually the impediment.

For example, I bet NixOS would alleviate a lot of pain with development and deployment, but the learning curve is steep, poorly documented, and still in need of work, and the community is just not very big yet.

Okay, this is taking computers too far.

I say this doesn't go too far enough!

I'm waiting for someone to comment that because some programmer was lazy enough to use Go instead of C or C++, Tailscale module takes 16 MB, when the entire CheerpX VM was 6 MB. Just the stack is almost twice as big as the entire VM.

Why is it written in GO when it could have been written in C? Lazy programmers.

Why would it be written in C when it could be written in assembly? Lazy programmers.

This used to be a serious argument once, by the way.

"Structured programming" (AKA the 'for' loop, 'if' statements) had early adopters, and serious arguments over their wasteful inefficiency took place at industry events.

You should read what John von Neumann said about assemblers...

it was compressed to 3.5 mb

Projects like this are cool, but I can't help but wonder why?

What problem is this, or any WASM, solving? Why do we need a VM in the browser?

I think it's because people want to code in other languages besides javascript

What if the only thing you have access to is a browser, but you'd like to explore Clang, networking, etc?

This turns a lock-down old Chromebook into a box you can learn to develop on.

Interesting thought, but realistically what need is that serving besides curiosity?

Even chromebooks have real linux underneath, the scenario you're describing is so niche it's hard to imagine. IMO it makes much more sense to use free tier on a cloud provider

Not all Chromebooks do. Because their processor doesn't support it.

Think about education Chromebooks that get locked down, too.

Moving emulators and virtual machines to the Web can be handy for software preservation. The Internet Archive has a massive collection of games and applications that you can run right now, on any device with a browser, thanks to this kind of tech.

Also (speaking from 1st hand experience) some big companies issue laptops that are extremely locked down - with IT needed to install any software and only after it's been vetted. This gives a bit more liberty without crossing any of the security boundaries.

a “cross-platform” assembly format could, in time, make introducing new hardware architectures a bit easier.

for example, these guys link to a discord channel to chat about their work, but i can’t join it easily because even though Discord ships a Linux client, they only ship it for x86 and not arm. further down the road, i’d like to try some RISC-V devices: that’ll be that same experience times ten. a portable assembly format has the chance to overcome this.

Isn't Discord's desktop client just an Electron wrapper around their website? It seems like there might be an easier way to get that running on other platforms.

If I wanted the full-fat Discord app (rather than a browser website or PWA, or a third-party client Discord will ban you over), I'd look into https://github.com/SpacingBat3/WebCord (which I think isn't detected and banned, but I cannot guarantee this or that they won't rewrite Discord to the point you can get banned for using it).

They also ban for blocking the /api/science/ data mining endpoint.

Do you have any cases of people getting banned over it? It would be scary, uBlock Origin blocks /api/*/science and it would be terrifying if running an adblocker could get you banned from Discord.

Where have I heard this before?

https://en.wikipedia.org/wiki/UNCOL

https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut...

https://en.wikipedia.org/wiki/P-code_machine

https://en.wikipedia.org/wiki/IBM_i#TIMI

Not bothering to list all of them since 1958, WebAssembly is only the latest go at it.

hey i’m not saying it will or won’t succeed on that front — just that it’s a motivating factor.

but also, look at its neighbors. Vulkan/SPIR-V has made it standard to ship bytecode-level shaders (graphical or compute) which are device agnostic but still performant. even if we’re cursed to try this “architecture agnostic” stuff a hundred times, i don’t think we can say there hasn’t been any progress. that progress only comes from people trying, even if 9 out of 10 serious attempts are flops.

So far Vulkan/SPIR-V doesn't seem to be as successful as DirectX/DXIL or CUDA/PTX, specially in what concerns mature polyglot support.

We weren't unaware of these things. Wasm is the first low-level format to instantly have broad availability, becoming available in all web browsers in 2017. AFAICT none of the previous formats had low overhead platform-independent in-process sandboxing, and certainly none had a machine-checked proof of type system soundness.

So Wasm has a few legs up on what came before.

If we ignore PNaCL and CrossBridge.

As for how sound the type system is in the face of attacks at the Flash, ActiveX and Java applets scale, it remains to be seen, although there are already some USENIX papers slowly coming up regarding WebAssembly actual security.

It's not that we need a VM in the browser, but we just need a VM that's sandboxed in terms of security.

Other than JavaScript, what other way can you send arbitrary code to a device and expect it to run there? WASM is the only other option.

Don't buy it. A sandbox is a sandbox. Yes, javascript runs in a sandbox, but other technologies exist beyond javascript-in-a-sandbox.

This is just really inefficient: VM in WASM in javascript in a sandbox in a browser, is insane and will forever be slow due to complexity.

Fun for the lulz, but for the planet's sake I hope this doesn't get adopted.

Wasm is not implemented "in JavaScript", rather JS engines reuse important parts of their compilation pipeline to generate good code for Wasm.

noob here.. how does wasm creates socket connections, isnt wasm handles cpu only operations

Wasm cannot indeed do much beside manipulating it's own memory and pure computation. Anything interesting happens via "imports", which are arbitrary functions implemented in JavaScript.

The networking capabilities are implemented via a JS API (itself, compiled from Go to WebAssembly/JavaScript). This Go library connects to Tailscale DERPs via WebSockets to provide network access to the Tailscale network of each user. The broader internet can then be also accessed if an exit node is configured.

Reply on news.ycombinator.com