MetaMask、オフにしても外部サーバーと接続し続けるプライバシー不具合を修正

稼働中のSnapsはオフ後も通信を続けていた

MetaMaskに、データ共有の設定をオフにしても外部サーバーとの接続が生き続けるというプライバシー上の不具合があり、開発チームは11月12日、GitHub上で修正を公開した。問題の中心にあったのは、価格や残高などの情報を取得するためにMetaMaskが外部サーバーへ接続するかどうかを制御する「Basic Functionality」というトグルだ。外部への通信を減らしたいユーザーはこれをオフにできる。だが公開されたコードの変更内容は、この設定を無効にしても一部の外部サーバーとの通信が依然として行われていたことを、そのまま認めている。

不具合の原因は、MetaMaskの拡張フレームワーク「Snaps」にある。Snapsはウォレットが外部のプログラムを実行し、他のチェーンへの対応を追加できる仕組みで、ビットコインやStellarもその対象だ。旧来の動作では、Basic FunctionalityをオフにするとSnapsからの新規リクエストはブロックされる一方、すでに稼働していたプログラムはそのまま残り、それぞれのエンドポイントと通信を続けた。設定が新規の活動だけを止め、メモリ上に残った処理を誰も制御できない状態だったことが、不具合が残り続けた理由だ。ビットコンネットワークに接続するサーバーと、デジタル資産の価格データを供給するサーバーは到達可能なままだった。つまりプライバシー設定を有効にしたはずのユーザーが、実際にはその設定で遮断されるはずのサービスへの接続を発生させ続けていた。

修正後のコードはこれを断った。Basic Functionalityをオフにすると、MetaMaskは稼働中のSnapsを停止させ、外部接続も終了させる。キルスイッチが一階層深く移された形だ。新規のSnapsを止めるだけでは不十分で、接続を保持しているのはすでにメモリ上にあるプログラムだからだ。開発者は変更前に検証テストでこのエラーを4回再現し、いずれの実行でも望ましくない接続が現れた。修正後は4回とも正常に動作し、トグルを切った瞬間に接続が切断された。

10月にも同種の暴露があった

同じ約束の破れは今回が初めてではない。10月29日、MetaMaskはBasic Functionalityをオフにしても複数の外部サーバーへリクエストが送られていた事例を自ら公表しており、オプトアウト後もウォレットが外部と通信していた先行事例だった。この公表は企業自身の手で行われたため記録に残っている。11月12日のコード変更はSnapsの挙動を個別に対処するもので、10月の開示で指摘されたすべてのエラーを解決するかについてはMetaMaskは言及していない。この空白が、本件の未解決部分だ。先行の発表を読んだユーザーには、その中で説明された事例が修正で閉じられたという確認はなく、再現されたSnapsの不具合がテストを通過したという事実だけがある。

舞台となったのは、もともとビットコインとは無関係に生まれたウォレットだ。MetaMaskはイーサリアムウォレットとして始まり、Snapsは他のチェーンへ対応範囲を広げる仕組みで、その対象にビットコインやStellarが含まれる。イーサリアム系ウォレットでのビットコインの自己管理は、歴史的には別のチェーン上で発行されるトークン化された代替物であるラップトビットコインを通じて行われてきたが、Snapsはこれを複数ネットワークへの直接対応へと広げた。この越境はかつて、ビットコインは独立を保つべきだとする立場であるビットコイン・マキシマリズムの支持者から反発を引き、今では多くのビットコイン保有者がインストールしたことのないウォレット内で、ビットコインネットワークのトラフィックが発生する状態を作った。Snapsはさらに、イーサリアムの技術基盤ではなくビットコイン上に構築される貸付や取引、利回りサービスの一群であるBitcoin DeFiへのウォレットの参入も担っており、フレームワークが外部サーバーに接続する処理を常時稼働させている背景はここにある。

影響を受けたユーザーにとって、実害の範囲は狭いが具体的だ。設定はオフスイッチとして表示され続けた一方で、ウォレットはビットコインネットワーク基盤や価格サーバーへの接続を保持していた。今回の開示が記録しているのは接続性の不具合であって資金の移動ではない。設定に反して残ったトラフィックこそ確認されており、残高へのリスクが示されたわけではない。

修正が語らない部分

筆者の検証は一次記録から出発する。MetaMask自身のリポジトリにあるコード変更は、Basic Functionalityの無効化が稼働中のSnapsを停止させ接続を閉じることを明記し、開発者テストで4回の再現を通過した。開示が確認していないのは、10月の事例がこの修正の対象かどうかであり、この沈黙こそが、同設定に依存するすべてのユーザーにとって支えとなる事実だ。望ましくないサーバー通信は、エクスプロイトやリプレイアタックのように資金を動かすものではない。損なわれたのは、有効になっているとユーザーが信じていたプライバシー制御だ。本件が再び動的な話題に変わるのは、MetaMaskが「修正は残る全事例を閉じる」と明言したときだ。その声明は、まだ出ていない。