Chromeが再起動不要の超高速アップデートを導入か、パッチ数が急増

ブラウザ分野において、Chromeは常にセキュリティとパフォーマンスの基準を示す存在であり続けてきた。しかし、ユーザーを長年悩ませてきた問題——更新後にブラウザを再起動しなければならない——が転機を迎えようとしている。Ars Technicaの報道によると、Googleは「Live Update」と呼ばれる技術を開発中であり、Chromeがバックグラウンドで静かに更新を適用し、ユーザーがタブを閉じたりプログラムを再起動したりする必要をなくすことを目指している。この情報はコードのコミット記録と内部文書に由来するもので、公式発表はまだないものの、その兆候は十分に明確だ。

パッチ数急増の背景にあるプレッシャー

報道が引用した統計データによると、Chromeの最近の2バージョン（129および130など）で修正されたセキュリティ脆弱性と安定性パッチの数は、それ以前の23バージョンの合計を上回っている。この急増は二つのトレンドを反映している。一つは、WebGPUやFederated Credential Managementといった新APIが導入した複雑性をはじめ、ブラウザの攻撃対象領域が拡大し続けていること。もう一つは、ゼロデイ脆弱性に対するGoogleの対応速度が著しく向上していることだ。しかし、頻繁なバージョン更新はユーザー体験にもコストをもたらしている——更新ごとに発生する再起動はワークフローを中断させ、特に企業環境では、IT管理者が数千台のデバイスの再起動タイミングを調整する必要がある。

「過去1年間で、Chromeセキュリティチームが修正した脆弱性の数は史上最多を記録したが、再起動の工程が最後の弱点となっている。」——Ars Technicaの分析記事

実際、Chromeの更新メカニズムは不変ではない。2023年にはすでに、GoogleがChromeOSに「Live Update」の概念を導入し、再起動なしでシステムにセキュリティパッチを適用できるようにしていた。一方、デスクトップ版ブラウザはアーキテクチャの違いから、実現の難易度がより高い。現在のChromeは「パッチング」モードを採用しており、更新パッケージをダウンロードした後、次回起動時に古いファイルを置き換える仕組みだ。この制限を打破するには、メモリ上で実行中のコードのホットスワップ問題を解決する必要がある——Linuxカーネルのkpatchや、MicrosoftのWindowsのHot Patchingに相当する技術だ。

技術的アプローチ：モジュール化とプロセス分離

Chromiumのコードリポジトリのコミット記録から、Googleが「Component Updater V2」と呼ばれる一連の改良を推進していることがわかる。その核心的な考え方は、ブラウザをより細粒度の独立したコンポーネントに分割し、各コンポーネントがグローバルプロセスに影響を与えることなく個別に更新できるようにすることだ。たとえば、GPUドライバモジュール、ネットワークスタック（QUIC/TLS）、V8エンジンなどの主要部分についても、「ホットスワップ」の実現が期待されている。さらに、新たな「セキュリティサンドボックス」技術により、隔離された環境内で更新済みのコードバージョンを読み込み、安定性が確認された後にポインタを切り替えることで、クラッシュのリスクを回避できる。

AppleのSafariブラウザはmacOS Venturaですでに同様の機能を実現している。システムレベルの更新フレームワークを通じて、アプリを再起動することなくブラウザコンポーネントを更新できる。ChromiumベースのMicrosoft Edgeも、「Startup Boost」とバックグラウンド更新を組み合わせる可能性を模索している。Chromeの今回の取り組みは、ブラウザ更新の効率基準を再定義するものになるかもしれない。

編集者注：「便利」から「不可欠」へ

一般ユーザーにとって、再起動不要の更新は「再起動」ボタンをクリックする手間が一度省けるだけの利便性に見えるかもしれない。しかし、サイバーセキュリティの観点からは、この変化は非常に深い意味を持つ。現在、パッチのリリースからユーザーが再起動を完了するまでの間に平均で数日から数週間の「露出ウィンドウ」が存在し、その間にハッカーは既知の脆弱性を利用して攻撃を仕掛けることができる。Chromeが再起動の工程を排除できれば、セキュリティ保護が真の意味でリアルタイムに機能することを意味する。また、企業のIT管理においても、ポリシー設定によってバックグラウンド更新を強制できるようになり、複雑なスクリプトで更新を配布し再起動ウィンドウを調整する必要がなくなる。

もちろん、技術的な課題も無視できない。ホットアップデートは安定性のリスクをもたらす可能性がある。あるパッチ自体に欠陥があった場合、実行時の置き換えが予測不能なエラーを引き起こしかねない。Googleは更新の検証とロールバックのメカニズムに十分な取り組みが必要だ。さらに、一部の低レイヤーシステムライブラリ（ANGLEレンダリングレイヤーなど）の置き換えには依然としてOSの権限サポートが必要であり、再起動不要の機能は初期段階では一部のモジュールに限定される可能性がある。

総じて、Chromeのこの取り組みはブラウザ進化における重要な一歩だ。WebアプリケーションがPWAやWebAssemblyを通じてネイティブアプリに近づくにつれ、ブラウザのランタイム信頼性もOSレベルに引き上げる必要がある。Googleがこれを実現できれば、Chromeの市場における地位を強化するだけでなく、ブラウザ業界全体の技術的な進歩を後押しすることになるだろう。

本稿はArs Technicaより編訳