Chrome 62のHTTP入力画面は警告文より先にHTTPSで送る範囲を確認する

Chrome 62では、HTTP pageで利用者が文字を入力すると、address barにNot secureの警告が表示される予定です。passwordやcard番号だけでなく、問い合わせ、資料請求、site内検索の文字も対象になります。警告を消す目的だけでformの表示URLを替えるのではなく、入力画面、送信先、完了画面、そこから送るmailまでをHTTPSで扱えるか確認します。

Googleは4月、Chrome 62でHTTP pageに入力したときと、private browsingでHTTP pageを開いたときにNot secureを表示すると案内しました。HTTPでは、同じnetwork上の第三者が表示内容を見たり替えたりできる可能性があります。利用者へ警告が見えるかどうかは結果であり、先に直すべきなのは、入力を受ける通信と公開する案内です。

password以外の入力も通信内容として扱う

問い合わせformに入るのは、氏名やmail addressだけとは限りません。見積りの希望、相談内容、電話番号、住所、予約したい日時など、事業者が受け取れば管理する情報が含まれます。site内検索の文字も、利用者が何を調べようとしたかを表します。入力欄の名前が簡単でも、HTTPで送ってよい情報だと決めません。

ここで注意したいのは、pageの見た目とformの送信先が同じとは限らないことです。たとえばhttps://example.jp/contact/で問い合わせpageを開いていても、formのactionがhttp://example.jp/contact/sendへ向いていれば、入力はHTTPへ送られます。反対に、HTTPで開いたpageの中に、外部serviceへ送るHTTPS formを埋め込んでいる場合もあります。URLの先頭だけを見て、送信全体が安全だと決めません。

最初に書き出すのは、利用者が文字を入れるpageです。問い合わせ、資料請求、予約、login、会員登録、site内検索、comment、mail magazineの登録などを並べます。次に、各pageを開くURL、formの送信先、送信後のpage、利用者へ届くmail、受ける側が読む管理画面を対応させます。入力欄が一つしかないpageも、対象から外しません。

説明用の仮例として、会社siteにhttp://example.jp/request/という資料請求pageがあるとします。pageをHTTPSへ替えても、送信後にhttp://example.jp/request/thanks/へ戻れば、利用者は途中でHTTP pageへ移ります。完了pageから会員登録や電話予約へ進むlinkがHTTPのままなら、案内の途中で接続の扱いが混ざります。必要なのは、最初のpageだけを証明書で開くことではなく、入力から受付までの経路を一つずつ確かめることです。

HTTPからHTTPSへ移す作業とformを直す作業を分ける

HTTPSへ移すときは、HTTPのURLをHTTPSの対応するURLへ恒久的に転送します。これにより、古いbookmarkや外部siteのlinkから来た人も新しいURLへ進めます。しかしredirectを入れただけで、formの設定が正しくなるわけではありません。themeやpluginに書かれたaction、JavaScriptが送るURL、外部form serviceの埋込みcode、mail本文に入れたlinkを別に確認します。

WordPress siteでは、管理画面の設定だけを替えて終わらせないようにします。固定pageの本文、widget、menu、template、pluginの設定画面にHTTPのURLが残ることがあります。問い合わせformを作った人、serverのredirectを設定する人、mailを受け取る人が別なら、作業を一人にまとめて頼みません。誰がURLを替え、誰が送信を試し、誰が受信を確認するかを決めます。

formへ入力する前に警告が表示される場合、利用者は送信をやめるかもしれません。だからといって、表示を隠すためにinputをJavaScriptで置き換えたり、別windowへ送ったりする方法を先に探しません。HTTPで送る構成を残したまま画面上の見え方だけを替えても、通信内容を守ることにはなりません。HTTPSへ移せない事情があるなら、どの入力を受けないか、代わりに電話や対面で何を受けるかを決めます。

一方で、certificateを入れたことと、すべてのpageが正しく表示されることも別です。HTTPS pageの中でHTTPの画像、script、style sheetを読めば、browserが一部を止めたり、表示やformの動きが崩れたりすることがあります。問い合わせpageなら、入力欄だけでなく、送信button、確認用script、完了画面の計測tagまで確認します。安全な接続を作る作業と、従来の画面が読めることを確認する作業を分けません。

private browsingの表示を通常の確認から外さない

Chrome 62では、private browsingでHTTP pageを開いたときもNot secureを表示する予定です。private browsingは、HTTP通信を暗号化する機能ではありません。browserを閉じた後に端末へ残す情報の扱いと、networkを流れる通信の扱いを同じものとして考えません。

確認するときは、普段使うwindowだけでなくprivate browsingでも重要なpageを開きます。問い合わせform、会員login、予約、検索、PDF downloadの前に情報を入れるpageを対象にします。ここで見るのは、warningが出るかだけではありません。HTTPへ戻るredirectがないか、入力した後に完了pageへ進めるか、利用条件とprivacy policyがHTTPSで読めるかを確かめます。

利用者向けの案内も整理します。「securityのためHTTPSへ替えました」と一文を足すだけでは、問い合わせの受付が続くことは分かりません。URLが変わるなら、旧URLから開いても新URLへ進むこと、mailや紙の案内に古いURLが残ること、bookmarkを替える必要があるかを確認します。外部の予約serviceや決済serviceを使う場合は、どのdomainで入力し、問い合わせ先がどこかを画面で分かるようにします。

公開後は入力画面を送信まで確かめる

HTTPS移行の確認は、トップpageが鍵の表示になったところで終わりません。実際に入力するpageを開き、test用の内容で送信します。送信先のURL、完了page、受信mail、管理画面の記録を順に見ます。testの入力内容へ実在の個人情報や顧客情報を使わず、確認後に不要な記録をどう扱うかも決めます。

制作会社へ依頼するなら、対象URLの一覧だけでなく、入力するpage、formの送信先、送信後のpage、外部service、mail、管理画面を渡します。「HTTPSにしてください」とだけ頼むと、redirectは入っても、実際の受付が確認されないままになることがあります。事業者側は、問い合わせや予約を受ける人がtest送信を確認します。制作側はURL、certificate、redirect、resource、formの動きを確認します。

最初の一手は、利用者が文字を入れるpageをすべて一覧にし、HTTPで開くURLと送信先を一組ずつ確かめることです。Chrome 62の警告は、見た目の小さな変更ではありません。入力を受けるsiteが、誰の情報をどの経路で受け、公開後に誰が確認するかを見直す機会です。