Chromiumは自分のコードを信用していない、速さより先に壊れ方を設計したブラウザ

バグはありません、と胸を張る開発計画ほど、バグが見つかった日の手順を持っていません。壊れない前提で作ったものは、壊れたときの止め方を誰も考えていないからです。Chromiumの設計は、その逆から出発しました。この記事では、マルチプロセス、サンドボックス、サイト分離を、速くするための工夫ではなく、破られたときに被害をどこで止めるかを先に決めておく仕組みとして読み直し、同じ発想が、多くのブラウザが一つの土台に乗る今の構図では弱点にもなりうることまで考えます。

2008年の前提は、ブラウザは落ちるものだ、でした

Chromiumは、Google ChromeやMicrosoft Edge、Opera、Brave、Vivaldiなどが土台にしているオープンソースのブラウザプロジェクトです。オープンソースとは、誰でも中身を見たり改良したりできるプログラムのことです。Googleのエンジニアが始め、いまは世界中の開発者が開発に加わっています。

始まりは2008年ごろです。GmailやGoogleマップのように、ブラウザの中で動く本格的なウェブアプリが登場していました。しかし当時のブラウザは、こうした重いサイトを開くと固まったり、落ちたりしがちでした。Googleは既存のブラウザを改良する道ではなく、新しく作る道を選びます。掲げた原則は、速さ、安定性、安全性、シンプルさ、そして誰でも参加できるオープン性でした。

注目したいのは、落ちないブラウザではなく、落ちても困らないブラウザを目指した点です。何百万行ものコードには、どれだけ注意深く書いてもバグが残ります。これを受け入れると、設計の問いは、どうすれば壊れないか、から、壊れたときにどこで止めるか、に変わります。

タブを分けたのは、タブ同士を信用しないためです

従来のブラウザは、すべての処理を一つのプログラム（プロセス）で動かしていました。社員が一人しかいない会社と同じで、その一人が倒れれば全部が止まります。

Chromiumは仕事を分けます。全体を管理するブラウザプロセス、タブごとにページを描くレンダラープロセス、画像処理を担うGPUプロセス、通信を担うネットワークプロセスなどです。重いゲームのタブが固まっても、隣のニュースのタブは動き続けます。

ページを画面に描くのは、Blinkというレンダリングエンジンです。HTMLからページの骨組み（DOMツリー）を作り、CSSで見た目を計算し、各要素の位置と大きさを決め、色を塗り、重ね合わせて表示します。JavaScriptを実行するのはV8というエンジンで、実行中に効率のよい機械語へ変換するJITコンパイルで高速に動かします。V8はNode.jsにも使われ、JavaScriptをサーバー側でも動かせるようにしました。

この分業は、作業の効率化である前に、互いを信用しない取り決めです。ページを描くレンダラーは、インターネットから来た得体の知れないデータを直接さわる、いちばん危ない持ち場です。だからChromiumは、レンダラーがいつか乗っ取られる前提で、そこから手の届く範囲を最初から狭くしています。

サンドボックスとサイト分離は、破られた後のための設計です

安全面の柱はサンドボックスです。子どもの砂場の遊びが外に出ないように、ウェブサイトを隔離された環境で動かします。各プロセスが触れられるファイルやネットワークを制限し、高い権限が要る操作は専用のプロセスだけに任せます。2018年には、異なるサイトの内容を必ず別のプロセスで動かすサイト分離（Site Isolation）も導入されました。ニュースサイトに埋め込まれた別サイトの部品が、元のサイトの情報を盗み見ることを防ぐ仕組みです。

どれも、侵入をゼロにする仕組みではありません。侵入されたときに、盗めるもの、壊せるものを小さくする仕組みです。多くのChromium系ブラウザが自動アップデートで修正を届けるのも同じ発想で、脆弱性は見つかるものとして、見つかった後の修正を利用者が意識しないうちに適用します。

うちのシステムは安全です、とだけ書かれたセキュリティ方針は、晴れとだけ告げて、雨具の置き場所を教えない天気予報です。安全かどうかは誰にも保証できない以上、方針として読めるのは、破られたら何が守られ、何が失われるかを書いた部分だけだからです。Chromiumの設計は、その書き方の見本になっています。

速さの工夫も添えておきます。リンク先の住所を前もって調べるDNSプリフェッチ、接続を先に確立するプリコネクト、開きそうなページを裏で読み込むプリレンダリング、長く見ていないタブを休ませるメモリの節約、描画や動画、3D表示をGPUに任せる工夫などです。

一つのブラウザの中の分離は、ブラウザ同士の間にはありません

Chromiumの技術はブラウザの外にも広がりました。HTMLとJavaScriptで作れる拡張機能、WebRTC、WebGL、WebAssemblyによって、ビデオ通話や3D表示がブラウザで動くようになりました。Chrome OSはChromium OSを土台にし、Chromium Embedded Framework（CEF）を使えば、SpotifyやSteamのように他のアプリの中にウェブの画面を組み込めます。ChromiumとNode.jsを組み合わせたElectronからは、VSCodeやSlackのようなアプリも生まれました。開発は、毎日更新されるCanary、開発版のDev、試験版のBeta、一般向けのStableという段階を経て進み、Googleが開発した通信方式QUICは、まずChromiumで実装され、のちにHTTP/3として標準化されました。

ここに皮肉があります。一つのブラウザの中では、壊れることを前提に持ち場を分けたChromiumが、ブラウザの世界全体では、主要なブラウザの多くを同じ一つの土台に乗せました。一つのタブの不具合は隣のタブに及ばなくても、Chromiumの一つの不具合は、その上に乗る派生ブラウザのすべてに及びえます。開発者が対応すべき違いが減った利点の裏で、競争が弱まること、一社がウェブの事実上の標準を左右しやすくなることも懸念されています。

ただし、この見方には条件があります。エンジンが多様なら安全になるとは限らず、エンジンごとに別の脆弱性を抱え、それぞれの修正に人手が要ります。共通の土台には、一度の修正がすべての派生先に届くという利点もあります。土台が一つであることが弱点になるか強みになるかは、修正がどれだけ速く、どれだけ漏れなく派生先に届くかで決まり、一般論では決着しません。

あなたの職場の仕組みのうち、壊れないことだけを前提に作られているものはどれでしょうか。それが壊れた日に、被害がどこで止まるかを答えられる人はいるでしょうか。

この記事の背景にある考え方は、拙著『GoogleのAI NotebookLM 意思決定の強化書』の「むすび　前提を言葉にすれば、結論を見直せる」に書きました。うまくいかなかったとき、誰が間違えたかではなく、選択肢が足りなかったのか、前提が抜けていたのか、見直しが遅れたのかを問う、という話で、「意思決定で見直すべきなのは、人ではなく仕組みです。」と書いています。ここを読むと、失敗を個人の注意不足で片づけず、仕組みのどこで止まるはずだったのかを、自分の現場に当てはめて考えられるようになります。