Permissions Policyによる機能ゲートの委譲モデル

Permissions Policy（旧 Feature Policy）は「このドキュメントとその埋め込みフレームが、どの強力機能を使ってよいか」をオリジン単位で宣言・強制する仕組みです。ユーザー許可ダイアログ（Permissions API）が「使ってよいか人に尋ねる」のに対し、こちらは「そもそも使う資格があるか」を開発者とブラウザが事前に区切ります。両者は直交し、Permissions Policy で塞がれた機能はダイアログすら出ません。ここでは allowlist の評価と委譲の代数を原理から見ていきます。

機能とポリシーの単位

Permissions Policy が制御する対象は 機能（policy-controlled feature） と呼ばれる名前付きの能力です。camera、microphone、geolocation、fullscreen、payment、autoplay、display-capture などが代表で、各機能ごとに独立した allowlist を持ちます。allowlist は「その機能を有効にしてよいオリジンの集合」です。

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

allowlist には4つの基本表現があります。

ここで重要なのは、機能ごとに 既定 allowlist が定義されている点です。既定値は仕様上 *・self・none のいずれかで、機能ごとに決まっています。camera や geolocation、autoplay など多くの強力機能は既定が self（自オリジンのみ、クロスオリジン埋め込みでは無効）です。Permissions-Policy ヘッダを一切送らなくても、各機能はこの既定値で動いています。ヘッダはその既定を上書きする手段にすぎません。

委譲モデル — 親から子への権限の流れ

Permissions Policy の核心は、メインフレームが持つ機能を iframe へ委譲（delegation） できることです。委譲は2つの設定の積で決まります。

1. 親ドキュメントの Permissions-Policy ヘッダの allowlist（その機能が親で有効か、どのオリジンに開かれているか）
2. その iframe を作る <iframe allow="..."> 属性

<!-- 親が geolocation を持つ前提で、この子フレームに委譲 -->
<iframe src="https://maps.example.com/embed"
        allow="geolocation 'src'; camera 'none'"></iframe>

allow 属性の各エントリは「機能名＋許可するオリジン」の並びです。'src' は iframe の src オリジン、'self' は親オリジン、'none' は無効、明示 URL も書けます。allow="geolocation" のように省略すると 'src' を許可した扱いになります。

決定的なのは、子フレームの実効 allowlist は「親の allowlist」と「allow 属性」の積集合（intersection） だという点です。親が geolocation=(self) で自分にしか許していなければ、いくら子の allow="geolocation *" と書いても、子フレームは geolocation を使えません。委譲は「親が持っている権限の一部を渡す」操作であり、無から権限を生み出すことはできません。

継承とサンドボックスの相互作用

委譲は階層的です。フレームが入れ子になると、各段で intersection が累積されます。孫フレームの実効許可は「ルート → 親 → 子 → 孫」の各 allowlist をすべて掛け合わせた結果で、途中のどこか一段でも閉じれば、その下流すべてで無効になります。一度狭めた権限を下層で広げ直すことは原理的にできません。

<iframe sandbox> との関係も整理が要ります。sandbox 属性は origin・スクリプト・フォーム送信などをまとめて剥奪する別系統の隔離機構ですが、Permissions Policy の委譲とは独立に評価されます。サンドボックス化された iframe はオリジンが不透明（opaque）になりやすく、その場合 'src' 指定の委譲先が一致せず機能が通らないことがあります。隔離の設計思想は 同一オリジンポリシーとサイト分離の信頼境界 の信頼境界と地続きで、両者を重ねて考えると挙動の食い違いに迷いません。

ヘッダ・allow・既定値の優先関係

実際にある機能が「このフレームで使えるか」は、複数の入力が合流して決まります。評価の流れは次のように整理できます。

Permissions-Policy ヘッダの値は、HTTP の Structured Field（構造化フィールド）構文に従います。値の文字列オリジンは二重引用符で囲み、self や * は引用符なしのトークンです。ここを混同すると静かにパース失敗して機能が既定値のまま、という事故が起きやすいので注意します。

レポーティング — 違反を観測する

ポリシーをいきなり厳格化すると、正規の機能まで止まってページが壊れます。これを避けるため、Permissions Policy は Reporting API と連携し、違反を観測できます。機能がポリシーで拒否されると、permissions-policy-violation タイプのレポートが生成され、Reporting-Endpoints（または旧 Report-To）で指定したエンドポイントへ送られます。

Reporting-Endpoints: pp-endpoint="https://report.example.com/pp"
Permissions-Policy: camera=(self), geolocation=(self)

ページ内では ReportingObserver で同じ違反を JavaScript から拾えます。

const observer = new ReportingObserver((reports) => {
  for (const r of reports) {
    if (r.type === "permissions-policy-violation") {
      // r.body.featureId に拒否された機能名が入る
      console.warn("blocked:", r.body.featureId);
    }
  }
}, { types: ["permissions-policy-violation"] });
observer.observe();

これにより、どの埋め込みフレームがどの機能を要求して弾かれたかを本番投入前に可視化できます。CSP の Report-Only 段階と同じく、まず観測して影響範囲を測り、それから allowlist を締めるのが安全な導入手順です。なお収集データの計測手法は Performance Measurement API の内部設計 と同じ Reporting／Observer 系の発想で動きます。

旧 Feature-Policy との違い

歴史的経緯として、この仕組みは当初 Feature Policy と呼ばれ、Feature-Policy ヘッダと異なる構文を持っていました。

両ヘッダが同時に送られた場合、対応ブラウザは新しい Permissions-Policy を優先します。古い記事の Feature-Policy: geolocation 'self' をそのまま Permissions-Policy に貼ると構文エラーになるため、移行時は機械的なコピーではなく構文変換が必要です。