- 2026年4月から、認証されていないデバイスはElementでエンドツーエンド暗号化（E2EE）メッセージを送受信できなくなる
- この変更はMatrix仕様の更新に伴うもので、すべてのユーザーの会話の安全性を強化するための措置
- デバイス認証は、ユーザーの各デバイスが実際に本人の所有物であることを暗号学的に証明する手続きであり、信頼されていないメッセージ表示をなくす
- 今後は認証済みデバイスのみが会話に参加でき、警告アイコンや盾の表示はなくなる
- この措置は、信頼に基づく安全なコミュニケーション環境を構築するための重要なステップ
セキュリティアップデート概要
- 2026年4月から、Elementは認証されていないデバイスによるエンドツーエンド暗号化メッセージの送受信をブロックする
- これは2025年10月のMatrixカンファレンスで発表されたMatrix仕様アップデートに従った措置
- ユーザーは既存デバイスで暗号化メッセージを引き続き送受信するために、デバイス認証を完了する必要がある
- このアップデートの目的は、メッセージが実際に意図した送信者から来たものであることを保証すること
- Elementはこれにより、最も安全なコミュニケーション技術の提供を目指す
認証されていないデバイスのリスク
- 認証されていないデバイスは攻撃ベクトルになり得る
- たとえば会話中に警告アイコンが表示される場合、それは単なる未認証デバイスかもしれないし、アカウント乗っ取りの試みかもしれない
- このような警告を無視すると、ネットワーク全体にセキュリティリスクが広がる可能性がある
- Elementはすべてのユーザーにデフォルトでエンドツーエンド暗号化を提供しており、認証の必須化によって不確実性や悪意ある活動の可能性を取り除こうとしている
デバイス認証の役割
- デバイス認証は、各デバイス間の**暗号学的な「握手（handshake）」**であり、そのデバイスがユーザー本人の所有物であることを証明する
- 認証されていない新しいデバイスから送られたメッセージは、信頼されていないメッセージとして表示される
- 認証を必須にすることで、ユーザーはすべてのメッセージが信頼できる状態にあると確信できる
基本設計としての信頼
- 今後、デバイスは**「認証済み」または「会話に参加不可」**の2つの状態のいずれかに区別される
- 警告や盾のアイコンは今後表示されない
- これは、ユーザーが警告に慣れて無感覚になる問題を防ぐため
- デバイス認証は個人の保護だけでなく、ネットワーク全体の信頼環境の強化にも寄与する
- Elementはセキュリティを最優先とするシステム設計を推進しており、認証手続きはその中核要素
ユーザーが取るべき対応
- すでにデバイスを認証し、**復旧キー（recovery key）**を設定しているユーザーは追加対応不要
- そうでないユーザーは次の手順を実施する必要がある
- モバイル、Web、デスクトップなど、すべてのデバイスの認証状態を確認
- 復旧機能を設定する（任意だが強く推奨）
- 復旧機能は新しいデバイスの認証を簡単にし、すべてのデバイスを失った場合でも認証を復旧可能にする
- プラットフォーム別の具体的な手順は、Elementのユーザー文書で確認できる
認証しない場合の制限
- 2026年4月以降の未認証デバイスの制限事項
- メッセージを送信できない
- 受信メッセージの内容を表示できない（メッセージが届いた事実のみ確認可能）
- 結果として、未認証デバイスはE2EE会話では利用できない
信頼構築とサポート
- Elementはデバイス認証による信頼の確保を安全な通信の中核として強調している
- この変化は小さいが、セキュリティ水準を大きく高める措置と評価される
- ユーザーと協力し、すべてのメッセージが対面での会話と同じくらい信頼できる水準になることを目標としている
- 移行期間中はサポートチームがユーザーからの問い合わせに対応し、円滑な導入を支援する予定
1件のコメント
Hacker Newsの意見
3か月前にサーバーを停止し、コミュニティを再びIRCへ戻した
PodmanコンテナでIRCを動かしていたものが残っていたので、簡単に復帰できた
毎月、デバイス認証エラー、メッセージの復号失敗、UXの問題などに悩まされていた
初期は急速に進化していたが、ここ数年はUX改善がほとんどなく残念だ
MatrixとElementの関係も、今ではよく分からなくなっている
開発チームは無関心に見え、提案されていた「policy server」も未完成のままだ
ルームが空だったり送信が止まったりして、一度も実際にメッセージのやり取りに成功しなかった
「分散型JSONデータベース」という概念に執着するあまり
実際のチャットシステムとしての使いやすさを見失ったように思える
今でも使ってはいるが、一般ユーザーを引きつけるにはまだ先が長い
IRCベースのコミュニティをアップグレードするなら、Jabber(XMPP) の方が現実的な代替案だと思う
友人たちと試したが、粗いUXのせいで他のメッセンジャーより使いづらく
IRCブリッジのサポートが打ち切られてからは使う理由がなくなった
数か月前、私のデバイスがランダムに認証解除され、復旧キーでログインしたが依然として認証されなかった
iOS、Linux、Windows、Androidの間で相互認証がまったく噛み合わなかった
こうした強制的な認証手順は、実質的に非自発的なオフボーディングだ
問題のある認証方式があるなら、ブログで告知すべきだ
Elementは好きだが、こういう部分は事前の準備が必要だ
たまに成功してもすぐログアウトされ、昔のデバイス認証ポップアップが出続ける
最終的にすべてのプロフィールを失うのではないかと心配している
たまに開くたび、30分も問題解決に付き合わされることがあった
アイデアは良いが、労力に対する見返りがあまりにも低い
OSSプロジェクトのコミュニケーションにも悪影響を与える
私はかなり頻繁に使っているが、そういう問題は一度もない
数か月前にMatrixボットを実装しようとしたが、Python向けのオープンソースSDKが
E2EEとデバイス認証をまったくサポートしておらず、ひどい体験だった
代わりに内部Rust SDKのmatrix-rust-sdkを見つけたが、かなり良かった
Python/Kotlin向けのFFIバインディングもあったが、ドキュメントが不足していた
LLMとソースコードを頼りにどうにか動かし、絵文字認証にも成功した
今ではドキュメントも大きく改善され、参考クライアントも提供されている
Redditで見たMatrix批判の投稿を読んだが、
データが永続保存・複製される構造のため、性能とプライバシーが低いという
Signalはメタデータさえ保護するが、Matrixはルーム名、参加者、時刻などが露出するという
これが本当なのか、将来性のあるプロトコルなのか気になる
現在のメタデータ保護水準はSignalより低いが、改善は進んでいる
Matrixは脅威モデルが異なり、信頼範囲を自分で選べる
小規模サーバーで運用すれば、Signalよりデータ露出が少なくなる
完璧ではないが、進化の速さと方向性は前向きに見ている
基本的なプライバシー要件なのに、実装が遅い
メッセージ復号の問題も依然として残っている
それでもオープンなシステムの中では依然として最良の選択肢だと思う
SIMスプーフィング攻撃に弱い
モジュール型・分散型設計が長所である一方、参入障壁にもなっている
Signalは単純な構造のおかげで、中核機能の完成度が高い
結局のところ、信頼できるサーバーを前提にしたプラットフォームだ
このスレッドの不満はさておき、
未認証の状態でログインして暗号化メッセージをやり取りできないようにするのは合理的だと思う
6年間Matrixを使ってきたが、認証プロセスは今ではかなりスムーズだ
QRコードログインまで完成すれば、ずっと簡単になるだろう
個々の判断は合理的かもしれないが、全体としてコミュニケーション不足と
ドキュメント不足のせいで混乱が生じている
頻繁に使う人は大丈夫でも、たまに使う人は毎回復旧ゲームをさせられる
それによって、ログイン前のメッセージを復号できるようになる
認証ステップをスキップできるようにしたUXが問題だった
ブログで認証が何なのかを明確に定義すべきだった
「認証とは何か？」という質問に対して
新しいデバイスでログインする際、既存デバイスで暗号学的な本人性証明を行う
絵文字の比較、QRコードのスキャン、復旧キーの入力のいずれかで進める
ほとんどは素早く簡単だが、一部のクライアントにはバグがある
単に、新しいデバイスを既存デバイスで承認する手続きだ
これまで使ってきた暗号化メッセンジャーの中で最も簡単な認証方式だった
2台のデバイスに表示された絵文字が同じなら承認される
新しいデバイスでログインした際、既存デバイスで承認するだけでよい
私はThunderbirdをMatrixクライアントとして使っているが、
ElementやNhekoを開くと互いに未認証だと警告してくる
認証ボタンを押しても何も起きず、QRコードも表示されない
MatrixのUXは本当に悪夢レベルだ
更新も遅いので使うのをやめた
改善の兆しがまったくない
アルファクライアントを使ってみたが、認証ポップアップが消えない
クライアントによっては認証フロー自体が実装されておらず、
新規クライアント参入のハードルがさらに高くなりそうだ
クライアントが頻繁にクラッシュし、同期遅延も深刻だ
こうした理由から、MatrixよりXMPPの方が優れた分散型チャットの選択肢だと思う
XMPPは欠陥をうまく処理し、リアルタイム同期の問題もない
職場の同僚を説得するには、もっと良いUIが必要だ
ただしXMPPにはCross Signingや鍵バックアップがなく、
Matrixほどの利便性はまだない
Elementは重く、他のクライアントは機能の偏りが大きい
その代わり、ProsodyサーバーでXMPPを再び試してみたが
ドキュメントはやや不親切でも、リソース効率には驚かされた
XMPPサーバーが低スペック環境でもよく動くのは印象的だ
クライアント側はやや期待外れだったが、
ドキュメント改善の余地は大きいと思う
結局のところ、私は自由・オープンソースのメッセンジャー生態系が繁栄してほしい
最新のMatrix Conference動画がmedia.ccc.deに公開されている
興味深い内容が多く、
自分でサーバーを運用しなくてもetke.ccのような有料ホスティングを利用できる
私はMatrix/Elementがとても好きだ
FOSDEM devroom向けのスペースを複数運営しているが
ビデオ通話まで完璧に動作した
ただ、もっと多くの機能が追加されてほしい