reage4e
The WASM interpreter developed by Microsoft for the Edge browser which has been added and enabled to Vanadium by default adds a huge attack surface.
No, that's completely wrong. It substantially reduces attack surface compared to the JIT. DrumBrake is an alternative to JIT compilation for WebAssembly. Vanadium isn't adding functionality not present in Chromium but rather is using a more secure and lower attack surface implementation by default. DrumBrake provides a far more secure implementation of WebAssembly compared to having the baseline JIT or all 3 JIT tiers enabled for it. In Vanadium, the JIT toggle is supposed to be a performance vs. security toggle and shouldn't lose functionality such as WebAssembly. Needing to enable full JIT compilation to use anything depending on WebAssembly would be a security regression, not an improvement. WebAssembly support is mandatory for a modern web browser with broad compatibility. Omitting WebAssembly support in the default configuration with no prompt to enable it isn't a serious option. Tying WebAssembly being available to whether JIT compilation is enabled also simply wouldn't make sense. Those should have nothing to do with each other. There should be a JIT toggle (performance vs. security) and a WebAssembly toggle (functionality used by sites as more than an optional performance optimization).
DrumBrake is clearly the lesser evil by far. DrumBrake is very clearly a more secure approach. That doesn't mean it won't have security vulnerabilities. The point is having fewer vulnerabilities along with being able to have more hardening enabled that's incompatible with JIT compilation. If we didn't have DrumBrake, then the JIT disabled default in Vanadium would become increasingly impractical until the point we had to switch it back to being enabled by default.
Functionality being available should not be tied to the toggle JIT. The JIT toggle should remain a performance vs. security toggle. Controlling whether WebAssembly is enabled shouldn't have anything to do with the JIT toggle since it exists both with and without JIT compilation.
Maybe this should be reason to remove support for Drumbrake in Vanadium, or at the very least allow users to disable it?
No, it wouldn't make any sense. The choice is between the whole baseline JIT and DrumBrake, not DrumBrake or nothing. DrumBrake doesn't mean anything to end users and it doesn't make sense to have a user-facing toggle to disable it. WebAssembly is what's adding the attack surface and is the functionality which should be possible to control, not DrumBrake. Support for disabling WebAssembly only when the JIT is disabled doesn't make sense. There can be a toggle for WebAssembly not tied to whether the JIT is enabled. WebAssembly is not simply a performance optimization where sites continue to work without it since it's increasingly uncommon to bother providing a JavaScript fallback for WebAssembly. Every mainstream browsers supports WebAssembly so web developers have little reason to implement a fallback to JavaScript let alone testing it.
We plan to provide toggles for functionality including WebGL, WebGPU, WebAssembly, WebRTC and much more for attack surface reduction. These features need to be enabled by default for usability unless we implement a reliable prompt to ask users to enable it for the site similarly to how the Local Network Access permission was implemented upstream. None of these toggles for functionality should be tied to whether the JIT is enabled. WebAssembly works both with and without JIT compilation. WebAssembly support is not a performance toggle because a growing amount of functionality uses WebAssembly with no fallback to JavaScript available. A lot of web apps and even basic website functionality are compiling C, C++ or Rust to WebAssembly and depending on it being available with no JavaScript implementation. WebAssembly is universally available in mainstream browsers so Vanadium would be increasingly less usable without it available.
WebAssembly is what's adding the attack surface, not DrumBrake. DrumBrake is a lower attack surface and simpler implementation of WebAssembly compared to the JIT compiler. A toggle for WebAssembly would allow reducing attack surface whether or not the JIT is enabled which makes far more sense. JIT toggle should be a performance vs. security toggle. We can't expect users to understand that sites aren't going to work unless they enable the JIT toggle. The JIT toggle shouldn't improve compatibility, only performance.