非保安的要請の昇格 — Upgrade Insecure Requests

1.1. 目標

包括的な目標は、［ 混在~内容の阻止-法 `MIX$r による負の副作用を抑制する ］ことにより，~siteを非保安的~生成元から移行する際の負担を抑制することである。 ◎ The overarching goal is to reduce the burden of migrating websites from insecure origins by reducing the negative side effects of mixed content blocking [MIX].

作者が［ ~server側で準備作業を済ませておくこと（ 証明書を得る ／ ~serverを環境設定する ／ ~redirectを設定しておく ）］，および［［ 当事者主体, 第三者主体 ］の両~内容とも，保安的`~scheme$url上の 【非保安的~scheme上のそれと】 同じ ( `~host$url, `~path$url ) 組 で~access可能になること ］を確保することを前提に，この特色機能が実装されたならば、次が成立するベキである： ◎ If we assume that authors do the server-side legwork (obtaining a certificate, configuring the server, setting up redirects), and that authors also ensure that both first- and third-party content is accessible at the same host and path on a secure scheme, then the following statements ought to hold after implementing this feature:

1. 作者は、所与の~pageから要請されるすべての内容が，成功裡かつ保安的に読込まれることを確保できるべきである。 混在~内容を阻止して保安的~生成元へ移行した結果，~pageが壊されるべきでない。 ◎ Authors should be able to ensure that all content requested by a given page loads successfully, and securely. Mixed content blocking should not break pages as a result of migrating to a secure origin.

   注記： 混在内容の`厳格~mode$は、この要件を満たさない — それが表明するのは、逆の性格の様な何かである。 ◎ Note: This requirement is not met by Mixed Content’s strict mode, which makes something like the opposite assertion.

2. ~UAは、前項の結果として、要請している混在~内容に関係するどの保安~指示子も格下げするべきでない — どのような非保安的~内容も要請されないべきである。 ◎ As a result of #1, the user agent should not degrade any security indicators related to requesting mixed content, as no insecure content should be requested.
3. 作者は、すべての内部~linkが，利用者にとって ~siteの保安的~addressへ — 移行前の非保安的~addressではなく — 正しく送信されることを確保できるべきである。 ◎ Authors should be able to ensure that all internal links correctly send users to the site’s secure address, and not to its pre-migration insecure address.
4. 作者は、~siteの内容を編集せずに，以上の目標すべてを達成できるべきである。 このことは、保守管理が~~相応に困難で, 昇格など全く~~想定されてない，~archiveされた内容や旧来の~systemにとり、特に重要である。 ◎ Authors should be able to achieve all these goals without editing a site’s content. This is particularly important for archived content and legacy systems for which maintenance is difficult enough, never mind upgrades.
5. 作者は、`昇格の仕組み$を~supportする~clientには保安的~資源を~serveしつつ，~supportしない~clientに対しても非保安的~資源を~serveし続けることで、非保安的から保安的への移行0を，~~継続的に行えるべきである。 ◎ Authors should be able to pursue a gradual transition from insecure to secure, serving secure resources to clients that support upgrades, while retaining insecure resources for clients that don’t.

注記： ここに定義される`昇格の仕組み$は、 Strict Transport Security `RFC6797$r に取代わることを意図するものではない。 詳細は、~HSTSとの関係節を見よ。 ◎ Note: The mechanism defined here does not intend to supplant Strict Transport Security [RFC6797]. See §8.2 Relation to HSTS for details.

1.2. 各種~例

`Content-Security-Policy$h: `upgrade-insecure-requests$dir

<img src="http://example.com/image.png">
<img src="http://not-example.com/image.png">

<img src="https://example.com/image.png">
<img src="https://not-example.com/image.png">

`Content-Security-Policy$h: `upgrade-insecure-requests$dir

<a href="http://example.com/">Home</a>

<a href="https://example.com/">Home</a>

<a href="http://not-example.com/">Home</a>

<img src="http://cdn.example.com/image.png">

1.3. 各種~推奨

作者【~server運用者】 には、`昇格の仕組み$を~supportする~UAが，可能な限り保安的になるよう確保したいと望むなら，次を行うことを推奨する： ◎ We recommend that authors who wish to ensure that user agents which support upgrade-insecure-requests are as secure as possible do the following:

1. 非保安的かつ`安全に昇格-可能$な要請に対しては、~status~code `307^st を伴う `Location$h ~headerで応答することにより，~HTTPから~HTTPSへ~redirectする。 ◎ Redirect insecure, safely upgradable requests from HTTP to HTTPS by responding with a Location header and a 307 status code.

   ~Nginxにおいては、この種の~redirectionは，次の様になるであろう： ◎ In Nginx, this kind of redirection might look like this:

   server {
     if ($http_upgrade_insecure_requests = "1") {
       add_header Vary Upgrade-Insecure-Requests;
       return 307 https://$host$request_uri;
     }
   }
   

   無論これは，ごく単純化されており、~~実際の環境設定はずっと複雑になるであろう。 ◎ This is, of course, greatly simplified; your configuration will likely be significantly more complex.

2. `先天的に認証-済み$かつ`安全に昇格-可能$な要請に対しては、要請されている資源に必要とされるなら， `upgrade-insecure-requests$dir 指令を伴わせて応答する。 ◎ Respond to a priori authenticated safely upgradable requests with a upgrade-insecure-requests directive if necessary for the resource being requested.

   ~Nginxにてこの指令を追加するときは、次の様になるであろう: ◎ In Nginx, adding this directive might look like this:

   server {
     ...
   
     add_header `Content-Security-Policy$h `upgrade-insecure-requests$dir;
   
     ...
   }
   
   

   無論これは，ごく単純化されており、~~実際の環境設定はずっと複雑になるであろう。 ◎ This is, of course, greatly simplified; your configuration will likely be significantly more complex.

3. 生成元が`~HSTS安全$である場合、~SSL-stripping中間者~攻撃に抗して保護するため、 `preload^dir 指令を伴う `Strict-Transport-Security$h ~headerを送信して，混在内容の`厳格~mode$を可能化することにより，非保安的~内容は決して読込まれないことを確保する。 ◎ If the origin is HSTS-safe, then protect against SSL-stripping man-in-the-middle attacks by sending a Strict-Transport-Security header with the preload directive, and ensure that insecure content is never loaded by enabling Mixed Content’s strict mode.

   ~Nginxにてこの~headerを追加するときは、次の様になるであろう（ `preload^dir 指令の利用は、この生成元の~HSTS状態を通達し，~UAの HSTS Preload Lists に安全に取込まれることに注意）: ◎ In Nginx, adding this header might look like this (note the use of the preloaded directive, which signifies that this origin’s HSTS state can be safely imported into user agents' HSTS preload lists):

   server {
     ...
     
     add_header `Strict-Transport-Security$h "max-age=10886400; preload"
     add_header `Content-Security-Policy$h `block-all-mixed-content$dir;
   
     ...
   }
   

   無論これは，ごく単純化されており、~~実際の環境設定はずっと複雑になるであろう。 ◎ This is, of course, greatly simplified; your configuration will likely be significantly more complex.

   加えて、~UA~vendorたちと協働する — 当の生成元を HSTS Preload Lists に追加することを通して（例えば、当の生成元を hstspreload.appspot.com まで届出ることにより）。 ◎ Additionally, work with user agent vendors to add the origin to HSTS Preload Lists (for example, by submitting the origin to hstspreload.appspot.com).

4. 生成元が`条件付きで~HSTS安全$の場合、`安全に昇格-可能$な要請のみに呼応して~HSTSを~opt-intoする。 ◎ If the origin is conditionally HSTS-safe, then opt-into HSTS only in response to safely upgradable requests.

   ~Nginxにて この~headerを条件付きに追加するときは、次の様になるであろう（ note the use of `map^c, as setting headers inside `if^c without returning immediately is, well, iffy 【~Nginxには不詳なので，原文のままにしておく】 ）： ◎ In Nginx, adding this header conditionally might look like this (note the use of map, as setting headers inside if without returning immediately is, well, iffy):

   server {
     ...
   
     map $http_https $sts {
       "1" "max-age=10886400"
     }
     
     add_header `Strict-Transport-Security$h $sts;
   
     ...
   }
   

   無論これは，ごく単純化されており、~~実際の環境設定はずっと複雑になるであろう。 ◎ This is, of course, greatly simplified; your configuration will likely be significantly more complex.

【この訳に固有の表記規約】

この訳の，~algoや定義の記述に利用されている各種記号（ ~LET, ~IF, ~RET, 等々）の意味や定義の詳細は、~SYMBOL_DEF_REFを~~参照されたし。

3.1. `upgrade-insecure-requests^dir ~CSP指令

~serverは、［ `upgrade-insecure-requests@dir 指令を包含する `Content-Security-Policy$h ~header `CSP$r ］を送信することにより，［ 特定0の`被保護~資源$に対する非保安的~要請 ］を昇格するよう，~UAに指図して~MAY。 この指令は、次の `ABNF$r 文法で定義される： ◎ A server MAY instruct a user agent to upgrade insecure requests for a particular protected resource by sending a Content-Security-Policy header [CSP] that contains a upgrade-insecure-requests directive, defined via the following ABNF grammar:

`directive-name$P  = "upgrade-insecure-requests"
`directive-value$P = ""

`upgrade-insecure-requests^dir 指令を`施行-$するときは： ◎ When enforcing the upgrade-insecure-requests directive:

1. %設定群 ~LET `被保護~資源$の`現任の設定群~obj$ ◎ Let settings be the protected resource’s incumbent settings object.
2. %設定群 の`非保安的~要請~施策$ ~SET `昇格可$i ◎ Set settings’s insecure requests policy to Upgrade.
3. %組 ~LET `被保護~資源$の`~URL$の ( `~host$url, `~port$url ) 組 ◎ Let tuple be a tuple of the protected resource’s URL's host and port.
4. %組 を %設定群 の`非保安的~navi昇格~集合$に挿入する ◎ Insert tuple into settings’s upgrade insecure navigations set.

`Content-Security-Policy-Report-Only$h: default-src https:; report-uri /endpoint

3.2. ~clientの昇格-能力についての特色機能の検出-法

［ 保安的への移行0越しに，利用者に適度な体験を供する ］ために，`昇格の仕組み$を要する~siteは、何らかの仕方で［ 個々の`要請$について，それを~HTTPから~HTTPS（あるいは その逆）へ安全に~redirectできるかどうか ］を決定する必要がある。 更には、`条件付きで~HSTS安全$な生成元は， 【昇格の仕組みを】~supportする~UAに限って `Strict-Transport-Security$h を~opt-intoできる — そうしなければ、~siteの利用者にとって よくない結果になりかねない。 ◎ Sites which require the upgrade mechanism laid out in this document in order to provide users with a reasonable experience over secure transit need some way to determine whether or not a particular request can safely be redirected from HTTP to HTTPS (and vice-versa). Moreover, conditionally HSTS-safe origins can only opt-into Strict-Transport-Security for supported user agents, and doing otherwise could have negative consequences for the site’s users.

この裁定は，~UA~sniffing 【~serverが，~UAが昇格の仕組みを~supportするかどうか推定（ sniff ）する？】 に依拠して下すものではない — ~UAは、`~navi要請$の発行-時に `Upgrade-Insecure-Requests$h ~headerを含ませることにより，自身の昇格~能力を告知できる。 `Upgrade-Insecure-Requests^h ~HTTP要請~header 節を見よ。 ◎ Rather than relying on user-agent sniffing to make this decision, user agents can advertise their upgrade capability when making navigation requests by including an Upgrade-Insecure-Requests header field as described in §3.2.1 The Upgrade-Insecure-Requests HTTP Request Header Field.

"Upgrade-Insecure-Requests:" *`WSP$P "1" *`WSP$P

GET / HTTP/1.1
Host: example.com
`Upgrade-Insecure-Requests$h: 1

HTTP/1.1 307 Moved Temporarily
`Location$h: https://example.com/
`Vary$h: `Upgrade-Insecure-Requests$h

HTTP/1.1 307 Moved Temporarily
`Location$h: https://example.com/
`Cache-Control$h: `no-store$dir

3.3. 施策の継承

［ `Document$I の`現任の設定群~obj$ の`非保安的~要請~施策$ ~EQ `昇格可$i ］の場合、~UAは，次の仕方で，すべての`入子の閲覧文脈$に設定が継承されることを確保し~MUST： ◎ If a Document's incumbent settings object’s insecure requests policy is set to Upgrade, the user agent MUST ensure that all nested browsing contexts inherit the setting in the following ways:

1. `入子の閲覧文脈$ %文脈 を作成するときは： ◎ When a nested browsing context context is created:

   1. %文書 ~LET %文脈 を`埋込んでいる文書$ ◎ ↓

   2. ~IF［ %文書 の`非保安的~要請~施策$ ~EQ `昇格可$i ］： ◎ If context’s embedding document’s insecure requests policy is Upgrade, then:

      1. %文脈 の`非保安的~要請~施策$ ~SET `昇格可$i ◎ Set context’s insecure requests policy to Upgrade.
      2. ［ %文書 の`非保安的~navi昇格~集合$ ］内の ~EACH ( %値 ) に対し ⇒ %文脈 の`非保安的~navi昇格~集合$に %値 を追加する ◎ For each value in context’s embedding document’s upgrade insecure navigations set, add value to context’s upgrade insecure navigations set.

2. `閲覧文脈$ %文脈 内に`新たな文書を作成-$をするときは： ◎ When creating a new Document object document in a browsing context context:

   1. ~IF［ %文脈 の`非保安的~要請~施策$ ~EQ `昇格可$i ］： ◎ If context’s insecure requests policy is Upgrade, then:

      1. %設定群 ~LET 作成される文書の`現任の設定群~obj$ ◎ Let settings be document’s incumbent settings object.
      2. %設定群 の`非保安的~要請~施策$ ~SET `昇格可$i ◎ Set settings’ insecure requests policy to Upgrade.
      3. %文脈 の`非保安的~navi昇格~集合$内の ~EACH ( %値 ) に対し ⇒ %設定群 の`非保安的~navi昇格~集合$に %値 を追加する ◎ For each value in context’s upgrade insecure navigations set, add value to settings’s upgrade insecure navigations set.

同様に、~workerの~~始動時には、~UAは，次の仕方で それを作成した文脈から設定が継承されることを確保し~MUST： ◎ Likewise, when spinning up a worker, the user agent MUST ensure that it inherits the setting from the context that created it in the following ways:

1. `~worker環境~設定群~objを設定しておく$ ~algoの，現在の段 #4 の後に次の手続きを~~挿入する： ◎ When executing the set up a worker environment settings object algorithm, perform the following steps after the current step #4:

   5. ~IF［ `継承ed担当の閲覧文脈^V の`非保安的~要請~施策$ ~EQ `昇格可$i ］： ◎ If inherited responsible browsing context’s insecure requests policy is Upgrade, then:

      1. %設定群~obj の`非保安的~要請~施策$ ~SET `昇格可$i ◎ Set settings object’s insecure requests policy to Upgrade.
      2. ［ `継承ed担当の閲覧文脈^V の`非保安的~navi昇格~集合$ ］内の ~EACH ( %値 ) に対し ⇒ %設定群~obj の`非保安的~navi昇格~集合$に %値 を追加する ◎ For each value in inherited responsible browsing context’s upgrade insecure navigations set, add value to settings object’s upgrade insecure navigations set.

3.4. 昇格の報告-法

非保安的~要請の昇格-法は、［ `昇格の仕組み$を~supportしない~UAにおいて要請が非保安的になるかどうかを，作者が突き止めれる能 ］に干渉しては~MUST_NOT。 そのため、昇格を遂行する時機は，［ %要請 を`監視-$下にある保安~施策すべてに対し評価した後 ］, かつ［ %要請 を`施行-$下にある保安~施策すべてに対し評価する前 ］で~MUST。 ◎ Upgrading insecure requests MUST not interfere with an authors' ability to track down requests that would be insecure in a user agent that does not support upgrades. To that end, upgrades MUST be performed after evaluating request against all monitored security policies, but before evaluating request against all enforced policies.

`Content-Security-Policy$h: `upgrade-insecure-requests$dir; `default-src$dir https:
`Content-Security-Policy-Report-Only$h: `default-src$dir https:; `report-uri$dir /endpoint

注記： `CSP$r が`FETCH$r の用語を通して書直されたなら、これは，有意に明確化されることになる。 ◎ Note: This will be significantly clarified once [CSP] is rewritten in terms of [FETCH].

4.1. 適切になるなら %要請 を先天的に認証-済み~URLに昇格する

この~algoは、所与の`要請$ %要請 に対し，［ %要請 が出自にしている`~client$rq ］が昇格を~opt-inしていたならば、 %要請 の`~url$rqを書直す。 それはまた、非保安的`~navi要請$に対し，［ ~serverによる~clientの昇格~特色機能を検出する能を改善する ］ために， `Upgrade-Insecure-Requests$h ~headerを注入する。 ◎ Given a request request, this algorithm will rewrite its url if the client from which the request originates has opted-in to upgrades. It will also inject an Upgrade-Insecure-Requests header field header for insecure navigation requests in order to improve a server’s ability to feature-detect a client’s upgrade capabilities.

~form提出は例外として、非同一生成元`~navi要請$は昇格されない。 ~form提出は、平文text提出を介して~dataが漏洩される~riskを軽減するため，昇格されることになる。 ◎ We will not upgrade cross-origin navigation requests, with the exception of form submissions. Form submissions will be upgraded to mitigate the risk of data leakage via plaintext submissions.

注記： この~algoは、`~main~fetch$~algoの冒頭で~callされる。 ◎ Note: This algorithm is called at the top of the Main Fetch algorithm.

1. %~url ~LET %要請 の`~url$rq ◎ ↓

2. ~IF［ %要請 は`~navi要請$である ］~AND［［ %~url は`先天的に認証-済み$でない ］~OR［ %~url の`~host$urlは`事前読込-可能な~HSTS~host$でない ］］ ⇒ %要請 の`~header~list$rqに`~headerを付加する$( `Upgrade-Insecure-Requests^h / `1^v ) ◎ If request is a navigation request, append a header named Upgrade-Insecure-Requests with a value of 1 to request’s header-list if any of the following criteria are met: • request’s url is not a priori authenticated • request’s url’s host is not a preloadable HSTS host

   注記： ~UAは、他の要請に対しても `Upgrade-Insecure-Requests$h ~headerを付加することを選べる — `Upgrade-Insecure-Requests^h ~HTTP要請~header 節にて論じられるように。 ◎ Note: User agents can choose to append the Upgrade-Insecure-Requests header field for other requests, as discussed in §3.2.1 The Upgrade-Insecure-Requests HTTP Request Header Field.

3. ~IF［ 次のすべてが満たされる ］ ⇒ ~RET： ◎ If request is a navigation request, then:

   • %要請 は`~navi要請$である
   • %要請 は~form提出でない ◎ If request is a form submission, skip the remaining substeps, and continue upgrading request.
   • %要請 の`~target閲覧文脈$rqは`入子の閲覧文脈$でない ◎ If request’s target browsing context is a nested browsing context, skip the remaining substeps and continue upgrading request.
   • %~url の ( `~host$url, `~port$url ) 組 ~NIN %要請 の`~client$rqの`非保安的~navi昇格~集合$ ◎ Let tuple be a tuple of request’s url’s host and port. ◎ If tuple is contained in client’s upgrade insecure navigations set, then skip the remaining substeps, and continue upgrading request. ◎ Return without further modifying request.

   注記： ~top-level`~navi要請$が昇格されるのは、特定0の`被保護~資源$に対し 挙動を明示的に~opt-intoしている~hostに限られる — 各種~例 節にて述べたように。 第三者主体~資源への~top-level~naviに対し 昇格を遂行することは、~pageを壊す~~確度をかなり高めるので，当面は避けることにしている。 入子の~navi（例えば `iframe$e を介するもの）に対しては、その埋込元の保安~statusに影響するので、必要に応じて，その昇格を確保する。 ◎ Note: We only upgrade top-level navigation requests for hosts that have explicitly opted-into the behavior for a particular protected resource, as described in §1.2 Examples. Performing upgrades for top-level navigations to third-party resources brings a significantly higher potential for breakage, so we’re avoiding it for the moment. Nested navigations (via iframe, for example) affect the security status of their embedder, so we ensure that they are upgraded if necessary.

4. ~IF［［ %要請 の`~client$rqに対する`非保安的~要請は昇格されるべきか？$ ］の結果 ~EQ `昇格不可$i ］ ⇒ ~RET ◎ Let upgrade state be the result of executing §4.2 Should insecure requests be upgraded for client? upon request’s client. ◎ If upgrade state is Do Not Upgrade, return without modifying request.
5. ~IF［ %~url の`~scheme$url ~EQ `http^c ］ ⇒ %~url の`~scheme$url ~SET `https^c；
   ~RET ◎ If request’s url’s scheme is http, set request’s url’s scheme to https, and return.

6. ~IF［ %~url の`~port$url ~EQ `80^c ］ ⇒ %~url の`~port$url ~SET `443^c ◎ If request’s urls port is 80, set request’s urls port to 443.

   注記： ~portが明示的に `80^c に設定されている場合は，~UAは ~URLの~portのみを変更し、［ ~portが設定されていない／何か非標準の値に設定されている ］場合は，その値を改変しないことになる。 この実装には、~HSTSと同じ~tradeoffがある【？】（ `RFC6797$r を見よ — 特定的には， Section 8.3 の段 #5, Appendix A の~item #6。 ◎ Note: This will only change the URL’s port if the port is explicitly set to 80. If the port is not set, or if it is set to some non-standard value, the user agent will not modify that value. This implementation makes the same tradeoffs as HSTS (see [RFC6797], and specifically step #5 of Section 8.3, and item #6 in Appendix A).

注記： `FETCH$r の再帰的な資質に因り、この~algoは，初期~要請のみならず ~redirectに対しても，非保安的な要請を昇格することになる。 ◎ Note: Due to [FETCH]'s recursive nature, this algorithm will upgrade insecurely-redirected requests as well as insecure initial requests.

4.2. %~client に対する非保安的~要請は昇格されるべきか？

この~algoは、所与の［ `要請$の`~client$rq ］ %~client （`環境~設定群~obj$）に結付けられている非保安的~要請が昇格されるべきならば `昇格可$i ／ ~ELSE_ `昇格不可$i ］を返す。 要約すると、これは、 %~client を検査して，［ %~client, または %~client の`閲覧文脈$ ］に設定されている適切な`非保安的~要請~施策$を返す： ◎ Given an request’s client client (an environment settings object), this algorithm returns Enforced Upgrade if insecure requests associated with that client should be upgraded, or Do Not Upgrade otherwise. In short, this will check the client and return the appropriate insecure requests policy set on it or its browsing context.

1. ~IF［ %~client には`担当の文書$がある ］ ⇒ ~RET それ†の`非保安的~要請~施策$の値 ◎ If client has a responsible document, return the value of its insecure requests policy.

   注記： これは，次のいずれかに該当する［ `Document$I ／ `Worker$I ］を~catchする：

   • `upgrade-insecure-requests$dir 指令により施策が直に設定されているもの
   • `埋込んでいる文書$から施策を継承しているもの

   ◎ Note: This catches Documents or Workers whose policy is set directly by the upgrade-insecure-requests directive, or which have inherited the policy from an embedding document.

   【† この “それ” と下の段の “それ” は、おそらく（ %~client ではなく） “担当の〜” の方を指す。 】

2. ~IF［ %~client には`担当の閲覧文脈$がある ］ ⇒ ~RET それ†の`非保安的~要請~施策$の値 ◎ If client has a responsible browsing context, return the value of its insecure requests policy.

   注記： これは、~detachされた`~client$rq から誘発された要請を~catchする。 これが必要とされるかどうかは確かでない, really, given 施策の継承 節に定義される継承~構造。【？】 ◎ Note: This catches requests triggered from detached clients. Not sure this is necessary, really, given the inheritance structure defined in §3.3 Policy Inheritance.

3. ~RET `昇格不可$i ◎ Return Do Not Upgrade.

6.1. ~HSTSとの相互作用

`upgrade-insecure-requests$dir 指令は、 `Strict-Transport-Security$h ~HTTP応答~header `RFC6797$r を置換するものではない。 自身の~siteを保安的~transport越しに~serveしている作者は、利用者が悪意的な［ 能動的／受動的 ］~network攻撃者による［ ~SSL-stripping攻撃や, 監視 ］の対象0にされないことを確保するため、適切な `max-age^dir を伴う~headerを送信する~SHOULDである。 ◎ The upgrade-insecure-requests directive does not replace the Strict-Transport-Security HTTP response header [RFC6797]. Authors who serve their site over secure transport SHOULD send that header with an appropriate max-age in order to ensure that users are not subject to SSL stripping attacks by maliciously active network attackers, or monitoring by maliciously passive network attackers.

6.2. ~CSP違反~報告

~UAは、昇格された資源に対し違反~報告を送信するときは、当の要請を誘発した［ `Document$I ／ `Worker$I ］を~targetにし~MUST — `upgrade-insecure-requests$dir 指令が設定された［ `Document$I ／ `Worker$I ］ではなく。 施策の継承 節に因り，後者は 前者の非同一生成元 先祖かもしれず、その場合，違反~報告を［ 報告-先 端点の集合 ］へ送信すると，期待されない仕方で~dataが漏洩され得るので。 ◎ When sending a violation report for an upgraded resource, user agents MUST target the Document or Worker that triggered the request, rather than the Document or Worker on which the upgrade-insecure-requests directive was set. Due to §3.3 Policy Inheritance, the latter might be a cross-origin ancestor of the former, and sending violation reports to that set of reporting endpoints could leak data in unexpected ways.

同じ理由から、 `SecurityPolicyViolationEvent$I は、当の要請を誘発した `Document$I 以外を~targetにしては~MUST_NOT。 ◎ Likewise, the SecurityPolicyViolationEvent MUST NOT target any Document other than the one which triggered the request, for the same reasons.

8.1. 旧来の~client

混在~内容の阻止-法 `MIX$r は~supportするが`昇格の仕組み$は~supportしない，旧来の~clientは、非保安的~URLを包含している~page上で，最適に劣る体験を~~供し続けることになる。 作者は、それらに`違反~報告を送信-$させ，収集された情報を利用して、利用者にとり最も問題がある資源はどれかを見定め，最もよく要請されると見込まれる旧来の内容~内の~URLを優先して修正する~SHOULDである。 ◎ Legacy clients which do support mixed content blocking [MIX], but do not support the upgrade-insecure-requests directive will continue to have a suboptimal experience on pages containing insecure URLs. Authors SHOULD ensure that they collect violation reports in order to determine which resources are most problematic for their users, and SHOULD use that information to prioritize fixes for URLs in legacy content that users will most likely request.

8.2. ~HSTSとの関係

`昇格の仕組み$が扱うのは、特定の`被保護~資源$用の保安~施策に限られる。 それは、 `Strict-Transport-Security^h ~HTTP応答~header `RFC6797$r を［ 非推奨にする ／ 置換する ／ 何らかの仕方で抑制する ］ものではない。 作者は、［ 利用者が，~SSL-stripping降格-攻撃の対象0にされないことを確保する ］ため，その~headerを利用し続けれるし、また，し続けるべきである — `upgrade-insecure-requests$dir 指令は、［ 利用者が，第三者主体~siteの~linkを介して作者~siteを訪問すること ］による~top-level~naviに対しては，~HTTPSへの昇格を確保しないので。 ◎ The mechanism specified here deals only with the security policy for a specific protected resource. It does not deprecate, replace, or in any way reduce the value of the Strict-Transport-Security HTTP response header [RFC6797]. Authors can and should continue to use that header to ensure that their users are not subject to SSL stripping downgrade attacks, as the upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation.

同様に、 `Strict-Transport-Security^h ~headerが，暗黙に `upgrade-insecure-requests$dir を作動化するよう挙動することはない。 それは、［ ある生成元から要請される資源が~networkを非保安的に叩くことは，決してない ］ことのみを確保する。 ◎ Likewise, the Strict-Transport-Security header does not imply the behavior that upgrade-insecure-requests activates. It only ensures that resources requested from an origin will never hit the network insecurely.

これらの概念は、意図的に別個に保たれている — 作者は、どちらの挙動を作動化させることも選べるが、双方を一緒に束ねるよう強いられるベキでない。 ◎ We are intentionally keeping these concepts distinct, as authors may choose to activate one or the other behavior, but ought not be forced to bind them together.

9.1. `Upgrade-Insecure-Requests^h ~header

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

9.2. `upgrade-insecure-requests^dir 指令

~CSP指令~registry `RFC7762$r は、次の登録で更新されるべきである： ◎ The Content Security Policy Directive registry should be updated with the following registration: [RFC7762]