タイムゾーンの不一致:ウェブで最も安上がりな一貫性チェック
ウェブサイトが実行できる一貫性チェックの中で、タイムゾーンの比較は最も安上がりです。必要なのはJavaScriptの呼び出し1回と、サーバーがすでに行っているルックアップ1回だけ。そして、アカウントが再チェックを受ける最も一般的な理由の1つでもあります。
2つのタイムゾーン、2つの情報源
1つ目のタイムゾーンは、あなたのアドレスから来ます。サーバーはリクエストがどこから来たかを知っており、ジオロケーションデータベースを使ってそのアドレスを地域とそのタイムゾーンに対応付けます。パリからの接続ならEurope/Parisです。これはサーバー側で行われ、ブラウザに発言権はありません。
2つ目はブラウザから来ます。Intl.DateTimeFormat().resolvedOptions().timeZoneは、OSに設定されているIANA名を返し、new Date().getTimezoneOffset()は現在のUTCオフセットを返します。マシンがベルリンに設定されていれば、パケットがどこから来たかに関係なく、ページにはEurope/Berlinが見えます。
両者が食い違う理由
正当な理由は、旅行、時計の地域設定を変更していないノートパソコン、別の国から出ていく企業ネットワークなどです。サイトが気にする理由はプロキシです。ブラウザが1つの国にあり、別の国のアドレスを使っているのに、誰も時計のことを考えていない、という状況です。パリとベルリンはオフセットが同じなので、オフセットだけなら一致してしまいますが、IANAの名前は一致しません。名前を比較するチェックはこれを捉えます。診断が数値のオフセットではなく、ブラウザの名前とアドレスの名前の両方を表示するのはそのためです。
不一致が意味するもの
それだけでは、決定的なことは何もありません。実在する多くの人が引っかかります。しかし、これは安上がりなシグナルであり、スコアリングシステムは安上がりなシグナルを足し合わせます。不一致に、ホスティングと分類されたアドレス、さらに第三の場所にあるWebRTC候補が重なれば、不一致だけの場合とは話が変わります。
両者を一致させる
一貫した結果を得る方法は2つあります。OSのタイムゾーンをアドレスに合わせる方法は、確実ですが、複数のプロファイルが異なるアドレスを使う場合は面倒です。もう1つは、ブラウザのプロファイルが報告するタイムゾーンを上書きする方法で、専用に作られたブラウザがやっているのはこれです。プロファイルのタイムゾーンが、起動時に使うアドレスに追従するため、2つの名前が自動的に一致します。2つ目の方法では、現在のオフセット、夏時間の切り替わり、ローカライズされた日付文字列もカバーしなければなりません。スクリプトはそのすべてを比較できるからです。Europe/Parisを報告しながら、ベルリンのオフセットで日付を整形するプロファイルは、矛盾を移動させただけです。
レポートで見るべきこと
「IPに基づくタイムゾーン」と「タイムゾーン」を並べて表示し、異なる場合にフラグを立てる診断は、サイトのチェックとまったく同じことをしています。一致していれば、チェックは通過です。一致していなければ、どちらを変えるべきかが分かります。いずれにせよ、有用なのは比較そのものであり、それに付けられたスコアではありません。
