20190905 追記
Draft版の仕様が出てきたので「Mixed Content Level 2の仕様について - ASnoKaze blog」を書きました。
HTTPSのサイト内にHTTPで提供される画像やスクリプトがあると、「Mixed Content」の仕組みによりURLバーに黄色い警告が出たり、リソースがブロックされます。
もちろんスクリプトがブロックされればWebページを正しく表示できません、URLバーに表示されたシールドマークから通信を許可することもできますが、一般ユーザにとって分かりにくいUXとなっています。
そこでChromeでは、HTTPで読まれるリソースをブロックするのではなく、HTTPSに自動でアップグレードしてリソースを取得する「Autoupgrade Mixed Content」という仕組みが検討されています。
以前、GoogleのMike West氏から提案されていた「Mixed Content Level 2」と似たような仕組みです。
asnokaze.hatenablog.com
( Auto Upgrade Mixed Contentの資料には「THIS DOCUMENT IS PUBLIC」と書かれてるので、おそらく大丈夫)
実験
Chromeでは、6通りの方式を実験してどのようなアップグレード手法が有効か模索しようとしています。この実験を解析し、新しい機能を改めて提案するかが決定されます。
3種類のアップグレード方式と、それぞれについてHTTPSのロードに失敗した場合HTTPにフォールバックするかの2種類を試し、計6種類を実験するようです。
stableのユーザのうち1%で実験を行うと書かれています。この実験では、画像など今までブロックされていなかったリソースもフォールバックなしだと表示されなくなる場合がありそうです。
方式
Upgrade blockable mixed content to HTTPS
Scriptなどのblockable mixed contentをアップグレードします。すでにブロックされているリソースですので、HTTPSにアップグレードしてリソースが読み込めなくてもページを破損させることはありません。
Upgrade only optionally blockable mixed content to HTTPS
画像などのoptionally blockable mixedのみをアップグレードします。通常、表示できているリソースですので、HTTPSににアップグレードすることで読み込めなくなり、ページを破損させる可能性があります。
Upgrade all mixed content to HTTPS
すべてのmixed contentをアップグレードします。このケースでは、警告表示や、ユーザによるmixed contentの許可はなくなります。
サイトがupgrade-insecure-requests ヘッダを指定した場合と似た挙動となります。
