Fuso horário do navegador versus localização por IP: um sinal de risco comparado
O fuso do navegador e o fuso derivado do IP medem coisas diferentes. Compare o que cada um pode provar antes que uma divergência vire veredito de VPN no seu modelo de risco.
Um navegador informa Europe/London enquanto um banco de dados de IP coloca a requisição em America/New_York. Isso é uma discordância entre duas observações, e vale registrá-la. Não é prova de que o visitante use VPN, e tratá-la como prova é onde a maioria das implementações erra. A comparação abaixo mantém os dois valores, e seus modos de falha, separados.
Duas observações com donos diferentes
O valor do navegador é uma configuração: o fuso que o sistema operacional ou o usuário escolheu para formatar datas. O valor do banco de dados é uma estimativa ligada a uma rede IP, produzida por um provedor que mapeia blocos de endereços para lugares. Nenhum dos dois é uma declaração autenticada sobre onde o visitante está, e nenhum sabe qual caminho de rede a requisição percorreu.
Como os donos diferem, os dois valores podem divergir por motivos que nada têm a ver com ferramentas de privacidade. Um viajante que mantém o fuso de casa, um notebook corporativo fixado no horário da matriz, um link de satélite com saída regional ou uma linha desatualizada no banco de dados produzem uma divergência.
Como cada valor é realmente produzido
Um navegador pode ler o fuso resolvido com new Intl.DateTimeFormat().resolvedOptions().timeZonenew Intl.DateTimeFormat().resolvedOptions().timeZone
, que retorna um identificador IANA derivado das configurações do formatador. Não pede permissão de localização e não consulta GPS. No servidor, resolva o endereço do cliente a partir da configuração de proxy confiável e depois consulte-o em um provedor aprovado. Um cabeçalho de encaminhamento fornecido pelo visitante não é automaticamente esse endereço.vpnDetectedArmazene as duas observações como campos separados, com o horário da observação e o resultado da consulta. Nomear o campo derivado de
vpnDetected
| quando o cálculo é apenas uma comparação de fusos embute uma conclusão na medição e dificulta a revisão posterior. | O que a concordância e a discordância provam |
|---|---|
| Observação | O que ela deixa em aberto |
| Fusos informados diferentes | Viagem, uma configuração mantida, um gateway corporativo, um proxy ou um erro no banco de dados podem produzir isso. |
| O mesmo fuso informado | Uma saída de VPN pode estar no fuso do usuário, então a concordância não estabelece conexão direta. |
Um valor ausente ou inválido
A comparação fica indisponível, o que não é concordância nem discordância.
A assimetria importa mais do que a tabela sugere. Uma divergência tem muitas explicações inocentes, enquanto uma concordância tem pelo menos uma culpada, então nenhuma direção sustenta uma regra categórica. As próprias notas de precisão do provedor descrevem precisão limitada e dados ausentes, e apontam que um serviço de anonimização pode expor a localização do servidor dele, não a do usuário.
Por isso o sinal pertence a uma pontuação de risco com motivo registrado e um estado desconhecido explícito, não a um booleano que controla acesso.
Deslocamentos UTC não são atalho
Comparar deslocamentos em vez de identificadores de fuso não corrige a inferência. Dois fusos diferentes podem compartilhar um deslocamento por parte do ano, e o mesmo fuso pode mudar de deslocamento na fronteira do horário de verão. Se um recurso realmente precisa de um deslocamento para agendamento, calcule-o para o instante específico em vez de guardar um número e reutilizá-lo como prova de identidade.
A comparação de strings tem sua própria armadilha: duas grafias do mesmo fuso, ou um alias antigo, diferem como texto embora descrevam a mesma configuração. Valide os identificadores e compare pelo tratamento de fusos da plataforma em vez de casar strings cruas.
Bloquear ou pontuar: escolha a resposta de propósito