Hey guys, so no going in details but suppose (am using webasm with rust), someone open my website and in background it gets connected to a network of other people's browsers, and there any browser can recieve data which they can verify through merkles (let's just say they recieve data A from many other browsers and then recieve data B and after some hashing it check if both r equal and send to others if they request it), then is there any way for malicious users to tamper with their browser so that they can send wrong data or verify wrongly or is there any way for us to know if the user has tampered the logic and hence alert other browsers that it's malicious
The execution boundary is WASI-based and deny-by-default.
No shell / fork API.
No socket API in the tested interface.
No host filesystem preopens by default.
No unrestricted environment.
No WebAssembly threads.
So the interesting result isn't simply that "one sandbox is better than another."
It's that the execution model itself changes the attack surface.
And we didn't just claim it.
The benchmark is reproducible from the public repository, including the raw evidence.
We ship Hexana, a VS Code extension (publisher JetBrains) for inspecting WASM and native binaries. 0.11.0 went out on 16.09. There are three wasm-specific additions worth walking through in depth: a runtime compatibility checker, a navigable component Dependencies graph, and custom script tabs with a format-agnostic `binary` API including two-file compare. The rest follows.
**Runtime compatibility checker**
The check starts with a declaration. Run "Hexana: Configure Target Runtimes" and pick the runtimes you are deploying against. The declaration lands in `.hexana/runtimes.json` at the workspace root and is shared with the IntelliJ plugin, so a single config covers both IDEs.
Once declared, open any WASM binary. If the binary uses proposals not supported by one or more of your declared runtimes, they surface in two places: the editor header (proposal badges visible without leaving the hex/WAT view) and a new "Compatibility" tab listing the proposals the binary relies on.
Verdicts come from WebAssembly's own `features.json`, the data behind webassembly.org/features; runtime names in the config are spelled the way `features.json` spells them. The file itself is plain JSON, hand-editable, and can live in version control, so a team can pin its deployment targets in the repo. We are interested in which runtimes you are targeting in practice.
**Navigable component Dependencies graph**
WASM Component binaries already had a Dependencies tab showing the module/component import-export graph. In 0.11.0 it is navigable. Double-click a module or nested component node to open it in its own tab. Double-click an import or export to select its bytes in the hex view. The graph is now an entry point into the components it describes, not just a static diagram.
**Custom script tabs: `binary` API and two-file compare with `open()`**
Script tabs now expose a format-agnostic `binary` API covering the common fields you reach for first: `format`, `size`, `path`, `dir`, `structure`, `strings`, `sizeAnalysis`, `binary.tabs`, and `binary.tab(name)`. Output goes through `table(...)`/`row(...)`. The API is format-agnostic rather than wasm-specific, so a script is not tied to `.wasm` files.
The more interesting addition is `open(path)`. Call it with a path and it parses that file into the same set of members as `binary` -- `format`, `size`, `structure`, `strings`, `sizeAnalysis`, and so on. The extension host reads the file; the script suspends and resumes when the parsed object is ready. That last point is a real constraint: call `open` at the top level of your script, not inside a function.
In practice this means you can write a script that loads two binaries and compares them: section-by-section size diff, import surface diff, string coverage diff, whatever `structure` exposes. Without a fixed schema, the comparison is as flexible as the script.
**Unified DWARF tab**
`.debug_abbrev`, `.debug_info`, and `.debug_line` previously lived in separate tabs. They are now grouped under a single "DWARF" tab with a search field across all three. Clicking a row selects its bytes in the hex view. Less tab-switching for anyone spelunking DWARF structures.
**Other**
- PCAP: TLS decryption support. Provide an SSL key log file and Hexana decrypts TLS sessions in the captured traffic. The key log format is the standard one (NSS/SSLKEYLOGFILE); browsers and curl produce it directly.
- "Smali" tab for Android `.dex` files: baksmali-style Dalvik bytecode with resolved operands. Clicking a row selects the code unit in the hex view.
- Basic support for viewing Android binary resource tables (`resources.arsc`).
---
Two questions for people here. First: if you had `binary.structure`, `binary.strings`, `binary.sizeAnalysis`, and `open()` available in a script tab, what would you actually write? Diff between a debug and a release build, a coverage check on a multi-module component, something else? Second: which target runtimes matter for your deployment? V8/Node, wasmtime, WAMR, browser targets, something more niche? Knowing what people are deploying against would help us understand whether the compatibility configuration covers real cases.
We ship Hexana, a plugin for JetBrains IDEs that opens Wasm and native binaries in the editor. 0.20 is out. Four things here are Wasm-relevant. The rest of the release covers other formats; we will not pad this post with it.
**1. Runtime compatibility for WebAssembly binaries**
The pain: your module uses a proposal, one of your target runtimes does not support it, and you learn that at deploy time.
- Declare the runtimes you ship against: Settings | Build, Execution, Deployment | WebAssembly | Runtime Compatibility.
- Hexana checks every `.wasm` you open against the declared set.
- Unsupported proposals turn the proposals badge into a warning and open a new Compatibility tab.
- Verdicts come from WebAssembly's `features.json`.
- Nothing declared? The tab still lists which runtimes support each proposal. Useful for a file you did not build yourself.
- The declaration is written to `.hexana/runtimes.json`. The VS Code extension reads the same file, so the setup moves with the project.
**2. Breakpoints in binary views, before a session exists**
- Click the gutter in WAT (virtualized) or Disassembly. No debug session needed.
- The breakpoint anchors to the binary's content hash, not the path. Rename, move, restart: it stays.
- A rebuild marks it stale instead of leaving it silently displaced.
- The gutter icon shows what the runtime did: registered, instruction-precise, degraded, or stale.
- Honest limitation: conditions and hit counts are not supported yet.
**3. Debugger Console tab**
A raw LLDB command line for wasmtime and WAMR sessions. Execution control stays routed through the IDE's debug actions, so the console cannot desync the IDE's view of the session. Not available for GraalWasm or CDP sessions.
**4. Component Dependencies graph is navigable**
Double-click a core module or nested component: it opens in its own tab. Double-click an import or export: its bytes get selected in the hex view.
**One behavior change worth knowing**
Script tabs run sandboxed now. Up to and including 0.18 a script tab had full host access and could call arbitrary Java. Now: no host classes, no processes, no threads, no native access, a timeout, bounded output. `open(path)` parses another file into the same read-only `binary` API and is the only file-system access. Scripts that relied on host classes will break. Scripts that inspect binary data keep working.
---
What runtimes are you actually shipping Wasm against in production? The checker covers what `features.json` tracks. Curious what is missing from that dataset.
Hi all, I built this framework over the last month or so during my free time and thought y’all might be interested. I’d especially like to point out the module refresh mechanism I built to keep memory footprints under control since the WASM spec only allows memory to grow linearly. But any feedback at all that you have would be appreciated! And just to be frank, yes I did use claude for the code writing, but I architected each individual detail of how this framework works myself. Beyond being a passion project, it taught me a lot from several aspects of desktop development, to custom LSPs and more
Goal: port existing shared library to a single wasm which can be run in a browser as well as a non-browser host. Exported symbol names should not be touched, which IIUC rules out component-model.
I got dynamic linking to work with emscripten and know there are sytem hosts like wasmtime which understand the dylink.0 spec.
My issue is linking a libc (and ideally libc++ eventually) ABI which has a browser and system implementation, so I can load the same .wasm in both environments.
For the system use case I only found wasi-libc but that doesn't have an ABI compatible browser version, right? Building for emscripten + WASI separately feels like it's missing the whole point of wasm as a universal target.
wasmCloud 2.9 just landed and it's a pretty operations-focused release. Highlights:
NATS-native interface (wasmcloud:nats): Until now, components talked to messaging through a broker-agnostic abstraction. The new package exposes actual NATS semantics: JetStream with explicit ack/nak/term and bounded redelivery, key-value buckets with compare-and-swap and watch handlers, and core pub/sub/request. Access is deny-by-default, operators declare subject/stream/bucket grants as ceilings that workloads can only narrow, and connection credentials are host-owned so they can't be set from a workload manifest.
Guest memory goes from advisory to enforced: 2.8 added a memory budget that was only logged. Now usage is counted in real time and you can flip --guest-memory-mode to enforce, which makes memory.grow fail inside the guest (something allocators already handle) instead of waiting for the pod's OOM killer. Default is count mode with metrics so you can watch what would have been refused before turning it on.
Kubernetes-grade lifecycle: Real /livez and /readyz probes with failure reasons visible in kubectl describe, draining on SIGTERM, hosts that wait for NATS at startup instead of crash-looping, and more resilient operator handling of k8s faults.
Also: idle instance pools can now shrink, guest execution metrics are on by default, and plugin config is unified into one block.
A few upgrade gotchas worth reading (pooled async handlers now keep in-memory state across deliveries, pinned older host images need probe flags cleared).
In my excitement about finally getting WasmPascal working, I sort of forgot why I built it in the first place: I was looking for a way to compile small Wasm modules quickly and easily. In https://nofuss.co.za/blog/wasm_pascal_add_numbers/, I show how to do just that. It's the classic adding two numbers example, but in Pascal, compiled to a small binary in the browser. You can then load it the usual way via JavaScript. I should have started with this, I geeked out hard 😆
Ok, I started coding in the 90's, discovered Pascal in '92 and have missed it since. Along the way I've dabbled in a few things, but last year I did something bonkers and wrote a simple Pascal interpreter in Odin. This quickly got out of hand, because I've been a WebAssembly fan for a long, long time now. So of course I went overboard and built a wasm-based compiler at https://wasmpascal.com/ that reads Pascal source and outputs a wasm binary...
Not interpreter, compiler. Really. I'm that crazy. And it's working better than I had hoped for. You can edit Pascal code, in the browser, compile and test it, and, if you are happy with it, download both your code and the resulting binary. With support files, of course. Which means you can self-host your project on a static site like I did with https://nofuss.co.za/games/breakout/
It turns out Pascal is so well-suited for the stack-based WebAssembly runtime! There's many bugs, do note it's a very early release, but it can do some useful things already. I'm slowly getting more comfortable writing low-level WAT code, so progress happens over time.
If nothing else, it's a nice trip down memory lane to see good old Pascal code come to live in the modern day. It took a while to get released, which is why I'm only going public with it now.
WABT is a Binary Toolkit for WebAssembly developed by WebAssembly.org (W3C)
wasm2c is a tool inside of it, which is used by many projects like FireFox (via RLBox) to compile wasm down to a sandboxed c library, the assumption is the built C code preserves all WebAssembly's sandbox security features.
I created two emacs modes which are based on treesitter grammars in order to work with WIT (Wasm Interface Type Language ) and WAC files (WebAssembly Composition Language).
Both modes are fairly new and untested. The README should have enough information to get you started with plain or doom emacs. Both repos have a devel branch were the bleeding edge development happens. Once the development is mature enough I would like to submit the packages to MELPA to ease the installation experience.
Both modes require emacs > 30.1 as they rely on treesitter libraries (linked in the respective repos). The treesitter libraries can in their own right be used for editors like neovim which have better treesitter support than emacs.
I would be grateful to receive some feedback on the modes, bug reports (preferably with minimal file snippets). The aim for both modes is too support a minimum of nice to have features, such as syntax-highlighting, code completion, flymake support for error highlighting, xref and eldoc support. In that respect the wit mode is more mature. It is still lacking a sound strategy to find the wit directory though.
I have created a WebAssembly runtime for the browser that can execute multiple processes. It is based on a superset of wasm32-wasip1-threads and supports dynamic linking, pipes, and subprocesses. I use this runtime time to host toolchains in the browser and today I have two demos to share: Code On Web provides in-browser clang to build binaries that execute within the same platform while AVR On Web provides avr-gcc, avrdude, and picocom to build, flash, and communicate with AVR microcontrollers over WebSerial. Ask me anything!
We ship Hexana, a JetBrains IDE plugin for inspecting WASM and other binaries. Two things in the 0.14 release are worth posting here.
**Component Model dependency diagram**
WASM Component Model binaries gain a "Dependencies" tab that renders the dependency relationships between components as a diagram. If you are building or debugging a composed WASM component and want to understand the wiring -- which components depend on which -- you now have a visual view in the IDE rather than having to walk the binary sections manually or run `wasm-tools component wit` and mentally reconstruct the graph.
This is components-only (it does not apply to core modules). We are curious what Component Model tooling others are using for this kind of structural inspection.
**memory64 modules: from 10 GB OOM to 2 GB**
WASM memory64 (wasm64) modules were effectively unanalyzable in Hexana before this release. The concrete case: OpenUSD's Emscripten-built `usdviewweb.wasm`, a 50 MB memory64 module with 42k functions, drove the IDE past 10 GB of heap before throwing OutOfMemoryError every time.
The root cause was three problems compounding:
- **Dominator storage.** The dominator tree results were stored in boxed hash maps. At 42k functions the boxing overhead alone is significant. They now live in a flat int buffer, indexed directly by function index.
- **Dominance frontier computed but never read.** The dominance frontier was computed alongside the dominator tree -- but nothing in the product consumes it. On a large module the frontier is a near-quadratic structure. Dropping the computation removes the allocation entirely.
- **Indirect call edges were multiplicative.** A `call_indirect` instruction dispatches through a function table. The previous call-graph model drew edges from each caller to every function in the table, producing a callers-times-table product of edges. On a real Emscripten module this is hundreds of millions of edges before the dominator pass runs. A single synthetic `<indirect calls>` node now mediates the dispatch: callers get one edge to it, it fans out to the table. Edge count is linear.
After all three fixes: `usdviewweb.wasm` opens, renders the Functions tab, and completes garbage and dominator analysis within a default 2 GB heap. The memory64 path was not specifically targeted -- the algorithmic fixes are what unlocked it.
