ドキュメントポリシー

コミュニティグループレポート草案、

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

概要

この仕様は、開発者が...

この文書のステータス

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

1. はじめに

この文書は、Web プラットフォームの一部として構成可能な機能を設計するためのフレームワークであり、 Web 開発者がサイトのデプロイメントの一部としてそれらの機能を構成できるようにする Document Policy を定義します。

2. 例 #

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

Document Policy は、文書構成のための既存のいくつかのメカニズムとスコープが類似していますが、 それぞれとは重要な違いがあります。

3.1. Permissions Policy との関係

Permissions Policy [PERMISSIONS-POLICY] は、作成者が文書内の機能を構成できるようにする 別のメカニズムであり、スコープは類似していますが、 異なる継承メカニズムを使用しているため、 Document Policy による制御に適したものとは別の種類の機能に適しています。

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

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

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

3.2. Content Security Policy との関係

Content-Security-Policy [CSP] も文書内の「機能」を構成しますが、 主にページ内のリソースのオリジンに関係しており、 それらのリソースがロードされた後に何を実行できるかを制御することを主な目的とはしていません。

CSP はまた、sandbox ディレクティブを通じて文書にサンドボックスフラグを設定する 別のメカニズムを提供します。 サンドボックスフラグが document policy に移動された場合、 2 つのヘッダーが同一の情報をエンコードする可能性があるため、 これは冗長になる可能性があります。

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

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

Iframe のサンドボックス化は、文書内の機能を制御する別のメカニズムであり、 document policy の必須ポリシーと非常によく似た動作をします。 機能を無効化することはフレームに適用でき、 そのフレームにロードされるすべてのコンテンツに影響します。

iframe sandbox 属性によって制御される機能は、 document policy を使用して非常に自然に表現できます。

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

4. フレームワーク

4.1. 構成ポイント

構成 ポイントとは、Document Policy を通じて有効化、無効化、または構成できる Web Platform API または動作です。 構成ポイントは、基礎となる API または動作を説明する仕様内で定義されるべきですが、 この文書には使用中の定義済み構成ポイントのレジストリも添付されています。

構成 ポイントには、名前があり、これは tokenです。

構成 ポイントには、型があり、以下のいずれかです。

  • boolean、

  • integer、

  • float、または

  • enum。

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

構成 ポイントには、 その範囲の要素である デフォルト値があります。

構成ポイントは 複数のパラメーターを持つことを許可されるべきでしょうか。 おそらくパラメーターは、名前、型、範囲とともに個別に定義されるべきです。
新しい構成ポイントを導入する際には、デフォルト 値は慎重に選択されるべきであり、 Web 互換性を最も重視する必要があります。 文書に明示的なポリシーが宣言されていない場合、デフォルト値が適用されます。

4.2. ポリシー

document policyは、 構成ポイントから ポリシー構成への順序付きマップです。

ポリシー 構成は、以下で構成されるタプルです。 値は、 構成ポイントの 範囲の要素であり、 レポートエンドポイントは文字列で、 null になる場合があります。

browsing contextには 必須 document policyがあり、 これはdocument policyです。 browsing contextに null のopener browsing contextがある場合、 必須 document policyは空になります。

Documentには ネストされたコンテキストの必須 document policyがあり、 これはdocument policyです。

Documentには document policyがあり、 これはdocument policyです。

Documentには report-only document policyがあり、 これはdocument policyです。

5. 必須ポリシーのシリアライズ

  • 必須ポリシーが Structured Headers として シリアライズされる方法をここで説明します。

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

6. レポート

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

このセクションでは、[REPORTING] Reporting API を使用して、 そのような違反をレポートするメカニズムを定義します。

サイトはまた、ポリシーを適用する前に、実際の状況でポリシーをテストしたい場合があります。 このセクションでは、ユーザーエージェントがポリシー違反となる状況を監視してレポートできる 「Report-only」モードも定義します。 これはポリシーを適用せずに行われます。 これにより、サイト所有者は実際にポリシーを展開する前に、 現実世界での違反数を許容可能なレベルまで減らすことができます。

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

「違反」は機能ごとに定義されますが、 常にユーザーが直接行った操作ではなく、Web 開発者の操作を反映する必要があります。

これは、すべてのポリシーがレポート可能であるとは限らないことを意味します。 マークアップやスクリプト操作によって、その設定が意味のある形で「違反」されたとは言えない 機能のクラスが存在します。 例えば、フォームフィールドへのテキスト入力を無効化する仮想的な機能は、 ユーザーエージェントによって強制できますが、 ユーザーがそのフィールドに入力しようとして強制が必要になった場合、 それはポリシー違反を表すものではなく、レポートされるべきではありません。

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. デフォルトのレポートエンドポイントの設定

多くまたはすべての機能に対する違反を同じエンドポイントに送信する必要がある場合、 単一のデフォルト エンドポイントを 定義する方が簡単な場合があります。 これは、特別な token * のパラメーターによって定義できます。 デフォルトの エンドポイントが提供されている場合、 別途指定されない限り、すべての違反レポートはその名前付きエンドポイントに送信されます。 機能が 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=endpoint

6.2. レポートのみ モード

document policy は「report-only」ポリシーにすることができます。 Report-only ポリシーは Document-Policy-Report-Only ヘッダーで指定されます。 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. Structured Headers としてのポリシー

ポリシーは、HTTP ヘッダーおよび HTML 属性内で、 sf-dictionary 構造のシリアライズとして表現されます。 各辞書メンバーは document policy directive です。

document policy directive は、 serialized document policy の要素であり、 directive name と、 関連付けられた パラメーターで構成されます。 directive name は sf-token です。

directive name は以下のいずれかです。

policy value は、 名前付き configuration point の range の要素です。

7.1.1. パラメーター

任意の document policy directive には、 report-to という名前のパラメーターを含めることができ、 その値は token でなければなりません。

document policy directive の directive name が configuration point を示し、 その type が boolean の場合、 必須パラメーターはありません。

document policy directive の directive name が configuration point を示し、 その type が integer の場合、 必須パラメーターがあり、その値は configuration point の range 内の整数でなければなりません。

document policy directive の directive name が Configuration point を示し、 その type が float の場合、 必須パラメーターがあり、その値は configuration point の range 内の小数でなければなりません。

document policy directive の directive name が configuration point を示し、 その type が enum の場合、 必須パラメーターがあり、その値は 'true' でなければならず、 その名前は token であり、 configuration point の range 内に存在しなければなりません。

例:

  • boolean-feature

  • boolean-feature=?0

  • integer-feature=2

  • float-feature=-0.2

  • enum-feature=state

7.2. HTTP ヘッダー

7.2.1. Document-Policy

`Document-Policy` HTTP ヘッダーは、response(サーバーからクライアント)で使用して、 クライアントによって適用されるべき document policy を伝達できます。

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

Document-Policy = sf-dictionary

いずれかの dictionary メンバー名がサポートされている configuration point または特別な値 "*" を示していない場合、 その dictionary メンバーは処理手順によって無視されます。

7.2.2. Document-Policy-Report-Only

`Document-Policy-Report-Only` HTTP ヘッダーは、response(サーバーからクライアント)で使用して、 文書の report-only document policy を構成できます。

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

7.2.3. Require-Document-Policy

`Require-Document-Policy` HTTP ヘッダーフィールドは response ヘッダーであり、 すべてのネストされたコンテンツに適用する最小限の required document policy をクライアントに伝達するために使用されます。

Require-Document-Policy ヘッダーは Structured Header dictionary であり、 Document-Policy ヘッダーと完全に同じ構文を持ちます。

7.2.4. Sec-Required-Document-Policy

`Sec-Required-Document-Policy` HTTP ヘッダーフィールドは request ヘッダーであり、 リクエストによって返される文書とともに送信されなければならない document policy をサーバーに伝達するために使用されます。

このヘッダーの値は、1 つ以上の document policy directive の § 5 必須ポリシーのシリアライズ です。

7.3. iframe 要素の policy 属性

iframe 要素には "policy" 属性があり、 これには必須の policy directive(SH 形式)が含まれます。

8. 統合

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

必須ポリシーの request ヘッダーが存在する場合、response には互換性のある document policy ヘッダーが含まれていなければならず、 そうでなければ fetch は失敗します。

8.1. HTML との統合

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

  • iframe 要素には以下の IDL を追加するべきです。

[CEReactions] attribute DOMString policy;

8.2. Fetch との統合

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

9. アルゴリズム

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

2 つの document policy、 requiredPolicy および declaredPolicy が与えられた場合、 このアルゴリズムは declaredPolicy が requiredPolicy と互換性がある場合は true を返し、 それ以外の場合は false を返します。
  1. requiredPolicy 内の各 configuration point → value について:

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

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

  2. true を返します。

9.2. ドキュメントポリシーを解析する

dictionary (header) が与えられた場合、 このアルゴリズムは、それとして解析できる場合は document policy を返し、 それ以外の場合は失敗します。
  1. header が null の場合、null を返します。

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

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

  4. header 内の各 name→(value,parameters) について:

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

    2. parameters["report-to"] が存在し、 token である場合:

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

    3. name が文字列 "*" の場合:

      1. defaultEndpoint を currentEndpoint に設定します。

    4. それ以外で、name がサポートされている configuration point の名前の場合:

      1. configuration point を、 名前が name であるサポートされた configuration point とします。

      2. policy[configuration point] が存在する場合、 次の element に続行します。

      3. configuration point の type が boolean の場合:

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

        2. policy[configuration point] を、 新しい boolean policy configuration として設定します。 その value は value、 reporting endpoint は currentEndpoint です。

        3. 次の element に続行します。

      4. configuration point の type が enum の場合:

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

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

        3. policy[configuration point] を、 新しい enum policy configuration として設定します。 その value は value、 reporting endpoint は currentEndpoint です。

        4. 次の element に続行します。

      5. configuration point の type が integer の場合:

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

        2. value が configuration point の range 内に 存在しない場合、失敗します。

        3. policy[configuration point] を、 新しい integer policy configuration として設定します。 その value は value、 reporting endpoint は currentEndpoint です。

        4. 次の element に続行します。

      6. configuration point の type が float の場合:

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

        2. value が configuration point の range 内に 存在しない場合、失敗します。

        3. policy[configuration point] を、 新しい float policy configuration として設定します。 その value は value、 reporting endpoint は currentEndpoint です。

        4. 次の element に続行します。

  5. policy 内の各 configuration point → config について:

    1. config が reporting endpoint を持たない場合、 config の reporting endpoint を defaultEndpoint に設定します。

  6. policy を返します。

9.3. 必須ポリシーをシリアライズする

document policy(requiredPolicy)が与えられた場合、 このアルゴリズムは、そのポリシーの正規シリアライズを表す 文字列を返します。
  1. dict を新しい順序付きマップとします。

  2. features を requiredPolicy のキーとします。

  3. features を、各要素の名前によって ASCII 順でソートします。

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

    1. value を requiredPolicy[feature] とします。

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

  5. dict のシリアライズ結果を返します。

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

browsing context (browsingContext)が与えられた場合、 このアルゴリズムは新しい Document Policy を返します。
  1. browsingContext が nested browsing context の場合:

    1. requiredPolicy を、 browsingContext の container document の nested context required document policy のクローンとします。

    2. browsingContext の browsing context container に "policy" 属性がある場合:

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

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

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

  2. それ以外の場合、requiredPolicy を新しい順序付きマップとします。

  3. requiredPolicy を返します。

9.5. レスポンスからドキュメントポリシー を作成する

browsing context (browsingContext)と response (response)が与えられた場合、 このアルゴリズムは新しい Document Policy を返します。
  1. requiredPolicy を、 browsingContext を指定して browsing context 用の必須ポリシーを作成する を実行した結果とします。

  2. header を、response の header list からヘッダー名 Document-Policy、 型 "dictionary" で get a structured field value を呼び出した結果とします。

  3. declaredPolicy を、 header に対して document policy を解析する を実行した結果とします。

  4. declaredPolicy が 互換性がある 場合、requiredPolicy と互換性があるなら、 declaredPolicy を返します。

  5. 例外を投げます。

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

browsing context (browsingContext)と response (response)が与えられた場合、 このアルゴリズムは新しい Document Policy を返します。
  1. requiredPolicy を、 browsingContext の required document policy のクローンとします。

  2. header を、response の header list からヘッダー名 Required-Document-Policy、 型 "dictionary" で get a structured field value を呼び出した結果とします。

  3. declaredNestedPolicy を、 header に対して document policy を解析する を実行した結果とします。

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

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

  5. requiredPolicy を返します。

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

request (request)と、その request に対する response (response)が与えられた場合、 このアルゴリズムは response が request の required policy と互換性がない場合は "blocked" を返し、それ以外の場合は "valid" を返します。
  1. request が required document policy を持つ場合:

    1. documentPolicy を、response の header list からヘッダー名 Document-Policy、 型 "dictionary" で get a structured field value を呼び出した結果とします。

    2. documentPolicy が request の required document policy と互換性がない場合、 "blocked" を返します。

    3. "valid" を返します。

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

機能(feature)と Document オブジェクト(document)が与えられた場合、 このアルゴリズムは document の document policy 内の feature の値を返します。
  1. policy を document の Document Policy とします。

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

  3. feature の default value を返します。

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

値(value)、機能(feature)および Document オブジェクト(document)が与えられた場合、 このアルゴリズムは以下で構成されるタプルを返します。
  • アクション。 これは、value が document の document policy と互換性があるかどうかに応じて、 "compatible" または "incompatible" のいずれかです。

  • レポートエンドポイント名。 これは、value が document の document policy および その report-only document policy の両方と互換性がある場合、 または feature に対してレポートが構成されていない場合は null になります。 それ以外の場合は、違反レポートを送信する reporting endpoint の名前になります。

適用ポリシーが report-only ポリシーより厳格な場合、 report-only ポリシーはチェックされないことに注意してください。

  1. policy を document の Document Policy とします。

  2. policyConfig を、存在する場合は policy[feature] とし、 それ以外の場合は feature の default value と null からなるタプルとします。

  3. policyValue および reporting endpoint を policyConfig の要素とします。

  4. policyValue が value より厳格な場合、 "incompatible" と reporting endpoint からなるタプルを返します。

  5. report-only policy を document の report-only document policy とします。

  6. report-only policyConfig を、存在する場合は report-only policy[feature] とし、 それ以外の場合は feature の default value と null からなるタプルとします。

  7. policyValue および reporting endpoint を report-only policyConfig の要素に設定します。

  8. policyValue が value より厳格な場合、 "compatible" と reporting endpoint からなるタプルを返します。

  9. ("compatible", null) を返します。

9.10. 値が機能に対するポリシーと互換性があるか、または レポートするかを決定する

値(value)、機能(feature)および Document オブジェクト(document)が与えられた場合、 このアルゴリズムは value が document の document policy と互換性がある場合は "compatible"、 それ以外の場合は "incompatible" を返します。 また、レポートが構成されている場合はレポートをキューに追加します。
  1. (action, reporting endpoint) を、 value、feature、document を使用して determine-compatibility を呼び出した結果とします。

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

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

      featureId

      feature の文字列表現。

      sourceFile

      null

      lineNumber

      null

      columnNumber

      null

      disposition

      action が "incompatible" の場合は "enforce"、 それ以外の場合は "report"。

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

    3. settings を document の environment settings object とします。

    4. Reporting API § 2.3 Queue data as type for destination を、body、 "document-policy-violation"、 reporting endpoint、 settings とともに実行します。

  3. action を返します。

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

値(value)、機能(feature)および Document オブジェクト(document)が与えられた場合、 このアルゴリズムは value が document の document policy と互換性がある場合は "compatible"、 それ以外の場合は "incompatible" を返します。
  1. (action, reporting endpoint) を、 value、feature および document を使用して determine-compatibility を呼び出した結果とします。

  2. action を返します。

10. IANA 考慮事項

永続的な message header field レジストリは、以下の登録によって更新されるべきです [RFC3864]。

Header field name
Document-Policy
Applicable protocol
http
Status
standard
Author/Change controller
W3C
Specification document
Document Policy API
Header field name
Require-Document-Policy
Applicable protocol
http
Status
standard
Author/Change controller
W3C
Specification document
Document Policy API
Header field name
Sec-Required-Document-Policy
Applicable protocol
http
Status
standard
Author/Change controller
W3C
Specification document
Document Policy API

11. プライバシーおよびセキュリティ

この仕様は、埋め込みページに対して適用されるポリシーを埋め込み元ページが設定するための メカニズムを標準化します。 ただし、既存の iframe sandbox メカニズムとは異なり、必須ポリシーについて明示的な承認が必要です。 これは、それらのサイトの協力なしに、公開済み Web サイト上の既存機能の動作を変更できないことを意味します。

このモデルには、考慮すべきプライバシーおよびセキュリティ上の考慮事項があります。

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

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

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

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

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

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

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

埋め込み元が要求したポリシーに従うことはロードされるために必要であるため、 サイト所有者は Web サーバーを構成して、 レスポンスの Document-Policy ヘッダーに Sec-Required-Document-Policy request ヘッダーを単純に反映したくなる可能性があります。 これは文書のポリシーが常にリクエストと互換性を持つことを保証しますが、 埋め込み元が既存 API の動作を無効化または変更することで、 埋め込まれた文書内部の制御フローを変更できるリスクをもたらす可能性があります。 これは、コンテンツが作成された後に document policy モデルへ新しい構成ポイントが追加される場合に 特に当てはまります。 すべての可能な新しい動作変更に対して文書を将来対応させることは困難です。

必須 document policy を持つコンテキストに埋め込まれることを想定しているサイトは、 実際にサポート可能であると認識している最も厳格なポリシーに設定するか、 または認識しており、動作変更の潜在的な範囲を理解している構成ポイントについてのみ 受信したポリシーを反映することで、この問題を軽減できます。

適合性

文書の 規約

適合性要件は、記述的なアサーションと 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" を使用して規範的なテキストから分離されています。 例:

Note、これは情報提供目的の注記です。

索引

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

参照によって定義される 用語

参考文献

規範的参考文献

[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; Ian Clelland; Mike West. Reporting API. URL: https://w3c.github.io/reporting/
[RFC2119]
S. Bradner. RFC で要件レベルを示すために使用する キーワード. 1997年3月. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC3864]
G. Klyne; M. Nottingham; J. Mogul. メッセージヘッダーフィールドの 登録手順. 2004年9月. Best Current Practice. URL: https://www.rfc-editor.org/info/rfc3864/
[RFC8941]
M. Nottingham; P-H. Kamp. HTTP の Structured Field Values . 2021年2月. Proposed Standard. URL: https://httpwg.org/specs/rfc8941.html

非規範的参考文献

[CSP]
Mike West; Antonio Sartori. Content Security Policy Level 3. URL: https://w3c.github.io/webappsec-csp/
[ECMA-262]
ECMAScript Language Specification. URL: https://tc39.es/ecma262/multipage/
[PERMISSIONS-POLICY]
Ian Clelland. Permissions Policy. URL: https://w3c.github.io/webappsec-permissions-policy/

Issue 索引

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