Matrixを見限った理由（2024）
(forum.hackliberty.org)- Matrixプロトコルの構造的なセキュリティ限界と運用上の問題により、Hack LibertyコミュニティはSimpleXへ移行した
- メタデータ露出、管理者権限の悪用、暗号化の脆弱性などにより、ユーザーのプライバシーと安全性が深刻に損なわれている
- Matrix.org組織が収集する個人データや、Cloudflareによる中間者介入、Torブラウザ対応の終了なども信頼低下の要因として指摘されている
- SimpleXはユーザー識別子なしでメッセージを配送し、2-hop onionルーティングと耐量子計算機暗号の鍵交換でセキュリティを強化する
- この移行は、分散型コミュニティのセキュリティとプライバシー確保のための現実的な代替案として提示されている
連合型プロトコルの限界
- 連合型（federated）ネットワークは、複数サーバー間の相互作用を通じて検閲耐性を提供するが、設計上の根本的なセキュリティ問題を内包している
- 2年以上にわたりMatrixやLemmyのような公開連合サービスを運営した結果、すべての連合型プロトコルに共通する構造的欠陥が確認された
Matrixプロトコルの問題点
メタデータ露出
- Matrixでは、メッセージ送信者、ニックネーム、プロフィール画像、リアクション、既読表示、タイムスタンプなどが暗号化されていない
- メッセージ検証、性能要件、プロトコル設計の不備などにより、一部のメタデータ露出は意図的または設計上の欠陥として存在する
- 実際の漏えい事例を示すリンクが例として提示されている
管理者による中間者攻撃（Admin in the Middle）
- 悪意あるサーバー管理者は、Synapseデータベースの参照だけでユーザー情報、リアクション、ルームのメタデータなどを収集できる
- ユーザーなりすまし、ルームのトピック変更、任意の招待・追放、権限操作などの積極的攻撃を実行できる
- 新しいデバイスを追加してE2EEメッセージへアクセスすることも可能で、ユーザー警告を無視するよう設定することもできる
プロトコルの構造的弱点
- Matrixは部分複製グラフデータベースの形で動作しており、次のような22の主要脆弱性が指摘されている
- 削除不可能なイベント、スパムへの脆弱性、履歴の不整合、メッセージ偽造の可能性、選択的暗号化、署名不一致、Split-brainルーム生成、違法メディア複製リスクなど
- サーバー間の状態不一致により、管理権限の喪失やルーム閉鎖不能の問題が発生する
Megolm暗号化の脆弱性
- MatrixのMegolmプロトコルでは、多数の実質的な暗号学的脆弱性が報告されている
- 機密性の崩壊、検証攻撃、信頼済みなりすまし、IND-CCA攻撃など、多様な攻撃シナリオが存在する
- 攻撃はサーバーの協力を前提とし、**Elementクライアントの中核ライブラリ（matrix-js-sdkなど）**で再現可能である
リソースの過剰消費
- Synapseサーバーは高いCPU、メモリ、ディスク、帯域幅を要求する
- ユーザー数に応じて4〜12のインスタンスが必要で、運用コストが過大である
Matrix.org組織の問題
データ収集
- matrix.orgとvector.imは、ユーザーのメールアドレス、電話番号、IP、デバイス情報、利用パターン、ルームIDなどを定期的に収集している
- 初期設定では個人情報が公開され、アップロードされたファイル・画像・プロフィール情報が公開アクセス可能になる
- 独自サーバーを使用していても、中央サーバーへ機微データが送信される
児童性的虐待コンテンツの流通
- Matrix.orgの対応の遅さにより、数万人の小児性愛者が違法コンテンツを拡散した
- ルームを閉鎖できないこと、未検証のメディアアップロード、自動複製機能により、違法資料が連合全体に拡散する
- 各ホームサーバーが違法コンテンツをホスティングする可能性が高い
Cloudflareによる中間者介入
matrix.orgとvector.imのTLSトラフィックがCloudflareで終端されていることが確認され、中間者攻撃の可能性がある
Torブラウザ対応の終了
- Element WebクライアントはTorブラウザをもはやサポートしていない
- Torの旧版Firefoxベース、テスト不可、資金不足などを理由に、対応予定なしとして終了された
Lemmy関連の問題
- Matrixと同じ連合型構造により、データ複製、検閲、違法コンテンツ責任の問題が同様に発生する
- 「de-federation」による検閲型の分散化、**集団思考（groupthink）**の誘導、アップ・ダウン投票の操作などにより、自由な議論が制限される
SimpleXへの移行
識別子のない通信構造
- SimpleXはユーザー識別子（電話番号、メールアドレス、公開鍵など）を一切使用しない
- 各会話ごとに独立した単方向メッセージキューアドレスを使い、相手との接続を匿名化する
- 今後は自動キュー交換機能により、サーバー間移動と追跡防止を支援する予定である
スパムと悪用の防止
- 招待リンクや一時アドレスを直接共有しなければ連絡できず、望まない接触を防げる
- アドレスの変更または削除により、スパムを完全に遮断できる
データの完全所有
- すべてのユーザーデータはクライアント端末にのみ保存され、サーバーは一時的なリレー役だけを担う
- サーバー間トラフィックでも送受信者を識別できず、追跡不可能なメッセージ配送構造になっている
ユーザー運営ネットワーク
- 誰でも独自のSimpleXサーバーを運営でき、SDKとオープンプロトコルによってボットやサービス開発が可能である
Matrixとの比較
| 項目 | SimpleX | Matrix |
|---|---|---|
| 暗号化 | 二重暗号化 + 耐量子鍵交換 | Megolm（脆弱性あり） |
| メッセージルーティング | 2-hop onionルーティング | 連合型構造、メタデータ露出 |
| 分散化 | 中央コンポーネントなし | 中央ブートストラップノードあり |
| メディア処理 | ローカル暗号化および手動キュー回転 | 未検証アップロード、自動複製 |
| Tor対応 | 対応あり、onionルーティング提供 | 対応終了 |
| Cloudflare | 不使用 | CloudflareでTLS終端 |
SimpleXの技術的特徴
- Double Ratchetベースのエンドツーエンド暗号化、耐量子鍵交換、2-hop onionルーティング
- TorおよびSOCKSプロキシ対応、TLS 1.2/1.3セキュアチャネル、再送防止署名構造
- 完全な分散ネットワーク、Flux統合によるメタデータ保護強化
ユーザー体験と追加機能
- E2EE音声・ビデオ通話、暗号化通知、ローカルファイル暗号化、メッセージ編集・リアクション、省電力型グループチャット
- 匿名モード、コンソールクライアント、ボットSDK、Linodeワンクリックサーバー配備など、多様な拡張機能を提供する
今後のロードマップ
- 安定性向上、大規模コミュニティ対応、プライバシー・セキュリティスライダー、エフェメラル会話、位置共有、自動化ルールなどを開発予定
結論: Hack Libertyは、Matrixの構造的なセキュリティ欠陥と運営への不信により、SimpleXベースの完全なプライバシー重視ネットワークへ移行した。SimpleXは、識別子のない通信、強力な暗号化、分散構造によって、次世代の安全なコミュニティプラットフォームとして提示されている。
1件のコメント
Hacker News の意見
Matrix には本当に成功してほしかったが、もう完全に諦めた。
state resolution システムがあまりに複雑で、リソース消費も激しい。ルームが壊れることも今なお起きる。単にルームのメンバー一覧を計算するだけでも、DB容量が数GBに達するほど非効率だ。
しかも何年経っても、カスタム絵文字、ユーザーステータス、招待リンクのような基本機能すらない。
関連イシュー: #339, #573, #426
最近は SimpleX が Signal に近いターゲットを狙いつつ、別のアプローチを取っているようで興味深い。ただ、まだ一般的に広く普及している感じはない。
カスタム絵文字やユーザーステータスのような機能は、すでに MSC 提案 が存在し、実装も進行中だ。2023年以降は資金難のため、生き残りをかけて政府プロジェクト中心に開発を集中していたためだ。
私と私の周囲では、Matrix の体験は非常に良好 だった。Beeper と Element を通じて数十人の非技術者をオンボーディングしたが、みんな問題なく使えている。デバイス変更も問題なく、Discord と比べても UX はかなり競争力がある。
だから HN で出てくる不満が理解できない。おそらく古いサーバーや互換性のないクライアントを使っているのではないかと推測している。
SimpleX は「ユーザー識別子がない」と主張しているが、実際には IPアドレスがそのまま露出 している。公開ネットワーク全体が Akamai と Runonflux の2社によってホストされている。
Tor を標準で同梱し、IPマスキングのオプションを明確に説明すべきだ。現状では「追加の識別子を作らない」という意味にすぎず、IP自体は保護されていない。
Tor を内蔵しない理由は FAQ に説明してある。
Matrix についての意見はないが、Nebuchadnezzar 論文 はぜひ読むことを勧める。グループ向けセキュアメッセージングの核心は暗号化ではなく、グループメンバーシップ管理 にある。
論文リンク
DAG の並べ替えを何度も試して合意を取ろうとしている部分を見て、このプロジェクトは根本的に間違っていると思った。むしろ NNTP + GnuPG で自分でグループチャットを作ったほうがよさそうだ。
Matrix の年末アップデートを投稿した: Matrix Holiday Special 2025
みんなよい年末を :)
私は 6年 Matrix を使っている。2020年の大規模流入時は大変だったが、今は安定している。
今でも Element Web のバグと遅さ には不満があるが、軽量な代替クライアントは多い。
メタデータ暗号化はまだ完全ではないが、日常会話では大きな問題ではない。
Matrix を使い続ける理由は、分散型アーキテクチャ、E2EE、マルチデバイス、自由ソフトウェア、セルフホスティング可能 という代えがたい組み合わせにある。
プロジェクトリーダーの 落ち着いたリーダーシップ にも信頼感がある。
matrix-rust-sdk に移行すれば大きく改善しそうだ。Aurora プロジェクト にも期待している。
Moxie（Signal 創業者） が 2020年の CCC で、フェデレーション型システムの問題を指摘した講演がある。
動画リンク
「Why Federation Must Die」という主張には同意しない。フェデレーション型は難しいが、Chatcontrol のような規制下でも EU 内で安全な通信を維持するための唯一の方法だ。
中央集権型システムは1つの組織に圧力をかければ済むが、フェデレーション型では誰もがサーバーを運用できるため、統制しにくい。
反ビッグテック陣営 は実際には複数の価値観の連合体だ。
一方は フェデレーションと自律性 を、もう一方は 暗号化とプライバシー を優先している。
互いの優先順位が違うことを認識すれば、完全に一致しなくても、もっと 寛容な協力 が可能になると思う。
Matrix のようなプロジェクトがこの両陣営を同時に満足させるのはほぼ不可能だ。
しかもセキュリティ・プライバシー陣営の声のほうが大きいため、議論全体が実際以上に否定的に聞こえることが多い。
今年、私たちは Matrix のメタデータ保護 を改善している。
以前は分散型暗号化の安定化に注力していたため、メタデータ保護は後回しだった。
また、ネットワークトラフィック自体がすでに多くのメタデータを露出させるため、完全な秘匿は難しい。
それでも 2026年にはさらによい改善が予定されている。
参考までに2016年の発表資料もある: Matrix Jardin Entropique (PDF)
一部の主張（例: 中央サーバーへのデータ送信）は事実ではない。メディア認証は 2024年6月から適用されており、2025年には Trust & Safety チーム も強化された。