The binary format that Blinkenlights executes is x86_64. The binary format that it generates for the purposes of JIT is x86_64 or aarch64. I'd like to add WASM to the list of JITable formats if it's possible. Currently, only about ~10 lines of handwritten assembly needed to be written per target architecture. Blink also needs a way to generate functions calls, plus an instruction length decoder. I currently know very little about WASM, but if someone else does, I'm hoping I've made it relatively straightforward to contribute JIT support.
Coming soon: web browser in an OS emulated in your web browser, to do CORS/XSS/MITM attacks. At 116kb and especially if you add JIT support, with a bloated site you won't even know it's being emulated!
>Coming soon: web browser in an OS emulated in your web browser,
That would mean a Nuclear War, most of Silicon Valley to be inside Exclusion Zone, and millions of refugees running for life off the coast of Australia.
It's not really a big advantage over existing attacks.
You still need the user to be on a domain controlled by the attacker, so a user will be able to spot that e.g. they're not on their real bank website if they just look at the URL. And there are already attacks which emulate the entire look and feel of a real bank website and you can only spot with a bad URL.
The key benefit of this approach is that you can put another website into your website like an iframe, and have full access to the website within your site (including e.g. reading and injecting JavaScript). But your site is still sandboxed, and users still have to be tricked into going to it in the first place. Then they need to be tricked into using the real website, inside the fake website, which at this point many people are smart enough to not do anyways.
I'd love to integrate this into my desktop environment in the browser "OS" (https://github.com/DustinBrett/daedalOS). I already have v86 (https://github.com/copy/v86) for running general x86 iso/bin files and BoxedWine (http://www.boxedwine.org/) for 16/32 bit exe's. It would be cool to be able to drag and drop a Linux binary and just run it. I tried to do this with box86js (https://github.com/raoofha/box86js) but had little luck. Although as a non-Linux user, I am not sure where to get good examples/tests of binaries.
Any luck so far? After reading through the GitHub discussion it seems like it could be hacked into Daedal, some folks in there had workflows for compiling the wasm binary.
Thanks! I actually am just looking into this now. It looks like a lot of progress is being made (https://github.com/jart/blink/issues/8#issuecomment-13832849...). I will follow this closely and try and integrate something as soon as I see some good demos or a way to get a POC up. Thanks for the support!
Justine here. I'm an avid Hacker News reader. I think Zig is awesome and I'd love for my projects (e.g. Cosmopolitan Libc) to support it. What makes that challenging is Zig doesn't depend on the C library and instead directly talks to the kernel ABIs. The Zig team might be able to add support for building Zig apps on the Cosmopolitan platform, but it's less likely to happen than other languages like Go, where we've already received the green light from the Go team for a GOOS=cosmo port. As for Blinkenlights, if Zig produces a static binary which doesn't assume a 4096 byte page size, then your Zig programs should work in Blink. If that's not the case, email me the logs and/or executable in question, so I can make sure Blink has the features you need. Please note that Zig has had some roadblocks surrounding the system page size https://github.com/jart/blink/issues/14
Author of Blinkenlights here. I'm a professional amateur so I do everything for fun. I think it's fun to create command line Linux programs. I want to be able to share the programs I've made with other people. The browser provides an environment for running software that's safe and easy. The problem is that most existing solutions for running Linux programs in the browser require emulating the operating system too. So I built a program that implements the x86_64-linux abi, which is very small. That way when myself and others share the programs we've written, they'll load fast and download fast.
As you note browsers are already a capable platform, so a compact compatibility layer is good way to add support for linux binaries. ABI virtualization really deserves to be more popular as an alternative or complement to containers and VMs. Perhaps it hasn't caught on (besides Proton/WINE) because there isn't a semi-standard format/platform like docker or virtualbox.
Haven't multiple people on HN built simple direct GUI libraries that work natively and on wasm? It would be cool for apps and game binaries with (sound, graphics, networking, controller support...) to be portable across linux and web (and probably windows, macos, android, etc.) with a compact compatibility layer.
I've currently been focusing on making terminal user interfaces work well across personal computer, server, and browser platforms, because rich ANSI TTYs (like Blinkenlight's TUI) is a problem that's tractable for mostly one individual to solve really well. Doing the same thing with GUIs would require millions of dollars of resources and even then, it'd be unlikely to have a native look and feel.
TUIs are great and underappreciated in my opinion.
Another thing I wish were used more is character-mode graphics such as line-drawing, semigraphics, and various unicode symbols; I also wish more terminal emulators supported inline images - often I don't want to start up a new app just to plot something.
Agreed about native look and feel, but I don't think GUIs are intrinsically huge and intractable. Consider the various immediate mode GUIs posted on HN (Nuklear, Imgui, etc.) as well as the original Mac toolbox, which fit in 64K of ROM.
Thanks for the reply and for the interesting projects and posts!
WebRTC lets you send messages point to point, you could tunnel over that, but no, arbitrarily sending packets from inside the users firewall isn’t going to happen.
You could also open a websocket connection back to a specific host and proxy raw tcp though that. But I wouldn’t be in any hurry to run a public proxy.
Right, but the traceroute would egress via the proxy, not from the users machine, which would be unhelpful.
Yes, there's absolutely good uses for being able to issue regular network packets from a browser, but there's also some quite serious misuses, so we can't have it.
All that's needed is a way to feed a single file/folder to the executable and you've fixed computer security by giving us N2E {Need(ed) To Execute} security.
I can't be the only one reading this and thinking "wow, this sounds terrible," right? This is certainly very cool as a tech demo but why would anyone want the websites of tomorrow to be delivered as opaque ELF binaries, running via emulation, in a virtual machine inside my browser? This sounds absolutely insane to me.
It was already bad enough when websites started shipping giant, obfuscated Javascript bundles circa 2010. Now we're enabling running arbitrary x86 binaries for websites and no one bats an eye?
If you think about it it's no different than wasm already.
And wasm has been accessible for at least 4 years now, and yet nobody has given up react and typescript.
wasm is being used to do compute heavy work efficiently, and giving that data back to js. and this will allow doing that but with the 60 or so years of unix programs that already exist. code reuse to the highest extent. how cool is that?
> Build wasm/emscripten packages with conda/mamba/boa. This repository consists of recipes for conda packages for emscripten. Most of the recipes have been ported from pyodide.
> While we already have a lot of packages built, this is still a big work in progress.
This in particular is a collaborative effort of multiple contributors. See the discussion on https://github.com/jart/blink/issues/8 for the emscripten/wasm port.
Trung Nguyen and Fabian Vogt are two of the unsung heroes who put a lot of work into helping me get Blink running in the browser. Their support is what made this project successful. You can visit their GitHub profiles here: https://github.com/trungnt2910 and https://github.com/Vogtinator
[^0]: https://wingolog.org/archives/2022/08/18/just-in-time-code-g...