ドキュメントポリシー

コミュニティグループ報告書草案,

このバージョン:
https://wicg.github.io/document-policy/
課題追跡:
GitHub
仕様内インライン
編集者:
(Google)

概要

この仕様は、開発者が ... できるようにする機構を定義します。

この文書のステータス

この仕様は、Web Platform Incubator Community Group により公開されました。 これは W3C 標準ではなく、W3C 標準化トラック上にもありません。 W3C Community Contributor License Agreement (CLA) の下では、限定的なオプトアウトおよびその他の条件が適用されることに注意してください。 W3C Community and Business Groups について詳しく学ぶ。

1. はじめに

この文書は、ウェブプラットフォームの一部として設定可能な機能を 設計するためのフレームワークであり、ウェブ開発者がサイトのデプロイの一環として それらの機能を設定できるようにする文書ポリシーを定義します。

2. 例 #

新しい例が必要です。現時点では、解説を参照してください。

文書ポリシーは、文書設定のための既存のいくつかの仕組みと 適用範囲が似ていますが、それぞれとは大きな違いがあります。

3.1. Permissions Policy との関係

Permissions Policy [PERMISSIONS-POLICY] も、作者が文書内の機能を設定できるようにする 仕組みであり、適用範囲は似ていますが、 異なる継承の仕組みを使用しているため、 文書ポリシーによる制御に適した機能とは別の、 特定の種類の機能により適しています。

歴史的には、文書ポリシーは Permissions Policy(当時は Feature Policy と 呼ばれていました)への多数の機能追加提案に対応するために作成されました。 それらは既存の「feature」モデルにうまく適合しないか、 Permissions Policy 仕様にかなりの追加の複雑さを 導入する必要がありました。これには、パラメーターを持つ機能、 サブフレームへの継承を任意にできる機能、および 他のトップレベル閲覧コンテキストとは異なる方法でポップアップに 継承される機能が含まれていました。

これらの機能は現在、文書ポリシーで扱うことが提案されており、 Permissions Policy は委譲が主な 関心事項である機能に使用されます。Permissions Policy の機能は boolean 値 (有効または無効)であり、親で無効にされた場合は子フレームで 再び有効にすることはできず、一般に「トップレベル閲覧 コンテキストとその同一オリジンの子では利用可能であり、クロスオリジン フレームには委譲する必要がある」というモデルに従います。

対照的に、文書ポリシーによって制御される機能はパラメーターを取ることができ、 それらのパラメーターは異なるフレームで互いに無関係な値を持つことができます(親フレームで 機能を制約しても、必ずしもその子 フレームを制約するわけではありません)。

3.2. Content Security Policy との関係

Content-Security-Policy [CSP] も文書内の 「features」を設定しますが、 主としてページ内のリソースのオリジンに関係し、 読み込み後にそれらのリソースが何を行えるかを制御することではありません。

CSP はまた、sandbox ディレクティブを通じて、 文書にサンドボックスフラグを設定するための異なる仕組みも提供します。サンドボックスフラグが 文書ポリシーへ移された場合、2 つのヘッダーが 同一の情報をエンコードする可能性があるため、これは冗長になる可能性があります。

CSP-Embedded-Enforcement は、子文書にポリシーへの 準拠を強制し、Fetch 中に適合しない文書を ネットワークエラーとして拒否するモデルを導入しました。このモデルは、 必須ポリシーの仕組みとして文書ポリシーに採用されています。

3.3. サンドボックス化との関係

iframe のサンドボックス化も、文書内の機能を制御するための仕組みであり、 文書ポリシーの必須ポリシーと非常によく似た方法で動作します。 機能を無効にすることをフレームに課すことができ、 そのフレームへ読み込まれるすべてのコンテンツに影響します。

iframe の sandbox 属性によって制御される機能は、 文書ポリシーで非常に自然に表現できます。

iframe のサンドボックス化と文書ポリシーの重要な違いの 1 つは、 フレームで 'sandbox' 属性が使用された場合、 すべてのサンドボックス機能が既定で適用され、 1 つずつ再び有効にする必要があることです。このため、 サンドボックス化モデルを新しい機能で拡張することは非常に困難です。追加された機能は 既存のすべてのサンドボックス化されたコンテンツに即座に影響するためです。さらに、 オリジンサーバーには、そのコンテンツがサンドボックス化されることを知るための 仕組みがないため、サンドボックス化された文書内の制御フローを 変更する可能性のある新しいサンドボックス機能を追加することは困難です。これは、 既存のコンテンツに新たなセキュリティ脆弱性を 導入する可能性があるためです。

4. フレームワーク

4.1. 設定ポイント

設定 ポイントとは、文書ポリシーを通じて有効化、無効化、または設定できる ウェブプラットフォーム API または動作です。 設定ポイントは、基礎となる API または動作を記述する仕様で定義されるべきですが、 使用されている定義済みの 設定ポイントのレジストリがこの文書に付属しています。

設定 ポイントには、トークンである 名前があります。

設定 ポイントには、次のいずれかである があります。

  • boolean

  • integer

  • float、または

  • enum

設定 ポイントには、その のすべての値の部分集合である 範囲があります。

設定 ポイントには、その 範囲の要素である 既定値があります。

設定 ポイントは複数の パラメーターを持てるようにすべきでしょうか? おそらくパラメーターは、名前、 型、範囲とともに個別に定義すべきです。
新しい設定ポイントを導入するときは、既定 値を慎重に選択し、 ウェブ互換性を最優先で考慮すべきです。文書に対して明示的なポリシーが 宣言されていない場合、既定値が有効になります。

4.2. ポリシー

文書 ポリシーとは、設定 ポイントから ポリシー設定への順序付きマップです。

ポリシー 設定とは、設定ポイント範囲の要素である と、文字列であり null であってもよい 報告エンドポイントからなるタプルです。

閲覧コンテキストには、 文書 ポリシーである 必須文書ポリシーがあります。 null の オープナー 閲覧コンテキストを持つ 閲覧コンテキストは、空の 必須文書ポリシーを持ちます。

Document には、 文書 ポリシーである ネストされたコンテキストの必須文書 ポリシーがあります。

Document には、文書ポリシーである 文書 ポリシーがあります。

Document には、文書ポリシーである 報告専用文書ポリシーがあります。

5. 必須ポリシーの直列化

  • ここでは、必須ポリシーが構造化 ヘッダーとしてどのように 直列化されるかを説明します。

  • 正準形式が存在することを保証します(互換性テスト用)。

6. 報告

文書ポリシーをデプロイするサイトは、そのページに設定された ポリシーのいずれかに違反があるかどうかを知りたい場合があります。たとえば、すべての画像が そのコンテナーのサイズと一致することを要求するポリシーを設定しているサイトは、 新しい開発者や CMS がコンテンツにサイズ超過の画像を挿入した場合に 警告を受けたい場合があります。 同様に、document.write API の使用を制限するポリシーをデプロイしているサイトは、 それを使用するスクリプトがインポートされた場合に 報告を受けたい場合があります。

この節では、Reporting API を使用してそのような違反を報告する仕組みを定義します。 [REPORTING]

サイトは、ポリシーを強制する前に、 実際の環境で試したい場合もあります。この節では「Report-only」モードも定義します。このモードでは、 ユーザーエージェントはポリシー違反となる状況を監視し、 ポリシーを強制せずにそれらを報告できます。これによりサイト所有者は、 実際にポリシーをデプロイする前に、 実環境での違反数を許容可能なレベルまで減らすための作業を行えます。

報告は、ポリシーを設定するページからのみ可能です。 必須ポリシーに違反するネストされたページから報告を受け取ることはできません。

「違反」は機能ごとに定義されますが、常にユーザー自身の直接的な行動ではなく、 ウェブ開発者の行動を反映すべきです。

これは、すべてのポリシーを報告できるわけではないことを意味します。 マークアップやスクリプトの操作によって意味のある形で「違反」されたとは言えない設定を持つ 機能の種類があります。たとえば、 フォームフィールドへのテキスト入力を無効にする仮想的な機能は、 ユーザーエージェントによって強制できますが、 ユーザーがそのフィールドへの入力を試みて強制が 必要になったとしても、それはポリシー違反を表すものではなく、 報告すべきではありません。

6.1. 文書内報告の設定

6.1.1. 「report-to」パラメーター

どのディレクティブにも report-to という名前のパラメーターを含めることができ、 その機能の違反報告の送信先となる報告 エンドポイントを指定します。

例:

Document-Policy: something=1.0;report-to=endpoint1, something-else=?0;report-to=endpoint2

6.1.2. 既定の報告エンドポイントの設定

多数またはすべての機能の違反を同じエンドポイントへ送信すべき場合、 単一の既定の エンドポイントを定義する方が簡単な場合があります。これは、 特別なトークン * のパラメーターによって定義できます。既定の エンドポイントが 指定されている場合、別途指定されない限り、すべての違反 報告はその名前付きエンドポイントへ送信されます。機能が report-to パラメーターで 独自のエンドポイントも指定している場合、報告は代わりにその エンドポイントへ送信されます。(報告は両方のエンドポイントには送信されません。)

例:

Document-Policy: something=1.0, something-else=?0, *;report-to=endpoint

6.1.3. 機能に対する報告の無効化

既定のエンドポイントが指定されている場合、特定の機能について 報告を無効にする必要がある場合があります。これは、report-to パラメーターの値として 特別なエンドポイント名 none を指定することで実現できます。 これにより既定のエンドポイントが上書きされ、その 機能について報告が無効になります。

例:

Document-Policy: something=1.0;report-to=none, something-else=?0,
                 *;report-to=endpoiont

6.2. 報告専用モード

文書ポリシーは「report-only」ポリシーにすることができます。報告専用ポリシーは Document-Policy-Report-Only ヘッダーで指定されます。 報告専用ポリシーへの違反は、強制ポリシーの場合と同様に 報告を生成しますが、ユーザーエージェントに その他の処理を実行させることはありません。

Document-Policy-Report-Only

report-to ディレクティブパラメーターは、この ヘッダー内のディレクティブとともに使用すべきです。そうしない場合、それらはまったく効果を持ちません。

例:

Document-Policy-Report-Only: something=1.0;report-to=endpoint,
                             something-else=?0;report-to=endpoint2

7. 配信

7.1. 構造化ヘッダーとしてのポリシー

ポリシーは HTTP ヘッダーおよび HTML 属性で、 sh-dictionary 構造の直列化として表現されます。各辞書メンバーは 文書ポリシー ディレクティブです。

文書 ポリシーディレクティブは、直列化された文書 ポリシーの要素であり、sh-token である ディレクティブ名と、 関連付けられた パラメーターから構成されます。

ディレクティブ名は、次のいずれかです。

ポリシー値は、名前付き 設定ポイント範囲の要素です。

7.1.1. パラメーター

どの 文書ポリシーディレクティブにも、 値が文字列でなければならない report-to という名前のパラメーターを含めることができます。

文書ポリシーディレクティブディレクティブ名が、設定 ポイントを指し、その boolean の場合、必須パラメーターはありません。

文書ポリシーディレクティブディレクティブ名が、設定 ポイントを指し、その integer の場合、必須パラメーターを持ち、 その値は 設定ポイント範囲内の integer でなければなりません。

文書ポリシーディレクティブディレクティブ名が、設定 ポイントを指し、その float の場合、必須パラメーターを持ち、 その値は 設定ポイント範囲内の decimal でなければなりません。

文書ポリシーディレクティブディレクティブ名が、設定 ポイントを指し、その enum の場合、必須パラメーターを持ち、 その値は 'true' でなければならず、 その名前は 設定ポイント範囲内のトークンでなければなりません。

例:

7.2. HTTP ヘッダー

7.2.1. Document-Policy

`Document-Policy` HTTP ヘッダーは、クライアントが強制すべき 文書ポリシーを 通知するため、レスポンス(サーバーからクライアント)で使用できます。

Document-Policy ヘッダーは Structured Header です。その値は dictionary でなければなりません。その ABNF は次のとおりです。

Document-Policy = sh-dictionary

辞書メンバー名が、サポートされている設定ポイントまたは 特別な値「*」を指していない場合、その辞書メンバーは 処理手順によって無視されます。

7.2.2. Document-Policy-Report-Only

`Document-Policy-Report-Only` HTTP ヘッダーは、文書の 報告専用文書ポリシーを設定するため、 レスポンス(サーバーからクライアント)で使用できます。

Document-Policy-Report-Only ヘッダーは Structured Header です。 その値は dictionary でなければなりません。Document-Policy ヘッダーとまったく同じ構文を持ちます。

7.2.3. Require-Document-Policy

`Require-Document-Policy` HTTP ヘッダーフィールドは、すべてのネストされた コンテンツに適用する最小限の 必須文書ポリシーを クライアントへ通知するために使用されるレスポンスヘッダーです。

Require-Document-Policy ヘッダーは Structured Header dictionary で、 Document-Policy ヘッダーとまったく同じ構文を持ちます。

7.2.4. Sec-Required-Document-Policy

`Sec-Required-Document-Policy` HTTP ヘッダーフィールドは、そのリクエストに対して返される文書とともに 送信されなければならない 文書 ポリシーをサーバーに通知するために使用されるリクエストヘッダーです。

このヘッダーの値は、1 つ以上の 文書ポリシーディレクティブ§ 5 必須ポリシーの直列化です。

7.3. iframe 要素の policy 属性

iframe 要素には「policy」属性があり、必須 ポリシーディレクティブ(SH 形式)を含みます。

8. 統合

フレームに必須ポリシーがある場合、そのポリシーは、 ユーザーエージェントによって文書に適用される ポリシーをサーバーに知らせるため、外向きのすべての文書リクエストの リクエストヘッダーで通知されなければなりません。これにより、 サーバーは返される表現を変更して、その ポリシーに適合させることができます。

必須ポリシーのリクエストヘッダーが存在する場合、 レスポンスには互換性のある文書ポリシーヘッダーが含まれていなければならず、そうでない場合 fetch は失敗します。

8.1. HTML との統合

次の変更を [HTML] に組み込むべきです。

  • iframe 要素に次の IDL を追加すべきです。

[CEReactions] attribute DOMString policy;

8.2. Fetch との統合

次の変更を [FETCH] に組み込むべきです。

9. アルゴリズム

9.1. ポリシーは互換性があるか?

2 つの 文書 ポリシーrequiredPolicydeclaredPolicy が与えられたとき、 このアルゴリズムは declaredPolicyrequiredPolicy と互換性がある場合は true を返し、そうでない場合は false を返します。
  1. requiredPolicy 内の各 configuration pointvalue について:

    1. declaredPolicy[configuration point] が存在しない場合、 false を返します。

    2. valuedeclaredPolicy[configuration point] より厳格な場合、 false を返します。

  2. true を返します。

9.2. 文書ポリシーを解析する

dictionary(header)が与えられたとき、このアルゴリズムは、 文書 ポリシーとして解析できる場合はそれを返し、そうでない場合は失敗します。
  1. header が null の場合、null を返します。

  2. policy を新しい順序付きマップとします。

  3. defaultEndpoint を、null に設定された新しい文字列とします。

  4. header 内の各 name->(value,parameters) について、

    1. currentEndpoint を、null に設定された新しい文字列とします。

    2. parameters["report-to"] が存在し、かつ文字列である場合:

      1. currentEndpointparameters["report-to"] の値に設定します。

    3. name が文字列「*」である場合:

      1. defaultEndpointcurrentEndpoint に設定します。

    4. そうでなく、name がサポートされている設定ポイントの名前である場合:

      1. configuration point を、名前が name である サポートされている設定ポイントとします。

      2. policy[configuration point] が存在する場合、 次の element へ進みます。

      3. configuration point の型が boolean である場合:

        1. value が Boolean でない場合、失敗します。

        2. policy[configuration point] を、 ポリシー 設定の新しい boolean 値に設定します。その value報告 エンドポイントcurrentEndpoint とします。

        3. 次の element へ進みます。

      4. configuration point の型が enum である場合:

        1. value が Token でない場合、失敗します。

        2. valueconfiguration point の 許可された enum 値のいずれかの名前でない場合、失敗します。

        3. policy[configuration point] を、 ポリシー 設定の新しい enum 値に設定します。その value報告 エンドポイントcurrentEndpoint とします。

        4. 次の element へ進みます。

      5. configuration point の型が integer である場合:

        1. value が Integer でない場合、失敗します。

        2. valueconfiguration point の範囲内にない場合、 失敗します。

        3. policy[configuration point] を、 ポリシー 設定の新しい integer 値に設定します。その value報告 エンドポイントcurrentEndpoint とします。

        4. 次の element へ進みます。

      6. configuration point の型が float である場合:

        1. value が Decimal でない場合、失敗します。

        2. valueconfiguration point の範囲内にない場合、 失敗します。

        3. policy[configuration point] を、 ポリシー 設定の新しい float 値に設定します。その value報告 エンドポイントcurrentEndpoint とします。

        4. 次の element へ進みます。

  5. policy 内の各 configuration pointconfig について、

    1. config報告 エンドポイントがない場合、config報告 エンドポイントdefaultEndpoint に設定します。

  6. policy を返します。

9.3. 必須ポリシーを直列化する

文書ポリシーrequiredPolicy)が与えられたとき、この アルゴリズムは、ポリシーの正準直列化を表す 文字列を返します。
  1. dict を新しい順序付きマップとします。

  2. featuresrequiredPolicy のキーとします。

  3. features を各要素の名前によって ASCII 順に並べ替えます。

  4. features 内の各 feature について:

    1. valuerequiredPolicy[feature] とします。

    2. dict[feature] を value に設定します。

  5. dict の直列化を返します。

9.4. 閲覧コンテキスト用の 必須ポリシーを作成する

閲覧コンテキストbrowsingContext)が与えられたとき、この アルゴリズムは 新しい 文書ポリシーを返します。
  1. browsingContextネストされた閲覧コンテキストである場合:

    1. requiredPolicybrowsingContextコンテナー文書ネストされたコンテキストの 必須文書 ポリシーの複製とします。

    2. browsingContext閲覧コンテキストコンテナーが 「policy」属性を持つ場合:

      1. containerPolicy を、その属性を解析した結果とします。

      2. containerPolicy 内の各 feature -> value について:

        1. requiredPolicy[feature] が存在しない場合、または valuerequiredPolicy[feature] より厳格な場合、 requiredPolicy[feature] を value に設定します。

  2. そうでない場合、requiredPolicy を新しい順序付きマップとします。

  3. requiredPolicy を返します。

9.5. レスポンスから 文書ポリシーを作成する

閲覧コンテキストbrowsingContext)と レスポンスresponse)が与えられたとき、このアルゴリズムは 新しい 文書ポリシーを返します。
  1. requiredPolicy を、browsingContext を与えて 閲覧コンテキスト用の必須ポリシーを 作成するを実行した結果とします。

  2. header を、responseヘッダーリストから、 ヘッダー名 Document-Policy および型 「dictionary」を指定して 構造化フィールド値を 取得するを呼び出した結果とします。

  3. declaredPolicy を、header に対して 文書 ポリシーを解析するを実行した結果とします。

  4. declaredPolicyrequiredPolicy互換性がある場合、 declaredPolicy を返します。

  5. 例外をスローします。

9.6. レスポンスからネストされたコンテキストの 必須文書ポリシーを作成する

閲覧コンテキストbrowsingContext)と レスポンスresponse)が与えられたとき、このアルゴリズムは 新しい 文書ポリシーを返します。
  1. requiredPolicy を、browsingContext必須文書ポリシーの複製とします。

  2. header を、responseヘッダーリストから、 ヘッダー名 Required-Document-Policy および 型「dictionary」を指定して 構造化 フィールド値を取得するを呼び出した結果とします。

  3. declaredNestedPolicy を、header に対して 文書ポリシーを 解析するを実行した結果とします。

  4. declaredNestedPolicy 内の各 feature -> value について:

    1. requiredPolicy[feature] が存在しない場合、または valuerequiredPolicy[feature] より厳格な場合、 requiredPolicy[feature] を value に設定します。

  5. requiredPolicy を返します。

9.7. 文書ポリシーによって リクエストへのレスポンスをブロックすべきか?

リクエストrequest)と、そのリクエストに対する レスポンスresponse)が与えられたとき、 このアルゴリズムは、レスポンスがリクエストの必須ポリシーと 互換性がない場合は「blocked」を返し、そうでない場合は「valid」を返します。
  1. request必須文書 ポリシーを持つ場合:

    1. documentPolicy を、responseヘッダーリストから、 ヘッダー名 Document-Policy および 型「dictionary」を指定して 構造化 フィールド値を取得するを呼び出した結果とします。

    2. documentPolicyrequest必須文書 ポリシー互換性がない場合、 「blocked」を返します。

    3. 「valid」を返します。

9.8. 文書内の機能のポリシー値を取得する

feature(feature)と Document オブジェクト(document)が与えられたとき、この アルゴリズムは document文書 ポリシー内の feature の値を返します。
  1. policydocument文書ポリシーとします。

  2. policy[feature] が存在する場合、その を返します。

  3. feature既定値を返します。

9.9. 機能の値と ポリシーとの互換性を判定する

value(value)、feature(feature)、および Document オブジェクト (document)が与えられたとき、このアルゴリズムは次からなるタプルを返します。
  • action。valuedocument文書ポリシーと互換性があるかどうかに応じて、 「compatible」または「incompatible」のいずれか。

  • 報告エンドポイント名。valuedocument文書 ポリシーおよびその 報告専用 文書ポリシーの両方と互換性がある場合、または feature に対して報告が設定されていない場合は null、それ以外の場合は、違反報告を送信すべき 報告エンドポイントの名前。

強制ポリシーが報告専用ポリシーより厳格な場合、 報告専用ポリシーは検査されないことに注意してください。

  1. policydocument文書 ポリシーとします。

  2. policyConfig を、存在する場合は policy[feature]、 そうでない場合は feature既定値と null からなるタプルとします。

  3. policyValuereporting endpointpolicyConfig の要素とします。

  4. policyValuevalue より厳格な場合、 「incompatible」と reporting endpoint からなるタプルを返します。

  5. report-only policydocument報告専用文書 ポリシーとします。

  6. report-only policyConfig を、存在する場合は report-only policy[feature]、 そうでない場合は feature既定値と null からなるタプルとします。

  7. policyValuereporting endpointreport-only policyConfig の要素に設定します。

  8. policyValuevalue より厳格な場合、 「compatible」と reporting endpoint からなるタプルを返します。

  9. (「compatible」、null)を返します。

9.10. 値が 機能のポリシーと互換性があるかを判定し、必要に応じて報告する

value(value)、feature(feature)、および Document オブジェクト (document)が与えられたとき、このアルゴリズムは valuedocument文書ポリシーと互換性がある場合は「compatible」を返し、 そうでない場合は「incompatible」を返します。報告が設定されている場合は、 報告もキューに入れます。
  1. actionreporting endpoint)を、 valuefeaturedocument を指定して 互換性を判定するを呼び出した結果とします。

  2. reporting endpoint が null でない場合、

    1. body を、次のプロパティを持つ新しい ECMAScript オブジェクトとします。 [ECMA-262]

      featureId

      feature の文字列表現。

      sourceFile

      null

      lineNumber

      null

      columnNumber

      null

      disposition

      action が「incompatible」の場合は「enforce」、 そうでない場合は「report」。

    2. ユーザーエージェントが現在スクリプトを実行中であり、settings から ソースファイルの URL、行番号、列番号を抽出できる場合、 body の sourceFile、lineNumber、columnNumber をそれに応じて設定します。

    3. settingsdocument環境設定 オブジェクトとします。

    4. body、「document-policy-violation」、reporting endpointsettings を指定して Reporting API § 2.3 宛先に対して型としてデータをキューに入れるを実行します。

  3. action を返します。

9.11. 値が機能のポリシーと互換性があるかを 判定する

value(value)、feature(feature)、および Document オブジェクト (document)が与えられたとき、このアルゴリズムは valuedocument文書ポリシーと互換性がある場合は「compatible」を返し、 そうでない場合は「incompatible」を返します。
  1. actionreporting endpoint)を、 valuefeaturedocument を指定して 互換性を判定するを 呼び出した結果とします。

  2. action を返します。

10. IANA に関する考慮事項

恒久的メッセージヘッダーフィールドレジストリは、 次の登録内容 [RFC3864] で更新されるべきです。

ヘッダーフィールド名
Document-Policy
適用可能なプロトコル
http
状態
standard
作者/変更管理者
W3C
仕様文書
Document Policy API
ヘッダーフィールド名
Require-Document-Policy
適用可能なプロトコル
http
状態
standard
作者/変更管理者
W3C
仕様文書
Document Policy API
ヘッダーフィールド名
Sec-Required-Document-Policy
適用可能なプロトコル
http
状態
standard
作者/変更管理者
W3C
仕様文書
Document Policy API

11. プライバシーとセキュリティ

この仕様は、埋め込み側ページが、 埋め込まれたページで強制されるポリシーを設定する仕組みを標準化します。ただし、既存の iframe の sandbox の仕組みとは異なり、必須ポリシーへの明示的な承認が必要です。 これは、公開済みのウェブサイトにおける既存機能の動作を、 それらのサイトの協力なしに変更することはできないことを意味します。

このモデルについて留意すべきプライバシーおよびセキュリティ上の考慮事項が いくつかあります。

  • クロスオリジンサブフレーム内の動作が埋め込み側に公開されること。

  • ポリシーを通じて埋め込み側の状態が埋め込まれた文書に公開されること。

  • 必須ポリシーを無条件に受け入れることによる、予期しない動作変更。

ある程度、これらの懸念はすでにウェブプラットフォームに存在しており、 この仕様は少なくとも、それらを不必要に悪化させないよう試みています。

セキュリティおよびプライバシー上の問題は、個々の 設定ポイントの設計によっても生じる可能性があるため、この 仕様と統合する際には注意が必要です。この節では、そのような問題を 引き起こし得る動作の種類について、いくらかの指針を提供します。

11.1. クロスオリジン動作の公開

設定ポイントは、フレーム化された文書内のポリシー違反が 他のフレーム内の文書から観測できないように設計すべきです。たとえば、 ポリシーによって無効にされているときに機能が使用されると 埋め込み側文書でイベントを発火する仮想的な機能は、 埋め込まれた文書の状態に関する情報を抽出するために使用され得ます。たとえば、 その機能がユーザーがサイトにログインしているときにのみ使用されることが分かっている場合、 埋め込み側はそのフレームでその機能を無効にし、その結果発生する イベントを監視して、ユーザーがログインしているかどうかを判定できてしまいます。

さらに、通常は文書から利用できない クロスオリジンリソースの内容に関する情報が、ポリシーによって 可視化されないよう注意する必要があります。たとえば画像の内容には機密 情報が含まれている可能性があり、細粒度のポリシーによって攻撃者が ポリシーの設定パラメーターを慎重に調整することで 画像の内容について何らかのことを推測できる可能性があります。サブリソースの内容に作用するポリシーは、 読み取り不能なリソースを除外するか、そのリソースについて 推測できる情報量を制限するための措置を講じるべきです。

上で説明した動作変更の問題を緩和するため、 必須ポリシーを持つフレーム内の埋め込みコンテンツへのリクエストは、 ポリシー要件の詳細を示す HTTP ヘッダーとともに送信されます。このヘッダーは オリジンサーバーから見ることができ、その内容は埋め込み側ページの詳細を 明らかにする可能性があります。埋め込み側は、埋め込みコンテンツに ポリシーを要求することを選択する際、この点を認識すべきです。

11.3. 必須ポリシーの無条件な受け入れ

読み込まれるためには埋め込み側が要求するポリシーに準拠する必要があるため、 サイト所有者は、ウェブサーバーを設定して、 Sec-Required-Document-Policy リクエストヘッダーをレスポンスの Document-Policy ヘッダーにそのまま反映させたいと考えるかもしれません。 これにより文書のポリシーが常にリクエストと互換性を持つことは保証されますが、 既存 API の動作を無効化または変更することで、 埋め込み側が埋め込まれた文書内の制御フローを変更できる危険に その文書をさらす可能性があります。これは特に、コンテンツが書かれた後に 新しい設定ポイントが文書ポリシーモデルへ追加された場合に当てはまります。 将来起こり得るすべての新しい動作変更に対して文書を 将来互換にすることは困難です。

必須文書ポリシーを持つコンテキストに埋め込まれることを想定するサイトは、 サポート可能であると分かっている実際の最も厳格なポリシーを 設定するか、把握していて、動作変更の潜在的な 範囲を理解している設定ポイントについてのみ、 受信したポリシーを反映することで、この問題を緩和できます。

適合性

文書の 規約

適合性要件は、 記述的な表明と RFC 2119 の用語を組み合わせて表現されます。 この文書の規範的部分におけるキーワード “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, および “OPTIONAL” は、RFC 2119 で説明されているとおりに解釈されます。 ただし、読みやすさのため、 この仕様ではこれらの語はすべて大文字では表示されません。

この仕様のすべてのテキストは規範的です。 ただし、非規範的であることが明示的に示された節、例、および注記を除きます。 [RFC2119]

この仕様における例は、“for example” という語で導入されるか、 規範的なテキストから分離され、 class="example" を用いて 次のように示されます:

これは参考情報としての例の一例です。

参考情報としての注記は “Note” という語で始まり、 規範的なテキストから分離され、 class="note" を用いて 次のように示されます:

注記、これは参考情報としての注記です。

適合 アルゴリズム

アルゴリズムの一部として命令形で記述された要件 (たとえば "strip any leading space characters" や "return false and abort these steps" など)は、 そのアルゴリズムを導入する際に用いられたキーワード ("must", "should", "may" など)の意味で解釈されます。

アルゴリズムまたは特定の手順として記述された適合性要件は、 最終結果が同等である限り、 任意の方法で実装できます。 特に、この仕様で定義されるアルゴリズムは 理解しやすいことを意図しており、 高性能であることを意図していません。 実装者は最適化することが推奨されます。

索引

この仕様で定義される用語

参照により定義される用語

参考文献

規範的参考文献

[DOM]
Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[FETCH]
Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[REPORTING]
Douglas Creager; et al. Reporting API. 25 September 2018. WD. URL: https://www.w3.org/TR/reporting-1/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC3864]
G. Klyne; M. Nottingham; J. Mogul. Registration Procedures for Message Header Fields. September 2004. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc3864

参考情報としての参考文献

[CSP]
Mike West. Content Security Policy Level 3. 29 June 2021. WD. URL: https://www.w3.org/TR/CSP3/
[ECMA-262]
ECMAScript Language Specification. URL: https://tc39.es/ecma262/multipage/
[PERMISSIONS-POLICY]
Ian Clelland. Permissions Policy. 16 July 2020. WD. URL: https://www.w3.org/TR/permissions-policy-1/

課題索引

設定ポイントは複数の パラメーターを持てるようにすべきでしょうか?おそらくパラメーターは、名前、 型、および範囲を持つものとして別々に定義されるべきです。