💍

RFC 6973: インターネット・プロトコルにおけるプライバシーに関する考慮事項

2024/04/23に公開

要旨

本文書は、プロトコル仕様にプライバシーへの考慮事項を盛り込むためのガイダンスを提供する。インターネット・プロトコルの設計者、実装者、そして利用者に、プライバシーに関連する設計上の選択を認識してもらうことを目的としている。本文書は、個々のRFCが特定のプライバシーに関する考慮事項のセクションを必要とするかどうかは、文書の内容に依存することを提案する。

本文書の位置付け

本文書はインターネット標準化過程の仕様書ではない。情報提供を目的として公開する。

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 5741のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc6973 で入手できる。

著作権表示

Copyright (c) 2014 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。

1. はじめに

[RFC3552]は、プロトコル設計者が、プロトコル設計の一部としてセキュリティを考慮する方法と、プロトコル仕様の読者にセキュリティの問題を知らせる方法の両方について、詳細なガイダンスを提供する。本文書は、プロトコル設計においてプライバシーを考慮するための同様のガイドラインを提供することを目的としている。

プライバシーは、多くの分野にまたがる豊かな歴史を持つ複雑な概念である。データに関しては、多くの場合、「個人データ」に適用される概念であり、一般には特定された、または特定可能な個人に関連する情報と定義されている。プライバシー原則やプライバシー設計の枠組みの多くは、長年にわたってさまざまな場で策定されてきた。これらには、個人データの収集と使用に関するプライバシー保護の基本セットである公正な情報慣行(FIP)(例えば、[OECD]で確立された原則に基づくことが多い)や、プライバシー・バイ・デザインの概念が含まれる。これは、システム設計のためのハイレベルのプライバシー・ガイダンス(一例として[PbD]を参照)を提供するものである。本文書で提供するガイダンスは、このような先行研究に触発されたものだが、より具体的で、インターネット・プロトコルを利用する個人のプライバシーに影響を与える可能性のある具体的なエンジニアリング上の選択をプロトコル設計者に指し示すことを目的としている。

⚠️ 公正な情報慣行(FIP)

公正な情報慣行(FIP)とは、データの使用、収集、プライバシーに関する8つの原則から成り、公正な情報慣行原則(FIPPs)とも呼ばれている。1980年に経済協力開発機構(OECD)が発表したもので、多くの国が原則的に合意している。8つの原則:

収集制限の原則: 個人データの収集に制限を設けるべきであるとともに、いかなる個人データも、適法で公正な手段によって、かつ、適宜、データ主体に知らせるか、その同意を得た上で、収集すべきである。
データ内容の原則: 人データは、それが利用される目的に見合うものであるとともに、この目的に必要とされる程度において、正確かつ完全であり、最新のものに維持すべきである。
目的特定の原則: 個人データの収集目的は、データ収集時より前に特定すべきであるとともに、その後の利用については、これらの目的やこれらの目的と矛盾せず、かつ、目的を変更する度に特定されるその他の目的の達成に限定すべきである。
利用制限の原則: 個人データは、以下の場合を除き、 3に従って特定された目的以外の目的のために開示、提供、その他の利用に供すべきではない。
a) データ主体の同意がある場合、または、

b) 法律に基づく場合
安全保護の原則: 個人データは、その紛失や承認されていないアクセス、破壊、利用、変更、開示などの危険から合理的な安全保護措置によって保護しなければならない。
公開の原則: 個人データに関する開発、慣行、方針については全般的な公開方針を策定すべきである。個人データの存在と性質、その主な利用目的、データ管理者の身元と通常の住所を知ることのできる手段を容易に利用できるようにすべきである。
個人参加の原則: 個人には以下の権利を付与すべきである。

a) データ管理者その他の者に、データ管理者が自分に関するデータを持っているかどうか確認すること。
b) 自分に関するデータを、
1. 合理的な期間内に、
2. 費用がかかるとしても、過度にならない費用で、
3. 合理的な方法で、かつ、
4. 自分に分かりやすい形で、自分に伝えること。
c) 上記 a)および b)の要求を拒否する場合にはその理由を知らせること、および、そうした拒否に異義申し立てできること。

d) 自分に関するデータに異義を申し立てること、および、その異議が認められた場合には、そのデータを消去、修正、完全化、変更させること。
責任の原則: データ管理者には、上記の諸原則の実施措置を遵守する責任(アカウンタビリティ)を負わせるべきである。

⚠️ プライバシー・バイ・デザイン

エンジニアリング・プロセス全体にわたってプライバシーを考慮するシステム・エンジニアリングのアプローチを言う。

プライバシーが何を意味するかについては、一般的な意味でも、個人的な意味でも、人によって根本的に異なる概念を持っている[Westin]。さらに、法的概念としてのプライバシーは、司法権によって理解が異なる。本文書で提供されるガイダンスは一般的なものであり、特定の法的枠組みを参照することなく、世界中のどこでも使用されるプロトコルの設計を伝えるために使用することができる。

個々の文書が特定のプライバシーに関する考慮事項のセクションを設ける価値があるかどうかは、文書の内容によって異なる。プライバシーに重点を置いた文書は、別個のセクションを設ける価値がないかもしれない(例えば、「信頼ネットワーク内でのアサートされたアイデンティティのためのセッション開始プロトコル (SIP)のプライベート拡張」[RFC3325])。いくつかの仕様では、プライバシーに関する考慮事項はセキュリティに関する考慮事項の一部であり、セキュリティに関する考慮事項セクションで明示的に説明できる。文書によっては、プライバシーに関する考慮事項についての議論を必要としない(例えば、「オーパス音声コーデックの定義」[RFC6716])。ここで提供されるガイダンスは、プロトコル、アーキテクチャ、運用仕様におけるプライバシーに関する考慮事項を評価し、それらの考慮事項を独立したセクションに文書化するか、セキュリティに関する考慮事項セクション内に文書化するか、文書全体に文書化するかを決定するために使用でき、また使用する必要がある。ここで提供されるガイダンスは、プライバシー分析の思考プロセスを助けることを目的としている。プライバシーに関する考慮事項セクションの書き方について、具体的な指示を与えるものではない。

本文書は以下のように構成されている。セクション2では、ここで提供されるガイダンスが、IETF内およびより大きなインターネット・コミュニティ内でどの程度適用可能かについて説明する。セクション3では、本文書で使用する用語について説明する。セクション4では、どの時点でプライバシーが脅かされるかを理解するために、典型的な通信アーキテクチャをレビューする。セクション5では、インターネット・プロトコルに適用されるプライバシーへの脅威について説明する。セクション6では、これらの脅威の軽減策を概説する。セクション7では、IETF仕様内のプライバシーに関する考慮事項を分析および文書化するためのガイドラインを提供する。セクション8では、ガイダンスのフレームワークの使用を実証するため、IETFプロトコルのプライバシー特性を検証する。

2. プライバシーの範囲とインターネット・プロトコルの影響

インターネット・プロトコルは柔軟に構築されることが多く、異なる設計のコンポーネント間で大きな相互依存性を必要とすることなく、さまざまなアーキテクチャ、コンテキスト、展開シナリオで有用である。プロトコル設計者は設計時に特定のターゲット・アーキテクチャやアーキテクチャ・セットを念頭に置いていることが多いが、実装が存在し、他のプロトコルやコンポーネントと組み合わせて展開され、完全なシステムを形成した後に、アーキテクチャのフレームワークが開発されることも珍しくない。

結果として、プロトコル設計者が設計時に特定のプロトコルのプライバシーへの影響をすべて予測できる範囲は限られる。個々のプロトコルは、それ自体は比較的安全かも知れないし、攻撃のリスクを軽減するために、プロトコル・スタックの下位層(インターネット・プロトコル・セキュリティ、トランスポート層セキュリティなど)でプライバシーやセキュリティ機能を利用するかも知れない。しかし、より大規模なシステムの中で導入されたり、設計時には想定されていなかった方法で使用されたりすると、その使用により新たなプライバシー・リスクを生み出すかも知れない。プロトコルはしばしば、設計時からずっと後に、プロトコルの設計者とは別の人によって実装され、導入されることがよくある。セクション7のガイドラインでは、プロトコル設計者に対し、そのプロトコルがプロトコルの境界の外側に存在するシステムや情報とどのように相互作用することが期待されるかを検討するよう求めているが、考えられるすべての導入シナリオを推測することは求めていない。

さらに、多くの場合、システムのプライバシー特性は、さまざまなプロトコルが組み合わされて製品ソリューションを形成する完全なシステム設計、ユーザ・インタフェースの設計を含む実装、およびデフォルトのプライバシー設定や導入を行う企業のセキュリティ・プロセスを含む運用配備の慣行に依存する。これらの詳細は、特定の実例に固有のものであり、一般にIETFで行われた作業の範囲外である。ここで提供されるガイダンスは、これらの詳細について選択する際に役立つかも知れないが、その主な目的は、プロトコルの設計、実装、運用を支援することである。

データの収集と使用の透明性は、─ しばしば、ユーザ・インタフェースの設計を通じて実現される ─ システムのプライバシーへの影響を決定する重要な要素として、(正しいか間違っているかは別として)通常、信頼されている。ほとんどのIETFの活動は、ユーザ・インタフェースやユーザ向け通信の標準化には関与していないが、場合によっては、期待されるユーザ・インタラクションを理解することがプロトコル設計にとって重要になることがある。予期しないユーザの行動は、セキュリティやプライバシーに悪影響を与えるかも知れない。

まとめると、プライバシーの問題は、プロトコルの開発に関連するものであっても、ここで説明する技術的な指針を超えている。例として、任意のデータの交換を可能にするために設計されたHTTP[RFC2616]を考えてみる。HTTPの使用に対するプライバシーに関する考慮事項の完全な分析は、どのような種類のデータが交換され、そのデータがどのように保存され、どのように処理されるかを含むかも知れない。したがって、個人の静的なウェブページに対する分析は、健康記録を交換するためのHTTPの使用とは異なるだろう。HTTP拡張(Web Distributed Authoring and Versioning (WebDAV) [RFC4918]など)に取り組むプロトコル設計者は、考えられるすべての利用シナリオから派生するプライバシー・リスクを記述することは期待されていない。むしろ、拡張に固有のプライバシー特性と、設計時に期待され、想定される拡張の特定の利用方法を記述することが期待されている。

3. 用語

このセクションでは、必要に応じて既存の定義を参照しながら、本文書で使用される基本的な用語を定義する。[RFC4949]と同様に、各項目の前には自動検索のためのドル記号($)と空白を置く。本文書では、「プライバシー」という用語を簡単に定義しようとするものではないことに留意すること。むしろ、プライバシーはこの文書に含まれるものの総和である。したがって、[RFC3552]で採用されているアプローチに従う。いくつかの異なる簡単な定義の例は[RFC4949]で提供されている。

3.1. エンティティ

これらの用語のいくつかは、セクション4でさらに詳しく説明する。

$ 攻撃者(Attacker): 1つ以上のプライバシー保護の目標に反して活動するエンティティ。オブザーバーとは異なり、攻撃者の行動は許可されていない。

$ 盗聴者(Eavesdropper): 攻撃者の一種で、イニシエータの通信を、イニシエータの知識や許可なしに、受動的に観察する。[RFC4949]を参照のこと。

$ イネーブラー(Enabler): 通信パスに直接入ることなく、イニシエータと受信者間の通信を促進するプロトコル・エンティティ。

$ 個人(Individual): 人間。

$ イニシエータ(Initiator): 受信者との通信を開始するプロトコル・エンティティ。

$ 仲介者(Intermediary): イニシエータと受信者の間に位置し、イニシエータと受信者が通信するために必要なプロトコル・エンティティ。盗聴者とは異なり、仲介者は通信アーキテクチャの一部であり、したがって、少なくとも暗黙のうちに許可されている。例えば、SIP[RFC3261]のプロキシは、SIPアーキテクチャの仲介者である。

$ オブザーバー (Observer): 通信を監視し、通信から情報を収集することができるエンティティ。状況によってはプライバシーの脅威となる可能性がある。本文書で定義するように、イニシエータ、受信者、仲介者、イネーブラーはすべてオブザーバーになり得る。オブザーバーは、少なくとも暗黙のうちに権限を与えられているという点で、盗聴者とは区別される。

$ 受信者 (Recipient): イニシエータから通信を受信するプロトコル・エンティティ。

3.2. データと分析

$ 攻撃 (Attack): エンティティが個人のプライバシーを侵害しようとする意図的な行為。 [RFC4949]を参照のこと。

$ 相関性 (Correlation): 個人に関連する、または組み合わせるとその特徴が得られるさまざまな情報の組み合わせ。

$ フィンガープリント (Fingerprint): デバイスまたはアプリケーションのインスタンスを識別する一連の情報要素。

$ フィンガープリンティング (Fingerprinting): オブザーバーまたは攻撃者が、そのオブザーバーまたは攻撃者に伝達された複数の情報要素に基づいて、デバイスまたはアプリケーション・インスタンスを(十分に高い確率で)ユニークに識別するプロセス。[EFF]を参照のこと。

$ 関心のある項目(IOI, Item of Interest): オブザーバーまたは攻撃者が関心を持つ可能性のあるあらゆるデータ項目。これには、属性、識別子、アイデンティティ(身元)、通信内容、通信のやり取りが行われたという事実が含まれる。

$ 個人データ (Personal Data): 直接的または間接的に個人を特定できる情報。

$ (プロトコル) やり取り (Interaction): 特定のプロトコル内の通信の単位。一つのやり取りは、プロトコルによって、イニシエータと受信者の間の一つのメッセージで構成されることもあれば、複数メッセージで構成されることもある。

$ トラフィック分析 (Traffic Analysis): たとえ、フローが暗号化されていたとしても、トラフィック・フロー(存在、不在、量、方向、タイミング、パケットサイズ、パケット構成、および/または頻度)の観察から情報の推測すること。[RFC4949]を参照のこと。

$ 検出不能性 (Undetectability): オブザーバーまたは攻撃者が、関心のある項目が存在するかどうかを十分に区別できないこと。

$ リンク不可能性 (Unlinkability): 特定の情報集合の中で、オブザーバーまたは攻撃者が、関心のある2つの項目が関連しているかどうかを(オブザーバーまたは攻撃者にとって有用な十分高い確率で)区別できないこと。

3.3. 識別可能性

$ 匿名性 (Anonymity): 匿名であることの状態。

$ 匿名集合 (Anonymity Set): 同じ属性を持つ個人の集合で、特定の攻撃者やオブザーバーの視点から見た場合、互いに区別がつかないようにする。

$ 匿名 (Anonymous): オブザーバーや攻撃者が、他の個体の集合(匿名集合)の中でその個人を識別できない個人の状態。

$ 属性 (Attribute): 個人の特性。

$ 識別可能性 (Identifiability): 個人を識別できる程度。

$ 識別可能 (Identifiable): 個人の身元がオブザーバーや攻撃者に知られる可能性がある特性。

$ 識別 (Identification): 個人の身元を推測するため、または何らかの状況で個人の身元を推測できるようにするために、特定の個人に情報を結び付けること。

$ 識別済み (Identified): 個人の身元が判明している状態。

$ 識別子 (Identifier): 何らかの文脈において、プロトコル・エンティティまたは個人の特定の身元をユニークに参照するデータ・オブジェクト。[RFC4949]を参照のこと。識別子は、正式名、個人名、ニックネームなどの自然名に基づくこともできるし、人工名 (x9z32vb など)に基づくこともできる。ただし、識別子は定義上、使用する文脈内でユニークだが、自然名はユニークではないことが多い。

$ アイデンティティ (Identity): 名前を含む個人の属性のサブセットで、特定の状況の中で個人を識別するもの。通常、個人はさまざまな状況で使用するために複数のアイデンティティを持つ。

$ アイデンティティ機密性 (Identity Confidentiality): 受信者だけが、他の個人の中でその個人を十分に識別できる個人の特性。これは、認証プロトコルの望ましい特性となる可能性がある。

$ アイデンティティ・プロバイダ (Identity Provider): 個人に関連付けられたアイデンティティを確立し、維持し、保護し、保証する責任を負うエンティティ(通常は組織)。

$ 正式名 (Official Name): 何らかの公式の場で登録されている個人の名前(例えば、出生証明書に記載されている名前)。正式名はユニークではないことが多い。

$ 個人名 (Personal Name): 個人の自然な名前。個人名はユニークではないことが多く、姓と名の組み合わせで構成されることが多い。個人名は、正式名を含め、いつでも、また生涯にわたって複数の個人名を持つ可能性がある。技術的な観点から、特定の個人に関する言及が、その個人の個人名であるのか、または個人名に基づいているのかを常に判断することはできない(「仮名」を参照)。

$ 仮名 (Pseudonym): ある個人が、ある文脈において名乗る名前で、その文脈において他人に知られている個人の個人名とは無関係なもので、その個人の他の名前に関連付けられた個人の身元を明らかにしないことを目的としている。仮名は多くの場合、ユニークではない。

$ 仮名の使用 (Pseudonymity): 仮名である状態。

$ 匿名 (Pseudonymous): 個人が仮名によって識別される個人の特性。

$ 本名 (Real Name): 個人名と正式名を参照のこと。

$ リライング・パーティー (Relying Party): 個人にサービスを提供するために、アイデンティティ・プロバイダからの個人のアイデンティティのアサーションに依存するエンティティ。事実上、リライング・パーティーはアイデンティティ管理の側面をアイデンティティ・プロバイダに委任する。このような委任には、プロトコルの交換、信頼、およびリライング・パーティーとアイデンティティ・プロバイダの間で交換される情報のセマンティクスの共通理解が必要である。

4. 通信モデル

プライバシー侵害という意味での攻撃を理解するには、全体的な通信アーキテクチャと、その中でのさまざまな関係者の役割を考えることが役立つ。ある受信者との通信を開始するプロトコル・エンティティ、つまり「イニシエータ」を考えてみる。プライバシーの分析は、イニシエータが個人(または異なる時点で異なる個人)に代わって行動するユースケースを持つプロトコルに最も関連する。プライバシーが脅かされる可能性があるのは、この個人である(ただし、イニシエータが別の個人に関する情報を伝達する場合もあり、その場合は両者のプライバシー上の利益が関係する)。

通信は、イニシエータと受信者の間で直接行われる場合もあれば、両者が通信に必要なアプリケーション層の仲介者(プロキシ、キャッシュ、リレーなど)が関与するかも知れない。時には、この仲介者は通信の全期間にわたって通信パスに留まる。場合によっては、インバウンド通信またはアウトバウンド通信のいずれかで、通信の確立のためにのみ使用される。一部の例では、一連の仲介者を経由することもある。下位層では、パケット転送に関与する追加のエンティティがプライバシー保護の目標を妨げる可能性がある。

一部の通信タスクは、さまざまなエンティティとの複数のプロトコルのやり取りを必要とする。例えば、HTTPサーバへのリクエストの前に、イニシエータとネットワーク・アクセスのための認証、認可、アカウンティング(AAA)サーバとのやり取り、および名前解決のためのドメインネームシステム(DNS)サーバとのやり取りが行われる場合がある。この場合、HTTPサーバは受信者であり、他のエンティティはイニシエータから受信者への通信のイネーブラーである。同様に、受信者との1回の通信が、イニシエータまたは受信者と他のエンティティの間でさらなるプロトコルのやり取りが生成される可能性があり、エンティティの役割がやり取りのたびに変わるかも知れない。例えば、HTTPリクエストは、認証サーバや他のリソースサーバとのやり取りを引き起こすかも知れず、その場合、受信者がその後のやり取りにおいてイニシエータになる。

したがって、複数の通信フェーズを含むアーキテクチャのプライバシー分析を行う場合、関係するエンティティは、各フェーズにおいて、プライバシーの考慮事項の観点から、異なるあるいは対立する役割を担うかも知れない。アーキテクチャ全体のプライバシーへの影響を理解するためには、各フェーズを個別に分析する必要があるかも知れない。

プロトコルの設計は、受信者、仲介者、イネーブラーが、イニシエータからデータを受信し、処理する権限を与えられていると仮定されるという考え方を前提としていることが多い。[RFC3552]が説明しているように、「プロトコル交換に関与するエンドシステム自体が侵害されていないと仮定する」。しかし、プライバシー分析では、個人データを取得する目的でシステムが侵害されることがよくあるため、この前提を疑う必要がある。

受信者、仲介者、イネーブラーは、一般的には攻撃者とは見なされないかも知れないが、プライバシー関連データを観察、収集、処理、転送することができるため、これらは(状況によっては)すべてプライバシーの脅威をもたらす可能性がある。これらのエンティティは、従来の攻撃者と区別するために、以下では「オブザーバー」としてまとめて説明する。プライバシーの観点から見ると、攻撃者の重要なタイプの1つが盗聴者である。つまり、イニシエータが知らないうちに、あるいは許可なしに、イニシエータの通信を受動的に観察するエンティティである。

次セクションの脅威の説明では、オブザーバーや攻撃者が個人のプライバシーを侵害するためにどのように行動するかを説明する。通信パスの異なるポイントでは、さまざまな種類の攻撃が行われる可能性がある。例えば、オブザーバーは、イニシエータと仲介者の間で監視や識別攻撃を仕掛けたり、代わりにイネーブラーを監視することもできる(例えば、イニシエータからのDNSクエリの監視)。

5. プライバシーの脅威

プライバシーの侵害は、経済的地位、評判、孤独、自律性、安全に対する損害など、さまざまな形で現れる。例えば、なりすましや恐喝の被害者は、結果として経済的損失を被るかも知れない。風評被害は、個人に関する情報の開示が真実か虚偽かにかかわらず、その個人が汚名、恥辱、または個人の尊厳の喪失を受ける場合に発生する。個人の生活や活動への侵入や妨害は、その個人が放っておかれる能力を害する可能性がある。個人やその活動が監視されたり、攻撃にされされたり、暴露される危険性がある場合、その人は自己表現したり、他者と交流したり、一般的に自由に生活を営むことが阻害される可能性がある。また、監視されたり、自分に関するデータを収集されたりするのは「気味が悪い」という一般的な不安感を抱くこともある。このような監視がストーカー行為や暴力を目的としている場合(例えば、家庭内虐待保護施設との間の通信の監視など)、個人を身体的危険にさらす可能性がある。

このセクションでは、一般的なプライバシーの脅威([Solove]と[CoE]から自由に引用した)を列挙し、それぞれの脅威がどのように個人にプライバシーの侵害をもたらすかを示し、これらの脅威がインターネット上でどのように存在し得るのかの例を示す。この脅威モデリングは、セキュリティ脅威分析からインスピレーションを受けている。これは、インターネット・プロトコルやシステムにおけるプライバシー・リスクの評価に完全に適合しているわけではないが、これより優れた方法論はこれまで開発されていない。

プライバシーの脅威の中には、日常的なセキュリティ分析の問題として、インターネット・プロトコルですでに考慮されているものもある。その他は、既存のセキュリティ上の考慮事項では通常扱われない、より純粋なプライバシーの脅威である。ここで説明する脅威は、セキュリティ上の脅威と考えられるものと、主にプライバシーの脅威であるものに分けられる。

以下に述べる慣行に対する個人の認識と同意は、プライバシーを脅かす範囲に対する個人の認識と懸念を変える可能性があることに留意すること。例えば、ある個人が自分自身の活動の監視を許可した場合、その個人はそれに関連する危害を軽減するための行動を取ることができるかも知れないし、危害のリスクは許容できると考えるかも知れない。

5.1. セキュリティとプライバシーの複合的な脅威

5.1.1. 監視(Surveillance)

監視とは、個人の通信や活動を観察または監視することである。個人に対する監視の影響は、不安や不快感から、抑制や自己検閲といった行動の変化、さらには個人に対する暴力の実行まで多岐にわたる。監視が個人のプライバシーに影響を与えるには、その個人が監視に気づく必要はない。監視の可能性は、個人の自主性を損なうのに十分かも知れない。

監視は、監視対象の個人が特定できない場合や、通信が暗号化されている場合であっても、プライバシーに影響を与える可能性がある。例えば、トラフィック分析を行う監視者や盗聴者は、たとえ監視する通信が暗号化されていたとしても、通信者が特定できない場合でも、どのような種類のトラフィックが存在するか(例えば、リアルタイム通信や大量のファイル転送など)、どのプロトコルを使用しているかを特定できる可能性がある。この種の監視は、関係する個人をさらなる調査や取り締まり活動の標的となることで、悪影響を及ぼす可能性がある。また、専用の傍受ポイントへのリダイレクトやプロトコル固有のサービス拒否など、そのプロトコルに特有の攻撃を可能にする可能性もある。予測可能なパケットサイズやタイミングを使用したり、パケット内の予測可能なオフセットに固定トークンを含むプロトコルは、この種の監視が容易になる。

監視は、通信パスに沿ったどの地点でも、オブザーバや盗聴者によって行われる可能性がある。([RFC3552]のセクション3に記載されている)機密保護は、通信内容の監視を止めるために必要である。トラフィック分析や他の通信パターンの監視を防ぐには、[Tor]のような他の対策が必要になるかも知れない。

5.1.2. 保存データの情報漏洩

不正または不適切なアクセスから保存データを保護するための適切な措置を講じないエンドシステムは、個人を経済的、評判的、または物理的な損害にさらす可能性がある。

保存データの情報漏洩に対する保護は、一般的にIETFプロトコルの範囲外である。しかしながら、多くの一般的なプロトコル機能、例えば、鍵管理、アクセス制御、操作ログなどは、通信のイニシエータに関するデータの保存が必要である。イニシエータやその通信に関する情報をエンドシステムによって保存または記録することを要求または推奨する場合(例えば、RFC 6302[RFC6302]を参照)、その情報が情報漏洩する可能性を認識し、その可能性をデータ保存の利点と比較検討することが重要である。データを保存する受信者、仲介者、イネーブラーは、情報漏洩に対して脆弱である可能性がある。(保存データの情報漏洩は、セクション5.2.4で説明する意図的な開示とは異なることに留意する。)

5.1.3. 侵入

侵入とは、人の生活や活動を妨害したり、邪魔したりする侵略的行為のことである。侵入は、そっとしておいて欲しいという個人の欲求を妨げたり、時間や注意力を奪ったり、活動を妨害したりする。この脅威は、個人の通信への直接的な侵入よりも、個人の生活への侵入に焦点を当てている。後者については、セクション 5.1.1で取り上げている。

迷惑メッセージとサービス拒否攻撃は、インターネット上で最も一般的なタイプの侵入である。侵入は、望まないトラフィックをイニシエータに送信できる攻撃者であれば、誰でも行うことができる。

5.1.4. 誤った帰属(Misattribution)

誤った帰属は、ある個人に関連するデータまたは通信が別の個人に帰属する場合に発生する。誤った帰属は、誤認された個人の評判、経済的、またはその他の悪影響をもたらす可能性がある。

プロトコルの文脈における誤った帰属は、アイデンティティまたは認証の不十分または安全ではない形態を使用した結果として発生し、なりすましに関連する場合もある。例えば、[RFC6269]が指摘しているように、不正行為の軽減は送信元IPアドレスに基づいて行われることが多く、不正行為がこれらのアドレスから発信されていると判断された場合、個々のIPアドレスからの接続が阻止されるか、一時的にブラックリストに登録されることがある。しかし、1つのIPアドレスが複数の個人によって共有されている場合、たとえそのアドレスが不正利用に関与していなかったとしても、そのアドレスを共有するすべての個人がそのようなペナルティを受ける可能性がある。この脅威は、適切な形式の認証(理想的には暗号化特性を持つ)を備えたアイデンティティ管理メカニズムを使用することで軽減することができる。これにより、行動を個人にユニークに帰属させ、誤検知を発生させることなく説明責任の根拠を提供できる。

5.2. プライバシーに特化した脅威

5.2.1. 相関性

相関性とは、個人に関連する、あるいは組み合わせるとその特徴が得られるさまざまな情報の組み合わせのことである。相関性は、他人が自分について知っていることの限界に対する人々の期待を裏切る可能性がある。それは、相関を行う者が個人に対して持つ力だけでなく、相関を行う者の判断能力を増大させ、個人の自主性と評判を脅かすことがある。

相関性は識別と密接に関係している。インターネット・プロトコルを使用すると、個人の活動を時系列に追跡し、組み合わせることを可能にするため、相関が容易になる。スタックのどの層でも、永続的な、または置換頻度の低い識別子を使用することで、相関が容易になる。例えば、イニシエータが複数のやり取りで同じデバイスID、証明書、電子メールアドレスを永続的に使用することで、受信者(およびオブザーバー)は、イニシエータのすべての通信を長期にわたって相関させることができる。

例として、Transport Layer Security (TLS)セッション再開[RFC5246]、またはサーバ側状態を使用しないTLSセッション再開[RFC5077]を考えてみる。RFC 5246[RFC5246]では、サーバはクライアントにServerHelloメッセージ内のsession_idを提供し、後のやり取りのためにmaster_secretをキャッシュする。クライアントがサーバとの新しい接続を開始するとき、クライアントは以前取得したsession_idを ClientHelloメッセージで再利用する。サーバは、同じsession_idと、TLSレコード層セキュリティ・アソシエーションの生成に以前に保存したmaster_secretを使用してセッションを再開することに同意する。RFC 5077[RFC5077]はセッション再開の設計アイデアを借用しているが、サーバはすべての状態情報をキャッシュする代わりに、チケットにカプセル化する。TLSクライアントとTLSサーバ間のプロトコル交換を監視できる攻撃者は、session_idとチケットが平文で交換される場合(これは、最初のハンドシェイク・メッセージで交換されるデータの場合である)、最初の交換とその後再開されるTLSセッションに結び付けることができる。

理論上、イニシエータの通信を受信するオブザーバーや攻撃者は、相関に関与することができる。相関の可能性の程度は、そのエンティティがイニシエーターからどのようなデータを受信し、それ以外にアクセスできるかに依存する。多くの場合、仲介エンティティは、メッセージのルーティングやセキュリティのために少量の情報しか必要としない。理論的には、プロトコルの仕組みは、エンドツーエンドの情報がこれらのエンティティにアクセスできないようにすることができるが、実際には、エンドツーエンドのセキュリティ手順の導入の難しさ、追加のメッセージングや計算のオーバーヘッド、その他のビジネス上または法的な要件によって、エンドツーエンドのセキュリティの仕組みの展開が遅くなったり妨げられたりすることがよくあり、仲介エンティティは、技術的な観点から厳密に必要な以上に、イニシエータのデータにより多く触れることになる。

5.2.2. 識別

識別とは、個人の身元を推測するため、または個人の身元の推測できるようにするために、情報を特定の個人に結びつけることである。状況によっては、個人を特定することは完全に合法だが、別の状況では、匿名または偽名である能力を阻害することによって、個人の活動や表現を阻害する可能性がある。また、識別は、個人が他者(政府など)によってあからさまに管理されたり、他の個人と比ベて差別的に扱うことも容易にする。

多くのプロトコルは、エンティティが主張する人物であることを検証するための何らかの手段が提供されているという考えを伝える機能を提供している。多くの場合、これは暗号化認証によって実現する。さらに、SIPやExtensible Messaging and Presence Protocol (XMPP)で使用されるような多くのプロトコル識別子は、個人を直接識別できる場合がある。プロトコル識別子は、相関によって間接的に識別に寄与することもある。例えば、ユーザを直接認証しないウェブサイトは、そのHTTPヘッダ・ログをユーザを認証する別のサイトのログと照合して、最初のサイトのユーザを識別できるかも知れない。

相関性と同様に、プロトコルの仕組みや他のチャネルを介して利用可能なイニシエータに関する情報によって、どのようなオブザーバーや攻撃者も識別に関与できるかも知れない。

5.2.3. 二次利用

二次利用とは、収集した個人情報を、本人の同意なしに、収集した目的とは異なる目的のために利用することである。二次利用は、人々の期待や願望に反する可能性がある。二次利用の可能性があると、自分の情報が将来どのように利用されるかについて不確実性が生じ、そもそも情報交換を妨げる可能性がある。二次利用には、開示を含むデータのあらゆる利用が含まれる。

二次利用の一例としては、ネットワーク・アクセス・サーバのAccess-Requestを使用してイニシエータの位置を追跡する認証サーバが挙げられる。オブザーバーや攻撃者も、イニシエータのデータを望まない二次利用を行う可能性がある。二次利用からの保護は通常、IETFプロトコルの範囲外である。

5.2.4. 情報開示

情報開示とは、ある個人に関する情報が明らかにされることであり、それは他者がその個人を判断する方法に影響を与える。開示は、共有するデータの機密性に対する個人の期待に反する可能性がある。情報開示の脅威により、人々は風評被害を恐れて、あるいは単に観察されたくないという理由で、特定の活動に参加することを思いとどまるかも知れない。

イニシエータに関するデータを受け取るオブザーバーや攻撃者は、情報開示に関与する可能性がある。システム設計者が、交換される情報が個人に関連することを認識していないため、意図せずに情報開示が起こることもある。プロトコルが情報開示を制限する最も一般的な方法は、アクセス制御の仕組みを提供することである(セクション5.2.5で説明)。さらなる例として、IETF地理位置情報プライバシ・アーキテクチャ[RFC6280]によって提供されており、これは、ユーザが自分の位置情報が意図した受信者以外には公開しないという希望を表明する方法をサポートしている。

5.2.5. 排除

排除とは、他者が持つ自分に関するデータについて個人が知ることを認めず、その取り扱いや使用に参加させないことである。排除は、人々に関する情報を管理するエンティティ側の説明責任を軽減させ、個人情報がどのように収集され、使用されるかをコントロールする個人の能力に関して、脆弱性の感覚を生み出す。

インターネット・プロトコルが排除の強制に関与する最も一般的な方法は、アクセス制御メカニズムである。IETFで開発されたプレゼンス・アーキテクチャは、個人に関する情報のコントロールに、個人が含まれる良い例である。ルール表現言語(例えば、プレゼンス認証ルール[RFC5025])を使用して、プレゼンス・クライアントは、自分のプレゼンス情報が共有される特定の条件を認可することができる。

排除は主に、受信者がデータの収集、処理、使用に関する決定に、イニシエータを関与させることに失敗した場合に問題があると見なされる。盗聴者は、データの収集と処理が秘密裏に行うため、その性質上、排除に関与する。

6. 脅威の軽減

プライバシーは測定と定量化は非常に難しい。特定のプロトコル、システム、またはアーキテクチャが、どの程度プライバシーを「保護」または「強化」するかは、その設計、使用、および潜在的な悪用に関連する多くの要因に依存する。しかし、セクション5で説明した脅威に対する軽減策として、いくつかの広く認識されている分類がある。本セクションでは、(1) データの最小化、(2) ユーザの参加、(3) セキュリティ、の3つのカテゴリの関連軽減策について説明する。このセクションで説明するプライバシー軽減策は、公正な情報慣行のような既存のプライバシー原則に大まかに対応付けることができるが、本文書の対象読者に合わせて調整されている。

6.1. データの最小化

データの最小化とは、タスクの実行に必要な最小限のデータを収集、使用、開示、保存することを指す。交換するデータ量を減らすことで、悪用や漏洩の可能性のあるデータ量を減らすことができる。

データの最小化は、個人データの収集、使用、開示、保持、識別可能性、機密性、アクセスを制限することを含む、さまざまな方法で実現することができる。プロトコル要素によって収集されるデータを必要なものだけに制限すること(収集制限)は、プロトコルの使用に伴うプライバシー・リスクの軽減を助ける最も簡単な方法である。場合によっては、プロトコル設計者は、データの使用や保持に対する制限を推奨できるかも知れないが、プロトコル自体はこれらの特性を制御できないことが多い。

しかし、データの最小化をプロトコル設計に最も直接的に適用するのは、識別可能性の制限である。仮名の使用や識別子をまったく使わないことで、データの識別可能性を減らすことは、個人とその通信とのつながりが弱めるのに役立つ。新しい、またはランダム化された識別子を定期的に作成できるようにすることで、複数のプロトコルのやり取りや通信が同じ個人に関連付けられる可能性を低くすることができる。次のセクションでは、プロトコル設計者が達成しようとする、識別可能性に関連するさまざまな特性を探っていく。

データの最小化は、監視、保存データの漏洩、相関、識別、二次利用、開示といった脅威を軽減する。

6.1.1. 匿名

個人の匿名性を実現するには、その個人と同じ属性を持つように見える個人の集合が存在しなければならない。攻撃者やオブザーバーからは、これらの個人は互いに見分けがつかないようにしなければならない。このような個人の集合は匿名性集合と呼ばれ、この集合のメンバーは時間の経過とともに変化する可能性がある。

匿名性集合の構成は、オブザーバーや攻撃者の知識に依存する。したがって、匿名性は、オブザーバーや攻撃者に対する相対的なものである。イニシエーターは、潜在的なイニシエータの集合(イニシエータ匿名性集合)内でのみ匿名かも知れない。この集合自体は、通信を開始できるすべての個人の部分集合かも知れない。逆に、受信者は、潜在的な受信者の集合、つまり受信者匿名性集合の中でのみ匿名かも知れない。両方の匿名性集合は、バラバラの場合もあれば、重複している場合もあり、同じ場合もある。

例として、RFC 3325(P-Asserted-Identity (PAI))[RFC3325]を考えてみる。これは、Voice over IP (VoIP)の発信者など、個人が信頼する仲介エンティティに対して、SIPのFromヘッダ・フィールドに個人の認証済みおよび検証済みのアイデンティティを入力しないように指示することを可能にするセッション開始プロトコル(SIP)の拡張である。したがって、通話の受信者だけでなく、個人の信頼ドメイン外の他のエンティティも、SIPメッセージ(通常はSIP INVITE)が個人のaddress-of-record(通常、ユーザの「公開アドレス」と考えられる)ではなく、「From: "Anonymous" <sip:anonymous@anonymous.invalid>」というヘッダ・フィールドで送られたことを知るだけである。PAIが使用される場合、その個人は、その特定の仲介エンティティを使用するすべての個人によって設定されるイニシエータ匿名性集合内で匿名になる。

この例では、受信者が他のSIPペイロード(例えば、SIP ViaやContactヘッダ、セッション記述プロトコル(SDP)など)から個人データを推測または取得する可能性があるという事実を無視していることに留意する。PAIは特定の脅威、つまり受信者に関するアイデンティティ(Fromヘッダー)の開示にのみ対処しようとしているということを意味する。この注意点は、特定のプロトコル拡張の分析が容易にするが、アーキテクチャ全体の分析を行う場合にはこの点を想定することはできない。

6.1.2. 仮名性(Pseudonymity)

インターネット・プロトコルの文脈では、通常、プロトコルで個人名を使用する必要がないため、ほとんどすべての識別子はニックネームまたは仮名にできる。ただし、特定のシナリオでは、個人名が使われると想定するのが妥当である(例えば、vCard[RFC6350]など)。

仮名性が強化されるのは、仮名にリンクできる個人データが少ない場合、そして、同じ仮名が使用される頻度や状況が少ない場合、また、独自に選択された仮名が、より頻繁に新たな行動に使用される場合(オブザーバーや攻撃者の観点からは、それらをリンクできなくなる)である。

インターネット・プロトコルの場合、プロトコルが人手を介さずに仮名を変更できるかどうか、仮名の有効期間のデフォルトの長さ、仮名が誰に公開されるか、個人がどのように公開をコントロールできるか、仮名を変更できる頻度、仮名を変更した場合の結果が重要な考慮事項である。

6.1.3. アイデンティティの機密性

受信者以外のいかなる当事者も、匿名性集合内でイニシエータを十分に識別できない場合、イニシエータはアイデンティティの機密性を持つ。匿名性集合のサイズは、小さければ小さいほどイニシエータを特定するのが容易になるため、アイデンティティの機密性に直接影響する。アイデンティティの機密性は、意図された通信のエンドポイントに対する保護ではなく、盗聴者や仲介者に対する保護を提供することを目的としている。

一例として、拡張認証プロトコル(EAP)[RFC3748]を使用するネットワーク・アクセス認証手順を考えてみる。EAPにはアイデンティティ交換が含まれ、アイデンティティ応答は主にルーティングの目的と、使用するEAPメソッドの選択に使われる。EAPアイデンティティ要求とアイデンティティ応答は平文で送信されるため、EAPピアとEAPサーバの間の通信パスにいる盗聴者や仲介者は、ネットワーク・アクセス識別子(NAI)の形式で符号化されているアイデンティティを盗み見ることができる。この脅威に対処するために、RFC 4282[RFC4282]で説明されているように、EAPメソッドが提供する暗号化によって、NAIのユーザ名部分(レルム部分ではない)を盗聴者や仲介者から隠すことができる。アイデンティティの機密性はEAPの推奨設計基準になっている([RFC4017]参照)。例えば、第3世代認証および鍵合意(EAP-AKA)[RFC4187]のEAPメソッドは、一時的なアイデンティティを利用することで、受動的な敵対者からEAPピアのアイデンティティを保護する。EAP-Internet Key Exchange Protocol version 2 (EAP-IKEv2)方式 [RFC5106]は、個人のアイデンティティに関して能動的な攻撃者から保護するEAP方式の一例である。

6.1.4. アイデンティティ管理におけるデータの最小化

最新システムでは、個人を認証するためにマルチパーティ・トランザクションに依存することが増えている。これらのシステムの多くは、保護されたリソースを提供するリライング・パーティーにAAA機能を提供する責任を負うアイデンティティ・プロバイダを利用している。これらの機能を容易にするために、アイデンティティ・プロバイダは通常、個人の身元を確認し、個人に資格情報を発行するプロセスを経る。個人がリライング・パーティーが提供するサービスを利用しようとするとき、リライング・パーティーは、アイデンティティ・プロバイダが提供する認証アサーションに依存する。より洗練されたシナリオでは、認証アサーションは個人の能力と役割を示す特性であることに留意する。認可責任は、アイデンティティ・プロバイダとリライング・パーティーの間で共有されることもあり、必ずしもアイデンティティ・プロバイダのみに存在する必要はない。

このようなシステムは、さまざまな方法でデータ収集を最小限に抑える多くの特性をサポートする能力を持っている:

特定のユースケースでは、リライング・パーティーは個人の本名や生年月日を知る必要がない(例えば、認証が必要な属性が個人の年齢だけの場合)。

秘密の合意をしているリライング・パーティーは、個人の資格情報を使用して個人を追跡することを防ぐことができる。つまり、2つの異なるリライング・パーティーは、同じ個人が両方のリライング・パーティーが認証したと判断することを防ぐことができる。これには通常、アイデンティティ管理プロトコルのサポートに加え、リライング・パーティーとアイデンティティ・プロバイダの両方によるサポートが必要である。

アイデンティティ・プロバイダは、個人がどのリライング・パーティーとやり取りしたかを知られないようにできる。これには、少なくとも、イニシエータによるリソースへのアクセス時に、アイデンティティ・プロバイダとリライング・パーティーとの間の直接通信を回避する必要がある。

6.2. ユーザの参加

セクション5.2.5で説明したように、個人の知らないところで「秘密裏に」行われるデータの収集と利用は、個人のプライバシーに対する期待に反する傾向があり、データの悪用のインセンティブを生み出す可能性がある。その結果、プライバシーに関する制度には、データの収集と利用について個人に通知し、データの取り扱いに関する決定に個人を関与させることを義務付ける規定が含まれる傾向がある。エンジニアリングの文脈では、ユーザの参加という目標をサポートすることは、通常、ユーザが自分について共有されるデータをコントロールする方法を提供することを意味する。また、ユーザが自分のデータがどのように利用され、共有されることを期待しているかを示す方法を提供することも意味する。プロトコルやアーキテクチャの設計の違いによって、ユーザ参加のサポート(例えば、ユーザとの対話のためのダイアログ・ボックスをサポートする機能)が容易になったり、難しくなったりすることがある。例えば、OAuthベースのサービスは、AAAサービスよりもユーザ入力のフックの方がより自然かも知れない。

ユーザの参加は、監視、二次利用、開示、排除などの脅威を軽減する。

6.3. セキュリティ

保存時と転送時にデータを安全に保つことは、プライバシー保護のもう1つの重要な要素である。[RFC3552]のセクション2で説明されているように、いくつかのセキュリティ目標もプライバシーを強化する役割を果たす:

機密性: 意図しないリスナーからデータを秘密にしておく。
ピア・エンティティ認証: 通信のエンドポイントが意図されたものであることを保証する(機密性の維持をサポートする)。
不正利用: データへのアクセスを許可されたユーザのみに限定する。(この目標もデータの最小化に含まれることに留意する。)
不適切な利用: 許可されたユーザがデータをどのように使用できるかを制限する。(この目標もデータの最小化に含まれることに留意する。)

これらの目標が達成されたとしても、属性、識別子、アイデンティティ、通信、アクション(通信の送信または受信など)、あるいは攻撃者やオブザーバーが関心を持つ可能性のある他の項目などの存在は、たとえ読み取れなくても、まだ検出できる可能性があることに留意する。したがって、監視者や攻撃者が、関心のある項目が存在するかどうかを十分に区別できない検出不可能性は、さらなるセキュリティ目標と考えることができる(ただし、達成するのが非常に困難ではある)。

トラフィック分析による使用中のプロトコルやアプリケーションを検出することは、防御が特に困難な場合がある。個人の匿名性と同様、「プロトコルの匿名性」を実現するには、パケットサイズ、コンテンツ、トークンの位置、パケット間のタイミングなど、同じ属性を持つように見える複数のプロトコルやアプリケーションが存在する必要がある。攻撃者やオブザーバーは、複数のプロトコルやアプリケーションが区別できない場合、トラフィック分析を使っても、どのプロトコルやアプリケーションが使用されているかを特定することはできない。

トラフィック分析の脅威に対する防御は、プロトコルによって可能な範囲はさまざまだろうし、実装や用途に固有の詳細に依存するかも知れないし、どのような他のプロトコルがすでに存在するか、そしてそれらが同じようなトラフィック特性を共有するかどうかにも依存するかも知れない。防御策もまた、プロトコルが何をするように設計されているかによって異なる。例えば、パケットサイズ、タイミング、トークンの位置をランダム化することで、トラフィック分析の脅威を軽減することができる状況もあるが、他の状況(リアルタイム通信など)では、これらの要素の一部またはすべてを一定に保つことが、より適切な防御となる。この種のトレードオフをどのように評価すべきかの例については、「Guidelines for the Use of Variable Bit Rate Audio with Secure RTP」(セキュアRTPでの可変ビットレート・オーディオの使用に関するガイドライン)[RFC6562]を参照のこと。

適切なセキュリティ保護を提供することで、監視、保存データのセキュリティ侵害、誤った帰属、二次利用、開示、侵入などの脅威を軽減することができる。

7. ガイドライン

このセクションは、設計中のプロトコルに関する質問形式で、文書作成者向けのガイダンスを提供する。この質問は、設計プロセスのどの時点でも、特に[RFC4101]で説明されているように、文書作成者が高レベルのプロトコル・モデルを開発した後でも役に立つ。

このセクションで提供されるガイダンスは、特定の実践方法を推奨するものではないことに留意する。IETFで開発されたプロトコルの範囲は広すぎるため、特定のデータの用途や、プライバシーと他の設計目標とのバランスをどのようにとるかについて勧告を行うことはできない。しかし、各質問に対する答えを慎重に検討することで、文書作成者は、プロトコルがプライバシーの脅威から適切に保護されているかどうかを議論するための基礎として機能する包括的な分析を作成することはできるはずである。このガイダンスは、プライバシー分析の思考プロセスを支援することを目的としている。プライバシーに関する考慮事項セクションの書き方について、具体的な指示を提供するものではない。

このフレームワークは4つのセクションに分かれている。セクション6の各軽減クラスを扱う3つのセクションと、一般的なセクションである。実質的なガイダンスが[RFC3552]にすでに存在しているため、セキュリティについては完全には詳しく説明しない。

7.1. データの最小化

a. 識別子(Identifiers)。プロトコルは、通信のイニシエータを区別するためにどのような識別子を使用しているか? プロトコルは、さまざまなプロトコルの相互作用を相関させることができる識別子を使用しているか? プロトコルの目標を達成しつつ、どのような識別子を省略したり、識別性を低くすることができるだろうか?

b. データ(Data)。このプロトコルは、個人、そのデバイス、および/またはデバイスの使用状況((a)で説明した識別子以外)について、どのような情報を公開するのか? その情報は、どの程度まで個人のアイデンティティに結びついているのだろうか? このプロトコルは、個人データと(a)で説明した識別子をどのように組み合わせているのか?

c. オブザーバー(Observers)。(a)と(b)で説明したどの情報が、他の各プロトコル・エンティティ(つまり、受信者、仲介者、イネーブラー)に公開されるのか? プロトコルの実装者が各エンティティと共有する情報を制限する方法はあるのか? 各エンティティと共有される情報を制限するために利用できる運用管理はあるのか?

d. フィンガープリンティング(Fingerprinting)。多くの場合、プロトコルの情報要素の特定の順序や出現によって、そのプロトコルを使うユーザ、デバイス、ソフトウェアのフィンガープリントを取ることが可能になる。このプロトコルはフィンガープリントに対して脆弱か? もしそうなら、どのようにして? 脆弱性を軽減、あるいは排除するように設計できるか? できない場合は、なぜできないのか?

e. 識別子の永続化(Persistence of identifiers)。 (a)で説明した識別子の有効期間について、プロトコル設計ではどのような仮定がなされているか? このプロトコルは、実装者やユーザに識別子の削除や置換を許可しているか? 仕様は、デフォルトでどれくらいの頻度で識別子を削除または置換することを推奨しているのか? 識別子は、他の状態情報とともに、自動的に期限切れになるように設定できるのか?

f. 相関性(Correlation)。プロトコルは識別子の相関を許すのか? プロトコルによって公開される情報が、プロトコルの外部で取得される情報と組み合わせたり、相関されることが予想される方法はあるのか? そのような組み合わせや相関性は、どのようにユーザ、デバイス、アプリケーションのフィンガープリントの取得を容易にするのだろうか? プロトコルのユーザをより識別しやすくする、外部データとの組み合わせや相関が予想されるのか?

g. 保持(Retention)。プロトコルまたはその想定される用途は、(a)または(b)で説明されている情報を受信者、仲介者、またはイネーブラーによって保持することが必要か? もしそうなら、その理由は何か? 保持は永続的なものか、一時的なものか?

7.2. ユーザの参加

a. ユーザ・コントロール。個人データや識別子がプロトコルを介して共有されたり、公開される前に、プロトコルはどのような管理や同意の仕組みを定義したり、要求するのか? そのような仕組みや管理が規定されていない場合、管理や同意はプロトコルの外部で処理されることが想定されているのか?

b. 個々の受信者との共有をコントロールする。プロトコルは、イニシエータがさまざまな受信者とさまざまな情報を共有する方法を提供しているのか? もし、そうでなければ、プロトコルの外部に、イニシエータにそのようなコントロールを提供する仕組みが存在するのか?

c. 仲介者との共有のコントロール。そのプロトコルは、仲介者と共有する情報を、イニシエータが制限する方法を提供しているのか? そうでない場合、プロトコルの外部に、ユーザにそのようなコントロールを提供するメカニズムが存在するのか? ユーザは、仲介者を運営する者と、情報の利用を管理する関係(契約上またはその他)を結ぶことが想定されているのか?

d. 好みの表明。プロトコルは、個人データの収集、利用、開示に関して、イニシエータが受信者または仲介者に個人の好みを表明する方法を提供しているか?

7.3. セキュリティ

a. 監視(Surveillance)。プロトコルのセキュリティ上の考慮事項は、盗聴やトラフィック分析を含む監視をどのように防いでいるのか? そのプロトコルは、例えば、固定オフセットで固定トークンを使用したり、パケットサイズやタイミングをオブザーバーがトラフィックの特徴(例えば、どのプロトコルが使用されているか、トラフィックがリアルタイム・フローの一部かなど)を判断できるようにするなど、トラフィック分析によって観察できる情報が漏洩しているか?

b. 保存データの漏洩(Stored data compromise)。プロトコルのセキュリティに関する考慮事項は、どのように保存データの漏洩を防止または軽減するのか?

c. 侵入(Intrusion)。そのプロトコルのセキュリティに関する考慮事項は、サービス拒否攻撃や、より一般的な未承諾通信を含む侵入をどのように防止または軽減するのか?

d. 誤った帰属(Misattribution)。個人を識別および/または認証するためのプロトコルの仕組みは、どのように誤った帰属を防いでいるのか?

7.4. 一般

a. トレードオフ(Trade-offs)。そのプロトコルは、プライバシーと使いやすさ、プライバシーと効率、プライバシーと実装可能性、プライバシーと他の設計目標の間でトレードオフを行うのか? トレードオフと選択した設計の理論的根拠を記述する。

b. デフォルト(Defaults)。プロトコルを複数のモードまたは複数の設定可能なオプションで運用できる場合、デフォルトのモードまたはオプションは、プロトコルが公開データと識別子の量、識別可能性、および永続性を最小限に抑えるか? デフォルトのモードやオプションは、ユーザ参加の機会を最大化するのか? すべてのモード/オプションの中で最も厳格なセキュリティ機能を提供しているのか? これらの質問に対する答えのいずれかが「いいえ」の場合、より保護力の低いデフォルトが選択された理由を説明する。

8. 例

以下のセクションでは、本文書が推奨する脅威の分析と軽減策の例を示す。これは、上記脅威の多くに脆弱なアーキテクチャ上で、これらの原則を実証しようとすると、特に難しいアプリケーション・プロトコルであるプレゼンスが対象となる。この文章は、IETF仕様に記載されるプライバシーに関する考慮事項セクションの一例として意図されたものではなく、プライバシーを第一原則として考える場合にプロトコルの設計に取り入れるべき考え方の一例として意図している。

[RFC2778]の抄録で定義されているように、プレゼンス・サービスは、通信サービスのユーザが、通信に関する決定を下すために、互いの可用性と性質(disposition)を監視することができる。プレゼンス情報は非常に動的であり、一般的に、ユーザがオンラインかオフラインか、ビジー状態かアイドル状態か、通信デバイスから離れているか近くにいるかなどを特徴付ける。必然的に、この情報にはある種のプライバシーに影響があり、IETFは当初から、自分のプレゼンス情報がどのように共有されるかを決定するためのコントロールをユーザに提供することを目的として、この作業に取り組んだ。Common Profile for Presence (CPP)(プレゼンス用共通プロファイル)[RFC3859]は、プレゼンス情報の配信に関する一連の論理操作を定義する。この抽象モデルは、複数のプレゼンス・システムに適用できる。SIP for Instant Messaging and presence Leveraging Extensions (SIMPLE)用プレゼンス・システム[RFC3856]は、ベースライン・アーキテクチャとしてCPPを使用し、Extensible Messaging and Presence Protocol (XMPP)のプレゼンス操作も CPP[RFC3922]にマッピングされている。

RFC 2778やRFC 3859で定義されている基本的なアーキテクチャは、仲介型である。クライアント(RFC 2778の用語ではプレゼンティティ)は、プレゼンス情報をプレゼンスサーバに公開し、プレゼンス・サーバは許可されたウォッチャーに情報を配布する。したがって、プレゼンス・サーバは、プレゼンス情報が変更されるか期限切れになるまで一定期間保持し、承認されたウォッチャーは要求に応じて公開できるようにする。このアーキテクチャは、既存の標準以前の展開モデルを反映したものである。プレゼンス・アーキテクチャに明示的な承認メカニズムを統合することで、情報を共有する前の意思決定プロセスにエンドユーザを関与させることに広く成功している。今日展開されているほぼすべてのプレゼンス・システムは、このようなメカニズムを提供している。通常、相互認証システムによって、一組のユーザが「バディ」になることに同意すると、お互いのプレゼンス情報を明らかにすることに同意する。バディリストはサーバによって管理されるが、エンドユーザによってコントロールされる。また、ユーザは同様のインタフェースを通じて、明示的に互いをブロックすることもでき、いくつかの展開では、さまざまな種類の「丁寧なブロック(polite blocking)」を提供することが望ましい。

しかし、プライバシー設計の観点から見ると、従来のプレゼンス・アーキテクチャは、ほぼ最悪のシナリオを表している。データの最小化という観点から、プレゼンティティは機密情報をプレゼンスサービスと共有し、サービスはこのプレゼンス情報をユーザによって承認されたウォッチャーとだけ共有するが、これらのウォッチャーがプレゼンスをさらに第三者に中継することを制限する技術的メカニズムはない。これらのエンティティはいずれかが、プレゼンス情報を無期限に記録または保持することも考えられる。システムの目的はお互いを知っているユーザ同志の通信を促進するため、ユーザを匿名にすることで、その機密性を軽減することはできない。ユーザが使用する識別子は長期間存続し、多くの場合、個人名やサービス・プロバイダのドメインなど、個人情報が含まれる。ユーザは確かにバディリストやブラックリストの作成に参加するものの、説明責任を果たす見込みはほとんどない。つまり、ユーザは自分のプレゼンス情報を壁を越えてプレゼンス・サーバに効果的に投げ込み、プレゼンス・サーバがその情報をウォッチャーに配布する。ユーザは通常、プレゼンス情報が承認されたウォッチャーにのみ配信されていることを確認する方法がない。さらに、サーバとプレゼンス・データのすべての発行者および消費者との間の接続は、盗聴者にとって魅力的な標的であり、強力な機密性メカニズムが必要である。しかし、エンドユーザは、プレゼンスサーバとウォッチャーの間にどのようなメカニズムが導入されているかを確認する術を持たない。

さらに、プレゼンス情報の機密性は、通信の性質や能力に限定されるものではない。また、例えば、ユーザが使用しているデバイスの種類を、機能によって明らかになる可能性があり、複数のデバイスが同じユーザのプレゼンスを公開できるため、攻撃者にユーザデバイスの関連付けを許すという重大なリスクがある。プレゼンスに対する重要な拡張は、位置情報共有のサポートを可能にするために開発された。位置情報を共有するシステムのプロトコルを標準化する取り組みは、GEOPRIVワーキンググループで開始された。ワーキンググループを設立する過程で、初期要件とプライバシー脅威の分析する中で、システムが位置情報を共有するためのユーザの同意をサポートする基礎となる通信メカニズムが必要であることが明らかになった。これらの要件とプレゼンス・フレームワークに似ていることはすぐに認識され、この設計上の決定は[RFC4079]に文書化された。このように、位置情報は、システムを介して仲介者や認可された監視者が利用できる他のプレゼンス情報と混在する。

プレゼンス情報に対するプライバシーの懸念は、プレゼンス・アーキテクチャに組み込まれた仲介が主な原因である。プレゼンス・サーバの必要性は、プレゼンスに関する2つの主要な設計要件によって動機付けられている。まず、ユーザがオンラインでない場合、サーバが「オフライン」表示で応答できること。次に、サーバがユーザの管理下にあるさまざまなデバイスによって公開されたプレゼンス情報を構成できる。さらに、エンティティの識別子として、URIを使用しやすくするために、何らかのサービスがプレゼンスURIに現れるドメイン名を持つホストを運用しなければならず、現実的には、どの商用プレゼンス・アーキテクチャもエンドユーザに独自のドメイン名の所有と運用を強制することはない。プレゼンスのようなアプリケーションの多くのエンドユーザは、NATやファイアウォールの背後にあり、事実上、インターネットから直接接続を受けることができない。このようなクライアントがプレゼンス・サーバとの間で開き、維持する永続的な双方向チャネルは、プロトコルの運用に不可欠である。

まず、プレゼンス情報の仲介というトレードオフに見合う価値かどうかどうかを問う必要がある。プレゼンス情報のすべてのパブリケーションの中心にサーバが存在する必要があるのだろうか? プレゼンス情報をエンドツーエンドで暗号化すれば、これらの問題の多くを解決できるように思えるかも知れない。プレゼンティティは、ウォッチャーの公開鍵でプレゼンス情報を暗号化し、その後サーバ経由でプレゼンス情報を送信する。IETFは、プレゼンス情報データ・フォーマット(PIDF)と呼ばれるプレゼンス情報オブジェクト・フォーマットを定義し、位置情報を伝える目的で、PIDFロケーション・オブジェクト(PIDF-LO)に拡張した --- これらのXMLオブジェクトは、暗号化されたラッパーに対応するように設計されている。このデータを暗号化することで、プレゼンス・サーバをセキュリティ侵害した攻撃者が、保存された平文のプレゼンス情報を横取りされるのを防ぐという追加の利点もある。しかし、この提案はすぐにユーザビリティの問題に突き当たる。ウォッチャーの公開鍵を発見することが最初の難題であり、これにうまく対処できたインターネット・プロトコルはほとんどない。このソリューションでは、プレゼンティティは、プレゼンス情報を積極的に探しているウォッチャがいるかどうかに関係なく、プレゼンス・サーバは承認されたウォッチャごとに1つのプレゼンス情報の暗号化されたコピーをプレゼンス・サービスに公開する必要がある。多くのウォッチャを抱えるプレゼンティティにとっては、特にプレゼンス情報のダイナミズムを考慮すると、プレゼンス・サーバに受け入れ難い負担を強いることになる。最後に、同じユーザの管理下にある複数のデバイスから報告されたプレゼンス情報を、サーバが構成することを妨げる。全体として、これらの問題は、プレゼンス情報のオブジェクト暗号化の見通しは疑わしいものになる。

SIPのようなプレゼンス情報をサポートするいくつかのプロトコルは、パブリッシング・モードやプロキシ・モードではなく、リダイレクト・モードで仲介エンティティを操作することができる。言い換えると、サーバを介してプレゼンス情報を送信する代わりに、これらのプロトコルは単にウォッチャーをプレゼンティティにリダイレクトすることができ、プレゼンス情報はプレゼンティティからウォッチャーに直接かつ安全に渡すことができる。この場合、プレゼンティティのIPアドレスがウォッチャーに開示されることになり、それなりのリスクが伴うことに留意する。その場合、プレゼンティティは、ウォッチャーと共有したい情報を正確に決定することができ、ウォッチャ自体を任意の強度の資格情報で認証することができ、エンドツーエンドの暗号化によって、不正アクセスの可能性を減らすことができる。リダイレクション・アーキテクチャでは、プレゼンス・サーバ自体がすべての情報を監視して転送する必要がなく、プレゼンス・サーバは必要な「オフライン」の表示を提供することができる。このメカニズムは、暗号化よりも有望だが、重大な難題も抱えている。このメカニズムもまた、複数のデバイスからのプレゼンス情報の合成を提供しない ─ 実際、ウォッチャーはこの合成を自ら行うことを余儀なくされる。ただし、このアプローチに対する最大唯一の障害は、プレゼンティティのデバイスとウォッチャーの間にエンドツーエンドの接続を作成することが難しいことである。これらのエンドポイントの一部またはすべてが、ピアツーピア接続を妨げるNATやファイアウォールの背後にある可能性があるから。この問題に対するソリューションは、Session Traversal Utilities for NAT (STUN)やTraversal using Relays around NAT (TURN)などが考えられるが、システム全体が複雑になる。

その結果として、仲介はプレゼンス・アーキテクチャの特徴として取り除くのが難しい。特に合成が要求されるため、仲介者と共有するデータを最小限に抑えることは難しい。そのため、仲介者との共有の制御は、アーキテクチャの他の明示的なコンポーネントから行う必要がある。そのため、IETFにおけるプレゼンス作業は、プレゼンス・サーバの活動へのユーザの参加を改善することに焦点を当てた。この作業はGEOPRIVワーキンググループで開始され、ユーザの位置情報は特に機密性の高いものとして認識されているため、位置情報のプライバシーに関する制御を行なった。[RFC2779]で定義されているプライバシー要件を満たすことを目的に、再送を許可するかどうかや、保持期間がいつ終了するかといった一連の使用法が、PIDF-LOに追加され、常に位置情報とともに一緒に移動するようになった。これらのプライバシー設定は、プレゼンス情報を保存・転送する仲介者だけでなく、それを利用するウォッチャーにも適用される。

このアプローチは、クリエイティブ・コモンズ[CC]の精神、すなわち限られた条件(「継承」[CC-SA]など)の使用に実によく従っている。ただし、クリエイティブ・コモンズとは異なり、GEOPRIVワーキンググループは、IETFの範囲外となるため、法的な言語を作成したり、グラフィック・アイコンをデザインしたりする作業を開始しなかった。特に、GEOPRIVのルールでは、位置情報の保持と再送信に関する優先事項を明記している。一方、GEOPRIVは、PIDF-LOオブジェクトを受信するいかなるエンティティにも、これらの優先事項を表現する能力をまったく欠いている場合、その優先事項が尊重されないことを保証できる。GEOPRIVのルールは、説明責任を確立する手段を提供できる。

保持と再送信の要素は、プレゼンスを共有する際の優先事項の表現の最も重要な例として想定された。PIDFオブジェクトは拡張のために設計されており、PIDF-LOのために作成されたルールセットも、ユーザの優先事項の新しい表現を提供するために拡張することができる。しかし、すべてのユーザの優先事項情報が特定のPIDFオブジェクトに結び付ける必要はない。プレゼンス・アーキテクチャが想定する多くの形式のアクセス制御ポリシーは、ユーザとの何らかのインタフェースによってプレゼンス・サーバにプロビジョニングする必要がある。この要件は、最終的に共通ポリシー・フレームワーク([RFC4745]で定義)と呼ばれる一般的なアクセス制御ポリシー言語の標準化の引き金となった。この言語は、情報の配布を制御する方法を、XML形式で表現された単純な条件、アクション、変換ルールとしてを表現できる。共通ポリシー自体は、インスタンス化する必要がある抽象形式である。プレゼンス認証ルール [RFC5025]と地理位置情報ポリシー[RFC6772]の2つの例を挙げることができる。前者はプレゼンスベースのシステムにさらなる表現力を提供し、後者は位置ベースの条件と変換のための構文とセマンティクスを定義する。

結局のところ、プレゼンスに関するプライバシーの取り組みは、プライバシーの原則とアーキテクチャと市場のニーズとの間の妥協の産物である。アーキテクチャから仲介者を完全に排除したり、プレゼンス情報へのアクセスを阻止することは現実的ではなかったが、IETFはユーザが自分の好みを表明し、プレゼンスサービスでの制御をプロビジョニングする方法を提供した。これまでのところ、プライバシー・メカニズムの実装分野では大きな成功が得られているわけではないが、これらのメカニズムの限界を文書化して認識することで、設計者は実装者とエンドユーザに、IETFのプレゼンス・プロトコルのプライバシー特性に関する十分な情報に基づいた視点を提供することができた。

9. セキュリティに関する考慮事項

本文書では、通常のセキュリティ分析に加えて、プロトコル設計者が考慮すべきプライバシーの側面について説明する。

10. 謝辞

クリスティン・ランネガーの広範囲にわたる有益なレビューコメントに感謝する。

スコット・ブリム、ケイシー・シャペル、マーク・リンスナー、ブライアン・マクラフリン、ニック・マシューソン、エリック・レスコラ、スコット・ブラッドナー、ナット・サキムラ、ビョルン・ヘールマン、デビッド・シンガー、ディーン・ウィリス、ルーシー・リンチ、トレント・アダムス、マーク・リザール、マーティン・トムソン、ジョシュ・ハウレット、ミーシャ・タフフィールド、S・ムーネサミー、ジョウ・スージン、クラウディア・ディアス、レイフ・ヨハンソン、ジェフ・ホッジス、スティーブン・ファレル、スティーブン・ジョンストン、カレン・ジェニングス、テッド・ハーディ、デイブ・セイラー、クラース・ウィレンガ、エイドリアン・ファレル、ステファン・ボルツマイヤー、デイブ・クロッカー、ヘクター・サントスらの、本文書に対する有益なフィードバックに感謝する。

最後に、MIT、ISOC、W3C、IABが共催した2010年12月のインターネット・プライバシー・ワークショップで、参加者から寄せられたフィードバックに感謝したい。

ジョン・モリスは現在米国政府に雇用されているが、個人的な立場で本文書の作成に参加したものであり、本文書で表明された見解は彼の雇用主の見解を反映したものではない可能性がある。

11. 承認時のIABメンバー

バーナード・アボバ
ヤリ・アルコ
マーク・ブランシェット
ロス・キャロン
アリッサ・クーパー
スペンサー・ドーキンス
ジョエル・ハルパーン
ラス・ハウスリー
エリオット・リア
シン・リー
アンドリュー・サリバン
デイブ・セイラー
ハンネス・チョフェニヒ

12. 参考規格

[CC-SA] Creative Commons, "Share Alike", 2012, http://wiki.creativecommons.org/Share_Alike.

[CC] Creative Commons, "Creative Commons", 2012, http://creativecommons.org/.

[CoE] Council of Europe, "Recommendation CM/Rec(2010)13 of the Committee of Ministers to member states on the protection of individuals with regard to automatic processing of personal data in the context of profiling", November 2010, https://wcd.coe.int/ViewDoc.jsp?Ref=CM/Rec(2010)13.

[EFF] Electronic Frontier Foundation, "Panopticlick", 2013, http://panopticlick.eff.org.

[FIPs] Gellman, B., "Fair Information Practices: A Basic History", 2012, http://bobgellman.com/rg-docs/rg-FIPShistory.pdf.

[OECD] Organisation for Economic Co-operation and Development, "OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data", (adopted 1980), September 2010, http://www.oecd.org/.

[PbD] Office of the Information and Privacy Commissioner, Ontario, Canada, "Privacy by Design", 2013, http://privacybydesign.ca/.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.

[RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.

[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.

[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.

[RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.

[RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)", RFC 3922, October 2004.

[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.

[RFC4079] Peterson, J., "A Presence Architecture for the Distribution of GEOPRIV Location Objects", RFC 4079, July 2005.

[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.

[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.

[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.

[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.

[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.

[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.

[RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, December 2007.

[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.

[RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "The Extensible Authentication Protocol- Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", RFC 5106, February 2008.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.

[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.

[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011.

[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011.

[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012.

[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, September 2012.

[RFC6772] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", RFC 6772, January 2013.

[Solove] Solove, D., "Understanding Privacy", March 2010.

[Tor] The Tor Project, Inc., "Tor", 2013, https://www.torproject.org/.

[Westin] Kumaraguru, P. and L. Cranor, "Privacy Indexes: A Survey of Westin's Studies", December 2005, <http://reports-archive.adm.cs.cmu.edu/anon/isri2005/ CMU-ISRI-05-138.pdf>.

著者のアドレス

アリッサ・クーパー
CDT
1634 Eye St. NW, Suite 1100
Washington, DC 20006
アメリカ
電話: +1-202-637-9800
メール: acooper@cdt.org
URI: http://www.cdt.org/

ハンネス・チョフェニヒ
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
フィンランド
電話: +358 (50) 4871445
メール: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at

バーナード・アボバ
Skype
メール: bernard_ababa@hotmail.com

ジョン・ピーターソン
NeuStar, Inc.
1800 Sutter St. Suite 570
Concord, CA 94520
アメリカ
メール: jon.peterson@neustar.biz

ジョン・B・モリス・ジュニア
メール: ietf@jmorris.org

マリット・ハンセン
ULD
メール: marit.hansen@datenschutzzentrum.de

リス・スミス
Janet
メール: rhys.smith@ja.net

更新履歴

2024.4.21

GitHubで編集を提案

要旨