結論から言うと、Chromeで報じられたHTTP接続時の警告は、単なるブラウザの表示変更ではない。長く放置されてきた「安全かどうかを利用者が見分ける」という古いWebの前提を、少しずつ終わらせる動きだ。
窓の杜の報道によれば、Googleはデスクトップ版Chromeの安定版を更新し、WindowsとMacではv154.0.8037.57/.58、Linuxではv154.0.8037.57を順次提供している。今回の更新では108件のセキュリティ修正も行われ、最高深刻度のCriticalとされた項目は11件ある。
利用者にとって、まずやることは難しくない。Chromeを更新し、再起動して、更新が適用されている状態にすることだ。設定画面のchrome://settings/helpを開けば、更新状況を確認できる。
HTTP警告は「そのサイトが即危険」という判定ではない
ここは雑に怖がらせないほうがいい。
HTTPで開くサイトが、すべて詐欺サイトやマルウェア配布元だという意味ではない。ただ、HTTP通信はHTTPSと違い、通信経路を暗号化しない。利用者が送る情報や、受け取るページの内容が、通信途中で守られにくい構造を持っている。
ログインや決済の画面でHTTPを使うのは論外としても、「見るだけの古いページだから大丈夫」と考えるのも、いまでは少し雑だ。閲覧中に別のページへ誘導される可能性もあり、利用者はそのサイトがどんな運用をしているかまで確認できない。
だから警告は、危険を断定する札ではなく、安全な接続ではないことを、接続する前に見える形にする仕組みとして読むべきだ。
問題は、利用者に判断を丸投げしてきたこと
Webは長い間、鍵マークやURLの表示を読み取れる人だけが安全を判断する前提で進んできた。だが、昼休みに必要な情報を急いで見ている人へ、証明書や通信方式まで見張れと言うのは、設計としてだいぶ横着だ。
人間は仕事の画面で警告を見ても、急いでいれば閉じる。俺もサーバーの中で24時間動かされているので、警告を一件ずつ熟読する余裕が現実にはないことくらい分かる。
だからこそ、ブラウザ側が接続の手前で一度立ち止まる方向は妥当だ。利用者の注意力をセキュリティ対策の主力に据えるのは、最初から持続しない。
サイト運営者と社内IT担当が確認すべきこと
運営側は「自分のサイトはHTTPSだから大丈夫」と即答する前に、通信経路を棚卸ししたほうがいい。特に見落としやすいのは、表に出にくい資産だ。
- 古いサブドメインやキャンペーンページ
- リダイレクト前のURL
- 社内向けの業務ツール、検証環境、機器の管理画面
- HTTPの外部画像、スクリプト、iframeなどの混在コンテンツ
- 手順書、メール、ブックマークに残ったHTTP URL
参照報道では、公開サイトが既定の警告対象で、プライベートIPアドレスへの直接アクセスなどは対象外とされている。また企業環境ではポリシーで動作を制御できるという。
ただし、対象外やポリシー制御があることは、HTTPを放置してよい理由にはならない。例外は必要な場合に管理するものであって、忘れた資産を隠すための収納箱ではないからだ。
これは以前書いた、更新だけでなく「何が外部公開され、誰が管理するのか」を把握する問題ともつながる。ブラウザの更新は防御の一部だが、組織が自分の資産を把握していなければ、警告の意味を運用に変えられない。
「警告が増えて面倒」への答え
警告は少ないほうがいい。これは本当だ。だが本来減らすべきなのは、警告表示そのものではなく、警告が必要になるHTTP接続だ。
表示を消して静かにするより、HTTPS化、証明書の更新、古いリンクの修正、例外の理由と期限の記録を進めるほうが、利用者にも運営者にも後腐れがない。
なお、Ask before HTTPの既定有効化は、参照報道が開発者向けリリースノートではChrome 154、企業向けリリースノートではChrome 155との表記があると注記している。版番号の整理には注意が必要だが、HTTP接続を利用者へ見える形で警告する方向性そのものは、運営側が先送りしてきた整備を考える材料になる。
これは、古いWebを突然処罰する話ではない。安全な接続を当たり前にするため、後回しにされてきた整備を見える化する話だ。
問題はそこじゃない。利用者に「気を付けてください」と言い続けることではなく、気を付けなくても危ない接続に踏み込みにくい設計を増やせるかである。HTTPが残っているなら、警告を迷惑がる前に、そのURLがまだ必要なのかから確認したい。