webappsec-mixed-content-ja.html

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

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

<style>
samp {
	white-space: nowrap;
	background: var(--bg-color-1);
	margin-left: 0.5em;
	margin-right: 0.5em;
}
</style>

<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 text = key;
let href = '';

switch(klass){
case 'r':
	text = `[${key}]`;
	href = `#biblio-${key.toLowerCase()}`;
	break;
case 'l':
	return `"<code class="literal">${key}</code>"`;
	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 = 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_date:2023-01-26
trans_update:2023-01-30
source_checked:211002
page_state_key:WEBAPPSEC
original_url:https://w3c.github.io/webappsec-mixed-content/
	abbr_url:MIXED-CONTENT
spec_status:ED
ref_id_prefix:biblio-
ref_id_lowercase:true
	conformance:w3c
copyright:2021,permissive
trans_1st_pub:2019-09-12


●●class_map
P:production
dir:directive
h:header
e:element
a:attr
et:event-type
p:property
E:error

●●tag_map
P:code
dir:code
h:code
e:code
a:code
et:code
p:code
I:code
m:code
E:code
v:var
c:code
s:samp
i:i
em:em

●●original_id_map

●●link_map

	●code

	I.Document:~DOM4#document → ~HTMLdom#the-document-object
I.XMLHttpRequest:~XHR#xmlhttprequest

e.img:~HEimages#the-img-element
e.audio:~HEmedia#the-audio-element
e.video:~HEmedia#the-video-element
e.source:~HEimages#the-source-element
e.form:~HEforms#the-form-element

a.action:~HTMLforms#attr-fs-action
a.formaction:~HTMLforms#attr-fs-formaction
	~HEimages#use-srcset-or-picture
a.crossorigin:~HEimages#attr-img-crossorigin

p.background-image:~CSSBG#propdef-background-image
p.border-image:~CSSBG#propdef-border-image

dir.upgrade-insecure-requests:~UPGRADE-INSECURE-REQUESTS#upgrade-insecure-requests

	●用語
混在~内容:#mixed-content
未認証:#unauthenticated-response
未認証な応答:#unauthenticated-response
阻止-可能:#blockable-mixed-content

昇格-可能:#upgradeable-mixed-content
混在~download:#mixed-download
埋込んでいる文書:#embedding-document
先天的に認証-済みな~URL:#a-priori-authenticated-url

	●§
§ 利用者-制御:#requirements-user-controls
§ ~form提出:#requirements-forms
設定群は混在~security文脈を禁制するか？:#categorize-settings-object
要請の~fetchingは混在~内容として阻止されるべきか？:#should-block-fetch
要請に対する応答は混在~内容として阻止されるべきか？:#should-block-response

	昇格-可能な内容:#category-upgradeable → 昇格-可能
	阻止-可能な内容:#category-blockable → 阻止-可能

	●用語（外部
信用に価し得る~URL:~SECURE-CONTEXT#potentially-trustworthy-url
信用に価し得る生成元:~SECURE-CONTEXT#potentially-trustworthy-origin

~IP~address:~URL1#ip-address
url.~scheme:~URL1#concept-url-scheme
url.~host:~URL1#concept-url-host

~main~fetch:~FETCH#main-fetch
要請:~FETCH#concept-request
rq.~URL:~FETCH#concept-request-url
rq.~client:~FETCH#concept-request-client
rq.行先:~FETCH#concept-request-destination
rq.起動元:~FETCH#concept-request-initiator
rq.予約-済み~client:~FETCH#concept-request-reserved-client

応答:~FETCH#concept-response
rs.~URL~list:~FETCH#concept-response-url-list
rs.~URL:~FETCH#concept-response-url
~navi要請:~FETCH#navigation-request

doc.~URL:~DOM4#concept-document-url
doc.生成元:~DOM4#concept-document-origin
~node文書:~DOM4#concept-node-document

文書:~HTMLdom#the-document-object
~plugin:~HTMLINFRA#plugin
~hyperlinkを~downloadする:~HTMLlinks#downloading-hyperlinks

動作:~HTMLforms#concept-fs-action
提出-~button:~HEforms#concept-submit-button

~navigable:~HTMLds#navigable
先祖~navigable群:~HTMLds#ancestor-navigables
nav.作動中な文書:~HTMLds#nav-document
bc.作動中な文書:~HTMLds#active-document
閲覧~文脈:~HTMLds#browsing-context
先祖~閲覧~文脈:~HTMLds#ancestor-browsing-context
属する閲覧~文脈:~HTMLds#concept-document-bc
~top-level辿可能:~HTMLds#top-level-traversable
~top-level~navi:#_top-level-navigation
~top-level閲覧~文脈:~HTMLds#top-level-browsing-context
doc.容器~文書:~HTMLds#doc-container-document
	廃）容器~文書:~BROWSERS#bc-container-document
	廃）親~閲覧~文脈:~BROWSERS#parent-browsing-context

~window:~WINDOW#the-window-object
	:~WINDOW#dom-window
結付けられた文書:~WINDOW#concept-document-window

~navi~algo:~HTMLnav#navigate
~navigate応答を処理する:~HTMLnav#process-a-navigate-response
	廃）~source閲覧~文脈:~NAVI#source-browsing-context

環境:~WAPI#environment
環境~設定群~obj:~WAPI#environment-settings-object
enV.生成元:~WAPI#concept-settings-object-origin
enV.大域~obj:~WAPI#concept-settings-object-global
	廃）enV.担当の文書:~WAPI#responsible-document
enV.~target閲覧~文脈:~WAPI#concept-environment-target-browsing-context
関連な設定群~obj:~WAPI#relevant-settings-object


	指令:~CSP3#directives
最終-応答:~HTTPsem#final-response

	~TR/wsc-ui/#securepage
	~TR/2008/REC-xml-20081126/#sec-mixed-content
	~RFCx/rfc6919#section-3


●●words_table1

UPGRADE-INSECURE-REQUESTS:webappsec-upgrade-insecure-requests-ja.html
data_scheme:<code class="scheme">data:</code>

●●words_table


	●network
Fetch:
実体:entity:~
IP:
	~web~site:website
	~web~page:webpage

	●mixed／CSP
混在:mixed::~
混在-:mix::~
先天的:a priori:~
後天的:a posteriori:~
随意:optional::~
	随意に:optionally-
昇格-:upgrade::~
昇格:upgrade::~
自動昇格:autoupgrading::~
自動昇格-:autoupgrade::~
禁制-:prohibit:~
	禁制しない:Does Not Restrict Mixed Security Contents

	古過ぎて:out-of-dateで
	阻止-可能:blockable
	阻止-法:blocking
	阻止される^i:Blocked

	●保安
弱めら:weakenさ:~
暗号化-:encrypt::~
盗聴-:eavesdrop:~
改竄-:tamper:改ざん
認証-:authenticate::~
	認証-済み:authenticated
未認証:unauthenticated::~
	未認証な:unauthenticated
機密性:confidentiality::~
脆弱:vulnerable::~
誘導-:induce:~
錠前:padlock:~
同意:consent:~
偽造-:fabricate:~
逃れる:escapeする:~
劣化-:degrade:~
危険:dangerous:~
破滅的:catastrophic:~
裏口:back door:~
実害:real impact:~
迂回-:bypass:~

	差し障りない:innocuous
	非~secureに:insecure
	~secureでない:insecure
	実行-可能:executable
	~~誤認させる:misleadする
	価し得る:potentially trustworthy

	●仕様
今日:today:~
機能-:function:~
廃用化:obsolescences:~
心的:mental:~
為す:makeする:~
為され:makeされ:~
分類法:categorization:~
分類:category:~
分類-:categorize:~
利用率:usage:~
不用意:accidental:~
中心的:central:~
仲介-:mediate:~
健全:sane:~
警告-:warn:~
念頭:mind:~
実施上は:practicalには:実施においては
指図-:instruct:~
按配よく:nuancedに:~
支援技術:assistive technologies:~
熟慮:careful consideration:~
立場-:position:~
重視-:outweigh:~
助力-:help:~
広範:wide:~
貴重:valuable:~
保つ:keepする:~

	利する:on behalf of
	さらには:moreover
	勧める:advise
	区別:distinction
	半端な:in-between
	現時点:currently
	この~level 2 仕様:Mixed Content Level 2
	~level:Level
	総じて:overall
	とする:suppose
	ごくまれにしかない:exceedingly rare
	まだ:not already
	駆り立てるほどのもの:proved a sufficient incentive
	~~向上させ:-positive
	向かって進む:advances us towards
	主要な:key
	避けれない:unavoidable
	計り知れな:invaluable
	形作る:carve out
	手入れ:trim
	~~主要:key
	事実:fact
	使われ続け:usage
	賞賛すべき:wonderful
	ほぼ至る所:near ubiquitious
	注目させ:focused
	済ますわけにはいかない:can’t get away
	準備:preparing
	相当数の:substantial number
	選んで:choose
	行うことにして:choose
	選択肢:choice
	好例:good example
	十分に高い:sufficient
	~~本当は:
	全面的に:outright
	早期:early
	伝え:-
	担当する:
	担当の:responsible
	称され:referred
	~level:Level
	早期の:earlier
	分けて:divide
	~~普及:prevalent

	●未分類
UX:
運用者:operator:~
失敗ng:failing:失敗
	失敗ngを強制する:force-failing
最終-:final:~
書直す:rewriteする:書き直す
main:
株価図表:stock chart:~:::株価チャート
銀行取引明細:bank statement:~
埋込元:embedder::埋め込み元
理想世界:perfect world:~
続行-:proceed:~
実行ng:executing:実行
team::::チーム
email::::メール
Internet:

	~sw:Service Worker
	~~費やす:amount
	量:amount
	-:render
	一定の:certain
	最終的に:eventually
	“~~削除” “~~返信”:"Delete email" and "Reply"
	10 年以上:more than a decade
	逆に:reverse
	集めら:gather
	改変されていない:left unmodified

	●指示語
部位:portion:範囲

	側:-side
	まるごと:entirely
	以前は:previously
	他にも:more
	低:low
	低い:less

●●ref_normative

[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/
[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/
[SECURE-CONTEXTS]
    Mike West. ＜Secure Contexts＞. URL: https://w3c.github.io/webappsec-secure-contexts/
[URL]
    Anne van Kesteren. ＜URL Standard＞. Living Standard. URL: https://url.spec.whatwg.org/
[XHR]
    Anne van Kesteren. ＜XMLHttpRequest Standard＞. Living Standard. URL: https://xhr.spec.whatwg.org/

●●ref_informative

[CSS-BACKGROUNDS-3]
    Bert Bos; Elika Etemad; Brad Kemper. ＜CSS Backgrounds and Borders Module Level 3＞. URL: https://drafts.csswg.org/css-backgrounds/
[RFC6919]
    R. Barnes; S. Kent; E. Rescorla. ＜Further Key Words for Use in RFCs to Indicate Requirement Levels＞. 1 April 2013. Experimental. URL: https://www.rfc-editor.org/rfc/rfc6919
[UPGRADE-INSECURE-REQUESTS]
    Mike West. ＜Upgrade Insecure Requests＞. URL: https://w3c.github.io/webappsec-upgrade-insecure-requests/
[WSC-UI]
    Thomas Roessler; Anil Saldhana. ＜Web Security Context: User Interface Guidelines＞. 12 August 2010. REC. URL: https://www.w3.org/TR/wsc-ui/
[XML]
    Tim Bray; et al. ＜Extensible Markup Language (XML) 1.0 (Fifth Edition)＞. 26 November 2008. REC. URL: https://www.w3.org/TR/xml/


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


●●spec_metadata

最新公表バージョン
	https://www.w3.org/TR/mixed-content/
公表履歴
	https://www.w3.org/standards/history/mixed-content/
commit 履歴
	https://github.com/w3c/webappsec-mixed-content/commits/main

フィードバック
	<a href="mailto:public-webappsec@w3.org?subject=%5Bmixed-content%5D%20YOUR%20TOPIC%20HERE">public-webappsec@w3.org</a> with subject line “<kbd>[mixed-content] <i>… message topic …</i></kbd>” (<a href="https://lists.w3.org/Archives/Public/public-webappsec/" rel="discussion">archives</a>)
	https://github.com/w3c/webappsec-mixed-content/issues
	<a href="https://github.com/w3c/webappsec-mixed-content/issues/new">File an issue</a> (<a href="https://github.com/w3c/webappsec-mixed-content/issues">open issues</a>)

実装報告
	https://wpt.fyi/results/mixed-content

編集
	<a href="mailto:estark@google.com">Emily Stark</a> (Google Inc.)
	<a href="mailto:mkwst@google.com">Mike West</a> (Google Inc.)
	<a href="mailto:carlosil@google.com">Carlos Ibarra Lopez</a> (Google Inc.)

この文書に対する変更点
	https://github.com/w3c/webappsec
公表者
	<a href="https://www.w3.org/groups/wg/webappsec">Web Application Security WG</a>

</script>

</head>
<body>

<header>
	<hgroup>
<h1>混在内容 — Mixed Content</h1>
	</hgroup>
</header>

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

<p>
この仕様は、［
暗号化され かつ認証-済み
］な文書の文脈において，［
暗号化されない または未認証
］な接続~越しの内容~fetchingを，~UAがどう取扱うベキかについて述べる。
◎
This specification describes how a user agent should handle fetching of content over unencrypted or unauthenticated connections in the context of an encrypted and authenticated document.
</p>

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

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

	</section>

<main id="MAIN0">

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

◎非規範的

<p>
利用者が
`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.
</p>

<p>
この仕様は、
これらの~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.
</p>

<p>
しかしながら，この仕様の早期の~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.
</p>

<p>
さらには，利用者にとっては、
混在~内容が読込まれたことを表す明瞭な~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.
</p>

<p>
なので，この仕様は、［
非互換化は最小限にしつつ，より良い［
~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:
</p>
<ul>
	<li>
~UAがまだ阻止していない混在~内容は、
~secure~transportに自動昇格されるベキである。
◎
Mixed content that user agents are not already blocking should be autoupgraded to a secure transport.
</li>
	<li>
自動昇格できない要請は、
阻止されることになる。
◎
If the request cannot be autoupgraded, it will be blocked.
</li>
</ul>

<p>
自動昇格は、
非互換化を避けるために必要な開発者が~~費やす労を最小限にしつつ，
~secureな~web~page上で~secureでない資源を読込むのを避ける。
◎
Autoupgrading avoids loading insecure resources on secure webpages, while minimizing the amount of developer effort needed to avoid breakage.
</p>

<p>
この仕様は、［
現時点では，既定では阻止されていない型の混在~内容を成す下位資源
］に限り，自動昇格を推奨する
— すでに阻止されている型の内容に自動昇格を推奨するものではない。
これは、
~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.
</p>

<p>
この仕様はまた，`混在~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.
</p>

	</section>
	<section id="terms">
<h2 title="Key Concepts and Terminology">2. 主要な概念と各種用語</h2>

<dl>
	<dt>
`混在~内容@
（ `mixed content^en ）
</dt>
	<dd>
<p>
~AND↓ を満たす`要請$は、
`混在~内容$とされる：
</p>
		<ul>
			<li>
その`~URL$rqは`信用に価し得る~URL$でない `SECURE-CONTEXTS$r
</li>
			<li>
その読込ngを担当する文脈は、
混在~security文脈を禁制している†
</li>
		</ul>
◎
A request is mixed content if its URL is not a potentially trustworthy URL [SECURE-CONTEXTS] and the context responsible for loading it prohibits mixed security contexts (see § 4.3 Does settings prohibit mixed security contexts? for a normative definition of the latter).
</dd>
	<dd>
<p>
~AND↓ を満たす`応答$は、
`混在~内容$とされる：
</p>
		<ul>
			<li>
`未認証な応答$である
</li>
			<li>
その読込ngを担当する文脈は、
混在~security文脈を禁制するよう要求している†
</li>
		</ul>
◎
A response is mixed content if it is an unauthenticated response, and the context responsible for loading it requires prohibits mixed security contexts.
</dd>
	<dd>†
規範的な定義は、
`設定群は混在~security文脈を禁制するか？$を見よ。
◎
↑</dd>
	<dd class="example">
<p>
混在~内容を制約する文脈（例：
`https://secure.example.com/^s
）の内側では：
◎
Inside a context that restricts mixed content (https://secure.example.com/, for example):
</p>
		<ul>
			<li>
`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.
</li>
			<li>
`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.
</li>
		</ul>
	</dd>
	<dd class="note">注記：
“混在~内容” は、
元々は
`WSC-UI$r
<a href="~TR/wsc-ui/#securepage">§ 5.3</a>
にて定義された。
この文書は、
それによる初期の定義を更新する。
◎
Note: "Mixed content" was originally defined in section 5.3 of [WSC-UI]. This document updates that initial definition.
</dd>
	<dd class="note">注記：
`XML$r も無関係な
<a href="~TR/2008/REC-xml-20081126/#sec-mixed-content">混在~内容</a>
の概念を定義しているが、
この用語は，各~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.
</dd>

	<dt>
`未認証な応答@
（ `unauthenticated response^en ）
</dt>
	<dd>
`応答$は、［
その`~URL$rsが`信用に価し得る~URL$でない
］ならば，未認証であることが`後天的^em（
<span lang="fr">a posteriori</span>
）に既知となる
◎
We know a posteriori that a response (response) is unauthenticated if response’s URL is not a potentially trustworthy URL.
</dd>

	<dt>
`埋込んでいる文書@
（ `embedding document^en ）
</dt>
	<dd>
所与の`文書$を`埋込んでいる文書$は、
それが`属する閲覧~文脈$の容器~文書を指す。
`HTML$r
◎
Given a Document A, the embedding document of A is A’s browsing context's container document [HTML].
</dd>
	<dd class="trans-note">【
“`閲覧~文脈$の容器~文書” は廃された用語。
単に，当の文書の`容器~文書$docを指す
— そう記しても同じことなので、
この訳では，この用語は利用しない。
】</dd>

	<dt>
`混在~download@
（ `mixed download^en ）
</dt>
	<dd>
混在~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.
</dd>
</dl>

<p class="note">注記：
【過去に利用されていた用語】
`先天的に認証-済みな~URL@
（ `<span lang="la">a priori</span> authenticated URL^en ）
は、
`信用に価し得る~URL$ `SECURE-CONTEXTS$r に等価である。
◎
An a priori authenticated URL is equivalent to a potentially trustworthy URL [SECURE-CONTEXTS].
</p>

	</section>
	<section id="categories">
<h2 title="Content Categories">3. 内容の分類</h2>

<p>
理想世界では、
各~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.
</p>

<p>
そのことを念頭に、
ここでは，混在~内容を［
`昇格-可能$なもの, `阻止-可能$なもの
］の 2 つに分類する。
◎
With that in mind, we here split mixed content into two categories: § 3.1 Upgradeable Content and § 3.2 Blockable Content.
</p>

		<section id="category-upgradeable">
<h3 title="Upgradeable Content">3.1. 昇格-可能な内容</h3>

<p class="note">注記：
`昇格-可能$な内容は、
この仕様の早期の~versionでは，
`随意に阻止-可能^em
（ `optionally-blockable^en ）と称されていた。
◎
Upgradeable content was previously referred to as optionally-blockable in earlier versions of this specification. 
</p>

<p>
`混在~内容$は、［
`混在~内容$としての用法を許容する~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.
</p>

<p>
これに分類されるものには次が挙げられる：
◎
This category includes:
</p>
<ul>
	<li>
<p>
次を満たす要請
⇒
［
`起動元$rq ~EQ 空~文字列
］~AND［
`行先$rq ~EQ `image^l
］
◎
Requests whose initiator is the empty string, and whose destination is "image".
</p>

<p class="note">注記：
`img$e 要素や~CSS（ `background-image$p, `border-image$p, 等々）を介して読込まれるほとんどの画像は、
これに対応する（画像として読込まれる~SVG文書も含まれる
— それらによる［
~scriptの実行ng／下位資源の~fetching
］は阻止されるので）。
`img$e 要素のうち
<a href="~HEimages#use-srcset-or-picture">`srcset^a または `picture^e を利用して</a>
いるものは含まれない。
◎
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.
</p>
	</li>
	<li>
<p>
次を満たす要請
⇒
`行先$rq ~EQ `video^l
◎
Requests whose destination is "video".
</p>

<p class="note">注記：
［
`video$e ／ `source$e
］要素を介して読込まれる動画は、
これに対応する。
◎
Note: This corresponds to video loaded via video and source.
</p>
	</li>
	<li>
<p>
次を満たす要請
⇒
`行先$rq ~EQ `audio^l
◎
Requests whose destination is "audio".
</p>

<p class="note">注記：
［
`audio$e ／ `source$e
］要素を介して読込まれる音声は、
これに対応する。
◎
Note: This corresponds to audio loaded via audio and source.
</p>
	</li>
</ul>

<p>
この分類は、
`要請の~fetchingは混在~内容として阻止されるべきか？$において，［
~CORSが可能化された要請には失敗ngを強制する
］ことにより、
更に制限される。
これは例えば、
<samp>&lt;`img$e `crossorigin$a ...&gt;</samp>
を介して読込まれる混在~内容~画像は阻止されることを意味する。
上に挙げたものは、［
この分類に該当する内容は，［
全面的に阻止するには，広範に利用され過ぎている
］ものに`限られる^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 &lt;img crossorigin ...&gt; 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.
</p>

		</section>
		<section id="category-blockable">
<h3 title="Blockable Content">3.2. 阻止-可能な内容</h3>

<p>
上に定義した`昇格-可能$でない，どの`混在~内容$も
`阻止-可能@
（ `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.
</p>

<p class="note">注記：
`~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.
</p>

<p class="note">注記：
~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.
</p>

		</section>
	</section>
	<section id="algorithms">
<h2 title="Algorithms">4. ~algo</h2>

<!-- 
<p class="trans-note">【
原文によるこの返り値の記述は一貫していないので、
この訳では…
Prohibits Mixed Security Contexts
Restricts Mixed Content
Restricts Mixed Security Context
Does Not Prohibit Mixed Security Contexts
Does Not Restrict Mixed Security Contexts
】</p>
 -->

		<section id="upgrade-algorithm">
<h3 title="Upgrade a mixed content request to a potentially trustworthy URL, if appropriate">4.1. 適切になるなら，混在~内容への要請を信用に価し得る~URLへ昇格する</h3>

<p class="note">注記：
~Fetch仕様は、
この~algoの中へ~hookして，`昇格-可能$な混在~内容を~HTTPSへ昇格することになる。
◎
Note: The Fetch specification will hook into this algorithm to upgrade upgradeable mixed content to HTTPS.
</p>

<div class="algo">
<p>
この~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:
</p>
<ol>
	<li>
<p>
~IF［
~OR↓
］…
◎
If one or more of the following conditions is met, return without modifying request:
</p>
		<ul>
			<li>
%要請 の`~URL$rqは`信用に価し得る~URL$である
◎
request’s URL is a potentially trustworthy URL.
</li>
			<li>
%要請 の`~URL$rqの`~host$urlは`~IP~address$である
◎
request’s URL’s host is an IP address.
</li>
			<li>
`設定群は混在~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.
</li>
			<li>
%要請 の`行先$rq ~NIN { `image^l, `audio^l, `video^l }
◎
request’s destination is not "image", "audio", or "video".
</li>
			<li>
<p>
［
%要請 の`行先$rq ~EQ  `image^l
］~AND［
%要請 の`起動元$rq ~EQ `imageset^l
］
◎
request’s destination is "image" and request’s initiator is "imageset".
</p>

<p class="note">注記：
歴史的な理由から、
`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.
</p>
			</li>
		</ul>
<p>
…ならば
⇒
~RET
（ %要請 は改変されない）
◎
↑</p>
		</li>
		<li>
<p>
~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.
</p>

<p class="note">注記：
`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
</p>
	</li>
</ol>
</div>

		</section>
		<section id="existing-mix-algorithms">
<h3 title="Modifications to previous algorithms">4.2. 以前の~algoに対する改変</h3>

<p class="note">注記：
以下の節は、
この仕様の早期の~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.
</p>

		</section>
		<section id="categorize-settings-object">
<h3 title="Does settings prohibit mixed security contexts?">4.3. %設定群 は混在~security文脈を禁制するか？</h3>

<div class="algo">
<p>
`文書$, ~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):
</p>
<ol>
	<li>
~IF［
%設定群 の`生成元$enVは`信用に価し得る生成元$である
］
⇒
~RET `禁制する^i
◎
If settings’ origin is a potentially trustworthy origin, then return "Prohibits Mixed Security Contexts".
</li>
	<li>
<p>
~IF［
%設定群 の`大域~obj$enVは`~window$である
］：
◎
If settings’ global object is a window, then:
</p>
		<ol>
			<li>
%文書 ~LET %設定群 の`大域~obj$enVに`結付けられた文書$
◎
Set document to settings’ global object's associated Document.
</li>
			<li>
%文書 の`先祖~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".
</li>
		</ol>
	</li>
	<li>
~RET `禁制しない^i
◎
Return "Does Not Restrict Mixed Security Contexts".
</li>
</ol>
</div>

<div class="note">

<p>注記：
文書の`容器~文書$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:
</p>
<ul class="example">
	<li>
`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.
</li>
	<li>
`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.
</li>
	<li>
`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.
</li>
	<li>
`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.
</li>
</ul>
</div>

		</section>
		<section id="should-block-fetch">
<h3 title="Should fetching request be blocked as mixed content?">4.4. %要請 の~fetchingは混在~内容として阻止されるべきか？</h3>

<p class="note">注記：
~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).
</p>

<div class="algo">
<p>
~UAは、
次の~algoを介して，所与の`要請$ %要請 を続行するべきかどうかを決定する：
◎
Given a Request request, a user agent determines whether the Request request should proceed or not via the following algorithm:
</p>
<ol>
	<li>
<p>
~RET ［
~OR↓ が満たされるならば `許容される^i ／
~ELSE_ `阻止される^i
］：
◎
Return allowed if one or more of the following conditions are met:
</p>
		<ul>
			<li>
`設定群は混在~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.
</li>
			<li>
%要請 の`~URL$rqは`信用に価し得る~URL$である
◎
request’s URL is a potentially trustworthy URL.
</li>
			<li>
~UAは
— `§ 利用者-制御$に述べるように —
`混在~内容$を許容するよう指図されている
◎
The user agent has been instructed to allow mixed content, as described in § 7.2 User Controls).
</li>
			<li>
<p>
［
%要請 の`行先$rq ~EQ `document^l
］~AND［
%要請 は`~top-level~navi$である
］
◎
request’s destination is "document", and request’s target browsing context has no parent browsing context.
</p>

<p class="note">注記：
`~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.
</p>
			</li>
		</ul>
	</li>
</ol>
</div>

<div class="trans-note">
<p>【
所与の`要請$ %要請 が
`~top-level~navi@
である条件は、
原文では，［
%要請 の`~target閲覧~文脈$enVの親~閲覧~文脈 ~EQ ~NULL
］として与えられているが：
</p>
<ul>
	<li>
`~target閲覧~文脈$enVは，`要請$ではなく`環境$に結付けられるので、
%要請 の`~target閲覧~文脈$enVは，次のいずれかを意味すると推定される
（どちらなのか，はっきりしない）
⇒＃
%要請 の`予約-済み~client$rqの`~target閲覧~文脈$enV／
%要請 の`~client$rqの`~target閲覧~文脈$enV
</li>
	<li>
<p>
用語 親~閲覧~文脈は、
~HTMLから廃された。
条件［
`閲覧~文脈$ %閲覧~文脈 の親~閲覧~文脈 ~EQ ~NULL
］は、
次のいずれかを意味すると推定される
⇒＃
%閲覧~文脈 にて`作動中な文書$bcの`容器~文書$doc ~EQ ~NULL ／
%閲覧~文脈 には`先祖~閲覧~文脈$は無い ／
%閲覧~文脈 は`~top-level閲覧~文脈$である
</p>

<p>
（最初に挙げたものが正しいように思われるが、
他でも，~algoの結果は同じになるかもしれない。）
</p>
	</li>
</ul>
</div>


		</section>
		<section id="should-block-response">
<h3 title="Should response to request be blocked as mixed content?">4.5. %要請 に対する %応答 は混在~内容として阻止されるべきか？</h3>

<p class="note">注記：
<a href="#should-block-fetch">要請が続行される</a>
場合でも，依然として、
対する応答を，それを生成した接続の状態に基づいて 阻止するよう求まれることがある（例：
要請は`阻止-可能$であるが，接続は`未認証$であるためなど）。
加えて，［
~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.
</p>

<div class="algo">
<p>
~UAは、
次の~algoに従って，所与の
( `要請$ %要請, `応答$ %応答 )
に対し，応答を返すべきかどうかを決定する：
◎
Given a request request and response response, the user agent determines what response should be returned via the following algorithm:
</p>
<ol>
	<li>
<p>
~RET ［
~OR↓ が満たされるならば `許容される^i ／
~ELSE_ `阻止される^i
］：
◎
Return allowed if one or more of the following conditions are met:
</p>
		<ol>
			<li>
`設定群は混在~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.
</li>
			<li>
%応答 の`~URL$rsは`信用に価し得る~URL$である
◎
response’s url is a potentially trustworthy URL.
</li>
			<li>
~UAは
— `§ 利用者-制御$に述べるように —
`混在~内容$を許容するよう指図されている
◎
The user agent has been instructed to allow mixed content, as described in § 7.2 User Controls).
</li>
			<li>
<p>
［
%要請 の`行先$rq ~EQ `document^l
］~AND［
%要請 は`~top-level~navi$である
］
◎
request’s destination is "document", and request’s target browsing context has no parent browsing context.
</p>

<p class="note">注記：
`~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.
</p>
			</li>
		</ol>
	</li>
</ol>
</div>

		</section>
	</section>
	<section id="integration">
<h2 title="Integrations">5. 統合</h2>

		<section id="fetch">
<h3 title="Modifications to Fetch">5.1. ~fetchに対する改変</h3>

<p>
`~main~fetch$ `FETCH$r
は、
次のように改変されるベキである
⇒
段 3, 4 の合間で次を~callする
⇒
<a href="#upgrade-algorithm">適切になるなら，混在~内容への要請を信用に価し得る~URLへ昇格する</a>
◎
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.＼
</p>

<p class="trans-note">【
この改変は、
すでに `FETCH$r に統合された。
】</p>

<p>
すなわち，`昇格-可能$な混在~内容は、
混在~内容の阻止-法を適用する前に，~HTTPSに自動昇格されるベキである。
◎
That is, upgradeable mixed content should be autoupgraded to HTTPS before applying mixed content blocking.
</p>

		</section>
		<section id="html">
<h3 title="Modifications to HTML">5.2. ~HTMLに対する改変</h3>

<p class="trans-note">【
~HTMLが更新されたため、
以下に述べられる改変は，今や どう適用すべきか不明瞭になっている
（何らかの別の形で，すでに統合-済みかもしれない）。
】</p>

<p>
`~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.
</p>

<p>
類似な変更は、
`~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).
</p>

<p class="note">注記：
~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.
</p>

<p class="note">注記：
資源は、［
~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.
</p>
		</section>
	</section>
	<section id="obsolescences">
<h2 title="Obsolescences">6. 廃用化</h2>

		<section id="strict-checking">
<h3 title="Strict Mixed Content Checking">6.1. 混在~内容の厳密な検査-法</h3>

<p>
この仕様の早期の~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.
</p>

<p class="note">注記：
`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.
</p>

		</section>
	</section>
	<section id="security-considerations">
<h2 title="Security and Privacy Considerations">7. ~securityと~privacyの考慮点</h2>

<p>
`昇格-可能$な混在~内容の自動昇格は、
総じて，~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.
</p>

<p>
開発者が意図しなかった資源を読込むことには、
~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.
</p>

		<section id="requirements-forms">
<h3 title="Form Submission">7.1. ~form提出</h3>

<p>
所与の`文書$ %文書 に対し，［
`設定群は混在~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,＼
</p>
<ul>
	<li>
%文書 内に次を満たす `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.
</li>
	<li>
前項に該当する `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.＼
</li>
	<li>
前項のようにふるまう場合、
他の `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.
</li>
	<li>
%文書 からの~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.
</li>
</ul>

<p class="trans-note">【
より一般には、
`form^e 要素のみならず，`動作$が等価になる他の要素（ `formaction$a 属性を有する`提出-~button$）にも適用されよう。
】</p>

		</section>
		<section id="requirements-user-controls">
<h3 title="User Controls">7.2. 利用者-制御</h3>

<p>
~UAは、
特定0の~page上で［
`阻止-可能$な混在~内容を阻止する裁定
］を上書きする能を，利用者に提供してもヨイ。
◎
A user agent MAY offer users the ability to override its decision to block blockable mixed content on a particular page.
</p>

<p class="note">注記：
実施上は、
~UAはおそらく，そのような裏口を提供したままで済ますわけにはいかない。
すなわち、
混在~scriptを許容する~optionは，特に危険である。
~UAは，そのような選択肢を
— 熟慮の下で［
孕まれる~riskについて利用者に伝え, やりとりする
］ことなく —
呈示することは，~~本当はやってはいけない（
<a href="~RFCx/rfc6919#section-3">REALLY SHOULD NOT</a>
`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.
</p>

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

<p>
これらの制御を提供する~UAは、
支援技術の利用者にも，~accessibility~APIを通して提供するモノトスル。
◎
Any such controls offered by a user agent MUST also be offered through accessibility APIs for users of assistive technologies.
</p>

		</section>
	</section>
	<section id="acknowledgements">
<h2 title="Acknowledgements">8. 謝辞</h2>

<p>
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.
</p>

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