Zona horaria do navegador fronte á localización IP: comparación dun sinal de risco
A zona do navegador e a zona derivada da IP miden cousas distintas. Compare o que cada unha pode demostrar antes de que unha discrepancia se converta nun veredicto de VPN no seu modelo de risco.
Un navegador informa de Europe/London mentres unha base de datos IP sitúa a petición en America/New_York. É unha discrepancia entre dúas observacións e paga a pena rexistrala. Non é proba de que o visitante use unha VPN, e tratar iso como proba é onde fallan a maioría das implementacións. A comparación de abaixo mantén os dous valores, e os seus modos de fallo, por separado.
Dúas observacións con propietarios distintos
O valor do navegador é un axuste: a zona que o sistema operativo ou o usuario escolleu para formatar datas. O valor da base de datos é unha estimación ligada a unha rede IP, producida por un provedor que asigna bloques de enderezos a lugares. Ningún dos dous é unha declaración autenticada sobre onde está o visitante, e ningún sabe que camiño de rede tomou a petición.
Como os propietarios difiren, os dous valores poden diverxer por motivos que nada teñen que ver con ferramentas de privacidade. Un viaxeiro que conserva a zona da casa, un portátil corporativo fixado á hora da sede, unha ligazón por satélite con saída rexional ou unha fila obsoleta na base de datos producen todos unha discrepancia.
Como se produce realmente cada valor
Un navegador pode ler a súa zona resolvida con new Intl.DateTimeFormat().resolvedOptions().timeZone, que devolve un identificador IANA derivado da configuración do formateador. Non solicita permiso de localización nin consulta o GPS. No servidor, determine o enderezo do cliente a partir da súa configuración de proxy de confianza e despois consúlteo nun provedor aprobado. Unha cabeceira de reenvío fornecida polo visitante non é automaticamente ese enderezo.
Garde as dúas observacións en campos separados xunto coa hora da observación e o resultado da consulta. Chamar ao campo derivado vpnDetected cando o cálculo só é unha comparación de zonas incrusta unha conclusión nunha medición e dificulta a revisión posterior.
Que demostran a coincidencia e a discrepancia
| Observación | Que deixa sen resolver |
|---|---|
| Zonas informadas distintas | Unha viaxe, un axuste conservado, unha pasarela empresarial, un proxy ou un erro da base de datos poden producilo todo. |
| A mesma zona informada | Unha saída de VPN pode estar na zona do usuario, así que a coincidencia non establece unha conexión directa. |
| Un valor ausente ou non válido | A comparación non está dispoñible, o que non é nin coincidencia nin discrepancia. |
A asimetría importa máis do que suxire a táboa. Unha discrepancia ten moitas explicacións inocentes, mentres que unha coincidencia ten polo menos unha culpable, así que ningunha dirección sostén unha regra categórica. As propias notas de precisión do provedor describen precisión limitada e datos ausentes, e sinalan que un servizo de anonimización pode expor a localización do seu servidor en lugar da do usuario.
Por iso o sinal pertence a unha puntuación de risco cunha razón rexistrada e un estado descoñecido explícito, non a un booleano que controla o acceso.
Os desprazamentos UTC non son un atallo
Comparar desprazamentos en lugar de identificadores de zona non repara a inferencia. Dúas zonas distintas poden compartir un desprazamento durante parte do ano, e a mesma zona pode cambiar de desprazamento nun límite de horario de verán. Se unha función necesita de verdade un desprazamento para programar, calcúleo para o instante concreto en lugar de gardar un só número e reutilizalo como proba de identidade.
A comparación de cadeas ten a súa propia trampa: dúas grafías da mesma zona, ou un alias antigo, diferirán como texto mentres describen o mesmo axuste. Valide os identificadores e compare mediante o manexo de zonas horarias da plataforma en lugar de facer coincidir cadeas en bruto.
Bloquear ou puntuar: escolla a resposta deliberadamente
Para mostrar a hora, pregunte ao visitante que zona prefire e detéñase aí. Para un sistema de risco de aplicación, trate unha discrepancia como un sinal contextual débil xunto a probas que encaixen co modelo de ameaza real, e deixe que unha consulta fallida produza un descoñecido en lugar dunha detección silenciosa. Bloquear só pola comparación converte un oco de medición nunha acusación ao usuario.
Se unha decisión con consecuencias necesita unha garantía máis forte, use un paso de verificación ou autenticación deseñado para iso. Unha heurística de zona horaria non pode fornecer esa garantía, e un detector que conta a evidencia ausente como éxito pode parecer eficaz mentres responde a unha pregunta distinta da que vostede formulou.