要約

  • RFC 6973は、データ、観測者、相関、保存、利用者の参加、セキュリティー、設計上の交換条件を問う。答えは議論の土台であって万能の採点ではない。
  • プロトコルが別のシステムや外部データと結合し、具体的なUI、既定値、ログ、運用に実装されると、プライバシー特性は変わり得る。
  • 信頼できる主張には、版を持つ脅威モデルと配備証拠が要る。誰が何を見られるか、何を結合できるか、データがいつまで残るか、実際の既定値は何か、残余リスクを誰が引き受けるかを残すべきだ。

終了ボタンのない質問票

RFC 6973は2013年7月、Internet Architecture BoardのInformational RFCとして公表された。Cooperは筆頭に記載され、Marit Hansen、Jon Peterson、Hannes Tschofenig、Rhys Smith、John Morris、Bernard Abobaが共著者である。個人が権威を与えた文書でも、Internet Standards Trackの仕様でもない。共同で形成された分析方法を恒久記録にしたものだ。

冒頭から、単純なラベルに向かない前提を受け入れている。プライバシーの理解は、人、学問、法域によって大きく異なる。そこで世界共通の法的定義を宣言せず、技術選択に即した問いを示す。考慮事項を独立の節にするか、セキュリティーの節に含めるか、本文全体に置くかも、文書の内容次第である。

これは緩さではない。質問票を埋めれば二値の判定が出る、という偽装を避ける設計だ。レビュー担当者は、見落とした仲介者、長寿命の識別子、保護の弱い既定値を問い直せる。回答は十分性を議論する根拠になるが、設計に永続的な「プライベート」という属性を付与しない。

出版後も境界は動く

インターネットプロトコルは再利用と組み合わせを前提にする。単独では無害な項目が、アカウント、位置履歴、別プロトコル、運用ログと結びつけば識別材料になる。実装の後に新しい構成が生まれ、当初の設計者とは別の人々が展開することも普通だ。

RFCは結果をシステム全体に置く。プロトコルの組み合わせ、製品、実装、UI、既定設定、セキュリティー手順、運用が関わる。仕様は構文を制約し、動作を推奨できる。しかし仲介者の保存期間、分析基盤のデータ結合、選択肢の分かりやすさ、運用者が選ぶモードまでは支配しにくい。

その限界は分析を省く理由ではなく、範囲を明示する理由である。想定できる外部連携は検討しつつ、未来の全用途を予言したふりをしない。何を対象にし、何を仮定し、何を実装者と運用者に残したかが分かるとき、審査は検証可能な証拠になる。

機密性だけでは説明できない

RFC 6973は、金銭、評判、平穏、自律、身体的安全への害を挙げる。さらに監視、保存データの侵害、誤帰属、相関、識別、二次利用、開示、排除、侵入を区別する。

相関は、実名を知らない段階でも活動を束ねられる。識別は、その履歴と外部情報を後で結んで生じる場合がある。仮名は名前を隠しても、固定されれば追跡軸になる。暗号化は本文を守っても、長さ、時刻、端点、長寿命トークンの模様を消すとは限らない。同意は期待を変え得るが、複製済みデータも二次利用の技術的可能性も消さない。

観測者は特性の一部である。匿名集合は特定の観測者の知識に依存し、時間とともに縮み得る。観測者、補助データ、期間を示さない「匿名」は未完成だ。「非リンク性」「最小化」「プライバシー保護」も同じである。

三つの緩和策は別の場所で決まる

データ最小化は、収集、利用、開示、保存、識別可能性、機微性、アクセスを目的に必要な範囲へ絞る。プロトコル設計者は項目を削り、識別子を短命・交換可能にできる。一方、受け取った記録の再利用や保存は、運用者への勧告にとどまることが多い。

利用者参加は、受信者ごとの共有、中間者への露出、選好表明、制御の理解可能性を問う。プロトコルに入る仕組みもあれば、UI、契約、運用に残る仕組みもある。選好を伝送できることは、既定画面が明確であることや、相手が従うことの証明ではない。

セキュリティーは盗聴、保存データ侵害、侵入、誤帰属などを緩和する。それでも安全な通信路の両端は平文を読み、過剰に保存できる。強い認証は成り済ましを防ぐ一方、活動を持続的に結びやすくすることもある。何を緩和し、どのデータ関係が残るかを分けて評価する必要がある。

質問票が残すのは判断の来歴

第7節は、識別子とその他の情報を棚卸しし、受信者、中間者、支援主体ごとの可視性を問う。要素の順序がフィンガープリントになるか、識別子がいつまで続くか、外部情報と相関できるか、保存はなぜ必要かを確かめる。

次に利用者制御とセキュリティーへ進む。相手ごとに情報を変えられるか、中間者への共有を抑えられるか、選好を表せるか、何をプロトコル外に頼るか。トラフィック分析は何を漏らし、保存データや帰属はどう守られるか。

最後に、既定値に埋め込まれた政策を表へ出す。初期モードがデータ量、識別可能性、持続性を最小にしないなら理由を書く。プライバシーと使いやすさ、効率、実装可能性の交換条件も明示する。方法は唯一解を選ばず、誰がどの仮定で何を受け入れたかを記録する。

大規模監視は結合点を主戦場にした

RFC 7258は後に、大規模監視を可能な限り緩和すべき技術的攻撃と位置づけた。緩和は完全阻止ではなく、費用を上げ、発覚しやすくし、効果を弱めることも含む。管理、悪用対策、透明性に必要な観測もあり、IETFが実装、展開、全レイヤー、非技術的対応を支配しないことも認める。

RFC 7624は、複数プロトコル、セッション、保存場所から内容とメタデータを集めて相関する観測者へモデルを広げた。一つのプロトコル内で正しい約束が、接続点で壊れる。だから構成のレビューは早期に必要で、文書審査は実装と運用の証拠につながっていなければならない。

RFC 6973の制度的な強さは認定印ではなく、根拠のない認定を拒む共通語彙にある。脅威モデル、データフロー、観測者表、既定値、保存限界、未解決リスクを示せば、監査者は現実のシステムを検証できる。

出典