Chromeの安定版が更新され、HTTPで配信されているサイトに接続しようとすると、利用者に確認を出す設定が最初から有効になりました。Chrome for Developersのリリースノートでは「Ask before HTTP」という名前で、プライバシーとセキュリティの項目に載っています。派手な新機能ではありませんが、お客様に渡したサイトや社内向けの小さなページに影響しうる変更なので、中身を整理しておきます。
何が変わったのか
リリースノートによると、HTTPの接続でサイトを開こうとしたとき、Chromeが既定で利用者に確認を促すようになりました。これまでも、アドレスバーに「保護されていない通信」と出る形で注意は促されていましたが、今回は開く前の確認という点が違います。HTTPSへの切り替えを促す流れが、表示の注意から操作の手前の確認へ一段進んだ、と受け取れます。
管理者向けには、HttpsOnlyModeという企業向けのポリシーで既定の動きを制御できると書かれています。社内のネットワークで、あえてHTTPのまま動かしている管理画面や機器の画面がある場合は、この設定で挙動をそろえる余地があるということです。リリースノートに書かれているのはここまでで、確認画面の細かな文言や、利用者が一度許可したあとの扱いまでは載っていません。実際の画面は、手元のChromeで確かめるのが確実です。
制作の現場で見ておきたい場所
公開しているメインのサイトは、すでにHTTPSになっているところがほとんどだと思います。むしろ見落としやすいのは、周辺に残っている古い入口です。たとえば次のような場所があります。
- 以前のドメインや、wwwの有無で分かれたアドレスからの転送設定
- 名刺やチラシ、メールの署名に印刷されたままのhttpから始まるURL
- サーバー移転のあとに残った、試験用や旧環境のサブドメイン
- 他社のサイトや地図、予約システムなどに貼られた自社サイトへのリンク
こうした入口から来た人が、サイトの手前で確認の画面に出会うと、そこで離れてしまうかもしれません。サーバー側でHTTPからHTTPSへ恒久的に転送する設定が、すべてのホスト名で効いているかを、一度通して確かめておく価値があります。転送先が正しく働いていれば、利用者が目にするのは最終的なHTTPSのページだけで済みます。
RESONIXでも、サイトの引き継ぎを受けたときは、まず入口のURLを洗い出して転送を確かめる作業から始めることが多いです。見た目の更新より先に、こうした土台の確認が効いてくる場面は少なくありません。
同じ版に入った、ローカル通信まわりの変更
同じChrome 154のリリースノートには、通信に関する項目もいくつかあります。ひとつはWebSocketのコンストラクタに、targetAddressSpaceというオプションを渡せるようになったことです。公開されているホスト名であっても、接続先を「local」や「loopback」として扱うよう指定できます。リリースノートによれば、HTTPSに対応していないローカルのサーバーへ接続するときの、混在コンテンツの制限を避ける手段になるとされています。ただし、利用者がローカルネットワークへのアクセスを許可し、ホスト名がローカルのIPアドレスに解決されることが条件です。
もうひとつは、Background Fetchに対する変更です。CORSの検証が適用されるようになり、ローカルネットワークへのアクセスについても、通常のfetchと同じ許可が必要になりました。通常のfetchでは止まる通信が、Background Fetchなら抜けてしまうという抜け道をふさぐ内容です。
どちらも、一般的なコーポレートサイトには直接関係しません。ただ、店舗の機器や社内システムと連携するウェブアプリを作っている場合は、ブラウザ側の確認がじわじわ厳しくなっている流れとして頭に置いておくと、後で慌てずに済みます。HTTPのままで動かすことに対して、ブラウザが少しずつ慎重になっている、という方向は共通しています。
今回の変更は、サイトを作る側にとっては新しい書き方を覚える話ではなく、すでにあるはずのHTTPS化が隅々まで届いているかを点検する話です。年内のうちに、受け持っているサイトの入口を一通り開いてみて、確認画面が出る場所がないかを見ておくとよさそうです。
