Summary

  • W3Cが2019年に公開したFeature Policyの草案は、位置情報や全画面表示、カメラ、マイクなどのブラウザー機能をページ側で制限する仕組みを示した。
  • 2026年9月のPermissions Policy草案では、ページのHTTP応答ヘッダーと個別のiframeのallow属性を組み合わせ、親から子へ規則を継承させる。

ページを小さな劇場だと思えば分かりやすい。地図は一つの舞台、動画は別の舞台、決済用の部品は奥の小部屋にいる。地図は位置を知りたがり、動画は全画面を使いたがり、会議ツールはカメラを欲しがる。出演を認めた相手に、舞台裏の鍵束まで渡す必要はない。

2019年4月のW3C初公開Feature Policy草案は、劇場の規則をHTTP応答へ載せた。Feature-Policyヘッダーで機能を閉じたり、許されるオリジンを選んだりできる。草案の例では全画面表示と位置情報を制限し、カメラやマイクを特定の埋め込み先に絞る。家主の意思を、ページを届ける応答と一緒にブラウザーへ渡す仕組みだった。

2026年9月のPermissions Policy草案は、この仕様が以前Feature Policyと呼ばれていたと明記する。今のPermissions-Policyヘッダーは構造化された辞書を使う。fullscreen=(), geolocation=()という例では二つの機能の許可先を空にする。親ページから子の部屋まで、該当する扉は閉まる。子の看板に「歓迎」と書いても、建物の閉鎖規則は消えない。

一方、地図の部屋だけに位置情報を使わせたい場合は、そのiframeにallow="geolocation"を付けられる。ヘッダーで許容するオリジンの外枠を決め、allowで具体的な部屋を選ぶ。2026年草案の例では、親の規則に指定オリジンを含めたうえで、必要なフレームへ機能を委ねる。隣の動画プレーヤーが、地図に渡した鍵を横から使うことはできない。

鍵は親から子へ規則として受け継がれる。機能には既定の許可リストがある。親文書は応答ヘッダーで宣言した政策を持つ。iframeはコンテナの政策を持つ。子文書が作られたり移動したりするとき、ブラウザーは親とコンテナから初期状態を計算する。子はその範囲で自分の方針を定められる。親が閉めた扉を子が内側から開け直す仕組みではない。

つまり、外部部品をiframeに入れただけでは権限の話は終わらない。枠は表示場所を分けるが、位置情報、カメラ、マイク、全画面表示は読者の体験へ直接出てくる機能だ。家主は部品を招き入れながら、利用できる機能を個別に決める必要がある。政策はその決定をブラウザーが扱える形へ変えた。

2026年草案では結果を問い合わせる手段も示す。文書のpermissionsPolicyやフレーム側の政策を調べれば、ある機能が使える状態か分かる。位置を得られない地図なら住所入力を前に出せる。カメラを使えない部品なら撮影ボタンを引っ込められる。政策は機能の入口を扱う。利用者の許可や機器の状態は、その後の別の判断になる。

W3Cの公開履歴には2026年9月までの作業草案が並ぶ。ページは他のページの一部を迎え入れ、ブラウザーはますます多くの機能を持つようになった。劇場には総則と部屋ごとの通行証が必要だったのである。