Vazamento de Fuso Horário: Sua VPN Muda o IP, Não o Relógio

Você liga a VPN, escolhe um servidor em Amsterdã e carrega uma página. Seu endereço IP aparece como holandês em todos os sites de verificação de IP que você testa. E mesmo assim o checkout adiciona uma etapa extra de verificação, o catálogo do streaming continua errado, ou um login dispara um e-mail de “novo dispositivo”. O que entregou você cabe em uma linha de JavaScript: Intl.DateTimeFormat().resolvedOptions().timeZone.

Essa chamada retorna o fuso horário configurado no seu sistema operacional, e a VPN não tem influência nenhuma sobre ele. Seus pacotes agora saem de Amsterdã; seu navegador segue reportando America/New_York na maior tranquilidade. O widget nesta página roda a mesma comparação que um script antifraude rodaria: consulta o fuso horário que seu endereço IP indica, lê o fuso horário que seu navegador reporta e verifica se os dois concordam.

Versão resumida: um site obtém duas respostas independentes para "onde está este visitante": o fuso horário do endereço IP e o fuso horário do sistema operacional. Uma VPN muda apenas a primeira. Comparar as duas custa uma única linha de código, e falsificar a segunda pela metade é a única jogada que fica pior do que não falsificar nada.

Duas respostas para uma mesma pergunta

A primeira resposta vem da rede. Um site vê o IP de onde você se conecta e o consulta em um banco de dados de geolocalização: ipinfo.io, MaxMind e os concorrentes retornam um fuso horário junto com a localização. Com a VPN ligada, essa resposta aponta para o servidor de saída: conecte por Amsterdã e o banco de dados dirá Europe/Amsterdam. Como esses bancos são construídos, e o quanto podem errar sobre o seu endereço exato, é uma história que contamos em nosso artigo sobre geolocalização de IP. Mas, na granularidade de fuso horário, eles quase nunca erram.

A segunda resposta vem do seu sistema operacional. O JavaScript consegue ler o offset local em relação ao UTC desde os anos noventa via new Date().getTimezoneOffset(), e os navegadores modernos entregam o nome completo da zona IANA pela API Intl. Sem pedido de permissão, sem gesto do usuário, sem registro em nenhum painel de privacidade. É tratado como metadado comum, da mesma categoria que o tamanho da sua tela.

Um visitante, duas respostas

O que seus pacotes dizem

IP de saída da VPN 198.51.100.7 banco de dados geo Europe/Amsterdam

O que seu navegador diz

Relógio do SO Intl.DateTimeFormat() America/New_York

Divergência

Europe/Amsterdam ≠ America/New_York — flagrado por uma única comparação de strings, antes de você ter clicado em qualquer coisa.

A resposta da rede sai de uma consulta de geolocalização do IP de onde você se conecta. A resposta do navegador sai do seu sistema operacional. Uma VPN só muda a primeira.

Comparar as duas sai de graça, então todo mundo que tem um motivo faz exatamente isso: pontuação de fraude em pagamentos, controle de região em streaming, filtros de fraude publicitária, sistemas de segurança de contas e as pilhas antibot que já rodam uma dúzia de outras verificações de consistência.

Por que a VPN não resolve isso

Uma VPN criptografa seu tráfego e troca o endereço IP que os servidores veem. Essa é a descrição completa do cargo. Seu fuso horário nunca atravessa o túnel porque ele simplesmente nunca viaja. Ele mora nas configurações do seu sistema operacional, e o navegador o lê localmente e o reporta a qualquer script que perguntar.

O site não descobre a hora do seu relógio; descobre o identificador da zona. America/New_York é uma alegação de localização, com precisão de uma faixa vertical do planeta, que fica exposta à vista de todos, ao lado de navigator.language e do cabeçalho Accept-Language, que fazem o mesmo tipo de alegação sobre onde você mora.

Para ser justo, uma divergência não prova nada sozinha. Tem gente que viaja com um notebook que ainda acha que está em casa, e quem trabalha remoto às vezes mantém o fuso da equipe de propósito. Os sistemas de detecção sabem disso, e é por isso que a divergência alimenta uma pontuação de risco em vez de disparar um banimento. Mas pontuações se acumulam: divergência de fuso horário mais IP de datacenter mais um vazamento de WebRTC deixa de ser ambíguo, e cada sinal faz o próximo pesar mais.

A armadilha da falsificação pela metade

A correção óbvia é mentir sobre o fuso horário também, e existe uma pilha de extensões oferecendo exatamente isso. A maioria sobrescreve Intl.DateTimeFormat para que resolvedOptions().timeZone retorne o que você configurar. O problema é que seu navegador anuncia o fuso horário em mais de um lugar:

new Date().getTimezoneOffset() reporta quantos minutos seu relógio está atrás do UTC, por um caminho de código completamente diferente.
Date.prototype.toString() escreve a zona por extenso: “GMT-0400 (Eastern Daylight Time)“.
Formatar uma data para um dia qualquer do ano expõe suas regras de horário de verão, que fazem parte da identidade da zona.

Um offset fixo não é um fuso horário. Amsterdã é UTC+2 em julho, mas UTC+1 em janeiro, e muda de horário em datas diferentes das de Nova York: a União Europeia ajusta os relógios no último domingo de março, os Estados Unidos duas ou três semanas antes. Um script pode perguntar qual era o seu offset em primeiro de janeiro e em primeiro de julho e conferir se o par bate com a zona que você alega. Uma falsificação que crava um único offset o ano inteiro não corresponde a lugar nenhum que mude os relógios, e certamente não à Amsterdã que ela diz ser.

Deixe escapar qualquer um desses pontos e o navegador começa a discutir consigo mesmo:

consistente — Offsets mostrados para julho. Corrigir o nome do fuso horário e deixar escapar o offset do relógio produz um navegador que discute consigo mesmo, e essa contradição é um sinal mais forte do que a VPN jamais foi.

inconsistente — Offsets mostrados para julho. Corrigir o nome do fuso horário e deixar escapar o offset do relógio produz um navegador que discute consigo mesmo, e essa contradição é um sinal mais forte do que a VPN jamais foi.

Essa armadilha tem uma segunda camada. Um Intl.DateTimeFormat sobrescrito deixa de parecer nativo quando um script inspeciona seu código-fonte. É o mesmo indício de função corrigida que expõe plugins de stealth, aquele que destrinchamos no artigo sobre detecção de bots. Uma divergência limpa diz “provavelmente uma VPN”. Uma API adulterada diz “esta pessoa está manipulando ativamente o navegador”, e todo sistema de pontuação sério cobra mais caro por isso.

O que realmente fazer

Teste antes de confiar. O widget nesta página compara agora mesmo o fuso horário do seu navegador com o do seu IP, e o scan completo do navegador roda essa verificação junto com as de WebRTC, plataforma e fingerprint. Rode com a VPN ligada. Se o widget sinaliza você, todo script antifraude também sinaliza.
Mova o relógio junto com a VPN. A correção sem graça é a que funciona: configure o fuso horário do sistema para a cidade de saída antes de conectar. Não há nada para detectar, porque nada é falso: toda API reporta a mesma zona vinda da mesma fonte. A alternativa do pessoal da privacidade é o Tor Browser, que reporta UTC para todo mundo; sua zona real fica escondida, ao custo de parecer exatamente o Tor Browser.
Se você gerencia múltiplas identidades, pare de fazer isso na mão. Administrar contas em várias regiões significa que cada perfil precisa do próprio IP, fuso horário, idioma e fingerprint, todos concordando entre si, em toda sessão. Essa contabilidade é o que os navegadores anti-detecção automatizam: o Incogniton deriva o fuso horário de cada perfil a partir do IP do proxy, para que as duas respostas deste artigo nem cheguem a discordar.

A verificação de fuso horário é o cruzamento de dados de geolocalização mais barato que um script pode rodar, e é exatamente por isso que está em toda parte. Trinta segundos com o widget acima dizem de que lado dela você está.

Rodar o scan completo do navegador