Show HN：WebAssembly 中的 Firefox

原文 ↗ Hacker News 讨论 ↗

在 WebAssembly 里直接运行 Firefox 本身——等于“浏览器套浏览器”——让很多人对它已经具备的可用性和性能印象深刻，甚至还能处理 YouTube 这类复杂网站。评论者深入讨论了其技术选择（单进程 Gecko、JSPI 要求、自定义 WASM→JS JIT、基于 WebSocket 的 TCP 网络），并争论安全影响，既包括更强的隔离层，也包括新的攻击面或沙箱回退。另一些人则质疑真实世界用途、成本（包括据称为移植辅助所花费的 25k 美元 AI token）以及对远程中继的依赖，同时设想了从在受限电视上做广告拦截，到未来可能绕过用户扩展的“内层浏览器”技巧等场景。

整体反应

  • 很多人觉得这个演示很“酷”/“惊艳”，而且出乎意料地流畅，尤其考虑到它是在浏览器里运行完整的 Firefox 引擎。
  • 也有人质疑实际用途，更把它看作 WebAssembly 的一个引人注目的概念验证。

技术实现

  • 使用了 Firefox 的单进程构建，并将 GPU/WebRender 透传到 canvas，另有可选的软件回退。
  • 依赖 WebAssembly JSPI（wasm_js_promise_integration）来让出事件循环并同步 OffscreenCanvas；Firefox 用户必须启用一个隐藏标志，未来 Firefox/Safari 版本预计会完整支持。
  • 包含一个实验性的 WASM→JS JIT，以及一些 WebAssembly 解释器后端工作；在性能和稳定性上投入了大量精力。
  • 提到的前身工作：WebKit-in-Wasm 移植和更早的 WebKit.js。

性能与兼容性

  • 对许多桌面用户都运行良好（包括 ARM Mac 和 Steam Deck），甚至还能播放 YouTube。
  • 在移动端（Firefox 和 Chrome/Android）上会失败或只能部分工作，原因包括内存限制、缺少特性，或在第一帧后冻结。
  • 嵌套的“Firefox-in-Wasm inside Firefox-in-Wasm”有时能工作，但不稳定。
  • 一些用户报告，wasm 浏览器内的网络速度慢了 10 倍，并存在各种 bug（GPU 驱动问题、不支持的系统调用）。

安全与网络

  • 有人认为这大幅强化了沙箱隔离（浏览器套浏览器，再加上 wasm 运行时），但也有人指出它禁用了 Firefox 常见的多进程隔离，并依赖一个经过大量修改、由 AI 编辑的构建版本。
  • 所有 TCP 流量都通过运行在 Cloudflare 上、基于 WebSocket 中继的代理（WISP 协议）转发；TLS 在浏览器内由编译成 Wasm 的 OpenSSL 处理。
  • wasm 浏览器内看到的 IP 是代理的 IP，这带来信任和滥用方面的担忧（伪装、潜在恶意行为）。
  • 对“端到端加密”的说法也有人批评，因为网站本身提供 wasm 代码并控制运行内容。

用途与影响

  • 提议的用途包括：为被锁定的智能电视添加广告拦截和扩展，以及作为通用浏览器沙箱。
  • 也有人预见出版商会分发混淆过的“内层浏览器”来绕过用户的广告拦截器，代价可能是大量 RAM 消耗和复杂性增加。

成本与 AI 参与

  • 据称这个移植在调试和 JIT 研究上消耗了约 25,000 美元的 AI token，引发了关于成本、可行性与人工工作的讨论，以及这到底是“有趣的实验”还是严肃研究。