1. 序論
◎非規範的利用者が `example.com^s から~secure~channel越しに（例えば，~HTTPS）~web~pageを成功裡に読込んだとき、 ~UAと `example.com^s の間で伝送される~dataを［ 盗聴する／改竄する ］実体は無いことが，利用者に保証される。 しかしながら，この保証は、 当の~web~pageが［ ~scriptや画像などの下位資源 ］を~secureでない接続~越しに読込む場合には，弱められる。 例えば，非~secureに読込まれた~scriptは、 利用者に利する~dataを［ 読取る／改変する ］ことを攻撃者に許容し得る。 非~secureに読込まれた画像は、 攻撃者に次を許容し得る： 不正な情報を利用者へ通信する（例：株価図表を偽造する）／ ~client側の状態を変異する（例： ~cookieを設定する）／ 意図しない動作をとるよう利用者を誘導する（例：~buttonの~labelを変更する）。 これらの要請は、 混在~内容（ `mixed content^en ）として知られている。 ◎ When a user successfully loads a webpage from example.com over a secure channel (HTTPS, for example), the user is guaranteed that no entity between the user agent and example.com eavesdropped on or tampered with the data transmitted between them. However, this guarantee is weakened if the webpage loads subresources such as script or images over an insecure connection. For example, an insecurely-loaded script can allow an attacker to read or modify data on behalf of the user. An insecurely-loaded image can allow an attacker to communicate incorrect information to the user (e.g., a fabricated stock chart), mutate client-side state (e.g., set a cookie), or induce the user to take an unintended action (e.g., changing the label on a button). These requests are known as mixed content.
この仕様は、 これらの~riskを~UAが［ 一定の型の混在~内容を阻止する／ 何らかの文脈において，もっと厳密に挙動する ］ことにより，どう軽減できるかについて詳細を与える。 ◎ This specification details how a user agent can mitigate these risks by blocking certain types of mixed content, and behaving more strictly in some contexts.
しかしながら，この仕様の早期の~versionでは、 利用者の~dataの機密性と完全性を全部的には保護していなかった。 現時点では，~secureでない［ 画像, 音声, 動画 ］などの内容は、 既定では~secureな文脈~内に読込める。 ~secureな~pageは、 ~secureでない~downloadでさえ起動し得る — それは、 ~UAの~sandboxから まるごと逃れる。 ◎ However, earlier versions of this specification did not fully protect the confidentiality and integrity of users' data. Insecure content such as images, audio, and video can currently be loaded by default in secure contexts. Secure pages can even initiate insecure downloads which escape the user agent’s sandbox entirely.
さらには，利用者にとっては、 混在~内容が読込まれたことを表す明瞭な~security指示子が無い。 ~web~pageが混在~内容を読込んだとき、 ~browserは “半端な” ~security指示子を表示する（錠前~iconを除去するなど）。 それは、 ~pageを信用するベキかどうかについての明瞭な指示を，利用者に与えていない。 この~UXはまた、 開発者にとっては，混在~内容を避けたいと駆り立てるほどのものになっていない — ~web~page用に混在~内容を読込むことは、 依然として共通的にあることなので。 混在~内容をすべて阻止すれば、 もっと単純な心的~model — ~web~pageは、 ~secureな~transport越しに読込まれたか, そうでないか，どちらかである — を利用者に供することになり、［ ~web~pageが適正に機能するために必要yな混在~内容 ］を~secureに読込むことを，開発者に奨励する。 ◎ Moreover, users do not have a clear security indicator when mixed content is loaded. When a webpage loads mixed content, browsers display an "in-between" security indicator (such as removing the padlock icon), which does not give users a clear indication of whether they should trust the page. This UX has also not proved a sufficient incentive for developers to avoid mixed content, since it is still common for webpages to load mixed content. Blocking all mixed content would provide the user with a simpler mental model -- the webpage is either loaded over a secure transport or it isn’t -- and encourage developers to securely load any mixed content that is necessary for their webpage to function properly.
なので，この仕様は、［ 非互換化は最小限にしつつ，より良い［ ~security／~privacy ］保証の下に より良い~security~UXを利用者に供する ］よう更新された。 単純に すべての混在~内容を厳密に阻止するよう，~browserに勧める代わりに、 この仕様は，混在~内容の自動昇格を勧める： ◎ So this specification was updated to provide users with better security and privacy guarantees and a better security UX, while minimizing breakage. Instead of advising browsers to simply strictly block all mixed content, this specification advises mixed content autoupgrading:
- ~UAがまだ阻止していない混在~内容は、 ~secure~transportに自動昇格されるベキである。 ◎ Mixed content that user agents are not already blocking should be autoupgraded to a secure transport.
- 自動昇格できない要請は、 阻止されることになる。 ◎ If the request cannot be autoupgraded, it will be blocked.
自動昇格は、 非互換化を避けるために必要な開発者が~~費やす労を最小限にしつつ， ~secureな~web~page上で~secureでない資源を読込むのを避ける。 ◎ Autoupgrading avoids loading insecure resources on secure webpages, while minimizing the amount of developer effort needed to avoid breakage.
この仕様は、［ 現時点では，既定では阻止されていない型の混在~内容を成す下位資源 ］に限り，自動昇格を推奨する — すでに阻止されている型の内容に自動昇格を推奨するものではない。 これは、 ~webに可視になる変化の量を最小限にする — 内容を自動昇格するよう求めるのは、 すべての混在~内容を既定で阻止する目標に向かって進む場合に限られる。 ◎ This specification only recommends autoupgrading types of mixed content subresources that are not currently blocked by default, and does not recommend autougprading types of content that are already blocked. This is to minimize the amount of web-visible change; we only want to autoupgrade content if it advances us towards the goal of blocking all mixed content by default.
この仕様はまた，`混在~download$の概念も明示的に導入する。 混在~downloadは、 ~UAが~downloadとして取扱う資源のうち，~secure文脈により起動されたが, ~secureでない接続~越しに~downloadされるものである。 ~UAは、 混在~downloadを阻止するベキである — それは、 ~UAの~sandboxから逃れることもあれば（実行-可能な事例において），敏感な情報を包含することもある（例：~downloadされる銀行取引明細）ので。 これは、 とりわけ利用者を~~誤認させるものになる — ~UAは、 概して~secure~page上にあると利用者に指示する一方で，混在~downloadを起動して完了するので。 ◎ This specification also explicitly introduces the concept of mixed downloads. A mixed download is a resource that a user agent handles as a download, which was initiated by a secure context but is downloaded over an insecure connection. User agents should block mixed downloads because they can escape the user agent’s sandbox (in the case of an executable) or contain sensitive information (e.g., a downloaded bank statement). This is especially misleading because user agents typically indicates to the user that they are on a secure page while initiating and completing a mixed download.
2. 主要な概念と各種用語
- `混在~内容@ （ `mixed content^en ）
-
~AND↓ を満たす`要請$は、 `混在~内容$とされる：
- その`~URL$rqは`信用に価し得る~URL$でない `SECURE-CONTEXTS$r
- その読込ngを担当する文脈は、 混在~security文脈を禁制している†
-
~AND↓ を満たす`応答$は、 `混在~内容$とされる：
- `未認証な応答$である
- その読込ngを担当する文脈は、 混在~security文脈を禁制するよう要求している†
- † 規範的な定義は、 `設定群は混在~security文脈を禁制するか？$を見よ。 ◎ ↑
-
混在~内容を制約する文脈（例： `https://secure.example.com/^s ）の内側では： ◎ Inside a context that restricts mixed content (https://secure.example.com/, for example):
- `http://example.com/script.js^s にある~scriptに対する要請は`混在~内容$になる。 この`要請$は`阻止-可能$になるので、 ~UAは，資源を読込む代わりに~network~errorを返すことになる。 ◎ A request for the script http://example.com/script.js is mixed content. As script requests are blockable, the user agent will return a network error rather than loading the resource.
- `http://example.com/image.png^s にある画像に対する要請は`混在~内容$になる。 この`要請$は`昇格-可能$になるので、 ~UAは，~URLを `https://example.com/image.png^c に書直すかもしれない — さもなければ、 読込nを阻止することになる。 ◎ A request for the image http://example.com/image.png is mixed content. As image requests are upgradeable, the user agent might rewrite the URL as https://example.com/image.png, otherwise it will block the load.
- 注記： “混在~内容” は、 元々は `WSC-UI$r § 5.3 にて定義された。 この文書は、 それによる初期の定義を更新する。 ◎ Note: "Mixed content" was originally defined in section 5.3 of [WSC-UI]. This document updates that initial definition.
- 注記： `XML$r も無関係な 混在~内容 の概念を定義しているが、 この用語は，各~UAにわたる~security文脈のほぼ至る所で 10 年以上 使われ続けているので、 実用的には混同されるおそれは少ないであろう。 ◎ Note: [XML] also defines an unrelated "mixed content". concept. This is potentially confusing, but given the term’s near ubiquitious usage in a security context across user agents for more than a decade, the practical risk of confusion seems low.
- `未認証な応答@ （ `unauthenticated response^en ）
- `応答$は、［ その`~URL$rsが`信用に価し得る~URL$でない ］ならば，未認証であることが`後天的^em（ a posteriori ）に既知となる ◎ We know a posteriori that a response (response) is unauthenticated if response’s URL is not a potentially trustworthy URL.
- `埋込んでいる文書@ （ `embedding document^en ）
- 所与の`文書$を`埋込んでいる文書$は、 それが`属する閲覧~文脈$の容器~文書を指す。 `HTML$r ◎ Given a Document A, the embedding document of A is A’s browsing context's container document [HTML].
- 【 “`閲覧~文脈$の容器~文書” は廃された用語。 単に，当の文書の`容器~文書$docを指す — そう記しても同じことなので、 この訳では，この用語は利用しない。 】
- `混在~download@ （ `mixed download^en ）
- 混在~downloadは、 ~UAが~downloadとして取扱う資源のうち［ ~secure文脈により起動されたが，~secureでない接続~越しに~downloadされるもの ］である。 ◎ A mixed download is a resource that a user agent handles as a download, which was initiated by a secure context but is downloaded over an insecure connection.
注記： 【過去に利用されていた用語】 `先天的に認証-済みな~URL@ （ `a priori authenticated URL^en ） は、 `信用に価し得る~URL$ `SECURE-CONTEXTS$r に等価である。 ◎ An a priori authenticated URL is equivalent to a potentially trustworthy URL [SECURE-CONTEXTS].
3. 内容の分類
理想世界では、 各~UAには，あらゆる`混在~内容$を例外なく阻止することが要求されることになるが、 あいにく今日の~Internetにおいては，それは実用的でない。 ~UAは、 より按配よく制約しなければ，相当数の~web~siteで利用者~体験の劣化は避けれなくなる。 ◎ In a perfect world, each user agent would be required to block all mixed content without exception. Unfortunately, that is impractical on today’s Internet; a user agent needs to be more nuanced in its restrictions to avoid degrading the experience on a substantial number of websites.
そのことを念頭に、 ここでは，混在~内容を［ `昇格-可能$なもの, `阻止-可能$なもの ］の 2 つに分類する。 ◎ With that in mind, we here split mixed content into two categories: § 3.1 Upgradeable Content and § 3.2 Blockable Content.
3.1. 昇格-可能な内容
注記： `昇格-可能$な内容は、 この仕様の早期の~versionでは， `随意に阻止-可能^em （ `optionally-blockable^en ）と称されていた。 ◎ Upgradeable content was previously referred to as optionally-blockable in earlier versions of this specification.
`混在~内容$は、［ `混在~内容$としての用法を許容する~risk ］より［ ~webの有意な部位を非互換化する~risk ］の方が重視されるとき， `昇格-可能@ （ `upgradeable^en ）とされる。 これは、 当の資源~種別が混在される利用率が十分に高いこと，および 資源それ自体は低~riskであることによる。 この種の資源が`昇格-可能$である事実が，`安全である^emことを意味するわけではない — 単純に，他の種別の資源より破滅的な危険~度は低いことを意味する。 例えば画像や~iconは、 ~appの~interfaceにおいて中心的な~UI要素になることが多い。 攻撃者が~emailの［ “~~削除”, “~~返信” ］を表す~iconを逆にした場合、 利用者に実害が及ぶことになる。 ◎ Mixed content is upgradeable when the risk of allowing its usage as mixed content is outweighed by the risk of breaking significant portions of the web. This could be because mixed usage of the resource type is sufficiently high, and because the resource is low-risk in and of itself. The fact that these resource types are upgradeable does not mean that they are safe, simply that they’re less catastrophically dangerous than other resource types. For example, images and icons are often the central UI elements in an application’s interface. If an attacker reversed the "Delete email" and "Reply" icons, there would be real impact to users.
これに分類されるものには次が挙げられる： ◎ This category includes:
-
次を満たす要請 ⇒ ［ `起動元$rq ~EQ 空~文字列 ］~AND［ `行先$rq ~EQ `image^l ］ ◎ Requests whose initiator is the empty string, and whose destination is "image".
注記： `img$e 要素や~CSS（ `background-image$p, `border-image$p, 等々）を介して読込まれるほとんどの画像は、 これに対応する（画像として読込まれる~SVG文書も含まれる — それらによる［ ~scriptの実行ng／下位資源の~fetching ］は阻止されるので）。 `img$e 要素のうち `srcset^a または `picture^e を利用して いるものは含まれない。 ◎ Note: This corresponds to most images loaded via img (including SVG documents loaded as images, as those are blocked from executing script or fetching subresources) and CSS (background-image, border-image, etc). It does not include img elements that use srcset or picture.
-
次を満たす要請 ⇒ `行先$rq ~EQ `video^l ◎ Requests whose destination is "video".
注記： ［ `video$e ／ `source$e ］要素を介して読込まれる動画は、 これに対応する。 ◎ Note: This corresponds to video loaded via video and source.
-
次を満たす要請 ⇒ `行先$rq ~EQ `audio^l ◎ Requests whose destination is "audio".
注記： ［ `audio$e ／ `source$e ］要素を介して読込まれる音声は、 これに対応する。 ◎ Note: This corresponds to audio loaded via audio and source.
この分類は、 `要請の~fetchingは混在~内容として阻止されるべきか？$において，［ ~CORSが可能化された要請には失敗ngを強制する ］ことにより、 更に制限される。 これは例えば、 <`img$e `crossorigin$a ...> を介して読込まれる混在~内容~画像は阻止されることを意味する。 上に挙げたものは、［ この分類に該当する内容は，［ 全面的に阻止するには，広範に利用され過ぎている ］ものに`限られる^em ］とする、 一般~原則の好例である。 ~WGは、 時を経るに伴い，より`阻止-可能$な下位集合を形作ることを意図している。 ◎ We further limit this category in § 4.4 Should fetching request be blocked as mixed content? by force-failing any CORS-enabled request. This means, for example, that mixed content images loaded via <img crossorigin ...> will be blocked. This is a good example of the general principle that content falls into this category only when it is too widely used to be blocked outright. The Working Group intends to carve out more blockable subsets as time goes on.
3.2. 阻止-可能な内容
上に定義した`昇格-可能$でない，どの`混在~内容$も `阻止-可能@ （ `blockable^en ）と見なされる。 この種の内容の代表的な例には、 次が挙げられる ⇒＃ ~script, `~plugin$用の~data, `XMLHttpRequest$I を介して要請される~data, 等々 ◎ Any mixed content that is not upgradeable as defined above is considered to be blockable. Typical examples of this kind of content include scripts, plugin data, data requested via XMLHttpRequest, and so on.
注記： `~navi要請$は、 `~top-level閲覧~文脈$【`~top-level辿可能$】を~targetにすることもあるが，混在~内容とは見なされない。 詳細は、 `要請の~fetchingは混在~内容として阻止されるべきか？$を見よ。 ◎ Note: Navigation requests might target top-level browsing contexts; these are not considered mixed content. See § 4.4 Should fetching request be blocked as mixed content? for details.
注記： ~pluginが自身に利するために為す要請は、 `阻止-可能$になる。 しかしながら、 ~UAが常に，そのような要請を仲介する立場にあるとは限らないことも認識されている。 一例として、 NPAPI ~pluginは，直接的な~network~accessを有することが多く、 一般に~UAをまるごと迂回できる。 ~UAには、 アリなときは，これらの要請を阻止することが推奨される。 ~plugin~vendorには、 自身における混在~内容の検査-法を実装して，この文書に要旨する~riskを軽減することが推奨される。 ◎ Note: Note that requests made on behalf of a plugin are blockable. We recognize, however, that user agents aren’t always in a position to mediate these requests. NPAPI plugins, for instance, often have direct network access, and can generally bypass the user agent entirely. We recommend that user agents block these requests when possible, and that plugin vendors implement mixed content checking themselves to mitigate the risks outlined in this document.
4. ~algo
4.1. 適切になるなら，混在~内容への要請を信用に価し得る~URLへ昇格する
注記： ~Fetch仕様は、 この~algoの中へ~hookして，`昇格-可能$な混在~内容を~HTTPSへ昇格することになる。 ◎ Note: The Fetch specification will hook into this algorithm to upgrade upgradeable mixed content to HTTPS.
この~algoは、 所与の ( `要請$ %要請 ) に対し， %要請 は`昇格-可能$な混在~内容と判断されるならば、 その`~URL$rqを書直す： ◎ Given a Request request, this algorithm will rewrite its URL if the request is deemed to be upgradeable mixed content, via the following algorithm:
-
~IF［ ~OR↓ ］… ◎ If one or more of the following conditions is met, return without modifying request:
- %要請 の`~URL$rqは`信用に価し得る~URL$である ◎ request’s URL is a potentially trustworthy URL.
- %要請 の`~URL$rqの`~host$urlは`~IP~address$である ◎ request’s URL’s host is an IP address.
- `設定群は混在~security文脈を禁制するか？$( %要請 の`~client$rq ) ~EQ `禁制しない^i ◎ § 4.3 Does settings prohibit mixed security contexts? returns "Does Not Restrict Mixed Security Contents" when applied to request’s client.
- %要請 の`行先$rq ~NIN { `image^l, `audio^l, `video^l } ◎ request’s destination is not "image", "audio", or "video".
-
［ %要請 の`行先$rq ~EQ `image^l ］~AND［ %要請 の`起動元$rq ~EQ `imageset^l ］ ◎ request’s destination is "image" and request’s initiator is "imageset".
注記： 歴史的な理由から、 `imageset^l は昇格されない。 この仕様は、 一部の型の混在~内容に対する昇格に先立って， 混在~内容を阻止-可能と随意に阻止-可能に分けていた — ~~普及してなかった型の混在~内容には、 阻止-可能が選好されるよう。 `imageset^l は，前者の一部を成していて、 この仕様に昇格が追加されたとき， 以前に阻止-可能として定義された内容は昇格しないものと裁定された。 ◎ Note: For historical reasons, "imageset" is not upgraded. Prior to some types of mixed content being upgraded, the spec divided mixed content into blockable and optionally-blockable, with blockable being preferred for any type of mixed content that wasn’t prevalent. "imageset" was part of the former, and when upgrades were added, the decision was to not upgrade any content that was previously defined as blockable.
…ならば ⇒ ~RET （ %要請 は改変されない） ◎ ↑
-
~IF［ %要請 の`~URL$rq の`~scheme$url ~EQ `http^l ］ ⇒ %要請 の`~URL$rq の`~scheme$url ~SET `https^l ◎ If request’s URL’s scheme is http, set request’s URL’s scheme to https, and return.
注記： `URL$r に従い、 ここでは~portは改変しない — それは、 ~scheme ~EQ `http^l のときには ~NULL に設定され，~schemeが `https^l に変更されたなら 443 として解釈されることになるので。 ◎ Note: Per [url], we do not modify the port because it will be set to null when the scheme is http, and interpreted as 443 once the scheme is changed to https
4.2. 以前の~algoに対する改変
注記： 以下の節は、 この仕様の早期の~versionにおける~algoに対する，［ 随意に阻止-可能, `阻止-可能$ ］の区別を無視するための改変を含む — 前者の混在~内容は、 今や，すべて自動昇格されることになるので。 ◎ Note: This section includes modifications to algorithms in earlier versions of the specification — to ignore the distinction between optionally-blockable and blockable mixed content, since all optionally-blockable mixed content is now be autoupgraded.
4.3. %設定群 は混在~security文脈を禁制するか？
`文書$, ~worker のいずれも，`環境~設定群~obj$ %設定群 を有する。 これは、［ 混在~内容を制約するかどうか ］を決定するために，次の~algoに則って精査され得る。 この~algoは、［ `禁制する^i, `禁制しない^i ］のいずれかを返す： ◎ Both documents and workers have environment settings objects which may be examined according to the following algorithm in order to determine whether they restrict mixed content. This algorithm returns "Prohibits Mixed Security Contexts" or "Does Not Prohibit Mixed Security Contexts", as appropriate. ◎ Given an environment settings object (settings):
- ~IF［ %設定群 の`生成元$enVは`信用に価し得る生成元$である ］ ⇒ ~RET `禁制する^i ◎ If settings’ origin is a potentially trustworthy origin, then return "Prohibits Mixed Security Contexts".
-
~IF［ %設定群 の`大域~obj$enVは`~window$である ］： ◎ If settings’ global object is a window, then:
- %文書 ~LET %設定群 の`大域~obj$enVに`結付けられた文書$ ◎ Set document to settings’ global object's associated Document.
- %文書 の`先祖~navigable群$を成す ~EACH( `~navigable$ %~navigable ) に対し ⇒ ~IF［ %~navigable にて`作動中な文書$navの`生成元$docは`信用に価し得る生成元$である ］ ⇒ ~RET `禁制する^i ◎ For each navigable navigable in document’s ancestor navigables: • If navigable’s active document's origin is a potentially trustworthy origin, then return "Prohibits Mixed Security Contexts".
- ~RET `禁制しない^i ◎ Return "Does Not Restrict Mixed Security Contexts".
注記： 文書の`容器~文書$doc【！`埋込んでいる文書$】 ~NEQ ~NULL の場合、 ~UAは，文書のみならず容器~文書【！が入子にしている`~top-level閲覧~文脈$】についても検査する必要がある — それが、［［ 利用者が読込んだ資源の~security状態s ］に関する利用者の期待 ］を制御する文脈なので。 例えば： ◎ If a document has an embedding document, a user agent needs to check not only the document itself, but also the top-level browsing context in which the document is nested, as that is the context which controls the user’s expectations regarding the security status of the resource she’s loaded. For example:
- `http://a.com^s が `http://evil.com^s を読込む場合 ⇒ `evil.com^s への~secureでない要請は、 許容されることになる — `a.com^s は ~secureな接続~越しに読込まれていないので。 ◎ http://a.com loads http://evil.com. The insecure request will be allowed, as a.com was not loaded over a secure connection.
- `https://a.com^s が `http://evil.com^s を読込む場合 ⇒ `evil.com^s への~secureでない要請は、 阻止されることになる — `a.com^s は ~secureな接続~越しに読込まれたので。 ◎ https://a.com loads http://evil.com. The insecure request will be blocked, as a.com was loaded over a secure connection.
- `http://a.com^s が~frame内に `https://b.com^s を入子にしていて， `b.com^s は `http://evil.com^s を読込む場合 ⇒ `evil.com^s への~secureでない要請は、 阻止されることになる — `a.com^s は そうでなくても， `b.com^s は ~secureな接続~越しに読込まれたので。 ◎ http://a.com frames https://b.com, which loads http://evil.com. In this case, the insecure request to evil.com will be blocked, as b.com was loaded over a secure connection, even though a.com was not.
- `https://a.com^s が~frame内に ~data_scheme ~URLを入子にしていて，その ~data_scheme ~URLは `http://evil.com^s を読込む場合 ⇒ `evil.com^s への~secureでない要請は阻止されることになる — ~top-level文脈における~data_scheme ~URLは 混在~内容を阻止しないが、 `a.com^s は ~secureな接続~越しに読込まれたので。 ◎ https://a.com frames a data: URL, which loads http://evil.com. In this case, the insecure request to evil.com will be blocked, as a.com was loaded over a secure connection, even though the framed data: URL would not block mixed content if loaded in a top-level context.
4.4. %要請 の~fetchingは混在~内容として阻止されるべきか？
注記： ~fetch仕様は、 要請をまるごと阻止する†べきかどうか決定するために，この~algoの中へ~hookする。 † 例えば，当の要請は、 `阻止-可能$な内容に対するものであり，~secureな接続~越しに読込まれることは ないと`見做せる^emことから。 ◎ Note: The Fetch specification hooks into this algorithm to determine whether a request should be entirely blocked (e.g. because the request is for blockable content, and we can assume that it won’t be loaded over a secure connection).
~UAは、 次の~algoを介して，所与の`要請$ %要請 を続行するべきかどうかを決定する： ◎ Given a Request request, a user agent determines whether the Request request should proceed or not via the following algorithm:
-
~RET ［ ~OR↓ が満たされるならば `許容される^i ／ ~ELSE_ `阻止される^i ］： ◎ Return allowed if one or more of the following conditions are met:
- `設定群は混在~security文脈を禁制するか？$( %要請 の`~client$rq ) の結果 ~EQ `禁制しない^i ◎ § 4.3 Does settings prohibit mixed security contexts? returns "Does Not Restrict Mixed Security Contexts" when applied to request’s client.
- %要請 の`~URL$rqは`信用に価し得る~URL$である ◎ request’s URL is a potentially trustworthy URL.
- ~UAは — `§ 利用者-制御$に述べるように — `混在~内容$を許容するよう指図されている ◎ The user agent has been instructed to allow mixed content, as described in § 7.2 User Controls).
-
［ %要請 の`行先$rq ~EQ `document^l ］~AND［ %要請 は`~top-level~navi$である ］ ◎ request’s destination is "document", and request’s target browsing context has no parent browsing context.
注記： `~top-level~navi$は，混在~内容~検査からは除外されるが、 ~UAは，~secureでない~form提出に対しては 混在~内容~検査を施行することを選んでもヨイ（ `§ ~form提出$を見よ）。 ◎ Note: We exclude top-level navigations from mixed content checks, but user agents MAY choose to enforce mixed content checks on insecure form submissions (see § 7.1 Form Submission). ◎ ↑↑ Return blocked.
【 所与の`要請$ %要請 が `~top-level~navi@ である条件は、 原文では，［ %要請 の`~target閲覧~文脈$enVの親~閲覧~文脈 ~EQ ~NULL ］として与えられているが：
- `~target閲覧~文脈$enVは，`要請$ではなく`環境$に結付けられるので、 %要請 の`~target閲覧~文脈$enVは，次のいずれかを意味すると推定される （どちらなのか，はっきりしない） ⇒＃ %要請 の`予約-済み~client$rqの`~target閲覧~文脈$enV／ %要請 の`~client$rqの`~target閲覧~文脈$enV
-
用語 親~閲覧~文脈は、 ~HTMLから廃された。 条件［ `閲覧~文脈$ %閲覧~文脈 の親~閲覧~文脈 ~EQ ~NULL ］は、 次のいずれかを意味すると推定される ⇒＃ %閲覧~文脈 にて`作動中な文書$bcの`容器~文書$doc ~EQ ~NULL ／ %閲覧~文脈 には`先祖~閲覧~文脈$は無い ／ %閲覧~文脈 は`~top-level閲覧~文脈$である
（最初に挙げたものが正しいように思われるが、 他でも，~algoの結果は同じになるかもしれない。）
4.5. %要請 に対する %応答 は混在~内容として阻止されるべきか？
注記： 要請が続行される 場合でも，依然として、 対する応答を，それを生成した接続の状態に基づいて 阻止するよう求まれることがある（例： 要請は`阻止-可能$であるが，接続は`未認証$であるためなど）。 加えて，［ ~swが、 `阻止-可能$な要請に対し，不用意に`未認証な応答$を返さない ］ことも確保する必要がある。 この~algoは、 これらを決定するために利用される。 ◎ Note: If a request proceeds, we still might want to block the response based on the state of the connection that generated the response (e.g. because the request is blockable, but the connection is unauthenticated), and we also need to ensure that a Service Worker doesn’t accidentally return an unauthenticated response for a blockable request. This algorithm is used to make that determination.
~UAは、 次の~algoに従って，所与の ( `要請$ %要請, `応答$ %応答 ) に対し，応答を返すべきかどうかを決定する： ◎ Given a request request and response response, the user agent determines what response should be returned via the following algorithm:
-
~RET ［ ~OR↓ が満たされるならば `許容される^i ／ ~ELSE_ `阻止される^i ］： ◎ Return allowed if one or more of the following conditions are met:
- `設定群は混在~security文脈を禁制するか？$( %要請 の`~client$rq ) の結果 ~EQ `禁制しない^i ◎ § 4.3 Does settings prohibit mixed security contexts? returns Does Not Restrict Mixed Content when applied to request’s client.
- %応答 の`~URL$rsは`信用に価し得る~URL$である ◎ response’s url is a potentially trustworthy URL.
- ~UAは — `§ 利用者-制御$に述べるように — `混在~内容$を許容するよう指図されている ◎ The user agent has been instructed to allow mixed content, as described in § 7.2 User Controls).
-
［ %要請 の`行先$rq ~EQ `document^l ］~AND［ %要請 は`~top-level~navi$である ］ ◎ request’s destination is "document", and request’s target browsing context has no parent browsing context.
注記： `~top-level~navi$は，混在~内容~検査からは除外されるが、 ~UAは，~secureでない~form提出に対しては 混在~内容~検査を施行することを選んでもヨイ（ `§ ~form提出$を見よ）。 ◎ Note: We exclude top-level navigations from mixed content checks, but user agents MAY choose to enforce mixed content checks on insecure form submissions (see § 7.1 Form Submission). ◎ ↑↑ Return blocked.
5. 統合
5.1. ~fetchに対する改変
`~main~fetch$ `FETCH$r は、 次のように改変されるベキである ⇒ 段 3, 4 の合間で次を~callする ⇒ 適切になるなら，混在~内容への要請を信用に価し得る~URLへ昇格する ◎ Fetch § 4.1 Main fetch should be modified to call § 4.1 Upgrade a mixed content request to a potentially trustworthy URL, if appropriate on request between steps 3 and 4.＼
【 この改変は、 すでに `FETCH$r に統合された。 】
すなわち，`昇格-可能$な混在~内容は、 混在~内容の阻止-法を適用する前に，~HTTPSに自動昇格されるベキである。 ◎ That is, upgradeable mixed content should be autoupgraded to HTTPS before applying mixed content blocking.
5.2. ~HTMLに対する改変
【 ~HTMLが更新されたため、 以下に述べられる改変は，今や どう適用すべきか不明瞭になっている （何らかの別の形で，すでに統合-済みかもしれない）。 】
`~navigate応答を処理する$は、 次に従って改変されるベキである。 段 3 は、 次が満たされる場合には，~downloadを中止して ~RET するベキである ⇒ ［ %source にて`作動中な文書$navの`~URL$docは`信用に価し得る~URL$である ］~AND［ %応答 の`~URL~list$rs内に`信用に価し得る~URL$でない~URLがある ］ ◎ Process a navigate response should be modified as follows. Step 3 should abort the download and return if source’s active document’s URL is a potentially trustworthy URL and any URL in response’s URL list is not a potentially trustworthy URL.
類似な変更は、 `~hyperlinkを~downloadする$にも為されるベキである。 この~algoの段 6.2 は、 次が満たされる場合は ~RET する（~downloadを中止する）よう改変されるベキである ⇒ ［ %要素【！~subject】 の`~node文書$の`~URL$docは`信用に価し得る~URL$である ］~AND［ 応答（ %要請 を~fetchした結果）の`~URL~list$rs内に`信用に価し得る~URL$でない~URLがある ］ ◎ A similar change should be made to download the hyperlink. In this algorithm, step 6.2 should be modified to return (aborting the download) if subject’s node document’s URL is a potentially trustworthy URL and any URL in response’s URL list is not a potentially trustworthy URL (where response is the result of fetching request).
注記： ~downloadは、 他の型の混在~内容の様には自動昇格されない — ~UAは、 ~downloadされることになるかどうか，資源を要請する前に常に知るとは限らないので。 ◎ Note: Downloads are not autoupgraded like other types of mixed content, because the user agent does not always know before requesting a resource that it will be downloaded.
注記： 資源は、［ ~downloadを中止するかどうか，~UAが~secureでない接続に基づいて裁定する前 ］に~downloadされる。 したがって，~UAが当の~downloadを最終的に阻止するとしても、 敏感な情報は，~networkを辿ることになろう。 これは、 一般には避けれない — ~UAは、 `最終-応答$を受信するまでは，資源が~downloadされることになるかどうか知らないこともあるので。 であるが，~UAが資源を阻止すれば、 ~downloadを~secure接続~越しに~serveするよう，~web~site運用者に奨励することになる。 ◎ Note: Resources are downloaded before the user agent decides whether to abort them based on an insecure connection. Sensitive information may therefore traverse the network even though the user agent eventually blocks the download. This is generally unavoidable because the user agent may not know that a resource is to be downloaded until it receives the final response, but by blocking the resource, user agents will encourage website operators to serve downloads over secure connections.
6. 廃用化
6.1. 混在~内容の厳密な検査-法
この仕様の早期の~versionは， `block-all-mixed-content^dir ~CSP指令を定義したが、 今や廃用にされた — 自動昇格できない混在~内容は、 今やすべて阻止されるので。 ◎ An earlier version of this specification defined the block-all-mixed-content CSP directive. It is now obsolete, because all mixed content is now blocked if it can’t be autoupgraded.
注記： `upgrade-insecure-requests$dir 指令 `UPGRADE-INSECURE-REQUESTS$r は、 廃用にされない。 それは、 `阻止-可能$な内容を昇格することを開発者に許容する。 この仕様は、 `昇格-可能$な内容に限り，既定で昇格する。 ◎ Note: The upgrade-insecure-requests ([upgrade-insecure-requests]) directive is not obsolete because it allows developers to upgrade blockable content. This specification only upgrades upgradeable content by default.
7. ~securityと~privacyの考慮点
`昇格-可能$な混在~内容の自動昇格は、 総じて，~security, ~privacyを~~向上させると期待される — 利用者の流通を~network上で［ 盗聴する／改竄する ］ことから より保護するので。 ◎ Overall, autoupgrading upgradeable mixed content is expected to be security- and privacy-positive, by protecting more user traffic from network eavesdropping and tampering.
開発者が意図しなかった資源を読込むことには、 ~web~page内に［ ~security／~privacy ］課題を導入する~riskがある。 例えば、 ある~web~siteが `http://www.example.com/image.jpg^s から差し障りない画像を含めていて，それが何らかの理由で追跡~siteへ~redirectされた場合など。 ~browserは、 今や［ 開発者／利用者 ］の明示的な同意なしに~privacy課題を導入することになる。 しかしながら，これらの事例は、 ごくまれにしかないと期待される。 この~riskは — `阻止-可能$な内容は自動昇格することなく — `昇格-可能$な内容に限り自動昇格することで，軽減される。 `阻止-可能$な内容には、 他にも~riskが在り得る — 例えば、 古過ぎて脆弱な~JS~libraryを読込む~riskなど。 ◎ There is a risk of introducing a security or privacy issue in a webpage by loading a resource that the developer did not intend. For example, suppose that a website includes an innocuous image from http://www.example.com/image.jpg, and for some reason https://www.example.com/image.jpg redirects to a tracking site. The browser will now have introduced a privacy issue without the developer’s or user’s explicit consent. However, these cases are expected to be exceedingly rare. The risk is mitigated by autoupgrading only upgradeable content, not blockable content as well. Blockable content could present more risk, for example the risk of loading an out-of-date and vulnerable JavaScript library.
7.1. ~form提出
所与の`文書$ %文書 に対し，［ `設定群は混在~security文脈を禁制するか？$( %文書 に`関連な設定群~obj$ ) ］の結果が `禁制する^i になる場合、 ~UAは： ◎ If § 4.3 Does settings prohibit mixed security contexts? returns Restricts Mixed Content when applied to a Document's relevant settings object,＼
- %文書 内に次を満たす `form$e 要素が在るときには，そのことを利用者に警告してもヨイ ⇒ `action$a 属性を有していて，その値は`信用に価し得る~URL$でない ◎ then a user agent MAY choose to warn users of the presence of one or more form elements with action attributes whose values are not potentially trustworthy URLs.
- 前項に該当する `form$e 要素による提出に際しては、 次を行うことにしてもヨイ ⇒ 利用者に警告した上で、 当の提出を中止することを利用者に許容する ◎ A user agent MAY choose to warn users on submission of a form element with action attributes whose values are not potentially trustworthy URLs and allow users to abort the submission.＼
- 前項のようにふるまう場合、 他の `form$e 要素による提出に際しても，`信用に価し得る~URL$でない~URLへ~redirectされたときは — 利用者が~form情報を公開しないことを選べるよう — 同様にふるまうベキである。 ◎ If a user agent warns on form element submissions to not potentially trustworthy URLs, it SHOULD also warn and allow users to abort the submission if upon submission, the form element’s action, redirects to a non potentially trustworthy URL, exposing the form information.
- %文書 からの~form提出を — %文書 が`属する閲覧~文脈$が`~top-level閲覧~文脈$であっても — `阻止-可能$な要請として扱ってもヨイ。 ◎ Further, a user agent MAY treat form submissions from such a Document as a blockable request, even if the submission occurs in the top-level browsing context.
【 より一般には、 `form^e 要素のみならず，`動作$が等価になる他の要素（ `formaction$a 属性を有する`提出-~button$）にも適用されよう。 】
7.2. 利用者-制御
~UAは、 特定0の~page上で［ `阻止-可能$な混在~内容を阻止する裁定 ］を上書きする能を，利用者に提供してもヨイ。 ◎ A user agent MAY offer users the ability to override its decision to block blockable mixed content on a particular page.
注記： 実施上は、 ~UAはおそらく，そのような裏口を提供したままで済ますわけにはいかない。 すなわち、 混在~scriptを許容する~optionは，特に危険である。 ~UAは，そのような選択肢を — 熟慮の下で［ 孕まれる~riskについて利用者に伝え, やりとりする ］ことなく — 呈示することは，~~本当はやってはいけない（ REALLY SHOULD NOT `RFC6919$r ）。 ◎ Note: Practically, a user agent probably can’t get away with not offering such a back door. That said, allowing mixed script is in particular a very dangerous option, and each user agent REALLY SHOULD NOT [RFC6919] present such a choice to users without careful consideration and communication of the risk involved.
~UAは、 特定0の~page上で［ `昇格-可能$な混在~内容を阻止する裁定 ］を上書きする能を，利用者に提供してもヨイ。 ◎ A user agent MAY offer users the ability to override its decision to automatically upgrade upgradeable mixed content on a particular page.
これらの制御を提供する~UAは、 支援技術の利用者にも，~accessibility~APIを通して提供するモノトスル。 ◎ Any such controls offered by a user agent MUST also be offered through accessibility APIs for users of assistive technologies.
8. 謝辞
WebAppSec ~WGから集められた，賞賛すべき~feedbackに加えて、 Chrome の~security~teamが，この仕様にかけた準備は計り知れない。 特に、 早期に多数の~feedbackを寄せられた `Chris Palmer, Chris Evans, Ryan Sleevi, Michal Zalewski, Ken Buchanan, Tom Sepez^en 各~氏。 `Anne van Kesteren^en 氏は、 Fetch を説明され, この仕様への~interfaceを定義することに助力され, ~level 2† の更新に貴重な~feedbackを供された。 `Brian Smith^en 氏は、 この仕様を注目させ, 手入れし, 健全に保つことに助力された。 【†この仕様は、過去には，~level 1, ~level 2 に分けられていた。】 ◎ In addition to the wonderful feedback gathered from the WebAppSec WG, the Chrome security team was invaluable in preparing this specification. In particular, Chris Palmer, Chris Evans, Ryan Sleevi, Michal Zalewski, Ken Buchanan, and Tom Sepez gave lots of early feedback. Anne van Kesteren explained Fetch, helped define the interface to this specification, and provided valuable feedback on the Level 2 update. Brian Smith helped keep the spec focused, trim, and sane.