特色機能施策 — Feature Policy

4.1. 施策により制御される特色機能

`施策により制御される特色機能@ は、`特色機能~施策$を~~参照することにより，文書において［ 可能化-／不能化- ］できる［ ~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 feature policy.

注記： 簡潔にするため，この文書においては、施策により制御される特色機能は “特色機能” と略称されることが多い。 他が指示されない限り，用語 “特色機能” は`施策により制御される特色機能$を指す。 そのような特色機能を定義する他の仕様は、多義性を避けるため，長い方の用語を利用するべきである。 ◎ 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.

この仕様は、現時点では，文書~内に定義される特色機能しか対処していない。 これについて，~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 feature policies in Workers and Worklets as well.

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

各 `特色機能$には、`既定の許容list$がある — それは、次の 2 つを定義する ⇒＃ その特色機能は `~top-level閲覧文脈$に`属する文書$内で可用かどうか／ その特色機能への~accessは `入子の閲覧文脈$にはどう継承されるか ◎ Each policy-controlled feature has a default allowlist, which defines whether that feature is available in documents in top-level browsing contexts, and how access to that feature is inherited in nested browsing contexts.

`特色機能$のうち，~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.

注記： `施策により制御される特色機能$自体は、この~frameworkの一部を成すものではない。 現時点で定義されている規範的でない特色機能の~listは、この仕様とは別に， 姉妹~文書 にて保守されている。 ◎ 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.

4.2. 施策

`特色機能~施策@ は、次の~itemからなる`構造体$である ⇒＃ `継承した施策$, `宣言-済み施策$ ◎ A feature policy is a struct with the following items: • An inherited policy. • A declared policy.

4.3. 継承した施策

`継承した施策@ は、各 `特色機能$を［ ある施策 ~IN { `可能化される^i, `不能化される^i } ］に対応付ける`有順序~map$である。 ◎ An inherited policy is an ordered map from features to either "Enabled" or "Disabled".

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

4.4. 宣言-済み施策

`宣言-済み施策@ は、各 `特色機能$を ある`許容list$に対応付ける`有順序~map$である。 ◎ A declared policy is an ordered map from features to allowlists.

4.5. ~header施策

`~header施策@ は、文書に伴う~HTTP~headerを介して送達された`施策~指令$からなる~listである。 これは、文書の`特色機能~施策$の`宣言-済み施策$を形成する。 ◎ A header policy is a list of policy directives delivered via an HTTP header with a document. This forms the document’s feature policy’s declared policy.

4.6. 容器~施策

各`入子の閲覧文脈$は、`~header施策$に加えて， `容器~施策@ を持つ。 それは、`施策~指令$であり，空にもなり得る。 `容器~施策$は、`閲覧文脈~容器$上の属性により設定できる。 ◎ In addition to the header policy, each nested browsing context has a container policy, which is a policy directive, which may be empty. The container policy can set by attributes on the browsing context container.

`入子の閲覧文脈$用の`容器~施策$は、その文脈の中に読込まれる文書に`継承される施策$に波及する（`特色機能~用に継承される施策を定義する$を見よ）。 ◎ The container policy for a nested browsing context influences the inherited policy of any document loaded into that context. (See §10.9 Define an inherited policy for feature)

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

4.7. 施策~指令

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

`施策~指令$は、［ ~HTTP~header／~HTML属性 ］内では，`~ASCII直列化$pdとして表現される。 ◎ A policy directive is represented in HTTP headers and HTML attributes as its ASCII serialization.

4.8. 許容list

特色機能~施策 `許容list@ は、概念的には，いくつかの`生成元$からなる集合である。 `許容list$は、次のいずれかをとり得る： ◎ A feature policy allowlist is conceptually a set of origins. An allowlist may be either:

• あらゆる生成元を表現する，特別な値 "`*@P" 。 この仕様における `全~生成元@i は、この値を表す別名として利用される。 【 この別名は、表記的／意味的に明快にするために，この訳に導入している。】 ◎ The special value *, which represents every origin, or
• `生成元$たちが成す`有順序~集合$ ◎ An ordered set of origins

注記： ［ ~headerや属性 ］内の文字列による許容listの~text表現には、~keyword［ `'self'^l, `'src'^l, `'none'^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.

`許容listは生成元に合致する@ かどうか決定するときは、所与の ( `許容list$ %許容list, 生成元 %生成元 ) に対し，次の手続きを走らす： ◎ To determine whether an allowlist matches an origin origin, run these steps:

1. ~IF［ %許容list ~EQ `全~生成元$i ］ ⇒ ~RET ~T ◎ If the allowlist is the special value *, then return true.
2. %許容list 内の ~EACH( %~item ) に対し ⇒ ~IF［ ( %~item, %生成元 ) は`同じ生成元~domain$である ］ ⇒ ~RET ~T ◎ Otherwise, for each item in the allowlist: • If item is same origin-domain with origin, then return true.
3. ~RET ~F ◎ return false.

4.9. 既定の許容list

各 `特色機能$には、 `既定の許容list@ がある。 `既定の許容list$は、次を決定する ⇒＃ `~top-level閲覧文脈$内に宣言された施策は無い下で，所与の特色機能は文書において許容されるかどうか ／ 特色機能への~accessは自動的に`入子の閲覧文脈$に`属する文書$に移譲されるかどうか ◎ Every policy-controlled feature has a default allowlist. The default allowlist determines whether the feature is allowed in a document with no declared policy in a top-level browsing context, and also whether access to the feature is automatically delegated to documents in nested browsing contexts.

`特色機能$用の`既定の許容list$は、次のいずれかの値をとる： ◎ The default allowlist for a feature is one of these values:

`全~生成元$i

特色機能は、既定では，`~top-level閲覧文脈$に`属する文書$において許容されることに加え、許容されるときは， `入子の閲覧文脈$に`属する文書$においても既定で許容される。 ◎ The feature is allowed in documents in top-level browsing contexts by default, and when allowed, is allowed by default to documents in nested browsing contexts.

`'self'^l

特色機能は、既定では，`~top-level閲覧文脈$に`属する文書$において許容されることに加え、許容されるときは： `入子の閲覧文脈$に`属する文書$のうち，同じ生成元~domainのものにおいては既定で許容されるが、非同一生成元の文書においては，既定では許容されない。 ◎ The feature is allowed in documents in top-level browsing contexts by default, and when allowed, is allowed by default to same-origin domain documents in nested browsing contexts, but is disallowed by default in cross-origin documents in nested browsing contexts.

`'none'^l

特色機能は、既定では，`~top-level閲覧文脈$に`属する文書$において許容されないことに加え、`入子の閲覧文脈$に`属する文書$においても，既定では許容されない。 ◎ The feature is disallowed in documents in top-level browsing contexts by default, and is also disallowed by default to documents in nested browsing contexts.

5.1. ~ASCII直列化

`施策~指令$は［ ~HTTP~header／~HTML属性 ］内では、~ASCII~textとして表現される。 ◎ Policy Directives are represented in HTTP headers and in HTML attributes as ASCII text.

`serialized-feature-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 = `serialized-origin$P / "*" / "'self'" / "'src'" / "'none'"

`serialized-origin@P は、`生成元の直列化$である。 しかしながら，符号位置［ `0027^U (') ／ `0021^U (*) ／ `002C^U (,) ／ `003B^U (;) ］は、直列化~内に現れては~MUST_NOT — それらが要求される場合には、［ `%27^l ／ `%2A^l ／ `%2C^l ／ `%3B^l ］として~percent-符号化され~MUST。 ◎ serialized-origin is the serialization of an origin. However, the code points U+0027 ('), U+0021 (*), U+002C (,) and U+003B (;) MUST NOT appear in the serialization. If they are required, they must be percent-encoded as "%27", "%2A", "%2C" or "%3B", respectively.

注記： 文字列 `'self'^l は、許容list内の生成元として利用されても~MAY。 この仕方で利用されたときは、当の特色機能~施策を包含する文書の生成元を指すことになる。 ◎ 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 feature policy.

6.1. `Feature-Policy^h ~HTTP~header

［ ~clientにより施行されるべきである`特色機能~施策$ ］を（ ~serverから~clientへ ）通信するときには、~HTTP応答~内に `Feature-Policy@h ~headerを利用できる。 ◎ The `Feature-Policy` HTTP header field can be used in the response (server to client) to communicate the feature policy that should be enforced by the client.

この~headerの値は、 1 個~以上の［ `施策~指令$の`~ASCII直列化$pd ］からなる。 ◎ The header’s value is the §5.1 ASCII serialization of one or more policy directives:.

FeaturePolicy = `serialized-feature-policy$P *("," `serialized-feature-policy$P)

`Feature-Policy$h ~headerを受信した~UAは、 ~HTMLとの統合 に従って， 応答~施策を処理して `施行-$し~MUST。 ◎ When the user agent receives a `Feature-Policy` header field, it MUST process and enforce the serialized policy as described in §8.1 Integration with HTML.

6.2. `iframe^e 要素の `allow^a 属性

`iframe$e 要素の `allow$aF 属性は、`直列形の特色機能~施策$を包含する。 ◎ iframe elements have an "allow" attribute, which contains an ASCII-serialized policy directive.

この属性~内に挙げられた名前の特色機能~用の`許容list$は、空になることもある。 その事例では、当の許容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.

空でないときは、 `allow^aF 属性により，それを有する `iframe^e 要素が`入子にしている閲覧文脈$が構築されるときに，その`容器~施策$に［ 認識される各`特色機能$用の`許容list$ ］が追加されることになる。 ◎ When not empty, the "allow" attribute will result in adding an allowlist for each recognized feature to the nested browsing context's container policy, when it is constructed.

6.3. 旧来の特色機能を~supportする追加の属性

この仕様により制御される一部の`特色機能$に対しては、それ用の既存の属性が `iframe^e 要素~上に定義されている。 この仕様は、これらの属性を `iframe^e 要素~用に宣言された施策として動作するように定義し直す。 ◎ Some features controlled by Feature Policy have existing iframe attributes defined. This specification redefines these attributes to act as declared policies for the iframe element.

8.1. ~HTMLとの統合

【† この訳では、原文をさらに簡約して，該当する変更点とその参照先を挙げるにとどめる（原文の “引用” による記述は、~HTML仕様の更新に伴い，次第に乖離していくと予想されるので）。 】

1. `文書$用の`特色機能~施策$は、各 `文書$の`特色機能~施策$doc（初期~時は空）を設定することにより， `施行-@ されることになる。 【具体的には、次項に挙げる~algo, および`特色機能~施策~属性を処理する$ことを通して。】 ◎ Document objects have a Feature Policy, which is initially empty. ◎ ↓
2. 次に挙げる~algoは改変された ⇒＃ `新たな閲覧文脈を作成する$／ `文書を初期化する$／ 特色機能の`利用は許容される$かどうかを決定する ◎ Replace the existing step 12 of "Create a new browsing context" with with the following step: • Execute the Initialize document’s Feature Policy algorithm on the Document object. ◎ Replace the existing step 8 of "Initialising a new Document object" with the following step: • Execute the Initialize document’s Feature Policy from response algorithm on the Document object and the response used to generate the document. ◎ A feature policy is enforced for a Document by setting it as the Document's Feature Policy. ◎ The "allowed to use" algorithm is replaced with the following: • 以下略
3. `iframe$e 要素に `allow$aF 属性が追加された。 ◎ The allow attribute is added to the IDL for the iframe element, with the description: • 以下略
4. `allowfullscreen$aF, `allowpaymentrequest$aF, `allowusermedia$aF 属性の挙動は変更された。 ◎ The description of the behavior of the allowfullscreen, allowpaymentrequest and allowusermedia attributes is changed to refer to this specification: • 以下略
5. もはや参照されなくなった “`set the allow* flags^en” ~algoは除去された。 ◎ The set the allow* flags algorithm is removed, as it is no longer referenced.

10.1. 応答~施策を処理する

この~algoは、所与の ( `応答$ %応答, `生成元$ %生成元 ) に対し，`宣言-済み施策$を返す： ◎ Given a response (response) and an origin (origin), this algorithm returns a declared feature policy.

1. ~IF［ %応答 の`~header~list$rs内に `Feature-Policy^h を`名前に持つ~header$は無い ］ ⇒ ~RET ◎ Abort these steps if the response’s header list does not contain a header whose name is "Feature-Policy".
2. %~header値 ~LET %応答 の`~header~list$rs内の `Feature-Policy^h に対する`結合-済みの値$hd ◎ Let header be the concatenation of the values of all header fields in response’s header list whose name is "Feature-Policy", separated by U+002C (,) (according to [RFC7230, 3.2.2]).
3. %特色機能~施策 ~LET `値と生成元から~headerを構文解析する$( %~header値, %生成元 ) ◎ Let feature policy be the result of executing §10.2 Parse header from value and origin on header and origin.
4. ~RET %特色機能~施策 ◎ Return feature policy.

10.2. %値 と %生成元 から~headerを構文解析する

この~algoは、所与の ( 文字列 %値, `生成元$ %生成元 ) に対し，`宣言-済み施策$を返す： ◎ Given a string (value) and an origin (origin) this algorithm will return a declared feature policy.

1. %施策 ~LET 新たな`有順序~map$ ◎ Let policy be an empty ordered map.

2. `~commaで分割する$( %値 ) の結果を成す ~EACH( %要素 ) に対し： ◎ For each element returned by splitting value on commas:

   1. %指令 ~LET `値と生成元から施策~指令を構文解析する$( %要素, %生成元 ) ◎ Let directive be the result of executing §10.3 Parse policy directive from value and origin on element and origin
   2. `指令を宣言-済み施策に併合する$( %指令, %施策 ) ◎ Run §10.4 Merge directive with declared policy on directive and policy.
3. ~RET %施策 ◎ Return policy.

10.3. %値 と %生成元 から施策~指令を構文解析する

この~algoは、所与の ( 文字列 %値, `生成元$ %生成元 ) に対し，`施策~指令$を返す： ◎ Given a string (value) and an origin (origin) this algorithm will return a policy directive.

1. %指令 ~LET 新たな`有順序~map$ ◎ Let directive be an empty ordered map.

2. `区切子で厳密に分割する$( %値, `003B^U (;) ) の結果を成す ~EACH( %直列形の宣言 ) に対し： ◎ For each serialized-declaration returned by strictly splitting value on the delimiter U+003B (;):

   1. %~token~list ~LET `~ASCII空白で分割する$( %直列形の宣言 ) ◎ Let tokens be the result of splitting serialized-declaration on ASCII whitespace.
   2. ~IF［ %~token~list は空である ］ ⇒ ~CONTINUE ◎ If tokens is an empty list, then continue.
   3. %特色機能~名 ~LET %~token~list[0] ◎ Let feature-name be the first element of tokens.
   4. %特色機能 ~LET %特色機能~名 により識別される`~support済み特色機能$が［ 在るならば それ ／ 無いならば ε ］ ◎ If feature-name does not identify any recognized policy-controlled feature, then continue.
   5. ~IF［ %特色機能 ~EQ ε ］ ⇒ ~CONTINUE ◎ Let feature be the policy-controlled feature identified by feature-name.
   6. %~target~list ~LET %~token~list から最初の~itemを除去して得られる~list ◎ Let targetlist be the remaining elements, if any, of tokens.
   7. %許容list ~LET `全~生成元$i ◎ ↓

   8. ~IF［ `全~生成元$i ~NIN %~target~list ］ ◎ Let allowlist be a new allowlist. ◎ If any element of targetlist is the string "*", set allowlist to the special value *. ◎ Otherwise:

      1. %許容list ~SET 新たな`有順序~集合$ ◎ Set allowlist to an new ordered set.

      2. %~target~list 内の ~EACH( %~target ) に対し： ◎ For each element in targetlist:

         1. ~IF［ %~target は 文字列 `'self'^l に`~ASCII大小無視$で合致しない ］ ⇒ %~target ~SET %生成元 ◎ If element is an ASCII case-insensitive match for the string "'self'", let result be origin.

         2. ~ELSE：

            1. %~target ~LET `~URL構文解析する$( %~target ) ◎ Otherwise, let result be the result of executing the URL parser on element.
            2. ~IF［ %~target ~EQ `失敗^i ］ ⇒ ~CONTINUE ◎ If result is not failure:
            3. %~target ~SET %~target の`生成元$url ◎ Let target be the origin of result.
         3. ~IF［ %~target は`不透明な生成元$でない ］ ⇒ %許容list に %~target を付加する ◎ If target is not an opaque origin, append target to allowlist.
   9. %指令[ %特色機能 ] ~SET %許容list ◎ Set directive[feature] to allowlist.
3. ~RET %指令 ◎ Return directive

10.4. 指令を宣言-済み施策に併合する

この~algoは、所与の ( 施策~指令 %指令, `宣言-済み施策$ %施策 ) に対し，新たな指令を織り込むように %施策 を改変する： ◎ Given a policy directive (directive) and a declared policy (policy), this algorithm will modify policy to account for the new directive.

1. %指令 を成す ~EACH( %特色機能 → %許容list ) に対し： ◎ For each feature → allowlist of directive:

   1. ~IF［ %施策[ %特色機能 ] ~EQ ε ］ ⇒ %施策[ %特色機能 ] ~SET %許容list ◎ If policy does not contain an allowlist for feature, then set policy[feature] to allowlist.

10.5. 特色機能~施策~属性を処理する

この~algoは、所与の ( 要素 %要素 ) に対し，`容器~施策$を返す（空にもなり得る）： ◎ Given an element (element), this algorithm returns a container policy, which may be empty.

1. %施策 ~LET 新たな`施策~指令$ ◎ Let policy be a new policy directive.
2. %容器~施策 ~LET `allow^a 属性を構文解析する( %要素 の `allow$aF 属性の値, %要素 の`~node文書$の生成元, %要素 に`宣言された生成元$ ) ◎ Let container policy be the result of running Parse allow attribute on the value of element’s allow attribute, with container origin set to the origin of element’s node document, and target origin set to element’s declared origin.
3. ~IF［ %要素 は `iframe$e 要素でない ］ ⇒ ~RET %容器~施策 【 `allow^a 属性が定義されているのは `iframe^e しかないので、この記述はおかしい。】 ◎ If element is an iframe element:
4. ~IF［ %要素 は `allowfullscreen$aF 属性を有する ］~AND［ %容器~施策[ `fullscreen^ft ] ~EQ ε ］ ⇒ %容器~施策[ `fullscreen^ft ] ~SET `全~生成元$i ◎ If element’s allowfullscreen attribute is specified, and container policy does not contain an allowlist for fullscreen, • Construct a new declaration for fullscreen, whose allowlist is the special value *. • Add declaration to container policy.
5. ~IF［ %要素 は `allowpaymentrequest$aF 属性を有する ］~AND［ %容器~施策[ `payment^ft ] ~EQ ε ］ ⇒＃ %容器~施策[ `payment^ft ] ~SET `全~生成元$i ◎ If element’s allowpaymentrequest attribute is specified, and container policy does not contain an allowlist for payment, • Construct a new declaration for payment, whose allowlist is the special value *. • Add declaration to container policy.

6. ~IF［ %要素 は `allowusermedia$aF 属性を有する 【原文の `allowusermediarequest^a は誤記であろう】 ］ ⇒ ◎ If element’s allowusermediarequest attribute is specified:

   1. ~IF［ %容器~施策[ `camera^ft ] ~EQ ε ］ ⇒ %施策[ `camera^ft ]† ~SET `全~生成元$i ◎ If container policy does not contain an allowlist for camera, • Construct a new declaration for camera, whose allowlist is the special value *. • Add declaration to policy.
   2. ~IF［ %施策[ `microphone^ft ]† ~EQ ε ］ ⇒ %容器~施策[ `microphone^ft ] ~SET `全~生成元$i ◎ If policy does not contain an allowlist for microphone, • Construct a new declaration for microphone, allowlist is the special value *. • Add declaration to container policy.
   【† おそらく、 %施策 ではなく， %容器~施策 （したがって最初の段も不要）】
7. ~RET %容器~施策 ◎ Return container policy.

10.6. `allow^a 属性を構文解析する

この~algoは、所与の ( 文字列 %値, 生成元 %容器~生成元, 生成元 %~target生成元 ) に対し，`施策~指令$を返す： ◎ Given a string (value), and two origins (container origin and target origin), this algorithm returns a policy directive.

1. %指令 ~LET 新たな`有順序~map$ ◎ Let directive be an empty ordered map.

2. `区切子で厳密に分割する$( %値, `003B^U (;) ) の結果を成す ~EACH( %直列形の宣言 ) に対し： ◎ For each serialized-declaration returned by strictly splitting value on the delimiter U+003B (;):

   1. %~token~list ~LET `~ASCII空白で分割する$( %直列形の宣言 ) ◎ Let tokens be the result of splitting serialized-declaration on ASCII whitespace.
   2. ~IF［ %~token~list は空である ］ ⇒ ~CONTINUE ◎ If tokens is an empty list, then continue.
   3. %特色機能~名 ~LET %~token~list[0] ◎ Let feature-name be the first element of tokens.
   4. %特色機能 ~LET %特色機能~名 により識別される`~support済み特色機能$が［ 在るならば それ ／ 無いならば ε ］ ◎ If feature-name does not identify any recognized policy-controlled feature, then continue.
   5. ~IF［ %特色機能 ~EQ ε ］ ⇒ ~CONTINUE ◎ Let feature be the policy-controlled feature identified by feature-name.
   6. %~target~list ~LET %~token~list から最初の~itemを除去して得られる~list ◎ Let targetlist be the remaining elements, if any, of tokens.
   7. %許容list ~LET 新たな`許容list$ ◎ Let allowlist be a new allowlist.
   8. ~IF［ `全~生成元$i ~IN %~target~list ］ ⇒ %許容list ~SET `全~生成元$i ◎ If any element of targetlist is the string "*", set allowlist to the special value *.

   9. ~ELSE： ◎ Otherwise:

      1. %許容list ~SET 新たな `有順序~集合$ ◎ Set allowlist to an new ordered set.
      2. ~IF［ %~target~list は空である ］ ⇒ %許容list に %~target生成元 を付加する ◎ If targetlist is empty, append target origin to allowlist.

      3. %~target~list を成す ~EACH( %~target ) に対し： ◎ For each element in targetlist:

         1. ~IF［ %~target は`~ASCII大小無視$で `'self'^l に合致する ］ ⇒ %~target ~SET %容器~生成元 ◎ If element is an ASCII case-insensitive match for "'self'", let result be container origin.
         2. ~ELIF［ %~target は`~ASCII大小無視$で `'src'^l に合致する ］ ⇒ %~target ~SET %~target生成元 ◎ If element is an ASCII case-insensitive match for "'src'", let result be target origin.

         3. ~ELSE：

            1. %~target ~LET `~URL構文解析する$( %~target ) ◎ Otherwise, let result be the result of executing the URL parser on element.
            2. ~IF［ %~target ~EQ `失敗^i ］ ⇒ ~CONTINUE ◎ If result is not failure:
            3. %~target ~SET %~target の`生成元$url ◎ Let target be the origin of result.
         4. ~IF［ %~target は`不透明な生成元$でない ］ ⇒ %許容list に %~target を付加する ◎ If target is not an opaque origin, append target to allowlist.
   10. %指令[ %特色機能 ] ~SET %許容list ◎ Set directive[feature] to allowlist.
3. ~RET %指令 ◎ Return directive

10.7. %文書 の特色機能~施策を初期化する

この~algoは、所与の ( `文書$ %文書 ) に対し， %文書 の`特色機能~施策$docを初期化する： ◎ Given a Document object (document), this algorithm initialises document’s Feature Policy

1. %継承した施策 ~LET 新たな`有順序~map$ ◎ Let inherited policy be a new ordered map.
2. %宣言-済み施策 ~LET 新たな`有順序~map$ ◎ Let declared policy be a new ordered map.
3. ~EACH( `~support済み特色機能$ %特色機能 ) に対し ⇒ %継承した施策[ %特色機能 ] ~SET ~LET `特色機能~用に継承される施策を定義する$( %特色機能, %文書 が`属する閲覧文脈$ ) ◎ For each feature supported, • Let isInherited be the result of running §10.9 Define an inherited policy for feature on feature and document’s browsing context. • Set inherited policy[feature] to isInherited.
4. %施策 ~LET 次のようにされた新たな`特色機能~施策$ ⇒＃ `継承した施策$ ~SET %継承した施策, `宣言-済み施策$ ~SET %宣言-済み施策 ◎ Let policy be a new feature policy, with inherited policy inherited policy and declared policy declared policy.
5. %文書 の`特色機能~施策$doc ~SET %施策 （すなわち、 %施策 を`施行する$） ◎ Enforce the policy policy on document.

10.8. %応答 からの特色機能~施策で %文書 のそれを初期化する

この~algoは、所与の ( `応答$ %応答, `文書$ %文書 ) に対し， %文書 の`特色機能~施策$を拡充する： ◎ Given a response (response) and a Document (document), this algorithm populates document’s Feature Policy

1. %文書 の`特色機能~施策を初期化する$ ◎ Initialize document’s Feature Policy
2. %継承した施策 ~LET %文書 の特色機能~施策が`継承した施策$ ◎ Let inherited policy be document’s Feature Policy’s inherited policy.
3. %宣言-済み施策 ~LET 新たな`有順序~map$ ◎ Let declared policy be a new ordered map.
4. %施策~指令 ~LET `応答~施策を処理する$( %応答, %文書 の生成元 ) ◎ Let d be the result of running Process response policy on response and document’s origin.
5. %施策~指令 を成す ~EACH( %特色機能 → %許容list ) に対し ⇒ ~IF［ %継承した施策[ %特色機能 ] ~EQ ~T ］ ⇒ %宣言-済み施策[ %特色機能 ] ~SET %許容list ◎ For each feature → allowlist of d: • If inherited policy[feature] is true, then set declared policy[feature] to allowlist.
6. %施策 ~LET 次のようにされた新たな`特色機能~施策$ ⇒＃ `継承した施策$ ~SET %継承した施策, `宣言-済み施策$ ~SET %宣言-済み施策 ◎ Let policy be a new feature policy, with inherited policy inherited policy and declared policy declared policy.
7. %文書 上で施策 %施策 を`施行する$ ◎ Enforce the policy policy on document.

10.9. %特色機能 用に継承される施策を定義する

この~algoは、所与の ( `特色機能$ %特色機能, `閲覧文脈$ %文脈 ) に対し， %文脈 が %特色機能 用に`継承した施策$を返す： ◎ Given a feature (feature) and a browsing context (context), this algorithm returns the inherited policy for that feature.

1. ~IF［ %文脈 は`入子の閲覧文脈$である ］ ⇒ ~RET `容器~内の特色機能~用に継承される施策を定義する$( %特色機能, %文脈 の`閲覧文脈~容器$ ) ◎ If context is a nested browsing context, return the result of executing §10.10 Define an inherited policy for feature in container on context’s browsing context container.
2. ~RET `可能化される^i ◎ Otherwise, return 'Enabled'.

10.10. %容器 内の %特色機能 用に継承される施策を定義する

この~algoは、所与の ( `特色機能$ %特色機能, `閲覧文脈~容器$ %容器 ) に対し， %容器 が %特色機能 用に`継承した施策$を返す： ◎ Given a feature (feature) and a browsing context container (container), this algorithm returns the inherited policy for that feature.

1. %親 ~LET %容器 の`~node文書$ ◎ Let parent be container’s node document.
2. %生成元 ~LET %親 の`生成元$ ◎ Let origin be parent’s origin
3. %容器~施策 ~LET `特色機能~施策~属性を処理する$( %容器 ) ◎ Let container policy be the result of running §10.5 Process feature policy attributes on container.

4. ~IF［ %容器~施策[ %特色機能 ] ~NEQ ε ］： ◎ If feature is a key in container policy:

   1. ~IF［ `許容listは生成元に合致する$( %容器~施策[ %特色機能 ], %生成元 ) ］~AND［ %親 が`継承した施策$[ %特色機能 ] ~EQ `可能化される^i ］ ⇒ ~RET `可能化される^i ◎ If the allowlist for feature in container policy matches origin, and parent’s inherited policy for feature is "Enabled", return "Enabled".
   2. ~RET `不能化される^i ◎ Otherwise return "Disabled".
5. ~RET `特色機能は施策により生成元~用に可能化されるか？$( %特色機能, %親, %生成元 ) ◎ Otherwise, if feature is enabled in parent for origin, return "Enabled". ◎ Otherwise return "Disabled".

10.11. %文書 内の %特色機能 は %生成元 用に可能化されるか？

この~algoは、所与の ( 特色機能 %特色機能, `文書$ %文書, `生成元$ %生成元 ) に対し，［ %特色機能 は不能化されるべきと見なされるならば `不能化される^i ／ ~ELSE_ `可能化される^i ］を返す： ◎ Given a feature (feature), a Document object (document), and an origin (origin), this algorithm returns "Disabled" if feature should be considered disabled, and "Enabled" otherwise.

1. %施策 ~LET %文書 の`特色機能~施策$ ◎ Let policy be document’s Feature Policy
2. ~IF［ %施策 が`継承した施策$[ %特色機能 ] ~EQ `不能化される^i ］ ⇒ ~RET `不能化される^i ◎ If policy’s inherited policy for feature is Disabled, return "Disabled".

3. ~IF［ %施策 の`宣言-済み施策$[ %特色機能 ] ~NEQ ε ］： ◎ If feature is present in policy’s declared policy:

   1. ~IF［ `許容listは生成元に合致する$( %施策 の`宣言-済み施策$[ %特色機能 ], %生成元 ) ］ ⇒ ~RET `可能化される^i ◎ If the allowlist for feature in policy’s declared policy matches origin, then return "Enabled".
   2. ~RET `不能化される^i ◎ Otherwise return "Disabled".
4. ~IF［ %特色機能 の`既定の許容list$ ~EQ `全~生成元$i ］ ⇒ ~RET `可能化される^i ◎ If feature’s default allowlist is *, return "Enabled".
5. ~IF［ %特色機能 の`既定の許容list$ ~EQ `'self'^l ］~AND［ ( %生成元, %文書 の生成元 ) は`同じ生成元~domain$である ］ ⇒ ~RET `可能化される^i ◎ If feature’s default allowlist is 'self', and origin is same origin-domain with document’s origin, return "Enabled".
6. ~RET `不能化される^i ◎ Return "Disabled".

10.12. %設定群 上で %特色機能~施策 の違反~用に %~message を伴う報告を生成する

この~algoは、所与の ( `特色機能$ %特色機能, 文字列 %~message, `環境~設定群~obj$ %設定群, 文字列 %~group （省略時は `default^l ） ) に対し，［ %特色機能 に対する施策の`違反$についての %~message ］を包含する`報告$を生成する： ◎ Given a feature (feature), a string (message), an environment settings object (settings), and an optional string (group), this algorithm generates a report, containing message, about the violation of the policy on feature.

1. %本体 ~LET 次のように初期化された新たな `FeaturePolicyViolationReportBody$I ⇒＃ `featureId$m ~SET %特色機能 の文字列~表現, `message$m ~SET %~message, `sourceFile$m ~SET ~NULL, `lineNumber$m ~SET ~NULL, `columnNumber$m ~SET ~NULL, `disposition$m ~SET `enforce^l ◎ Let body be a new FeaturePolicyViolationReportBody, initialized as follows: ◎ featureId • feature’s string representation. message • message sourceFile • null lineNumber • null columnNumber • null disposition • "enforce"
2. ~IF［ ~UAは現在~scriptを実行している ］~AND［ %設定群 から~source~fileの［ ~URL, 行番号, 列番号 ］を抽出できる† ］ ⇒ それに則って， %本体 の［ `sourceFile$m, `lineNumber$m, `columnNumber$m ］を設定する 【† ~URLのみ抽出できる場合もあるかもしれない。その場合、 `sourceFile^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.
3. `報告先~group用に~dataを~queueする$( %本体, `feature-policy-violation^l, %~group, %設定群 ) ◎ ↑↑If group is omitted, set group to "default". ◎ Execute Reporting API §#queue-report with body, "feature-policy-violation", group, and settings.

注記： 特色機能~施策が`違反-$されたときには、この~algoが~callされるべきである。 ◎ Note: This algorithm should be called when a feature policy has been violated.

12.1. 埋込まれた非同一生成元の挙動の公開

特色機能は、［ ~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.

自己検分~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 <iframe> element will cause the observable policy to be updated.

12.2. 挙動の予想外の変化

特色機能~施策は、［ ある下位frameが読込まれる時点で，［ その~frame内で，どの特色機能が可用になるか, ならないか ］を制御する能 ］を，文書に是認する。 当の特色機能が，~web~platformに長期に存在していた挙動を表現しているならば、このことは［ ~web上に公表された既存の内容において，特定0の~APIが失敗し得る ］ことを意味する（内容がそれを予期することなく書かれたならば）。 ◎ Feature policy 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.

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

~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.

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

• 脆弱な頁は、 `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.
• ~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.
• 特色機能~検出がアリでない事例では、新たな~web内容は［ `Policy$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 feature policy which is currently enforced, and adjust behaviour or user interface accordingly.

自身による特色機能を この仕様と統合している策定者は、［ 当の特色機能が不能化されている下で，文書がそれを利用しようと試みたとき、それが いつどのように失敗することになるか ］を裁定できる。 策定者は、既存の失敗~mode【既存の例外~名など】が存在するならば，それを用立てようと試みるべきである — そうすれば、そのような失敗をすでに正しく取扱っている既存の内容への~~影響は抑えられるので。 ◎ Authors integrating their features with Feature 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.

12.3. 埋込んでいる側の施策の公開

ある頁が非同一生成元~頁を埋込んでいるとき — 埋込んだ側が，埋込まれた側の挙動について推定できる情報を制限するよう~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.

これは既存の `document.fullscreenEnabled$m に類似する。 それは、埋込まれた側の文書が［ 埋込んだ側は、埋込まれた側に `FULLSCREEN$r ~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.