現行バージョンのFirefoxは、原則としてマルチプロセスで動作しています。 この記事では、Firefoxのマルチプロセス動作を無効化した時に起こる問題の例を紹介します。

Firefoxのマルチプロセス動作

Firefoxではマルチプロセス動作が後付けの機能¹として実装されたため、当初は設定でマルチプロセス動作の有効・無効を切り替えることができましたが、現在はそれらの設定は廃止されています。 マルチプロセス動作を無効化した状態のシングルプロセス動作で使われることは、現在は推奨されていません。

とはいえ、シングルプロセス動作を強制することは、設計上は現在も可能となっています。 具体的には、MOZ_FORCE_DISABLE_E10S という環境変数に適切な値²を設定すると、Firefoxのマルチプロセス動作は停止し、シングルプロセスで動作するようになります。

シングルプロセス動作のよく知られたデメリット

シングルプロセス動作で犠牲になる事柄としては、以下がよく知られています。

• 安全性。センシティブな個人情報が共有メモリ上に置かれるため、脆弱性を突く攻撃を受けた場合の情報漏洩のリスクが高まる。
• 安定性。Webページの内容が原因でメモリ不整合などが発生してクラッシュした時に、Firefox全体が巻き込まれる形で強制終了されてしまう。
• 応答性。FirefoxのUIとWebページの内容が同一スレッド上でシーケンシャルに処理されることから、Webページのスクリプトの動作によって、FirefoxのUIの応答性が低下したり、場合によっては、操作を受け付けないフリーズ状態になってしまったりする。

マルチプロセス動作はRAMを多く消費することから、RAMが著しく逼迫している環境においては、前述のデメリットを承知の上で、敢えてシングルプロセスで動かしたいと考える方もいらっしゃることでしょう。 安全性も、安定性も、応答性も、基本的な機能が備わった上でプラスアルファとして期待される物に過ぎず、一通りの機能が動作するのであればよい、という考え方は確かにあり得ます。

しかし、そのような選択を取りたい方にあまり認知されていないこととして、現在のFirefoxでは、シングルプロセス動作を強制すると、機能的にも正常に動作しなくなる部分があります。 この度、お客さまからのお問い合わせにより、その一例が発覚しましたので、注意喚起のためにご紹介します。

パスワードマネージャのトラブル

当初頂いたお問い合わせは、「Firefox Lockwise（新パスワードマネージャ）が期待通りに動作しない」というものでした。

Firefoxは、Webページのログインフォームに入力されたユーザー名とパスワードをセットで保存しておき、次回訪問時にそれらを自動入力する機能を持っています。 この機能は従来は「パスワードマネージャ」と呼ばれていましたが、Firefox ESR78以降³では従来のパスワードマネージャが廃止され、「Firefox Lockwise」という名前の新実装に置き換えられました⁴。 お問い合わせの内容は、この新パスワードマネージャになって以降、保存済みのパスワードが一覧表示されなくなった、というトラブルについてでした。

お客さま側での調査および原因切り分けによって、この時点で以下のことは分かっていました。

• Webページのログインフォームにパスワードを入力した際には、それを保存するかどうか尋ねられる。（期待通り）
• そのWebページを再訪した際には、ログインフォームにログイン情報が自動入力される。（期待通り）
• Firefox ESR68以前で使用していたユーザープロファイルを引き継いだ場合、Firefox ESR68で保存されたログイン情報も、ログインフォームに自動入力される。（期待通り）

これらのことから、ログイン情報自体が失われたわけではなく、あくまで新パスワードマネージャのUIに関わる部分の問題であると判断できます。

Firefoxの実装を調査した結果、新パスワードマネージャのUIは以下の流れで動作していることが分かりました。

1. ユーザーが新パスワードマネージャのタブを開く。
2. 開かれたタブの中に読み込まれたスクリプトが、Firefox本体に対して「新パスワードマネージャの初期化処理が要求された」胸を示すメッセージを送る。
3. 2で送られたメッセージをFirefox本体が受信する。
4. Firefox本体のスクリプトが、パスワードマネージャのデータベースを走査し、保存済みのログイン情報（ユーザー名と、パスワードの平文）の一覧を作成する。
5. Firefox本体のスクリプトが、1で開かれたタブの内容に対し、4で作成したログイン情報の一覧を含むメッセージを送る。
6. 1で開かれたタブのスクリプトが、5のメッセージを受信する。
7. 1で開かれたタブのスクリプトが、6で受信したメッセージを処理して、ログイン情報の一覧を表示する。

このとき、2と3の間、および5と6の間で、通常であれば、プロセスをまたいだメッセージのやり取りが発生します。 お客さまの環境では、3の段階までは処理が進行しているものの、3と4の間のタイミングで、Firefoxのエラーコンソール上に以下のログが出力されていたことが分かりました。

AboutLoginsParent: Received AboutLogins:Subscribe message the remote type didn't match expectations: null == privilegedabout

ログの出所を調べると、Firefoxのメインプロセスがメッセージを受信した際に、その内容を処理するよりも前の時点で、メッセージの送り主であるプロセスの種類を確認し、種類が想定どおりでなければ処理を中断する実装となっていることが分かりました。 パスワードの平文という、極めてセンシティブな情報を取り扱うためか、「信用できる」と確証を持って判断できる相手以外には応答しないという、安全に安全を期した設計になっている模様です。

しかしながら、今回問題が発生していたお客さまの環境では、前述の環境変数によってマルチプロセス動作が無効化され、強制的にシングルプロセスで動作する状態になっていました。 つまり、このように「Firefox本体のプロセス」と「タブのプロセス」が同一である状況では、本体側から見たときに「タブのプロセスの種類」を識別するための情報が設定されないために、メッセージの送り主の種類を特定できなくなっていた、というのが、この度のトラブルの状況です。

設計上避け得ない問題のため、これを回避するためには、マルチプロセス動作を再び有効化する以外の対処方法はありません。

なお、Firefoxのバグトラッキングシステム上では、このことは2年前の時点で報告されており、別の類似の報告に対する議論の中で示された「デスクトップ版Firefoxでは、シングルプロセス動作はもはや設定画面から選択できない状態になっている以上、その状態で何が起こっても修正は行わない」という判断に基づいて、修正しないという判断が行われたようでした。

まとめ

以上、Firefoxのマルチプロセス動作を強制的に無効化した場合に起こる問題の一例をご紹介しました。

文中で言及したBug 1510087のコメントやBug 1592562のコメントでは、現在のFirefoxについて、マルチプロセス動作無効化時に起こる不具合を解消するための努力は行われない方針であることが明言されています。 今後も、マルチプロセス動作になっていることが前提で書かれたコードの分量が増えていくことが予想され、シングルプロセス動作での使い勝手は悪貨していくと予想できます。

マルチプロセス動作であっても、コンテンツ領域用のプロセスの最大数を制限することは依然として可能です。 どうしてもRAM使用量を削減したい場合には、マルチプロセス有効・コンテンツプロセス数1の状態とするのが安全でしょう。

とはいえ、Webの様々な新しいニーズに対応するために、今後もWebブラウザのRAM使用量は増加傾向が続くと考えられます。 RAM使用量のある程度の増加はもはや避け得ないものとして、予算を確保した上で、RAMの増設など実行環境側の増強の方に力を入れていくことをおすすめします。

ツイートする

フォローする