RFC 9620: 人権プロトコルとアーキテクチャに関する検討のガイドライン
要旨
本文書は、ネットワーク・プロトコルやアーキテクチャの開発に従事する開発者向けに人権の考慮事項に関するガイドラインを定めたもので、プライバシーの考慮事項に関するガイドライン(RFC 6973)で行われた作業と同様の内容となっている。これは、RFC 8280の人権の考慮事項に関するガイドラインの更新版である。
この文書は、IRTFの人権プロトコルに関する考慮事項(HRPC)研究グループの成果である。
本文書の位置付け
本文書はインターネット標準化過程の仕様書ではなく、情報提供を目的で公開する。
本文書は、インターネット・リサーチ・タスクフォース(IRTF)の成果物である。IRTFは、インターネット関連の研究開発活動の成果を公開している。これらの成果は、展開に適さないかも知れない。このRFCは、インターネット・リサーチ・タスクフォース(IRTF)のQIRG研究グループの合意を表す。IRSGによって公開が承認された文書は、インターネット標準のいかなるレベルにも該当しない。RFC 7841のセクション2を参照のこと。
文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、<https://www.rfc-editor.org/info/rfc9620>で入手できる。
著作権に関する通知
Copyright (c) 2024 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。
本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(<https://trustee.ietf.org/license-info>)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。
1. はじめに
本文書は、プロトコル開発者向けの人権プロトコルの考慮事項を概説したものである。この文書では、エンジニアがプロトコルの開発や改善を行う際、自分たちの決定がインターネット上の人権行使に潜在的にどのような影響を与える可能性があるかを理解したい場合、自らに問いかけるべき課題を提示している。プロトコルの影響は、その設計からだけで推測できるものではなく、その使用法や実装も研究し、人権への影響を完全に評価する必要があることに留意すべきである。
これらの課題は、人権プロトコルに関する考慮事項(HRPC)研究グループが実施した調査に基づいており、この調査は以前に文書化されている。この調査では、人権が標準規格やプロトコルに関連していることを明らかにし、人権に影響を与える技術的概念の共通語彙を提供し、また、これらの技術的概念をどのように組み合わせれば、インターネットが人権を促進する環境であり続けるかを示す。これにより、人権プロトコル考慮事項を策定するためのモデルの輪郭が具体化する。
本文書は、 [RFC8280]に記載されているガイドラインの繰り返しである。本文書における人権レビューの実施方法(セクション3.2)と人権に関する考慮事項のガイドライン(セクション3.3)は、関連性、正確性、妥当性について検証されている[HR-RT]。人権とは何かについての理解は、「世界人権宣言」[UDHR]とその後の条約に基づいており、これらは全体で国際人権法の体系を構成している[UNHR]。
本文書は、直接的か間接的か、長期的か短期的かを問わず、ある種のプロトコルの選択がもたらし得る(潜在的な)人権侵害の性質について、詳細な分類法を提供するものではない。これは文脈に大きく依存するためでもあり、またこの文書が実用的なガイドラインを提供することを目的としているためでもある。しかし、この分野でのさらなる研究は、開発者と実装者にとって間違いなく有益であろう。
この情報文書は、インターネット・リサーチ・タスク・フォース(IRTF)の人権プロトコルに関する考慮事項(HRPC)研究グループから、公表に向けた合意を得ている。この文書は、研究グループだけでなく、研究グループ外の研究者や実務者によってもレビューされ、試行され、検証されている。研究グループは、インターネット・プロトコルやアーキテクチャが社会に与える影響の理解は発展途上の活動であり、現在も継続中の研究であることを認めている。本文書はIETFの製品ではなく、標準でもない。
2. 人権への脅威
インターネット上の人権行使に対する脅威は、さまざまな形で現れる。プロトコルや標準規格は、表現の自由の権利、情報を与えられる権利、差別を受けない権利、平等な保護を受ける権利、文化生活・芸術・科学への参加の権利、集会及び結社の自由に対する権利、プライバシーの権利 、安全を求める権利を傷つけたり、侵害したりする可能性がある。特定のサービスやコンテンツへのアクセスを拒否されたエンド・ユーザは、政府やその他当局の不正行為に関する重要な情報を開示できなくなる可能性がある。通信を監視されている人は、結社の自由を行使したり、政治的プロセスに参加したりすることを妨げられたり、思いとどまらせたりする可能性がある[Penney]。最悪のシナリオでは、情報を漏洩するプロトコルが物理的な危険につながる可能性がある。現実的な例として考えられるのは、国家にとって脅威であると認識された個人が、国家機関によってネットワーク・トラフィックの監視を通じて収集された情報に基づいて、拷問、超法規的殺害、拘留の対象となる場合が挙げられる。
本文書は、人権に対する脅威がインターネット上でどのように具体化するかについて、いくつかの例を示す。この脅威モデルは、セキュリティ脅威分析に基づく「インターネット・プロトコルのプライバシーに関する考慮事項」[RFC6973]にヒントを得たものである。この方法はまだ開発中であり、インターネット・プロトコルやシステムにおける人権リスクを評価するための完璧な解決策ではない。インターネット・プロトコルにおいて、ある特定の人権の脅威は、安全への考慮事項[RFC3552]の一部として間接的に考慮されている。しかし、プライバシーに関する考慮事項[RFC6973]やレビュー、ましてやプロトコルの人権への影響評価は、標準化も実装もされていない。
多くの脅威、イネイブラー、リスクは、さまざまな権利と結びついている。人権が相互に関連し、依存し合い、不可分であることを考慮すれば、これは驚くべきことではない。というのも、すべての人権が情報通信技術(ICT)全般、特にプロトコルや標準に関連しているわけではないため、ここではすべての人権について議論しているわけではない[Orwat]:
人権の価値の主な源泉は、世界人権宣言(UDHR)[UDHR]、市民的及び政治的権利に関する国際規約(ICCPR)[ICCPR]、経済的、社会的及び文化的権利に関する国際規約(ICESCR)[ICESCR]で構成される国際人権章典(International Bill of Human Rights)である。インターネット検閲のいくつかの事例を踏まえ、2012年に国連人権理事会決議20/8が採択され、「...オフラインで人々が有する権利と同じ権利が、オンラインでも保護されなければならない...」[UNHRC2016]と確認した。2015年には、インターネットのための人権憲章と原則[IRP]が策定され、発表された[Jorgensen]。これらの文書によると、ICTシステムに関連する人権の例としては、人間の尊厳(世界人権宣言第1条)、差別の禁止(第2条)、生命・自由・安全に対する権利(第3条)、意見と表現の自由(第19条)、集会と結社の自由(第20条)、平等な保護、法的救済、公正な裁判、適正な手続き、推定無罪に対する権利(第7条から第11条)、適切な社会・国際秩序(第28条)、公共活動への参加(第21条)、文化生活への参加、知的財産の保護(第27条)、プライバシー(第12条)などが挙げられる。
経済的権利を含むICTに関連する人権の部分的な一覧は、[Hill]に掲載されている。
これは決して特定の権利を排除したり、ある権利を他の権利よりも優先させようとするものではない。
3. 人権レビューの実施
理想的には、プロトコルの開発者と協力者は、人権への配慮を設計プロセス自体に組み込む必要がある(セクション3.1(「人権配慮モデルのガイドラインに基づくインターネット草案の分析」)を参照)。このセクションでは、人権レビューの実施方法、つまりプロトコルや標準が人権に与える影響や潜在的な影響を測定する方法についてのガイダンスを提供する。
人権レビューは参加者であれば誰でも行うことができ、インターネット草案の開発プロセスのさまざまな段階で行うことができる。一般的に言って、技術の開発に影響を与えるのは、後の段階よりも前の段階の方が容易である。これは、ラストコールでのレビューが重要ではないという意味ではないが、レビューされた文書に大きな変更がもたらす可能性は低くなる。
人権レビューは、標準開発プロセスに影響を与えるため、文書作成者、文書指導者、レビュー・チームのメンバー、支持者、または影響を受けるコミュニティが行うことができる。IETF文書は、その実装が多くのさまざまなコミュニティにも影響を与える可能性があるため、さまざまな知識、視点、背景を持つ人々から恩恵を受けることができる。
具体的な人権への影響についてテクノロジーを分析する方法は、まだ初期段階である。現在、人権レビュー・チームでは5つの方法が検討されており、多くの場合、相互に関連している。
3.1. 人権への考慮事項のガイドライン・モデルに基づくインターネット草案の分析
このインターネット草案の分析では、セクション4で説明したモデルを使用する。インターネット草案のレビューには、概要を示したカテゴリーと質問を用いることができる。この利点は、既知の概要を提供し、文書作成者は背景と文脈を理解するために[RFC8280]と同様に、この文書に戻ることができることである。
3.2. インターネット草案を、認識または推測される影響に基づいて分析する
インターネット草案をレビューする際、草案を精読し、それがネットワークや社会にどのような影響を与えるかを理解しようと努めることで、具体的な人権への影響が明らかになることがある。人権への考慮事項のモデルをそのままストレートに使うよりは構造化されていないが、この分析は人権とプロトコルの関係についての新たな推測的理解につながるかもしれない。
3.3. 専門家インタビュー
文書作成者、ワーキング・グループの活動メンバー、またはその分野の専門家へのインタビューは、プロトコルの特徴とその効果を探るのに役立つ。このアプローチには、主に2つの利点がある。
- レビュー担当者がプロトコルの(意図された)仕組みをより深く理解することができる。
- これにより、レビュー担当者は専門家や文書作成者と議論を始めることができ、レビューが公開されたときに、そのレビューが支持される助けとなる。
3.4. 影響を受ける人々とコミュニティーへのインタビュー
プロトコルはインターネットの利用者に影響を与える。インタビューは、プロトコルを利用する人々にどのような影響を与えるかをレビュー担当者が理解するのに役立つ。人権は権利保有者の視点から理解するのが最もよいため、このアプローチはテクノロジーの現実世界への影響の理解を深めることができる。同時に、ある変化がをあるプロトコルに起因すると考えるのは難しいかもしれない。もちろん、プロトコルが広く普及していない場合は、さらに難しい。
3.5. 実装の影響の追跡
実際に展開されたプロトコルは、プロトコルの設計や開発段階における期待と食い違う可能性がある[RFC8980]。仕様がすでに実行コードに関連付けられている場合、そのコードは実験的な設定またはその影響を観察できるインターネット上で分析することができる。草案の文章をレビューするのとは対照的に、このアプローチでは、レビュー担当者は仕様が実際にはどのように機能するかを理解でき、また、そのテクノロジーがどのような未知または予期しない影響を与える可能性があるかを理解できる。
4. 人権への考慮事項に関するガイドライン
このセクションでは、プロトコルと技術的な決定が人権の行使にどのように影響するかについて、アンケート形式で文書作成者向けのガイダンスを提供する。このアンケートは、設計プロセスのどの時点でも有用だが、特に文書作成者が[RFC4101]で説明されているようなハイレベルのプロトコル・モデルを開発した後に役立つ可能性がある。これらのガイドラインは、参照されている既存の仕様を置き換えることを目的とするものではなく、むしろそれらに貢献し、人権の観点から設計プロセスを検討することを目的としている。
プロトコルとインターネット標準は、Request for Comments (RFC)で説明しているプロトコルまたはテクノロジーの潜在的な誤用から生じる潜在的な人権リスクに関する文書化された議論から恩恵を受ける可能性がある。これは、そのRFCの適用性ステートメントと組み合わせることができる。
このセクションで提供されるガイダンスは、特定の慣行を推奨するものではないことに留意されたい。IETFで開発されたプロトコルの範囲は広範にわたるため、データの特定の用途や、人権と他の設計目標とのバランスをどのように取るかについて推奨することはできない。しかし、以下の質問に対する回答を慎重に検討することで、文書作成者は、プロトコルが特定の人権に対する脅威を適切に考慮しているかどうかについての議論の基礎となる包括的な分析を作成することができるはずである。このガイダンスは、人権分析の思考プロセスを支援することを目的としている。人権に関する考慮事項のセクションをどのように記述するかについての具体的な指示を与えるものではない([RFC6973]で示された例に従う)。
このような問題を検討するにあたり、著者は技術の進歩や時間の経過が保護を弱体化させる可能性があることを認識する必要がある。一般的に、権利に関する検討は、抽象的で絶対的な目標ではなく、目的と具体的なユースケースを持つ方が、より効果的であると考えられる。
また、このセクションでは「プロトコル」という言葉を使用しているが、これらの質問で挙げた原則は、他のタイプのソリューション(既存のプロトコルの拡張、特定の問題に対するソリューションのアーキテクチャなど)にも適用できる場合があることに留意する。
4.1. 中間者 (Intermediaries)
課題: プロトコルは、中間ノードにおけるプロトコル固有の機能に依存しているか、またはそれを許可しているか?
説明: エンドツーエンド原則[Saltzer]では、特定の機能はネットワークの「エッジ」で実行できるし、実行すべきであると述べている。[RFC1958]は、「非常に一般的な言葉で言えば、コミュニティは目標は接続性であり、インテリジェンスはネットワークに隠されるのではなく、エンドツーエンドであると考えている」と述べている。プロトコルの交換に両エンドポイントと中間者が含まれる場合、特に中間者がどちらのエンドポイントの管理下にない場合、また例えばHTTPSプロキシの傍受[HTTPS-interception]のように、エンドポイントからほとんど見えない場合、新しい障害が発生する可能性がある。このパターンは、中間者がプロトコルの制限 -- [RFC8446]のセクション9.3で説明しているように、エンドポイントがより新しいプロトコルを使用することができないよう -- を課す可能性があるため(仕様に違反する場合もある)、硬直化の一因にもなる。
中間者はサービスとは異なることに留意する。前者の場合、サードパーティの要素はプロトコル交換の一部であり、後者の場合、エンドポイントは明示的にサービスと通信する。クライアント/サーバ・パターンは、中間者を持つよりも要素間の責任を明確に分離することができる。ただし、クライアント/サーバ・システムであっても、メッセージング・レイヤ・セキュリティ(MLS) [RFC9420]の設計のように、サービスの範囲外のプロトコル要素に対して、エンドポイント間でエンドツーエンドの暗号化を提供することは、多くの場合良い慣行である。
例: エンドポイント間の暗号化は、中間者による干渉からプロトコルを保護するために使用できる。QUIC[RFC9000]のトランスポート層情報の暗号化とTLS Server Name Indication (SNI)フィールド[TLS-ESNI]の暗号化は、この慣行例である。この結果、ネットワーク・オペレータがトラフィックを検査できる範囲が制限され、エンドポイントの動作を監視するためにオペレータがエンドポイントを制御することが必要になる。
影響:
- 表現の自由の権利
- 集会及び結社の自由に対する権利
4.2. 接続性 (Connectivity)
課題: そのプロトコルは低帯域幅と高レイテンシの接続に最適化されているか? プロトコルをステートレスな方法で開発することは可能か?
ネットワークの品質や状況は地理や時間によって異なるという事実を考慮すると、低帯域幅や高レイテンシの接続でも信頼できるようなプロトコルを設計することも重要である。
影響:
- 表現の自由の権利
- 集会及び結社の自由に対する権利
4.3. 信頼性 (Reliability)
課題: そのプロトコルはフォールト・トレランスか? フォールバックや通知のメカニズムを使用して、適切にダウングレードできるか? プロトコルは悪意のあるでグレードの試みに抵抗できるか? でグレードを通知するための文書化された方法があるか? 障害からの復旧や部分的な回復のための手段があるか? 予期しない変化や状況に直面しても、プロトコルは信頼性と性能を維持できるか?
説明: 信頼性とレジリエンスは、プロトコルが記述されたとおりに、エラーに強く(耐性があり)、一貫してその機能を実行し、予期しない結果が招くことなく機能することを保証する。プロトコルの信頼性対策は、利用者が意図した通信が正常に実行されることを保証する。
信頼性の高いシステムは、グレースフルにデグレードし、デグレードを通知する方法が文書化されている。また、障害からグレースフルに回復するメカニズムも備えており、該当する場合は部分的な回復も可能である。
ここで、ランダムなデグレードと悪意のあるデグレードを区別することが重要である。例えば、TLSの旧バージョンに対する攻撃の中には、TLSが安全ではない暗号スイートにグレースフルにダウングレードする機能を悪用したものがある[FREAK] [Logjam]。機能の観点からは有用だが、セキュリティの観点からは悲惨な結果を招く可能性がある。
信頼性を確保するには、配信が失敗した場合にサービスが利用者に通知することが必要である。リアルタイム・システムの場合、信頼性の高い配信に加えて、プロトコルは適時性(timeliness)を確保する必要がある。
例: 最新のIPスタック構造では、信頼性の高いトランスポート層は、TCPのACKメッセージ[RFC9293]で与えられるような、トランスポート処理が正常に完了したことを示す情報を必要とする。同様に、アプリケーション層のプロトコルは、リクエストの処理を示すステータス・コードを含む、アプリケーション固有の確認応答を必要とするかもしれない([RFC3724]を参照)。
影響:
- 表現の自由の権利
- 安全を求める権利
4.4. コンテンツ・シグナル (Content Signals)
課題: プロトコルは、ペイロードまたはヘッダのいずれかに、差別的処理に使用できる明示的または暗黙的なプレーンテキスト要素が含まれているか? このようなデータがネットワーク中間者に漏洩するのを最小限に抑える方法はあるか? もし、そうでない場合、そのプロトコルの展開において、差別的処理(特定のトラフィックの優先順位付けを含む)がネット中立性に悪影響を及ぼすかどうかを監査できるようにする方法はあるか?
例: ネットワーク中間者が、パケットが運んでいるコンテンツの種類を判断できるようになると、その情報を使って、ある種類のコンテンツを優先したり、別の種類のコンテンツを不利に扱うことができる。これは、利用者が選択したコンテンツを送受信する能力に影響を与える。
[RFC8558]で推奨されているように、プロトコル設計者はその内容の暗黙的なシグナルの構築を避けるべきである。一般的に、プロトコル設計者は中間者のための明示的なシグナルの追加を避けるべきである。特定のケースでは、そのような明示的なシグナルを追加することが必要になるかもしれないが、設計者はそれがエンドユーザに明確な利益をもたらす場合にのみそうすべきである(構成員の優先順位の詳細については[RFC8890]を参照)。このような場合、そのシグナルが人権に与える影響を文書化すべきである。
多くのプロトコルは、エンドポイント向けのシグナルを提供し、コンテンツ(例えばTCPポート番号)または送信者/受信者(IPアドレス)のいずれかに基づいて、トラフィックを差別するために、中間者が暗黙のシグナルとして使用できることに留意する。可能であれば、これらは暗号化によって中間者から保護すべきである。多くの場合(例えばIPアドレス)、これらのシグナルを取り除くことは困難だが、TLSアプリケーション層プロトコルのネゴシエーション[RFC7301]などの他のケースでは、このデータを保護するための積極的な取り組みが行われている[TLS-ESNI]。
影響:
- 表現の自由の権利
- 差別を受けない権利
- 平等な保護を受ける権利
4.5. 国際化 (Internationalization)
課題: プロトコルや仕様では、ペイロードやヘッダ内に、人間が理解または入力しなければならないテキスト文字列要素を定義しているか? 仕様ではUnicodeを許可しているか? もし、そうであれば、1つの文字セット(UTF-8でなければならない)または複数の文字セット(相互運用性にとって危険)のテキストを受け入れるか? UTF-8以外の文字セットやエンコーディングが許可されている場合、仕様では文字セットの適切なタグ付けを義務付けているか? [RFC6365]を参照したか?
説明: 国際化とは、プロトコル、標準、実装をさまざまな言語やスクリプトで使えるようにすることである(セクション4.6(「ローカリゼーション」)を参照)。IETFでは、国際化とは、プロトコルに非ASCIIテキストの処理を追加または改善することを意味する[RFC6365]。別の観点として、最初からグローバルな使用を想定して設計されたプロトコルに適しているのは、ワールド・ワイド・ウェブ・コンソーシアム(W3C)が使用している定義である[W3Ci18nDef]:
国際化とは、文化、地域、言語が異なる対象オーディエンス向けに簡単にローカライズできるように、製品、アプリケーション、文書コンテンツを設計・開発することである。
テキストを扱う多くのプロトコルは、1つの文字セット(US-ASCII)のみを扱うか、コード化された文字セットとエンコーディングが何であるかをローカルな推測に任せている(当然、相互運用性の問題につながる)。複数の文字セットが許可されている場合、それらは明示的に識別されなければならない[RFC2277]。プロトコルに非ASCIIテキストを追加することで、プロトコルはより多くのスクリプトを処理できるようになり、うまくいけば世界中の利用者を代表することができる。今日の世界では、それは通常、UTF-8でエンコードされたUnicodeのみを許可することで、ほとんど達成できる。
現在のIETFの慣行[RFC2277]では、国際化は、テキストベースのプロトコルで使用される動詞のようなプロトコル要素が対象ではなく、利用者向けの文字列を対象としている。(文字列の中には、識別子のように、コンテンツとプロトコルの両方の要素を持つものがあることに留意する。) これは、利用者が目にすることができない要素に対しては合理的な慣行だが、開発者は、プロトコルの利用者向けの機能と、それらが運ぶコンテンツに対して、すべてのスクリプトと文字セットの完全かつ平等なサポートを提供すべきである。
例: セクション4.6(「ローカリゼーション」)を参照のこと。
影響:
- 表現の自由の権利
- 政治参加の権利
- 文化生活・芸術・科学への参加の権利
4.6. ローカライゼーション (Localization)
課題: プロトコルは国際化の基準を守っているか? 関連するオーディエンス向けにプロトコルをローカライズするための具体的な手段を講じたか?
説明: 「ローカリゼーションとは、製品、アプリケーション、文書のコンテンツを、特定のターゲット市場 (「ロケール」)の言語、文化、他の要件を満たすために適合させることを指す」[W3Ci18nDef]。私たちの目的では、特定の言語または特定のロケールの利用者向けに機能するように実装を翻訳することと説明できる(セクション4.5 (「国際化」)を参照)。国際化はローカリゼーションと関連しているが、同じではない。国際化はローカリゼーションの必要条件である。
例: インターネットはグローバルなメディアだが、そのプロトコルや製品の多くは、ASCII (情報交換用米国標準コード)の読み書きができ、英語を知っているというような特殊な特性を持つ特定の利用者を念頭に置いて開発されている。このため、世界中のオンライン人口の大部分が、文化的・言語的にアクセス可能な方法でインターネットを利用する能力が制限される。個人が自分の好みの言語でデータにアクセスしたいという見解を考慮した標準の例が、[RFC5646]にある。この文書では、情報が記述されている言語の識別子でラベル付けする方法を説明している。これにより、情報は複数の言語で表示され、アクセスできるようになる。
影響:
- 差別を受けない権利
- 文化生活・芸術・科学への参加の権利
- 表現の自由の権利
4.7. オープン標準 (Open Standards)
課題: プロトコルは、容易に実装、改善、構築、および/またはさらなる開発ができるように、完全に文書化されているか? プロトコルの実装、実行、またはさらなる開発にプロプライエタリなコードに依存しているか? プロトコルは、例えば組み込まれたベンダー仕様を「必須」や「推奨」にするなど、技術的に同等の競合する仕様よりも特定のプロプライエタリな仕様を優遇しているか[RFC2026]? 有料の別の標準を規範的に参照しているか(それがなくても実行できるか)? 標準が完全に実装されるのを妨げる特許があるか[RFC8179] [RFC6701]?
説明: インターネットがグローバルなネットワークに発展できたのは、オープンで非独占的な標準[Zittrain]が存在したからである。それらは相互運用性を実現するために極めて重要である。しかし、オープン標準はIETFの中で明確に定義されているわけではない。この件に関して、[RFC2026]は以下のように述べている:
ANSI、ISO、IEEE、ITU-Tなど、さまざまな国内や国際標準化団体が、ここ[IETF]で定義されている技術仕様に類似した、さまざまなプロトコルやサービスの仕様を策定している。また、国内および国際的グループは、適用性ステートメントに類似した「実装者合意」を発表し、その標準の実用的な適用に関する実装固有の詳細な情報をまとめている。これらすべて、インターネット標準化プロセスの目的では「オープンな外部標準」と見なされる。
同様に、[RFC3935]はオープン標準を定義していないが、「オープン・プロセス」の重要性を強調している、例:
... 関心のある人なら誰でも作業に参加することができ、何が決定されようとしているかを知ることができ、その問題について意見を述べることができる。
オープン標準(およびオープン・ソース・ソフトウェア)により、利用者は使用しているツールのセキュリティやプライバシーの特性を含め、そのツールがどのように機能するかについての情報を得ることができる。さらに、パーミッションレス・イノベーションを可能にする。これは、既存の通信構造に基づいて新しいプロトコルを自由に作成し、展開する自由と能力を維持するために重要である。これは、私たちが知っているインターネットの核心であり、その基本的にオープンな性質を維持するために、オープン標準を開発する必要性を意識する必要がある。
規範的に実装される必要のある標準規格はすべて、オープンソースやフリーソフトウェアでも実装できるように、特許侵害の申し立てに対して適切な保護が講じられ、自由に利用できるようにすべきである。特に暗号の分野では、特許はしばしばオープン標準化を妨げたり、オープンな標準を展開する人々に不利に働いたりすることがよくあった[Newegg]。標準化されたプロトコルが、他の標準化組織(SDO)が作成した仕様に規範的に依存しており、その仕様が自由に利用できない場合は、この例外となることがある。オープン標準や他の標準への規範的な参照における特許は、特許の開示[Note-well]、ロイヤリティフリーのライセンス[Patent-policy]、または公正で合理的かつ非差別的な条件の他の形態を取るべきである。
例: [RFC6108]は、インターネット・サービス・プロバイダ(ISP)であるComcastが導入した、ウェブブラウザに重要なエンドユーザ通知を提供するシステムについて説明している。このような通知システムは、トラフィックがマルウェアやウイルスの感染の兆候を示すパターンを示していることを警告するなど、カスタマにほぼ即時の通知を提供するために使用されている。このような通知を実行できる独自のシステムは他にもあるが、それらのシステムはディープ・パケット・インスペクション(DPI)技術を利用している。対照的に、この文書では、DPIに依存せず、オープンなIETF標準とオープンソースのアプリケーションに基づくシステムについて説明している。
影響:
- 表現の自由の権利
- 文化生活・芸術・科学への参加の権利
4.8. ヘテロジェナイティーのサポート (Heterogeneity Support)
課題: プロトコルは設計上、ヘテロジェナイティーをサポートしているか? そのプロトコルは複数の種類のハードウェアをサポートしているか? プロトコルは、複数のタイプのアプリケーション・プロトコルを許容しているか? そのプロトコルは、何を受信し、何を処理するかについて自由であるか? コンテキストが変わっても、プロトコルは使用可能でオープンなままか?
説明: インターネットは、デバイス、ノード、ルータのスケジューリング・アルゴリズム、キュー管理メカニズム、ルーティング・プロトコル、多重化のレベル、プロトコルのバージョンと実装、トラフィック・ミックス、時間や場所による輻輳レベルにおける基礎となるリンク層(例えば、ポイントツーポイント、マルチアクセス・リンク、ワイヤレス、ファイバ分散型データ・インタフェース(FDDI)など)など、さまざまなレベルで異種性を特徴とする。さらに、インターネットは、それぞれが独自のポリシー上の懸念事項を持つ自律的な組織とISPで構成されているため、管理領域と料金体系には大きな異種性がある。その結果、[RFC1958]で提案されている異種性の原則を設計でサポートする必要がある[FIArch]。
プロトコルにおける異種性サポートにより、さまざまなデバイス(ひいてはユーザ)がネットワークに参加できるようになる。
例: ヘテロジェナイティーはインターネット・アーキテクチャの成功に大きく貢献した[Zittrain]。ニールス・ボーアの名言に、「予測は難しい。特に未来のこととなると。」というものがある。これは、インターネット・アーキテクチャとインフラの将来的な利用にも当てはまる。したがって、経験則として、さまざまなデバイスや用途に合わせて、特にスタックの下位層部分では、可能な限りプロトコルを設計することが重要である。しかし、そうしない場合は、その理由を文書化することが必要である。
影響:
- 表現の自由の権利
- 政治参加の権利
4.9. 適応性 (Adaptability)
課題: プロトコルはモジュール方式で記述されており、拡張性を促進しているか、あるいは妨げているか? この意味で、プロトコルはパーミッションレス・イノベーションに影響を与えるか? (セクション4.7 (「オープン標準」)を参照。)
説明: 適応性は、パーミッションレス・イノベーションと密接に関連している。どちらも、現在存在する通信構造の上に新しいプロトコルを作成し、展開する自由と能力を維持している。これは、私たちが知っているインターネットの核心であり、インターネットの基本的にオープンな性質を維持するために、私たちはインターネットが発展し続けることができるよう、パーミッションレス・イノベーションを維持または削減させるプロトコルの影響を留意する必要がある。
適応性とパーミッションレス・イノベーションは、ユーザ・グループの好みに応じて情報ネットワークを形成するために使用することができる。さらに、適応性の前提条件となるのは、ネットワークを適応させることができる人々が、ネットワークを認識して理解できる能力である。適応性とパーミッションレス・イノベーションは、ネットワークの利用者がどのように集まり、協力し、表現するかを決めることができるようにするため、教育の権利、科学の権利、集会・結社の自由の権利、表現の自由の権利と本質的に結びついている。
例: WebRTCは音声や動画データを生成する。WebRTCはさまざまな場所でさまざまな関係者が使用することができる。WebRTCの標準アプリケーション・プログラミング・インタフェース(API)は、さまざまな音声サービス・プロバイダのアプリケーションをサポートするために開発されている。複数の関係者が同様の機能を持つことになる。すべての関係者が既存の標準の上に構築できるようにするには、これらの標準が適応可能で、パーミッションレス・イノベーションを可能にする必要がある。
影響:
- 教育を受ける権利
- 科学への参加の権利
- 表現の自由の権利
- 集会及び結社の自由に対する権利
4.10. 完全性 (Integrity)
課題: プロトコルは、ペイロード・データの正確性を維持、保証、検証しているか? プロトコルはデータの一貫性を維持し、保証しているか? そのプロトコルは、何らかの方法でデータが(意図的または意図せずに)改ざんを許容するか?
説明: 完全性とは、データが(意図的または意図せずに)改ざんされていないことを保証するため、データの正確性と一貫性を維持・保証することを指す。
例: データの完全性検証は、オンパス攻撃者からの脆弱性や攻撃を防ぐために重要である。このような攻撃は、第三者が(多くの場合、悪意を持って)2者間の通信を傍受し、その間に割って入り、データの内容を変更することで発生する。実際には、以下のようになる:
アリスはボブと通信したいと考えている。アリスはボブにメッセージを送信するが、コリンがそれを傍受して変更する。ボブはアリスからのデータがコリンによって改ざんされたことを知ることができない。コリンはアリスとボブの間で送信される通信を傍受して改ざんする。コリンは通信内容をコントロールできる。
影響:
- 表現の自由の権利
- 安全を求める権利
4.11. 真正性 (Authenticity)
課題: 一つのデータやエンティティの属性の真正性を確認するのに十分な手段があるか? 途中で属性が文字化けしないか(セクション4.13 (「セキュリティ」)を参照)? 該当する場合、IPsec、DNSセキュリティ(DNSSEC)、HTTPS、その他の標準的なセキュリティのベスト・プラクティスを実装しているか?
説明: 真正性は、データが実際にその発信元から来たと主張するものであることを保証する。これは、特定の攻撃やデータの不正アクセスや使用を防ぐために重要である。
同時に、ベンダー・ロックインやデジタル著作権管理でよく行われるように、異種性サポートを防ぐ方法として認証を使用すべきではない。
例: データの認証は、オンパス攻撃者からの脆弱性や攻撃を防ぐために重要である。このような攻撃は、第三者が(多くの場合は悪意を持って)2者間の通信を傍受し、間に割って入り、両者を装うときに発生する。実際には、以下のようになる:
アリスはボブと通信したいと考えている。アリスはボブにデータを送信する。コリンはボブに送信されたデータを傍受する。コリンはボブへのメッセージを読む(場合によっては改ざんする)。ボブは、そのデータがアリスからではなくコリンから送信されたものであることを認識できない。
適切な認証があれば、シナリオは以下のようになる:
アリスはボブと通信したいと考えている。アリスはボブにデータを送信する。コリンはボブに送信されたデータを傍受し、そのメッセージを読み、改ざんする。ボブはそのデータがアリスから送信されたものかどうか検証できない。
影響:
- プライバシーの権利
- 表現の自由の権利
- 安全を求める権利
4.12. 機密保持 (Confidentiality)
課題: プロトコルは、ネットワーク経由で送信されたデータを公開するか? プロトコルは、識別子やデータに関連する情報を公開しているか? もしそうなら、プロトコルの各エンティティ(つまり、受信者、中間者、イネイブラー)[RFC6973]に何を公開するのか? プロトコルの実装者が、各エンティティと共有する情報を制限するために選択できるオプションは何か? 各エンティティと共有される情報を制限するために、どのような運用管理が利用できるか?
個人データや識別子がプロトコルを介して共有されたり、公開されたりする前に、プロトコルはどのような制御や同意メカニズムを定義したり要求するか? そのようなメカニズムや制御が規定されていない場合、制御や同意はプロトコルの外部で処理されることが想定されているか?
プロトコルは、イニシエータがさまざまな情報をさまざまな受信者と共有する方法を提供しているか? そうでない場合、イニシエータにそのような制御を提供するためのプロトコルの外部にメカニズムが存在するか?
プロトコルは、個人データの収集、使用、開示に関して、イニシエータが受信者または中間者に対して、個人の好みの共有または表明を制限する方法を提供しているか? そうでない場合、利用者にそのような制御を提供するメカニズムがプロトコルの外部に存在するか? 利用者は、これらの中間者を運営する人々との間で、情報の利用を管理する関係(契約上またはそれ以外の関係)を持つことが想定されているか? そのプロトコルは、平文操作よりも暗号化を優先するか?
説明: 機密性とは、意図しないリスナーからデータを秘密にすることを指す[RFC3552]。インターネットの成長は、ネットワークが個人データを保護するという確信をユーザが持てるかどうかにかかっている[RFC1984]。広範囲にわたる監視やサーベイランスの可能性は利用者の信頼を損ない、機密性を確保することで軽減することができる。つまり、受動的な攻撃者は、プロトコルの活動の観察や推測からほとんど、あるいはまったく情報を取得できないようにする必要がある[RFC7258] [RFC7624]。
例: ペイロードを暗号化しないプロトコルは、通信内容全体がそのパスに沿って、理想的な攻撃者が利用できるようになる。[RFC3365]のアドバイスに従い、そのようなプロトコルのほとんどは、機密性を確保するためにペイロードを暗号化する安全なバリアントを備えており、これらの安全なバリアントはますます広く展開されている。注目すべき例外は、DNS[RFC1035]で、DNSSEC[RFC4033]は機密性が要件としていない。このことは、 DNS over TLS [RFC7858]やDNS over HTTPS [RFC8484]のような最近の標準を使用しない限り、あらゆるプロトコルの活動によって生成されたすべてのDNSクエリと応答を、攻撃者が利用可能になることを意味する。ストア・アンド・フォワード・プロトコル(SMTP [RFC5321]など)を使用する場合、アプリケーション層プロトコルによってエンドツーエンドでデータが暗号化されるか、実装がこのデータの暗号化されたストアを使用しない限り、中間者はこのデータを、これらの中間者を侵害した攻撃者による監視の対象として残ることになる[RFC7624]。
影響:
- プライバシーの権利
- 安全を求める権利
4.13. 安全 (Security)
課題: 「安全に関する考慮事項に対するRFC文書作成ガイドライン」 [RFC3552]を読んだか? プロトコル/仕様に多少関連しているものの、文書の範囲外と考えられる攻撃を見つけたか? これらの攻撃は、(この文書全体で説明しているように)インターネットの人権を実現する機能に関連するものか?
説明: 安全は、プロトコルやシステムの単一のモノリシックな特性ではなく、むしろ関連性がありながらもある程度独立した一連の特性である。これらの特性のすべてが、すべてのアプリケーションに要求さらるわけではない。通信はシステムによって実行され、システムへのアクセスは通信チャネルを介して行われるため、セキュリティの目標は明らかに連動しているが、独立して提供することもできる[RFC3552]。
一般的に、インターネット上で動作するプロトコルは、受動的攻撃(攻撃者がネットワーク上のパケットにアクセスして読み取ることができる場合)と能動的攻撃(攻撃者がネットワーク・パケットに情報を書き込むことができる場合)の標的になる可能性がある[RFC3552]。
例: [RFC3552]を参照のこと。
影響:
- 表現の自由の権利
- 集会及び結社の自由に対する権利
- 差別を受けない権利
- 安全を求める権利
4.14. プライバシー (Privacy)
課題: 「インターネット・プロトコルのプライバシーに関する考慮事項」[RFC6973]のセクション7に記載されているガイドラインを読んだことはあるか? プロトコルはメタデータの機密性を保持しているか? プロトコルはトラフィック分析に対抗できるか? プロトコルはデータ最小化の原則に準拠しているか? プロトコルが記録する潜在的に機密性の高いデータや、技術的な理由でそれがどのくらい保持する必要があるかを、文書は明記されているか?
説明: プライバシーとは、エンティティ(通常は個人)が自らの利益のために行動し、そのエンティティが自分の個人情報を他者と共有する意思の程度を含め、その環境とやりとりする程度を決定する権利を指す[RFC4949]。プロトコルが不十分なプライバシー保護を提供する場合、利用者が監視を恐れて自己検閲したり、自由に自己表現できないと感じたりするため、表現の自由に悪影響を及ぼす可能性がある。
例: [RFC6973]を参照のこと。
影響:
- 表現の自由の権利
- プライバシーの権利
- 差別を受けない権利
4.15. 匿名性と仮名性 (Anonymity and Pseudonymity)
課題: プロトコルは識別子を利用しているか? これらの識別子は永続的か? 複数のコンテキストで使用されているか? プロトコルの動作に悪影響を与えることなく、利用者が識別子をリセットしたり、ローテーションしたりすることは可能か? 識別子はプロトコルのエンドポイント以外からも見えるようになっているか? 識別子は現実世界のアイデンティティと結び付いているか? 「インターネット・プロトコルのプライバシーに関する考慮事項」[RFC6973]、特にセクション6.1.2を考慮したか?
説明: ほとんどのプロトコルは、時間的・空間的なアクティビティを相関させるために、何らかの識別子の使用に依存している。例えば:
- IPアドレスは、IPデータグラムの送信元と宛先の識別子として使用される。
- QUIC接続識別子は、同じ接続に属するパケットを関連付けるために使用される。
- HTTPは、同じクライアントからの複数のHTTPリクエストを関連付けるためにCookieを使用する。
- 電子メールでは、送信者と受信者を識別するために、example@example.comという形式の電子メール・アドレスを使用する。
一般的に、これらの識別子はプロトコル運用の継続性を維持するために必要な機能を果たす。しかし、これらはプライバシーのリスクを生むこともある。そのリスクが顕在化する主な方法は2つある:
- E.164(電話)番号がインスタント・メッセージング・システムの識別子として使用される場合のように、識別子自体が何らかの方法で利用者の身元を明らかにするか、または明らかにする識別子に結び付けられる可能性がある。
- 識別子は利用者の身元を明らかにしないかもしれないが、HTTPクッキーの場合のように、利用者のプライバシーを脅かすのに十分な利用者の行動を結び付けることを可能にするかもしれない。
識別子はプロトコルの動作に必要であるため、真の匿名性を実現することは非常に困難だが、識別子を使用する場合でも利用者のプライバシーを促進する慣行がある。
影響:
- 差別を受けない権利
- 表現の自由の権利
- 政治参加の権利
- 集会及び結社の自由に対する権利
4.15.1. 仮名性 (Pseudonymity)
一般的に、識別子が仮名(利用者の現実世界でのアイデンティティに結び付けられていない)である方が、利用者のプライバシーはより適切に保護される。
例: IPv6プロトコルの開発では、一意のIPアドレスにメディア・アクセス制御(MAC)アドレスを埋め込むことが議論された。これにより、盗聴者やその他の情報収集者は、異なるトランザクションで使用された異なるアドレスが、実際には同じノードに対応していることを識別できるようになる。これが、「IPv6のステートレス・アドレス自動構成のための一時アドレス拡張」[RFC8981]やMACアドレスのランダム化[MAC-ADDRESS-RANDOMIZATION]のような標準化の取り組みが進められてきた理由である。
永続的な識別子から仮名を作成しようとすることは、しばしば魅力的であることに留意する。これは、永続的な識別子を復元できないような方法で正しく実行するのが非常に難しい場合がある。
例: ウェブ追跡でよく行われるのは、メール・アドレスをハッシュ化することで「暗号化」し、「個人を特定できない」ようにすることである。しかし、ハッシュ関数は公開操作であるため、メール・アドレスの候補を辞書で検索して元のアドレスを復元することができる[Email-hashing]。
4.15.2. リンク不可能性 (Unlinkability)
真の仮名識別子であっても、それが十分に広い範囲で使用される場合、プライバシー・リスクがもたらす可能性がある。識別子が時間的にも空間的にも限定された範囲であれば、利用者のプライバシーはより適切に保護される。
例: 一例として、動的ホスト構成プロトコル(DHCP)がある。DHCPでは、永続的な識別子をクライアント名として送信することは必須ではないが、実際には、DHCP以前にも多くの実装で行われていた[RFC7844]。
例: HTTPのサードパーティCookieは、トラッカーがサイト間のHTTPトラフィックを相関させることができる。これは、ウェブ・トラッキングのエコシステム全体の基盤である。ウェブ・ブラウザは、利用者のプライバシーを保護するために、サードパーティCookie の使用を制限する傾向が強まっている。
4.16. 検閲耐性 (Censorship Resistance)
課題: プロトコル・アーキテクチャは検閲し易くするか? 検閲に使い易い「チョーク・ポイント」を含んでいるか? 特定の種類のトラフィックを選択的にブロックするために使用できる識別子を公開しているか? 検閲に強いように設計しているか? プロトコルは、リソースへのアクセスが制限されている場合、なぜ制限されているのか、その理由を明確にあるいは透明にしているか?
説明: 政府やサービス・プロバイダは多くの場合、エンドユーザに知られることなく、コンテンツやトラフィックをブロックしたり、フィルタリングしたりする[RFC7754]。世界中で採用されている検閲手法の調査については、情報へのアクセスを検閲するために悪用されてきたプロトコルの特性を示した[RFC9505]を参照のこと。検閲耐性とは、インターネット検閲を防ぐ方法と手段を指す。
例: 現在のウェブのデザインには、検閲者が介入できるアーキテクチャ上のチョーク・ポイントが多数ある。これには、ドメイン名自体の制御の取得、プロトコル層またはリゾルバでのDNSブロッキング、IPアドレスのブロッキング、ウェブサーバでのブロッキングなどがある。検閲耐性を高めることを目的としたコンテンツ配信システムについては、広範囲にわたる作業が行われており、BitTorrentなどの一部のシステムが広く使われている。しかし、これらのシステムは、ウェブと比較して信頼性や性能が劣っている可能性がある(例えば、サーバ上のアクティブ・コンテンツをサポートしていない)。
例: プロトコル内で公開されているコンテンツ識別子は、検閲者がどのトラフィックをブロックするかを決定できるようにすることで、検閲を容易にするために使用されるかもしれない。DNSクエリ、HTTPリクエストの「host」リクエスト・ヘッダ、トランスポート層セキュリティ (TLS)のClientHelloのServer Name Indication(SNI)はすべて、平文で送信され、利用者がアクセスしようとしているコンテンツを識別するために検閲者が使用できるプロトコル要素の例である[RFC9505]。Encrypted ClientHello[TLS-ESNI]やDNS over HTTPS[RFC8484]のようなメタデータを暗号化するプロトコル・メカニズムは、このタイプのプロトコル検査に対してある程度の耐性を提供する。Tor <https://torproject.org>のような完全なトラフィック暗号化システムも、検閲されているリソースにアクセスするために使用できる。
例: 上で述べたように、ウェブトラフィックを検閲する一つの方法は、サーバにトラフィックをブロックするように要求するか、ISPにサーバへのリクエストをブロックするように要求することである。HTTPでは、アクセスの拒否や制限はステータス・コード451の使用によって明らかにすることができる。これは、法律や公共政策の問題が運用に影響する状況において、サーバ ・オペレータや中間者がより透明性を持って運用できるようになる[RFC7725]。プロトコルが検閲を可能にする可能性がある場合、プロトコルの設計者は、エンドユーザにとっての曖昧さを最小限に抑えるために、さまざまなシナリオ(例えば、管理ポリシーによってブロックされた、法的要件により利用できないなど)を捕捉するエラーコードを作成するように努力する必要がある。
影響:
- 表現の自由の権利
- 政治参加の権利
- 文化生活・芸術・科学への参加の権利
- 集会及び結社の自由に対する権利
4.17. 結果の透明性 (Outcome Transparency)
課題: プロトコルの意図する効果、予測される効果は文書化され、容易に理解できるか? プロトコルの中心的なユースケースについて、想定される動作と、それが他のプロトコル、実装、ユーザの期待や動作にどのような影響を与えるか、あるいは与えないかを明確に説明しているか? 同様の問題を解決したり、同様のメカニズムを使用したりした他のプロトコルをレビューし、それらの使用と誤用から学べる教訓があるかどうかを確認したか?
説明: ある種の技術的選択は、意図しない結果が生じるかもしれない。
例: 真正性の欠如は、完全性の欠如や負の外部性につながる可能性がある。その一例がスパムである。課金や会計に使用できるデータの欠如は、実際のコストやコスト配分が不明瞭になるいわゆる「無料」の取り決めにつながる可能性がある。例えば、インターネットの相互接続でよく使われる物々交換の取り決めや、検索エンジンやソーシャル・ネットワークなどのいわゆる「無料」サービスの最も一般的な資金調達モデルであるターゲット広告のための個人データの商業的利用などである。予期しない結果は、技術的なものではなく、むしろアーキテクチャ、社会的、経済的なものかもしれない。したがって、意図された結果や、検討された他の可能性のある結果を文書化することが重要である。
影響:
- 表現の自由の権利
- プライバシーの権利
- 集会及び結社の自由に対する権利
- 情報へのアクセスの権利
4.18. アクセシビリティ (Accessibility)
課題: プロトコルは、すべての人に利用可能な環境を提供するように設計されているか? 例やガイダンスについては、W3Cウェブ・アクセシビリティ・イニシアティブ[W3CAccessibility]を参照したか?
説明: プロトコル、ウェブサイト、ウェブテクノロジ、ウェブツールの設計では、ウェブの利用を妨げる障壁が作られることがある。インターネットは、ハードウェア、ソフトウェア、言語、文化、場所、身体的・精神的能力に関係なく、すべての人々が利用できるように設計する必要がある。インターネット・テクノロジがこの目標を達成すれば、聴覚、運動能力、視覚、認知能力など、さまざまな人々がアクセスできるようになる[W3CAccessibility]。
例: [HTML]で定義されているHTMLプロトコルは、ウェブページ内の非テキスト・コンテンツを解読できない人にとって、画像がアクセシブルであることを保証するために、すべての画像に alt属性(いくつかの例外を除く)を設定することが明示的に要求されている。
もう1つの例としては、IETFのAVTおよびAVTCOREワーキンググループで行われた作業があり、マルチメディア、テキスト電話、ワイヤレス・マルチメディア、手話や読唇術のためのビデオ通信におけるテキスト会話を可能にする作業がある(つまり、[RFC9071])。
影響:
- 差別を受けない権利
- 集会及び結社の自由に対する権利
- 教育を受ける権利
- 政治参加の権利
4.19. 非中央集権化 (Decentralization)
課題: プロトコルは、単一の管理ポイントなしで実装できるか? 該当する場合、そのプロトコルはフェデレーション方式で展開できるか? そのプロトコルは追加の集中管理ポイントを生み出すか?
説明: 非中央集権化は、インターネットのアーキテクチャの中心的な技術概念の1つであり、IETFによってそのように受け入れられている[RFC3935]。これは、集中化された管理ポイントが存在しない、または最小限に抑えられていることを指し、この機能により、新しい利用者が参加しやすくなり、新しい用途が展開しやすくなると考えられている[Ziewitz]。また、単一障害点に関する問題が軽減され、1つまたは複数のノードが無効になってもネットワークが機能し続けるように分散化される。1990年代初頭にインターネットが商用化されると、分散型インターネットの技術的な利点が損なわれ、分散化から徐々に遠ざかっていった。このトピックの詳細な議論については、[Arkko]を参照のこと。
例: インターネットを行き交うビットは、政府やISPだけでなく、(悪意のある)第三者による監視や検閲の影響を受けやすくなっている。監視や検閲の能力は、ネットワークの集中化が進み、侵入可能な中央インフラ・ポイントが形成されることによって、さらに高まっている。ピアツーピア・ネットワークの構築や、スケーラビリティのために分散ハッシュ・テーブル(DHT)と組み合わせたピアツーピア技術を使用したVoice-over-IPプロトコルの開発は、プロトコルが分散化を維持できる方法の例である[Pouwelse]。
影響:
- 表現の自由の権利
- 集会及び結社の自由に対する権利
4.20. 救済策 (Remedy)
課題: プロトコルは、他の当事者の人権、特にプライバシー権に不釣り合いな影響を与えることなく、悪影響を受けた当事者の救済の権利を促進することができるか?
説明: 国家と企業による救済へのアクセスを提供することは、国連のビジネスと人権に関する指導原則[UNGP]の一部である。救済へのアクセスは、人権侵害の被害者が正義を求めたり、法執行機関が潜在的な違反者を特定できるようするのに役立つかもしれない。ただし、個人への「帰属」を可能にしようとするプロトコルの現在のメカニズムは、プライバシー権の行使を妨げている。元国連表現の自由特別報告者も、匿名性は表現の自由に固有のものであると主張している[Kaye]。プライバシーの権利と表現の自由に対する帰属の潜在的な悪影響を及ぼす可能性があることを考慮すると、個人レベルでの帰属を可能にすることは、人権と矛盾する可能性が高い。
例: 人権救済を可能にする手段として、個人を特定できる情報をデータ・ストリームに追加することは、人権侵害者を特定し、救済へのアクセスを提供するのに役立つかもしれないが、これはすべての利用者のプライバシー、匿名表現、結社の権利に不釣り合いな影響を与えるだろう。さらに、エンドツーエンドの暗号化メッセージング・システムで不正使用を検出できるようにする最近の進歩も見られるが、これもまた利用者のプライバシーに何らかのリスクをもたらす[Messenger -franking] [Hecate]。¶
影響:
- 救済を受ける権利
- 安全を求める権利
- プライバシーの権利
4.21. 他の考慮事項
課題: プロトコルや文書がもたらす可能性のある潜在的な悪影響(個人または社会)を考慮したか?
説明: 特定のステータスで特定のRFCを公開すると、結果が伴う。標準化過程の一部としてインターネット標準として公開することは、実装者に対して、仕様が一定レベルの成熟度、運用経験、コンセンサスを持っていることを示すことができる。同様に、標準化過程の一部ではない実験的な文書として仕様を公開することは、その文書が「インターネット標準になることを意図していないか、最終的な標準化を意図しているが、まだ広く展開する準備ができていない」ことをコミュニティに知らせることになる[RFC2026]。展開の範囲、結果としてエンドユーザへの全体的な影響は、RFCで提示される文書のステータスによって異なる。より詳しい説明は、 [RFC2026]とその更新を参照のこと。
5. 文書のステータス
この研究グループの文書は、ネットワーク・プロトコル、アーキテクチャ、他のインターネット草案のRFCの人権レビューのためのベスト・プラクティスとガイドラインを示すものである。
6. セキュリティに関する考慮事項
「世界人権宣言」の第3条には、「すべての人は、生命、自由および身体の安全に対する権利を有する」[UDHR]とある。この条文は、セキュリティの重要性、人間の生命と自由との相互関係を強調しているが、人権は不可分であり、相互に関連し、依存し合っているため、セキュリティは他の人権や自由とも密接に結びついている。この文書は、これらの概念をインターネット・プロトコルとアーキテクチャ開発で使用される概念と慣行に関連付け、翻訳することによって、人権、自由、セキュリティを強化することを目指している。その目的は、人権を保護し、それによってネットワークの持続可能性、使いやすさ、有効性を向上させることにある。本文書は、この文書のセクション3で行われるようなガイドラインを提供することで、これを実現しようとするものである。
7. IANAに関する考慮事項
本文書にはIANAのアクションはない。
8. 研究グループの情報
IRTF人権プロトコル検討研究会の議論リストは、電子メール・アドレス<mailto:hrpc@ietf.org>にある。
グループに関する情報やメーリングリストの登録方法に関する情報は、<https://www.irtf.org/mailman/listinfo/hrpc>にある。
リストのアーカイブは、<https://mailarchive.ietf.org/arch/browse/hrpc/>にある。
9. 参考文献
[Arkko] Arkko, J., Trammell, B., Nottingham, M., Huitema, C., Thomson, M., Tantsura, J., and N. ten Oever, "Considerations on Internet Consolidation and the Internet Architecture", Work in Progress, Internet-Draft, draft-arkko-iab-internet-consolidation-02, 8 July 2019, <https://datatracker.ietf.org/doc/html/draft-arkko-iab-internet-consolidation-02>.
[Email-hashing] Acar, G., Englehardt, S., and A. Narayanan, "Four cents to deanonymize: Companies reverse hashed email addresses", April 2018, <https://freedom-to-tinker.com/2018/04/09/four-cents-to-deanonymize-companies-reverse-hashed-email-addresses/>.
[FIArch] Papadimitriou, D., Zahariadis, T., Martinez-Julia, P., Papafili, I., Morreale, V., Torelli, F., Sales, B., and P. Demeester, "Design Principles for the Future Internet Architecture", The Future Internet, pp. 55-67, DOI 10.1007/978-3-642-30241-1_6, January 2012, <https://link.springer.com/chapter/10.1007/978-3-642-30241-1_6>.
[FREAK] University of Michigan, "Tracking the FREAK Attack", Wayback Machine archive, March 2015, <https://web.archive.org/web/20150304002021/https://freakattack.com/>.
[Hecate] Issa, R., Alhaddad, N., and M. Varia, "Hecate, Abuse Reporting in Secure Messengers with Sealed Sender", 31st USENIX Security Symposium (USENIX Security 22), pp 2335-2352, August 2022, <https://www.usenix.org/conference/usenixsecurity22/presentation/issa>.
[Hill] Hill, R., "Partial Catalog of Human Rights Related to ICT Activities", May 2014, <http://www.apig.ch/UNIGE Catalog.pdf>.
[HR-RT] "IRTF-HRPC / reviews", commit 3f5fbff, December 2020, <https://github.com/IRTF-HRPC/reviews>.
[HTML] WHATWG, "HTML Living Standard", August 2024, <https://html.spec.whatwg.org/multipage/>.
[HTTPS-interception] Durumeric, Z., Ma, Z., Springall, D., Barnes, R., Sullivan, N., Bursztein, E., Bailey, M., Halderman, J., and V. Paxson, "The Security Impact of HTTPS Interception", NDSS Symposium 2017, DOI 10.14722/ndss.2017.23456, February 2017, <https://doi.org/10.14722/ndss.2017.23456>.
[ICCPR] United Nations General Assembly, "International Covenant on Civil and Political Rights", December 1966, <https://www.ohchr.org/en/instruments-mechanisms/instruments/international-covenant-civil-and-political-rights>.
[ICESCR] United Nations General Assembly, "International Covenant on Economic, Social and Cultural Rights", December 1966, <https://www.ohchr.org/en/instruments-mechanisms/instruments/international-covenant-economic-social-and-cultural-rights>.
[IRP] Internet Rights and Principles Dynamic Coalition, "10 Internet Rights & Principles", <https://internetrightsandprinciples.org/campaign/>.
[Jorgensen] Jørgensen, R. F., "An internet bill of rights", Research Handbook on Governance of the Internet, edited by Ian Brown. Cheltenham: Edward Elgar Publishing, DOI 10.4337/9781849805025.00022, April 2013, <https://doi.org/10.4337/9781849805025.00022>.
[Kaye] Kaye, D., "Report of the Special Rapporteur on the Promotion and Protection of the Right to Freedom of Opinion and Expression, David Kaye", A/HRC/29/32, May 2015, <https://digitallibrary.un.org/record/798709?v=pdf>.
[Logjam] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., Green, M., Halderman, J., Heninger, N., Springall, D., Thomé, E., Valenta, L., VanderSloot, B., Wustrow, E., Zanella-Béguelin, S., and P. Zimmerman, "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice", CCS '15: Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pp 5-17, DOI 10.1145/2810103.2813707, October 2015, <https://doi.org/10.1145/2810103.2813707>.
[MAC-ADDRESS-RANDOMIZATION] Zúñiga, J. C., Bernardos, C. J., Ed., and A. Andersdotter, "Randomized and Changing MAC Address State of Affairs", Work in Progress, Internet-Draft, draft-ietf-madinas-mac-address-randomization-15, 15 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-madinas-mac-address-randomization-15>.
[Messenger-franking] Grubbs, P., Lu, J., and T. Ristenpart, "Message Franking via Committing Authenticated Encryption", Cryptology ePrint Archive, Paper 2017/664, July 2017, <https://eprint.iacr.org/2017/664>.
[Newegg] Mullin, J., "Newegg on trial: Mystery company TQP rewrites the history of encryption", Ars Technica, November 2013, <https://arstechnica.com/tech-policy/2013/11/newegg-on-trial-mystery-company-tqp-re-writes-the-history-of-encryption/>.
[Note-well] IETF, "Note Well", <https://www.ietf.org/about/note-well/>.
[Orwat] Orwat, C. and R. Bless, "Values and Networks: Steps Toward Exploring their Relationships", ACM SIGCOMM Computer Communication Review, vol. 46, no. 2, pp 25-31, DOI 10.1145/2935634.2935640, May 2016, <https://doi.org/10.1145/2935634.2935640>.
[Patent-policy] Weitzner, D., "W3C Patent Policy", W3C Recommendation, February 2004, <https://www.w3.org/Consortium/Patent-Policy-20040205/>.
[Penney] Penney, J., "Chilling Effects: Online Surveillance and Wikipedia Use", Berkeley Technology Law Journal, vol. 31, no. 1, pp 117-182, DOI 10.15779/Z38SS13, September 2016, <https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2769645>.
[Pouwelse] Pouwelse, J., Ed., "Media without censorship (CensorFree) scenarios", Work in Progress, Internet-Draft, draft-pouwelse-censorfree-scenarios-02, 22 October 2012, <https://datatracker.ietf.org/doc/html/draft-pouwelse-censorfree-scenarios-02>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, <https://www.rfc-editor.org/info/rfc1958>.
[RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic Technology and the Internet", BCP 200, RFC 1984, DOI 10.17487/RFC1984, August 1996, <https://www.rfc-editor.org/info/rfc1984>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, January 1998, <https://www.rfc-editor.org/info/rfc2277>.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, DOI 10.17487/RFC3365, August 2002, <https://www.rfc-editor.org/info/rfc3365>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, DOI 10.17487/RFC3724, March 2004, <https://www.rfc-editor.org/info/rfc3724>.
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, <https://www.rfc-editor.org/info/rfc3935>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, DOI 10.17487/RFC4101, June 2005, <https://www.rfc-editor.org/info/rfc4101>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. Van Lieu, "Comcast's Web Notification System Design", RFC 6108, DOI 10.17487/RFC6108, February 2011, <https://www.rfc-editor.org/info/rfc6108>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, <https://www.rfc-editor.org/info/rfc6365>.
[RFC6701] Farrel, A. and P. Resnick, "Sanctions Available for Application to Violators of IETF IPR Policy", RFC 6701, DOI 10.17487/RFC6701, August 2012, <https://www.rfc-editor.org/info/rfc6701>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, <https://www.rfc-editor.org/info/rfc7624>.
[RFC7725] Bray, T., "An HTTP Status Code to Report Legal Obstacles", RFC 7725, DOI 10.17487/RFC7725, February 2016, <https://www.rfc-editor.org/info/rfc7725>.
[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. Nordmark, "Technical Considerations for Internet Service Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, March 2016, <https://www.rfc-editor.org/info/rfc7754>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, DOI 10.17487/RFC8179, May 2017, <https://www.rfc-editor.org/info/rfc8179>.
[RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, October 2017, <https://www.rfc-editor.org/info/rfc8280>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", RFC 8558, DOI 10.17487/RFC8558, April 2019, <https://www.rfc-editor.org/info/rfc8558>.
[RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, DOI 10.17487/RFC8890, August 2020, <https://www.rfc-editor.org/info/rfc8890>.
[RFC8980] Arkko, J. and T. Hardie, "Report from the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol Development", RFC 8980, DOI 10.17487/RFC8980, February 2021, <https://www.rfc-editor.org/info/rfc8980>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/info/rfc8981>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[RFC9071] Hellström, G., "RTP-Mixer Formatting of Multiparty Real-Time Text", RFC 9071, DOI 10.17487/RFC9071, July 2021, <https://www.rfc-editor.org/info/rfc9071>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, <https://www.rfc-editor.org/info/rfc9293>.
[RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, July 2023, <https://www.rfc-editor.org/info/rfc9420>.
[RFC9505] Hall, J. L., Aaron, M. D., Andersdotter, A., Jones, B., Feamster, N., and M. Knodel, "A Survey of Worldwide Censorship Techniques", RFC 9505, DOI 10.17487/RFC9505, November 2023, <https://www.rfc-editor.org/info/rfc9505>.
[Saltzer] Saltzer, J. H., Reed, D. P., and D. D. Clark, "End-to-end arguments in system design", ACM Transactions on Computer Systems, vol. 2, no. 4, pp 277-288, DOI 10.1145/357401.357402, November 1984, <https://doi.org/10.1145/357401.357402>.
[TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-20, 4 August 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-20>.
[UDHR] United Nations General Assembly, "Universal Declaration of Human Rights", December 1948, <https://www.un.org/en/about-us/universal-declaration-of-human-rights>.
[UNGP] United Nations, "Guiding Principles on Business and Human Rights: Implementing the United Nations 'Protect, Respect and Remedy' Framework", January 2012, <https://www.ohchr.org/en/publications/reference-publications/guiding-principles-business-and-human-rights>.
[UNHR] United Nations, "The Core International Human Rights Instruments and their monitoring bodies", <https://www.ohchr.org/en/core-international-human-rights-instruments-and-their-monitoring-bodies>.
[UNHRC2016] United Nations Human Rights Council, "The promotion, protection and enjoyment of human rights on the Internet", A/HRC/32/L.20, June 2016, <https://digitallibrary.un.org/record/845728?ln=en>.
[W3CAccessibility] W3C, "Accessibility", <https://www.w3.org/standards/webdesign/accessibility>.
[W3Ci18nDef] Ishida, R. and S. Miller, "Localization vs. Internationalization", December 2005, <https://www.w3.org/International/questions/qa-i18n.en>.
[Ziewitz] Ziewitz, M. and I. Brown, "A Prehistory of Internet Governance", Research Handbook on Governance of the Internet, edited by Ian Brown. Cheltenham: Edward Elgar Publishing, DOI 10.4337/9781849805025.00008, April 2013, <https://doi.org/10.4337/9781849805025.00008>.
[Zittrain] Zittrain, J., "The Future of the Internet and How to Stop It", Yale University Press, 2008, <https://dash.harvard.edu/handle/1/4455262>.
謝辞
- [RFC8280]でのコリーヌ・キャス-スペスの作業に、
- リース・エンハート、ジョー・ホール、アヴリ・ドリア、ジョーイ・サラザール、コリーヌ・キャス-スペス、ファルザネ・バディイ、サンドラ・ブラマン、コリン・パーキンス、ジョン・カラン、エリオット・リア、マロリー・クノデル、ブライアン・トラメル、ジェーン・コフィン、エリック・レスコラ、ソフィア・チェリ、hrpcリストのレビューと提案に、
- 人権に関するレビューを実施し、その作業とフィードバックを提供してくれたアメリア・アンダースドッター、シェーン・カー、ベアトリーチェ・マルティーニ、カラン・サイニ、シバン・コール・サーヒブに、
感謝する:
著者のアドレス
グルシャバード・グローバー
メールアドレス: <gurshabad@cis-india.org>
ニールス・テン・オーヴェル
アムステルダム大学
メールアドレス: <mail@nielstenoever.net>
更新履歴
- 2024.9.16
Discussion