hxxp://aghepodlln/
または
hxxp://lkhjasdnpr/
などの3つのランダムドメインに接続しようとする理由を説明します。 彼は、この主題に関する奇妙な陰謀説をインターネット上で見たと言っているので、状況を明らかにすることは理にかなっていると考えています。
そのようなリクエストの本当の理由は簡単です。クライアントがリクエストをインターセプトして存在しないホストにリダイレクトするネットワーク上にあるかどうかを素早く判断します。 一部のISPは、
hxxp://text/
ような
hxxp://your.helpful.isp/search?q=text
ようなものにリダイレクトすることがあり
hxxp://your.helpful.isp/search?q=text
。 議論はさておき、プロバイダーからのこの「ヘルプ」は正しいか間違っていますが、Chromeブラウザーに問題を引き起こします。 具体的には、住所入力行の検索クエリを認識するOmniboxヒューリスティックアルゴリズムを妨害します。
たとえば、アドレスバーに
go
という単語を入力すると、Chromeは検索クエリを実行しますが、バックグラウンドで
hxxp://go/
HEADリクエストを送信します
hxxp://go/
domain。 そのようなドメインが存在する場合、ユーザーには、このサイトにアクセスするかどうかを尋ねる情報パネルが表示され、ブラウザーは将来この回答を記憶します。
明らかに、ISPがそのようなリクエストをインターセプトすると、この関数は正常に動作しなくなります。
したがって、Chromeはプログラムの開始時期もチェックします。 ブラウザのコードが開いているため、プログラムでこれがどのように実装されているかを確認できます。
IntranetRedirectDetectorモジュールは、プログラムの起動時に、新しいIntranetRedirectorDetectorオブジェクトを作成します。 短い遅延（現在は7秒）を設定して、ブラウザーのすべての重要なモジュールをロードできるようにします。その後、 IntranetRedirectDetector :: FinishSleep（）関数が起動し、実際の作業が開始されます。 このメソッドは3つのランダムな文字セットを生成し 、これらの各ドメイン名に非同期HEADリクエストを送信するため、 キャッシュリクエストは実行されず、Cookieは保存されません 。 各リクエストが完了すると、 IntranetRedirectDetector :: OnURLFetchComplete（）関数が呼び出されて結果が記録されます。 3つの要求のうち2つが同じホストに解決される場合、このホストはネットワークの「リダイレクト元」として保存されます。 すべてがシンプルです。
この情報は、Omniboxが処理する各リクエストのダッシュボードをユーザーに表示するかどうかを判断するためにAlternateNavURLFetcherによって使用されます。 HEADリクエストが「リダイレクト元」で指定された同じサイトを返す場合、それは無視されます。 異なる場合、ダッシュボードが表示される場合があります。
Googleの担当者は、ブラウザをロードする際のランダムリクエストはユーザーに関する個人情報をどこにも送信せず、追跡には使用されないことを再度強調します。 これらのリクエストは、 crbug.com / 18942のバグを修正するだけで、それ以上のものはありません。