Chromeが起動時に三つのランダムなドメインに接続しようとする理由

“Chrome connects to three random domains at startup.” — Mike West

Chromeを起動した際、http://aghepodlln/とかhttp://lkhjasdnpr/のようなランダムなドメインへの接続を試みる。何でこんなコトをしているのかという見当はずれの推測が、いくつか出回っている。事実としては、この挙動は必要なのだ。以下の説明で、この疑問を晴らす。

このような接続要求の目的は、現在使用しているネットワークが、存在しないホスト名への接続要求を検知して勝手にリダイレクトするかどうかを判定するものである。例えば、少なからぬISPが、http://text/のようなDNSルックアップの失敗に対し、http://your.helpful.isp/search?q=text（あなたの親切なISP）へリダイレクトしている。この「親切」な挙動の可否はさておくとして、この挙動はChromeにとって問題を引き起こすのだ。特に、Omniboxで使われている、ユーザーの入力がキーワード検索なのか非標準のドメイン名へのアクセスなのかを判定するヒューリスティックを阻害するのだ。

問題の1つとして、Googleの内部ネットワークはいい例となる。Google内部のgoというショートリンクサービスは、共有しやすい簡潔なリンクを提供している。今、"go"とChromeのOmniboxにタイプしてエンターキーを押した時、それはhttp://go/へのアクセスを意味するのか、あるいは"Go"を検索したいのか曖昧である（ところで、Goは面白いプログラミング言語である）。Chromeはできるだけ「正しいこと™」をするため、検索を実行しつつ、裏で、ひょっとしたらドメインかもしれないこの入力に対してHEADリクエストも発行する。サーバーが応答したならば、グーグルはinfobarを表示して、もしかしてhttp://go/を意図していたのかどうかを尋ねる。そして、ユーザーの回答を、将来のために覚えておくのだ。

お分かりのように、この機能は、ISPがそのようなリクエストを補足している場合、ぶっ壊れてしまう。どんな一単語のキーワードに対しても、infobarが表示されてしまうのだ。だから、Chromeは起動時とIPアドレスの変更時にチェックを行なっているのだ。ところで、Chromeは美しくもオープンソースであるので、この実装を確認してみるとしよう。

まず読むべきなのはIntranetRedirectDetectorだ。Chromeが起動した時、IntranetRedirectorDetectorのオブジェクトを生成する。これは短時間のディレイ（現在、7秒にハードコートされている）を設けて、起動時の重要な処理を妨害しないようにし、その後、IntranetRedirectDetector::FinishSleep()を呼び出して実際の処理をはじめる。このメソッドはランダムなドメイン名を三つ生成して、それぞれのドメイン名に対して非同期HEADリクエストを、キャッシュの生成とcookieの保存を行わないようにした上で、発行する。リクエストが完了したならば、IntranetRedirectDetector::OnURLFetchComplete() が呼ばれ、結果を記録する。もし、三つのリクエストのうち、いずれか二つが同じホストに名前解決された場合、そのホストは、ネットワークの"redirect origin"として記録される。簡単だ。

この情報は、AlternateNavURLFetcherで、Omniboxによる検索に対しinfobarを表示するべきかどうかという判断に使われる。もし、HEADリクエストがChrome起動時に得たredirect originと同じサイトを返した場合、無視される。もし、別物であれば、便利なinfobarの出番だ。

とまあ、こんなところだ。Chromeは起動時に三つのランダムなドメイン名に対するリクエストを発行することによって、Omniboxのヒューリスティックがユーザーの意図に添うようにしている。このリクエストは、ユーザーの個人情報を悪意ある目的でどこかに送信しているわけではないし、トラッキング用でもない。crbug.com/18942を修正するために必要なリクエストであり、他意はない。

以上、Chromeが起動時にランダムなドメインにアクセスを試みる理由の説明。それにしても、そんな馬鹿なことをするISPを糾弾するべきだ。ドメイン名が解決できないならば、解決できないと返すべきなのだ。DNS名前解決をハイジャックすべきではない。