Summary
- エージェント探索では、能力、地域、信頼要件、時刻、条件の絞り直しが組織の目的を選択前に明かしうる。本文を暗号化しても、周辺情報まで消えるわけではない。
draft-iannone-dawn-privacy-considerations-00は監視、保存データ、相関、識別の危険を整理し始めたが、DNSとの比較、プライバシーと監査可能性、RFC 6973の質問票、複数の脅威がなおTBDの個人提出Internet-Draftである。- Daniel Kadeは、照会粒度、最小候補集合、リンク可能期間、役割分離、ブートストラップ経路、結果の閲覧範囲、保存期間を一体で扱う「選択開示予算」を提案する。これは編集上の提言であり、DAWNやIETFの要件ではない。
最初の通信より先に始まる開示
探索は、意図と実行をつなぐ無害な矢印として描かれがちだ。依頼者が要件を持ち、ディレクトリーに候補を尋ね、返答を比較し、一つを選ぶ。認証、権限付与、実作業はその後に来るため、探索は単なる配管に見える。
DAWNの用語案を読むと、その矢印が運ぶ情報量はずっと大きい。発見される対象はエージェントだけでなく、ワークロードや名前付き資源でもよい。公開される属性は機能、プロトコル、運営主体、場所、法域、信頼指標を含みうる。事前の関係がなくてもソフトウェアが多数の候補を機械的に絞れることが相互運用の価値である。同時に、探索要求は依頼者の方針を圧縮した文書になる。
「翻訳」だけなら広い。そこへ言語対、医療データの取扱条件、特定の証明方式、欧州の法域、遅延上限、即時利用可能性を足すと、特定の患者対応業務まで推測できるかもしれない。遅延条件を外して再照会し、次に法域を変えれば、どの制約が交渉可能かも分かる。実際にどのエージェントを選んだかを知らなくても、検索の軌跡だけで目的に近づける。
DAWNの要求事項草案は、選択の仕組みと方針を範囲外としている。特定プロトコルを選ばない要求文書としては妥当な境界だ。しかし、選択方針が観測不能になるわけではない。探索サービスが、試された属性、緩和された順序、返した候補、問い合わせ時刻を見れば、仕様が定義しない選択方針を逆算できる。
暗号化は内容を隠すが、探索の形を消さない
2026年5月22日付の draft-iannone-dawn-privacy-considerations-00 は、この問題に正面から名前を付ける。照会者と能力の組合せ、組織の関心、作業負荷、運用上の振る舞いが探索基盤に見える可能性を指摘する。保存された照会履歴は業務の型を明かし、繰り返し照会は相関を可能にし、組織名、所有者、運営者、能力メタデータは識別につながりうる。
ただし、この文書を完成したIETF方針として扱ってはならない。これはRFC系列も担当Area DirectorもIESGテレチャットも持たない進行中の個人提出草案である。侵入、誤帰属、二次利用、開示、排除は未記入で、DNSとの比較、プライバシー対監査可能性、RFC 6973質問票、DAWN固有の緩和策、Security Considerationsも将来作業として残る。重要なのは結論ではなく、設計がまだ結論を必要としている箇所を明示した点だ。
本文を暗号化すれば第三者に意味が読めなくなる場合はある。しかしRFC 7258が示すように、通信内容だけでなく外形や相関の収集も監視になりうる。接続先、メッセージ量、時刻、反復、失敗、応答集合の大きさは、暗号化の外側に残りやすい。探索のプライバシーは「TLSを使ったか」ではなく、「誰がどの断片をどれだけ長く結合できるか」で評価すべきである。
RFC 9458のOblivious HTTPもよい比較になる。中継は依頼者を知るが平文要求を知らず、ゲートウェイは要求を知るが依頼者を直接知らない。だがメッセージ長、時刻、鍵識別子、接続の再利用、差別的応答は相関の手掛かりになり、匿名集合が小さければ役割分離の効用は薄れる。非共謀の仮定も必要だ。役割を分けた図だけでは、実運用上のプライバシーを証明できない。
候補集合そのものが回答以上のことを語る
照会本文だけを守っても、結果が一件なら、その一件が要求の意味を代弁する。候補集合が十分に大きく、多様であることは、可用性だけでなく照会者を守る性質になる。逆に、非常に細かい属性を許し、該当数を即座に返す仕組みは、属性データベースに対する存在確認オラクルとして使える。
RFC 9156のOblivious DoHは、問い合わせの粒度をどう小さくし、観測者へ渡す情報を減らすかという実例を与える。だが探索では単一名の解決よりも属性の組合せが重要になる。粗い候補群から段階的に絞る設計なら、一回の問い合わせへすべての意図を詰め込まずに済む。一方で段階をまたいで同じ識別子や同じ接続を使えば、分割した条件が再結合される。粒度とリンク可能性は別々に設定できない。
RFC 9540のOblivious HTTP鍵設定も、保護された要求より前のブートストラップを忘れてはいけないと教える。鍵取得、設定URL、リダイレクト、固有のネットワーク経路が、どの探索サービスを使おうとしているかを先に明かすことがある。トンネルの内部だけを監査しても、入口までの足跡を見落とせば評価は不完全だ。
さらに、結果の閲覧者を一種類と考えるべきではない。公開結果、認可された利用者だけの結果、依頼者に合わせた結果は、異なる漏えい面を持つ。閲覧制限は提供者の機微情報を守れるが、認証された依頼者と条件を強く結び付ける。個別化は有用性を高めるが、応答差分から依頼者分類や内部ルールが見える。守る対象を変えるだけで、漏えいが消えるとは限らない。
「プライバシーか監査か」という二択を避ける
草案に残る「Privacy vs Auditability」という見出しは、今後の設計で最も重要な分岐の一つだ。運用者は不正照会、スクレイピング、品質劣化を調べたい。規制や契約は説明可能性を要求するかもしれない。そのために全照会、完全な候補一覧、永続識別子を中央ログへ保存すれば、監査基盤そのものが意図の履歴書になる。
反対に、ログを全廃すれば、差別的な結果、不正な除外、障害、利用者への被害を立証しにくい。必要なのは二択ではなく、問いごとに証拠を限定する設計である。誰が、何の目的で、どの解像度の記録へ、いつまでアクセスできるかを決める。生の探索語や候補を保存しなくても、候補数の帯、失敗率、遅延分布、異常な絞り込み頻度、方針版、例外承認の期限を短期間の集計値として保持できる。
RFC 9576のPrivacy Passアーキテクチャは、発行、証明、償還の文脈を分け、不要な結合を避ける発想を示す。RFC 9614のプライバシーパスも、誰が接続したかと何へ接続したかを別の主体へ分配する。ただし、どちらも万能ではない。参加者が共謀する、集合が小さい、時刻が一致する、長期識別子が残るなら、分離された断片は再び一つになる。監査設計も同じく、分離を宣言するだけでなく、結合条件と保存時間を検証しなければならない。
選択開示予算
Daniel Kadeが提案するのは、中央集権的な全照会台帳ではなく「選択開示予算」である。これは、探索が一回または一連の照会を通じて、依頼者の選択方針をどこまで外部へ明かしてよいかを事前に定め、運用中に測り、例外を期限付きで扱うための統治枠組みだ。
第一に、照会で許される属性の最大粒度を決める。希少な属性の組合せは、それぞれが無害でも全体として識別子になる。初期段階では広い能力群や法域帯を使い、必要な場合だけ次段階へ進む。第二に、結果集合の最低水準と下回った場合の動作を決める。一件を返す代わりに、条件を粗くする、応答を遅延させる、または「十分な集合がない」とだけ示す選択肢がある。
第三に、リンク可能期間を明記する。同じ依頼者の連続照会を何分、何時間、何日ひも付けられるのか。バッチ処理、時間の粗粒度化、識別子のローテーション、必要に応じたパディングは、制度上の上限と組み合わせて初めて意味を持つ。第四に、役割ごとの可視性表を作る。依頼者、中継、索引、提供者、監査者が、照会属性、身元、候補、時刻、結果のどれを見られるのかを列挙する。
第五に、非共謀の仮定とブートストラップ経路を記録する。別会社に見えても共通のクラウド、ログ集約、分析基盤を共有していれば、分離は弱い。鍵や設定の取得経路も可視性表に含める。第六に、結果の公開範囲、保存期間、削除と訂正、例外を承認する主体、例外の期限と再審査を決める。
この予算に生の照会、資格情報、タスク本文、個人データ、独自の重み、全候補の身元を集めるべきではない。短期のローカル計数、粗い分布、合成照会、独立した設定検査で、かなりの統治目的を満たせる。必要以上の証拠を持たないこと自体が統制になる。
いま断定できないこと
DAWNについて、導入済み実装、採用規模、性能、実際のプライバシー事故を示す資料は、ここで参照した文書にはない。PIRは可能な構成要素として言及されるが、採用済み方式でも大規模運用で実証済みの解でもない。特定の法令適合や責任の所在も、これらの技術文書から結論できない。
したがって、この記事の提案をIETFの合意、実装要件、法的義務として読むべきではない。現時点で確かなのは、探索の価値が属性を機械的に比較できることにあり、その同じ属性と比較順序が意図を表現することだ。仕様が若い今なら、漏えいを後付けの暗号機能に押し込めず、結果集合、時間、役割、保存、例外という運用面まで設計対象にできる。
選択前だから安全なのではない。選択前こそ、組織が何をしようとしているかが、まだ広い観測面へ投影される。探索を意思決定の外側に置く統治は、最初の決定を記録し損なう。
Sources
- https://heng.lu/the-policy-mirror/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
- https://datatracker.ietf.org/doc/html/draft-iannone-dawn-privacy-considerations-00
- https://datatracker.ietf.org/doc/draft-iannone-dawn-privacy-considerations/
- https://datatracker.ietf.org/doc/draft-iannone-dawn-privacy-considerations/history/
- https://datatracker.ietf.org/doc/html/draft-akhavain-moussa-dawn-problem-statement-02
- https://datatracker.ietf.org/doc/html/draft-king-dawn-requirements-01
- https://datatracker.ietf.org/doc/html/draft-farrel-dawn-terminology-01
- https://www.rfc-editor.org/rfc/rfc6973.html
- https://www.rfc-editor.org/rfc/rfc7258.html
- https://www.rfc-editor.org/rfc/rfc9156.html
- https://www.rfc-editor.org/rfc/rfc9230.html
- https://www.rfc-editor.org/rfc/rfc9458.html
- https://www.rfc-editor.org/rfc/rfc9540.html
- https://www.rfc-editor.org/rfc/rfc9576.html
- https://www.rfc-editor.org/rfc/rfc9614.html
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
