ИИтог

Firefox скомпилировали в WebAssembly и запустили внутри Chrome

инструментыРедакция ИИтогSimon Willison🔥71Рейтинг ИИтог · значимость 59 · 200000/ч
Firefox скомпилировали в WebAssembly и запустили внутри Chrome

Компания Puter скомпилировала браузер Firefox (движок Gecko) в WebAssembly, низкоуровневый формат байткода, который выполняется прямо в браузере без плагинов. В результате весь Firefox запускается как обычная веб-страница внутри другого браузера: разработчик и автор блога Саймон Уиллисон показал демо, где его собственный сайт открывается в Firefox, а тот, в свою очередь, работает в WebAssembly внутри вкладки Chrome.

Движок Gecko выбрали потому, что он умеет работать в одном процессе, это заметно упрощает перенос в WebAssembly по сравнению с многопроцессными архитектурами других браузеров. Сама разработка обошлась примерно в $25 000 в пересчёте на токены нейросетей Claude Opus и Fable (обе, модели Anthropic), но реальные расходы оказались намного меньше благодаря подписке Claude Max, которая покрывает часть использования фиксированной ценой.

Поскольку код, выполняющийся в браузере, не может напрямую открывать произвольные сетевые соединения, весь трафик скомпилированного Firefox проходит через сервер Puter по протоколу WebSocket (используется протокол Wisp), то есть браузер внутри браузера на деле общается с интернетом через прокси-сервер компании. Такая схема оказалась ресурсоёмкой: когда новость о проекте попала на Hacker News и на демо хлынул трафик, серверы Puter пришлось экстренно масштабировать.

Puter заявляет, что схема поддерживает сквозное шифрование (end-to-end encryption). Уиллисон проверил это сам, изучив содержимое WebSocket-сообщений: трафик к его собственному сайту по HTTPS действительно был зашифрован, а запросы к тестовому адресу http://www.example.com по обычному HTTP шли в открытом виде, то есть шифрование работает ровно там, где и должно.

Исходный код проекта опубликован в репозитории firefox-wasm. Есть и похожий проект, WebkitWasm от разработчика theogbob, который таким же образом компилирует в WebAssembly движок WebKit (используется в Safari), но у него пока нет работающей онлайн-демонстрации.

Ключевые факты

  • Puter скомпилировала Firefox (движок Gecko) в WebAssembly, браузер целиком запускается как веб-страница внутри Chrome
  • Gecko выбрали за поддержку однопроцессного режима, это упростило перенос в WebAssembly
  • Проект обошёлся примерно в $25 000 токенов Claude Opus и Fable, но благодаря подписке Claude Max реальные расходы оказались намного ниже
  • Весь трафик идёт через сервер Puter по протоколу Wisp поверх WebSocket, потому что код в браузере не может открывать сетевые соединения напрямую; после всплеска трафика с Hacker News серверы пришлось масштабировать
  • Заявленное end-to-end шифрование подтвердилось на практике: HTTPS-трафик был зашифрован, HTTP, нет

Почему это важно

Проект показывает, что современные браузерные движки, многомиллионные по объёму кода системы вроде Gecko, уже можно переносить в WebAssembly почти целиком, а не только отдельные модули. Это демонстрация практического предела возможностей WebAssembly как универсальной платформы выполнения кода: если в браузере можно запустить другой полноценный браузер, туда же помещается практически любое другое сложное приложение.

Кому это важно

Разработчикам браузерных движков и веб-платформ, которые следят за возможностями WebAssembly; инженерам, интересующимся тем, как ИИ-модели вроде Claude справляются с задачами масштаба переноса целого браузера; специалистам по веб-безопасности, которым интересна архитектура проксирования трафика через WebSocket.

Как это применить

Проект, работающая демонстрация, а не готовый продукт: исходный код Firefox-в-WASM выложен в открытом репозитории firefox-wasm, его можно изучить и запустить. Прямого практического применения (замена обычного браузера, встраивание в продукт) в источнике не описано, это в первую очередь технический эксперимент и демонстрация возможностей.

Можно ли доверять

Источник, личный блог Саймона Уиллисона, известного разработчика и наблюдателя за индустрией ИИ, который лично проверил заявления Puter о сквозном шифровании, изучив содержимое сетевых сообщений, а не просто пересказал пресс-релиз. Указаны ссылки на репозиторий проекта и на демо, что позволяет проверить факты независимо.

Риски и подводные камни

Весь трафик пользователя проходит через промежуточный сервер Puter, даже при работающем сквозном шифровании до конечных HTTPS-сайтов это дополнительная точка, через которую идут все запросы. Схема с проксированием через WebSocket ресурсоёмка для самой Puter: рост нагрузки после публикации на Hacker News уже потребовал экстренного масштабирования серверов, что говорит об ограниченной готовности решения к постоянной высокой нагрузке.

«Вот мой блог, который работает в Firefox, который работает в WebAssembly, который работает в Chrome.»

— Саймон Уиллисон