Should response to request be blocked as mixed content?

Edit New

混合内容 (Web)

[8] Web における混合内容 (mixed content) とは、 HTTPS の文書から参照される HTTP のスクリプトのように、 安全なプロトコルによってもたらされた文書に含まれる安全でないプロトコル由来のデータのことをいいます。

[46] かつては混合内容も普通に用いられていましたが、 TLS を用いない素のHTTPが安全ではないとの認識が広まるにつれ、 混合内容が禁止されるようになっていきました。

[47] 現在では画像や媒体を除き、混合内容は禁止されています。 混合内容の fetch は、ネットワークエラーとなります。

仕様書

意味

[88] あるページが HTTPS (HTTP over TLS) で保護されて配送されてきたとしても、 其の表示に際して別の資源を埋め込む時に素のHTTP を使っていたら、 その Webページ全体は信頼できるとは言い切れなくなります。 特にそれがスクリプトの場合、 攻撃者によって Webページの表示全体が置き換えられる場合すらあり得ます。

[89] 混合内容制約は、 TLS で保護されているように見える Webページが、 真に保護されていることを確保するための最低限の保証と言えます。

[91] 要求は、 URL が 先験的認証済URL でなく、 Does settings prohibit mixed security contexts? が真であるとき、 混合内容 (mixed content) です。 >>90

[92] 応答は、 unauthenticated response であって、 Does settings prohibit mixed security contexts? が真であるとき、 混合内容 (mixed content) です。 >>90

[94] 混合内容が、 混合内容を制限する文脈に読み込まれる時、 当該文脈は RFC 6797 混合保安文脈 (mixed security context) です。 >>90

適用対象

[174] Fetch に適用されます。 JavaScript の fetch に限らず、 Webページからのネットワークアクセスほとんどすべてに適用されます。 WebSocket も適用対象に含まれます >>26, >>25。

[96] 要求が混合内容で任意選択的ブロック可能 (optionally-blockable) であるとは、 終点が video か audio であるか、 initiator が空文字列で終点が image であるかをいいます。 >>95

[97] img などの画像, video, audio, video や audio の source などが該当します。これらは従前より混合内容が比較的よく使われてきました。 それをただちにブロックすることはWeb互換性のため極めて難しいので、 当分の間の暫定的措置として混在が認められています >>95。 とはいえ混在が安全でないことは間違いなく、 理想的にはブロックするべきものであるため、 将来的にブロックできるようになることが期待されています >>95。 利用者の設定で任意選択的ブロック可能なものも含めてブロックすることができます (>>168)。 (なお、 任意選択的ブロック可能に該当しても、他の条件によりブロックされる場合があります。)

[98] 要求が混合内容で任意選択的ブロック可能でない場合、 ブロック可能 (blockable) です。 >>95

[99] プラグインからのネットワークアクセスも混合内容制約の適用対象ですが、 NPAPI プラグインが直接ネットワークにアクセスする可能性があるように、 実際には擦り抜けられてしまうことがあります。 Webブラウザーはこれを防ぐべきで、 プラグインの開発者も制約に從うべきとされています。 >>95 Flash を最後に外部プラグインが廃止されることで、 この問題は解消されます。

[85] navigation、つまり HTTPS ページから素のHTTP のページへのリンクの遷移は認められています。 しかし navigation であっても HTTPS ページ内部の iframe に表示させるようなものは、認められません。

[141] HTTPS から素のHTTP へのフォームの提出も基本的には認められています。 しかし Webブラウザー依存でこれを制限しても構わないことになっています (>>124)。 そのような場合古くから多くの Webブラウザーがモーダルダイアログを表示して利用者に確認していました。

[175] 利用者エージェントは、 仕様書のアルゴリズムより更に厳しい制限を課すことが認められ (というか推奨 (encouraged) され) ています。 >>163 いくつか例示されていますが、それ以外の措置も認められるようです。

[176] そのような曖昧性を残した規定は相互運用性のため好ましくないとも思われますが、 要はすべて HTTPS で安全に輸送すれば良いということでしょう。

[177] Strict-Transport-Security ヘッダー (HSTS) があるとき、 すべてをブロック可能とみなしたり、 厳密混合内容検査フラグを設定するものとみなしたりして構いません。 >>163

[178] 利用者の安全のため危険性を下げるべく、 任意選択的ブロック可能な要求を修正して構いません。 例えばクッキーその他認証トークンw除去したり、 自動的に URL scheme を格上げしてみたり、 などの措置を取り得ます。 >>163

[179] 入れ子閲覧文脈内の任意選択的ブロック可能なものをブロック可能とみなして構いません。 そうすることで混合内容が含まれてしまうおそれを排除して埋め込みできます。 >>163

プロトコル

[100] 混合内容制約の制御

[167] Mixed Content は Webブラウザーが実装する制約で、 HTTPS 頁に素のHTTPが埋め込まれるものをエラーとするものです。 ところが従来素のHTTPで提供されてきた Web頁を HTTPS に移行したい時、 ページ内にあるすべての URL を http: から https: に書き換えないといけないとすると、大規模な Webサーバーでは困難な場合があります。 そこで UIR を使うと、 Mixed Content でエラーとなる以前に暗黙裡に http: から https: への読み替えがなされます。

処理

[103] 環境設定群オブジェクト設定群について Does settings prohibit mixed security contexts? は、 真 (Prohibits Mixed Security Contexts) か偽 (Does Not Prohibit Mixed Security Contexts) を返し、 次のようにします。 >>102

  1. [104] 設定群の HTTPS状態 が none でない場合、
    1. [105] 真を返し、 ここで停止します。
  2. [106] 文書を、設定群の有責文書に設定します。
  3. [108] 文書が null でない場合、
    1. [107] 文書の埋め込んでいる文書が null でない間、 繰り返し、
      1. [109] 文書を、 文書の埋め込んでいる文書に設定します。
      2. [110] 埋め込み器設定群を、 文書の大域オブジェクトの関連設定群オブジェクトに設定します。
      3. [111] 埋め込み器設定群の HTTPS状態が none でない場合、
        1. [112] 真を返します。
  4. [113] 偽を返します。

[114] おおまかにいえば、親フレームに https: のものがあれば真を返します。

[166] 要求 (>>116) や応答 (>>142) に対するアルゴリズムの他、 アドレスバー表示でも使われます。

[116] 要求要求について Should fetching request be blocked as mixed content? は、 真 (blocked) か 偽 (allowed) を返し、 次のようにします。 >>102

  1. [117] 要求のクライアントについて Does settings prohibit mixed security contexts? が偽の場合、
    1. [118] 偽を返し、ここで停止します。
  2. [119] 要求のURLの先験的認証済が真の場合、
    1. [120] 偽を返し、ここで停止します。
  3. [121] 混合内容を認めるよう利用者エージェントが設定 (>>170) されている場合、
    1. [169] 偽を返し、ここで停止します。
  4. [122] 要求の終点が document で、 要求の対象閲覧文脈の親閲覧文脈が null の場合、
    1. [124] 要求がフォーム提出であって利用者エージェントがこの種の混合内容を検査する場合を除き >>102, >>163、
      1. [123] 偽を返し、ここで停止します。
  5. [125] 要求のクライアントの CSPリスト中の各方針について、順に、
    1. [126] 方針の指令集合に block-all-mixed-content 指令が含まれる場合、
      1. [127] 違反を、 要求のクライアントの大域オブジェクトと block-all-mixed-content について create-violation-for-global した結果に設定します。
      2. [128] 違反の資源を、 要求の URL に設定します。
      3. [129] 違反について report-violation します。
  6. [115] 任意選択的ブロック可能混合内容を認めないよう利用者エージェントが設定 (>>168) されている場合、
    1. [130] 真を返し、 ここで停止します。
  7. [131] 要求のクライアントの厳密混合内容検査フラグが真の場合、
    1. [132] 真を返し、 ここで停止します。
  8. [133] 要求のモードが CORS の場合、
    1. [134] 真を返し、 ここで停止します。
  9. [135] 要求の終点が image で、 要求の initiator が imageset でない場合、
    1. [136] 偽を返し、 ここで停止します。
  10. [137] 要求の終点が video か audio の場合、
    1. [138] 偽を返し、 ここで停止します。
  11. [139] 真を返します。

[140] fetch から呼び出されます。

[142] 要求要求、 応答応答について Should response to request be blocked as mixed content? は、 真 (blocked) か 偽 (allowed) を返し、 次のようにします。 >>102

  1. [143] 要求のクライアントについて Does settings prohibit mixed security contexts? が偽の場合、
    1. [144] 偽を返し、ここで停止します。
  2. [145] 混合内容を認めるよう利用者エージェントが設定 (>>170) されている場合、
    1. [146] 偽を返し、ここで停止します。
  3. [147] 要求の終点が document で、 要求の対象閲覧文脈の親閲覧文脈が null の場合、
    1. [148] 要求がフォーム提出であって利用者エージェントがこの種の混合内容を検査する場合を除き >>102, >>163、
      1. [149] 偽を返し、ここで停止します。
  4. [150] 応答の HTTPS状態が modern の場合、
    1. [151] 偽を返し、 ここで停止します。
  5. [152] 任意選択的ブロック可能混合内容を認めないよう利用者エージェントが設定 (>>168) されている場合、
    1. [153] 真を返し、 ここで停止します。
  6. [154] 要求のクライアントの厳密混合内容検査フラグが真の場合、
    1. [155] 真を返し、 ここで停止します。
  7. [156] 要求の終点が image で、 要求の initiator が imageset でない場合、
    1. [157] 偽を返し、 ここで停止します。
  8. [158] 要求の終点が video か audio の場合、
    1. [159] 偽を返し、 ここで停止します。
  9. [160] 真を返します。

[161] fetch から呼び出されます。

[162] この処理は要求に対する処理と似ています。 要求に対する処理はネットワークに送信する前に実行し、 それを通過したもののみがこちらの応答に対する処理も実行されます。 応答に対する処理は、 リダイレクトの結果やサービスワーカーが動作した場合も考慮して、 一部重複して検査が実行されています。

利用者インターフェイス

[101] 表示中の Web頁が混合内容を含むかどうかは、 通例アドレスバーに表示されます。 アドレスバー

[165] 他に開発者コンソールに詳しくエラーが表示されることがあります。 文書の厳密混合内容検査フラグが真で一般の利用者に混合内容の表示がない場合 アドレスバー であっても、開発者コンソールには表示して構いません >>163。

[164] 古くは混合内容を表示するかどうかいちいちモーダルダイアログを表示する Webブラウザーもありました。

[173] Webブラウザー利用者の設定による一部挙動の変更も認められています。

[168] 利用者エージェントは、 すべての混合内容をブロック可能とする (任意選択的ブロック可能なものもブロックする) 選択肢を利用者に提供して構いません。 その場合利用者はこれを利用することが強く推奨 (strongly recommended) されます。 >>163

[170] 利用者エージェントは、 特定の Webページについて、 ブロック可能なものをブロックする決定を覆す手段を利用者に提供して構いません。 >>163

[171] 仕様書は現実的にそうした機能を提供しないことはできないとし、 危険なので十分注意喚起するよう求めていました >>163。 実際古くからそうした機能を Webブラウザーは備えていました。 其後 HTTPS 移行が進んでおり、現在では必要もほとんどなくなっているとみられます。

[172] 利用者エージェントは、こうした機能について、 AT 利用者のためアクセシビリティーAPI を通じても提供しなければなりません。 >>163

誤訳「コンテンツ」

[63] 単数形の「Mixed Content」 を混合コンテンツ、 混在コンテンツと訳す人もいますが、 明確な誤訳です。

[54] はてなブログへの接続をすべてHTTPSにできる機能の実装予定と、利用を検討するユーザー様に準備いただきたいこと - はてなブログ開発ブログ () http://staff.hatenablog.com/entry/2017/09/25/143000

混在コンテンツ(Mixed Content)

[55] なぜ英語で単数形なのに日本語で複数形に訳すのか、理解に苦しむ。

[68] はてなブックマーク・ネイティブ広告 - はてなのコンテンツマーケティング支援総合サービス () http://www.hatena.ne.jp/contentmarketing/nativeads では 「はてなコンテンツマーケティング」が 「Hatena Content Marketing」 とされています。株式会社はてなでは content の「t」を「ツ」 と音訳していると思われます。

[69] 他社ではこうした事例は多くないので (なくはない)、 業界独自の慣習でもなくこの会社の人がそうしているだけ?

[73] 英語原文では「content」と単数なのがことごとく「コンテンツ」 と複数形で誤訳されています。

[75] Google は コンテンツ セキュリティ ポリシー | Web | Google Developers () https://developers.google.com/web/fundamentals/security/csp で CSP の C も「コンテンツ」 と訳しています。 「ツ」は 「t」の音訳なのかもしれません。

[71] Google、Chromeで混合コンテンツを完全にブロックする計画 | スラド IT () https://it.srad.jp/story/19/10/05/2112223/

>>72 を引用。

[76] 「コンテント」と「コンテンツ」を正しく訳し分けしないと、 技術者は block-all-mixed-content の正しい綴りを覚えるのに苦労することになります。

関連

[10] SGML や XML の内容モデルにおける混合内容とは関係ありません。 混合内容の語は長年 Webブラウザーで使われるため混乱は少ないと説明されています >>90。

[84] 保安文脈は HTTPS とそれ以外を分離した上で更に HTTPS 側だけに機能を提供する、更に強い制約となっています。

歴史

[86] 当初 HTTPS と素のHTTP の混合はまったく制約なく認められていました。 Web 上では普通に行われていました。

[87] しかし IE4 など HTTPS からの素のHTTP の利用の一部を制限することがある Webブラウザーもありました。

[9]

A Web page is called mixed content if the top-level resource was retrieved through a strongly TLS protected HTTP transaction, but some dependent resources were retrieved through a weakly protected or unprotected HTTP transaction.

Web Security Context: User Interface Guidelines ( 版) http://www.w3.org/TR/2010/REC-wsc-ui-20100812/#def-mixed-content
[93] この旧定義は Mixed Content により更新されました >>90。

[6] Web Security Context: User Interface Guidelines ( ( 版)) http://www.w3.org/TR/wsc-ui/#def-mixed-content

[7] RFC 6797 - HTTP Strict Transport Security (HSTS) ( ( 版)) http://tools.ietf.org/html/rfc6797#section-2.3.1.3

[1] Mixed Content ( ( 版)) http://projects.mikewest.org/webappsec/specs/mixedcontent/

[2] webappsec/specs/mixedcontent at master · w3c/webappsec ( ( 版)) https://github.com/w3c/webappsec/tree/master/specs/mixedcontent

[3] Mixed Content ( ( 版)) https://w3c.github.io/webappsec/specs/mixedcontent/

[4] Add Mixed Content hook placeholders. Broaden placeholder CSP hook. · f04393a · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/f04393aa9815dd6dce350d5d058f2bac9c4d606c

[5] Bug 22262 – Mixed content / CSP ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=22262

[11] RFC 6797 - HTTP Strict Transport Security (HSTS) ( ( 版)) http://tools.ietf.org/html/rfc6797#section-12.4

[12] Clarify MIX and CSP hooks a bit · 682f68d · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/682f68d5f0cce7f9637a8f6d9450b514ed276f9b

[13] Put MIX/CSP hooks in switch. Put second MIX check before tainting. · 567fe8a · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/567fe8ad5f1804efdefa7aa273f2a366b223c70e

[14] Mixed Content ( ( 版)) http://www.w3.org/TR/2014/WD-mixed-content-20140722/

[15] Mixed Content ( ( 版)) http://www.w3.org/TR/2014/WD-mixed-content-20140916/

[16] Mixed Content ( ( 版)) http://www.w3.org/TR/2014/WD-mixed-content-20141113/

[17] MIX: Walk the ancestor tree for powerful features. · 8d8d201 · w3c/webappsec ( ( 版)) https://github.com/w3c/webappsec/commit/8d8d201a571896267b229e9be0bd5cab222d67a2

[18] Fix the order of CSP, HSTS, Mixed Content, and Referrer https://www.w3.o... · b8c2c49 · whatwg/fetch ( 版) https://github.com/whatwg/fetch/commit/b8c2c4964c233cd3616042c04e2c14e0ff25485d

[19] Mixed Content ( ( 版)) http://www.w3.org/TR/2015/CR-mixed-content-20150317/

[20] Part2 - browsersec - Browser Security Handbook, part 2 - Browser Security Handbook - Google Project Hosting ( 版) https://code.google.com/p/browsersec/wiki/Part2#Protocol-level_encryption_facilities

[21] Re: Fetch, MSE, and MIX (Matthew Wolenetz 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2015Apr/0093.html

[22] Re: [MIX] Modifications to script APIs (Anne van Kesteren 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0228.html

[23] Bug 28577 – [XMLHttpRequest] Throwing SecurityError on open() call for some kind of simple errors ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=28577

[24] HTML Standard ( 版) https://html.spec.whatwg.org/#dom-websocket

If secure is false but the origin specified by the entry settings object has a scheme component that is itself a secure protocol, e.g. HTTPS, then throw a SecurityError exception and abort these steps.

[27] MIX: Clarify mixed content "resources" vs "requests". · w3c/webappsec@8732a84 ( 版) https://github.com/w3c/webappsec/commit/8732a8402ba535dc7ab05423fec251f8ceb5c8bd

[28] MIX: Explicitly update WSC-UI's 'mixed content' definition (h/t @equa… · w3c/webappsec@d9d8246 ( 版) https://github.com/w3c/webappsec/commit/d9d8246bf985bcfe78d02dfb6d0c1be6ccb3b56a

[29] MIX: Cite a source for the IE4 note. · w3c/webappsec@9b1690c ( 版) https://github.com/w3c/webappsec/commit/9b1690c0432e0320fa861c89ced452bbaf45a5ed

[30] PRB: Security Warning Message Occurs When You Browse to a Page That Contains an IFRAME Through SSL ( 版) https://support2.microsoft.com/default.aspx?scid=kb;EN-US;Q261188

[31] Eric Lawrence on Twitter: "@mikewest IE6-IE8 used a modal dialog box. http://t.co/fvK7RiZ9Pi implies that IE4/IE5 had the same. Sadly, I don't have any Win9x VMs." ( 版) https://twitter.com/ericlaw/status/469813922908758016

[32] MIX: Clarify "mixed content" vs XML's term. · w3c/webappsec@528162c ( 版) https://github.com/w3c/webappsec/commit/528162c3014ddd19cc6e04570fe19e57292ca0d1

[33] RFC 6797 - HTTP Strict Transport Security (HSTS) ( 版) http://tools.ietf.org/html/rfc6797#section-12.4

"Mixed security context" loads happen when a web application

resource, fetched by the UA over a secure transport, subsequently

causes the fetching of one or more other resources without using

secure transport. This is also generally referred to as "mixed

content" loads (see Section 5.3 ("Mixed Content") in

[W3C.REC-wsc-ui-20100812]) but should not be confused with the same

"mixed content" term that is also used in the context of markup

languages such as XML and HTML.

NOTE: In order to provide behavioral uniformity across UA

implementations, the notion of mixed security context will

require further standardization work, e.g., to define the

term(s) more clearly and to define specific behaviors with

respect to it.

[34] Re: CSP2: Drop 'unsafe-redirect'. (Brian Smith 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0019.html

When Firefox implemented mixed content blocking, Mozilla treated

Mozilla-owned sites specially: We assumed that our coworkers would make the

necessary changes before we shipped, after we helped them understand what

was necessary, and so we didn't consider breaking any Mozilla site a risk

for shipping. That strategy worked very well for us (IIRC).

[35] Intent to Ship: Strict mixed content checking. - Google Groups ( 版) https://groups.google.com/a/chromium.org/d/msg/blink-dev/MafYMJ3zQw0/DkZdADnS3hMJ

[36] MIX: First stab at SW integration. · w3c/webappsec@e577d4d ( 版) https://github.com/w3c/webappsec/commit/e577d4d5746bd33248a7dd4dbe0db515c16f20fb

[37] MIX: Dropping the irrelevant CORS mode check from passthrough requests. · w3c/webappsec@72c2dba ( 版) https://github.com/w3c/webappsec/commit/72c2dba9b871a577c2be24101d57f71b63240974

[38] MIX: Align 'should block response?' with Fetch. · w3c/webappsec@bbe52ec ( 版) https://github.com/w3c/webappsec/commit/bbe52eca3e5c3b1c726b03c0363bf87bf4c66972

[39] MIX: Clarify blocking algorithm for passthrough requests. · w3c/webappsec@1d683bb ( 版) https://github.com/w3c/webappsec/commit/1d683bb8e9e4c60b4e51f40299c5e634eb024170

[40] MIX: Target browsing context. · w3c/webappsec@05c7c4c ( 版) https://github.com/w3c/webappsec/commit/05c7c4caf52596baab0acb85083be3a1dd710ae2

[41] Mixed Content ( 版) https://w3c.github.io/webappsec-mixed-content/

[42] w3c/webappsec-mixed-content ( 版) https://github.com/w3c/webappsec-mixed-content

[43] Mixed Content ( ( 版)) http://www.w3.org/TR/2015/CR-mixed-content-20151008/

[44] Clean up language. · w3c/webappsec-mixed-content@bb27f07 ( 版) https://github.com/w3c/webappsec-mixed-content/commit/bb27f07b05e5e385ca4a767f186870d3831cd338

[45] Update WebSocket to use Fetch's WebSocket alterations · whatwg/html@3dadbca ( 版) https://github.com/whatwg/html/commit/3dadbcad063a10b586ef52dd4b427aa339048ee7

[48] [MIX] Carveout for `127.0.0.1`? (Mike West 著, 版) https://lists.w3.org/Archives/Public/public-webappsec/2016Apr/0044.html

[49] Internet Explorer 7 における HTTPS セキュリティの強化点 ( ()) https://msdn.microsoft.com/ja-jp/library/bb250503

現象 : HTTPS コンテンツと HTTP コンテンツが混在するページを表示すると、Internet Explorer 6 以前で表示されていたモーダル ダイアログ ボックスではなく、情報バーが表示される。

回避策 : HTTPS ページに、HTTP プロトコルによりアドレス指定されるリソースへの参照が埋め込まれていないことを確認します。

[50] Use 'Is URL trustworthy?' rather than whitelisting 'https' and 'wss'. (mikewest著, ) https://github.com/w3c/webappsec-mixed-content/commit/349501cdaa4b4dc1e2a8aacb216ced58fd316165

[51] CfC: Republish "Mixed Content" as CR; deadline July 27th. (Mike West著, ) https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0033.html

[52] Mixed Content () https://www.w3.org/TR/2016/CR-mixed-content-20160802/

[53] Call for Exclusions: Mixed Content (Xueyuan Jia著, ) https://lists.w3.org/Archives/Public/public-webappsec/2016Aug/0000.html

[56] Remove outdated note regarding passthrough requests. (mikewest著, ) https://github.com/w3c/webappsec-mixed-content/commit/025b6c392fdf2bb367526cd8e6130a424b4c67de

[57] Remove service worker mixed content exceptions · Issue #12 · w3c/webappsec-mixed-content () https://github.com/w3c/webappsec-mixed-content/issues/12

[58] Cleaning up 'optionally-blockable'. (mikewest著, ) https://github.com/w3c/webappsec-mixed-content/commit/2ff806843a8e634d7d47484db185b995d2d6a95c

[59] Normative definition of optionally-blockable contradicts following note · Issue #8 · w3c/webappsec-mixed-content () https://github.com/w3c/webappsec-mixed-content/issues/8

[60] Proposal for a MIX Level 2 roadmap. (Mike West著, ) https://lists.w3.org/Archives/Public/public-webappsec/2017Oct/0013.html

[61] webappsec-mixed-content/proposed-level-2-roadmap.md at master · mikewest/webappsec-mixed-content () https://github.com/mikewest/webappsec-mixed-content/blob/master/proposed-level-2-roadmap.md

[62] Mixed Content Level 2 (John Wilander著, ) https://lists.w3.org/Archives/Public/public-webappsec/2018Feb/0001.html

[64] CfC to transition MIX to PR. (Mike West著, ) https://lists.w3.org/Archives/Public/public-webappsec/2018Aug/0027.html

[65] Move "Mixed Content" to PR. · Issue #15 · w3c/webappsec-mixed-content () https://github.com/w3c/webappsec-mixed-content/issues/15

[66] Merge pull request #16 from w3c/admin-stuff (wseltzer著, ) https://github.com/w3c/webappsec-mixed-content/commit/dce78c1ffb302c27170de59aa5bf359182537a3f

[67] Admin stuff by plehegar · Pull Request #16 · w3c/webappsec-mixed-content () https://github.com/w3c/webappsec-mixed-content/pull/16

[70] Chromium Blog: No More Mixed Messages About HTTPS () https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html

[77] Add MIX level 2 skeleton (estark37著, ) https://github.com/w3c/webappsec-mixed-content/commit/4b68136d948df44e6d112cac2906d574b7035294

[78] Add MIX level 2 skeleton by estark37 · Pull Request #21 · w3c/webappsec-mixed-content () https://github.com/w3c/webappsec-mixed-content/pull/21

[79] Add html output (estark37著, ) https://github.com/w3c/webappsec-mixed-content/commit/d08a1927257b14169b91227c02774d5b1c27c96c

[80] Fill out Level 2 spec (#22) (estark37著, ) https://github.com/w3c/webappsec-mixed-content/commit/3d3335503f68736890ea89b9bbdc3ac71533fd01

[81] Fill in level 2 security + privacy considerations (estark37著, ) https://github.com/w3c/webappsec-mixed-content/commit/5e27950001ea7231563fb40e20c6f28305017d5e

[82] Add level 2 security+privacy questionnaire (estark37著, ) https://github.com/w3c/webappsec-mixed-content/commit/123c78c9efcac2681ebf114353c50ed22b712c9d

[83] Update and expand Introduction (estark37著, ) https://github.com/w3c/webappsec-mixed-content/commit/8ce96e12c70d6efa745b3612292bfc79f997476c

[180] Add FPWD document for MIX2 (carlosjoan91, , ) https://github.com/w3c/webappsec-mixed-content/commit/3051e22deb3c5ba4cd5f2c564e75ab21530325cf

[181] Add carlosil as editor (carlosjoan91, , ) https://github.com/w3c/webappsec-mixed-content/commit/0235c9196e8a83c25bd6adbd2ec36cd25e0abd82

[182] Add FPWD document for MIX2 by carlosjoan91 · Pull Request #24 · w3c/webappsec-mixed-content () https://github.com/w3c/webappsec-mixed-content/pull/24

[183] Mixed Content Level 2, , https://w3c.github.io/webappsec-mixed-content/level2.html

[184] replace original level2.html file (carlosjoan91, , ) https://github.com/w3c/webappsec-mixed-content/commit/e85f5805718759b48d2e9603124c1a8ffa44e390

Updated: