Show HN: Firefox in WebAssembly
255 points • 1 day agoArticle Link

Puter Labs 推出了一项可以在单个浏览器标签页内完整运行 Firefox 的新项目。它把驱动 Firefox 的 Gecko 引擎编译成 WebAssembly,从而在另一个浏览器的环境中重现传统桌面浏览器的界面和渲染能力,作为一个完整的应用运行,而不是简单的网页。

要让这个"浏览器内的浏览器"正常工作,用户需要进行一些环境配置。由于项目依赖 WebAssembly JSPI,Firefox 用户需在 about:config 中手动启用 javascript.options.wasm_js_promise_integration 标志。完成配置后,引擎会在标签页中初始化并启动 Firefox 界面,为网络探索提供一个沙箱环境。

项目还为希望试验性能和架构的用户提供了高级选项,包括通过 WebGL 实现的 GPU 加速,以及一个将 JavaScript 转译为 WebAssembly 的实验性即时编译器(JIT)。尽管该 JIT 功能仍属试验阶段,但可作为在此虚拟化场景中提升引擎速度和效率的测试平台。

嵌套浏览器的网络由 Wisp 服务器管理,充当 WebSocket 代理。当用户通过该 Firefox 实例浏览网页时,流量会通过由 Puter 托管的该代理转发。整个方案由 Puter.js 支持——一个用于在浏览器中处理复杂网络任务的库,使内部的 Firefox 实例能够在多层虚拟化下无缝加载外部网页内容。

125 comments • Comments Link

• 将 Firefox engine 移植到 WebAssembly 的工作涉及在 AI 辅助调试和 JIT 研究上投入大量资源,消耗了约 $25,000 的 usage tokens 。

• 该项目是对"browser-in-a-browser" 功能的试验性探索,利用了 Firefox 相较于 Chromium 在单进程支持方面的优势。

• 要在这种环境下实现高性能执行,需要启用特定的浏览器标志,例如开启 javascript.options.wasm_js_promise_integration,以便管理事件循环让步和 offscreen canvas 的同步。

• 安全影响非常复杂。尽管 WASM 提供了强大的沙箱,但若通过以单进程模式运行 engine 而禁用多进程隔离,一旦 site-level renderer 出现漏洞被利用,风险会显著增加。

• 网络连通性则通过将流量隧道到基于 WebSocket 的中继来实现,因为网页浏览器无法原生发起原始的 TCP 套接字连接。

• 该项目凸显了 WASM 不断发展的潜力,但也引发了对潜在滥用的担忧,例如 IP cloaking,以及如果网站转向混淆的"内置浏览器"渲染,可能会削弱用户端的广告屏蔽控制。

• 类似将 WebKit 移植到 WASM 的尝试表明,行业内正有将渲染引擎推向非常规环境的更广泛趋势,这让人想起长期以来开发者关于 web 架构循环性的讨论。

• 移动浏览器支持仍受内存限制、稳定版本中缺乏 JSPI 等专业功能,以及对底层设置访问受限的制约。

• Mozilla 对来自 Google 的搜索分成的依赖影响了其对广告屏蔽的立场,尽管它仍保持对 uBlock Origin 等第三方工具的可访问性。

• 在宣传性质和网络术语透明度方面,该项目也受到审视,尽管维护者强调使用了开源且加密的协议。

围绕 Firefox-in-WASM 项目的讨论既展示了 WebAssembly 令人印象深刻的技术成熟度,也暴露出现代浏览器架构的实际局限。虽然在另一个浏览器内运行复杂渲染引擎是一项重要的工程成就,但它引入了新的安全权衡,并依赖专门的网络中继来绕过浏览器沙箱限制。归根结底,许多人将该项目视为 Web 应用未来的有力概念验证,而另一些人则警告称,这可能对广告屏蔽产生意想不到的影响,并导致资源消耗增加。