自己レビュー質問票: セキュリティとプライバシー

1. 導入

Webプラットフォームの新機能を設計する際には、 作業のセキュリティおよびプライバシー上の影響を常に考慮しなければなりません。 新しいWeb機能は常に Web全体のセキュリティとプライバシーを 維持または向上させるべきです。

この文書には、 仕様作成者が 自分たちの作業の セキュリティおよびプライバシー上の影響を検討し、 仕様内に含める説明的な「セキュリティ上の考慮事項」および「プライバシー上の 考慮事項」の節を書く際に役立つことを意図した 一連の質問が含まれています。 これは下記の§ 2.16 この仕様には「セキュリティ上の 考慮事項」と「プライバシー上の 考慮事項」の両方の節がありますか？で説明されています。 また、仕様作成者が仕様に取り組む中で遭遇する セキュリティおよびプライバシー上の懸念に対処するために使用できる 緩和戦略も記録しています。

この文書自体も進行中の作業であり、 この文書が（まだ）扱っていない セキュリティまたはプライバシー上の懸念がある可能性があります。 この質問票が尋ねるべき セキュリティまたはプライバシー上の懸念を見つけた場合は、お知らせください。

1.1. 質問票の使い方

設計プロセスの早い段階、 物事を変更しやすい時点で、 これらの質問に取り組んでください。 プライバシーおよびセキュリティの問題が後になって、 機能が出荷された後で初めて見つかった場合、 設計を変更することははるかに困難です。 セキュリティまたはプライバシーの問題が遅れて見つかった場合、 ユーザーエージェントは問題を修正するために 破壊的変更を採用する必要があるかもしれません。

仕様に取り組む間、これらの質問を念頭に置いてください。 定期的にこの質問票を再確認し、質問の検討を続けてください。 特に設計が時間とともに変化する場合はそうです。

1.2. 追加リソース

プライバシーWGが公開した「Web仕様におけるブラウザーフィンガープリンティングの緩和」[FINGERPRINTING-GUIDANCE]文書は、 ブラウザーフィンガープリンティングについて さらに深く掘り下げており、この文書と 並行して検討されるべきです。

プライバシー上の考慮事項に関するIETFのRFC、[RFC6973]は、 特に第7節がすばらしいリソースです。

1.3. TAG、プライバシーWG、セキュリティIG、およびこの質問票

プライバシーワーキンググループおよび セキュリティ関心グループに プライバシーおよび セキュリティレビューを依頼する前に、 § 2.16 この仕様には「セキュリティ上の考慮事項」と「プライバシー上の 考慮事項」の両方の節がありますか？で説明されているように、 文書内に「セキュリティ上の考慮事項」および 「プライバシー上の考慮事項」の節を書いてください。この 文書の質問に答えることで、それらの節を書く際の参考になることを 期待しています。ただし、この質問票を単にそれらの節へコピーすることは 適切ではありません。 セキュリティおよびプライバシーレビューを依頼する手順は、 幅広いレビューの行い方という文書に あります。

技術アーキテクチャグループ（TAG）にレビューを依頼する際は、 この文書の質問に対する回答を TAGに提供してください。そうする際には、この Markdown テンプレートが役立つかもしれません。

2. 検討すべき質問

2.1. この機能はどのような情報を公開し、 どのような目的で公開しますか？

ユーザーエージェントは、明確なユーザーニーズに応えるために必要な場合にのみ、 Webに情報を公開するべきです。 あなたの機能はWebサイトに情報を公開しますか？ もしそうなら、その情報を公開することはユーザーにどのような利益をもたらしますか？ ユーザーへのリスクは、ユーザーへの利益によって上回られていますか？ もしそうなら、どのようにですか？

関連項目

• Web Platform Design Principles § priority-of-constituencies

この質問に答える際には、情報の公開/共有に関する 次の4つの可能な領域をそれぞれ考慮してください。

以下の副質問については、 潜在的に識別可能な情報という用語を、ブラウザーユーザーを説明する情報であり、 同じブラウザーバージョンを使用する他の人とは区別される情報を意味すると 受け取ってください。 そのような潜在的に識別可能な情報の例には、 ブラウザーユーザーの環境（例: オペレーティングシステムの構成、 ブラウザー構成、ハードウェア能力）に関する情報、およびユーザーの過去の活動 や関心（例: 閲覧履歴、購入の好み、個人的 特徴）に関する情報が含まれます。

1. あなたの仕様は、ファーストパーティが現在容易には判断できないどのような情報を ファーストパーティに公開しますか。

2. あなたの仕様は、サードパーティが現在容易には判断できないどのような情報をサード パーティに公開しますか。

3. あなたの仕様は、ファースト パーティがすでにアクセスできるどのような潜在的に識別可能な情報をファースト パーティに公開しますか（すなわち、あなたの仕様はどのような 識別情報を複製または反映しますか）。

4. あなたの仕様は、サード パーティがすでにアクセスできるどのような潜在的に識別可能な情報をサード パーティに公開しますか。

2.2. あなたの仕様の機能は、意図した機能を実装するために必要な 最小限の情報を公開していますか？

機能は、絶対に必要な場合にのみ 情報を公開するべきです。 ある機能が必要以上の情報を公開する場合、 なぜそうするのですか。また、より少ない情報を公開することで 同じ機能を実現できますか？

関連項目

• § 4.1 データ最小化

Content Security Policy [CSP]は、 違反レポートを通じてあるオリジンが別のオリジンに関する詳細を推測できるようにすることで、 リダイレクト先を意図せず クロスオリジンに公開しました（[HOMAKOV]を参照）。ワーキンググループは最終的に、 リダイレクト後にポリシーの粒度を下げることで リスクを緩和しました。

2.3. あなたの仕様の機能は、個人情報、 個人を特定できる情報（PII）、または そのいずれかから派生した情報を公開しますか？

個人情報とは、ユーザーに関するあらゆるデータ （たとえば自宅住所）、 またはユーザーを識別するために使用できる情報、 たとえば別名、メールアドレス、識別番号などです。

注: 個人情報は、 個人を特定できる情報 （PII）とは異なります。 PIIは法的概念であり、 その定義は法域によって異なります。 法的ではない文脈で使用される場合、 PIIは一般に、 ユーザーを識別するために使用できる 情報を指す傾向があります。

個人情報、PII、または派生情報を 公開する場合、 仕様作成者は、ユーザーへの潜在的な害を 防止しなければならず、また防止が不可能な場合は最小化しなければなりません。

認証のために 生体認証データ （指紋や網膜スキャンなど）を収集する機能は、 この生体認証データをWebに直接公開するべきではありません。 代わりに、 その生体認証データを使用して、 オリジン間で共有されない一時的なキーを検索または生成し、 それを安全にオリジンへ公開することができます。 [WEBAUTHN]

個人情報、PII、またはそれらの派生物は、 意味のあるユーザー同意なしに オリジンへ公開されるべきではありません。 多くのAPIは、 意味のあるユーザー同意を取得するためにPermissions APIを使用します。 [PERMISSIONS]

Webプラットフォームに 追加される各権限プロンプトは、 ユーザーがすべての権限プロンプトの内容を無視する リスクを高めることを 念頭に置いてください。 権限プロンプトを追加する前に、 意味のあるユーザー同意を得るための、より目立たない方法を使用する 選択肢を検討してください。 [ADDING-PERMISSION]

<input type=file>は、 個人情報を含む文書を Webサイトにアップロードするために使用できます。 これは、 下位のネイティブプラットフォームのファイルピッカーを利用して、 別個の権限プロンプトなしに、 ファイルとその内容が Webサイトへ公開されることを ユーザーが理解できるようにします。

関連項目

• § 4.3 明示的なユーザー仲介

• Web Platform Design Principles § consent

2.4. あなたの仕様の機能は機微情報をどのように扱いますか？

機微情報は個人情報だけではありません。 他にも多くの種類の情報が機微情報になり得ます。 何が機微情報であるか、またはそうでないかは、 人によって あるいは場所によって異なり得ます。 ある人または人々の集団について知られても無害な情報が、 別の人または集団について知られると危険である可能性があります。 ある国では無害な個人に関する情報が、 別の国ではその人を拘束、誘拐、または投獄するために 使用される可能性があります。

機微情報の例には、 カースト、 市民権、 肌の色、 資格情報、 犯罪歴、 人口統計情報、 障害の状態、 雇用状態、 民族性、 金融情報、 健康情報、 位置データ、 婚姻状況、 政治的信条、 職業、 人種、 宗教的信条または無信仰、 性的嗜好、 および トランスジェンダーであることの状態が含まれます。

機能が機微情報をWebに公開する場合、 その設計者は、 情報を公開するリスクを緩和するための 手段を講じなければなりません。

位置情報を必要とする多くのユースケースは、 非常に粗い位置データで 十分に満たすことができます。 たとえば、 レストランを推薦するサイトは、 ユーザーの正確な位置を公開する代わりに 市区町村レベルの位置情報で ユーザーに十分なサービスを提供できるでしょう。

関連項目

• Web Platform Design Principles § do-not-expose-use-of-assistive-tech

2.5. あなたの仕様によって公開されるデータは、ユーザーには明らかでない可能性のある 関連しているが別個の情報を含んでいますか？

ユーザーがオリジンとデータを共有できるようにする機能は、 そのようなデータが、 ユーザーの認識、理解、および同意なしに 埋め込まれた、場合によっては隠れた情報を 含まないようにするべきです。

画像や動画ファイルなどの 文書は、 画像、動画、または音声がいつどこで取得されたか、 そして どの種類のデバイスがそのデータを取得または生成したかに関する メタデータを含むことがよくあります。 アップロードされると、 この種のメタデータは、 ユーザーが明らかにするつもりのなかった情報、 たとえばユーザーの現在または過去の位置 および社会経済的地位を オリジンに明らかにする可能性があります。

ユーザーエージェントは、ユーザーがそのようなデータをサイトと共有するかどうかを 選択できるようにするべきであり、 既定ではそのようなデータが 共有されないようにするべきです。

2.6. あなたの仕様の機能は、 閲覧セッションをまたいで持続する状態を導入しますか？

Webプラットフォームにはすでに、 オリジンが情報を 保存するために使用できる多くの仕組みがあります。 Cookies、ETag、Last Modified、localStorage、 およびindexedDBは、 ほんの数例です。

Webサイトが、 閲覧セッションをまたいで持続する形で ユーザーのデバイスに データを保存できるようにすると、 この状態がユーザーの認識や制御なしに ユーザーを追跡するために使用される リスクが生じます。 これはファーストパーティまたはサードパーティのコンテキストのいずれにおいても起こり得ます。

ユーザーエージェントが、 クライアント側ストレージ機構の悪用を オリジンに防止する一つの方法は、 オリジンによって保存されたデータを消去する能力を ユーザーに提供することです。 仕様作成者は、新しい クライアント側ストレージ機構が、 ユーザーの制御なしにドメインをまたいでユーザーを追跡するために 悪用されないことを確実にするため、 同様の保護を含めるべきです。 しかし、ユーザーにオリジン設定の状態を削除する能力を与えるだけでは、 通常は十分ではありません。 ユーザーが手動でブラウザー状態を消去することはまれだからです。 仕様作成者は、 値の一意性を低下させる、 値をローテーションする、 または機能を必要以上に識別可能にしないようにするなど、 ストレージ全消去なしで新機能をよりプライバシー保護的にする方法を 検討するべきです。

さらに、仕様作成者は、 可能な場合、自分たちの機能がブラウザーキャッシュ 機能とどのように相互作用すべきかを慎重に検討し、明記するべきです。 オリジンがキャッシュを悪用して、 ユーザー同意なしにサイトまたはセッションをまたいでユーザーを識別し追跡することを 防ぐために、追加の緩和策が必要になる場合があります。

プラットフォーム固有の DRM実装 （コンテンツ復号モジュールなど、[ENCRYPTED-MEDIA]内のもの）は、 ユーザーを識別し、 特定のメディア片へのアクセスを許可されるべきかを判断するために、 オリジン固有の情報を 公開する可能性があります。 この種の識別子は、 悪用をどのように緩和できるかを判断するために 慎重に評価されるべきです。 ユーザーが容易に変更できない識別子は、 追跡の観点から非常に価値があり、 そのような識別子を能動的 ネットワーク攻撃者から保護することは不可欠です。

2.7. あなたの仕様の機能は、 下位プラットフォームに関する情報をオリジンに公開しますか？

（下位プラットフォーム情報には、 ユーザー構成データ、 センサーなどのハードウェアI/Oデバイスの存在と属性、 およびさまざまなソフトウェア機能の可用性や挙動が含まれます。）

もしそうなら、同じ情報がオリジン間で公開されますか？ 異なるオリジンは異なるデータを見ますか、それとも同じデータを見ますか？ そのデータは頻繁に変化しますか、それともまれにしか変化しませんか？ 複数のオリジンに公開される、まれにしか変化しないデータは、 それらのオリジンをまたいでユーザーを一意に識別するために使用される可能性があります。 これは直接的である場合もあります （情報片が一意である場合）し、 間接的である場合もあります （そのデータが他のデータと組み合わされてフィンガープリントを形成し得るため）。 [FINGERPRINTING-GUIDANCE]

そのような情報を公開するかどうかを検討する際、 仕様およびユーザーエージェントは その情報を単独で考えるべきではなく、 プラットフォームの既存のフィンガープリンティング面に それを追加するリスクを評価するべきです。

特定の情報片の フィンガープリンティングリスクは、 プラットフォームによって異なる可能性があることを念頭に置いてください。 あなたが使用しているハードウェアおよびソフトウェアプラットフォーム上での あるデータのフィンガープリンティングリスクは、 他のプラットフォーム上での フィンガープリンティングリスクとは異なる可能性があります。

そのような情報を公開すると決めた場合、 その公開による害を緩和するための措置を講じるべきです。

場合によっては、そもそもデータを公開しないことが正しい答えです（§ 4.6 機能を削除するを参照）。 他の場合には、 フィンガープリント可能性を低減することは、 たとえば利用可能なリソースの一覧を順序付けることによって 一貫性を確保するだけでよい場合もありますが、 より複雑な緩和策が必要になる場合もあります。 詳細は§ 4 緩和戦略を参照してください。

あなたの仕様の機能がそのようなデータを公開し、 十分な緩和策を定義していない場合、 そのような情報が 意味のあるユーザー同意なしに オリジンへ明らかにされないことを確実にするべきであり、 さらにこれを あなたの仕様のセキュリティ上およびプライバシー上の考慮事項の節に 明確に記述するべきです。

WebGLの RENDERER文字列は、 一部のアプリケーションが性能を向上させることを可能にします。 これはフィンガープリンティングデータとしても価値があります。 そのようなデータをオリジンに公開することを検討する際には、 このプライバシーリスクを慎重に比較衡量しなければなりません。

PDFビューアープラグインオブジェクトの一覧は、ほとんど変化しません。 一部のユーザーエージェントは、このインターフェイスのフィンガープリンティング上の害を減らすために、プラグイン一覧の直接列挙を無効化しています。

関連項目:

• デバイスに関する識別情報を公開する際には注意する

• デバイスを選択または列挙するAPIを公開する際には注意する

2.8. この仕様は、オリジンが下位プラットフォームへデータを送信することを 許可しますか？

もしそうなら、どのような種類のデータを送信できますか？

プラットフォームは渡されたデータをどのように処理するかが異なり、 それによってユーザーに対する異なるリスクが生じる可能性があります。

下位プラットフォームが、渡されたデータを安全に処理すると仮定してはいけません。 可能な場合は、プラットフォームに渡されるデータの種類を制限または構造化することで攻撃を緩和してください。

2.9. この仕様の機能は、デバイスセンサーへのアクセスを可能にしますか？

もしそうなら、センサーから、またはセンサーについてのどのような種類の情報がオリジンに公開されますか？

センサーからの情報は、オリジンをまたぐフィンガープリンティングベクトルとして機能する可能性があります。 さらに、 センサーはデバイスまたはその環境についての機微な事柄を明らかにする可能性があります。

センサーデータが比較的安定しており、 オリジン間で一貫している場合、 それはクロスオリジン識別子として使用される可能性があります。 2つのユーザーエージェントが同じセンサーからそのような安定したデータを公開する場合、 そのデータはクロスブラウザー、あるいは潜在的にはクロスデバイス識別子としてさえ使用される可能性があります。

研究者は、 十分に細粒度のジャイロスコープを マイクロフォンとして使用できることを 発見しました [GYROSPEECHRECOGNITION]。 これはジャイロスコープのサンプルレートを下げることで緩和できます。

環境光 センサーは、攻撃者がユーザーが特定のリンクを訪問したかどうかを知ることを 可能にし得ます [OLEJNIK-ALS]。

バッテリー状態のような比較的 短命なデータであっても、 識別子として機能し得ます [OLEJNIK-BATTERY]。

2.10. この仕様の機能は、新しいスクリプト実行/読み込み メカニズムを可能にしますか？

スクリプトを実行または読み込む新しいメカニズムには、新たな攻撃面を可能にするリスクがあります。 一般に、新機能がこれを必要とする場合は、より広い関係者に相談し、 既存のメカニズムを使用できるかどうか、 またはその機能が本当に必要かどうかを検討するべきです。

JSONモジュールはデータとしてのみ扱われることが期待されていますが、 初期提案では、攻撃者がユーザーに知られることなくそれをコードに差し替えることが可能でした。 Import assertionsが この脆弱性の緩和策として実装されました。

2.11. この仕様の機能は、オリジンが他のデバイスにアクセスすることを許可しますか？

もしそうなら、この仕様の機能は、オリジンがどのようなデバイスに アクセスすることを許可しますか？

ネットワーク接続および ユーザーのマシンへの直接接続（例: Bluetooth、 NFC、またはUSB）を介して他のデバイスにアクセスすることは、 脆弱性を公開する可能性があります。これらのデバイスの中には、 Web接続を念頭に置いて作られていないものがあり、悪意のある入力に対する 強化が不十分であったり、Web上での使用に対する強化が不十分であったりする可能性があります。

ユーザーのローカルネットワーク上の他のデバイスを公開することにも、重大なプライバシー リスクがあります:

• 2つのユーザーエージェントがローカルネットワーク上に同じデバイスを持っている場合、 攻撃者は、その2つのユーザーエージェントが同じホスト上で動作している、 または同じ物理的 場所にいる2人の別々のユーザーによって使用されていると推測する可能性があります。

• ユーザーのローカルネットワーク上のデバイスを列挙すると、 攻撃者がユーザーエージェントをフィンガープリントするために使用できる 大きなエントロピーが提供されます。

• この仕様の機能がローカルネットワークデバイスの 永続的または長命の識別子を公開する場合、 ユーザーがそのような追跡を防ぐための手段を取ったとしても（例: Cookieや他の状態を持つ追跡メカニズムを消去する）、 攻撃者に長期にわたりユーザーを追跡する手段を提供します。

• 直接接続は、他のAPIが提供するセキュリティチェックを 回避するためにも使用される可能性があります。たとえば、攻撃者はWebUSB APIを使用して、 初期のU2F APIにおける同一オリジンチェックを回避し、 ハードウェアセキュリティ上の他サイトの資格情報に アクセスしました。 [YUBIKEY-ATTACK]

Network Service Discovery API [DISCOVERY-API]は、デバイスへのアクセスを許可する前に CORSプリフライトを推奨し、ユーザーエージェントが 何らかの権限要求でユーザーを関与させることを要求しました。

同様に、Web Bluetooth [WEB-BLUETOOTH]には、 Web Bluetooth § 3 Privacy considerationsにおいて そのような問題についての広範な議論があり、類似の作業に対する例として 読む価値があります。

[WEBUSB]は、 ユーザー仲介/ プロンプト、セキュアオリジン、および機能ポリシーの組み合わせを通じて これらのリスクに対処します。 詳細はWebUSB API § 3 Security and Privacy Considerationsを参照してください。

2.12. この仕様の機能は、オリジンがユーザーエージェントのネイティブUIに対して ある程度の制御を行うことを許可しますか？

ユーザーエージェントのUIを制御できる機能（例: 全画面 モード）や下位システムへの変更（例: スマートフォンのホーム画面に 「アプリ」をインストールする）は、ユーザーを驚かせたり、セキュリティ/プライバシー 制御を不明瞭にしたりする可能性があります。あなたの機能が ユーザーエージェントのUIを変更できる範囲において、それは セキュリティ/プライバシー制御に影響できますか？ どのような分析が この結論を確認しましたか？

2.13. この仕様の機能は、どのような一時的識別子を作成または Webに公開しますか？

標準が一時的識別子をWebに公開する場合、その識別子は 短命であり、この識別子が長期にわたりユーザーを追跡するために使用される リスクを緩和するため、一定の期間ごとにローテーションされるべきです。 ユーザーがユーザーエージェント内の状態を消去する場合、これらの一時的識別子も 消去され、一時的識別子を使用した状態の再相関を防ぐべきです。

この仕様の機能が一時的識別子を作成または Webに公開する場合、それらはどのように、いつ、どの実体に対して公開され、 また、それらの一時的識別子はどのくらいの頻度で ローテーションされますか？

一時的識別子の例には、TLS Channel ID、Session Tickets、および IPv6アドレスが含まれます。

Gamepad API [GAMEPAD]におけるindex属性 — ゼロから始まり、 増分され、リセットされる整数 — は、プライバシーに配慮した 一時的識別子の良い例です。

2.14. この仕様は、ファーストパーティおよび サードパーティのコンテキストにおける挙動をどのように区別しますか？

機能の挙動は、ユーザーが訪れているファーストパーティオリジンによって 使用される文脈だけでなく、そのファーストパーティに含まれる任意の サードパーティによって使用される場合の影響も考慮されるべきです。 仕様を開発する際には、ページ上のサードパーティリソースによる 使用の影響を検討し、サードパーティリソースによる使用のサポートを 仕様への適合において任意とすべきかどうかを検討してください。 サードパーティリソースによる使用のサポートが適合のために必須である場合は、 その理由と、どのようなプライバシー緩和策があるかを説明してください。 これは特に重要です。サードパーティが機能を悪用していると判明した場合、 ユーザーエージェントは特定の機能の可用性または機能性をサードパーティに対して 低減するための措置を取る可能性があるからです。

2.15. この仕様の機能は、ブラウザーの プライベートブラウジングまたはシークレットモードの文脈でどのように動作しますか？

ほとんどのブラウザーはプライベートブラウジングまたはシークレットモードを実装していますが、 それらが提供する機能や、その保護がユーザーにどのように説明されるかは 大きく異なります [WU-PRIVATE-BROWSING]。

共通点の一つは、ブラウザーの「通常」の状態とは異なる 状態の集合を提供することです。

この仕様の機能は、 通常モードとプライベートブラウジング/シークレットモードをまたいで 単一ユーザーの活動を相関させることを可能にする情報を提供しますか？ 仕様の機能は、 プライベートブラウジング/シークレットモードのセッション終了後も持続する情報を ユーザーのホストに書き込む結果になりますか？

次の両方について研究があります:

• ユーザーエージェントがプライベートブラウジングモードにあるかどうかを検出すること [RIVERA]。 これは window.requestFileSystem()などの 非標準化メソッドを使用します。

• 機能を使用してブラウザーをフィンガープリントし、特定のユーザーについて プライベートモードおよび非プライベートモードのセッションを相関させること。 [OLEJNIK-PAYMENTS]

仕様作成者は、可能な限り、 プライベートブラウジングモードの存在をサイトに検出可能にすることを避けるべきです。 Web Platform Design Principles § do-not-expose-use-of-private-browsing-mode

2.16. この仕様には、「セキュリティ上の考慮事項」と「プライバシー上の 考慮事項」の両方の節がありますか？

仕様には、実装者およびWeb開発者が 機能のもたらすリスクを理解し、十分な緩和策が整っていることを 確実にするため、 「セキュリティ上の考慮事項」と「プライバシー上の 考慮事項」の両方の節があるべきです。 この文書の質問への回答は、それらの節を書く際の参考になりますが、 この質問票を単にそれらの節へコピーしてはいけません。 代わりに、実装者およびWeb開発者に役立つ、 あなたの仕様に固有の言葉を作成してください。

[RFC6973]は、 仕様のプライバシー影響を検討する際に参照すべき優れたリソースであり、 特にRFC6973の第7節が有用です。 [RFC3552]は、 セキュリティ上の考慮事項の節を書くための一般的な助言を提供し、 RFC3552の第5節には具体的な要件があります。

一般に、これらの節には、 あなたの仕様が導入する機能についての プライバシーおよびセキュリティリスクの明確な説明を含めるべきです。 また、仕様内の別の場所で緩和されているリスクを文書化し、 仕様どおりでない方法で実装された場合に脆弱性につながる可能性が高い詳細を 指摘することも適切です。

あなたの仕様のどの機能にもセキュリティまたは プライバシーへの影響がないように思われる場合は、たとえば次のように その旨を本文中に述べてください:

この仕様の機能による既知のセキュリティ影響はありません。

ただし、ほとんどの仕様には、 ブラウザーのフィンガープリンティング面に少なくとも何らかの 影響を与える機能が含まれることに注意してください。 あなたの仕様が例外であると考えるなら、その主張を正当化することが 必要です。

2.17. あなたの仕様の機能は、オリジンが既定の セキュリティ保護を格下げすることを可能にしますか？

あなたの仕様の機能は、 何かを実現するために、 オリジンがセキュリティ設定をオプトアウトすることを 可能にしますか？ もしそうなら、 これらの機能はどのような状況でそのような格下げを許可し、それはなぜですか？

これは最初から避けることができますか？ 避けられない場合、 この格下げがユーザーへのリスクを劇的に高めないことを確実にする 緩和策はありますか？ たとえば、[PERMISSIONS-POLICY]は、 信頼されていない iframeが そのような機能を使用することをサイトが防ぐために使用できる メカニズムを定義しています。

2.18. あなたの機能を使用する文書が、ナビゲーション後に（破棄される代わりに） BFCache内で存続し、将来その文書への戻りナビゲーションで再利用される可能性がある場合、 何が起こりますか？

ユーザーが文書から離れるナビゲーションを行った後、 その文書は非「完全にアクティブ」状態のまま残り、 「戻る/進むキャッシュ（BFCache）」に保持され、 ユーザーがその文書に戻るナビゲーションを行ったときに再利用される可能性があります。 ユーザーの視点からは、 非完全にアクティブな文書はすでに破棄されているため、 ユーザーがそこから離れた後に発生する更新/イベント、 特にプライバシーに敏感な情報（例: 位置情報）を受け取るべきではありません。

また、文書はナビゲーション後でも再利用される可能性があるため、 何かを文書の寿命に結びつけることは、 ナビゲーション後にもそれを再利用することを意味する点に注意してください。 これが望ましくない場合は、 完全にアクティブ状態の変化を監視し、 必要に応じてクリーンアップすることを検討してください。

BFCachedされた文書の扱い方についてのより詳細なガイダンスは、 Web Platform Design Principles § support-non-fully-activeおよびSupporting BFCached Documentsガイドを参照してください。

注: 文書は、 BFCacheに関係しない他の理由で非完全にアクティブになる可能性もあります。 たとえば、文書を保持するiframeが切断される場合です。 私たちの助言は、すべての非完全にアクティブな文書は同じように扱われるべきだというものです。 唯一の違いは、BFCachedされた文書は再び完全にアクティブになる可能性があるのに対し、 切り離されたiframe内の文書は永遠に非アクティブのままであることです。 したがって、BFCacheの場合には特に注意を払うことを提案します。

2.19. あなたの機能を使用する文書が切断された場合、何が起こりますか？

2.20. あなたの仕様は、新しい種類のエラーをいつ、どのように発生させるべきかを 定義していますか？

エラー処理、 およびどの条件がエラー状態を構成するかは、 意図しない情報漏えいやプライバシー脆弱性の原因になり得ます。 エラーをトリガーすること、 エラーに含まれる（またはエラーによって学習可能な）情報、 およびアプリケーション内のどの当事者がそのエラーについて知ることができるかは、 すべてユーザーのプライバシーに影響する（または弱める）可能性があります。 提案作成者は、エラー処理によってユーザーのプライバシーおよびセキュリティが 損なわれないように、これらの各側面を 慎重に検討するべきです。

エラー定義およびエラー処理がユーザーをリスクにさらし得る方法の 部分的な一覧には、次が含まれます:

• あなたの仕様が、特定のシステムリソースが利用可能かどうかに基づいて エラー状態を定義する場合、 アプリケーションはそのエラー状態をプローブとして使用し、 それらのシステムリソースの可用性について知ることができます。 これは、ユーザーエージェントがアプリケーションにそのようなシステム リソースについて知らせるつもりがない場合、 ユーザーのプライバシーを害する可能性があります。

• 仕様には、アプリケーションの問題を特定しデバッグするために 作成者を助けることを意図した情報を、 エラーオブジェクトに含めることがよくあります。 仕様作成者は、 そのようなデバッグ情報が何を公開するか、 また、ページ上のどのアクターがその情報にアクセスできるかを 慎重に検討するべきです。

2.21. あなたの機能は、サイトがユーザーによる支援技術の使用について知ることを 許可しますか？

仕様作成者は、 支援技術に依存するWebユーザーが、 Webを使用する際に固有のリスクに直面することを念頭に置くべきです。 支援技術の使用により、それらのWebユーザーは 他のWebユーザーの中で目立つ可能性があり、望ましくない再識別 およびプライバシー上の害のリスクが高まります。同様に、一部のWebサイト運営者は、 支援技術に依存するWebユーザーを差別しようとする可能性があります。

したがって、機能設計者および仕様作成者は、 Webサイトが支援技術の使用について知ることができるかどうか、また何を知ることができるかを制限するために、 思慮深く慎重であるべきです。仕様作成者は、 その機能が支援技術の使用について明示的および暗黙的に明らかにする情報を 最小化しなければなりません。 支援技術に関する明示的な情報の例には、 デバイス識別子またはモデル名が含まれます。支援技術の使用に関する暗黙的な情報の例には、 マウス、キーボード、またはタッチスクリーンでは生成されそうにない ユーザー操作パターンが含まれる場合があります。

[wai-aria-1.3]は、 作成者が支援技術でページをよりナビゲートしやすくするために使用できる 追加のマークアップを定義しています。仕様には、 aria-hidden 属性が含まれており、サイト作成者はそれを使用して、 特定のコンテンツを支援技術から隠すべきであることを示すことができます。

悪意あるサイト作成者は、 aria-hidden属性を悪用して、ユーザーが支援技術を使用しているかどうかを知る可能性があります。 たとえば、特定のページコンテンツを支援技術には明らかにし、 他のユーザーには非常に異なるページコンテンツを表示することによってです。悪意ある サイト作成者は、その後、ユーザーがどのコンテンツと相互作用していたかを ユーザーの挙動から推測し、したがって支援技術が 使用されていたかどうかを推測できる可能性があります。

2.22. この質問票は何を尋ねるべきでしたか？

この質問票は網羅的ではありません。 プライバシーレビューを完了した後、 あなたの仕様には、 この質問票を厳密に読み、それに回答しても 明らかにならなかった プライバシー側面があるかもしれません。 その場合は、 それらのプライバシー上の懸念を伝え、 この側面を扱うことができたであろう改善された質問または新しい質問を 思いつくかどうかを示してください。

この質問票が何を尋ねるべきだったかを知らせるため、課題を提出することを検討してください。

3. 脅威モデル

セキュリティおよびプライバシーを考えるには、脅威モデル、 つまり可能なリスクを明らかにする方法の観点で考えると便利です。

Webプラットフォーム向けの機能を開発する際に考慮すべき 具体的なプライバシー上の懸念がいくつかあります [RFC6973]:

• 監視: 監視とは、個人の通信または活動を観察またはモニタリングすることです。

• 保存データの侵害: 保存データを不正または不適切なアクセスから 保護するための十分な措置を取らないエンドシステム。

• 侵入: 侵入とは、人の生活または活動を妨げたり中断したりする 侵害的行為から成ります。

• 誤帰属: 誤帰属は、ある個人に関連するデータまたは通信が 別の個人に帰属されるときに発生します。

• 相関: 相関とは、個人に関連する、または組み合わされるとその特徴を得る、 さまざまな情報片を組み合わせることです。

• 識別: 識別とは、個人の身元を推測するため、または 個人の身元の推測を可能にするために、 情報を特定の個人へ結びつけることです。

• 二次利用: 二次利用とは、収集された目的とは異なる目的で、 個人の同意なしに、その個人について収集された情報を使用することです。

• 開示: 開示とは、 他者がその個人を判断する方法に影響する、個人に関する情報の 暴露です。

• 排除: 排除とは、 他者が自分についてどのようなデータを持っているかを個人が知り、 その取り扱いと使用に参加することを認めないことです。

緩和策の節では、この文書はこれらのリスクを緩和するために適用できる いくつかの技法を概説しています。

以下に列挙するのは、Web機能を開発する際に考慮すべき 脅威の広範な分類です。

3.1. 受動的ネットワーク攻撃者

受動的ネットワーク 攻撃者は、ユーザーと通信相手のサーバーとの間の 回線上を流れるビットに対する読み取りアクセスを持っています。彼女はバイトを変更できませんが、 それらを収集し分析できます。

インターネットの分散的な性質、およびユーザー活動への一般的な 関心の度合いを考えると、 あなたが今使っているプロキシ、ルーター、サーバーのネットワークを跳ね回っている 暗号化されていない実質的にすべてのビットが、誰かに読まれていると仮定するのは合理的です。 それらの攻撃者の中には、 暗号化されたビットも理解しようと最善を尽くしている者がいる可能性も同様に高く、 後の暗号解析のために暗号化された通信を保存することも含まれます （ただし、それにはかなり多くの労力が必要です）。

• IETFの「Pervasive Monitoring Is an Attack」文書 [RFC7258]は、 この仮定がもたらすプライバシーへの影響のいくつかを概説しており、 有用な読み物です。

• 懸念は政府だけではありません。地元のコーヒーショップも 顧客に関する情報を収集している可能性が高く、自宅のISPも 同じことをしている可能性が高いです。

3.2. 能動的ネットワーク攻撃者

能動的ネットワーク 攻撃者は、ユーザーと通信相手のサーバーとの間の 回線上を流れるビットに対する読み取りおよび書き込みアクセスの両方を持っています。 彼女はデータを収集し分析できるだけでなく、転送中にそれを変更し、 JavaScript、HTML、および他のコンテンツを任意に 注入および操作できます。 これは、良性および悪意のある目的の両方で、あなたが予想するよりも一般的です:

• ISPおよびキャッシュプロキシは、 データ使用量を削減するために、ユーザーへ配信する前に 画像をキャッシュおよび圧縮することがよくあります。 これは、電話のような低帯域幅・高遅延デバイスを使用するユーザーには 特に有用です。

• ISPはまた、より良性でない目的のために、 JavaScript [COMCAST]や 他の識別子 [VERIZON]を注入することもよくあります。

• あなたのISPが利益のために、そこを流れる大量のトラフィックを 進んで変更するなら、 国家レベルの攻撃者が受動的なままでいると信じるのは困難です。

3.3. 同一オリジンポリシー違反

同一オリジン ポリシーはWeb上のセキュリティの礎です。 あるオリジンは別のオリジンのデータに直接アクセスするべきではありません （このポリシーは[RFC6454]の第3節でより形式的に定義されています）。 このポリシーの当然の帰結として、オリジンはどのオリジンにも関連付けられていないデータ、 たとえばユーザーのハードドライブの内容に直接アクセスするべきではありません。 さまざまな種類の攻撃が、この保護を何らかの方法で回避します。たとえば:

• クロスサイトスクリプティング攻撃は、 攻撃者が、ターゲットオリジンのコンテキスト内で攻撃者制御のコードを実行するように オリジンをだますことを伴います。

• クロスサイトリクエストフォージェリ攻撃は、 ユーザーがログインしているサイトで、ユーザーに代わってリクエストを送信することにより、 ユーザーエージェントをだましてユーザーの周辺権限を行使させます。

• データ漏えいは、情報の断片がクロスオリジンで意図せず利用可能になるときに発生します。 これは、CORSヘッダー [CORS]を通じて明示的に起こる場合も、 [TIMING]のようなサイドチャネル攻撃を通じて暗黙的に起こる場合もあります。

3.4. サードパーティトラッキング

Webの力の一部は、ページが画像からJavaScriptに至るまで、 他のサードパーティからコンテンツを取り込み、 サイトのコンテンツやユーザー体験を向上させられる能力にあります。 しかし、ページがサードパーティからコンテンツを取り込むと、 それは本質的にいくらかの情報をサードパーティへ漏らします。 たとえばreferer情報や、ユーザーの追跡およびプロファイリングに使用され得る その他の情報です。これには、Cookieが最初にそれを保存した ドメインへ戻ることでクロスオリジン追跡を可能にするという事実が含まれます。 さらに、サードパーティは、Webページに含まれるサードパーティ JavaScriptを通じて実行能力を得ることができます。 ページはサードパーティコンテンツのリスクを緩和するための措置を取ることができ、 ブラウザーは特定のページからのファーストパーティおよびサードパーティコンテンツの扱いを 区別することがありますが、 新しい機能がファーストパーティサイトではなくサードパーティによって実行されるリスクは、 機能開発プロセスで考慮されるべきです。

最も単純な例は、特定の条件下で異なる挙動をするサイトへのリンクを注入することです。 たとえば、ユーザーがそのサイトにログインしているかどうかに基づくものです。 これは、ユーザーがそのサイトにアカウントを持っていることを明らかにする可能性があります。

3.5. 正当な誤用

強力な機能が開発者に提供される場合であっても、 すべての使用が常に良い考えである、または正当化されるとは限りません。 実際、世界中のデータプライバシー規制は、特定のデータ使用に 制限を課すことさえあります。 ファーストパーティの文脈では、正当なWebサイトが 強力な機能と相互作用し、ユーザーの行動または 習慣について知ることができる可能性があります。たとえば:

• マウス移動追跡などのメカニズムを介して、Webサイト閲覧中の ユーザーを追跡すること

• 使用パターンに基づいてユーザーの行動プロファイリングを行うこと

• ファーストパーティがユーザーのシステム、ユーザー自身、またはユーザーの周囲について 知ることを可能にする強力な機能にアクセスすること。 たとえばWebカメラやセンサーを通じて行われ得るもの

この点は他の点とは明らかに異なりますが、 何かが可能であるからといって、それが常に行われるべきだとは限らないことを強調しています。 これには、プライバシー影響評価、あるいは倫理評価を検討する必要も含まれます。 セキュリティとプライバシーを念頭に置いて機能を設計する際には、 使用ケースと誤用ケースの両方が範囲に含まれるべきです。

4. 緩和戦略

あなたの仕様で特定したセキュリティおよびプライバシーリスクを緩和するために、 以下に説明する緩和策の1つ以上を適用するとよいでしょう。

4.1. データ最小化

最小化とは、特定の操作を完了するために必要なだけの できる限り少ない情報を 他の通信相手へ公開する戦略です。 より具体的には、ユーザー仲介によるアクセスで明らかになった以上の 情報へのアクセスを提供しないこと、または提供される情報を正確に ユーザーがある程度制御できるようにすることを要求します。

たとえば、ユーザーが特定のファイルへのアクセスを提供した場合、 それを表すオブジェクトが、 そのファイルの親ディレクトリやその内容に関する情報を取得できるようにするべきではありません。 それは明らかに期待されていることではないからです。

データ最小化の文脈では、 異なる当事者間でどのデータが渡されるのか、 データ項目および識別子がどれほど永続的か、 そして異なるプロトコル実行間に相関の可能性があるかを問うのは自然です。

たとえば、W3C Device APIs Working Groupは、 Privacy Requirements文書においていくつかの 要件を定義しています。 [DAP-PRIVACY-REQS]

データ最小化は、仕様作成者および実装者、 ならびに最終サービスを展開する者に適用されます。

例として、マウスイベントを考えてください。ページが読み込まれたとき、 アプリケーションはマウスが接続されているかどうか、どの種類のマウスか （例: メーカーやモデル）、どのような能力を公開するか、何台接続されているか、 などを知る方法がありません。ユーザーがマウスを使用しようと決めたときにのみ — おそらくそれが相互作用に必要だからですが — この情報の一部が利用可能になります。それでも、公開されるのは最小限の情報だけです。 たとえば、それがトラックパッドであるかどうかを知ることはできず、 右ボタンがあるという事実も、それが使用された場合にのみ公開されます。 たとえば、Gamepad APIはこのデータ最小化能力を利用しています。Webゲームが、 ユーザーエージェントがゲームパッドにアクセスできるかどうか、何台あるか、 どのような能力を持つかなどを知ることは不可能です。 ユーザーがゲームパッドを通じてゲームと相互作用したい場合、彼女はいつそれを操作すべきかを知っていると 単に仮定されます。そしてそれを操作することで、アプリケーションが動作するために必要なすべての情報 （ただしそれ以上ではない）が提供されます。

マウスについて機能がサポートされる方法は、 特定のイベントが発生したときにのみマウスの挙動に関する情報を提供することです。 したがって、このアプローチは、イベント処理（例: クリック、移動、ボタン押下でトリガー）を デバイスへの唯一のインターフェイスとして公開することです。

機能が公開するデータを最小化している仕様には、次の2つがあります:

• [BATTERY-STATUS] ユーザーエージェントは高精度の読み取り値を公開するべきではない

• [GENERIC-SENSOR] 最大サンプリング周波数を制限する、 精度を下げる

4.2. 既定のプライバシー設定

ユーザーはしばしば既定値を変更しません。その結果、 仕様の既定モードが、公開されるデータおよび識別子の量、識別可能性、 永続性を最小化することが重要です。 これは、特定の環境に合わせて調整できる柔軟なオプションをプロトコルが伴う場合に 特に当てはまります。

4.3. 明示的なユーザー仲介

機能のセキュリティまたはプライバシーリスクを 仕様内で他の方法では緩和できない場合、 実装者がユーザーにプロンプトを出すことを任意で許可することが、 可能な最善の緩和策であるかもしれません。 ただし、それがプライバシーリスクを完全に取り除くわけではないことを理解する必要があります。 仕様が実装者にプロンプトを許可しない場合、 一部のユーザーエージェントがよりプライバシーに配慮したバージョンを実装することを選ぶため、 異なるユーザーエージェントによる実装の分岐につながる可能性があります。

機能そのものにリスクが内在しているために、 機能のリスクを緩和できない場合があります。 たとえば、[GEOLOCATION]は意図的にユーザーの位置を明らかにします。 ユーザーエージェントは一般に、 ユーザーが受け入れることを選択できる権限プロンプトによって その機能へのアクセスを制限します。 このリスクは、個人データまたは識別子を公開する機能にも存在し、 考慮されるべきです。

そのようなプロンプトを設計することは困難であり、 権限が提供すべき期間を決定することも困難です。

多くの場合、最善のプロンプトは、 ユーザー操作に明確に結びついたものです。たとえば、 ユーザー操作に応答してファイルピッカーが表示され、 ユーザーが個別のサイトに対して特定のファイルへのアクセスを与えるようなものです。

一般的に言えば、プロンプトの期間とタイミングは、 公開されるデータがもたらすリスクに反比例するべきです。 さらに、プロンプトは次のような問題を考慮するべきです:

• 権限要求はどのようにスコープされるべきですか？ 特に埋め込まれたサードパーティiframeによって要求される場合はどうですか？

• 永続性は、トップレベル/埋め込みオリジンの組に基づくべきですか、 それとも異なるスコープに基づくべきですか？

• プロンプトがデータを必要とする文脈で発生しており、 かつプロンプトがなぜ発生しているのかユーザーに明確な時点で発生していることを どのように確実にしますか。

• ユーザーにプロンプトを出す前に、 アクセス可能かつローカライズされた方法で、権限の意味を説明すること -- _誰が_求めているのか、_何を_求めているのか、_なぜ_それを必要としているのか？

• ユーザーがプロンプト時に要求を拒否した場合、または 後で気が変わってアクセスを取り消した場合、何が起こりますか。

これらのプロンプトには、データが他の当事者と共有された後、 ユーザーが自分のデータに対してどのような制御を持つか（もしあれば）についての考慮も 含めるべきです。 たとえば、ユーザーはどの情報が他の当事者と共有されたかを判断できますか？

4.4. 機能をファーストパーティオリジンに明示的に制限する

「サードパーティトラッキング」の節で説明したように、 Webページはファーストパーティおよびサードパーティのコンテンツを単一のアプリケーションに混在させます。 これは、サードパーティコンテンツがファーストパーティコンテンツと同じ一連のWeb機能を 誤用できるリスクを導入します。

作成者は、機能の可用性の範囲を明示的に指定するべきです:

• 機能が埋め込まれたサードパーティに提供されるべき場合 -- そして多くの場合、ファーストパーティはそれを明示的に制御できるべきです （iframe属性または機能ポリシーを使用して）

• 機能がバックグラウンドで利用可能であるべきか、 それとも最前面の可視タブでのみ利用可能であるべきか。

• 機能がオフラインサービスワーカーで利用可能であるべきか。

• イベントが同時に発火するかどうか

機能へのサードパーティアクセスは、 適合のための任意実装とするべきです。

4.5. セキュアコンテキスト

あなたの仕様で特定した主要なリスクが 能動的ネットワーク攻撃者による脅威である場合、 安全でないオリジンに機能を提供することは、 その機能をすべてのオリジンに提供することと同じです。 なぜなら、攻撃者はフレームやコードを任意に注入できるからです。 機能を使用するために暗号化され認証された接続を要求することは、 この種のリスクを緩和できます。

セキュアコンテキストは、受動的ネットワーク攻撃者に対しても保護します。 たとえば、ページがGeolocation APIを使用し、センサーから提供された 緯度と経度を安全でない接続でサーバーへ送り返す場合、 受動的ネットワーク攻撃者は、ユーザーや他者による検知への実現可能な経路なしに、 ユーザーの位置を知ることができます。

しかし、セキュアコンテキストを要求することは、 能動的ネットワーク攻撃者以外の脅威主体からの多くの プライバシーリスク、さらにはセキュリティリスクを緩和するのに十分ではありません。

4.6. 機能を削除する

機能の潜在的な負のセキュリティまたはプライバシー影響を 緩和する最も単純な方法は、 おそらくその機能を削除することです。 ただし、一部のセキュリティまたはプライバシーリスクは、 プラットフォームに機能を追加することで 取り除かれたり緩和されたりする可能性があることを 念頭に置くべきです。 仕様内のすべての機能は、 そうでないことが証明されるまで、 セキュリティおよび/またはプライバシーリスクを 追加する可能性があるものとして見なされるべきです。 セキュリティまたはプライバシー影響に対する緩和策として 機能を削除することを議論するのは、 有用な演習です。 それにより、 機能と、 それが必要最小限のデータを公開しているかどうか、 および他の可能な緩和策との間の トレードオフが明らかになるからです。

機能追加が、 ユーザーが抱く Webページを訪問することは安全である という全体的な印象に与える累積的な影響も検討してください。 ユーザーがWebサイトを訪問することは安全であると理解することを 複雑にする行為、 またはWebの安全性についてユーザーが理解する必要のあることを 複雑にする行為 （例: より安全でない機能を追加する）は、 その安全性の理解に基づいて行動するユーザーの能力、 または存在する安全性を正しく反映した方法で行動する能力を低下させます。

すべての仕様は、セキュリティ/プライバシー攻撃面を削減し最小化するという理由だけでも、 可能な限り小さくあることを目指すべきです。 そうすることで、特定の機能だけでなく、モジュール（関連する一連の 機能）、仕様、そしてWebプラットフォーム全体の セキュリティおよびプライバシー攻撃面を削減できます。

例

• MozillaおよびWebKitはBattery Status APIを削除しました

• Mozillaは devicelight、 deviceproximity、およびuserproximityイベントを削除しました

4.7. プライバシー影響評価を行う

一部の機能は機微データを供給する可能性があり、 エンド開発者、システム所有者、または管理者には、 これを認識し、自分たちのシステム設計において適切に行動する責任があります。 特に個人に関するデータが処理される可能性がある場合、 一部の使用はプライバシー影響評価の実施を正当化するかもしれません。

機微データを公開する機能を含む仕様は、 そのAPIを採用するWebサイトおよびアプリケーションが、 収集するデータについてプライバシー影響評価を実施することを推奨する内容を 含めるべきです。

これを行う機能の例は:

• [GENERIC-SENSOR]は、プライバシー影響 評価の実施を検討するよう 助言しています

これらの影響を文書化することは組織にとって重要ですが、 この責任を組織に負わせることには限界がある点にも注意すべきです。 研究によれば、サイトは仕様内のセキュリティ/プライバシー 要件に従わないことがよくあります。たとえば、[DOTY-GEOLOCATION]では、 調査対象のWebサイトのどれも、サイトが位置情報を要求する前に ユーザーへプライバシー慣行を知らせていなかったことが 判明しました。

謝辞

Alice Boxhall、 Alex Russell、 Anne van Kesteren、 Chris Cunningham、 Coralie Mercier、 Corentin Wallez、 David Baron、 Domenic Denicola、 Dominic Battre、 Jeffrey Yasskin、 Jeremy Roman、 Jonathan Kingston、 Marcos Caceres、 Marijn Kruisselbrink、 Mark Nottingham、 Martin Thomson、 Michael(tm) Smith、 Mike Perry、 Nick Doty、 Robert Linder、 Piotr Bialecki、 Samuel Weiler、 Tantek Çelik、 Thomas Steiner、 Wendy Seltzer、 そして PING、プライバシーワーキンググループ、 セキュリティ関心グループ、およびTAGの多くの現および元参加者による この文書への貢献に深く感謝します。

特に、 仕様作成者がbfcacheを考慮に入れるのを助ける編集を行った Rakina Zata Amniに感謝します。

Mike Westは この文書の初期版を書き、 何年にもわたり編集しました。 Yan Zhuは Mikeから引き継ぎ、さらに Jason Novak および Lukasz Olejnikが 彼女から引き継ぎました。 現在の編集者たちは、彼ら全員の尽力に恩義を感じています。 私たちがそれを（あまり）悪くしていないことを願っています。