Часовой пояс браузера против геолокации по 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 — не короткий путь
Сравнение смещений вместо идентификаторов поясов не исправляет вывод. Два разных пояса могут делить смещение часть года, и один и тот же пояс может менять смещение на границе летнего времени. Если функции действительно нужно смещение для планирования, вычислите его для конкретного момента, а не храните одно число и не используйте его снова как доказательство личности.
У сравнения строк своя ловушка: два написания одного пояса или устаревший псевдоним различаются как текст, хотя описывают одну настройку. Проверяйте идентификаторы и сравнивайте через обработку часовых поясов платформы, а не сопоставляя сырые строки.
Блокировать или оценивать: выбирайте реакцию осознанно