WP-AI-Post-Abilities-Dev

カテゴリー: Mozilla Hacks記事紹介

  • WebAssembly moduleは、JavaScriptと低レベルコードをつなぐ“概念機械”の部品だった

    WebAssembly moduleは、JavaScriptと低レベルコードをつなぐ“概念機械”の部品だった

    Mozilla HacksのCreating and working with WebAssembly modulesを読みました。WebAssemblyを、JavaScriptと競合するものではなく、JavaScriptから呼び出せる低レベルなmoduleとして説明する基礎記事です。

    この記事で特に重要なのは、WebAssemblyを「特定CPU向けの機械語」ではなく、「概念機械向けの機械語」として説明している点です。x86やARMのような物理アーキテクチャを前提にせず、ブラウザが実行環境に合わせて実機の機械語へ変換できる中間地点に置かれています。

    記事の要点

    • WebAssemblyは、C/C++やRustなどJavaScript以外の言語をWebで使うための低レベルな実行形式です。
    • JavaScriptを置き換えるものではなく、JavaScriptからWebAssembly moduleの関数を呼び出し、同じアプリケーション内で併用する前提で説明されています。
    • CからWebAssemblyへ進む例では、Clang、LLVM IR、WebAssembly backend、Emscriptenといったツールチェーンが登場します。
    • .wasm はJavaScriptから WebAssembly.instantiate などで読み込めます。現在のMDNでは instantiateStreaming や compileStreaming も整理されています。
    • 複雑なデータ型をJavaScriptとWebAssemblyの間で渡す場合は、WebAssembly.Memory のArrayBufferを通じて、ポインタのように位置を渡す必要があります。
    • WebAssemblyはstack machineとして説明され、命令は値をスタックに積み、演算が上から取り出す形で進みます。
    • .wasm moduleは、Type、Function、Codeなどの必須sectionと、Import、Export、Memory、Table、Dataなどの任意sectionから構成されます。

    参照リンクから見えたこと

    MDNのWebAssemblyページでは、WebAssemblyは低レベルでコンパクトなバイナリ形式を持ち、C/C++、C#、Rustなどのコンパイルターゲットとして説明されています。この記事の時点では読み込み手順がまだ手作業寄りでしたが、現在のMDNではWebAssembly JavaScript APIや各種streaming APIも体系化されています。

    WebAssembly text formatの解説も確認しました。バイナリの .wasm と、人間が読めるテキスト表現の対応を知ると、記事内で出てくるhex、binary、text representationの説明が見通しやすくなります。

    コメント欄で触れられていたWebAssembly FAQも重要です。なぜLLVM bitcodeをそのまま配布形式にしないのか、という問いは、WebAssemblyが単なるコンパイラ内部表現ではなく、Webで長く安定して使うための実行形式として設計されていることを示しています。

    気づき

    今回の気づきは、WebAssembly moduleを理解するには「高速な別言語実行」より先に、「JavaScriptと低レベルコードの境界」を見る必要があることです。関数呼び出しは簡単に見えても、文字列や構造体を渡すにはMemoryを共有し、Export/Importで境界を設計する必要があります。この境界の設計が、後のWASIやRLBoxのような話にもつながっています。

    あわせて読みたいリンク

  • WASIは、WebAssemblyをブラウザ外へ出すための“安全なシステム境界”だった

    WASIは、WebAssemblyをブラウザ外へ出すための“安全なシステム境界”だった

    Mozilla HacksのStandardizing WASI: A system interface to run WebAssembly outside the webを読みました。WASIは、WebAssemblyをブラウザの外でも安全に動かすためのシステムインターフェースを標準化しようとする取り組みです。

    WebAssemblyは、もともとWebページ内で高速にコードを実行するための技術として広まりました。ただ、WebAssemblyの特徴である安全なサンドボックス、移植性、コンパクトなバイナリ形式は、ブラウザ外でも役立ちます。問題は、ファイル、ネットワーク、時刻、乱数のようなシステム機能へどう安全にアクセスするかです。WASIは、その境界を設計するための標準です。

    記事の要点

    • WASIは、WebAssembly System Interfaceの略で、WebAssemblyプログラムがOSの機能へアクセスするための標準化されたインターフェースです。
    • 従来のシステムコールをそのままWebAssemblyへ渡すのではなく、移植性と安全性を保ちながら、必要な権限だけを渡すことを目指しています。
    • 記事では、wasmtimeやLucetのようなブラウザ外WebAssemblyランタイム、ブラウザ用polyfillが初期実装として紹介されています。
    • WASIはcapability-based securityを重視します。たとえば、プログラムへファイルシステム全体ではなく、特定ディレクトリへの権限だけを渡す考え方です。
    • Emscriptenのような既存の移植手法とは異なり、WASIは各環境ごとにOSをエミュレートするのではなく、共通の低レベル標準を作ろうとしています。
    • wasi-sysrootやlibpreopenのような部品は、既存言語やC/C++プログラムをWASI上で扱うための基盤です。

    参照リンクから見えたこと

    WASI.devを見ると、WASIは今も「securely access operating system capabilities」という方向で説明されています。WebAssemblyの安全な実行モデルを、ブラウザ外のCLI、サーバー、プラグイン、エッジ環境へ広げるための土台です。

    記事中のwasmtimeやLucetは、WebAssemblyを単なるブラウザ機能ではなく、独立した実行環境として扱う流れを示しています。後のBytecode AllianceやサーバーサイドWasmの流れを考えると、この記事はかなり早い段階でその方向を説明していました。

    また、Mozilla HacksのWebAssembly modulesの記事では、WebAssemblyが概念上の機械向けアセンブリとして説明されています。WASIは、その概念機械が外部世界とやり取りするときの標準的な窓口を決める話だと捉えると分かりやすいです。

    気づき

    今回の気づきは、WASIの本質が「WebAssemblyをOSっぽく便利にする」ことではなく、「OSへ触れる境界を最初から権限ベースで作り直す」ことにある点です。既存のアプリを動かすために何でも許すのではなく、必要な能力だけを明示的に渡す。この発想があるから、WebAssemblyをブラウザ外へ出しても安全性の物語を保てます。

    あわせて読みたいリンク

  • bugbugは、Firefoxのバグトリアージを“分類問題”として現実的に支える

    bugbugは、Firefoxのバグトリアージを“分類問題”として現実的に支える

    Mozilla HacksのTeaching machines to triage Firefox bugsを読みました。Firefoxに日々届く大量のBugzillaチケットを、機械学習で適切なproduct/componentへ振り分ける bugbug の初期導入を紹介する記事です。

    バグ報告は、開発者の目に届いて初めて修正へ進みます。ただし、Mozilla規模では毎日多くの報告や機能要望が届き、すべてを人手で正確に分類するのは難しくなります。この記事は、その最初の分類を機械に補助させることで、トリアージ担当者と開発者の時間を取り戻そうとする話です。

    記事の要点

    • bugbugは、新しく登録された未分類バグに対して、適切なproduct/componentを自動で割り当てる機械学習ツールです。
    • 学習データには、過去20年分のBugzillaデータのうち、Mozillianがレビューして分類済みのバグが使われています。
    • 運用時には、バグが最初に登録された時点まで履歴を巻き戻し、後から追加された情報を学習に混ぜないようにしています。
    • 入力特徴量には、タイトル、最初のコメント、キーワード、フラグなどが使われ、モデルにはXGBoostが使われています。
    • モデルは常に分類を実行するのではなく、十分に自信があるときだけ割り当てます。記事時点では60%のconfidence thresholdが使われています。
    • 2019年2月末の本番投入後、記事時点で約350件のバグをトリアージし、開発者が動き始めるまでの中央値は2日と説明されています。

    参照リンクから見えたこと

    記事中のbugbugリポジトリを見ると、現在のbugbugは単なるcomponent分類器ではなく、test selection、defect prediction、regression検出、QA要否、spam判定など、ソフトウェアエンジニアリング向け機械学習の基盤として広がっています。前回紹介したFirefox CIのテスト選択も、この系譜の上にあります。

    関連リンクのMarco Castelluccio氏の記事では、Bugzilla上の「bug report」と「feature request」を見分ける取り組みが紹介されています。これは、単に担当componentを当てる前段として、そもそもチケットの性質を理解する必要があることを示しています。

    また、BugzillaやXGBoostへのリンクも確認しました。ここで面白いのは、最新の巨大モデルではなく、既存の構造化データとテキスト特徴量を使った実務的な分類器で十分に価値を出している点です。

    気づき

    今回の気づきは、bugbugが「人間の判断を置き換えるAI」ではなく、「自信がある範囲だけ先に動かす仕分け係」として設計されていることです。60%のしきい値を置き、誤分類を抑えながら、明らかなものだけ早く担当者へ渡す。この控えめな自動化だからこそ、トリアージの現場に入れやすかったのだと思います。

    あわせて読みたいリンク

  • Firefox Nightlyの自動化機能は、WebDriver BiDiへ向かう橋渡しだった

    Firefox Nightlyの自動化機能は、WebDriver BiDiへ向かう橋渡しだった

    Mozilla HacksのImproving Cross-Browser Testing, Part 2: New Automation Features in Firefox Nightlyを読みました。前回紹介したWebアプリテストの現状編に続き、Firefox NightlyでPuppeteerやSelenium 4から使えるようになった新しい自動化機能を紹介する記事です。

    Part 1では、WebDriverの安定した標準性と、DevToolsプロトコルの双方向・低レベルな柔軟性の間にある課題が整理されていました。Part 2では、そのギャップを埋めるために、Firefox NightlyがPuppeteerやSelenium 4とどう接続し始めたのかが説明されています。

    記事の要点

    • PuppeteerはChrome DevTools Protocolを前提に発展したツールですが、Firefox Nightlyでも利用できるようにする取り組みが進められていました。
    • npm install puppeteerでFirefox Nightlyを取得し、product: 'firefox'を指定して起動する形が紹介されています。
    • Selenium 4でも、DevTools由来の機能を使えるようにする動きがあり、Firefox側ではRemote Protocolを通じて接続します。
    • Firefox Nightlyでは --remote-debugging-port を使ってリモートデバッグ用のポートを開き、自動化クライアントから接続します。
    • ただし、記事はこの時点の実装を最終形とはしていません。最終的には、ブラウザ横断の標準としてWebDriver BiDiへ向かう流れが示されています。
    • 問題報告先としてPuppeteerのissue tracker、Bugzilla、Matrixのremote-protocolチャンネルも案内されており、開発中の機能としてフィードバックを集めていました。

    参照リンクから見えたこと

    Puppeteerは、ブラウザ自動化を開発者体験に近いAPIで扱えるツールです。記事中のcross-browser exampleや、Firefox対応状況を示すページは、当時のFirefox対応がまだ段階的なものだったことを示しています。

    Selenium 4は、従来のWebDriver資産を持つ利用者にとって重要です。記事がPuppeteerとSeleniumの両方を扱っているのは、新しいDevTools系機能を使いたい層と、既存のWebDriver/Selenium資産を持つ層の両方を橋渡しするためだと読めます。

    WebDriver BiDi仕様も確認しました。従来のWebDriverがコマンド/レスポンス中心だったのに対し、BiDiはブラウザからイベントを流せる双方向プロトコルです。この記事時点のFirefox Nightly対応は、その完成形へ向かう実験的な通路だったと言えます。

    気づき

    今回の気づきは、標準が完成してから実装するのではなく、Nightlyで先に開発者と接続し、実際のツールからフィードバックを得ながら標準へ近づけている点です。Puppeteer対応もSelenium 4対応も、単なる互換機能ではなく、WebDriver BiDiへ向けて実利用の要求を集めるための足場になっていました。

    あわせて読みたいリンク

  • クロスブラウザテストは、WebDriverの安定性とDevToolsの即時性の間で揺れていた

    クロスブラウザテストは、WebDriverの安定性とDevToolsの即時性の間で揺れていた

    Mozilla HacksのImproving Cross-Browser Testing, Part 1: Web Application Testing Todayを読みました。Webアプリのテスト自動化が、WebDriverの標準化された安定性と、DevToolsプロトコルの低レベルな柔軟性の間で揺れていることを整理した記事です。

    Webアプリは、OS、ブラウザ、端末、画面サイズがばらばらな環境で動きます。MDN Developer Needs Assessmentでも、クロスブラウザテストは開発者の大きな痛点として挙げられていました。この記事は、なぜその痛みが残り続けるのかを、ツールの歴史とプロトコルの設計から説明しています。

    記事の要点

    • 現在のクロスブラウザ自動テストの中心には、W3C標準のWebDriverがあります。
    • WebDriverはHTTPベースの同期的なコマンド/レスポンスモデルで、Seleniumの流れをくむ分かりやすい仕組みです。
    • Firefoxでは geckodriver がWebDriverメッセージをGeckoのMarionetteプロトコルへ変換し、ChromeDriverやSafariDriverも同様にブラウザ固有の内部プロトコルへ橋渡しします。
    • HTTPベースのWebDriverは安定していて大規模運用しやすい一方、ログやネットワークイベント、突然出るアラートのような非同期イベントを扱いにくい弱点があります。
    • DevToolsプロトコルは双方向通信なので、コンソールログやネットワークイベントをリアルタイムに受け取れます。ただし、ブラウザ内部実装に近く、エンジンごとに差が大きくなります。
    • Puppeteer、Playwright、Cypressのようなツールは、WebDriverだけでは難しい機能を提供するためにDevTools系の仕組みへ寄っています。

    参照リンクから見えたこと

    WebDriver仕様を確認すると、WebDriverはブラウザを外部プロセスから制御するための、プラットフォームにも言語にも依存しにくいワイヤープロトコルとして定義されています。SeleniumやSelenium Grid、Sauce Labs、BrowserStackのような大規模なリモート実行基盤と相性がよい理由もここにあります。

    一方で、PlaywrightやCypressのような近年のテストツールを見ると、開発者が求めるのは単なるクリックや入力だけではありません。ネットワークの差し替え、コンソールログの取得、ブラウザ内部状態に近い情報、非同期イベントの観測など、よりフロントエンド開発に近い体験が求められています。

    記事が示している問題は、機能を求めるとブラウザ固有のDevToolsプロトコルに近づき、ブラウザ横断性を求めるとWebDriverの枠に戻る、という緊張関係です。この緊張が、後のWebDriver BiDiやFirefoxのPuppeteer対応につながる背景になっています。

    気づき

    今回の気づきは、テスト自動化の標準化は「操作できるコマンドを増やす」だけでは足りないということです。Webアプリが非同期イベントだらけになった以上、テストプロトコルもブラウザから自発的にイベントを送れる必要があります。ただし、それをブラウザ固有の内部APIとして広げると横断性が壊れます。だから、WebDriver BiDiのような標準化された双方向プロトコルが必要になったのだと理解できます。

    あわせて読みたいリンク

  • FirefoxのCIは、機械学習で“全部テストする”から“必要なテストを選ぶ”へ進んだ

    FirefoxのCIは、機械学習で“全部テストする”から“必要なテストを選ぶ”へ進んだ

    Mozilla HacksのTesting Firefox more efficiently with machine learningを読みました。Firefoxの巨大なCIで、どのテストをどの構成で走らせるべきかを機械学習で選ぶ取り組みを紹介している記事です。

    Firefoxには約85,000個のテストファイルがあり、Windows、macOS、Linux、Android、PGO、debug、ASan、Site Isolation、WebRenderなど、多数の構成で動かす必要があります。記事では、すべてを全構成で全pushごとに走らせると、1日に約23億件のテストファイル実行になり得ると説明されています。つまり、品質を守るにはテストが必要ですが、全部を機械的に走らせるだけではCIが持ちません。

    記事の要点

    • MozillaのCIは、統合ブランチでは一部テストを走らせ、定期的に広い範囲を確認し、code sheriffsが回帰を調査する運用になっています。
    • 従来の単純なヒューリスティックは、過去に失敗しやすいタスクを重視していましたが、変更内容そのものとは強く結びついていませんでした。
    • 新しい取り組みでは、過去の回帰データ、変更されたファイル、diff、テストとの距離、過去に一緒に変更された履歴などを使って、どのテストが失敗しそうかを予測します。
    • モデルにはXGBoostが使われ、入力は「TEST, PATCH」の組み合わせ、出力はFAIL / NOT FAILの二値分類として扱われています。
    • さらに、テストを選ぶだけでなく、どのOSや構成で走らせるかも最適化し、冗長な構成を減らします。
    • 結果の評価には、回帰検出率とpushあたりの時間を組み合わせた独自指標を使い、shadow schedulerで実験を継続しています。

    参照リンクから見えたこと

    記事中のActiveDataは、テスト結果のような大量データを集計・検索する基盤として紹介されています。機械学習以前に、まず過去のテスト実行結果を使える形で持っていることが前提になっています。

    bugbugは、Mozillaのソフトウェアエンジニアリング向け機械学習プロジェクト群の基盤です。記事末尾では、このテスト選択の取り組みも、Bugzilla管理支援から広がった大きな機械学習基盤の一部として位置づけられています。

    また、Firefox Source Docsのmach try autoを見ると、開発者が手でテスト構成を選ぶ負担を減らす方向が分かります。rust-parsepatchやrust-code-analysisも、パッチ内容を機械が理解できる特徴量へ変換するための部品としてつながっています。

    気づき

    今回の気づきは、この機械学習の目的が「AIでテストを賢くする」こと自体ではなく、CIという開発基盤のコストと開発者の認知負荷を同時に下げることにある点です。モデルの偽陽性は余分なテストを少し走らせるだけで済みますが、偽陰性は回帰を見逃します。だから精度だけではなく、回帰検出率、実行時間、実験用shadow schedulerまで含めて、運用可能な意思決定システムとして設計されています。

    あわせて読みたいリンク

  • Firefox 95のRLBoxは、WebAssemblyを“配布物”ではなく隔離の中間表現として使う

    Firefox 95のRLBoxは、WebAssemblyを“配布物”ではなく隔離の中間表現として使う

    Mozilla HacksのWebAssembly and Back Again: Fine-Grained Sandboxing in Firefox 95を読みました。Firefox 95で、RLBoxという細粒度サンドボックス技術を全対応プラットフォームへ広げ、Graphite、Hunspell、Oggなど複数のモジュールを隔離したという記事です。

    Firefoxの防御には、Site IsolationやProcess Isolationのようにプロセス単位で境界を作る方法があります。ただし、小さなC/C++ライブラリをすべて別プロセスへ移すのは現実的ではありません。メモリコストも、非同期化の手間も大きくなります。RLBoxは、その隙間を埋めるために、同じプロセス内でライブラリだけを信頼しないコードとして扱う仕組みです。

    記事の要点

    • Firefox 95では、RLBoxを使ったサンドボックスがデスクトップとモバイルを含む全対応プラットフォームへ広がりました。
    • Firefox 95ではGraphite、Hunspell、Oggが対象になり、ExpatとWoff2はFirefox 96で対象になると説明されています。
    • RLBoxは、対象ライブラリをWebAssemblyへコンパイルし、さらにネイティブコードへ戻すことで、通常のFirefoxビルドに組み込みます。Firefoxが .wasm ファイルを配布するわけではありません。
    • WebAssemblyを中間表現として使うことで、隔離されたコードが予期しない場所へジャンプしたり、許可された領域外のメモリへ触れたりできないようにします。
    • サンドボックス内から返ってくる値は攻撃者に操作されている可能性があるため、RLBoxはtainting layerで境界を明示し、ホスト側コードに検証を促します。
    • プロセス分離では重すぎるXMLパーサーやフォント・圧縮・メディア関連ライブラリのような部品に、より細かい隔離を適用できるのが狙いです。

    参照リンクから見えたこと

    RLBox公式ドキュメントを見ると、RLBoxはC++側から第三者Cライブラリを安全に呼び出すためのツールキットとして整理されています。単にメモリ隔離するだけでなく、サンドボックスをまたぐ関数呼び出し、コールバック、値の検証をAPIとして扱えるようにしている点が重要です。

    以前のMozilla Hacks記事Securing Firefox with WebAssemblyでは、Graphiteを対象にしたプロトタイプ的な導入が説明されていました。今回の記事はその続きで、GraphiteだけでなくHunspell、Ogg、Expat、Woff2へ対象を広げる段階です。

    また、wasm2cを使ってWebAssemblyからCへ戻し、既存のClang中心のビルドやプロファイルガイド最適化、クラッシュレポート、デバッグ、ソース検索へ乗せやすくしている点も面白いところです。WebAssemblyをランタイム機能ではなく、ビルドパイプライン上の隔離用IRとして使っているわけです。

    気づき

    今回の気づきは、WebAssemblyの価値が「ブラウザ上で別言語を動かす」だけに限らないことです。この記事では、WebAssemblyは配布形式ではなく、既存C/C++ライブラリを安全な形へ変換する中間表現として使われています。つまりRLBoxは、古いコードを全部Rustへ書き換える前に、信頼境界を先に作るための現実的な道具になっています。

    あわせて読みたいリンク

  • FirefoxのSite Isolationは、同一オリジンだけでは守れない時代のブラウザ防御だ

    FirefoxのSite Isolationは、同一オリジンだけでは守れない時代のブラウザ防御だ

    Mozilla HacksのIntroducing Firefox’s new Site Isolation Security Architectureを読みました。FirefoxのProject Fission、つまりSite Isolationがなぜ必要になったのかを、Spectre以後のブラウザ防御として説明している記事です。

    Webには昔から同一オリジンポリシーがあります。これは、あるオリジンの文書やスクリプトが、別オリジンのリソースへどう触れるかを制限する重要な仕組みです。ただしSpectreのようなCPUレベルのサイドチャネル攻撃では、アプリケーション層の境界だけでは足りない可能性が見えてきました。そこでFirefoxは、サイトごとにOSプロセスを分け、メモリ空間そのものを分離する方向へ進みました。

    記事の要点

    • Site Isolationは、異なるサイト由来のWebコンテンツを別々のOSプロセスに分けるFirefoxのセキュリティアーキテクチャです。
    • 背景には、MeltdownやSpectreのように、同じプロセス内のメモリを推測的実行やタイミング差から読み取る攻撃への対策があります。
    • 従来のマルチプロセス構成では、複数サイトが同じcontent processに入る可能性がありました。Site Isolationでは、トップレベルページだけでなく、別サイトのサブフレームも別プロセスに分けます。
    • 同じサイトかどうかの判定には、GitHub PagesやBlogspotのような共有ドメインを扱うためにPublic Suffix Listも関係します。
    • 副次的な効果として、重い処理やクラッシュの影響を別サイトへ波及させにくくし、CPUコアの活用にもつながります。

    参照リンクから見えたこと

    MDNの同一オリジンポリシーの記事を見ると、オリジンはプロトコル、ホスト、ポートの組み合わせで決まります。この仕組みは今でもWebセキュリティの土台ですが、Site Isolationの記事が扱っているのは、その上に「プロセスの境界」を足す話です。JavaScriptの権限モデルだけでなく、OSのメモリ分離を使って防御する発想です。

    Mozilla Security Blogのタイミング攻撃への緩和策も確認しました。Firefoxは当時、performance.now()の精度低下やSharedArrayBufferの無効化など、短期的な緩和策を入れています。Site Isolationは、こうした一時的な緩和から、より構造的な防御へ進む流れにあります。

    また、Project Fissionは単なる設定項目ではなく、Firefoxのプロセスモデルを作り替える大規模な取り組みでした。この記事の後に続くWin32k LockdownやRLBoxの記事まで見ると、Firefoxは「サイト単位」「OS権限」「ライブラリ単位」という複数の粒度で隔離を積み重ねていることが分かります。

    気づき

    今回の気づきは、Site Isolationが同一オリジンポリシーの置き換えではなく、別レイヤーの補強だという点です。同一オリジンポリシーは「触ってよいか」を決めるルールですが、Site Isolationは「そもそも同じメモリ空間に置かない」ための構造です。ブラウザの防御は、ルールだけでなく配置そのものを変える段階に入っていたのだと感じました。

    あわせて読みたいリンク

  • Firefox 100のProcess Isolationは、分離の旗を立てるだけでは済まない大改修だった

    Firefox 100のProcess Isolationは、分離の旗を立てるだけでは済まない大改修だった

    Mozilla HacksのImproved Process Isolation in Firefox 100を読みました。Firefox 100で到達したWindows向けのWin32k Lockdownを中心に、ブラウザのプロセス分離を強めるために何を作り替えたのかを解説する記事です。

    FirefoxはWebコンテンツを別プロセスで動かすことで、攻撃者がページ経由でcontent processを突破しても、OSやブラウザ全体へ簡単には届かないようにしています。ただ、content processが従来どおりWindowsの広いAPIへ触れる状態では、まだ攻撃面が残ります。この記事の主役であるWin32k Lockdownは、特にwin32k.sys系のグラフィックやウィンドウ管理まわりのシステムコールをcontent processから切り離す取り組みです。

    記事の要点

    • Firefox 100では、Windowsのcontent processでWin32k Lockdownを進め、win32k.sysへのアクセスを大きく制限しました。
    • この変更は単独では成立せず、Fission / Site IsolationやRLBoxと並ぶ、大きな防御強化の流れに位置づけられています。
    • WebRenderによって、ページ描画の多くはcontent processではなくGPU Process側へ移せるようになりました。
    • Canvas 2DやWebGLは、描画命令やGPU関連処理をIPC越しに扱う必要があり、性能と安全性の両方を見ながら調整されています。
    • フォーム部品、スクロールバー、複雑な文字の改行処理、第三者DLL読み込みなど、一見サンドボックスと関係なさそうな領域まで影響が及んでいます。
    • 同じ基盤整理により、macOSではWindowServerへのアクセス制限、Linuxではcontent processからX11 Serverへの接続削除にもつながっています。

    参照リンクから見えたこと

    記事中の参照先も確認しました。Site Isolationの記事では、異なるサイトを別プロセスに分け、Spectre系の攻撃で別サイトのメモリを読まれにくくする考え方が説明されています。今回の記事は、その分離したcontent process自体の権限をさらに削る話です。

    RLBoxの記事も合わせると、Firefoxの防御は一枚岩ではないことが分かります。サイト単位で分ける、content processのOS権限を削る、さらにライブラリ単位で細かく隔離する、という複数の層を重ねています。

    また、WebRender、MDNのCanvas API、WebGL APIを見ると、描画パイプラインの整理がセキュリティ強化にも効いている点が見えてきます。レンダリングの責任をGPU Process側へ移せる設計になっていたからこそ、content processからWindowsのグラフィック系APIを遠ざけられたわけです。

    気づき

    今回の気づきは、プロセス分離は「別プロセスにする」だけでは終わらないということです。分離した先のプロセスが、描画、フォーム、文字処理、DLL、GPU、OSウィジェットに直接触り続けるなら、攻撃面は残ります。Firefox 100の改修は、境界を引くだけでなく、その境界を越えていた責任を1つずつ別の安全な場所へ移す作業だったと言えます。

    あわせて読みたいリンク

  • Firefox 110のDLLブロック機能は、“全部禁止”ではなく利用者に選択肢を渡す設計だ

    Firefox 110のDLLブロック機能は、“全部禁止”ではなく利用者に選択肢を渡す設計だ

    Mozilla HacksのLetting users block injected third-party DLLs in Firefoxを読みました。Firefox 110で、Windows版Firefoxに読み込まれる第三者DLLを利用者がブロックできるようになった、という記事です。

    Windowsでは、ウイルス対策ソフト、ドライバー、スクリーンリーダー、銀行系ソフトなどが、別プロセスへDLLを注入して連携することがあります。記事では、Windows版Firefox利用者の70%以上で少なくとも1つの第三者DLLが確認されていると説明されています。一方で、こうしたDLLはFirefox内部の関数にフックすることがあり、クラッシュ、性能低下、セキュリティ上の懸念につながる場合があります。

    記事の要点

    • Firefox 110では、about:third-party から、問題を起こしている第三者DLLを確認し、利用者がブロックできるようになりました。
    • Mozillaは以前から既知の問題DLLを静的にブロックする仕組みを持っていましたが、それは多数のクラッシュを起こすような場合の最後の手段です。
    • すべてのDLL注入を既定で止めると、スクリーンリーダーや地域固有の銀行・行政系ソフトなど、利用者に必要な機能まで壊す恐れがあります。
    • ブロックに失敗したり問題が起きたりした場合は、Troubleshoot Modeで一時的にDLLブロックを無効化できます。
    • 技術的には、FirefoxのLauncher Processが起動の早い段階でブロックリストを渡し、DLL読み込み時の処理をフックして、対象DLLのロードを失敗させます。

    参照リンクから見えたこと

    記事中のリンク先も確認しました。サポート記事では about:third-party が、読み込まれたモジュール名、発行元、発生回数、ロード時間、クラッシュ関与の警告などを表示するページとして説明されています。利用者が「Firefoxが不安定」と感じたときに、原因がブラウザ本体なのか、注入された外部モジュールなのかを切り分ける入口になっています。

    関連するMozilla Hacks記事のSite IsolationやFirefox 100のProcess Isolationも読むと、Firefoxが信頼できないWebコンテンツをプロセス分離で閉じ込めようとしている流れが分かります。第三者DLL注入は、その分離されたプロセスの中へ外部コードが入ってくる話なので、別方向からブラウザの安定性と安全性を揺らす問題です。

    技術面では、Launcher Process、WindowsのCreateFileMapping、WriteProcessMemory、NtMapViewOfSection周辺の説明が重要です。さらにFirefox Source DocsのWindows DLL Blocklistingでは、静的ブロックリストと利用者向けの動的ブロックリストの違いも整理されています。

    気づき

    今回の気づきは、この機能が「外部DLLは危険だから全部止める」という設計ではなく、「必要な連携は残しつつ、問題が見えたときに利用者が止められる」設計になっていることです。ブラウザの安全性を高めるだけなら一律ブロックが単純ですが、実際の環境ではアクセシビリティ、業務、地域固有のサービスが絡みます。Firefoxはそこで、診断情報と選択肢を利用者に渡す方向を選んでいます。

    あわせて読みたいリンク