許可ポリシー

W3C 作業草案,

この文書の詳細
このバージョン:
https://www.w3.org/TR/2025/WD-permissions-policy-1-20251006/
最新の公開バージョン:
https://www.w3.org/TR/permissions-policy/
編集者草案:
https://w3c.github.io/webappsec-permissions-policy/
以前のバージョン:
履歴:
https://www.w3.org/standards/history/permissions-policy-1/
フィードバック:
GitHub
仕様内インライン
編集者:
(Google)

Copyright © 2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

概要

この仕様は、開発者が様々なブラウザ機能やAPIの利用を選択的に有効化・無効化できる仕組みを定義します。

この文書のステータス

このセクションは、公開時点での文書のステータスを説明します。W3Cの最新の公開文書やこの技術報告書の最新版は、W3C技術報告インデックスで確認できます。

この文書は Webアプリケーションセキュリティ作業グループ により、勧告プロセスを用いて作業草案として公開されました。この文書はW3C勧告となる予定です。

(アーカイブ) 公開メーリングリスト public-webappsec@w3.org (案内参照) でこの仕様について議論することを推奨します。 メール送信時は、 件名に「permissions-policy」を含めてください。 例: 「[permissions-policy] …コメント要約…」

作業草案としての公開は W3Cおよびその会員による支持を意味しません。この文書は草案であり、随時更新・置換・廃止される可能性があります。進行中の作業以外として引用するのは不適切です。

この文書は Webアプリケーションセキュリティ作業グループ によって作成されました。

この文書は W3C特許ポリシーの下で活動するグループによって作成されました。 W3Cは、グループの成果物に関連する公開特許開示リストを管理しています。 そのページには特許開示の方法も記載されています。 実際に特許の存在を知っている場合は、必須請求項を含むと考える場合、W3C特許ポリシー第6節に従い情報を開示する必要があります。

この文書は2025年8月18日 W3Cプロセス文書に従って管理されています。

1. はじめに

ウェブプラットフォームは、機能やAPIの拡大を続けており、より豊かな機能、開発者にとって使いやすい設計、パフォーマンスの向上を提供しています。しかし、開発者がこれらのブラウザ機能やAPIの一部をアプリケーション内で選択的に有効化・無効化・挙動変更できる仕組みが不足しています：

  1. 開発者は、アプリケーションの安全性やパフォーマンス確保のため、特定のブラウザ機能やAPIへのアクセスを選択的に無効化したい場合があります。これは、アプリケーション内で自身や第三者コンテンツが不要または予期しない挙動を持ち込むことを防ぐためです。
  2. 開発者は、デフォルトで無効化されている場合がある特定のブラウザ機能やAPIへのアクセスを選択的に有効化したい場合があります。例えば、一部の機能は埋め込みコンテキストでは明示的に有効化しない限り無効化されている場合があり、他のポリシー要件に従う必要がある場合もあります。
  3. 開発者は、ポリシーを利用して、特定の機能やAPIの利用有無についてクライアントや埋め込み先へ約束を示したい場合があります。例えば、ブラウザで特定の「高速経路」最適化を有効にする、あるいは他の埋め込み先（SNS、検索エンジンなど）が定める要件への準拠を約束するためです。

この仕様は、上記のユースケースに対応するポリシー機構を定義します。

本仕様は以前「Feature Policy」という名称でした。

2. 例

SecureCorp Inc.は、アプリケーション内でFullscreenおよびGeolocation APIの利用を無効化したいと考えています。以下のHTTPレスポンスヘッダーを配信することで、パーミッションポリシーを定義できます：

Permissions-Policy: fullscreen=(), geolocation=()

空のオリジンリストを指定することで、指定した機能はオリジンに関係なく、すべてのドキュメント（ネストされたドキュメントも含む）で無効化されます。

Geolocationは、すべてのクロスオリジンフレームでデフォルトで無効化されています。FastCorp Inc.は、自サイト上の特定のクロスオリジンiframeでジオロケーションを有効化したいと考えています。これにはiframe要素に「allow」属性を追加します：

<iframe src="https://other.com/map" allow="geolocation"></iframe>

iframe属性を使うことで、同じオリジンのドキュメントであっても、特定のフレームだけ機能を選択的に有効化できます。

SecureCorp Inc.は、攻撃者が自身のiframeをSecureCorpのページに埋め込める場合でも、独自オリジンおよび「https://example.com」のオリジンを除き、すべての子孫ナビゲーション可能内でGeolocation APIの利用を完全に無効化したいと考えています。このために、以下のようなHTTPレスポンスヘッダーを配信してGeolocation用の制限付きパーミッションポリシーを定義します：

Permissions-Policy: geolocation=(self "https://example.com")

許可リストは1つ以上のオリジンのリストであり、アプリケーションのオリジン（オプションで「self」キーワード付き）や第三者オリジンを含めることができます。

このポリシーが有効の場合、通常通りiframe属性「allow」でジオロケーションを許可できますが、APIの利用権限が与えられるのはhttp://example.comまたはSecureCorp自身のコンテンツのみです。

SecureCorp Inc.はドメインを再編し、Geolocation APIの利用権限を自身のオリジン（「https://example.com」）および3つのサブドメイン（「https://geo.example.com」、「https://geo2.example.com」、「https://new.geo2.example.com」）に委譲する必要があります。他の閲覧コンテキストではGeolocation APIの利用を無効化したままにする必要があります。これには以下のHTTPレスポンスヘッダーを配信します：

Permissions-Policy: geolocation=(self "https://example.com" "https://geo.example.com" "https://geo2.example.com" "https://new.geo2.example.com")

これで目的は達成できますが、SecureCorp Inc.が「https://example.com」の任意のサブドメインへの委譲も安全と判断する場合、HTTPレスポンスヘッダーは次のようにできます：

Permissions-Policy: geolocation=(self "https://example.com" "https://*.example.com")

上記のヘッダーでは、「https://geo.example.com」、「https://geo2.example.com」、「https://new.geo2.example.com」などのサブドメインだけでなく、「https://example.com」の他のサブドメインでもAPIを利用できます。ただし、「https://example.com」自体は「https://*.example.com」の許可リストには含まれないため、別途追加する必要があります。

SecureCorp Inc.はサービスを再編し、Geolocation APIの利用権限を自身のオリジン（「https://example.com」）および3つの非デフォルトポート（「https://example.com:444」、「https://example.com:445」、「https://example.com:446」）に委譲する必要があります。他の閲覧コンテキストではGeolocation APIの利用を無効化したままにします。これには以下のHTTPレスポンスヘッダーを配信します：

Permissions-Policy: geolocation=(self "https://example.com" "https://example.com:444" "https://example.com:445" "https://example.com:446")

これで目的は達成できますが、SecureCorp Inc.が「https://example.com」の任意のポートへの委譲も安全と判断する場合、HTTPレスポンスヘッダーは次のようにできます：

Permissions-Policy: geolocation=(self "https://example.com:*")

上記ヘッダーでは、「https://example.com:444」、「https://example.com:445」などのポートだけでなく、「https://example.com」の他のポートでもAPIを利用できます。

JSPlaygroundCorp Inc.はユーザー生成ウェブアプリケーションをホストしたいと考えていますが、ブラウザに各アプリケーションの 強力な機能利用権限を個別に管理させたいと考えています。これには各ウェブコンテンツや制作者ごとに個別のサブドメインを発行し、トップレベルドキュメントとしてナビゲートすることで実現できます（フレームワークとユーザーコンテンツはsame-originのiframeで分離可能）。

ユーザーはブラウザで操作対象のドメイン（トップレベルドメイン）に権限を付与するため、この分離が必要です。

この場合、JSPlaygroundCorpは自社ドメインからiframeのallow属性を使ってユーザー生成アプリケーションをiframe化することは避けるべきです。そうすると全てに自社ドメインの権限が与えられてしまうためです。

PlatformCorp Inc.は、トップレベルドメインで組み込み可能な第三者コンポーネントのマーケットプレイスを提供したいと考えています。「強力な機能」であるgetUserMedia() APIなどの利用権限を責任を持って委譲したいと考えています。どのコンポーネントアプリが機能を必要とするかは独自の「インストール」UXで管理し、エンドユーザーが主導権を持てるようにします。

カメラとマイクは、すべてのクロスオリジンフレームでデフォルトで無効化されています。各第三者コンポーネントはサブドメインを持ち、クロスオリジンiframeで埋め込むことができます。PlatformCorpはallow属性をiframe要素に指定することで、各サブドメインごとにカメラやマイクへのアクセス権限を委譲できます。

例えば、コンポーネント「app1」はカメラを、「app2」はマイクを、「app3」は両方を使えるようにするには、以下のようなiframeになります：

<iframe
  allow="camera https://app1.site.com https://app3.site.com;
         microphone https://app2.site.com https://app3.site.com"
  src="https://doc1.site.com"
  sandbox="allow-same-origin allow-scripts">
</iframe>

iframe属性を使うことで、同じオリジンのドキュメントであっても、特定のフレームだけ機能を選択的に有効化できます。実際のサンドボックストークンのリストはもっと長くなる場合もあります。

ブラウザは通常、ユーザーがトップレベルドメインに権限を付与するため、ユーザーがPlatformCorpを既に信頼している場合、コンポーネントがカメラやマイクアクセスを要求しても追加の許可プロンプトは表示されないことがあります。

[HTML5]では、sandbox属性がiframe要素に定義されており、開発者が潜在的に信頼できないコンテンツを含めるリスクを減らすために、フォーム送信やスクリプト・プラグイン実行の禁止などの制限を課すことができます。sandboxディレクティブは、[CSP2]で定義されており、フレーム以外のリソースにも同様の制限をHTTPレスポンスヘッダー（Content-Security-Policy: sandbox）などで要求できます。これらの仕組みにより開発者は以下のことが可能です：

しかし、上記の仕組みにはいくつか制限があります。開発者はすべてのコンテキストに自動的にポリシーを適用できず、第三者コンテンツによるフレーム挿入など、制御できない場合は一貫性ある強制が困難です。デフォルトで無効化されている機能を選択的に有効化する仕組みもありません。サンドボックスはすべての機能を自動的に無効化し、個別に再有効化する必要があるため、機能セットの拡張が互換性リスクなしには不可能です。

Permissions Policyはsandbox機構と組み合わせて使うことを想定しており（sandboxで既に制御可能な機能は重複して制御しません）、上記の制限を解決するための拡張性ある仕組みを提供します。

4. フレームワーク

4.1. ポリシー制御機能

ポリシー制御機能とは、permissions policyで参照することでドキュメント内で有効化・無効化できるAPIや挙動です。

簡潔のため、本仕様では「ポリシー制御機能」を単に「機能」と呼ぶことがあります。特に断りがない限り、「機能」はポリシー制御機能を指します。こうした機能を定義する他の仕様では、混乱を避けるために長い用語を使用してください。
本仕様は現状ではドキュメントで定義された機能のみを扱っています。WorkersやWorkletsでも機能とパーミッションポリシーの可能性を含める表現方法を検討すべきです。

ポリシー制御機能はトークンによって識別されます。これは、ポリシー指令で用いられる文字列です。

各ポリシー制御機能には、デフォルト許可リストがあり、トップレベルナビゲーション内のドキュメントでその機能が利用可能か、および子ナビゲーションでの継承方法が定義されています。

ユーザーエージェントは、サポート機能のセットを持ちます。これは、ポリシーによって制御可能な機能の集合です。ユーザーエージェントは、すべての機能をサポートする必要はありません。

ポリシー制御機能自体は本フレームワークの一部ではありません。現在定義済みの機能の非規範的なリストは、この仕様の付随文書で管理されています。

4.2. ポリシー

宣言ポリシーは、以下の構造体であり、次の項目を持ちます：

宣言

順序付きマップで、機能から許可リストへの対応付けを持ちます。

レポート設定

順序付きマップで、機能から文字列への対応付けを持ちます。

permissions policyは、以下の構造体であり、次の項目を持ちます：

継承ポリシー

順序付きマップで、機能から"Enabled"または"Disabled"への対応付けを持ちます。

宣言ポリシー

宣言ポリシーです。

空のpermissions policyは、すべてのサポート機能に対して"Enabled"を含む継承ポリシーを持ち、宣言およびレポート設定がいずれも空の順序付きマップとなっているpermissions policyです。

4.3. 継承ポリシー

機能の継承ポリシーfeatureは、継承ポリシーのfeatureキーの値です。permissions policyが初期化されると、継承ポリシーにはすべてのサポート機能に対する値が含まれます。

作成・ナビゲーション時に、各Documentは親フレームからポリシーを継承します。Documentがトップレベルナビゲーションの場合は、各ポリシー制御機能の定義済みデフォルトから継承します。継承ポリシーは各機能の初期状態（"Enabled"か"Disabled"）と、Document内の宣言ポリシーで制御可能かを決定します。

Documentがトップレベルナビゲーションの場合は、継承ポリシーは各機能の定義済みデフォルトに基づきます。

Documentが子ナビゲーションの場合は、親ドキュメントのpermissions policyおよび子ナビゲーションのコンテナポリシーに基づきます。

4.4. ヘッダーポリシー

ヘッダーポリシーとは、ポリシー指令のリストであり、HTTPヘッダーを通じてドキュメントと共に配信されます。これがドキュメントのpermissions policyの宣言ポリシーを形成します。

4.5. コンテナポリシー

ヘッダーポリシーに加え、各子ナビゲーションにはコンテナポリシーがあります。これはポリシー指令であり、空の場合もあります。コンテナポリシーはナビゲーションコンテナの属性で設定できます。

コンテナポリシーは、子ナビゲーションに読み込まれる任意のDocumentの継承ポリシーに影響を与えます。（§ 9.7 コンテナ内の機能の継承ポリシー定義参照）

現時点では、コンテナポリシーは直接設定できず、iframeのallowfullscreenやallow属性によって間接的に設定されます。今後の改訂で、完全なコンテナポリシーを明示的に宣言する仕組みが導入される可能性があります。

4.6. ポリシー指令

ポリシー指令とは、順序付きマップであり、ポリシー制御機能を対応する許可リストにマッピングします。

ポリシー指令は、HTTPヘッダーではsf-dictionary構造のシリアル化、HTML属性ではASCIIシリアル化として表現されます。

4.7. 許可リスト

パーミッションポリシーの許可リストは、概念的にオリジンの集合です。許可リストは以下のいずれかです：

  • 特別な値 *（すべてのオリジンを表します）
  • 構造体（以下を含む）:
キーワード'self'、'src'、'none'は、ヘッダーや属性文字列で許可リストのテキスト表現として使われます。これらのキーワードは解析時に文脈で解釈され、参照するオリジンのみが許可リストに保存されます。キーワード自体は許可リストの一部ではありません。

許可リストがオリジンoriginに一致するか判定するには、以下の手順を実行します：

  1. もし許可リストが特別な値 *なら、trueを返す。

注：HTTPSスキームが必要なため、CSP形式のワイルドカード一致は使用しません。

  1. 許可リストのself-originがnullでなく、originと同一オリジンドメインなら、trueを返す。

  2. 許可リストのsrc-originがnullでなく、originと同一オリジンドメインなら、trueを返す。

  3. もしoriginが不透明オリジンなら、falseを返す。

  4. urlを、url parserにoriginのserializationを渡した結果とする。

  5. 各permissions-source-expressionitemについて、許可リストのexpressions内で実行する：

    1. Does url match expression in origin with redirect count?をurl、item、origin、0で実行してtrueなら、trueを返す。

  6. falseを返す。

4.8. デフォルト許可リスト

すべてのポリシー制御機能にはデフォルト許可リストが存在します。デフォルト許可リストは、Documentが宣言ポリシーなしでトップレベルナビゲーションで利用される場合、その機能が許可されるかどうか、またその機能へのアクセスが子ナビゲーションに自動的に委譲されるかどうかを決定します。

デフォルト許可リストは、以下のいずれかです：

*
この機能は、デフォルトでDocumentがトップレベルナビゲーションおよびすべての子ナビゲーションで許可されます。コンテナポリシーをナビゲーションコンテナで明示的に指定することで、子ナビゲーションで無効化できます（または、任意のナビゲーションでDocumentに適切なPermissions-Policyヘッダーを付与することで無効化できます）。
'self'
この機能は、デフォルトでドキュメントが トップレベルのナビゲーションにある場合、または 子ナビゲーションで、そのドキュメントが 親の親のドキュメントと同一オリジンであり、かつそのDocumentで許可されている場合に利用可能です。 一方、子ナビゲーションで、そのドキュメントが親の親のドキュメントとクロスオリジンの場合、デフォルトでは許可されません。

5. Permissions Policy シリアル化

5.1. HTML属性のシリアル化

ポリシー指令は、HTML属性内では以下のABNFの通りASCIIシリアル化で表現されます：

serialized-permissions-policy = serialized-policy-directive *(";" serialized-policy-directive)
serialized-policy-directive = feature-identifier RWS allow-list
feature-identifier = 1*( ALPHA / DIGIT / "-")
allow-list = allow-list-value *(RWS allow-list-value)
allow-list-value = permissions-source-expression / "*" / "'self'" / "'src'" / "'none'"
permissions-source-expression = scheme-source / host-source
文字列 "'self'" は、allowlist 内でオリジンとして使用できます。そのように使用された場合、それは オリジン を指し、Document に含まれる permissions policy になります.

5.2. 構造化ヘッダーのシリアル化

ポリシー指令は、HTTPヘッダーではStructured Fieldとして表現されます。[RFC8941]

この表現では、ポリシー指令はDictionaryとして表されます。

各Dictionaryのメンバーは、featureと許可リストを関連付けます。メンバー名はTokenでなければなりません。Tokenがユーザーエージェントの対応機能名でない場合、そのDictionaryメンバーは処理手順で無視されます。

メンバー値は許可リストを表し、次のいずれかでなければなりません：

メンバー値には、"report-to"という名前のパラメータを持てます。その値は文字列でなければなりません。他のパラメータは無視されます。

Inner List内の他の項目は処理手順で無視され、メンバー値はそれらが存在しないものとして扱われます。その他の形式のメンバー値は、そのDictionaryメンバー全体が処理手順で無視されます。

6. 配信

6.1. `Permissions-Policy` HTTPヘッダーフィールド

`Permissions-Policy` HTTPヘッダーフィールドは、response（サーバーからクライアント）で利用され、クライアントが適用すべきpermissions policyを伝達できます。

`Permissions-Policy`は構造化ヘッダーであり、値はDictionaryでなければなりません。そのABNFは次の通りです： 

PermissionsPolicy = sf-dictionary

Dictionaryの意味論は§ 5.2 構造化ヘッダーのシリアル化で定義されています。

処理手順は§ 9.2 辞書とオリジンからポリシーを構築で定義されています。

6.2. iframe要素のallow属性

iframe要素はallow属性を持ち、この属性にはASCIIシリアル化されたポリシー指令が含まれます。

属性で指定された機能の許可リストが空の場合、デフォルト値は'src'となり、これはiframeのsrc属性に指定されたURLのオリジンを表します。

空でない場合、allow属性は、認識された各機能の許可リストを、iframe要素のcontent navigableのコンテナポリシーに追加することになります（生成時）。

6.3. レガシー機能をサポートする追加属性

Permissions Policyで制御されるいくつかの機能には、既存のiframe属性が定義されています。本仕様では、これらの属性がiframeのcontent navigableのコンテナポリシーに影響を与えるように再定義します。

6.3.1. allowfullscreen

allowfullscreen iframe 属性は requestFullscreen() へのアクセスを制御します。

iframe要素がallow属性を持ち、その値に"fullscreen"トークンが含まれる場合、allowfullscreen属性は効果を持ちません。

それ以外の場合、iframe要素にallowfullscreen属性があると、"fullscreen"機能に対して*の許可リストが生成時にiframe要素のcontent navigableのコンテナポリシーに追加されます。

これは<iframe allow="fullscreen">の動作とは異なります。既存のallowfullscreen利用との互換性のためです。iframe要素にallow="fullscreen"とallowfullscreenが両方ある場合は、より制限的なallow="fullscreen"の許可リストが使われます。

7. スクリプトによるポリシーの内省

7.1. 概要

ドキュメントで有効な現在のポリシーは、スクリプトによって観察できます。これは、例えば機能が有効かどうかを他の方法で判断できない場合に、どのユーザーインターフェースを表示するべきかの判断に利用できます。（一部の機能は失敗モードが観察できなかったり、機能検出の副作用が望ましくない場合があります。）

ドキュメントとiframeの両方は、PermissionsPolicyオブジェクトを提供しており、それを使って適用されているパーミッションポリシーを調査できます。

7.1.1. ドキュメントポリシー

現在有効なポリシーを取得するには、document.permissionsPolicyを使います。これはPermissionsPolicyオブジェクトを返し、以下のことが可能です：

  • 指定した機能が現在のドキュメントで許可されているか否かの状態を問い合わせる

  • 現在のドキュメントで利用可能な（許可されていなくても）すべての機能の一覧を取得する

  • 現在のドキュメントで許可されている機能の一覧を取得する

  • 現在のドキュメントにおける指定機能の許可リストを取得する

<!doctype html>
<script>
 const policy = document.permissionsPolicy;

 // このドキュメントでWebUSBが使える場合はtrueになる。
 const can_use_usb = policy.allowsFeature('usb');

 // https://example.com の新しいフレームでWebXRが許可されている場合はtrue。
 if (policy.allowsFeature('xr-spatial-tracking', 'https://example.com')) {
   // UIで https://example.com のフレーム作成を表示。
 } else {
   // 別のUIを表示。
 }

 // 決済リクエストが許可されているオリジンのリスト取得。すべてのオリジン許可の場合は ['*']。
 const allowed_payment_origins = policy.getAllowlistForFeature('payment');

 // このドキュメントでサポートされている（許可されていないものも含む）すべての機能一覧。
 // 結果は文字列の配列。
 const all_features = policy.features();
 if (all_features.includes('geolocation')) {
   // サードパーティの地図サービスを子フレームとして追加。
 }
</script>

7.1.2. フレームポリシー

iframe要素のポリシーも、それを含むドキュメントから調査可能です。この場合のポリシーオブジェクトは、そのフレームの可観測ポリシーを表し、現在のドキュメントおよびiframe要素の属性のみに依存します。実際にフレーム内で機能が許可されているかどうかは示されません。フレーム内のドキュメントがHTTPヘッダーで独自のポリシーを適用している場合や、初期位置から他のオリジンに遷移している場合もあるためです。iframe要素のネストされたナビゲーション内の有効なポリシーを公開すると、クロスオリジン文書の挙動について情報漏洩が発生する可能性があります。 

<!doctype html>
<iframe id="frame" allow="fullscreen; xr-spatial-tracking"></iframe>
<script>
 const iframe_element = document.getElementById("frame");
 const iframe_policy = iframe_element.permissionsPolicy;

 // フレーム内のドキュメントでWebXRが許可されている場合はtrue
 if (iframe_policy.allowsFeature('xr-spatial-tracking')) {
  // VRコントロールを表示
 }
</script>

iframe要素の可観測ポリシーは、フレームに実際に読み込まれているコンテンツ（クロスオリジン情報漏洩防止のため）や、ドキュメントツリーに存在するかどうかに依存しません。 

<!doctype html>
<!-- このフレームは、src属性で指定されたドキュメントがロードされた時、fullscreenが許可されないはず -->
<iframe id="frame" allow="fullscreen https://example.com" src="https://example.net/" ></iframe>
<script>
 const iframe_element = document.getElementById("frame");
 const iframe_policy = iframe_element.permissionsPolicy;
 // src属性に指定されたURLはポリシーでfullscreenが許可されていないためfalseになる。
 const is_fullscreen_allowed_in_frame = iframe_policy.allowsFeature('fullscreen');

 const new_frame = document.createElement('iframe');
 new_frame.allow = 'sync-xhr';
 // このiframeは、src属性で指定されるURLに関係なくsync-xhrが許可されているためtrue。
 const is_sync_xhr_allowed = new_frame.permissionsPolicy.allowsFeature('sync-xhr');
</script>

7.2. permissionsPolicyオブジェクト

[Exposed=Window]
interface PermissionsPolicy {
  boolean allowsFeature(DOMString feature, optional DOMString origin);
  sequence<DOMString> features();
  sequence<DOMString> allowedFeatures();
  sequence<DOMString> getAllowlistForFeature(DOMString feature);
};

partial interface Document {
    [SameObject] readonly attribute PermissionsPolicy permissionsPolicy;
};

partial interface HTMLIFrameElement {
    [SameObject] readonly attribute PermissionsPolicy permissionsPolicy;
};

PermissionsPolicyオブジェクトは、関連ノードを持ちます。これはNodeです。関連ノードは、PermissionsPolicyオブジェクト作成時に設定されます。

PermissionsPolicyオブジェクトは、デフォルトオリジンを持ちます。これはoriginであり、値はPermissionsPolicyオブジェクトの関連ノードの状態によって決まります：

各Documentはポリシーオブジェクトを持ちます。これはPermissionsPolicyインスタンスであり、関連ノードがそのDocumentです。

DocumentのpermissionsPolicyIDL属性は、取得時にDocumentのポリシーオブジェクトを返さなければなりません。

各iframe要素はポリシーオブジェクトを持ちます。これはPermissionsPolicyインスタンスであり、関連ノードがその要素です。

iframeのpermissionsPolicyIDL属性は、取得時にiframeのポリシーオブジェクトを返さなければなりません。

allowsFeature(feature, origin)メソッドは以下の手順を実行しなければなりません：

  1. originが省略された場合、このPermissionsPolicyオブジェクトのデフォルトオリジンをoriginに設定する。

  2. policyをこのPermissionsPolicyオブジェクトの関連ノードに対する可観測ポリシーとする。

  3. featureがpolicyでoriginに許可されていればtrueを返す。

  4. それ以外はfalseを返す。

features()メソッドは以下の手順を実行しなければなりません：

  1. resultを空の順序付き集合にする。

  2. 各対応機能featureについて：

    1. featureをresultに追加する。

  3. resultを返す。

allowedFeatures()メソッドは以下の手順を実行しなければなりません：

  1. resultを空の順序付き集合にする。

  2. originをこのPermissionsPolicyオブジェクトのデフォルトオリジンとする。

  3. policyをこのPermissionsPolicyオブジェクトの関連ノードに対する可観測ポリシーとする。

  4. 各対応機能featureについて：

    1. featureがpolicyでoriginに許可されていれば、featureをresultに追加する。

  5. resultを返す。

getAllowlistForFeature(feature)メソッドは以下の手順を実行しなければなりません：

  1. resultを空リストにする。

  2. originをこのPermissionsPolicyオブジェクトのデフォルトオリジンとする。

  3. policyをこのPermissionsPolicyオブジェクトの関連ノードに対する可観測ポリシーとする。

  4. featureがpolicyでoriginに許可されていなければresultを返す。

  5. allowlistをpolicyの宣言ポリシー[feature]の宣言とする。

  6. allowlistが特別な値*の場合：

    1. "*"をresultに追加する

    2. resultを返す

  7. allowlistのself-originがnullでない場合、そのシリアル化をresultに追加する。

  8. allowlistのsrc-originがnullでない場合、そのシリアル化をresultに追加する。

  9. それ以外の場合、各permissions-source-expressionitemについて、allowlistのexpressions内で：

    1. itemをresultに追加する

  10. resultを返す。

任意のNodeの可観測ポリシーは、permissions policyであり、そのNodeが表すナビゲーション可能な部分について、現在のドキュメントから見えるポリシー情報を含みます。

Document documentの可観測ポリシーを取得するには、documentのpermissions policyを返します。

Element nodeの可観測ポリシーを取得するには、次の手順を実行します：

  1. inherited policyを空の順序付きマップにする。

  2. 各対応機能featureについて：

    1. isInheritedを、コンテナで機能の継承ポリシーを定義をfeature、node、nodeの宣言オリジンで実行した結果とする。

    2. inherited policy[feature]にisInheritedを設定する。

  3. 新しいpermissions policyを返す。継承ポリシーはinherited policy、宣言ポリシーは両方とも新しい構造体（宣言とレポート設定が空の順序付きマップ）とする。

Element nodeの宣言オリジンを取得するには、次の手順を実行します：

  1. nodeのnode documentのサンドボックス化オリジンブラウジングコンテキストフラグが設定されている場合、新しい不透明オリジンを返す。

  2. nodeのsandbox属性が設定されており、allow-same-originキーワードが含まれていない場合、新しい不透明オリジンを返す。

  3. nodeのsrcdoc属性が設定されている場合、nodeのnode documentのオリジンを返す。

  4. nodeのsrc属性が設定されている場合：

    1. urlを、nodeのsrc属性をnodeのnode documentからの相対URLとしてパースした結果とする。

    2. urlが失敗でなければ、urlのオリジンを返す。

  5. nodeのnode documentのオリジンを返す。

宣言オリジンの概念は、埋め込みページがフレームに読み込もうとしているドキュメントのオリジンを表すことを意図しています。つまり、ブラウザが sandboxやsrcdoc属性をサポートしていない場合、それらの属性は宣言オリジンの計算に考慮すべきではありません。

8. レポート

Permissions policy 違反レポートは、Documentの何らかの動作がpermissions policyに違反したことを示します。どのような場合に違反と見なすか、またその違反がいつ発生したかの判断方法は、各ポリシー制御機能の仕様で定義されます。

Permissions Policy 違反レポートは、report typeとして "permissions-policy-violation" を持ちます。

Permissions Policy 違反レポートは、ReportingObserver から参照可能です。

[Exposed=Window]
interface PermissionsPolicyViolationReportBody : ReportBody {
  [Default] object toJSON();
  readonly attribute DOMString featureId;
  readonly attribute DOMString? sourceFile;
  readonly attribute long? lineNumber;
  readonly attribute long? columnNumber;
  readonly attribute DOMString disposition;
  readonly attribute DOMString? allowAttribute;
  readonly attribute DOMString? srcAttribute;
};

Permissions Policy 違反レポートのbodyは、JavaScriptではPermissionsPolicyViolationReportBodyで表現され、以下のフィールドを持ちます：

8.1. `Permissions-Policy-Report-Only` HTTPヘッダーフィールド

`Permissions-Policy-Report-Only` HTTPヘッダーフィールドは、response（サーバーからクライアント）で利用でき、クライアント側で実際にポリシーを強制せず、もしポリシーが有効だった場合に違反となる挙動があった時のみレポート送信を行います。

`Permissions-Policy-Report-Only`は構造化ヘッダーであり、値はディクショナリでなければなりません。

ディクショナリの意味論は§ 5.2 構造化ヘッダーのシリアル化で定義されています。

処理手順は§ 9.2 辞書とオリジンからポリシーを構築で定義されています。

9. アルゴリズム

9.1. レスポンスポリシーの処理

response（response）、origin（origin）、boolean（report-only）を受け取り、このアルゴリズムは宣言ポリシーを返します。

  1. report-onlyがTrueなら、header nameを "Permissions-Policy-Report-Only"、そうでなければ "Permissions-Policy" にする。

  2. parsed headerを、responseのheader listからheader nameと "dictionary" を指定してget a structured field valueを実行した結果とする。

  3. parsed headerがnullなら、空の順序付きマップを返す。

  4. policyを、parsed headerとoriginで辞書とオリジンからポリシーを構築を実行した結果とする。

  5. policyを返す。

9.2. 辞書とオリジンからポリシーを構築

順序付きマップ（dictionary）とorigin（origin）を受け取り、このアルゴリズムは宣言ポリシーを返します。

  1. declarationsを空の順序付きマップにする。

  2. reporting-configを空の順序付きマップにする。

  3. 各 feature-name → (value, params) をdictionaryで：

    1. feature-nameが認識されるポリシー制御機能でなければ、continue。

    2. featureをfeature-nameで識別されるポリシー制御機能とする。

    3. params["report-to"]が存在し、文字列なら、reporting-config[feature]にparams["report-to"]をセットする。

    4. allowlistを新しいallowlistにする。

    5. valueがトークン*、またはリスト内にトークン*が含まれる場合、allowlistを特別な値*とする。

    6. それ以外の場合：

      1. valueがトークンselfなら、allowlistのself-originをoriginにする。

      2. それ以外でvalueがリストなら、各elementをvalueで：

        1. elementがトークンselfなら、allowlistのself-originをoriginにする。

        2. elementが有効なpermissions-source-expressionなら、appendでallowlistのexpressionsにelementを追加。

    7. declarations[feature]にallowlistをセット。

  4. «declarations, reporting-config»を返す。

9.3. ポリシー指令の解析

文字列（value）、origin（container origin）、オプションのorigin（target origin）を受け取り、このアルゴリズムはポリシー指令を返します。

  1. directiveを空の順序付きマップにする。

  2. strictly splitting value on the delimiter U+003B (;)で返された各serialized-declarationについて：

    1. tokensを、splitting serialized-declaration on ASCII whitespaceの結果とする。

    2. tokensが空リストなら、continue。

    3. feature-nameをtokensの最初の要素とする。

    4. feature-nameが認識されるポリシー制御機能でなければ、continue。

    5. featureをfeature-nameで識別されるポリシー制御機能とする。

    6. targetlistをtokensの残りの要素（存在する場合）とする。

    7. allowlistを新しいallowlistにする。

    8. targetlistに文字列"*"が含まれる場合、allowlistを特別な値*とする。

    9. それ以外の場合：

      1. targetlistが空でtarget originが与えられていれば、allowlistのsrc-originをtarget originにする。

      2. targetlistの各elementについて：

        1. elementが'self'（ASCII大文字小文字区別なし）で一致する場合：

          1. allowlistのself-originをcontainer originにする。

          2. 次のelementにcontinue。

        2. target originが与えられ、elementが'src'（ASCII大文字小文字区別なし）で一致する場合：

          1. allowlistのsrc-originをtarget originにする。

          2. 次のelementにcontinue。

        3. resultを、URL parserをelementに適用した結果とする。

        4. resultが失敗でなければ：

          1. targetをresultのoriginとする。

          2. targetが不透明オリジンでなければ、appendでallowlistのシリアル化をexpressionsに追加する。

    10. directive[feature]にallowlistをセット。

  3. directiveを返す。

9.4. パーミッションポリシー属性の処理

要素（element）を受け取り、このアルゴリズムはコンテナポリシーを返します（空の場合あり）。

  1. もしelementが iframe 要素でなければ、空のポリシー指令を返します。

  2. container policyを、elementの allow 属性の値、elementのオリジン、elementのノードドキュメント、elementの宣言オリジンに対してポリシー指令の解析を実行した結果とする。

  3. elementの allowfullscreen 属性が指定されており、かつcontainer policyにfullscreen 機能のエントリが含まれない場合

    1. セット container policy[fullscreen] = 特別な値 *。

  4. container policyを返します。

9.5. ナビゲーション可能対象のPermissions Policy作成

nullまたは要素（container）、オリジン（origin）を受け取り、このアルゴリズムは新しいPermissions Policyを返します。

  1. アサート：nullでない場合、containerはナビゲーション可能コンテナである。

  2. inherited policyを新しい順序付きマップにする。

  3. 各feature サポート機能について、

    1. isInheritedをコンテナで機能の継承ポリシーを定義をfeature、 container、originで実行した結果とする。

    2. inherited policy[feature]にisInheritedをセット。

  4. policyを新しいpermissions policy（継承ポリシーはinherited policy、 宣言ポリシーは «[], []»）とする。

  5. policyを返す。

9.6. レスポンスからナビゲーション可能対象のPermissions Policy作成

nullまたはナビゲーション可能コンテナ（container）、オリジン（origin）、レスポンス（response）、オプションのboolean（report-only、デフォルトFalse）を受け取り、このアルゴリズムは新しいpermissions policyを返します。

  1. policyをナビゲーション可能対象のPermissions Policy作成をcontainer、originで実行した結果とする。

  2. dをレスポンスポリシーの処理をresponse、origin、report-onlyで実行した結果とする。

  3. 各feature → allowlistについて、dの宣言で：

    1. もしpolicyの継承ポリシー[feature]がtrueなら、policyの宣言ポリシーの宣言[feature]にallowlistをセット。

  4. policyの宣言ポリシー[feature]のレポート設定にdのレポート設定をセットする。

  5. policyを返す。

9.7. コンテナで機能の継承ポリシーを定義

機能（feature）、nullまたはナビゲーション可能コンテナ（container）、そのコンテナ内のDocumentのオリジン（origin）、オプションのboolean（report-only、デフォルトFalse）を受け取り、このアルゴリズムはfeatureの継承ポリシー値を返します。

  1. containerがnullなら、"Enabled"を返す。

  2. オリジンの機能値取得をfeature、containerのノードドキュメント、containerのノードドキュメントのオリジン、report-onlyで実行した結果が"Disabled"なら、"Disabled"を返す。

  3. オリジンの機能値取得をfeature、containerのノードドキュメント、origin、report-onlyで実行した結果が"Disabled"なら、"Disabled"を返す。

  4. container policyをパーミッションポリシー属性の処理をcontainerで実行した結果とする。

  5. もしfeatureがcontainer policyに含まれる場合：

    1. そのfeatureの許可リストがoriginに一致するなら、"Enabled"を返す。

    2. それ以外は"Disabled"を返す。

  6. featureのデフォルト許可リストが*なら、"Enabled"を返す。

  7. featureのデフォルト許可リストが'self'かつ、originがcontainerのノードドキュメントのオリジンと同一オリジンなら、"Enabled"を返す。

  8. それ以外は"Disabled"を返す。

9.8. オリジンの機能値取得

機能（feature）、Documentオブジェクト（document）、オリジン（origin）、boolean（report-only）を受け取り、このアルゴリズムはfeatureが無効と見なす場合は"Disabled"、そうでなければ"Enabled"を返します。

  1. policyをreport-onlyがTrueならdocumentのreport-only permissions policy、そうでなければdocumentのpermissions policyとする。

  2. もしpolicyのfeatureの継承ポリシーが"Disabled"なら、"Disabled"を返す。

  3. もしfeatureがpolicyの宣言ポリシーに存在する場合：

    1. policyの宣言ポリシーの宣言[feature]がoriginに一致する場合、"Enabled"を返す。

    2. それ以外は"Disabled"を返す。

  4. "Enabled"を返す。

9.9. Permissions Policyチェック

permissions policy（policy）、機能（feature）、オリジン（origin）、もう一つのオリジン（document origin）を受け取り、このアルゴリズムはfeatureが無効と見なす場合は"Disabled"、そうでなければ"Enabled"を返します。

  1. もしpolicyのfeatureの継承ポリシーが"Disabled"なら、"Disabled"を返す。

  2. もしfeatureがpolicyの宣言ポリシーに存在する場合：

    1. policyの宣言ポリシーの宣言[feature]がoriginに一致する場合、"Enabled"を返す。

    2. それ以外は"Disabled"を返す。

  3. featureのデフォルト許可リストが*なら、"Enabled"を返す。

  4. featureのデフォルト許可リストが'self'で、originがdocument originと同一オリジンなら、"Enabled"を返す。

  5. "Disabled"を返す。

9.10. ドキュメントで機能がオリジンに対して有効か？

機能（feature）、Documentオブジェクト（document）、オリジン（origin）、オプションのboolean（report、デフォルトTrue）を受け取り、このアルゴリズムはfeatureが無効と見なす場合は"Disabled"、そうでなければ"Enabled"を返します。reportがTrueの場合、機能がdocumentのpermissions policyまたはreport-only permissions policyのいずれにも有効でない場合、違反レポートも生成・キューします。

注： reportのデフォルト値Trueは、ほとんどのパーミッションポリシーチェックで、機能が有効でない場合に違反レポートが生成されることを意味します。これは、ほとんどのチェックが実際の機能利用試行のためであるため、期待される結果です。機能の状態をただ問い合わせるだけで実際の機能利用を表さない場合は、reportをFalseにするべきです。

  1. policyをdocumentのpermissions policyとする。

  2. report-only policyをdocumentのreport-only permissions policyとする。

  3. resultをPermissions Policyチェックをpolicy、feature、origin、documentのオリジンで実行した結果とする。

  4. report-only resultをPermissions Policyチェックをreport-only policy、feature、origin、documentのオリジンで実行した結果とする。

  5. もしreportがTrueなら：

    1. settingsをdocumentの環境設定オブジェクトとする。

    2. もしresultが"Disabled"なら：

      1. endpointを機能のレポートエンドポイント取得をfeature、policyで実行した結果とする。

      2. 設定のPermissions Policy違反レポート生成をfeature、settings、"Enforce"、endpointで呼び出す。

    3. それ以外でreport-only resultが"Disabled"なら：

      1. report-only endpointを機能のレポートエンドポイント取得をfeature、report-only policyで実行した結果とする。

      2. 設定のPermissions Policy違反レポート生成をfeature、settings、"Report"、report-only endpointで呼び出す。

  6. resultを返す。

9.11. 機能のレポートエンドポイント取得

feature（feature）およびpermissions policy（policy）を受け取り、このアルゴリズムは違反レポート送信先のエンドポイント名（文字列）を返します。policyでエンドポイントが宣言されていない場合はnullを返します。

  1. configをpolicyの宣言ポリシーのレポート設定とする。

  2. config[feature]が存在する場合は、config[feature]を返す。

  3. nullを返す。

9.12. コンテナでPermissions Policyの潜在的違反チェック

navigable container（container）、string-or-null（allowAttribute）、string-or-null（srcAttribute）を受け取り、このアルゴリズムは潜在的違反レポートを送信します。

  1. documentをcontainerのノードドキュメントとする。

  2. settingsをdocumentの環境設定オブジェクトとする。

  3. 各サポート機能featureについて：

    1. コンテナで機能の継承ポリシーを定義をfeature、container、containerの宣言オリジンで実行した結果が"Disabled"なら：

      1. endpointを機能のレポートエンドポイント取得をfeature、documentのpermissions policyで実行した結果とする。

      2. 設定のPermissions Policy潜在的違反レポート生成をfeature、settings、"Enforce"、endpoint、allowAttribute、srcAttributeで呼び出す。

    2. それ以外でコンテナで機能の継承ポリシーを定義をfeature、container、containerの宣言オリジン、Trueで実行した結果が"Disabled"なら：

      1. report-only endpointを機能のレポートエンドポイント取得をfeature、documentのreport-only permissions policyで実行した結果とする。

      2. 設定のPermissions Policy潜在的違反レポート生成をfeature、settings、"Report"、report-only endpoint、allowAttribute、srcAttributeで呼び出す。

9.13. 設定のPermissions Policy違反レポート生成

feature（feature）、環境設定オブジェクト（settings）、文字列（disposition）、string-or-null（endpoint）を受け取り、このアルゴリズムはfeatureのポリシー違反レポートを生成します。

  1. bodyを新しいPermissionsPolicyViolationReportBodyとして、以下の値で初期化：

    featureId

    featureの文字列表現

    sourceFile

    null

    lineNumber

    null

    columnNumber

    null

    disposition

    disposition

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

  3. generate and queue a reportをbody、"permissions-policy-violation"、endpoint、settingsで実行する。

9.14. 設定のPermissions Policy潜在的違反レポート生成

feature（feature）、環境設定オブジェクト（settings）、文字列（disposition）、string-or-null（endpoint）、string-or-null（allowAttribute）、string-or-null（srcAttribute）を受け取り、このアルゴリズムはfeatureのポリシー潜在的違反レポートを生成します。

  1. bodyを新しいPermissionsPolicyViolationReportBodyとして、以下の値で初期化：

    featureId

    featureの文字列表現

    sourceFile

    null

    lineNumber

    null

    columnNumber

    null

    disposition

    disposition

    allowAttribute

    allowAttribute

    srcAttribute

    srcAttribute

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

  3. generate and queue a reportをbody、"potential-permissions-policy-violation"、endpoint、settingsで実行する。

9.15. リクエストで機能利用を許可すべきか？

feature（feature）、request（request）を受け取り、このアルゴリズムはリクエストがfeatureを利用すべきならtrue、そうでなければfalseを返します。

  1. clientをrequestのclientとする。

  2. clientがnullなら、falseを返す。

  3. clientのglobal objectがWindowでなければ、falseを返す。

    Window以外のコンテキスト（WorkerGlobalScopeやWorkletGlobalScope）でのPermissions Policyはissue #207で議論中。解決後、このアルゴリズムを更新し、こうしたコンテキストでのフェッチに機能制御ポリシーが使えるようにする。解決まではこれらのコンテキスト内ではすべてのポリシー制御機能（例：Client Hintsなど）を不許可とする。

  4. documentをclientのglobal objectの関連Documentとする。

  5. originをrequestのoriginとする。

  6. resultをドキュメントで機能がオリジンに対して有効か？をfeature、document、originで実行した結果とする。

  7. resultが"Enabled"ならtrueを返す。

  8. それ以外はfalseを返す。

10. 他仕様への変更点

10.1. HTML仕様への変更点

すべてのDocumentは、report-only permissions policy（報告のみのpermissions policy）を持ち、これは初期状態で空のpermissions policyです。

7.5.1 共通ドキュメント生成インフラの手順3の後に、以下の手順を挿入：

  1. reportOnlyPermissionsPolicyを、navigationParamsのnavigableのcontainer、navigationParamsのorigin、navigationParamsのresponse、Trueを引数にレスポンスからナビゲーション可能対象のPermissions Policy作成を呼び出した結果とする。

同セクションの手順10で、新しいDocumentのreport-only permissions policyをreportOnlyPermissionsPolicyに設定する。

iframe load event stepsの手順6の後に、以下の手順を挿入：

  1. コンテナでPermissions Policyの潜在的違反チェックをelement、elementのallow属性、elementのsrc属性で呼び出す。

11. IANA考慮事項

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

ヘッダーフィールド名
Permissions-Policy
適用プロトコル
http
ステータス
standard
著者/変更管理者
W3C
仕様書
https://www.w3.org/TR/permissions-policy/

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

この仕様は、埋め込みページに対してポリシーを設定し、それを強制する仕組みを標準化します。iframeのsandboxのように、埋め込まれるページの明示的な許可なしに行うことができ、公開済みウェブサイト上の既存機能の挙動を、適切なコンテナポリシーを持つ別のドキュメントに埋め込むことで変更することが可能です。

このため、最大のプライバシーとセキュリティ上の懸念は次の通りです：

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

セキュリティやプライバシーの課題は、個々の機能の設計によっても生じ得るため、本仕様と統合する際には注意が必要です。このセクションでは、どのような挙動が問題を引き起こす可能性があるかについて指針を示します。

12.1. クロスオリジン挙動の露出

機能は、フレーム内ドキュメントでポリシー違反（violation）が発生しても、他のフレームのドキュメントから観察できないように設計すべきです。例えば、仮想の機能で、ポリシーで無効化された際に埋め込みドキュメントでイベントが発生する場合、埋め込み元がそのイベントを監視することで、埋め込まれたドキュメントの状態情報を取得できてしまいます。例えば、その機能がログイン中にのみ利用されると分かっている場合、埋め込み元はその機能をフレームで無効化し、イベントを監視することでユーザーのログイン状態を推測できます。

内省APIは、サブフレームのポリシー情報を埋め込みドキュメントが既に推測できる範囲のみに限定して表示されるよう設計されています。この可観測ポリシーは、フレームドキュメントで配信されたHTTPヘッダーによって影響されず、フレームが自身でナビゲートしても（異なるオリジンでも異なるポリシーでも）変化しません。src属性の設定によるナビゲーションのみ、可観測ポリシーが更新されます。

12.2. 予期しない挙動の変化

Permissions Policyの仕組みにより、ドキュメントはサブフレームでどの機能を利用可能・不可にするかを制御できます。機能がウェブプラットフォームの既存・長期的な挙動を表している場合、公開済みウェブコンテンツが特定APIが失敗し得ることを想定していない場合があります。

実用的（少し極端ですが）な例として、同期XMLHttpRequestを使ってユーザーが十分な権限を持っているか判定するドキュメントを考えます：

<!DOCTYPE html>
<h1>Welcome to SecureCorp!</h1>
<script>
  var req = new XMLHttpRequest();
  req.open("GET", "/api/security_check.json", false);
  req.send();
  if (req.response == "untrusted user") {
    // User is not logged in; redirect to a safe page
    location.href = "/security_check_failed.html";
  }
</script>
<!-- Page continues with assumption that user is logged in -->

このドキュメントが、"sync-xhr"機能を無効化したページに埋め込まれると、XMLHttpRequest.open()の呼び出しは失敗し、セキュリティチェックが回避されてしまいます。

このような挙動の強制は既にウェブ上で可能です：一部の機能はトップレベルドキュメントでのみ許可され、iframeでは許可されず、iframeのサンドボックス機能を使って同様に依存している機能へのアクセスを防ぐこともできます。

一般的に、この懸念は以下の2つの方法で軽減されます：

Permissions Policyに機能を統合する著者は、ドキュメントが無効状態で機能を利用しようとした際の失敗タイミングや方法を決めることができます。既存の失敗モードがあればそれを活用することで、既存コンテンツが既にその失敗を適切に処理している可能性を高めることができます。

12.3. 埋め込みポリシーの露出

埋め込みページがクロスオリジンページの挙動について推測できる情報は制限されています。しかし一部のケースでは、埋め込み先ページが自身に強制されたポリシーを調査することで、埋め込み元に関する情報を推測できる場合があります。

これは既存のdocument.fullscreenEnabledプロパティにも類似していて、埋め込まれたドキュメントは埋め込み元がFullscreen APIの利用権限を与えているかを推測できます。これが特定条件（例えば、埋め込み元でユーザーがログインしている場合のみ許可）で付与されている場合、埋め込み先サイトは埋め込み元の状態情報を取得することができます。

13. 変更履歴

13.1. FPWD以降の変更点

適合性

文書規約

適合性要件は、記述的な断定とRFC 2119の用語を組み合わせて表現されています。 この文書の規範部分では、「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」というキーワードはRFC 2119で規定された意味で解釈されます。 ただし、可読性のため、これらの語は本仕様書ではすべて大文字では記載されません。

この仕様のすべてのテキストは、非規範と明示されたセクション、例、注記を除き、規範的です。[RFC2119]

この仕様内の例は「例えば」などの語で導入されるか、class="example"で規範文と区別されて提示されます。例えば、以下のようになります:

これは情報提供のための例です。

情報提供的な注記は「注:」という語で始まり、class="note"で規範文と区別されて提示されます。例えば、以下のようになります:

注: これは情報提供のための注記です。

適合アルゴリズム

アルゴリズムの一部として命令形で表現された要件（「先頭の空白文字を削除する」「falseを返してこれらの手順を中止する」など）は、アルゴリズムの導入に用いられるキーワード（"must"、"should"、"may"等）の意味で解釈されます。

アルゴリズムや具体的な手順として表現された適合性要件は、同等の結果となる限り、どのような方法で実装してもかまいません。 特に、本仕様で定義されるアルゴリズムは理解しやすいことを目的としており、パフォーマンスを意図するものではありません。 実装者は最適化を推奨します。

索引

本仕様で定義される用語

参照定義用語

参考文献

規範参考文献

[CSP3]
Mike West; Antonio Sartori. Content Security Policy Level 3. 2025年7月11日. WD. URL: https://www.w3.org/TR/CSP3/
[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/
[FULLSCREEN]
Philip Jägenstedt. Fullscreen API Standard. Living Standard. URL: https://fullscreen.spec.whatwg.org/
[HTML]
Anne van Kesteren; 他. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[REPORTING-1]
Douglas Creager; Ian Clelland; Mike West. Reporting API. 2025年6月11日. WD. URL: https://www.w3.org/TR/reporting-1/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. 1997年3月. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC3864]
G. Klyne; M. Nottingham; J. Mogul. Registration Procedures for Message Header Fields. 2004年9月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc3864
[RFC8941]
M. Nottingham; P-H. Kamp. Structured Field Values for HTTP. 2021年2月. Proposed Standard. URL: https://httpwg.org/specs/rfc8941.html
[URL]
Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/
[WEBIDL]
Edgar Chen; Timothy Gu. Web IDL Standard. Living Standard. URL: https://webidl.spec.whatwg.org/

参考情報

[CSP2]
Mike West; Adam Barth; Daniel Veditz. Content Security Policy Level 2. 2016年12月15日. REC. URL: https://www.w3.org/TR/CSP2/
[HTML5]
Ian Hickson; 他. HTML5. 2018年3月27日. REC. URL: https://www.w3.org/TR/html5/
[MEDIACAPTURE-STREAMS]
Cullen Jennings; 他. Media Capture and Streams. 2025年9月25日. CRD. URL: https://www.w3.org/TR/mediacapture-streams/
[PERMISSIONS]
Marcos Caceres; Mike Taylor. Permissions. 2025年9月26日. WD. URL: https://www.w3.org/TR/permissions/

IDL索引

[Exposed=Window]
interface PermissionsPolicy {
  boolean allowsFeature(DOMString feature, optional DOMString origin);
  sequence<DOMString> features();
  sequence<DOMString> allowedFeatures();
  sequence<DOMString> getAllowlistForFeature(DOMString feature);
};

partial interface Document {
    [SameObject] readonly attribute PermissionsPolicy permissionsPolicy;
};

partial interface HTMLIFrameElement {
    [SameObject] readonly attribute PermissionsPolicy permissionsPolicy;
};

[Exposed=Window]
interface PermissionsPolicyViolationReportBody : ReportBody {
  [Default] object toJSON();
  readonly attribute DOMString featureId;
  readonly attribute DOMString? sourceFile;
  readonly attribute long? lineNumber;
  readonly attribute long? columnNumber;
  readonly attribute DOMString disposition;
  readonly attribute DOMString? allowAttribute;
  readonly attribute DOMString? srcAttribute;
};

課題索引

この仕様は現在、Documentで定義された機能のみを扱っています。WorkersやWorkletsでも機能やpermissions policyを含める表現方法を検討すべきです。 ↵
Window以外のコンテキスト (WorkerGlobalScope または WorkletGlobalScope) でのPermissions Policyは issue #207で議論中。解決後、このアルゴリズムを更新し、こうしたコンテキストでのフェッチに機能制御ポリシーが使えるようにする。 解決まで、これらのコンテキスト内では全てのポリシー制御機能（例：Client Hintsの第三者送信など）を不許可とする。↵
⚠MDN

Headers/Feature-Policy

現在1つのエンジンのみ対応。

FirefoxなしSafariなしChrome60+
Opera?Edge79+
Edge (従来版)?IEなし
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?

Headers/Permissions-Policy

現在1つのエンジンのみ対応。

FirefoxなしSafariなしChrome88+
Opera?Edge88+
Edge (従来版)?IEなし
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?