webappsec-permissions-policy-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>Permissions Policy （日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="common-w3c.css" type="text/css">

<script src="common0.js"></script>
<script src="common1.js" async></script>

<script>

Util.ready = function(){
	const source_data = {
		toc_main: 'MAIN0',
		generate: expand
	};
	Util.switchWordsInit(source_data);
}

function expand(){
	const class_map = this.class_map;
	const tag_map = this.tag_map;
	const link_map = this.link_map;

	return this.html.replace(
		/%[\w\-~一-鿆あ-ん]+|`(.*?)([$@^])(\w*)/g,
		create_html
	);

	function create_html(match, key, indicator, klass){

if(!indicator) {//%
	return `<var>${match.slice(1)}</var>`;
}

let href = '';
let href1 = '';
{
	const n = key.indexOf('＠');
	if(n > 0) {
		href1 = key.slice(n + 1);
		key = key.slice(0, n);
	}
}
let text = key;

switch(klass){
case 'r':
	text = `[${key}]`;
	href = `#biblio-${key.toLowerCase()}`;
	break;
case 'l': //literal
	text = `"<code class="literal">${key}</code>"`;
	break;
case 'bl':
	text = `\`<code class="literal">${key}</code>\``;
	break;
case 'm' : // interface member
	const n = text.indexOf('(');
	if(n > 0){
		key = text.slice(0, n);
		text = key + text.slice(n).replace(/\w+/g, '<var>$&</var>');
	}
	break;
case 'sf': // structured fields
	text = `<sub>sf-</sub>${text}`;
	break;
case 'U':
	text = `U+${key}`;
	break;
case 'pull':
	text = '~link';
	href = `https://github.com/w3c/webappsec-permissions-policy/pull/${key}`;
	break;
case 'en':
	return `<span lang="en">${key}</span>`;
	break;
}

let tag = tag_map[klass];
if(tag) {
	let classname = class_map[klass];
	classname = classname ? ` class="${classname}"` : '';
	text = `<${tag}${classname}>${text}</${tag}>`;
}

if(indicator !== '^'){
	href = href1 || link_map[ klass ? `${klass}.${key}` : key ] || href;
	if(!href){
		console.log(match); // check error
		return match;
	}

	switch(indicator){
	case '$':
		text = `<a href="${href}">${text}</a>`;
		break;
	case '@':
		text = `<dfn id="${href.slice(1)}">${text}</dfn>`;
		break;
	}
}

return text;

	}
}
</script>

<script type="text/plain" id="_source_data">

●●options

spec_title:Permissions Policy
spec_date:2025-02-10
trans_update:2025-02-15
source_checked:230525
page_state_key:WEBAPPSEC
original_url:https://w3c.github.io/webappsec-permissions-policy/
	abbr_url:PERMISSIONS-POLICY
spec_status:ED
ref_id_prefix:biblio-
ref_id_lowercase:true
	site_nav:
conformance:w3c
copyright:2025,permissive
trans_1st_pub:2018-07-15


●●class_map
P:production
e:element
a:attr
aF:attr
dir:directive
v:value
h:header
U:code-point

●●tag_map
p:var
P:code
dir:code
h:code
I:code
m:code
v:code
c:code
e:code
a:code
aF:code
s:samp
U:span
i:i
em:em
cite:cite

●●original_id_map

	dom-permissionspolicyviolationreportbody-columnnumber:permissionspolicyviolationreportbody-columnnumber
	dom-permissionspolicyviolationreportbody-disposition:permissionspolicyviolationreportbody-disposition
	dom-permissionspolicyviolationreportbody-featureid:permissionspolicyviolationreportbody-featureid
	dom-permissionspolicyviolationreportbody-linenumber:permissionspolicyviolationreportbody-linenumber
	dom-permissionspolicyviolationreportbody-message:permissionspolicyviolationreportbody-message
	dom-permissionspolicyviolationreportbody-sourcefile:permissionspolicyviolationreportbody-sourcefile
	dom-permissionspolicyviolationreportbody-allowattribute:permissionspolicyviolationreportbody-allowattribute
	dom-permissionspolicyviolationreportbody-srcattribute:permissionspolicyviolationreportbody-srcattribute

●●mdn_urls
permissions-policy-header:HTTP/Headers/Feature-Policy

●●link_map

	●IDL
Default:~WEBIDLjs#Default
Exposed:~WEBIDLjs#Exposed
SameObject:~WEBIDLjs#SameObject

sequence:~WEBIDL#idl-sequence
boolean:~WEBIDL#idl-boolean
DOMString:~WEBIDL#idl-DOMString
long:~WEBIDL#idl-long
object:~WEBIDL#idl-object

I.PermissionsPolicyViolationReportBody:#permissionspolicyviolationreportbody
I.PermissionsPolicy:#permissionspolicy
I.ReportBody:~REPORTING#reportbody
	I.Node:~DOM4#node → ~node
	I.Element:~DOM4#element → 要素
I.Document:~DOM4#document
	→ `文書$
I.HTMLIFrameElement:~HEembed#htmliframeelement
I.XMLHttpRequest:~XHR#xmlhttprequest
I.Window:~WINDOW#window
I.WorkerGlobalScope:~WORKERS#workerglobalscope
I.WorkletGlobalScope:~WORKLETS#workletglobalscope

m.~permissionsPolicyD:#dom-document-permissionspolicy
c.document.permissionsPolicy:#dom-document-permissionspolicy
m.~permissionsPolicyF:#dom-htmliframeelement-permissionspolicy


m.toJSON:#dom-permissionspolicyviolationreportbody-tojson
m.columnNumber:#dom-permissionspolicyviolationreportbody-columnnumber
m.disposition:#dom-permissionspolicyviolationreportbody-disposition
m.featureId:#dom-permissionspolicyviolationreportbody-featureid
m.lineNumber:#dom-permissionspolicyviolationreportbody-linenumber
m.sourceFile:#dom-permissionspolicyviolationreportbody-sourcefile
m.allowAttribute:#dom-permissionspolicyviolationreportbody-allowattribute
m.srcAttribute:#dom-permissionspolicyviolationreportbody-srcattribute
	columnNumber:#permissionspolicyviolationreportbody-columnnumber
	disposition:#permissionspolicyviolationreportbody-disposition
	featureId:#permissionspolicyviolationreportbody-featureid
	lineNumber:#permissionspolicyviolationreportbody-linenumber
	sourceFile:#permissionspolicyviolationreportbody-sourcefile
	allowAttribute:#permissionspolicyviolationreportbody-allowattribute
	srcAttribute:#permissionspolicyviolationreportbody-srcattribute

m.allowedFeatures:#dom-permissionspolicy-allowedfeatures
m.allowsFeature:#dom-permissionspolicy-allowsfeature
m.features:#dom-permissionspolicy-features
m.getAllowlistForFeature:#dom-permissionspolicy-getallowlistforfeature

m.requestFullscreen:~FULLSCREEN#dom-element-requestfullscreen
m.allow:~HEembed#dom-iframe-allow
	m.allow:#dom-htmliframeelement-allow
m.document.fullscreenEnabled:~FULLSCREEN#dom-document-fullscreenenabled


e.iframe:~HEembed#the-iframe-element

aF.sandbox:~HEembed#attr-iframe-sandbox
aF.src:~HEembed#attr-iframe-src
aF.srcdoc:~HEembed#attr-iframe-srcdoc
aF.allow:~HEembed#attr-iframe-allow
aF.allowfullscreen:~HEembed#attr-iframe-allowfullscreen

dir.sandbox:~CSP3#sandbox

P.*:#the-special-value
i.全~生成元:#default-allowlist
P.self:#_self
l.'self':#default-allowlist-self

P.serialized-permissions-policy:#serialized-permissions-policy
P.serialized-policy-directive:#serialized-policy-directive
P.feature-identifier:#feature-identifier
P.allow-list:#allow-list
P.allow-list-value:#allow-list-value
P.permissions-source-expression:#permissions-source-expression
P.host-source:~CSP3#grammardef-host-source
P.scheme-source:~CSP3#grammardef-scheme-source

P.sf-dictionary:~STRUCTURED-FIELDS#p.sf-dictionary

h.Permissions-Policy:#permissions-policy-header
h.Permissions-Policy-Report-Only:#permissions-policy-report-only-header

	●用語


許容list:#allowlist
新たな許容list:#_new-allowlist
AL.自己-生成元:#self-origin
AL.~src生成元:#src-origin
AL.式~群:#expressions
許容listは生成元に合致するか？:#matches

	§許容-属性:#iframe-allow-attribute

宣言-済み施策:#declared-policy
新たな宣言-済み施策:#_new-declared-policy
dP.宣言~群:#declared-policy-declarations
dP.報告用~環境設定:#declared-policy-reporting-configuration
許可~施策:#permissions-policy
pP.継承した施策:#permissions-policy-inherited-policy
pP.宣言-済み施策:#permissions-policy-declared-policy
継承される施策:#permissions-policy-inherited-policy
既定の許容list:#policy-controlled-feature-default-allowlist
特能~用に継承される施策:#inherited-policy-for-a-feature
~header施策:#header-policy
容器~施策:#container-policy
空な許可~施策:#empty-permissions-policy

施策により制御される特能:#policy-controlled-feature
~token:#policy-controlled-feature-tokens
特能:#policy-controlled-feature
施策~指令:#policy-directive
~support済み特能:#supported-features

違反:#violate
違反-:#violate
結付けられた~node:#associated-node
宣言された生成元:#declared-origin
既定の生成元:#default-origin
観測-可能な施策:#observable-policy
許可~施策~違反~報告:#permissions-policy-violation-reports
doc.施策~obj:#document-policy-object
iF.施策~obj:#iframe-policy-object

	algo
応答~施策を処理する:#process-response-policy
辞書と生成元から施策を構築する:#construct-policy
施策~指令を構文解析する:#parse-policy-directive
許可~施策~属性を処理する:#process-policy-attributes
~navigable用の許可~施策を作成する:#create-for-navigable
応答から~navigable用の許可~施策を作成する:#create-from-response
生成元~用の特能~値を取得する:#get-feature-value-for-origin
生成元に属する容器~内の特能~用に継承される施策を定義する:#define-inherited-policy-in-container
文書~内の特能は生成元~用に可能化されるか？:#is-feature-enabled
容器~内の許可~施策の潜在的な違反を検査する:#check-potential-violation-in-container
設定群に対し許可~施策の違反~用に報告を生成する:#report-permissions-policy-violation
設定群に対し許可~施策の潜在的な違反~用の報告を生成する:#report-potential-permissions-policy-violation
要請には特能の利用は許容されるべきか？:#should-request-be-allowed-to-use-feature
許可~施策を検査する:#check-permissions-policy
特能~用の報告用~端点を取得する:#get-reporting-endpoint

doc.報告のみの許可~施策:#document-report-only-permissions-policy

属する文書:#_documents-in-a-navigable

	＠#structured-header-serialization

	●外部
文字列:~INFRA#string
~ASCII大小無視:~INFRA#ascii-case-insensitive
~ASCII小文字~化する:~INFRA#ascii-lowercase
~ASCII空白で分割する:~INFRA#split-on-ascii-whitespace
区切子で厳密に分割する:~INFRA#strictly-split
~list:~INFRA#list
付加する:~INFRA#list-append
有順序~集合:~INFRA#ordered-set
set.付加する:~INFRA#set-append
有順序~map:~INFRA#ordered-map
map.~key:~INFRA#map-key
map.値:~INFRA#map-value
構造体:~INFRA#struct
sct.~item:~INFRA#struct-item


有構造~field:~STRUCTURED-FIELDS#structured-field
有構造~header:~STRUCTURED-FIELDS#structured-header
sf.~token:~STRUCTURED-FIELDS#sf-token
sf.文字列:~STRUCTURED-FIELDS#sf-string
sf.内縁~list:~STRUCTURED-FIELDS#sf-inner-list
sf.~item:~STRUCTURED-FIELDS#sf-item
sf.辞書:~STRUCTURED-FIELDS#sf-dictionary
	sf.辞書:~STRUCTURED-FIELDS#dictionary
sf.~key:~STRUCTURED-FIELDS#sf-key
sf.~parameter:~STRUCTURED-FIELDS#sf-parameter
sf.~parameter群:~STRUCTURED-FIELDS#sf-parameters


doc.許可~施策:~HTMLdom#concept-document-permissions-policy

~URLを相対的に構文解析する:~HTMLurl#parse-a-url
~URLを符号化法の下で相対的に構文解析する:~HTMLurl#encoding-parsing-a-url

~iframe~load~event手続き:~HEembed#iframe-load-event-steps

生成元:~ORIGIN#concept-origin
	原文）rq.生成元:~FETCH#concept-request-origin
不透明な生成元:~ORIGIN#concept-origin-opaque
生成元を直列化する:~ORIGIN#ascii-serialisation-of-an-origin
同一-生成元:~ORIGIN#same-origin
同じ生成元~domain:~ORIGIN#same-origin-domain
閲覧~文脈~sandbox化( 生成元 )~flag:~ORIGIN#sandboxed-origin-browsing-context-flag
作動中な~sandbox法~flag集合:~ORIGIN#active-sandboxing-flag-set
~navigable:~HTMLds#navigable
nav.親:~HTMLds#nav-parent
子孫~navigable群:~HTMLds#descendant-navigables
子~navigable:~HTMLds#child-navigable
~navigable容器:~HTMLds#navigable-container
内容~文書:~HTMLds#concept-bcc-content-document
内容~navigable:~HTMLds#content-navigable
~top-level辿可能:~HTMLds#top-level-traversable
~node~navigable:~HTMLds#node-navigable
nav.作動中な文書:~HTMLds#nav-document
nvP.~navigable:~HTMLnav#navigation-params-navigable
nvP.応答:~HTMLnav#navigation-params-response
nvP.生成元:~HTMLnav#navigation-params-origin
nav.容器:~HTMLds#nav-container

環境~設定群~obj:~WAPI#environment-settings-object
enV.大域~obj:~WAPI#concept-settings-object-global

~node:~DOM4#concept-node
要素:~DOM4#concept-element
文書:~DOM4#concept-document
	文書:~HTMLdom#the-document-object
~node文書:~DOM4#concept-node-document
doc.生成元:~DOM4#concept-document-origin

~URL構文解析する:~URL1#concept-url-parser
url.生成元:~URL1#concept-url-origin
	→ 生成元

要請:~FETCH#concept-request
rq.~window:~FETCH#concept-request-window
rq.生成元:~FETCH#concept-request-origin

応答:~FETCH#concept-response
	原文誤）応答:~FETCH#concept-response-response
rs.~header~list:~FETCH#concept-response-header-list
hd.値:~FETCH#concept-header-value
有構造~field値を取得する:~FETCH#concept-header-list-get-structured-header
結付けられた文書:~WINDOW#concept-document-window

強力な特能:~PERMISSIONS#dfn-powerful-feature
~URLは ( 生成元, ~redirect回数 ) について式に合致するか？:~CSP3#match-url-to-source-expression

報告:~REPORTING#report
rP.本体:~REPORTING#report-body
報告~種別:~REPORTING#report-type
報告用~観測器から可視:~REPORTING#visible-to-reportingobservers
報告を生成して~queueする:~REPORTING#generate-and-queue-a-report

●●words_table1

permissionsPolicyD:permissionsPolicy
permissionsPolicyF:permissionsPolicy
HTTPch:http-client-hints-ja.html

●●words_table

	●施策／feature

許容list:allowlist::許容 list:許容リスト
Geolocation:
地理所在:geolocation::~
Fullscreen:

報告用:reporting::~::レポート用
報告先:endpoint::~::レポート先
	報告のみ:report-only
列番号:column number:~
行番号:line number:~

	施策により制御される:policy-controlled
	~support済み特能:recognized feature 


	●環境
Worker:
Worklet:
下位frame:subframe::下位 frame:下位フレーム

	~frame化され:framed
	`iframe^e:iframe
	`iframe^e 化:iframing
	自身が埋込む〜~host:embedee
	埋込んだ側／埋込む側:embedder
	ある:embedding〜
	不能化-:off
仮想現実:virtual reality::~
WebUSB:
WebXR:
fullscreen::::全スクリーン
再構成-:restructure::~

	●network
social::::ソーシャル
下位domain:subdomain:::下位ドメイン
端点:endpoint::~::エンドポイント

	^en:Client Hints

	●保安
予防策:precaution::~
	監禁:lock down
推定-:infer::~
特権:privilege::~
脆弱:vulnerable::~
迂回-:bypass::~
log-in:log in:::ログイン
予想外の:unanticipated:~
不自然な:contrived:~
	予期することなく書かれた:not written with the expectation
明示-:express:~
	信用できない:potentially untrusted
露呈-:reveal::~

	~~影響は抑えられる:increase the chance that
	悪化させ:make worse
	無用に:needlessly
	最も重大な:biggest
	長期に存在していた:existing, long-standing
	隔離する下で:in isolation of

	●データ／構文
直列形の:serialized::~::シリアル形の
式:expression:~
wildcard:
src:
allow:

	直列化された宣言:serialized-declaration
	文字列:character strings
	-:separated
	-:concatenation
	%~URL:url
	%~item:element
	%応答~施策:d
	有構造~field$:Structured Field:#1
	辞書$sf:Dictionary
	辞書$sfの~member:Dictionary Member
	~member:Member
	~memberの名前:Name
	~memberの値:Value
	文字列$sf:String
	~token$sf:Token
	内縁~list:Inner List
	~T:True
	`可能化される^i:"Enabled"
	`不能化される^i:"Disabled"
	`辞書^i:"dictionary"

	●変数
params::::パラメタ群
処置:disposition::~

	%~navigable
	%特能:feature
	%許容list:allowlist
	%許容list:the allowlist
	%生成元:origin
	%~URL:url
	%式:permissions-source-expression item
	%親~文書: parent’s document
	%要素:the iframe element
	%P:PermissionsPolicy object
	%P:PermissionsPolicy instance
	%~node:associated node
	%文書:’s node document
	%文書:document
	%文書:Each Document
	%要素:Each iframe element
	%施策:policy
	%結果:result
	%~item:item
	%~item:element
	%~node
	%継承した施策:inherited policy
	%要素:node
	%要素:element
	%応答:response
	%構文解析した~header:parsed header
	%辞書:dictionary
	%特能~名:feature-name
	%値:value
	%容器~生成元:container origin
	%~target生成元:target origin
	%指令:directive
	%直列形の宣言:serialized-declaration
	%~token群:tokens
	%~target~list:targetlist
	%~target:target
	%容器~施策:container policy
	%容器:container
	%応答~施策:d
	%内容~生成元:origin
	%設定群:settings
	%~params:params
	%~navi~params:navigationParams
	%処置:disposition
	%本体:body
	%要請:request
	%~window:window
	%報告するか:report
	%報告のみか:report-only
	%報告のみの施策:report-only policy
	%報告のみの結果:report-only result
	%報告先:endpoint
	%報告先:-
	%環境設定:config
	%報告のみの許可~施策:reportOnlyPermissionsPolicy
	%~navi~params:navigationParams
	%報告用~環境設定:reporting-config
	%文書~生成元:document origin
	%宣言-済み施策:-
	%~header名:header name
	%宣言~群:declarations
	%報告のみの報告先:report-only endpoint
	%~allow属性:allowAttribute
	%~src属性:srcAttribute

	●仕様
有効:effective:~
可能性:possibility:~
不可能:impossible:~
多彩:rich:~
	より多彩な:richer
姉妹:companion:~
	任意選択で元に戻す:opt back in
自己検分:introspection:~
約束:promise:~
選択的:selective:~
	詳細はそれらを参照すること。:references which ought to be consulted for detailed information
演繹-:deduce:~
変種:variant:~
末端-:end-:~
責務:responsibility:~
作成者:creator::~
帰属-:attribute:~
潜在的:potential:~

	~custom化:customize
	効果を発揮している:in effect
	難しい:hard
	欠如:lack of thereof
	この仕様:Permissions Policy
	絶えず発展し続ける:ever-expanding
	これまで無かった:missing piece
	任意選択で外す:opt-out
	簡潔にするため:for brevity
	ある程度:to a degree
	に足る:sufficient
	仮に，ある:hypothetical
	組合せて:in combination with
	指す:refer
	~~参照:refer
	support済み:supported
	〜で定義されている:〜-defined
	拡張-可能:extensible／:extendable
	期待されない:unexpected
	求まれない:unwanted
	重複-:duplicate
	もたらす／:caused
	知り:learn
	課す:impose
	略称され:referred to 〜 simply as 
	対処:deals with
	可能性も含みにする言い回しを見つける:figure out how to word this to include the possibility of
	他が指示されない限り:unless otherwise indicated
	現時点で定義されている:currently-defined
	書ける:can be written
	模索中:being figured out
	最初の公な草案:FPWD
	非推奨にされた:deprecation
	感触を得た:feel
	そのような試みではなく:does not represent an actual attempt to use the feature
	~~特注:bespoke
	~~管理下におく:heep 〜 in charge
	自身の責任の下で:responsibly

	●未分類
Geolocation:
	CSP:Content Security Policy
FastCorp:
SecureCorp:
JSPlaygroundCorp:
PlatformCorp:
	~target~list:targetlist
恒久的:permanent:~
地図:map:~
給する:supplyする:~
回数:count:~
component::::コンポーネント
game::::ゲーム
camera::::カメラ
microphone::::マイクロホン
知覚-:perceive:~
UX:
埋込-:embed::埋め込み
	埋込-可能:embeddable
市場:marketplace:~
遊ぶ:playする:~
iframe:
load:

	-:cross-origin
	-:expand
	現れ:appear
	挙げら:mention
	~EQ ε:omit
	有する:presence
	-:documented
	-:property
	~web~platform:web-platform
	^en:fast path
	~RET:abort these steps
	^I:XMLHttpRequest
	社:Inc.
	-:in place for
	^l:payment
	^l:sync-xhr
	何であれ:whatever
	~obj:instance
	-:isInherited
	それ以上の:no further
	-:single
	~F :False
	~T :True
	あらゆる:every
	および:as well as
	にわたって:across
	も:as well
	一連の:set of
	長い方の:longer
	個々の:each individual
	別に:alongside
	nor
	thereof
	~~別個:discrete
	各:each piece of
	もっと長い:longer
	~NULL:omitted

●●ref_normative

[CSP3]
    Mike West; Antonio Sartori. ＜Content Security Policy Level 3＞. URL: https://w3c.github.io/webappsec-csp/
[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; et al. ＜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＞. URL: https://w3c.github.io/reporting/
[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
[RFC8941]
    M. Nottingham; P-H. Kamp. ＜Structured Field Values for HTTP＞. February 2021. 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/

●●ref_informative

[CSP2]
    Mike West; Adam Barth; Daniel Veditz. ＜Content Security Policy Level 2＞. URL: https://w3c.github.io/webappsec-csp/
[HTML5]
    Ian Hickson; et al. ＜HTML5＞. 27 March 2018. REC. URL: https://www.w3.org/TR/html5/
[MEDIACAPTURE-STREAMS]
    Cullen Jennings; et al. ＜Media Capture and Streams＞. URL: https://w3c.github.io/mediacapture-main/
[PERMISSIONS]
    Marcos Caceres; Mike Taylor. ＜Permissions＞. URL: https://w3c.github.io/permissions/


●●trans_metadata
<p>
~THIS_PAGEは、~W3Cにより編集者草案として公開された
<a href="~SPEC_URL">Permissions Policy</a>
を日本語に翻訳したものです。
~PUB
</p>

●●spec_metadata

最新公表バージョン
	https://www.w3.org/TR/permissions-policy/
公表履歴
	https://www.w3.org/standards/history/permissions-policy-1/
編集者草案
	https://w3c.github.io/webappsec-permissions-policy/

フィードバック
	<a href="https://github.com/w3c/webappsec-permissions-policy/issues">GitHub</a>

編集
	<a href="mailto:iclelland@google.com">Ian Clelland</a> (Google)
commit 履歴
	https://github.com/w3c/webappsec-permissions-policy/commits/main/

公表者
	<a href="https://www.w3.org/groups/wg/webappsec">Web Application Security Working Group</a>

</script>

</head><body>

<header>
	<hgroup>
<h1>許可施策 — Permissions Policy</h1>
	</hgroup>
</header>

<div id="MAIN" hidden>
	<section id="abstract">
◎要約

<p>
この仕様は、
~browserに備わる様々な［
特能や~API
］の利用を選択的に［
可能化する／不能化する
］ことを，開発者に許容する仕組みを定義する。
◎
This specification defines a mechanism that allows developers to selectively enable and disable use of various browser features and APIs.
</p>

	</section>
	<section id="sotd">
◎位置付け

<p>
これは編集者草案の公な複製です…
【以下、この節の他の内容は，~SOTD-W3Cに移譲。】
</p>

<p><strong>
この文書に対する変更点は、
`https://github.com/w3c/webappsec＠https://github.com/w3c/webappsec$
にて追跡できます。</strong>
◎
Changes to this document may be tracked at https://github.com/w3c/webappsec.
<p>

	</section>

<main id="MAIN0">

	<section id="_conventions">
<h2>【この訳に特有な表記規約】</h2>

◎表記記号

<p>
一部の箇所では、
既存の用語を利用して記述を簡約している。
</p>

<p>
原文には明示的に定義されていないが、
所与の
( `~navigable$ %~navigable )
に対し，
%~navigable に
`属する文書@
とは、
次を満たす`文書$たちを指す
⇒
その`~node~navigable$ ~EQ %~navigable
</p>

<p>
これは、
%~navigable にて`作動中な文書$navを意図している箇所もあるかもしれない
（明示的に参照されていないので，はっきりしない）。
</p>

	</section>
	<section id="introduction">
<h2 title="Introduction">1. 序論</h2>

<p>
~web~platformは、
絶えず発展し続ける［
特能や~API
］たちが成す集合を供して，より［
多彩な機能性, 開発者にとって使い勝手の良さ, 改善された処理能
］を提供する。
しかしながら、
開発者が，~browserに備わるこれらの［
特能や~API
］のうち一部の挙動を 自身の~appの中で選択的に［
可能化- ／ 不能化- ／ 改変-
］する能は、
これまで無かった：
◎
The web platform provides an ever-expanding set of features and APIs, offering richer functionality, better developer ergonomics, and improved performance. However, a missing piece is the ability for the developer to selectively enable, disable, or modify the behavior of some of these browser features and APIs within their application:
</p>
<ol>
	<li>
開発者は、
~browserに備わる ある種の［
特能や~API
］への~accessを 選択的に`不能化-^emしたいと求めることもある
— ~securityや処理能のための予防策として，自身の~appの中で実行されている［
自前の／第三者-主体の
］内容が［
求まれない／期待されない
］挙動を導入するのを防止して，自身の~appを “監禁する” ために。
◎
The developer may want to selectively disable access to certain browser features and APIs to "lock down" their application, as a security or performance precaution, to prevent own and third-party content executing within their application from introducing unwanted or unexpected behaviors within their application.
</li>
	<li>
開発者は、［
既定では不能化され得るような，~browserに備わる ある種の［
特能や~API
］］への~accessを，選択的に`可能化-^emしたいと求めることもある
— 例：一部の特能は、［
埋込まれた文脈においては、
明示的に可能化されない限り，既定で不能化される
］こともあれば［
他の施策~要件の~subjectになる
］こともある。
◎
The developer may want to selectively enable access to certain browser features and APIs which may be disabled by default - e.g. some features may be disabled by default in embedded context unless explicitly enabled; some features may be subject to other policy requirements.
</li>
	<li>
<p>
開発者は、［
ある種の［
特能や~API
］の［
利用, または欠如
］について，自身の~app［
の~client／を埋込む側
］に約束する
］ことを表明するような施策を利用したいと求めることもある。
例えば：
</p>
		<ul>
			<li>
~browserにおいて ある種の “`fast path^en”† 最適化を可能化するため。
【†よくある事例~用の “優先路”（観光客専用の入出国手続きの様な）】
</li>
			<li>
埋込む側
— 例：様々な~social~network, 探索~engine, 等々 —
が設定した一部の要件に対する適合性についての約束を表明するため。
</li>
		</ul>
◎
The developer may want to use the policy to assert a promise to a client or an embedder about the use—or lack of thereof—of certain features and APIs. For example, to enable certain types of "fast path" optimizations in the browser, or to assert a promise about conformance with some requirements set by other embedders - e.g. various social networks, search engines, and so on.
</li>
</ol>

<p>
この仕様は、
上の利用事例に取組む施策の仕組みを定義する。
◎
This specification defines a policy mechanism that addresses the above use cases.
</p>

<p class="note">注記：
この仕様は、
以前は “`Feature Policy^en” （ “特能~施策” ）と命名されていた†。
◎
This specification used to be named Feature Policy.
</p>

<p class="trans-note">【†
“`Feature Policy^en”
を名前の一部に含む［
用語, ~IDL構成子, ~header, 原文の~URL, GitHub 内の関連な~pageの~URL, 等々
］も，すべて
“`Permissions Policy^en （許可~施策）”
に改称された
（文字大小は問わず，文字大小や約物はそのままに）。
】</p>

	</section>
	<section id="examples">
<h2 title="Examples">2. 例</h2>

<div class="example">
<p>
~SecureCorp社は、
自身の~appの中では［
~Fullscreen／~Geolocation
］~APIの利用を不能化したいと求めているとする。
次のような許可~施策を定義する~HTTP応答~headerを送達すれば、
それを行える：
◎
SecureCorp Inc. wants to disable use of Fullscreen and Geolocation APIs within their application. It can do so by delivering the following HTTP response header to define a permissions policy:
</p>

<pre class="lang-http">
`Permissions-Policy$h: fullscreen=(), geolocation=()
</pre>

<p>
空な生成元~listを指定することにより、
指定された特能は
— 入子なものも含め，どの文書においても、
その生成元に関わらず —
不能化されることになる。
◎
By specifying an empty origin list, the specified features will be disabled for all documents, including nested documents, regardless of their origin.
</p>
</div>

<div class="example">
<p>
地理所在（ `geolocation^en ）は、
非同一-生成元に属する どの~frame内でも，既定では不能化される。
~FastCorp社の~siteは、
特定の非同一-生成元 `iframe$e 内では地理所在を可能化したいと求めているとする。
そうするためには、
`iframe^e 要素に `allow$aF 属性を含ませる：
◎
Geolocation is disabled by default in all cross-origin frames. FastCorp Inc. has a specific cross-origin iframe on their site for which it wants to enable geolocation. It can do so by including an "allow" attribute on the iframe element:
</p>

<pre class="lang-html">
&lt;iframe src="https://other.com/map" allow="geolocation"&gt;&lt;/iframe&gt;
</pre>

<p>
各種 `iframe^e 用の属性は、
一定の~frame内に限り，選択的に特能を可能化できる
— 他では，同じ生成元からの文書を包含する場合でも可能化しないように。
◎
Iframe attributes can selectively enable features in certain frames, and not in others, even if those contain documents from the same origin.
</p>
</div>

<div class="example">
<p>
~SecureCorp社は、［
自前の生成元／ 生成元 `https://example.com^l 
］用を除くどの`子孫~navigable群$の中でも
— ~SecureCorp社の~pageに自前の `iframe$e を埋込める攻撃者が居たとしても —
~Geolocation~APIの利用を完全に不能化したいと求めているとする。
次のような［
制約された許可~施策を~Geolocation用に定義する，~HTTP応答~header
］を送達すれば、
それを行える：
◎
SecureCorp Inc. wants to completely disable use of the Geolocation API within all descendant navigables except for its own origin and those whose origin is "https://example.com", even in the presence of an attacker who can embed their own iframes on SecureCorp’s pages. It can do this by delivering the following HTTP response header to define a restricted permissions policy for Geolocation:
</p>

<pre class="lang-http">
`Permissions-Policy$h: geolocation=(self "https://example.com")
</pre>

<p>
`許容list$は、
【概念的には】【！1 個~以上の】`生成元$たちが成す~listである
— 各~生成元には、
次のいずれかを与え得る
⇒＃
任意選択で~keyword `self$P を伴う，~appの生成元 ／
任意の第三者-主体~生成元
◎
The allowlist is a list of one or more origins, which can include the application’s origin, optionally with the keyword "self", and any third-party origin.
</p>

<p>
この施策の効果がある下では、［
通例通り `iframe^e の `allow$aF 属性を利用して，一定の~frameに対し地理所在を是認できる
］が、
その~APIを利用する能が実際に是認されるのは，［
`http://example.com^l ／ ~SecureCorp自身
］からの内容を~hostしている~frameに限られることになる。
◎
With this policy in effect, it can then use the "allow" iframe attribute as usual to grant geolocation to certain frames, but only those frames hosting content from http://example.com or SecureCorp itself will actually be granted the ability to use that API.
</p>
</div>

<div class="example">
<p>
~SecureCorp社は，自身の~domainたちを再構成したため、
今や，~Geolocation~APIの利用を［
自身の生成元（ `https://example.com^l ）に加え，
3 個の下位domain
（ `https://geo.example.com^l,
`https://geo2.example.com^l,
`https://new.geo2.example.com^l ）
］へ委任する必要があり、
それは，他の閲覧~文脈の中では~Geolocation~APIの利用を不能化したまま成遂げる必要があるとする。
これは、
次の~HTTP応答~headerを送達して行える：
◎
SecureCorp Inc. restructured its domains and now needs to delegate use of the Geolocation API to its origin ("https://example.com") as well as three subdomains ("https://geo.example.com", "https://geo2.example.com", and "https://new.geo2.example.com"). This needs to be accomplished while still disabling the use of the Geolocation API within all other browsing contexts. It can do this by delivering the following HTTP response header:
</p>

<pre class="lang-http">
`Permissions-Policy$h: geolocation=(self "https://example.com" "https://geo.example.com" "https://geo2.example.com" "https://new.geo2.example.com")
</pre>

<p>
これは働くが、
~SecureCorp社が `https://example.com^l の どの下位domainに委任しても安全になる感触を得たなら，~HTTP応答~headerを次のように代えることもできる：
◎
This works, but if SecureCorp Inc. feels safe delegating to any subdomains on "https://example.com" the HTTP response header could instead be:
</p>

<pre class="lang-http">
`Permissions-Policy$h: geolocation=(self "https://example.com" "https://*.example.com")
</pre>

<p>
上の~headerは、［
`https://geo.example.com^l,
`https://geo2.example.com^l,
`https://new.geo2.example.com^l
］のみならず，
`https://example.com^l の他の下位domainにも~Geolocation~APIの利用を許可する。
`許容list$を成す~entryとして， `https://example.com^l も追加しなければならないことに注意
— `https://*.example.com^l は、
それを受持たないので。
◎
Not only would the above header permit "https://geo.example.com", "https://geo2.example.com", and "https://new.geo2.example.com" to use the Geolocation API, but any other subdomains of "https://example.com" could use it too. Note that "https://example.com" is not covered by the allowlist entry "https://*.example.com" and must also be added.
</p>
</div>

<div class="example">
<p>
~SecureCorp社は，自身の~serviceたちを再構成したため、
今や，
~Geolocation~APIの利用を［
自身の生成元（ `https://example.com^l ）に加え，
3 個の既定でない~port
（ `https://example.com:444^l,
`https://example.com:445^l,
`https://example.com:446^l ）
］へ委任する必要があり、
それは，他の閲覧~文脈の中では~Geolocation~APIの利用を不能化したまま成遂げる必要があるとする。
これは、
次の~HTTP応答~headerを送達して行える：
◎
SecureCorp Inc. restructured its services and now needs to needs to delegate use of the Geolocation API to its origin ("https://example.com") as well as three non-default ports ("https://example.com:444", "https://example.com:445", and "https://example.com:446"). This needs to be accomplished while still disabling the use of the Geolocation API within all other browsing contexts. It can do this by delivering the following HTTP response header:
</p>

<pre class="lang-http">
`Permissions-Policy$h: geolocation=(self "https://example.com" "https://example.com:444" "https://example.com:445" "https://example.com:446")
</pre>

<p>
これは働くが、
~SecureCorp社が `https://example.com^l の どの~portに委任しても安全になる感触を得たなら，~HTTP応答~headerを次のように代えることもできる：
◎
This works, but if SecureCorp Inc. feels safe delegating to any ports on "https://example.com" the HTTP response header could instead be:
</p>

<pre class="lang-http">
`Permissions-Policy$h: geolocation=(self "https://example.com:*")
</pre>

<p>
上の~headerは、［
`https://example.com:444^l,
`https://example.com:444^l ,
`https://example.com:445^l
］のみならず，
`https://example.com^l の他の~portにも~Geolocation~APIの利用を許可する。
◎
Not only would the above header permit "https://example.com:444", "https://example.com:444", and "https://example.com:445" to use the Geolocation API, but any other ports on "https://example.com" could use it too.
</p>
</div>

<div class="example">
<p>
~JSPlaygroundCorp社は、［
利用者が生成した~web~appを~hostする
］よう求めるが，［
それらが`強力な特能$を利用する許可
］を~browserが［
それらを互いに隔離する下で管理する
］よう求めるとする。
これは、
各［
~web内容／~web内容の作成者
］用に~~別個な下位domainを作成して，
それらを~top-level文書として~navigateすることにより，成遂げれる
（それでも、［
~framework／利用者-内容
］は，同一-生成元な `iframe^e を利用して分離できる）。
◎
JSPlaygroundCorp Inc. wants to host user-generated web applications, but wants the browser to manage their permissions to use powerful features in isolation of each other. This can be accomplished by creating discrete subdomains for each piece of web-content or web-content creator, and navigating them as top-level documents (framework and user-content can still be separated using same-origin iframes).
</p>

<p>
そのようにすることは、
必要yある。
各~利用者は、
~top-level~domain
— 自身が~browser内でヤリトリしているものと知覚する~domain —
に対し，許可を是認するので。
◎
This is necessary since users grant permissions to the domain they perceive they are interacting with in the browser, which is the top-level domain.
</p>

<p>
この事例では、
~JSPlaygroundCorp社は，利用者が生成した~web~appに対し［
自前の~domainからの `allow$aF 属性を利用して `iframe^e 化する
］ことを避けるべきである
— そうすると、
それらすべてに対し 自身の~domain許可を是認することになるので。
◎
JSPlaygroundCorp should avoid iframing user-generated web applications using the allow attribute from its own domain in this case, as this would grant its domain permissions to all of them.
</p>
</div>

<div class="example">
<p>
~PlatformCorp社は、
いくつかの［
何かを築くために埋込-可能な第三者-主体~component
］や［
自身の~top-level~domainの下で遊ぶ~game
］からなる市場を提供していて，
`getUserMedia()＠https://w3c.github.io/mediacapture-main/#dom-mediadevices-getusermedia$c ~APIの様な`強力な特能$の利用を自身の責任の下で委任するよう求めるとする。
~PlatformCorp社は、［
それら~component~appのうち，どれが特能を必要とするか
］を追跡する責務を受容することに加え，［
~~特注な “~install” ~UXを利用して，末端-利用者を~~管理下におく
］とする。
◎
PlatformCorp Inc. wants to offer a marketplace of embeddable third-party components to build from or games to play under its top-level domain. It wants to delegate the use of powerful features like the getUserMedia() API responsibly. It accepts responsibility for tracking which of its component applications need a feature, using bespoke "install" UX to keep end-users in charge.
</p>

<p>
すべての非同一-生成元な~frame内では、
~cameraと~microphoneは既定では不能化される。
各~第三者-主体~componentは、
下位domainを有していて，
非同一-生成元な `iframe^e 内に埋込めるとする。
~PlatformCorp社は、
`iframe$e 要素の `allow$aF 属性を利用することで，各~下位domainに対し［
~cameraや~microphoneへの~accessを委任するか否か
］を制御できる。
◎
Camera and microphone are disabled by default in all cross-origin frames. Each third-party component has a subdomain, and can be embedded in a cross-origin iframe. PlatformCorp can use the allow attribute on the iframe element to control whether to delegate camera or microphone access or not to each subdomain.
</p>

<p>
ある `iframe^e において，~component［
"app1" は~camera,
"app2" は~microphone,
"app3" はこの両者
］への~accessを有するべきであるとするなら、
次の様になろう：
◎
An iframe where the component "app1" should have camera access, "app2" should have microphone access, and "app3" should have both might look like this:
</p>

<pre class="lang-html">
&lt;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"&gt;
&lt;/iframe&gt;
</pre>

<p>
`iframe$e 用の属性は、
ある種の~frameにおいては特能を選択的に可能化でき，
他においては
— それを包含する文書と`同一-生成元$に属する場合でも —
可能化できない。
実施においては、
`sandbox$aF 用の~tokenたちが成す~listは，もっと長いかもしれない。
◎
Iframe attributes can selectively enable features in certain frames, and not in others, even if those contain documents from the same origin. The list of sandbox tokens might be longer in practice.
</p>

<p>
~browserは，一般に［
~top-level~domainに対し，許可を是認する
］よう利用者に依頼するので、
利用者が~PlatformCorp社をすでに信用-済みな場合，［
~cameraや~microphoneへの~accessを要請する~component
］用には追加的な許可は~promptされないかもしれない。
◎
Since browsers generally ask users to grant permissions to the top-level domain, there might not be any additional permission prompt for the components to request camera or microphone access if the user already trusts PlatformCorp.
</p>
</div>

	</section>
	<section id="other-and-related-mechanisms">
<h2 title="Other and related mechanisms">3. 他の／関係する仕組み</h2>

<p>
`HTML5$r が `iframe$e 要素~用に定義する `sandbox$aF 属性は、［
内容の能に制約を課すことにより，信用できない内容が含まれることによる~riskを抑制する
］ことを，開発者に許容する
— 例：［
~formを提出する／~scriptや~pluginを走らす／その他
］を防止するなど。
`CSP2$r が定義する `sandbox$dir 指令は、
同じ一連の制約を依頼するために，この能力を どの資源にも
— ~frame化されるかどうかを問わず —
拡張する
— 例： ~HTTP応答~headerを介することにより（ `Content-Security-Policy: sandbox^l ）。
これらの仕組みは、
開発者に次を可能化する：
◎
[HTML5] defines a sandbox attribute for iframe elements that allows developers to reduce the risk of including potentially untrusted content by imposing restrictions on content’s abilities - e.g. prevent it from submitting forms, running scripts and plugins, and more. The sandbox directive defined by [CSP2] extends this capability to any resource, framed or not, to ask for the same set of restrictions - e.g. via an HTTP response header (Content-Security-Policy: sandbox). These mechanisms enable the developer to:
</p>

<ul>
	<li>
どの資源に対しても，~CSPを介して~sandbox施策を［
設定する／~custom化する
］。
◎
Set and customize a sandbox policy on any resource via CSP.
</li>
	<li>
自身の~appの中の各 `iframe^e 要素に対し，個別に~sandbox施策を［
設定する／ ~custom化する
］。
◎
Set and customize individual sandbox policies on each iframe element within their application.
</li>
</ul>

<p>
しかしながら，上の仕組みには、
いくつか制限がある：
◎
However, there are several limitations to the above mechanism:＼
</p>
<ul>
	<li>
開発者は、
すべての文脈にわたって施策を自動的には適用できないため、
一部の事例では，一貫して施行するのが難しいか不可能である
（例：第三者-主体からの内容が，開発者が制御しない~frameを注入することに因るものなど）
◎
the developer cannot automatically apply a policy across all contexts, which makes it hard or impossible to enforce consistently in some cases (e.g. due to third-party content injecting frames, which the developer does not control);＼
</li>
	<li>
既定では不能化され得るような特能を，選択的に可能化する仕組みが無い
◎
there is no mechanism to selectively enable features that may be off by default;＼
</li>
	<li>
~sandboxの仕組みは、
すべての~sandbox特能を自動的に不能化して，そのそれぞれを任意選択で元に戻すことを，開発者に要求するので、
有意な互換性~riskなしに一連の~sandbox特能を拡張することは不可能である。
◎
the sandbox mechanism automatically disables all sandbox features, and requires the developer to opt back in to each of them, so it is impossible to extend the set of sandbox features without significant compatibility risk.
</li>
</ul>

<p>
許可~施策は、
~sandboxの仕組みと組合せて利用することが意図されており
（すなわち、
すでに~sandboxが受持っている特能~制御とは重複しない），
上の制限に取組む拡張-可能な仕組みを供する。
◎
Permissions Policy is intended to be used in combination with the sandbox mechanism (i.e. it does not duplicate feature controls already covered by sandbox), and provides an extensible mechanism that addresses the above limitations.
</p>

	</section>
	<section id="framework">
<h2 title="Framework">4. ~framework</h2>

		<section id="features">
<h3 title="Policy-controlled Features">4.1. 施策により制御される特能</h3>

<p>
`施策により制御される特能@
は、
`許可~施策$を~~参照することにより，文書において［
可能化-／不能化-
］できる［
~APIや挙動
］である。
◎
A policy-controlled feature is an API or behaviour which can be enabled or disabled in a document by referring to it in a permissions policy.
</p>

<p class="trans-note">【
参考：
`~browserにて実装された施策により制御される特能の一覧＠https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md$
】</p>

<p class="note">注記：
簡潔にするため，この文書においては、
施策により制御される特能は “特能” と略称されることが多い。
他が指示されない限り，用語 “特能” は`施策により制御される特能$を指す。
そのような特能を定義する他の仕様は、
多義性を避けるため，長い方の用語を利用するべきである。
◎
For brevity, policy-controlled features will often be referred to in this document simply as "Features". Unless otherwise indicated, the term "feature" refers to policy-controlled features. Other specifications, defining such features, should use the longer term to avoid any ambiguity.
</p>

<p class="issue">
この仕様は、
現時点では，文書~内に定義される特能しか対処していない。
これについて，~Workerや~Worklet内の［
特能／許可~施策
］の可能性も含みにする言い回しを見つけるべきである。
◎
This spec currently only deals with features defined in Documents. We should figure out how to word this to include the possibility of features and permissions policies in Workers and Worklets as well.
</p>

<p>
`施策により制御される特能$は、
`~token@
により識別される
— それは、
文字列であり，`施策~指令$内で利用される。
◎
Policy-controlled features are identified by tokens, which are character strings used in policy directives.
</p>

<p>
各`特能$には、
`既定の許容list$がある
— それは、
次の 2 つを定義する：
◎
Each policy-controlled feature has a default allowlist, which defines＼
</p>
<ul>
	<li>
当の特能は、
`~top-level辿可能$に`属する文書$内で可用になるかどうか
◎
whether that feature is available in documents in top-level traversables,＼
</li>
	<li>
当の特能への~accessは、
`子~navigable$へ どう継承されるか
◎
and how access to that feature is inherited in child navigables.
</li>
</ul>

<p>
`特能$のうち，~UAが施策を通して制御することを許容するものは、
`~support済み特能@
と呼ばれる。
~UAには、
あらゆる`特能$を~supportすることは要求されない。
◎
A user agent has a set of supported features, which is the set of features which it allows to be controlled through policies. User agents are not required to support every feature.
</p>

<p class="note">注記：
`施策により制御される特能$自体は、
この~frameworkの一部を成すものではない。
現時点で定義された規範的でない特能たちが成す~listは、
この仕様とは別に，
`姉妹~文書＠https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md$
にて保守されている。
◎
The policy-controlled features themselves are not themselves part of this framework. A non-normative list of currently-defined features is maintained as a companion document alongside this specification.
</p>

		</section>
		<section id="policies">
<h3 title="Policies">4.2. 施策</h3>

<p>
`宣言-済み施策@
は、
次に挙げる`~item$sctからなる`構造体$である：
◎
A declared policy is a struct with the following items:
</p>
<ul>
	<li>
`宣言~群@dP
⇒
`有順序~map$
— 各`特能$を`許容list$に対応付ける。
◎
declarations
• an ordered map from features to allowlists
</li>
	<li>
`報告用~環境設定@dP
⇒
`有順序~map$
— 各`特能$を`文字列$に対応付ける。
◎
reporting configuration
• an ordered map from features to strings
</li>
</ul>

<div class="algo">
`新たな宣言-済み施策@
は、
次を遂行する
⇒
~RET 新たな`宣言-済み施策$
— その
⇒＃
`宣言~群$dP ~SET 新たな`有順序~map$,
`報告用~環境設定$dP ~SET 新たな`有順序~map$
</div>

<p>
`許可~施策@
は、
次に挙げる`~item$sctからなる`構造体$である：
◎
A permissions policy is a struct with the following items:
</p>
<ul>
	<li>
`継承した施策@pP
⇒
`有順序~map$
— 各`特能$を［
ある施策 ~IN { `可能化される^i, `不能化される^i }【！"Enabled" or "Disabled"】
］に対応付ける。
◎
inherited policy
• an ordered map from features to "Enabled" or "Disabled"
</li>
	<li>
`宣言-済み施策@pP
⇒
ある`宣言-済み施策$
◎
declared policy
• a declared policy
</li>
</ul>

<p>
`空な許可~施策@
は、
~AND↓ を満たす`許可~施策$である：
◎
An empty permissions policy is a permissions policy that＼
</p>
<ul>
	<li>
どの`~support済み特能$ %特能 に対しても
⇒
`継承した施策$pP[ %特能 ] ~EQ `可能化される^i
◎
has an inherited policy which contains "Enabled" for every supported feature,＼
</li>
	<li>
`宣言-済み施策$は次を満たす
⇒
［
その`宣言~群$dPは空である
］~AND［
その`報告用~環境設定$dPは空である
］
◎
a declared policy whose declarations and reporting configuration are both empty ordered maps.
</li>
</ul>

		</section>
		<section id="inherited-policies">
<h3 title="Inherited policies">4.3. 継承した施策</h3>

<p>
`特能~用に継承される施策@
は、
所与の %特能 に対し，`継承した施策$pP[ %特能 ] で与えられる。
`許可~施策$が初期化された後には、
それが`継承した施策$pPは，各`~support済み特能$用に何らかの値を包含することになる。
◎
The inherited policy for a feature feature is the value in the inherited policy whose key is feature. After a permissions policy has been initialized, its inherited policy will contain a value for each supported feature.
</p>

<div class="note" role="note">
<p>注記：
各`文書$は、［
作成, ~navi
］どちらに際しても，施策たちが成す集合を継承する
— ［
`~top-level辿可能$に`属する文書$は 各`特能$用に定義される既定~のものから ／
他の`文書$は その親~frameから
］。
この継承した施策は、
次を決定する：
◎
Upon both creation and navigation, Each Document inherits a set of policies from its parent frame, or in the case of the Document in a top-level traversable, from the defined defaults for each policy-controlled feature. This inherited policy determines＼
</p>
<ul>
	<li>
各~特能の初期~状態（ `可能化される^i ／ `不能化される^i ）
◎
the initial state ("Enabled" or "Disabled") of each feature,＼
</li>
	<li>
`文書$内の`宣言-済み施策$pPにより制御できるかどうか
◎
and whether it can be controlled by a declared policy in the Document.
</li>
</ul>

<p>
`~top-level辿可能$に`属する文書$に継承される施策は、
各~特能~用に定義される既定の施策に基づく。
◎
In a Document in a top-level traversable, the inherited policy is based on defined defaults for each feature.
</p>

<p>
`子~navigable$に`属する文書$に継承される施策は、［
親~文書の`許可~施策$doc,
当の`子~navigable$の`容器~施策$
］に基づく。
◎
In a Document in a child navigable, the inherited policy is based on the parent document’s permissions policy, as well as the child navigable’s container policy.
</p>
</div>

		</section>
		<section id="header-policies">
<h3 title="Header policies">4.4. ~header施策</h3>

<p>
`~header施策@
は、
文書に伴う~HTTP~headerを介して送達された`施策~指令$たちが成す~listである。
これは、
文書の`許可~施策$docの`宣言-済み施策$pPを形成する。
◎
A header policy is a list of policy directives delivered via an HTTP header with a document. This forms the document’s permissions policy’s declared policy.
</p>

		</section>
		<section id="container-policies">
<h3 title="Container policies">4.5. 容器~施策</h3>

<p>
各 `子~navigable$は、
`~header施策$に加えて，
`容器~施策@
を有する。
それは、
`施策~指令$であり，空にもなり得る。
`容器~施策$は、
`~navigable容器$の属性により設定できる。
◎
In addition to the header policy, each child navigable has a container policy, which is a policy directive, which may be empty. The container policy can be set by attributes on the navigable container.
</p>

<p>
`子~navigable$用の`容器~施策$は、
その~navigableの中に読込まれる文書に`継承される施策$に波及する
（`生成元に属する容器~内の特能~用に継承される施策を定義する$を見よ）。
◎
The container policy for a child navigable influences the inherited policy of any Document loaded into that navigable. (See § 9.7 Define an inherited policy for feature in container at origin).
</p>

<p class="note">注記：
現時点では，`容器~施策$は直には設定できないが、
`iframe$e 要素の［
`allowfullscreen$aF, `allow$aF
］属性により，間接的に設定される。
この仕様の将来の改訂は、
全部的な`容器~施策$を明示的に宣言する仕組みを導入し得る。
◎
Currently, the container policy cannot be set directly, but is indirectly set by the iframe allowfullscreen, and allow attributes. Future revisions to this spec may introduce a mechanism to explicitly declare the full container policy.
</p>

		</section>
		<section id="policy-directives">
<h3 title="Policy directives">4.6. 施策~指令</h3>

<p>
`施策~指令@
は、
各 `特能$を ある`許容list$に対応付ける`有順序~map$である。
◎
A policy directive is an ordered map, mapping policy-controlled features to corresponding allowlists of origins.
</p>

<p>
`施策~指令$は
⇒＃
~HTTP~header内では`辞書$sfの直列化として表現される／
~HTML属性~内では`~ASCII直列化＠#ascii-serialization$として表現される
◎
A policy directive is represented in HTTP headers as the serialization of an sf-dictionary structure, and in HTML attributes as its ASCII serialization.
</p>

		</section>
		<section id="allowlists">
<h3 title="Allowlists">4.7. 許容list</h3>

<p>
許可~施策
`許容list@
は、
概念的には，`生成元$たちが成す集合である。
`許容list$は、
次のいずれかをとり得る：
◎
A permissions policy allowlist is conceptually a set of origins. An allowlist may be either:
</p>

<ul>
	<li>
<p>
あらゆる生成元を表現する，特別な値
"`*@P"
（ `全~生成元$i ）
</p>

<p class="trans-note">【
`全~生成元$i は、
この値の（意味論上の側面を表す）別名として利用される。
この別名は、
表記的／意味的に明快にするために，この訳に導入している。
】</p>
◎
The special value *, which represents every origin, or
</li>
	<li>
<p>
次に挙げる~itemからなる`構造体$：
◎
A struct containing:
</p>
		<ul>
			<li>
`式~群@AL
⇒
`permissions-source-expression$P に合致する文字列たちが成す`有順序~集合$
◎
expressions, which is an ordered set of permissions-source-expression
</li>
			<li>
<p>
`自己-生成元@AL
⇒
`生成元$ ／ ~NULL
</p>

<p class="trans-note">【
これは、
~HTTP~header内では， `self$P で表現される。
】</p>
◎
self-origin, which is an origin or null
</li>
			<li>
<p>
`~src生成元@AL
⇒
`生成元$ ／ ~NULL
</p>

<p class="trans-note">【
これは、
`src^a （ `iframe$e の `src$aF 属性など）から導出される。
】</p>
◎
src-origin, which is an origin or null 
</li>
		</ul>

<p>
`新たな許容list@
は、
この構造体を次のように初期化して返す
⇒＃
`自己-生成元$AL ~SET ~NULL,
`~src生成元$AL ~SET ~NULL,
`式~群$AL ~SET 新たな`有順序~集合$
</p>

<p class="trans-note">【
この定義は、
この訳による補完。
】</p>

	</li>
</ul>

<p class="note">注記：
［
~headerや属性
］内の文字列による許容listの~text表現には、
~keyword［
`'self'^l, `'src'^l, `'none'^l
］も現れ得る。
【~header内では、 `self^l に限り，一重引用符 `'^l で括られずに現れ得る。】
これらの各~keywordは，常に構文解析の間に その文脈において解釈され、
それぞれが指す生成元のみが，許容list~内に格納される。
~keyword自身は、
許容listの一部を成すことはない。
◎
The keywords 'self', 'src', and 'none' can appear in the text representation of allowlists in headers and attribute strings. These keywords are always interpreted in context during parsing, and only the origins which they refer to are stored in the allowlist. The keywords themselves are not part of the allowlist.
</p>

<div class="algo">
<p>
`許容listは生成元に合致するか？@
は、
所与の
( `許容list$ %許容list, 生成元 %生成元 )
に対し，次の手続きを走らす：
◎
To determine whether an allowlist matches an origin origin, run these steps:
</p>
<ol>
	<li>
<p>
~IF［
%許容list ~EQ `全~生成元$i
］
⇒
~RET ~T
◎
If the allowlist is the special value *, then return true.
</p>

<p class="note">注記：
~CSPによる~wildcard照合の変種は利用しない
— それには，~HTTPS~schemeが要求されるので。
◎
Note: We are not using the CSP variant of wildcard matching as it requires the HTTPS scheme.
</p>
	</li>
	<li>
~IF［
%許容list の`自己-生成元$AL ~NEQ ~NULL
］~AND［
( %許容list の`自己-生成元$AL, %生成元 )
は`同じ生成元~domain$である
］
⇒
~RET ~T
◎
If the allowlist’s self-origin is not null and it is same origin-domain with origin, then return true.
</li>
	<li>
~IF［
%許容list の`~src生成元$AL ~NEQ ~NULL
］~AND［
( %許容list の`~src生成元$AL, %生成元 )
は`同じ生成元~domain$である
］
⇒
~RET ~T
◎
If the allowlist’s src-origin is not null and it is same origin-domain with origin, then return true.
</li>
	<li>
~IF［
%生成元 は`不透明な生成元$である
］
⇒
~RET ~F
◎
If origin is an opaque origin, return false.
</li>
	<li>
%~URL ~LET `~URL構文解析する$( `生成元を直列化する$( %生成元 ) )
◎
Let url be the result of calling the url parser on the serialization of origin.
</li>
	<li>
%許容list の`式~群$ALを成す
~EACH( %式 )
に対し
⇒
~IF［
`~URLは ( 生成元, ~redirect回数 ) について式に合致するか？$( %~URL, %式, %生成元, 0 ) の結果 ~EQ ~T
］
⇒
~RET ~T
◎
For each permissions-source-expression item in the allowlist’s expressions:
• If the result of running Does url match expression in origin with redirect count? on url, item, origin, and 0 is true then return true.
</li>
	<li>
~RET ~F
◎
Return false.
</li>
</ol>
</div>

		</section>
		<section id="default-allowlists">
<h3 title="Default Allowlists">4.8. 既定の許容list</h3>

<p>
各 `特能$には、
`既定の許容list@
がある。
`既定の許容list$は、
次を決定する：
◎
Every policy-controlled feature has a default allowlist. The default allowlist determines＼
</p>
<ul>
	<li>
`~top-level辿可能$内に宣言された施策は無い下で、
当の特能は，`文書$において許容されるかどうか
◎
whether the feature is allowed in a Document with no declared policy in a top-level traversable,＼
</li>
	<li>
当の特能への~accessは、
自動的に`子~navigable$に`属する文書$に委任されるかどうか
◎
and also whether access to the feature is automatically delegated to documents in child navigables.
</li>
</ul>

<p>
所与の`特能$用の`既定の許容list$は、
次に挙げる いずれかの値をとる：
◎
The default allowlist for a feature is one of these values:
</p>

<dl>
	<dt>
`全~生成元@i
（ `*$P ）
◎
*
</dt>
	<dd>
当の特能は、［
`~top-level辿可能$／【当の`~navigable$の】すべての`子~navigable$
］に`属する文書$においては，既定では許容される。
◎
The feature is allowed in Documents in top-level traversables by default, as well as those in all child navigables.＼
</dd>
	<dd>
`子~navigable$においては、
その`~navigable容器$に対し，この既定を上書きする`容器~施策$を明示的に給する
（あるいは、
どの`~navigable$においても，
当の`文書$を相応しい `Permissions-Policy$h ~headerを伴わせて送達する）
ことにより許容しなくできる。
◎
It can be disallowed in child navigables by explicitly supplying a container policy on the navigable container that overrides this default (or in any navigable, by delivering the Document with a suitable Permissions-Policy header).
</dd>

	<dt>`'self'@l</dt>
	<dd>
当の特能は、
`~top-level辿可能$にて`作動中な文書$navにおいては，
既定では許容される。
◎
The feature is allowed in documents in top-level traversables by default,＼
</dd>
	<dd>
加えて，`子~navigable$にて`作動中な文書$navにおいては、［
その`親$navにて`作動中な文書$nav %親~文書 と`同一-生成元$に属する
］かつ［
当の特能は %親~文書 にて許容される
］ならば，既定では許容される
— 同一-生成元に属さない場合、
既定では許容されない。
◎
as well as those in child navigables whose document is same origin with its parent’s document, when allowed in that Document.＼
It is disallowed by default in child navigables whose document is cross-origin with its parent’s document.
</dd>
</dl>

		</section>
	</section>
	<section id="serialization">
<h2 title="Permissions Policy Serialization">5. 許可~施策の直列化</h2>

		<section id="ascii-serialization">
<h3 title="HTML attribute serialization">5.1. ~HTML属性の直列化</h3>

<p>
`施策~指令$は、
~HTML属性~内では，次の~ABNFによる~ASCII直列化として表現される：
◎
Policy Directives in HTML attributes are represented as their ASCII serialization, with the following ABNF:
</p>

<pre class="bnf">
`serialized-permissions-policy@P
	= `serialized-policy-directive$P *(";" `serialized-policy-directive$P)
`serialized-policy-directive@P
	= `feature-identifier$P RWS `allow-list$P
`feature-identifier@P
	= 1*( ALPHA / DIGIT / "-")
`allow-list@P
	= `allow-list-value$P *(RWS `allow-list-value$P)
`allow-list-value@P
	= `permissions-source-expression$P
	/ "*"
	/ "'self'"
	/ "'src'"
	/ "'none'"
`permissions-source-expression@P
	= `scheme-source$P
	/ `host-source$P
</pre>

<p class="note">注記：
文字列 `'self'^l は、
許容list内の生成元として利用され得る。
この仕方で利用されたときは、
当の許可~施策を包含する文書の生成元を指すことになる。
◎
The string "'self'" may be used as an origin in an allowlist. When it is used in this way, it will refer to the origin of the Document which contains the permissions policy.
</p>

		</section>
		<section id="structured-header-serialization">
<h3 title="Structured header serialization">5.2. 有構造~headerの直列化</h3>

<p>
~HTTP~header内の`施策~指令$は、
`有構造~field$として表現される。
`RFC8941$r
◎
Policy Directives in HTTP headers are represented as Structured Fields. [RFC8941]
</p>

<p>
この表現においては、
`施策~指令$は，`辞書$sfにより表現される。
◎
In this representation, a policy directive is represented by a Dictionary.
</p>

<p>
この`辞書$sfを成す各~memberは、
ある`特能$をある`許容list$に結付ける。
~memberの名前は、
~tokenでなければナラナイ
【と記されているが、これは`~token$sfではなく，`~key$sfでなければならないはず】
。
~tokenが`~support済み特能$の名前でない場合、
当の辞書~memberは，処理~手続きにより無視されることになる。
◎
Each Dictionary Member associates a feature with an allowlist. The Member Names must be Tokens. If a token does not name one of the user agent’s supported features, then the Dictionary Member will be ignored by the processing steps.
</p>

<p>
各~memberの値は、
`許容list$を表現する
— 次に挙げるいずれかでなければナラナイ：
◎
The Member Values represent allowlists, and must be one of:
</p>
<ul>
	<li>
次に挙げるいずれかの`~item$sf
⇒＃
~ASCII `permissions-source-expression$P を包含する`文字列$sf／
`~token$sf `*^P （ `全~生成元$i ）／
`~token$sf `self@P
◎
a String containing the ASCII permissions-source-expression
◎
the Token *
◎
the Token self
</li>
	<li>
`内縁~list$sf
— この~listを成す`~item$sfのうち，前項に挙げたもの以外は、
処理~手続きにより無視され，無かったかのように処理されることになる。
◎
an Inner List containing zero or more of the above items.
◎
↓</li>
</ul>

<p>
各~memberの値に伴われる`~parameter群$sfは、
~key `report-to^l を伴う`~parameter$sfを有してもヨイ
— その値は`文字列$sfでなければナラナイ。
他の~parameterは無視されることになる。
◎
Member Values may have a Parameter named "report-to", whose value must be a String. Any other parameters will be ignored.
◎
↑ Any other items inside of an Inner List will be ignored by the processing steps, and＼
</p>

<p>
この`辞書$sfの~memberが他の形による値をとる場合、
処理~手続きにより，当の~member全体が無視されることになる。
◎
the Member Value will be processed as if they were not present. Member Values of any other form will cause the entire Dictionary Member to be ignored by the processing steps.
</p>

		</section>
	</section>
	<section id="delivery">
<h2 title="Delivery">6. 送達</h2>

		<section id="permissions-policy-http-header-field">
<h3 title="Permissions-Policy HTTP Header Field">6.1. `Permissions-Policy^h ~HTTP~header</h3>

<p>
~serverは、
~HTTP応答【！~FETCH#concept-response-response】~内に
`Permissions-Policy@h
~headerを利用することにより，［
~clientにより施行されるべきである`許可~施策$
］を~clientへ通信できる。
◎
The `Permissions-Policy` HTTP header field can be used in the response (server to client) to communicate the permissions policy that should be enforced by the client.
</p>

<p>
`Permissions-Policy$h は、
`有構造~header$である。
その値は、
`辞書$sfでなければナラナイ。
その~ABNFは：
◎
`Permissions-Policy` is a structured header. Its value must be a dictionary. It’s ABNF is:
</p>

<pre class="bnf">
PermissionsPolicy
	= `sf-dictionary$P
</pre>

<p>
この辞書の意味論は、
`§ 有構造~headerの直列化＠#structured-header-serialization$
にて定義される。
◎
The semantics of the dictionary are defined in § 5.2 Structured header serialization.
</p>

<p>
この辞書の処理は、
`辞書と生成元から施策を構築する$
手続きにて定義される。
◎
The processing steps are defined in § 9.2 Construct policy from dictionary and origin.
</p>

		</section>
		<section id="iframe-allow-attribute">
<h3 title="The allow attribute of the iframe element">6.2. `iframe^e 要素の `allow^a 属性</h3>

<p>
`iframe$e 要素の `allow$aF 属性は、
`直列形の許可~施策＠#serialized-policy-directive$を包含する。
◎
iframe elements have an allow attribute, which contains an ASCII-serialized policy directive.
</p>

<p>
`allow^aF 属性~内に挙げられた各 名前の特能~用の`許容list$は：
◎
↓</p>

<ul>
	<li>
空になることもある。
その事例では、
当の許容list用の既定の値は `'src'^l とする
— この値は、
`iframe$e 要素の `src$aF 属性に与えられた~URLの`生成元$urlを表現する。
◎
The allowlist for the features named in the attribute may be empty; in that case, the default value for the allowlist is 'src', which represents the origin of the URL in the iframe’s src attribute.
</li>
	<li>
空でないときは、
当の `allow$aF 属性を有する `iframe$e 要素の`内容~navigable$が構築されるときに，
その`容器~施策$に［
認識される各`特能$用の`許容list$
］が追加されることになる。
◎
When not empty, the allow attribute will result in adding an allowlist for each recognized feature to the iframe element’s content navigable’s container policy, when it is constructed.
</li>
</ul>

		</section>
		<section id="legacy-attributes">
<h3 title="Additional attributes to support legacy features">6.3. 旧来の特能を~supportする追加的な属性</h3>

<p>
この仕様により制御される一部の`特能$に対しては、
それ用の既存の属性が `iframe$e 要素に定義されている。
この仕様は、
これらの属性を `iframe^e の`内容~navigable$の`容器~施策$に波及するよう定義し直す。
◎
Some features controlled by Permissions Policy have existing iframe attributes defined. This specification redefines these attributes to influence the iframe’s content navigable’s container policy.
</p>

			<section id="iframe-allowfullscreen-attribute">
<h4 title="allowfullscreen">6.3.1. `allowfullscreen^a</h4>

<p>
`iframe$e 要素 %要素 の `allowfullscreen$aF 属性は、
`requestFullscreen()$m への~accessを制御する：
◎
The allowfullscreen iframe attribute controls access to requestFullscreen().
</p>

<ul>
	<li>
%要素 が `allow$aF 属性を有していて，その値は ~token `fullscreen^l を包含する場合、
`allowfullscreen$aF 属性による効果は無いモノトスル。
◎
If the iframe element has an allow attribute whose value contains the token "fullscreen", then the allowfullscreen attribute must have no effect.
</li>
	<li>
他の場合， %要素 が `allowfullscreen$aF 属性を有するならば、
%要素 の`内容~navigable$が構築されるときに，
その`容器~施策$に `fullscreen^l 特能~用の`許容list$として `全~生成元$i が追加されることになる。
◎
Otherwise, the presence of an allowfullscreen attribute on an iframe will result in adding an allowlist of * for the "fullscreen" feature to the iframe element’s content navigable’s container policy, when it is constructed.
</li>
</ul>

<p class="note">注記：
これは、
`&lt;iframe allow="fullscreen"&gt;^c
の挙動とは異なるが、
既存の `allowfullscreen^a の利用と互換性を得るためにある。
`iframe^e 要素が［
`allow="fullscreen"^c,
`allowfullscreen^a
］どちらも有する場合、
より制約的な方の許容listを成す `allow="fullscreen"^c が利用されることになる。
◎
This is different from the behaviour of &lt;iframe allow="fullscreen"&gt;, and is for compatibility with existing uses of allowfullscreen. If allow="fullscreen" and allowfullscreen are both present on an iframe element, then the more restrictive allowlist of allow="fullscreen" will be used.
</p>

			</section>
		</section>
	</section>
	<section id="introspection">
<h2 title="Policy Introspection from Scripts">7. ~scriptからの施策の自己検分</h2>

		<section id="introspection-overview" class="non-normative">
<h3 title="Overview">7.1. 概観</h3>

<p>
文書~内で効果を発揮している現在の施策は、
~scriptから観測できる。
これは、［
ある特能が可能化されているかどうか判らない限り，何かを決定するのが
— 一例として, どの~UIを表示するかなど —
アリでない事例
］で，裁定を下すときに利用できる。
（特能には、
観測-可能な失敗~modeが無いものや，
特能~検出に際し求まれない副作用を伴うものもあるかもしれない。）
◎
The current policy which is in effect in a document can be observed by scripts. This can be used to make decisions, for instance, about what user interface to display, in cases where it is not possible to determine otherwise whether a feature is enabled or not. (Some features may not have any observable failure mode, or may have unwanted side effects to feature detection.)
</p>

<p>
`文書$, `iframe$e は、
どちらも `PermissionsPolicy$I ~objを供する
— それを利用すれば、
自身に適用される許可~施策を検分できる。
◎
Documents and iframes both provide a PermissionsPolicy object which can be used to inspect the permissions policies which apply to them.
</p>

			<section id="document-policies">
<h4 title="Document policies">7.1.1. 文書~施策</h4>

<p>
現在~有効な施策を検索取得するときは、
`document.permissionsPolicy$c を利用する。
これは、
次に利用できる `PermissionsPolicy$I ~objを返す：
◎
To retreive the currently effective policy, use document.permissionsPolicy. This returns a PermissionsPolicy object, which can be used to:
</p>

<ul>
	<li>
現在の文書に対し，所与の特能~用の状態（許容されるか／否認されるか）を~queryする
◎
query the state (allowed or denied) in the current document for a given feature,
</li>
	<li>
現在の文書にて可用な特能すべて（許容されないものも含む）が成す~listを取得する
◎
get a list of all available features (allowed or not) in the current document,
</li>
	<li>
現在の文書にて許容される特能すべてが成す~listを取得する
◎
get a list of all allowed features in the current document, or
</li>
	<li>
現在の文書における，所与の特能~用の許容listを取得する。
◎
get the allowlist for a given feature in the current document.
</li>
</ul>

<div class="example">
<pre class="lang-html">
&lt;!doctype html&gt;
&lt;script&gt;
 const %policy = document.permissionsPolicy;

 /* <span class="comment">
この文書が~WebUSBを利用できるならば、
次の結果は ~T になる。
◎
This will be true if this document can use WebUSB.
</span> */
 const %can_use_usb = %policy.allowsFeature('usb');

 /* <span class="comment">
`https://example.com^s にある新たな~frameには，~WebXRの利用は許容されるならば、
次の結果は ~T になる。
◎
True if a new frame at https://example.com will be allowed to use WebXR.
</span> */
 if (%policy.allowsFeature('xr-spatial-tracking', 'https://example.com')) {
   /* <span class="comment">
`https://example.com^s にある~frameを作成する~UIを示す。
◎
Show UI to create frame at https://example.com.
</span> */
 } else {
   /* <span class="comment">
代替~UIを示す。
◎
Show an alternative UI.
</span> */
 }

 /* <span class="comment">
`payment^l （支払い）要請が許容される生成元たちが成す~listを取得する。
結果は、
すべての生成元に許容される場合は `全~生成元$i のみが成す~list（ `['*']^c ）になり，他の場合は 明示的な生成元たちが成す~listになる。
◎
Get the list of origins which are allowed to request payment. The result will be a list of explicit origins, or the single element ['*'] if all origins are allowed.
</span> */
 const %allowed_payment_origins = %policy.getAllowlistForFeature('payment');

 /* <span class="comment">
この文書~内で~supportされる特能すべてが成す~listを（許容されないものも含めて）取得する。
結果は、［
ある特能を表現する文字列
］たちが成す配列になる。
◎
Get the list of all features supported in this document (even those which are not allowed). The result will be an array of strings, each representing a feature.
</span> */
 const %all_features = policy.features();
 if (%all_features.includes('geolocation')) {
   /* <span class="comment">
第三者-主体の地図~serviceに子~frameを付加する
◎
Append a child frame to a third-party map service.
</span> */
 }
&lt;/script&gt;
</pre>
</div>

			</section>
			<section id="frame-policies">
<h4 title="Frame policies">7.1.2. ~frame施策</h4>

<p>
`iframe^e 要素~上の施策を，それを包含する文書から検分することもアリである。
この事例における施策~objは、
その~frame用の`観測-可能な施策$を表現する
— それは、
現在の文書と `iframe^e 要素の属性のみに依存し，［
~frame内で，ある特能が実際に現在~許容されているかどうか
］を露呈することはない。
~frame内の文書は、
~HTTP~headerを介して自前の施策を適用していることもあれば，初期の所在から新たな生成元へ~navigateされることもある。
そのような事例で［
`iframe$e 要素の`内容~navigable$【！nested navigable】内で有効な施策
］が露呈されれば、
非同一-生成元に属する文書の挙動について情報を漏洩することになり得る。
◎
It is also possible to inspect the policy on an iframe element, from the document which contains it. The policy object in this case represents the observable policy for the frame, which depends only on the current document and the attributes of the iframe element. It does not reveal whether a feature is actually currently allowed in the frame, as the document in the frame may have applied its own policy via an HTTP header, or may have navigated away from its initial location to a new origin. Revealing the effective policy in the iframe element’s nested navigable in that case could leak information about the behaviour of a cross-origin document.
</p>

<div class="example">
<pre class="lang-html">
&lt;!doctype html&gt;
&lt;iframe id="frame" allow="fullscreen; xr-spatial-tracking"&gt;&lt;/iframe&gt;
&lt;script&gt;
 const %iframe_element = document.getElementById("frame");
 const %iframe_policy = %iframe_element.permissionsPolicy;

 /* <span class="comment">
~frame化された文書にて~WebXRの利用は許容されるならば、
次の結果は ~T になる。
◎
True if the framed document will be allowed to use WebXR
</span> */
 if (%iframe_policy.allowsFeature('xr-spatial-tracking')) {
  /* <span class="comment">
仮想現実~controlを表示する
◎
display virtual reality controls
</span> */
 }
&lt;/script&gt;
</pre>
</div>

<p>
`iframe^e 要素~用の`観測-可能な施策$は、
~frameの中に読込まれた実際の内容には依存しない
（非同一-生成元への情報~漏洩eを避けるため）
— また、
要素が文書~tree内にあるかどうかにも依存しない。
◎
The observable policy on an iframe element is independent of any actual content loaded into the frame (to avoid cross-origin information leakage,) or even whether it is in a document tree.
</p>

<div class="example">
<pre class="lang-html">
&lt;!doctype html&gt;
&lt;!-- <span class="comment">
次の~frameの `src^a 属性に与えた文書が読込まれるときは、
その~frameには，~fullscreenの利用は許容されるべきでない。
◎
this frame should not be allowed to use fullscreen when the document in its src attribute is loaded in it
</span> --&gt;
&lt;iframe id="frame" allow="fullscreen https://example.com" src="https://example.net/" &gt;&lt;/iframe&gt;

&lt;script&gt;
 const %iframe_element = document.getElementById("frame");
 const %iframe_policy = %iframe_element.permissionsPolicy;
 /* <span class="comment">
次の結果は、
~F になる
— 施策により、
`src^a 属性~内に挙げられた~URLには，~fullscreenの利用は許容されないので。
◎
This will be false, as the URL listed in the src attribute is not allowed by policy to use fullscreen.
</span> */
 const %is_fullscreen_allowed_in_frame = iframe_policy.allowsFeature('fullscreen');

 const %new_frame = document.createElement('iframe');
 %new_frame.allow = 'sync-xhr';
 /* <span class="comment">
次の結果は、
~T になる。
すなわち、
この `iframe^e には `sync-xhr^l 【同期的 `XMLHttpRequest$I 】の利用-は許容される
— `src^a 属性に挙げられた~URLが何であれ，属性がまだ設定されてなくとも。
◎
This will be true, as the iframe is allowed to use sync-xhr at whatever URL is mentioned in its src attribute, even though that attribute is not yet set.
</span> */
 const %is_sync_xhr_allowed = %new_frame.permissionsPolicy.allowsFeature('sync-xhr');
&lt;/script&gt;
</pre>
</div>

			</section>
		</section>
		<section id="the-policy-object">
<h3 title="The permissionsPolicy object">7.2. `PermissionsPolicy^I ~obj</h3>

<pre class="idl">
[`Exposed$=Window]
interface `PermissionsPolicy@I {
  `boolean$ `allowsFeature$m(`DOMString$ %feature, optional `DOMString$ %origin);
  `sequence$&lt;`DOMString$&gt; `features$m();
  `sequence$&lt;`DOMString$&gt; `allowedFeatures$m();
  `sequence$&lt;`DOMString$&gt; `getAllowlistForFeature$m(`DOMString$ %feature);
};

partial interface `Document$I {
    [`SameObject$] readonly attribute `PermissionsPolicy$I `~permissionsPolicyD$m;
};

partial interface `HTMLIFrameElement$I {
    [`SameObject$] readonly attribute `PermissionsPolicy$I `~permissionsPolicyF$m;
};
</pre>

<p>
各 `PermissionsPolicy$I ~obj %P には、
ある`~node$が結付けられる
— それは， %P に
`結付けられた~node@
と称され、
%P の作成-時に設定される。
◎
A PermissionsPolicy object has an associated node, which is a Node. The associated node is set when the PermissionsPolicy object is created.
</p>

<p>
各 `PermissionsPolicy$I ~obj %P の
`既定の生成元@
は、
%P に`結付けられた~node$ %~node に応じて，次で与えられる`生成元$になる
⇒＃
`文書$であるならば %~node の`生成元$doc【！`生成元$】 ／
`要素$であるならば %~node 用に`宣言された生成元$
◎
A PermissionsPolicy object has a default origin, which is an origin, whose value depends on the state of the PermissionsPolicy object’s associated node:
• If the PermissionsPolicy object’s associated node is a Document, then its default origin is the Document’s origin.
• If the PermissionsPolicy object’s associated node is an Element, then its default origin is the Element’s declared origin.
</p>

<p>
各`文書$ %文書 には、
%文書 の
`施策~obj@doc
と称される，次を満たす `PermissionsPolicy$I ~obj %P がただ一つ在る
⇒
%P に`結付けられた~node$ ~EQ %文書
◎
Each Document has a policy object, which is a PermissionsPolicy instance whose associated node is that Document.
</p>

<div class="algo">
`Document$I の
`~permissionsPolicyD@m
取得子~手続きは
⇒
~RET コレの`施策~obj$doc
◎
A Document’s permissionsPolicy IDL attribute, on getting, must return the Document’s policy object.
</div>

<p>
各 `iframe$e 要素 %要素 には、
%要素 の
`施策~obj@iF
と称される，次を満たす `PermissionsPolicy$I ~obj %P がただ一つ在る
⇒
%P に`結付けられた~node$ ~EQ %要素
◎
Each iframe element has a policy object, which is a PermissionsPolicy instance whose associated node is that element.
</p>

<div class="algo">
`HTMLIFrameElement$I （すなわち `iframe$e ）の
`~permissionsPolicyF@m
取得子~手続きは
⇒
~RET コレの`施策~obj$iF
◎
An iframe’s permissionsPolicy IDL attribute, on getting, must return the iframe’s policy object.
</div>

<div class="algo">
<p>
`allowsFeature(feature, origin)@m
~method手続きは：
◎
The allowsFeature(feature, origin) method must run the following steps:
</p>
<ol>
	<li>
~IF［
%origin ~EQ ε
］
⇒
%origin ~SET コレの`既定の生成元$
◎
If origin is omitted, set origin to this PermissionsPolicy object’s default origin.
</li>
	<li>
%施策 ~LET コレに`結付けられた~node$用の`観測-可能な施策$
◎
Let policy be the observable policy for this PermissionsPolicy object’s associated node.
</li>
	<li>
~IF［
%施策 により， %特能 は %origin 用に許容される
【具体的な~algoは指定されていない】
］
⇒
~RET ~T
◎
If feature is allowed by policy for origin, return true.
</li>
	<li>
~RET ~F
◎
Otherwise, return false.
</li>
</ol>
</div>

<div class="algo">
<p>
`features()@m
~method手続きは：
◎
The features() method must run the following steps:
</p>
<ol>
	<li>
%結果 ~LET 新たな`有順序~集合$
◎
Set result to an empty ordered set.
</li>
	<li>
~EACH( `~support済み特能$ %特能 )
に対し
⇒
%特能 を %結果 に`付加する$set
◎
For each supported feature feature:
• Append feature to result.
</li>
	<li>
~RET %結果
◎
return result
</li>
</ol>
</div>

<div class="algo">
<p>
`allowedFeatures()@m
~method手続きは：
◎
The allowedFeatures() method must run the following steps:
</p>
<ol>
	<li>
%結果 ~SET 新たな`有順序~集合$
◎
Set result to an empty ordered set.
</li>
	<li>
%生成元 ~LET コレの`既定の生成元$
◎
Let origin be this PermissionsPolicy object’s default origin.
</li>
	<li>
%施策 ~LET コレに`結付けられた~node$用の`観測-可能な施策$
◎
Let policy be the observable policy for this PermissionsPolicy object’s associated node.
</li>
	<li>
~EACH( `~support済み特能$ %特能 )
に対し
⇒
~IF［
%施策 により， %特能 は %生成元 用に許容される
］
⇒
%結果 に %特能 を`付加する$set
◎
For each supported feature feature:
• If feature is allowed by policy for origin, append feature to result.
</li>
	<li>
~RET %結果
◎
return result
</li>
</ol>
</div>

<div class="algo">
<p>
`getAllowlistForFeature(feature)@m
~method手続きは：
◎
The getAllowlistForFeature(feature) method must run the following steps:
</p>
<ol>
	<li>
%結果 ~SET 空な~list
◎
Set result to an empty list.
</li>
	<li>
%生成元 ~LET コレの`既定の生成元$
◎
Let origin be this PermissionsPolicy object’s default origin.
</li>
	<li>
%施策 ~LET コレに`結付けられた~node$用の`観測-可能な施策$
◎
Let policy be the observable policy for this PermissionsPolicy object’s associated node.
</li>
	<li>
~IF［
%施策 により， %特能 は %生成元 用には許容されない
］
⇒
~RET %結果
◎
If feature is not allowed in policy for origin, return result
</li>
	<li>
%許容list ~LET %施策 の`宣言-済み施策$pPの`宣言~群$dP[ %特能 ]
◎
Let allowlist be policy’s declared policy[feature]'s declarations.
</li>
	<li>
<p>
~IF［
%許容list ~EQ `全~生成元$i
］：
◎
If allowlist is the special value *:
</p>
		<ol>
			<li>
%結果 に`全~生成元$iを`付加する$set
◎
Append "*" to result
</li>
			<li>
~RET %結果
◎
Return result.
</li>
		</ol>
	</li>
	<li>
~IF［
%許容list の`自己-生成元$AL ~NEQ ~NULL
］
⇒
%結果 に次の結果を`付加する$set
⇒
`生成元を直列化する$( %許容list の`自己-生成元$AL )
◎
If the allowlist’s self-origin is not null, append the serialization of it to result.
</li>
	<li>
~IF［
%許容list の`~src生成元$AL ~NEQ ~NULL
］
⇒
%結果 に次の結果を付加する
⇒
`生成元を直列化する$( %許容list の`~src生成元$AL )
◎
If the allowlist’s src-origin is not null, append the serialization of it to result.
</li>
	<li>
~ELSE
⇒
%許容list の`式~群$ALを成す
~EACH( %~item )
に対し
⇒
%結果 に %~item を付加する
◎
Otherwise, for each permissions-source-expression item in allowlist’s expressions:
• Append item to result
</li>
	<li>
~RET %結果
◎
Return result.
</li>
</ol>
</div>

<div class="algo">
<p>
所与の［
`要素$／`文書$
］【！Node】 %~node 用の
`観測-可能な施策@
は、［
%~node の`~node~navigable$【！the navigable represented by that Node】内の施策についての情報のうち，
%~node の`~node文書$【！現在の文書】から可視なもの
］を包含する`許可~施策$であり，
次を走らせた結果になる：
◎
The observable policy for any Node is a permissions policy, which contains the information about the policy in the navigable represented by that Node which is visible from the current document.
◎
↓ To get the observable policy for a Document document, return document’s permissions policy.
◎
To get the observable policy for an Element node, run the following steps:
</p>
<ol>
	<li>
~IF［
%~node は`文書$である
］
⇒
~RET %~node の`許可~施策$doc
◎
↑</li>
	<li>
%継承した施策 ~LET 新たな`有順序~map$
◎
Let inherited policy be an empty ordered map.
</li>
	<li>
~EACH( `~support済み特能$ %特能 )
に対し
⇒
%継承した施策[ %特能 ] ~SET
`生成元に属する容器~内の特能~用に継承される施策を定義する$( %特能, %~node, %~node 用に`宣言された生成元$ )
◎
For each supported feature feature:
• Let isInherited be the result of running Define an inherited policy for feature in container at origin on feature, node and node’s declared origin.
• Set inherited policy[feature] to isInherited.
</li>
	<li>
<p>
~RET 新たな`許可~施策$
— その
⇒＃
`継承した施策$pP ~SET %継承した施策
`宣言-済み施策$pP ~SET `新たな宣言-済み施策$()
◎
Return a new permissions policy with inherited policy inherited policy, declared policy a struct with both declarations and reporting configuration new ordered maps.
</li>
</ol>
</div>

<div class="algo">
<p>
所与の
( `要素$ %要素 )
用に
`宣言された生成元@
を取得するときは、
次を走らす：
◎
To get the declared origin for an Element node, run the following steps:
</p>
<ol>
	<li>
%文書 ~LET %要素 の`~node文書$
◎
↓</li>
	<li>
~IF［
`閲覧~文脈~sandbox化( 生成元 )~flag$ ~IN %文書 にて`作動中な~sandbox法~flag集合$
］
⇒
~RET 新たな`不透明な生成元$
◎
If node’s node document’s sandboxed origin browsing context flag is set, then return a new opaque origin.
</li>
	<li>
~IF［
%要素 は `sandbox$aF 属性を有していて，その値は `allow-same-origin^v ~keywordを包含しない
］
⇒
~RET 新たな`不透明な生成元$
◎
If node’s sandbox attribute is set, and does not contain the allow-same-origin keyword, then return a new opaque origin.
</li>
	<li>
~IF［
%要素 は `srcdoc$aF 属性を有する
］
⇒
~RET %文書 の`生成元$doc
◎
If node’s srcdoc attribute is set, then return node’s node document’s origin.
</li>
	<li>
<p>
~IF［
%要素 は `src$aF 属性を有する
］：
◎
If node’s src attribute is set:
</p>
		<ol>
			<li>
<p>
%~URL ~LET `~URLを相対的に構文解析する$( %要素 の `src$aF 属性の値, %文書 )
</p>

<p class="trans-note">【
`~HTMLの更新＠https://github.com/whatwg/html/commit/59e75bb5eace7d378c5b52e47790cd8553bb66e7$により、
“~URLを相対的に構文解析する” の挙動は改められ，
元と同じに挙動する “`~URLを符号化法の下で相対的に構文解析する$” が追加されたので、
これは，後者を参照するべきと思われる。
】</p>
◎
Let url be the result of parsing node’s src attribute, relative to node’s node document.
</li>
			<li>
~IF［
%~URL ~NEQ `失敗^i
］
⇒
~RET %~URL の`生成元$url
◎
If url is not failure, return url’s origin.
</li>
		</ol>
	</li>
	<li>
~RET %文書 の`生成元$doc
◎
Return node’s node document’s origin.
</li>
</ol>

<p class="note">注記：
`宣言された生成元$の概念は、［
~pageが~frameの中へ読込もうと意図している文書
］の生成元を表現することが意図される。
このことは、
一例として，［
`sandbox^a ／ `srcdoc^a
］属性を~supportしない~browserは、［
宣言された生成元を算出するときには，
その属性を織り込まないべきである
］ことを意味する。
◎
The declared origin concept is intended to represent the origin of the document which the embedding page intends to load into a frame. This means, for instance, that if the browser does not support the sandbox or srcdoc attributes, it should not take those attributes into account when computing the declared origin.
</p>
</div>

		</section>
	</section>
	<section id="reporting">
<h2 title="Reporting">8. 報告-法</h2>

<p>
`許可~施策~違反~報告@
は、［
`文書$内のある挙動が，許可~施策に`違反-$している
］ことを指示する。
［
その施策に
`違反-@
するとは何を意味するのか定義すること
］，および［
そのような`違反$は，いつ生じたとされるか決定する方法
］は、
個々の`施策により制御される特能$の仕様に委ねられる。
◎
Permissions policy violation reports indicate that some behavior of the Document has violated a permissions policy. It is up to the specification of each individual policy-controlled feature to define what it means to violate that policy, and how to determine when such a violation has occurred.
</p>

<p>
`許可~施策~違反~報告$の`報告~種別$は、
`permissions-policy-violation^l とする。
◎
Permissions policy violation reports have the report type "permissions-policy-violation".
</p>

<p>
`許可~施策~違反~報告$は、
`報告用~観測器から可視$になるとする。
◎
Permissions policy violation reports are visible to ReportingObservers.
</p>

<pre class="idl">
[`Exposed$=Window]
interface `PermissionsPolicyViolationReportBody@I : `ReportBody$I {
  [`Default$] `object$ `toJSON@m();
  readonly attribute `DOMString$ `featureId$m;
  readonly attribute `DOMString$? `sourceFile$m;
  readonly attribute `long$? `lineNumber$m;
  readonly attribute `long$? `columnNumber$m;
  readonly attribute `DOMString$ `disposition$m;
  readonly attribute `DOMString$? `allowAttribute$m;
  readonly attribute `DOMString$? `srcAttribute$m;
};
</pre>

<p>
`許可~施策~違反~報告$の`本体$rPは、
~JSにおいては，次の~fieldを包含する
`PermissionsPolicyViolationReportBody$I により表現される：
◎
A permissions policy violation report’s body, represented in JavaScript by PermissionsPolicyViolationReportBody, contains the following fields:
</p>

<dl class="idl-def">
	<dt>`featureId@m</dt>
	<dd>
当の施策に`違反-$した`特能$を識別する文字列。
この文字列は、
関係する報告を［
~group化する／数える
］ときに利用できる。
◎
featureId: The string identifying the policy-controlled feature whose policy has been violated. This string can be used for grouping and counting related reports.
</dd>

	<dt>`sourceFile@m</dt>
	<dd>
既知ならば，`違反$が生じた~file
— 他の場合は ~NULL 。
◎
sourceFile: If known, the file where the violation occured, or null otherwise.
</dd>

	<dt>`lineNumber@m</dt>
	<dd>
既知ならば， `sourceFile$m において`違反$が生じた箇所の行番号
— 他の場合は ~NULL 。
◎
lineNumber: If known, the line number in sourceFile where the violation occured, or null otherwise.
</dd>

	<dt>`columnNumber@m</dt>
	<dd>
既知ならば， `sourceFile$m において`違反$が生じた箇所の列番号
— 他の場合は ~NULL 。
◎
columnNumber: If known, the column number in sourceFile where the violation occured, or null otherwise.
</dd>

	<dt>`disposition@m</dt>
	<dd>
<p>
`違反-$された許可~施策は、
この事例にて施行されたかどうかを指示する文字列：
◎
disposition: A string indicating whether the violated permissions policy was enforced in this case. disposition will be＼
</p>
		<ul>
			<li>
当の施策は施行されたならば、
`enforce^l に設定される。
◎
set to "enforce" if the policy was enforced,＼
</li>
			<li>
当の`違反$は，この報告を生成させるだけであった
（~UAは、
違反に呼応して，それ以上の動作はとらなかった）
ならば、
`report^l に設定される。
◎
or "report" if the violation resulted only in this report being generated (with no further action taken by the user agent in response to the violation).
</li>
		</ul>
	</dd>

	<dt>`allowAttribute@m</dt>
	<dd>
潜在的な違反の報告†は、
特定の `iframe$e 要素に帰属し得る。
そのような報告~用には、
当の要素の `allow$aF 属性の値
— 他の場合は ~NULL 【！omitted】。
◎
allowAttribute: For reports of potential violations, which can be attributed to a specific iframe element, the value of the allow attribute of that element, or omitted otherwise.
</dd>

	<dt>`srcAttribute@m</dt>
	<dd>
潜在的な違反の報告†は、
特定の `iframe$e 要素に帰属し得る。
そのような報告~用には、
当の要素の `src$aF 属性の値
— 他の場合は ~NULL 【！omitted】。
◎
srcAttribute: For reports of potential violations, which can be attributed to a specific iframe element, the value of the src attribute of that element, or omitted otherwise.
</dd>
</dl>

<p class="trans-note">【†
“潜在的な違反（ `potential violations^en ）” とは，正確に何を意味するのかは、
この仕様には述べられていない
— いずれにせよ、
`設定群に対し許可~施策の潜在的な違反~用の報告を生成する$~algoにより作成される報告。
】</p>

		<section id="permissions-policy-report-only-http-header-field">
<h3 title="Permissions-Policy-Report-Only HTTP Header Field">8.1. `Permissions-Policy-Report-Only^h ~HTTP~header</h3>

<p>
~serverは、
~HTTP応答【！~FETCH#concept-response-response】内に
`Permissions-Policy-Report-Only@h
~headerを利用することにより，［
~clientにより施行されるべきではない代わりに、
次のために利用されるベキ`許可~施策$
］を~clientへ通信できる
⇒
それの中で宣言された いずれかの施策が［
それが作動中に`なったなら^em 違反される場合
］には、
報告の送信を誘発する。
◎
The `Permissions-Policy-Report-Only` HTTP header field can be used in the response (server to client) to communicate a permissions policy that should not be enforced by the client, but instead should be used to trigger reports to be sent if any policy declared within it would have been violated, had the policy been active.
</p>

<p>
`Permissions-Policy-Report-Only$h は、
`有構造~header$である。
その値は、
`辞書$sfでなければナラナイ。
◎
`Permissions-Policy-Report-Only` is a structured header. Its value must be a dictionary.
</p>

<p>
この辞書の意味論は、
`§ 有構造~headerの直列化＠#structured-header-serialization$
にて定義される。
◎
The semantics of the dictionary are defined in § 5.2 Structured header serialization.
</p>

<p>
この辞書の処理は、
`辞書と生成元から施策を構築する$
手続きにて定義される。
◎
The processing steps are defined in § 9.2 Construct policy from dictionary and origin.
</p>

		</section>
	</section>
	<section id="algorithms">
<h2 title="Algorithms">9. 各種~algo</h2>

		<section id="algo-process-response-policy">
<h3 title="Process response policy">9.1. `応答~施策を処理する@</h3>

<div class="algo">
<p>
この~algoは、
所与の
( `応答$ %応答, `生成元$ %生成元, 真偽値 %報告のみか )
に対し，`宣言-済み施策$を返す：
◎
Given a response (response), an origin (origin), and a boolean (report-only), this algorithm returns a declared policy.
</p>
<ol>
	<li>
%~header名 ~LET %報告のみか に応じて
⇒＃
~T ならば `Permissions-Policy-Report-Only^bl ／
~F ならば `Permissions-Policy^bl ／
◎
Let header name be "Permissions-Policy-Report-Only" if report-only is True, or "Permissions-Policy" otherwise.
</li>
	<li>
%構文解析した~header ~LET
%応答 の`~header~list$rsから`有構造~field値を取得する$( %~header名, `辞書^i )
◎
Let parsed header be the result of executing get a structured field value given header name and "dictionary" from response’s header list.
</li>
	<li>
~IF［
%構文解析した~header ~EQ ~NULL
］
⇒
~RET `新たな宣言-済み施策$()【！empty ordered map】
◎
If parsed header is null, return an empty ordered map.
</li>
	<li>
~RET `辞書と生成元から施策を構築する$( %構文解析した~header, %生成元 )
◎
Let policy be the result of executing Construct policy from dictionary and origin on parsed header and origin.
◎
Return policy.
</li>
</ol>
</div>

		</section>
		<section id="algo-construct-policy">
<h3 title="Construct policy from dictionary and origin">9.2. `辞書と生成元から施策を構築する@</h3>

<div class="algo">
<p>
この~algoは、
所与の
( `有順序~map$【`辞書$sf】 %辞書, `生成元$ %生成元 )
に対し，`宣言-済み施策$を返す：
◎
Given an ordered map (dictionary) and an origin (origin), this algorithm will return a declared policy.
</p>
<ol>
	<li>
%宣言-済み施策 ~LET `新たな宣言-済み施策$()
◎
Let declarations be an empty ordered map.
◎
Let reporting-config be an empty ordered map.
</li>
	<li>
<p>
%辞書 を成す
~EACH( %特能~名 → ( %値, %~params ) )
に対し：
◎
For each feature-name → (value, params) of dictionary:
</p>
		<ol>
			<li>
%特能 ~LET ［
%特能~名 は ある`施策により制御される特能$を識別するものであって，~UAは それを認識するならば その特能／
~ELSE_ ε
］
◎
If feature-name does not identify any recognized policy-controlled feature, then continue.
◎
Let feature be the policy-controlled feature identified by feature-name.
</li>
			<li>
~IF［
%特能 ~EQ ε
］
⇒
~CONTINUE
◎
↑</li>
			<li>
%報告先 ~LET %~params[ `report-to^l ]
◎
↓</li>
			<li>
~IF［
%報告先 は`文字列$sf【！文字列】である
］
⇒
%宣言-済み施策 の`報告用~環境設定$dP[ %特能 ] ~SET %報告先
◎
If params["report-to"] exists, and is a string, then set reporting-config[feature] to params["report-to"].
</li>
			<li>
~IF［
%値 は`~list$でない
］
⇒
%値 ~SET « %値 »
◎
↓</li>
			<li>
~IF［
`全~生成元$i ~IN %値
］
⇒＃
%施策[ %特能 ] ~SET `全~生成元$i；
~CONTINUE
◎
↓ Let allowlist be a new allowlist.
◎
If value is the token *, or＼
if value is a list which contains the token *, set allowlist to the special value *.
◎
Otherwise:
◎
↓ If value is the token self, let allowlist’s self-origin be origin.
</li>
			<li>
%許容list ~LET `新たな許容list$
◎
↑</li>
			<li>
<p>
%値 を成す
~EACH( %~item )
に対し：
◎
Otherwise if value is a list, then for each element in value:
</p>
				<ol>
					<li>
~IF［
%~item ~EQ `self$P
］
⇒
%許容list の`自己-生成元$AL ~SET %生成元
◎
If element is the token self, let allowlist’s self-origin be origin.
</li>
					<li>
~ELIF［
%~item は妥当な `permissions-source-expression$P である
］
⇒
%許容list の`式~群$ALに %~item を`付加する$
◎
If element is a valid permissions-source-expression, append element to allowlist’s expressions.
</li>
				</ol>
			</li>
			<li>
%宣言-済み施策 の`宣言~群$dP[ %特能 ] ~SET %許容list
◎
Set declarations[feature] to allowlist.
</li>
		</ol>
	</li>
	<li>
~RET %宣言-済み施策
◎
Return «declarations, reporting-config».
</li>
</ol>
</div>

		</section>
		<section id="algo-parse-policy-directive">
<h3 title="Parse policy directive">9.3. `施策~指令を構文解析する@</h3>

<div class="algo">
<p>
この~algoは、
所与の
( 文字列 %値, `生成元$ %容器~生成元, `生成元$ %~target生成元（省略時は ε ） )
に対し，`施策~指令$を返す：
◎
Given a string (value), an origin (container origin), and an optional origin (target origin), this algorithm returns a policy directive.
</p>
<ol>
	<li>
%指令 ~LET 新たな`有順序~map$
◎
Let directive be an empty ordered map.
</li>
	<li>
<p>
`区切子で厳密に分割する$( %値, `003B^U (;) )
の結果を成す
~EACH( %直列形の宣言 )
に対し：
◎
For each serialized-declaration returned by strictly splitting value on the delimiter U+003B (;):
</p>
		<ol>
			<li>
%~token群 ~LET `~ASCII空白で分割する$( %直列形の宣言 )
◎
Let tokens be the result of splitting serialized-declaration on ASCII whitespace.
</li>
			<li>
~IF［
%~token群 は空である
］
⇒
~CONTINUE
◎
If tokens is an empty list, then continue.
</li>
			<li>
%特能~名 ~LET %~token群[ 0 ]
◎
Let feature-name be the first element of tokens.
</li>
			<li>
%特能 ~LET %特能~名 により識別される`~support済み特能$が［
在るならば それ ／
無いならば ε
］
◎
If feature-name does not identify any recognized policy-controlled feature, then continue.
</li>
			<li>
~IF［
%特能 ~EQ ε
］
⇒
~CONTINUE
◎
Let feature be the policy-controlled feature identified by feature-name.
</li>
			<li>
%~target~list ~LET %~token群 から最初の~itemを除去して得られる~list
◎
Let targetlist be the remaining elements, if any, of tokens.
</li>
			<li>
~IF［
`全~生成元$i ~IN %~target~list
］
⇒＃
%指令[ %特能 ] ~SET `全~生成元$i；
~CONTINUE
◎
Let allowlist be a new allowlist.
◎
If any element of targetlist is the string "*", set allowlist to the special value *.
</li>
			<li>
%許容list ~SET `新たな許容list$
◎
↑ Otherwise:
</li>
			<li>
~IF［
%~target~list は空である
］
⇒
%~target~list に `'src'^l を`付加する$
◎
↓ If targetlist is empty and target origin is given, let allowlist’s src-origin be target origin.
</li>
			<li>
<p>
%~target~list を成す
~EACH( %~item【！element】 )
に対し：
◎
For each element in targetlist:
</p>
				<ol>
					<li>
<p>
~IF［
%~item は `'self'^l に`~ASCII大小無視$で合致する
］：
◎
If element is an ASCII case-insensitive match for "'self'":
</p>
						<ol>
							<li>
%許容list の`自己-生成元$AL ~SET %容器~生成元
◎
Let allowlist’s self-origin be container origin.
</li>
							<li>
~CONTINUE
◎
Continue to the next element.
</li>
						</ol>
					</li>
					<li>
<p>
~IF［
%~target生成元 ~NEQ ε
］~AND［
%~item は `'src'^l に`~ASCII大小無視$で合致する
］：
◎
If target origin is given, and element is an ASCII case-insensitive match for "'src'":
</p>
						<ol>
							<li>
%許容list の`~src生成元$AL ~SET %~target生成元
◎
Let allowlist’s src-origin be target origin.
</li>
							<li>
~CONTINUE
◎
Continue to the next element.
</li>
						</ol>
					</li>
					<li>
%結果 ~LET `~URL構文解析する$( %~item )
◎
Let result be the result of executing the URL parser on element.
</li>
					<li>
~IF［
%結果 ~EQ `失敗^i
］
⇒
~CONTINUE
◎
If result is not failure:
</li>
					<li>
%~target ~LET %結果 の`生成元$url
◎
Let target be the origin of result.
</li>
					<li>
~IF［
%~target は`不透明な生成元$である
］
⇒
~CONTINUE
◎
If target is not an opaque origin,＼
</li>
					<li>
<p>
%許容list の`式~群$ALに次の結果を`付加する$set【！`付加する$】
⇒
`生成元を直列化する$( %~target )
</p>

<p class="trans-note">【
結果は `permissions-source-expression$P に合致するはずである。
】</p>
◎
append the serialization of target to allowlist’s expressions.
</li>
				</ol>
			</li>
			<li>
%指令[ %特能 ] ~SET %許容list
◎
Set directive[feature] to allowlist.
</li>
		</ol>
	</li>
	<li>
~RET %指令
◎
Return directive
</li>
</ol>
</div>

		</section>
		<section id="algo-process-policy-attributes">
<h3 title="Process permissions policy attributes">9.4. `許可~施策~属性を処理する@</h3>

<div class="algo">
<p>
この~algoは、
所与の
( 要素 %要素 )
に対し，`容器~施策$を返す（空にもなり得る）：
◎
Given an element (element), this algorithm returns a container policy, which may be empty.
</p>
<ol>
	<li>
~IF［
%要素 は `iframe$e 要素でない
］
⇒
~RET 空な`容器~施策$
◎
If element is not an iframe element, then return an empty policy directive.
</li>
	<li>
%容器~施策 ~LET `施策~指令を構文解析する$(
%要素 の `allow$aF 属性の値,
%要素 の`~node文書$の`生成元$doc,
%要素 用に`宣言された生成元$
)
◎
Let container policy be the result of running Parse policy directive given the value of element’s allow attribute, the origin of element’s node document, and element’s declared origin.
</li>
	<li>
~IF［
%要素 は `allowfullscreen$aF 属性を有する
］~AND［
%容器~施策[ `fullscreen^l ] ~EQ ε
］
⇒
%容器~施策[ `fullscreen^l ] ~SET `全~生成元$i
◎
If element’s allowfullscreen attribute is specified, and container policy does not contain an entry for the fullscreen feature.
• Set container policy[fullscreen] = the special value *.
</li>
	<li>
~RET %容器~施策
◎
Return container policy.
</li>
</ol>
</div>

		</section>
		<section id="algo-create-for-navigable">
<h3 title="Create a Permissions Policy for a navigable">9.5. `~navigable用の許可~施策を作成する@</h3>

<div class="algo">
<p>
この~algoは、
所与の
( ［
~NULL ／`要素$
］ %容器, `生成元$ %生成元 )
に対し，新たな`許可~施策$を返す：
◎
Given null or an element (container) and an origin (origin) this algorithm returns a new Permissions Policy.
</p>
<ol>
	<li>
~Assert：
%容器 ~EQ ~NULL ならば，
%容器 は`~navigable容器$である。
◎
Assert: If not null, container is a navigable container.
</li>
	<li>
%継承した施策 ~LET 新たな`有順序~map$
◎
Let inherited policy be a new ordered map.
</li>
	<li>
~EACH( `~support済み特能$ %特能 )
に対し
⇒
%継承した施策[ %特能 ] ~SET `生成元に属する容器~内の特能~用に継承される施策を定義する$( %特能, %容器, %生成元 )
◎
For each feature supported,
• Let isInherited be the result of running Define an inherited policy for feature in container at origin on feature, container and origin.
• Set inherited policy[feature] to isInherited.
</li>
	<li>
%施策 ~LET 新たな`許可~施策$
— その
⇒＃
`継承した施策$pP ~SET %継承した施策
`宣言-済み施策$pP ~SET `新たな宣言-済み施策$()
◎
Let policy be a new permissions policy, with inherited policy inherited policy and declared policy «[], []».
</li>
	<li>
~RET %施策
◎
Return policy.
</li>
</ol>
</div>

		</section>
		<section id="algo-create-from-response">
<h3 title="Create a Permissions Policy for a navigable from response">9.6. `応答から~navigable用の許可~施策を作成する@</h3>

<div class="algo">
<p>
この~algoは、
所与の
( ［
~NULL ／ `~navigable容器$
］ %容器, `生成元$ %生成元, `応答$ %応答, 真偽値 %報告のみか （省略時は ~F ）)
に対し，新たな`許可~施策$を返す：
◎
Given null or a navigable container (container), an origin (origin), a response (response), and an optional boolean (report-only), with a default value of False, this algorithm returns a new permissions policy.
</p>
<ol>
	<li>
%施策 ~LET `~navigable用の許可~施策を作成する$( %容器, %生成元 )
◎
Let policy be the result of running Create a Permissions Policy for a navigable given container and origin.
</li>
	<li>
%応答~施策 ~LET `応答~施策を処理する$( %応答, %生成元, %報告のみか )
◎
Let d be the result of running Process response policy given response, origin and report-only.
</li>
	<li>
%応答~施策 の`宣言~群$dPを成す
~EACH( %特能 → %許容list )
に対し
⇒
~IF［
%施策 が`継承した施策$pP[ %特能 ] ~EQ `可能化される^i【！~T】
］
⇒
%施策 の`宣言-済み施策$pPの`宣言~群$dP[ %特能 ] ~SET %許容list
◎
For each feature → allowlist of d’s declarations:
• If policy’s inherited policy[feature] is true, then set policy’s declared policy’s declarations[feature] to allowlist.
</li>
	<li>
%施策 の`宣言-済み施策$pPの`報告用~環境設定$dP[ %特能 ] ~SET %応答~施策 の`報告用~環境設定$dP
◎
Set policy’s declared policy[feature]'s reporting configuration to d’s reporting configuration.
</li>
	<li>
~RET %施策
◎
Return policy.
</li>
</ol>
</div>

		</section>
		<section id="algo-define-inherited-policy-in-container">
<h3 title="Define an inherited policy for feature in container at origin">9.7. `生成元に属する容器~内の特能~用に継承される施策を定義する@</h3>

<div class="algo">
<p>
この~algoは、
所与の
⇒＃
`特能$ %特能,
［ ~NULL ／ `~navigable容器$ ］ %容器,
%容器 内の文書【 %容器 の`内容~文書$】用の`生成元$ %内容~生成元,
真偽値 %報告のみか（省略時は ~F ）
◎終
に対し，`特能~用に継承される施策$を返す：
◎
Given a feature (feature), null or a navigable container (container), an origin for a Document in that container (origin), and an optional boolean (report-only), with a default value of False, this algorithm returns the inherited policy value for feature.
</p>
<ol>
	<li>
~IF［
%容器 ~EQ ~NULL
］
⇒
~RET `可能化される^i
◎
If container is null, return "Enabled".
</li>
	<li>
%文書 ~LET %容器 の`~node文書$
◎
↓</li>
	<li>
« %文書 の`生成元$doc, %内容~生成元 »
を成す
~EACH( %生成元 )
に対し
⇒
~IF［
`生成元~用の特能~値を取得する$( %特能, %文書, %生成元, %報告のみか ) ~EQ `不能化される^i
］
⇒
~RET `不能化される^i
◎
If the result of executing Get feature value for origin on feature, container’s node document, container’s node document’s origin, and report-only is "Disabled", return "Disabled".
◎
If the result of executing Get feature value for origin on feature, container’s node document, origin, and report-only is "Disabled", return "Disabled".
</li>
	<li>
%容器~施策 ~LET `許可~施策~属性を処理する$( %容器 )
◎
Let container policy be the result of running Process permissions policy attributes on container.
</li>
	<li>
<p>
~IF［
%容器~施策[ %特能 ] ~NEQ ε
］：
◎
If feature exists in container policy:
</p>
		<ol>
			<li>
~IF［
`許容listは生成元に合致するか？$( %容器~施策[ %特能 ], %内容~生成元 ) ~EQ ~T
］
⇒
~RET `可能化される^i
◎
If the allowlist for feature in container policy matches origin, return "Enabled".
</li>
			<li>
~RET `不能化される^i
◎
Otherwise return "Disabled".
</li>
		</ol>
	</li>
	<li>
~IF［
%特能 の`既定の許容list$ ~EQ `全~生成元$i
］
⇒
~RET `可能化される^i
◎
If feature’s default allowlist is *, return "Enabled".
</li>
	<li>
~IF［
%特能 の`既定の許容list$ ~EQ `'self'^l
］~AND［
( %内容~生成元, %文書 の`生成元$doc )
は`同一-生成元$である
］
⇒
~RET `可能化される^i
◎
If feature’s default allowlist is 'self', and origin is same origin with container’s node document’s origin, return "Enabled".
</li>
	<li>
~RET `不能化される^i
◎
Otherwise return "Disabled".
</li>
</ol>
</div>

		</section>
		<section id="algo-get-feature-value-for-origin">
<h3 title="Get feature value for origin">9.8. `生成元~用の特能~値を取得する@</h3>

<div class="algo">
<p>
この~algoは、
所与の
⇒＃
`特能$ %特能,
`文書$ %文書,
`生成元$ %生成元,
真偽値 %報告のみか（省略時は ~F ）
◎終
に対し，［
%特能 は不能化されるべきと見なされるならば `不能化される^i ／
~ELSE_ `可能化される^i
］を返す：
◎
Given a feature (feature), a Document object (document), an origin (origin), and a boolean (report-only), this algorithm returns "Disabled" if feature should be considered disabled, and "Enabled" otherwise.
</p>
<ol>
	<li>
%施策 ~LET %報告のみか に応じて
⇒＃
~T ならば %文書 の`報告のみの許可~施策$doc／
~F ならば %文書 の`許可~施策$doc
◎
Let policy be document’s report-only permissions policy if report-only is True, or document’s permissions policy otherwise.
</li>
	<li>
~IF［
%施策 が`継承した施策$pP[ %特能 ] ~EQ `不能化される^i
］
⇒
~RET `不能化される^i
◎
If policy’s inherited policy for feature is "Disabled", return "Disabled".
</li>
	<li>
%許容list ~LET %施策 の`宣言-済み施策$pPの`宣言~群$dP[ %特能 ]
◎
↓</li>
	<li>
<p>
~IF［
%許容list ~NEQ ε
］：
◎
If feature is present in policy’s declared policy:
</p>
		<ol>
			<li>
~IF［
`許容listは生成元に合致するか？$( %許容list, %生成元 ) ~EQ ~T
］
⇒
~RET `可能化される^i
◎
If policy’s declared policy’s declarations[feature] matches origin, then return "Enabled".
</li>
			<li>
~RET `不能化される^i
◎
Otherwise return "Disabled".
</li>
		</ol>
	</li>
	<li>
~RET `可能化される^i
◎
Return "Enabled".
</li>
</ol>
</div>

		</section>
		<section id="algo-check-permissions-policy">
<h3 title="Check permissions policy">9.9. `許可~施策を検査する@</h3>

<div class="algo">
<p>
この~algoは、
所与の
( `許可~施策$ %施策, `特能$ %特能, `生成元$ %生成元, `生成元$ %文書~生成元 )
に対し，［
%特能 は不能化されるべきと見なされるならば `不能化される^i ／
~ELSE_ `可能化される^i
］を返す：
◎
To check a permissions policy, given permissions policy (policy), a feature (feature), an origin (origin) and another origin (document origin), this algorithm returns "Disabled" if feature should be considered disabled, and "Enabled" otherwise.
</p>
<ol>
	<li>
~IF［
%施策 が`継承した施策$pP[ %特能 ] ~EQ `不能化される^i
］
⇒
~RET `不能化される^i
◎
If policy’s inherited policy for feature is "Disabled", return "Disabled".
</li>
	<li>
%許容list ~LET %施策 の`宣言-済み施策$pPの`宣言~群$dP[ %特能 ]
◎
↓</li>
	<li>
<p>
~IF［
%許容list ~NEQ ε
］：
◎
If feature is present in policy’s declared policy:
</p>
		<ol>
			<li>
~IF［
`許容listは生成元に合致するか？$( %許容list, %生成元 ) ~EQ ~T
］
⇒
~RET `可能化される^i
◎
If policy’s declared policy’s declarations[feature] matches origin, then return "Enabled".
</li>
	<li>
~RET `不能化される^i
◎
Otherwise return "Disabled".
</li>
		</ol>
	</li>
	<li>
~IF［
%特能 の`既定の許容list$ ~EQ `全~生成元$i
］
⇒
~RET `可能化される^i
◎
If feature’s default allowlist is *, return "Enabled".
</li>
	<li>
~IF［
%特能 の`既定の許容list$ ~EQ `'self'^l
］~AND［
( %生成元, %文書~生成元 )
は`同一-生成元$である
］
⇒
~RET `可能化される^i
◎
If feature’s default allowlist is 'self', and origin is same origin with document origin, return "Enabled".
</li>
	<li>
~RET `不能化される^i
◎
Return "Disabled".
</li>
</ol>
</div>

		</section>
		<section id="algo-is-feature-enabled">
<h3 title="Is feature enabled in document for origin?">9.10. `文書~内の特能は生成元~用に可能化されるか？@</h3>

<div class="algo">
<p>
この~algoは、
所与の
( `特能$ %特能, `文書$ %文書, `生成元$ %生成元, 真偽値 %報告するか（省略時は ~T【！True】 ）)
に対し：
◎
Given a feature (feature), a Document object (document), an origin (origin), and an optional boolean (report), with a default value of True, this algorithm＼
</p>
<ul>
	<li>
［
%特能 は不能化されるべきと見なされるならば `不能化される^i ／
~ELSE_ `可能化される^i
］を返す。
◎
returns "Disabled" if feature should be considered disabled, and "Enabled" otherwise.＼
</li>
	<li>
%報告するか ~EQ ~T の場合、
%特能 は［
%文書 の`許可~施策$doc ／
%文書 の`報告のみの許可~施策$doc
］いずれかにおいて可能化されない場合に，
`報告を生成して~queueする$ことになる。
◎
If report is True, then it will also generate and queue a report if the feature is not enabled in either document’s permissions policy or document’s report-only permissions policy.
</li>
</ul>

<p class="note">注記：
%報告するか 用の既定の値 ~T は、［
ほとんどの許可~施策~検査に対しては、
当の特能が可能化されない場合に，違反~報告を生成することになる
］ことを意味する。
ほとんどの検査は，当の特能の利用を実際に試みるために遂行されるので、
これが期待される結果になる。
そのような試みではなく，
ある特能の状態をただ~queryするために この~algoを~callする場合、
%報告するか を ~F に設定するべきである。
◎
Note: The default value of True for report means that most permissions policy checks will generate a violation report if the feature is not enabled. This is the expected result, as most checks are for an actual attempted use of the feature. If a call to this algorithm is performed just to query the state of a feature, and does not represent an actual attempt to use the feature, then report should be set to False.
</p>
<ol>
	<li>
%施策 ~LET %文書 の`許可~施策$doc
◎
Let policy be document’s permissions policy.
</li>
	<li>
%報告のみの施策 ~LET %文書 の`報告のみの許可~施策$doc
◎
Let report-only policy be document’s report-only permissions policy.
</li>
	<li>
%結果 ~LET `許可~施策を検査する$( %施策, %特能, %生成元, %文書 の`生成元$doc )
◎
Let result be the result of calling Check permissions policy, given policy, feature, origin, and document’s origin.
</li>
	<li>
%報告のみの結果 ~LET 
`許可~施策を検査する$( %報告のみの施策, %特能, %生成元, %文書 の`生成元$doc )
◎
Let report-only result be the result of calling Check permissions policy, given report-only policy, feature, origin, and document’s origin.
</li>
	<li>
<p>
~IF［
%報告するか ~EQ ~T
］：
◎
If report is True:
</p>
		<ol>
			<li>
%設定群 ~LET %文書 の`環境~設定群~obj$
◎
Let settings be document’s environment settings object.
</li>
			<li>
<p>
~IF［
%結果 ~EQ `不能化される^i
］：
◎
If result is "Disabled":
</p>
				<ol>
					<li>
%報告先 ~LET `特能~用の報告用~端点を取得する$( %特能, %施策 )
◎
Let endpoint be the result of calling Get the reporting endpoint for a feature given feature and policy.
</li>
					<li>
`設定群に対し許可~施策の違反~用に報告を生成する$( %特能, %設定群, `enforce^l【！"Enforce"】, %報告先 )
◎
Call Generate report for violation of permissions policy on settings given feature, settings, "Enforce", and endpoint.
</li>
				</ol>
			</li>
			<li>
<p>
~ELIF［
%報告のみの結果 ~EQ `不能化される^i
］：
◎
Else, if report-only result is "Disabled":
</p>
				<ol>
					<li>
%報告のみの報告先 ~LET `特能~用の報告用~端点を取得する$( %特能, %報告のみの施策 )
◎
Let report-only endpoint be the result of calling Get the reporting endpoint for a feature given feature and report-only policy.
</li>
					<li>
`設定群に対し許可~施策の違反~用に報告を生成する$( %特能, %設定群, `report^l【！"Report"】, %報告のみの報告先 )
◎
Call Generate report for violation of permissions policy on settings given feature, settings, "Report", and report-only endpoint.
</li>
				</ol>
			</li>
		</ol>
	</li>
	<li>
~RET %結果
◎
Return result
</li>
</ol>
</div>

		</section>
		<section id="algo-get-reporting-endpoint">
<h3 title="Get the reporting endpoint for a feature">9.11. `特能~用の報告用~端点を取得する@</h3>

<div class="algo">
<p>
この~algoは、
所与の
( `特能$ %特能, `許可~施策$ %施策 )
に対し，［
違反~報告の送信-先を与える報告先が %施策 内に宣言されているならば，それを命名している文字列／
無いならば， ~NULL
］を返す：
◎
Given a feature (feature) and a permissions policy (policy), this algorithm returns a string naming the endpoint to send violation reports to, or null if no such endpoint has been declared in policy.
</p>
<ol>
	<li>
%結果 ~LET %施策 の`宣言-済み施策$pPの`報告用~環境設定$dP[ %特能 ]
◎
Let config be policy’s declared policy’s reporting configuration.
◎
If config[feature] exists, return config[feature].
</li>
	<li>
~IF［
%結果 ~NEQ ε
］
⇒
~RET %結果
◎
↑</li>
	<li>
~RET ~NULL
◎
Return null.
</li>
</ol>
</div>

		</section>
		<section id="algo-check-potential-violation-in-container">
<h3 title="Check potential violation of permissions policy in container">9.12. `容器~内の許可~施策の潜在的な違反を検査する@</h3>

<div class="algo">
<p>
この~algoは、
所与の
⇒＃
`~navigable容器$ %容器,
［文字列／~NULL］ %~allow属性,
［文字列／~NULL］ %~src属性
◎終
に対し，潜在的な違反~報告を送信する：
◎
Given a navigable container (container), a string-or-null (allowAttribute), and a string-or-null (srcAttribute), this algorithm sends potential violation reports.
</p>
<ol>
	<li>
%文書 ~LET %容器 の`~node文書$
◎
Let document be container’s node document.
</li>
	<li>
%設定群 ~LET %文書 の`環境~設定群~obj$
◎
Let settings be document’s environment settings object.
</li>
	<li>
<p>
~EACH( `~support済み特能$ %特能 )
に対し：
◎
For each supported feature feature:
</p>
		<ol>
			<li>
<p>
~IF［
`生成元に属する容器~内の特能~用に継承される施策を定義する$( %特能, %容器, %容器 の`宣言された生成元$ ) ~EQ `不能化される^i
］：
◎
If the result of running Define an inherited policy for feature in container at origin on feature, container and container’s declared origin is "Disabled":
</p>
				<ol>
					<li>
%報告先 ~LET `特能~用の報告用~端点を取得する$( %特能, %文書 の`許可~施策$doc )
◎
Let endpoint be the result of calling Get the reporting endpoint for a feature given feature and document’s permissions policy.
</li>
					<li>
`設定群に対し許可~施策の潜在的な違反~用の報告を生成する$( ↓ )
⇒＃
%特能,
%設定群,
`enforce^l【！"Enforce"】,
%報告先,
%~allow属性,
%~src属性
◎
Call Generate report for potential violation of permissions policy on settings given feature, settings, "Enforce", endpoint, allowAttribute, and srcAttribute.
</li>
				</ol>
			</li>
			<li>
<p>
~ELIF［
`生成元に属する容器~内の特能~用に継承される施策を定義する$( %特能, %容器, %容器 の`宣言された生成元$, ~T ) ~EQ `不能化される^i
］：
◎
Else, if the result of running Define an inherited policy for feature in container at origin on feature, container, container’s declared origin and True is "Disabled":
</p>
				<ol>
					<li>
%報告のみの報告先 ~LET `特能~用の報告用~端点を取得する$( %特能, %文書 の`報告のみの許可~施策$doc )
◎
Let report-only endpoint be the result of calling Get the reporting endpoint for a feature given feature and document’s report-only permissions policy.
</li>
					<li>
`設定群に対し許可~施策の潜在的な違反~用の報告を生成する$( ↓ )
⇒＃
%特能,
%設定群,
`report^l【！"Report"】,
%報告のみの報告先,
%~allow属性,
%~src属性
◎
Call Generate report for potential violation of permissions policy on settings given feature, settings, "Report", report-only endpoint, allowAttribute, and srcAttribute.
</li>
				</ol>
			</li>
		</ol>
	</li>
</ol>
</div>

		</section>
		<section id="algo-report-permissions-policy-violation">
<h3 title="Generate report for violation of permissions policy on settings">9.13. `設定群に対し許可~施策の違反~用に報告を生成する@</h3>

<div class="algo">
<p>
この~algoは、
所与の
( `特能$ %特能, `環境~設定群~obj$ %設定群, 文字列 %処置, ［
文字列／~NULL
］ %報告先 )
に対し，%特能 用の施策に対する`違反$についての`報告$を生成する：
◎
Given a feature (feature), an environment settings object (settings), a string (disposition), and a string-or-null (endpoint), this algorithm generates a report about the violation of the policy for feature.
</p>
<ol>
	<li>
%本体 ~LET 新たな `PermissionsPolicyViolationReportBody$I
— その
⇒＃
`featureId$m ~SET %特能 の文字列~表現,
`sourceFile$m ~SET ~NULL,
`lineNumber$m ~SET ~NULL,
`columnNumber$m ~SET ~NULL,
`disposition$m ~SET %処置
◎
Let body be a new PermissionsPolicyViolationReportBody, initialized as follows:
◎
featureId
• feature’s string representation.
sourceFile
• null
lineNumber
• null
columnNumber
• null
disposition
• disposition
</li>
	<li>
<p>
~IF［
~UAは現在~scriptを実行している
］~AND［
%設定群 から~source~fileの［
~URL, 行番号, 列番号
］を抽出できる†
］
⇒
それに則って， %本体 の［
`sourceFile$m, `lineNumber$m, `columnNumber$m
］を設定する
</p>

<p class="trans-note">【†
~URLのみ抽出できる場合もあるかもしれない。
その場合、
`sourceFile^m のみ設定されることになりそうだが，
何もしないようにも読める。
】</p>
◎
If the user agent is currently executing script, and can extract the source file’s URL, line number, and column number from settings, then set body’s sourceFile, lineNumber, and columnNumber accordingly.
</li>
	<li>
`報告を生成して~queueする$( %設定群 の`大域~obj$enV, `permissions-policy-violation^l, %報告先, %本体 )
◎
Execute generate and queue a report with body, "permissions-policy-violation", endpoint, and settings.
</li>
</ol>

<p class="note">注記：
許可~施策が`違反-$されたときには、
この~algoが~callされるべきである。
◎
Note: This algorithm should be called when a permissions policy has been violated.
</p>
</div>

		</section>
		<section id="algo-report-potential-permissions-policy-violation">
<h3 title="Generate report for potential violation of permissions policy on settings">9.14. `設定群に対し許可~施策の潜在的な違反~用の報告を生成する@</h3>

<div class="algo">
<p>
この~algoは、
所与の
⇒＃
`特能$ %特能,
`環境~設定群~obj$ %設定群,
文字列 %処置,
［文字列／~NULL］ %報告先,
［文字列／~NULL］ %~allow属性,
［文字列／~NULL］ %~src属性
◎終
に対し，
%特能 用の施策の`違反$についての`報告$を生成する：
◎
Given a feature (feature), an environment settings object (settings), a string (disposition), a string-or-null (endpoint), a string-or-null (allowAttribute), and a string-or-null (srcAttribute), this algorithm generates a report about the violation of the policy for feature.
</p>
<ol>
	<li>
%本体 ~LET 新たな `PermissionsPolicyViolationReportBody$I
— その
⇒＃
`featureId$m ~SET %特能 の文字列~表現,
`sourceFile$m ~SET ~NULL,
`lineNumber$m ~SET ~NULL,
`columnNumber$m ~SET ~NULL,
`disposition$m ~SET %処置,
`allowAttribute$m ~SET %~allow属性,
`srcAttribute$m ~SET %~src属性
◎
Let body be a new PermissionsPolicyViolationReportBody, initialized as follows:
◎
featureId
• feature’s string representation.
sourceFile
• null
lineNumber
• null
columnNumber
• null
disposition
• disposition
allowAttribute
• allowAttribute
srcAttribute
• srcAttribute
</li>
	<li>
~IF［
~UAは現在~scriptを実行している
］~AND［
%設定群 から~source~fileの［
~URL, 行番号, 列番号
］を抽出できる
］
⇒
それに則って， %本体 の［
`sourceFile$m, `lineNumber$m, `columnNumber$m
］を設定する
◎
If the user agent is currently executing script, and can extract the source file’s URL, line number, and column number from settings, then set body’s sourceFile, lineNumber, and columnNumber accordingly.
</li>
	<li>
`報告を生成して~queueする$( %設定群 の`大域~obj$enV, `potential-permissions-policy-violation^l, %報告先, %本体 )
◎
Execute generate and queue a report with body, "potential-permissions-policy-violation", endpoint, and settings.
</li>
</ol>
</div>

		</section>
		<section id="algo-should-request-be-allowed-to-use-feature">
<h3 title="Should request be allowed to use feature?">9.15. `要請には特能の利用は許容されるべきか？@</h3>

<div class="algo">
<p>
この~algoは、
所与の
( 特能 %特能, `要請$ %要請 )
に対し，［
%要請 には %特能 の利用は許容されるべきならば ~T ／
~ELSE_ ~F
］を返す：
◎
Given a feature (feature) and a request (request), this algorithm returns true if the request should be allowed to use feature, and false otherwise.
</p>
<ol>
	<li>
%~window ~SET %要請 の`~window$rq
◎
Set window to request’s window.
</li>
	<li>
<p>
~IF［
%~window は `Window$I でない
］
⇒
~RET ~F
◎
If window is not a Window, return false.
</p>

<p class="issue">
`Window^I でない文脈
（ `WorkerGlobalScope$I ／ `WorkletGlobalScope$I ）
の中の許可~施策については、
`課題 #207＠https://github.com/w3c/webappsec-permissions-policy/issues/207$
にて模索中にある。
それが解決されたなら、［
これらの文脈の中で起動される~fetchに，施策により制御される特能の利用を許容する
］よう，この~algoを更新することになる。
`解決されるまでは^em、
施策により制御される特能
（例：
第三者-主体に `Client Hints^en 【`参照＠~HTTPch#client-hint$】を送信するなど）
は，これらの文脈においては許容されない。
◎
Permissions Policy within non-Window contexts (WorkerGlobalScope or WorkletGlobalScope) is being figured out in issue #207. After that’s resolved, update this algorithm to allow fetches initiated within these contexts to use policy-controlled features. Until that’s resolved, disallow all policy-controlled features (e.g., sending Client Hints to third parties) in these contexts.
</p>
	</li>
	<li>
%文書 ~SET %~window に`結付けられた文書$
◎
Set document to window’s associated Document.
</li>
	<li>
%生成元 ~LET %要請 の`生成元$rq
◎
Let origin be request’s origin.
</li>
	<li>
~RET ~IS［
次の結果 ~EQ `可能化される^i
］
⇒
`文書~内の特能は生成元~用に可能化されるか？$( %特能, %文書, %生成元 )
◎
Let result be the result of executing Is feature enabled in document for origin? on feature, document, and origin.
◎
If result is "Enabled", return true.
◎
Otherwise, return false.
</li>
</ol>
</div>

		</section>
	</section>
	<section id="changes-to-other-specifications">
<h2 title="Changes to other specifications">10. 他の仕様に対する変更点</h2>

		<section id="changes-to-html">
<h3 title="Changes to the HTML specification">10.1. ~HTML仕様に対する変更点</h3>

<p>
各`文書$は、
`報告のみの許可~施策@doc
を有する
— それは`許可~施策$であり，初期~時は空†とする。
◎
Every Document has a report-only permissions policy, which is a permissions policy, which is initially empty.
</p>

<p class="trans-note">【†
`空な許可~施策$を意味するのか，その［
`継承した施策$pPは空な~mapであり，
`宣言-済み施策$pPは`空な許可~施策$と同じ条件を満たす
］ことを意味するのか，はっきりしない
】</p>

<p>
`文書を作成して初期化する＠~HTMLlifecycle#initialise-the-document-object$
【！~HTMLlifecycle#shared-document-creation-infrastructure】
~algoの：
◎
In 7.5.1 Shared document creation infrastructure,＼
</p>
<ul>
	<li>
<p>
段 3 の後に，次を遂行する段を挿入する：
◎
after step 3, insert the following step:
</p>
		<ol start="4">
			<li>
%報告のみの許可~施策 ~LET `応答から~navigable用の許可~施策を作成する$( ↓ )
⇒＃
%~navi~params の`~navigable$nvPの`容器$nav,
%~navi~params の`生成元$nvP,
%~navi~params の`応答$nvP,
~T
◎
Let reportOnlyPermissionsPolicy be the result of calling Create a Permissions Policy for a navigable from response given navigationParams’s navigable’s container, navigationParams’s origin, navigationParams’s response, and True.
</li>
		</ol>
	</li>
	<li>
段 10 【の直後？】に次を遂行する段を挿入する
⇒
新たな`文書$の`報告のみの許可~施策$doc ~SET %報告のみの許可~施策
◎
And in the same section, in step 10, set the new Document’s report-only permissions policy to reportOnlyPermissionsPolicy.
</li>
</ul>

<p>
`~iframe~load~event手続き$の “~eventを発火する” 段の直後に，
次を遂行する段を挿入する
⇒
`容器~内の許可~施策の潜在的な違反を検査する$( ↓ )
⇒＃
%要素,
［ %要素 は `allow$aF 属性を有するならば その値／~ELSE_ ~NULL］,
［ %要素 は `src$aF 属性を有するならば その値／~ELSE_ ~NULL］
◎
In iframe load event steps, after step 6, insert the following step:
• Call Check potential violation of permissions policy in container given element, element’s allow attribute, and element’s src attribute.
</p>

		</section>
	</section>
	<section id="iana-considerations">
<h2 title="IANA Considerations">11. ~IANA 考慮点</h2>

<p>
恒久的~message~header~registryは、
次の登録で更新されるべきである
`RFC3864$r
：
◎
The permanent message header field registry should be updated with the following registration [RFC3864]:
</p>

<div>

<dl>
	<dt>~header名</dt>
	<dd>`Permissions-Policy^h</dd>

	<dt>適用-可能な~protocol</dt>
	<dd>http</dd>

	<dt>位置付け</dt>
	<dd>標準</dd>

	<dt>著作者／変更~制御者</dt>
	<dd>W3C</dd>

	<dt>仕様~文書</dt>
	<dd>
`Permissions Policy＠~TR/permissions-policy-1/$cite
【この仕様】
</dd>
</dl>

◎
Header field name
• Permissions-Policy
Applicable protocol
• http
Status
• standard
Author/Change controller
• W3C
Specification document
• Permissions Policy API
</div>

	</section>
	<section id="privacy-and-security">
<h2 title="Privacy and Security">12. ~privacyと~security</h2>

<p>
この仕様は、
埋込まれる~page上で施行することになる施策を設定するための仕組みを標準~化する。
`iframe^e 要素の `sandbox$aF 属性と類似に、
これは，埋込まれる~pageから許可が明示されなくとも行える。
それは、
すでに公表された~web~site内に存在している特能の挙動を変更できることを意味する
— 別の文書~内で、
それらの~pageを，適切な容器~施策を伴わせて埋込むことにより。
◎
This specification standardizes a mechanism for an embedding page to set a policy which will be enforced on an embedded page. Similar to iframe sandbox, this can be done without the express permission of the embedded page, which means that behaviors of existing features can be changed in published web sites, by embedding them in another document with an appropriate container policy.
</p>

<p>
そのようなわけで、
最も重大な
~privacy／~security
上の懸念は：
◎
As such, the biggest privacy and security concerns are:
</p>

<ul>
	<li>
非同一-生成元 下位frame内の挙動が，それを埋込んでいる側に公開されること
◎
Exposure of behavior in a cross-origin subframe to its embedder
</li>
	<li>
埋込んだ側が制御することによる、
下位frameにおける挙動の予想外の変化
◎
Unanticipated behavior changes in subframes controlled by the embedder
</li>
</ul>

<p>
これらの懸念は、
すでにある程度~web~platformに在る。
この仕様は、
少なくとも それを無用に悪化させないよう試みる。
◎
To a degree, these concerns are already present in the web platform, and this specification attempts to at least not make them needlessly worse.
</p>

<p>
個々の特能の設計も，~securityと~privacyの課題をもたらし得るので、
この仕様と統合するときには，~careされなければナラナイ。
この節は、
どの種類の挙動がそのような課題をもたらし得るかについて，いくつかの指導を供することを試みる。
◎
Security and privacy issues may also be caused by the design of individual features, so care must be taken when integrating with this specification. This section attempts to provide some guidance as to what kinds of behaviors could cause such issues.
</p>

		<section id="privacy-expose-behavior">
<h3 title="Exposure of cross-origin behavior">12.1. 埋込まれた非同一-生成元の挙動の公開</h3>

<p>
特能は、［
~frame化された文書における施策の`違反$は、
他の~frame内の文書からは観測-可能にならない
］ように，設計されるべきである。
一例として、
仮に，ある特能が［
施策により不能化されている下で利用されたときは、
当の~frameを埋込んでいる文書に向けて~eventを発火させる
］となると、
埋込まれた文書の状態についての情報を抽出することにも利用できることになる。
一例として，［
その特能は，利用者が~siteに~log-inしている間に限り利用される
］ことが既知である場合、
埋込んだ側は
— その特能を当の~frameに対し不能化した上で，結果の~eventを~listenすることにより —
利用者が~log-inしているかどうか決定することもできる。
◎
Features should be designed such that a violation of the policy in a framed document is not observable by documents in other frames. For instance, a hypothetical feature which caused a event to be fired in the embedding document if it is used while disabled by policy, could be used to extract information about the state of an embedded document. If the feature is known only to be used while a user is logged in to the site, for instance, then the embedder could disable that feature for the frame, and then listen for the resulting events to determine whether or not the user is logged in.
</p>

<p>
自己検分~APIは、［
下位frameの施策について、
埋込んでいる文書から，すでに演繹できる情報
］のみを示すように設計されている。
この`観測-可能な施策$は、
~frame化された文書に伴って送達された どの~HTTP~headerからも影響されない。
加えて、
~frame自身が他へ~navigateされても
— その先が，異なる施策が適用される異なる生成元であっても —
変化しない。
`観測-可能な施策$を更新させるのは、
`iframe^e 要素の `src$aF 属性を設定して生じる~naviに限られる。
◎
The introspection API is designed to only show information about a subframe’s policy which could already be deduced by the embedding document. This observable policy is not affected by any HTTP headers delivered with the framed document, and does not change when the frame navigates itself, even if such navigation is to a different origin, where a different policy applies. Only navigations caused by setting the src attribute of the &lt;iframe&gt; element will cause the observable policy to be updated.
</p>

		</section>
		<section id="privacy-alter-behavior">
<h3 title="Unanticipated behavior changes">12.2. 挙動の予想外の変化</h3>

<p>
許可~施策の仕組みは、［
ある下位frameが読込まれる時点で，［
その~frame内で，どの特能が可用になるか, ならないか
］を制御する能
］を，文書に是認する。
当の特能が，~web~platformに長期に存在していた挙動を表現しているならば、
このことは［
~web上に公表された既存の内容において，特定0の~APIが失敗し得る
］ことを意味する
（内容がそれを予期することなく書かれたならば）。
◎
The Permissions Policy mechanism grants a document the ability to control which features will and will not be availble in a subframe at the time it is loaded. When a feature represents an existing, long-standing behavior of the web platform, this may mean that existing published content on the web was not written with the expectation that a particular API could fail.
</p>

<div class="example">
<p>
（不自然だが）実用的な例として、［
利用者が~pageに~accessするに足る特権を有するかどうか
］を，同期的 `XMLHttpRequest$I を利用して決定している文書を考える：
◎
As a practical (though contrived) example, consider a document which uses synchronous XMLHttpRequest to determine whether a user has sufficient privileges to access the page:
</p>

<pre class="lang-html">
&lt;!DOCTYPE html&gt;
&lt;h1&gt;Welcome to SecureCorp!&lt;/h1&gt;
&lt;script&gt;
  var %req = new XMLHttpRequest();
  %req.open("GET", "/api/security_check.json", false);
  %req.send();
  if (%req.response == "untrusted user") {
	/* <span class="comment">
利用者は~log-inしていない
— 安全な~pageへ~redirectする
◎
User is not logged in; redirect to a safe page
</span> */
    location.href = "/security_check_failed.html";
  }
&lt;/script&gt;
&lt;!-- <span class="comment">
~pageは、
利用者が~log-inした前提の下で継続する
◎
Page continues with assumption that user is logged in
</span> --&gt;
</pre>

<p>
この文書がある~pageに埋込まれ，その~pageが `sync-xhr^l 特能を不能化した場合、
`XMLHttpRequest.open()^m の~callは失敗して，~security検査は迂回されることになる。
◎
If this document is embedded by a page which disables the "sync-xhr" feature, the call to XMLHttpRequest.open() would fail, and the security check would be bypassed.
</p>
</div>

<p>
~web上では、
この類の挙動の強制-法はすでにアリなことに注意。
特能には、
`iframe^e には許容されず，~top-level文書~内に限り許容されるものもある。
また， `iframe^e ~sandbox法は、
類似な仕方で，~frameを
— それが依存し得る特能に~accessすることなく —
埋込むときに利用できる。
◎
Note that this sort of behavior forcing is already possible on the web: some features are only allowed in top-level documents, and not in any iframes, and iframe sandboxing can be used in a similar way to embed a frame without access to features which it may be depending on.
</p>

<p>
一般に，この懸念を軽減するには、
2 つの仕方がある：
◎
In general, this concern is mitigated in two ways:
</p>

<ul>
	<li>
脆弱な~pageは、
`X-Frame-Options^h ~HTTP~headerを伴わせて ~serveできる
— そうすれば、
攻撃者が~frame化するのは許容されなくなるので。
◎
The vulnerable page may be served with an X-Frame-Options HTTP header which does not allow it to be framed by an attacker.
</li>
	<li>
~siteは、
~APIや挙動を利用しようと試みる前に，それが可用かどうかを特能~検出を利用して決定した上で、
~callした~APIから［
返された~error／投出された例外
］を取扱うべきである。
◎
Sites should use feature detection to determine whether an API or behavior is available before attempting to use it, and should handle any documented errors returned or exceptions thrown by the APIs they call.
</li>
	<li>
特能~検出がアリでない事例では、
新たな~web内容は［
`PermissionsPolicy$I ~objを利用して，現在~施行されている許可~施策を検分した上で、
それに則って挙動や~UIを調整する
］ように書ける。
◎
In the case where feature detection is not possible, new web content can be written to use the policy object to inspect the permissions policy which is currently enforced, and adjust behaviour or user interface accordingly.
</li>
</ul>

<p>
自身による特能を この仕様と統合している策定者は、［
当の特能が不能化されている下で，文書がそれを利用しようと試みたとき、
それが いつどのように失敗することになるか
］を裁定できる。
策定者は、
既存の失敗~mode【既存の例外~名など】が存在するならば，それを用立てようと試みるべきである
— そうすれば、
そのような失敗をすでに正しく取扱っている既存の内容への~~影響は抑えられるので。
◎
Authors integrating their features with Permissions Policy can decide when and how the feature will fail when a document attempts to use it while it is disabled. Authors should attempt to make use of existing failure modes, when they exist, to increase the chance that existing content will already be correctly handling such failures.
</p>

		</section>
		<section id="privacy-expose-policy">
<h3 title="Exposure of embedding policy">12.3. 埋込んでいる側の施策の公開</h3>

<p>
ある~pageが非同一-生成元~pageを埋込んでいるとき
— 埋込んだ側が，埋込まれた側の挙動について推定できる情報を制限するよう~careされていたとしても —
局面によっては、
埋込まれた側が，埋込んだ側の情報について推定することも
— ［
自身に対し，埋込んだ側が施行した施策
］を精査することにより —
アリになり得る。
◎
Care has been taken to limit the information which an page can infer about the behavior of cross-origin pages which it embeds. It may be possible in some scenarios however, for the embedded page to infer information about its embedder, by examining the policy which the embedder has enforced on it.
</p>

<p>
これは既存の `document.fullscreenEnabled$m に類似する。
それは、
埋込まれた側の文書が［
埋込んだ側は、
埋込まれた側に~Fullscreen~APIを利用する能を是認したかどうか
］を推定するために利用できる。
これが ある種の事例
— 一例として，利用者が埋込んだ側の~siteに~log-inしたとき —
に限り是認される場合、
埋込まれた側の~siteは，埋込んだ側の状態について何かを知り得るようになる。
◎
This is similar to the existing document.fullscreenEnabled property, which can be used by the embedded document to infer whether its embedder has granted it the ability to use the Fullscreen API. If this is only granted in certain cases — when the user is logged in to the embedding site, for instance — then the embedded site can learn something about the state of its embedder.
</p>
		</section>
	</section>
	<section id="change-log">
<h2 title="Change log">13. 変更~log</h2>

<dl>
	<dt id="changes-since-fpwd">
最初の公な草案からの変更点：
◎
13.1. Changes since FPWD
</dt>
	<dd>
文書が作成される前に 特能~施策を作成する新たな~algoを公開した。
（ `324$pull ）
◎
Expose new algorithms to create a Feature Policy before document is created. Link
</dd>
	<dd>
もはや必要でない~algoを除去した。
（ `325$pull ）
◎
Remove algorithms no longer needed. Link
</dd>
	<dd>
`同じ生成元~domain$の検査を`同一-生成元$のそれに変更した。
（ `326$pull ）
◎
Change same-origin-domain check to same-origin. Link
</dd>
	<dd>
~headerと属性の組合nにおける意味論を ~OR から ~AND に変更した。
（ `378$pull ）
◎
Change Header and attribute combination from OR to AND semantics. Link
</dd>
	<dd>
“特能~施策” を “許可~施策” に改称した。
（ `379$pull ）
◎
Rename to "Permissions Policy". Link
</dd>
	<dd>
`Permissions-Policy$h を有構造~headerとして定義した。
（ `383$pull ）
◎
Define "Permissions-Policy" as a structured header. Link
</dd>
	<dd>
編集上の修正点。
◎
Editorial fixes.
</dd>
	<dd>
`allowpaymentrequest^a 属性を除去した
— Payment Request API, HTML にて非推奨にされたことに因り。
（ `402$pull ）
◎
The allowpaymentrequest attribute was removed due to deprecation by Payment Request API and HTML. Link
</dd>
</dl>

	</section>
</main></div>