20190905 追記
Draft版の仕様が出てきたので「Mixed Content Level 2の仕様について - ASnoKaze blog」を書きました。
20181010 追記
Chromeが行っている取り組みについて、「Auto Upgrade Mixed Contentとは - ASnoKaze blog」を書きました。
W3CのWeb Application Security WGのco-chairとなった GoogleのMike West氏から、11月に実施されるTPAC 2017に先立って「Mixed Content Level 2」という提案が出されている。
Mixed Content
https://のURLで、http://のリソースを読み込むと警告・もしくはブロックを行うMixed Contentという仕様がある。そのMixed Contentの問題とそれを改善するMixed Content Level 2の議論が始まっている。
まだまだ議論のたたき台ではあるが、簡単に読んでおく。
問題点
- 仕様でOptionally-blockableとして定義される、必ずしも読み込みがブロックされない画像などのリソースは、未だにhttp://で使用されているケースが有ります。警告などは表示されますが、その割を減らすには効果は弱いようです。
- https://mixed.badssl.com/といったoptionally-blockableがある場合は、ChromeではURLバーの鍵マークを表示しません。blockable がブロックされた場合は鍵マークが表示されます。blockableとoptionally-blockableの区別をし続け、ユーザにとって区別出来るものでしょうか？
- HTTPからHTTPSへの移行は大変です。Upgrade-Insecure-Requestsは部分的に問題を解決しますが、開発者がヘッダに指定する必要があります。HSTS PrimingはFirefoxで実装されていますが、その価値は示されていません。
提案
- ユーザエージェントは、blockable mixed contentをブロックするのではなくアップグレードします。Upgrade-Insecure-Requestsがあるかのように、http://のリソースでもhttps://でアクセスします
- ユーザエージェントは、optionally-blockable mixed contentをデフォルトでblockableとして扱います。そして上記のようにアップグレードが適応されます。開発者がヘッダなどで明示的にoptionally-blockableとして扱うように指示できるようにすることも検討する。
- ユーザエージェントは、複雑さを避けるためにUpgrade-Insecure-Requestsを廃止する。
- ユーザエージェントは、より多くの状況でURLバーの鍵マーク(盾マーク)を消すべきです
また、アップグレードしてもhttpsの接続性がない場合はタイムアウトするまでレンダリングがブロックされる可能性があるため、タイムアウト時間を短した方がいいとMLで意見が出ています。
