なぜブラウザエンジンは 1 つではダメなのか? または Ladybird への期待

Intro

Ladybird は、他のブラウザエンジンをフォークせず、企業との取引に頼らず、寄付だけで作ることを宣言した新しいブラウザエンジンだ。

• Ladybird
  • https://ladybird.org/

これがいかに価値のある取り組みなのか、 Web を漫然と眺めてきた筆者による N=1 の妄言を書いてみる。

ブラウザエンジンとは

ブラウザは、「ブラウザ UI」と「ブラウザエンジン」と、大きく二つの構成要素に分けて考えることができる。

ブラウザエンジンとは、いわゆる Web 標準の技術を片っ端から実装した、ブラウザの土台となるものだ。

ビルドすれば、入力した URL からネットワーク経由でリソースを取得し、パースしてレンダリングして表示できる。そのための IETF RFC や WHATWG HTML や ECMAScript が実装されている、標準技術の結集だ。

その上に、例えばタブをグループ化したり、お気に入りをシンクしたり、そのためのアカウントを作ってログインしたり、 AI を連携させたりといった UI を追加すると、それがいわゆるユーザの使うブラウザになる。

この部分には、さまざまなビジネス上の観点や、プライバシーなどに対するポリシーが如実に現れる。

Chrome は Chromium、 Safari は Webkit、 Firefox は Gecko というエンジンの上に、それぞれの UI が載っている。

UI は、ビジネスや用途に直接結びつくため、各企業が自由に作って、多様で差別化が行われて良い。さまざまなプロダクトがあり、ユーザはそこから自分に合ったものを選び、なんなら自由にカスタマイズして使えばいいのだ。

一方、ブラウザエンジンはそうはいかない。

ブラウザエンジンの互換性

ブラウザエンジンは、同じ URL を入力すれば、同じように表示されることが求められる。表示だけではなく、 JS は同じ結果を返し、 CSS は同じ挙動をしてくれないと困る。

この実装間の互換性を保つためには、細かく仕様を規定し、標準となるテストを書き、各実装がそれを遵守する必要がある。

しかし、各ブラウザが業界シェアを奪い合っていた頃は、差別化のために多くの独自機能が実装され、「このブラウザでしか動かないページ」というのが、むしろビジネス面で喧伝されていた時代すらある。

ところが、そうした独自機能は最終的には互換性の問題を生み、開発者もユーザも苦しめることになるため、徐々に是正され、互換性の重要性が広くブラウザと Web 開発者に根付いていった。

意識が根付いても、すでにリリースされたブラウザの挙動は、そう簡単には変えられない。特にバグがあったとしても、それを直してリリースすれば終わりといった、簡単な問題ではないのだ。

特に IE は、長いことそうしたバグを多く抱えており、本来ならば早く引退してブラウザを刷新したかった MS も、その IE の挙動に合わせて実装された多くのエンプラ製品が壊れないように、セキュリティバグ以外に関しては極力現状を維持し続ける必要があった。 IE を直しても、それに合わせて企業は既存コードを直してくれないからだ。

すでにリリースされた挙動、それに合わせて作られたコンテンツ、仕様上の負の遺産、それら全てを少しずつ修正し、同じ間違いが起こらないようにテストリソースを整備し、その上で新しいケイパビリティを増やしていく。そうした地道な作業の積み重ねで、だいぶまともな Web が形作られて今に至る。

ブラウザエンジンの多様性

その作業が行われている期間に、 Web を支えていたエンジンは、大きく 4 つある。

• Microsoft / Trident
• Mozilla / Gecko
• Apple / WebKit
• Google / Chromium

もとを辿れば Gecko の前には Netscape があったり、 Chromium も WebKit のフォークから始まったりといろいろあるが、これら 4 つが「別のブラウザエンジン」としてそれぞれ開発を進めていた頃、今から十数年前くらいからの話を振り返ろう。

後発の Chromium は、 Google がすでにリリースしていた Map/Gmail/Office などさまざまなサービスをフルに活用するためには、高速で軽量で豊富な機能を持つ独自のブラウザが必要として、開発が始まった。

そして、単に既存のページが表示できるだけでなく、 Ajax 以降にアプリ化が進んだ Web で、さらにリッチな表現を可能にするために、 HTML5 の一連の展開を迎える中で、 Google は Web に潤沢なリソースを投入し業界を強く牽引した。

一番分が悪かったのはやはり IE だ。既存のバグを抱えながらも大きな刷新が難しく、新機能の開発も後手に回り、開発者からのヘイトはたまるが、シェアは相変わらず大きく、依存しているエンプラコードは山のようにあり、それらをサポートしないといけない。最も IE を刷新したかったのは、他でもなく MS 自身だった。

Apple は、 HTML5 に反対とは言わずとも、そこまで積極的だった印象はない。アナリストは「Apple はアプリで儲けるので、 Web のプライオリティが低いのだ」という定説をことあるごとに書く。それも無くはないかもしれないが、どちらかというとリソース配分の問題に筆者には思えた。 Google ほど潤沢なリソースはないため、フォーカスが必要だ。そして彼らは、新機能よりも「パフォーマンスとセキュリティ」にフォーカスしていたと思う。 JSC を使っている Bun が、 V8 の Node よりも速いのも、こうした結果の現れだ。

Mozilla は、 Apple / Google / Microsoft のような営利企業と異なり、非営利団体として Firefox の開発をしていた。実際、この辺の話は割とややこしいので、組織の話はおいといて、スタンスとしては「営利団体である他のベンダが、自社の利益に Web を引き込む暴走を食い止める」といったニュアンスのスタンスがある。しかし、先立つものなくブラウザの開発はできないので寄付を募るが、実際の大きな収入は、 Firefox の検索エンジンを Google 検索にすることで得られる、 Google からのライセンス料だとされる。

この力関係は、表面的に見ると「Google が一人で Web を好き勝手に牛耳り、 Mozilla はそれに反対し、 Apple は我関せず、 IE はそれどころじゃない」みたいな構図に見えている人が多くおり、その言説が当時の Twitter にはことあるごとに撒かれていた。

しかし、本当にそうだったら、 Google はもっと簡単に Web を手中に収めていただろう。

ブラウザエンジンの均衡

ブラウザエンジンが Chromium だけになれば、開発者は 1 つのエンジンだけサポートすれば良いし、標準化も Google が行って、 Chrome が Ship して終わりなため、物事がシンプルになると思うかもしれない。

しかし、実際それを最も望んでいないのは Google 自身だろう。

Web の過去の失敗からもわかるように、合意なく独自に進めていってもうまくいかないのは、火を見るよりも明らかだ。(Google も Gears という失敗を元に HTML5 をはじめた)。そして、合意を取るためには、相手が必要なのだ。相手がいない一人遊びは、そのプラットフォーム自体が反感を買い、 Web そのものがユーザに拒否され、終わってしまう可能性すらある。 Web ほど大きなプラットフォームは簡単には終わらないと思うかもしれないが、おそらくそんなことはない。使われなければ、案外簡単に終わるものだ。

「Web は誰のものでもない」は本来真実なのだが、 Google だけが段違いのリソースをそこに投入しているために、一般人に「Google が牛耳っている」と思われてしまう。時には Google の中の人もそう勘違いする人間が出てしまうこともある。したがって、均衡を保つために Google は他よりも気を使わざるをえない。自分が 4 人チームに所属し、他の 3 人よりも数倍の作業量をこなす状態でも、独立せずにチームでうまくやっていく状態を考えてみれば、大変さがわかると思う。

Firefox とライセンスを結ぶのは、確かに Google 検索を使うユーザを増やすというビジネス的な目的もあるかもしれない。しかしビジネスの合理性だけを考えるなら、ライセンスを切って Firefox を潰し、 Chrome のシェアを広げた方が話が早い。そうしないのは、均衡を保つために買い支えているというニュアンスが、実際のところ強いだろうと筆者は考えている。

標準についてもそうだ。 Chromium は Google がメインでメンテナンスしているが、立ち位置としては OSS だ。そして、そこに新しい機能を実装するには、必ずその機能を先んじて標準化することになっている。標準化は IETF であれ、 W3C であれ、 TC39 であれ合議制だ。そこには、各ブラウザベンダが集まり会議をし、時にはなんらかの合意を取る。 Chrome がどんなにリソースを投入していても、比例代表制になるわけではない。 TC39 の「最低 2 つの実装」を要件とする場合も、 V8 はあくまで一票でしかない。他のエンジンが、合意しつつも実装する余裕がなければ、 Chromium の人間か Igalia に頼んで、パッチを提供することも珍しくない。

実装にあたっても、 Chrome は必ず Safari と Firefox の Standard Position を聞きにいかないといけない。逆は行われてない。そして、 Chrome が長大なプロセスをかけて整備した提案やコードも、 Safari や Firefox の人間の必ずしも納得できない説明で Deny されることもある。この意思決定に「Google からのライセンス料」の話など持ち出されても、「だったらもう少し忖度してあげ欲しいわ w」とすら思うほど、容赦ない。 Private Relay や Passkey のような重要な機能を相談もなく出して、標準化は後から行う Apple の方が、好き勝手やっているように見えるときだって少なくない。

まあ、 Chromium にもたまに怪しいプロセスを押し通そうとする不届きものがいるが、基本はルールに則って進められる。 Chrome がやりたいことが、そのままできることばかりではない。このプロセスを知っていてなお「Chrome が好き勝手やっている」と思うのは、やはりかけているリソースが多く、作業量と成果が他のベンダーと比べて段違いなだけなことがほとんどで、その結果しか見えていないからだろう。

それだけ、エンジンの実装が複数あり、議論と合意形成が成立し、その多様性はありながら互換性は保たれている、という状態を維持するのは非常に大変かつ重要なのだ。それは Chrome にとっても、他のブラウザベンダにとっても同じだ。

均衡の崩れ

筆者はずっとこの均衡の崩れを懸念していた。

なぜなら、 Web が始まってから 30 年近い蓄積があり、年々新しい仕様が入り、その上で互換性を保つという、複雑性の塊のようなブラウザを、またゼロから新しく作るのは、人類には不可能だと思っているからだ。

具体的には「Mozilla の体力が尽きて、 Firefox が終わってしまったら、 Web はどうなるのか」そんなことを日々考えていた。

2015 年、 Chrome チームを立ち上げに携わり、長年 PM をやっていた及川さんが Google を辞めた直後に、 mozaic.fm にお呼びして議論したのは、まさしく「人類が新しくブラウザを作れないとしたら、 Web はどうなるのか」という問題だった。

• ep20 Browser | mozaic.fm
  • https://mozaic.fm/episodes/20/browser.html

ここでは「ゼロから作る」とはどういうことかも議論している。例えば OpenSSL を使うのか TLS スタックをフルで書くのかといった匙加減はあるが、まあある程度既存のエコシステムの力を借りることはできる。それでも難しいだろうという話だった。

ところが、その後予想に反して Microsoft からこの均衡の崩れが始まった。

IE 卒業を視野に入れて、 EdgeHTML という新しいエンジンの開発が始まったのだ。この時点では、新しいエンジン開発という意味で歓迎できるものだった。特にレンダリング周りの実装は革新的だったと、当時のコードを読んだ人が言っていたのを記憶している。

しかし、数年の努力もむなしく EdgeHTML は開発をやめ、新しい Edge ブラウザは、 Chromium をブラウザエンジンに選んだ。そこからの話は早く、数年で MS が思い描く理想的なブラウザは Chromium の上に構築され、 2022 年 IE 引退という歴史的な転換を迎えるまでに至った。その流れは、 IE サポートチームの Yusuke さんをお呼びして mozaic.fm で議論している。

• ep83 IE | mozaic.fm
  • https://mozaic.fm/episodes/83/ie.html

時を前後して Opera も Chromium ベースになり、 Brave, Vivaldi, Ark, Sidekick とさまざまな Chromium ベースのブラウザが生まれた。「ブラウザエンジン」の実装は増えないが、「ブラウザ」の実装はどんどん増えていったのだ。

確かに MS にしてみれば、今から EdgeHTML を Chromium, Gecko, Webkit レベルまで育てていくのは、途方も無いコストがかかるもので、現実的に完成に漕ぎ着けられるかもあやしい。その過程で使われる Edge も、他のブラウザと比べて不完全な時間が長く、その間にユーザからは IE 並のヘイトを集め、顧客が離れてしまう可能性もある。

MS のビジネス的に、エンジンを育てることよりも、ブラウザ UI 側を育てて、 MS の各サービスと連携して顧客に価値を届ける方が理にかなっているのは事実だろう。現に Vertical Tab, Split View, Collections など便利な機能は多く提供され、 Bing 連携では Google を差し置いて AI 連携を提供することにも成功している。

今の MS はベースの標準化と実装は Google にまかせ、その足りてない所として OpenUI に注力し、画面を使いやすくすることにフォーカスしているように思う。すでに実現した <dialog> や popover 、そしてその後ろに控えているさまざまな提案は、おそらく Web の表現をリッチにすることを通じて MS 製品の改善にも寄与していくだろう。

「ブラウザをゼロから実装するのは難しい」というのは、問いが間違っていたのだ。 Chromium というエコシステムの力を借りれば、「ブラウザ」はゼロから実装できる。実装できないのは「ブラウザエンジン」の方だった。

さらなる危機

Trident と EdgeHTML が同時にリタイアし、現状は 3 つだ。

• Mozilla / Gecko
• Apple / WebKit
• Google / Chromium

次なる危機は、またしても Firefox ではなく、 Safari の方に訪れている。

• Apple によるブラウザエンジン規制の緩和 | blog.jxck.io
  • https://blog.jxck.io/entries/2024-01-28/apple-sideloading.html

これまで Apple は、「iPhone 向けのブラウザアプリは Webkit ベースであること」という制限を課していた。

これはつまり、 iPhone にインストールできる Chrome も Firefox も、全部 Webkit の上にブラウザ UI をかぶせたものだったことを意味する。 PC Chrome で動く機能が iPhone Chrome を入れても動かなかったのは、それが Webkit に実装されていなかったからだ。

このような制限は、確かに囲い込みの側面はあるかもしれない。一方で、 Apple は Apple 製品全体にプライバシーやセキュリティについての強いクライテリアを用意している。 Apple の CM で「あなたの個人情報は守られてますか?」などと宣伝されているアレだ。これを実現するには、プラットフォームに強い制限が必要で、どんな邪悪なアプリを実装しようとしても、プラットフォーム側で守られていれば、顧客は安全というものだ。ブラウザも Webkit でできる以上のことができなければ、闇堕ちしたブラウザをユーザが掴まされることはない。

ここが iPhone が Android に対する差別化の一つとして提供している価値で、特に日本企業が高くても iPhone を社用に配る理由になっていたりする。自由かつ安価な Android を配布する際に担当者が気を使うべきことの大部分が、 多少高額でありながら iPhone はネイティブに提供していたからだ。税金を払って警察に守ってもらうか、税金を払わずに自衛するかといった違いだ。どちらが良いかはユーザが決めればいい。

しかし、プラットフォームは力を持つと反感を買う。反感を買えば規制が入り、今回は独占禁止の観点で規制の緩和が命令された。これは、技術的な話ではなく、文字通りフェアトレードの観点が強いため、その結果ユーザの安全がどの程度脅かされるかも、手数料を払わなくて済むベンダにとっては、取るに足らない言い訳程度にしか響かず、施行に向かっている。最初は EU だけだったが、日本はこのあたりの施策をだいたい EU からコピペしているので、先日日本でも同等の規制緩和が指令された。

つまり、そう遠くない未来で iPhone に Chromium ベースの Chrome や、 Gecko ベースの Firefox がインストールできるようになるということなのだ。今のところ、エンジンへの制限はありどんなブラウザでもストアに出せるわけではなさそうだが、どう展開されていくかは実施されてみないとわからない。

さて、 Web 開発者の視点に立てばどうだろうか? IE リタイア後は「次世代の IE」と揶揄される Safari を Web サービスがサポートするのは、実際のところ iPhone のシェアが無視できないほど多いからという側面がある。 Windows にもあえて Chrome を入れる人がいるように、 iPhone にもあえて Chrome を入れる人が増えたら、何が起こるだろうか?

もしインストール時に、デフォルトブラウザとして Safari, Chrome, Firefox から選択する画面が出るような構成になった時、ユーザは Safari を選び続けるだろうか?

もし、 PC と同じく iPhone での Chrome のシェアが増えても、サービスは Safari をサポートし続けられるだろうか?「Chrome を入れてアクセスしてください」というメッセージのもと、ストアのリンクを貼ったエラー画面だけを出すようにならないと、断言できるだろうか?

mozaic.fm では 7 年くらい前からブラウザの動向を毎月トラッキングしてきたが、最近の Safari の新機能開発の速度はこれまでよりも加速しており、今まで Safari がずっと後回しにしていたような機能が、どんどんリリースされている。 Safari のリリースノートも、どんどん長くなっている。穿ってみれば、プラットフォームの縛りがなくなったあとの、 Safari のシェアを案じた焦りとも見えなくはない。開発者のブラウザに対する評価軸は Speedmeter の結果よりも Can I Use の星取表の方が支配的だ。

このまま、より Chrome のシェアが一方的に増え、他のブラウザエンジンがビジネス的な理由から終わってしまうようなことがあれば、それは Web Platform の側面では「よくないこと」だ。でもだからといって、 Chrome も Firefox も刷新版を iPhone のストアに並べないという選択肢もないだろう。

新しいブラウザを作るという挑戦

実際のところ、実装が多すぎれば最大公約数が下がって大変ではあるだろう。しかし、現状はギリギリの数しかない。つまり Web は新しい実装を求めている。

それも、単に HTML をパースして DOM を表示するだけの習作ブラウザではなく、 Baseline が求めるような WPT や Test262 を 80% 通すくらい互換性が保たれていて、現実的なタイムスパンでモダンブラウザの仲間入りをしてくれるような実装だ。それは、一朝一夕ではできないし、リソースも必要だろうとは思う。

一方、新しい実装が育つまで、進化を止めるということもできない。

だからといって下手に手や資本を入れて、独立したプロジェクトのように始めても、世間は必ず穿った見方で批判をするため、新星の登場は、願って待つしかないのだ。

標準化の場面でもエンジンが 3 つでは、多数決のできる最小人数まで減ってしまっている。あと 1 個終われば、もう多数決は成立しないのだ。新しいブラウザの開発者が、標準化の場面にも参加してくれることは、新しい視点の導入や、ユースケースの拡大という意味でも良い影響が予想される。実際、 IETF の HTTPBis はこれまでブラウザベンダーが中心だったが、近年 CDN 系の会社からエンジニアが来たことで、議論の雰囲気が良い意味で変わっている。 そうした新星が現れてくれるなら、多少シェアが奪われようと、参入を拒むブラウザベンダはいないと思う。

そして、新しいブラウザを作ろうという話は、無いわけではない。

Igalia は Firefox Reality からフォークした Wolvic というブラウザを作っているし、 Ekioh は Flow というブラウザをスクラッチから作っている。しかし、それぞれ目的が少し違うようにも思う。

そんななか、最近出てきた Ladybird もまた、他のブラウザのコードを使わず、寄付以外にビジネス的な支援を受けないで中立なブラウザを作ることを目指しているという。

こうした挑戦は、今の Web にとっては非常に重要だ。標準化で「実装」としてカウントされるような後発のブラウザエンジンは、しばらく現れていないし、その上で独自の UI も提供している Chromium ベースじゃない新しい「ブラウザ」もまた、最近あまり出てきていない。

「ゼロから実装は無理だと言われているが、我々はそれをやる」という意気込みも素晴らしい。

「ゼロから」がどこからなのかは、ここからは「他のブラウザのコードを借りない」という点しか読み取れない。例えば先の TLS の例で言えば、少なくとも BoringSSL は使わないんだろうか。 OpenSSL はありなのか、それとも TLS から自作するのか? QUIC は? WebRTC のための DTLS や SRTP はどうするんだろう。とネットワークだけでも気になることは色々ある。そんな気になる箇所が、数百箇所はある。

もちろん、 Chromium をフォークせずに作れば、多少ライブラリが被っていたくらい気にならずに「新しいエンジン」と言えるだろう。本当に全部フルスクラッチしたら、完成はしても 10 年先といった事態になりかねない。そして 10 年経ったら、 Web は今以上に進化して結局追いつけないか、もうすでに手遅れになっている可能性もある。ここの塩梅だけはうまく落とし所を見つけて、できれば、 Baseline が求めるような WPT や Test262 を 80% 通すくらい互換性が保たれていて、現実的なタイムスパンでモダンブラウザの仲間入りをしてくれると嬉しい。

その上で、できればちゃんとシェアを獲得して、使われてほしい。

そして、それが最初から中立で、経済的な支援もなく開発が続くのであれば、そんなに良いことはないのだ。

これがどれだけ難しいことなのかは、筆者には想像もできない。

できることは手伝いたいと思うし、寄付サイトが落ちていたが、寄付もしたい。

Ladybird じゃなくてもいい。 Flow でも、それ以外の誰かでもいい。 Chromium が Webkit のフォークだったように、 Chromium をフォークして大部分を書き換えるようなスタートでも、別に良いと思う。誰かが、本気で新しいブラウザエンジンの開発に参入するなら、それは心から応援したい。

Outro

「新しい Web ブラウザエンジンを作る。」

これは、 Web の大きさがどのくらい高い解像度で認識できているかによって、感じるところの変わる目標だろう。

途中でその膨大さに挫けず、資金が途切れず、モチベーションが続き、 Web が終わってしまう前に

新しいブラウザエンジンが Baseline のリストに上がるような日が来ることを、心待ちにしている。