Summary

  • MIMIプロトコル草案、第07版は2026年11月2日に更新された作業部会のInternet-Draftだ。第5.10節は、メッセージ外に置く暗号化済み添付と、ExternalPartが運ぶHTTPS取得先を扱う。
  • 直接ダウンロードではファイル保管先に利用者のIPアドレスと取得時刻が見える。hub代理ならその住所は隠れるが、受信側事業者はURLを自社の利用者と会話室に結び付けられる。
  • Oblivious HTTPは中継とゲートウェイでさらに視野を分ける。草案はhubにゲートウェイを義務付け、ほかの事業者に中継を勧める。この場面で受信側事業者がすべての保存先ドメインを直接知る必要を減らす。

三つの通信サービスをまたぐグループ会話を考える。ある人が暗号化された写真を送り、メッセージに取得URLを載せる。受信者が画像を開く。保存中の写真は暗号化されたままだが、取得という行為は時刻、宛先、要求経路を作る。その出来事と受信者や会話室を誰が結び付けられるかは、選ばれた経路で変わる。ファイルの錠前は交通整理をしてくれない。

RFC 9420のMLSはグループメッセージを保護する。MIMI草案は事業者間の経路を加え、添付を別の暗号化オブジェクトとして扱う。会話室ポリシー草案のasset_policyは、保存先として許すドメインを指定する。この設定は見た目の問題ではない。どの会社が取得要求を受け、最初のアクセス記録を持つかを決める。

直通なら保管先に読者が見える

第一の経路は利用者の端末から保管先への直接取得だ。草案によれば、保管先はクライアントのIPアドレスと時刻を知る。同じ添付への複数の要求を見れば、利用者のオンライン時刻や同じ会話室にいる可能性を推測できる。草案は、とりわけ別事業者の保管先に対する直通をNOT RECOMMENDEDとする。内容の暗号化が働いていても、取得の動きが読者を語る。

第二の経路では、受信側事業者がhubへGET /proxyDownload/{downloadUrl}を送り、hubが保管先へ取得を頼む。保管先には受信者の住所ではなくhubが見える。hubには要求した事業者とURLが見えるが、その要求に特定の利用者や会話室は直接書かれない。一回の要求から保管先とhubが知る範囲は確かに狭まる。hubは対象ホストが相手事業者に設定された添付用ドメインであることも確かめなければならない。これを省けば便利な代理が無制限の公開プロキシになってしまう。草案はhubに代理取得の実装を義務付ける。

受信側事業者には別の視界がある。利用者を扱い、求められたURLも知る。草案はURLと利用者を対応させ、どの会話室に現れた添付かを推測できると述べる。会話室のメッセージ到着時刻と外向きの代理要求時刻も照合できる。事業者やhubのキャッシュは、上流取得をまとめて時間の対応を曖昧にし得る。代理取得は保管先への露出を減らすが、受信側事業者の照合能力までは消さない。

OHTTPは知る人を入れ替える

第三の経路では、利用者の要求をOHTTPで包む。受信側事業者の中継が保護された要求をhubのゲートウェイへ送り、ゲートウェイが保管先へアクセスする。RFC 9458では中継は利用者の接続を見て対象の要求を読まず、ゲートウェイは対象を見て元の利用者接続を直接受けない。役割が分かれている場合の仕組みだ。MIMIはhubにゲートウェイを必須とし、ほかの事業者には中継を勧める。ゲートウェイが訪ねられる先は設定済みの相手事業者の保存領域に限る。

草案がこの経路に与える具体的な利点は、受信側事業者が利用者の添付ごとの保存先ドメインを直接知らずに済むことだ。ゲートウェイは取得先を知る。受信側事業者は自社利用者がいつ中継を使ったかを知る。同じ組織が両側のログを集めれば、分けたはずの視界をまた合わせられる。各役割の運営者、ログの保管期間、結合できる権限を配置図に書き込む必要がある。

公式資料には、実際の導入環境で会話室を推測できた割合は載っていない。既知の添付を三経路で取得し、キャッシュを切り替えて各事業者のログを比べれば検証できる。設計上の結論はすでに見える。暗号化は写真を守る。取得経路は、写真を見に来た人の名簿を誰が持つかを決める。事業者間で私的な添付を約束するなら、その経路を最初に決めるべきだ。

MIMI草案 · RFC 9458 · RFC 9420 · MIMI会話室ポリシー