ブラウザのタイムゾーンと IP 位置情報：リスク信号としての比較

ブラウザのタイムゾーンと IP から推定したタイムゾーンは別のものを測っています。不一致を VPN の判定に使う前に、それぞれが何を証明できるかを比較します。

ブラウザは Europe/London を報告しているのに、IP データベースはそのリクエストを America/New_York に置いている。これは二つの観測の不一致であり、記録する価値がある。しかし訪問者が VPN を使っている証拠ではなく、証拠として扱うところにほとんどの実装はつまずく。以下の比較では、二つの値とそれぞれの失敗の仕方を切り離して扱う。

所有者の異なる二つの観測

ブラウザ側の値は設定である。オペレーティングシステムや利用者が日付の整形のために選んだタイムゾーンだ。データベース側の値は IP ネットワークに紐づく推定値で、アドレスブロックを場所に対応づける事業者が生成する。どちらも訪問者がどこに立っているかを認証した表明ではなく、どちらもリクエストがたどったネットワーク経路を知らない。

所有者が違うため、二つの値はプライバシー関連のツールとは無関係な理由でも食い違う。自宅のタイムゾーンを保つ旅行者、本社の時刻に固定された会社のノートパソコン、地域ごとの出口を持つ衛星回線、古いデータベースの行、いずれも不一致を生む。

それぞれの値が実際にどう作られるか

ブラウザは解決済みのタイムゾーンを次で読める：new Intl.DateTimeFormat().resolvedOptions().timeZonenew Intl.DateTimeFormat().resolvedOptions().timeZone

。これはフォーマッタの設定から導かれた IANA 識別子を返す。位置情報の許可を求めず、GPS も参照しない。サーバー側では、信頼するプロキシ設定からクライアントのアドレスを解決し、承認済みの事業者で検索する。訪問者が提供する転送ヘッダーが、そのままそのアドレスになるわけではない。vpnDetected二つの観測は、観測時刻と検索結果とともに別々のフィールドとして保存する。計算が単なるタイムゾーンの比較であるのに、派生フィールドを

vpnDetected

と名付けると、測定に結論を焼き込み、後からの見直しを難しくする。一致と不一致がそれぞれ何を証明するか
観測未解決のまま残ること
報告されたタイムゾーンが異なる旅行、保持された設定、企業のゲートウェイ、プロキシ、データベースの誤り、いずれもこれを生み得る。
報告されたタイムゾーンが同じVPN の出口が利用者のタイムゾーン内にあることもあるため、一致は直接接続を裏づけない。

片方の値が欠落または無効

比較ができない状態であり、一致でも不一致でもない。

非対称性は表が示す以上に重要だ。不一致には無害な説明が数多くある一方、一致には少なくとも一つの後ろめたい説明がある。したがってどちらの向きも断定的な規則を支えない。事業者自身の精度に関する注記も、精度の限界と欠損データを述べ、匿名化サービスは利用者ではなくサーバーの所在を露出し得ると指摘している。

だからこの信号は、理由と明示的な不明状態を記録したリスクスコアに属し、アクセスを左右するブール値に属さない。

UTC のオフセットは近道ではない

タイムゾーン識別子の代わりにオフセットを比べても、推論は修復されない。別々のタイムゾーンが年の一部で同じオフセットを共有することがあり、同じタイムゾーンでも夏時間の境界でオフセットが変わる。機能がスケジューリングのために本当にオフセットを必要とするなら、一つの数値を保存して身元の証拠として使い回すのではなく、その時点のために計算する。

文字列の比較にも罠がある。同じタイムゾーンの二つの表記や旧式の別名は、同じ設定を指していてもテキストとしては異なる。生の文字列を照合するのではなく、識別子を検証し、プラットフォームのタイムゾーン処理を通して比較する。

遮断か評価か：対応を意識的に選ぶ

関連記事