# Viagem impossível: a regra que acusa o cliente honesto que negou a localização Análise · UNIFOKAL · 5 de setembro de 2026 · 8 min de leitura · Antifraude Comparar o GPS de um evento com a geolocalização de IP do seguinte produz velocidade impossível sem que ninguém tenha viajado. Como desenhar a regra, quais pisos ela precisa e o que ela pode decidir. Depois que o cadastro é aprovado, a conta continua produzindo eventos: entradas, depósitos, saques, troca de dispositivo. Monitorar essa sessão é o que permite perceber que a conta legítima mudou de dono sem que nada no cadastro tenha mudado. A regra mais intuitiva desse monitoramento é a viagem impossível. Dois eventos da mesma conta, cada um com uma posição e um horário, e a velocidade implícita entre eles maior do que qualquer deslocamento físico plausível. É fácil de explicar, é fácil de programar, e costuma produzir alarme falso contra o titular legítimo quando construída sem cuidado. O erro de projeto que causa isso não está na fórmula. Está na origem das duas posições que entram nela. ## A regra parece aritmética simples Pegue dois eventos consecutivos, calcule a distância entre as posições, divida pelo intervalo, compare com um teto. Acima do teto, alerta. O teto é uma escolha declarada, não uma verdade física. Um valor da ordem de novecentos quilômetros por hora fica na faixa da velocidade de cruzeiro da aviação comercial e muito acima de qualquer deslocamento terrestre, o que serve para capturar o impossível, não o incomum. Qualquer número erra nas bordas, e ele precisa estar escrito na política, com data, para que mudar a sensibilidade seja decisão e não efeito colateral. Até aqui não há dificuldade. Ela aparece quando se pergunta de onde vêm as coordenadas. ## Duas fontes de posição que não se comparam Numa aplicação web há duas origens possíveis para a posição de um evento, e elas medem coisas diferentes. A primeira é a geolocalização do navegador. A especificação Geolocation API, do W3C, trata a funcionalidade como poderosa e exige permissão expressa do usuário antes de qualquer dado de localização ser compartilhado com a aplicação. A recusa devolve o código PERMISSION_DENIED, que na mesma especificação cobre também o contexto não seguro e o bloqueio pela política de permissões da própria página: quem recebe esse erro no servidor não sabe se o titular disse não ou se o site está mal configurado. E a permissão some sem ninguém retirá-la, porque a especificação recomenda limitar a duração dela a uma única sessão. E há um detalhe da mesma especificação que desmonta a suposição mais comum a respeito dela. A introdução lista as fontes usuais de localização, e entre elas está a inferida a partir de sinais de rede, o endereço IP inclusive, ao lado de Wi-Fi, Bluetooth e identificadores de célula; e acrescenta que a interface é agnóstica quanto a essas fontes e que não é dada garantia de que a resposta seja a localização real do dispositivo. Ou seja: uma posição rotulada como vinda do navegador pode ter sido derivada do mesmo endereço IP que a outra via usaria. A segunda origem é a geolocalização por endereço IP, que não pede permissão porque não pergunta nada a ninguém: infere a posição a partir de bases que mapeiam prefixos de rede para lugares. A RFC 8805, "A Format for Self-Published IP Geolocation Feeds", de agosto de 2020, é uma submissão independente publicada pelo RFC Editor e registra um formato já em uso. A motivação que ela declara é esta: quando um provedor muda o lugar onde um prefixo está implantado, os serviços que usam geolocalização podem começar a sofrer degradação, e falta meio centralizado de comunicar isso aos interessados. O formato, aliás, só admite de propósito localização grosseira, e marca o código postal como desaconselhado por ser específico demais. Agora junte as duas. O titular legítimo concede a permissão no primeiro evento e a nega no segundo, ou troca o aplicativo pelo navegador do computador. O primeiro evento carrega uma coordenada fina; o segundo cai para o ponto grosseiro que a base associa àquele prefixo de rede, que pode ficar bem longe do lugar real. A diferença entre as duas posições não é deslocamento, é troca de instrumento de medição, e a fórmula devolve uma velocidade impossível. A direção do erro tende a ser a pior. Quem concede a permissão é, em geral, o cliente que instalou o aplicativo. Quem opera de fora, por um navegador limpo num endereço de datacenter, quase nunca tem posição concedida a oferecer, e por isso raramente produz o par de fontes misturadas. A exceção é o invasor que age de dentro do aparelho do titular, e esse já herda a permissão. A correção é uma linha de política, não um modelo melhor: carimbe cada posição com a fonte de onde ela veio e só compare posições de mesma procedência. O par de fontes diferentes é descartado sem alerta, e o descarte precisa deixar rastro, porque "não houve viagem" e "a viagem era imensurável" são coisas diferentes para quem revisa depois. Vale dizer o que essa guarda não faz. Como a posição do navegador pode vir ela própria de inferência de rede, dois eventos com o mesmo rótulo ainda podem ter precisões distintas. Carimbar a fonte reduz o alarme falso, não o elimina; quem precisar de mais olha a precisão declarada em cada leitura, que a interface devolve junto das coordenadas. Já cair para o IP dos dois eventos no par misto parece elegante e é armadilha de outro tipo, porque muda a sensibilidade da regra no meio da sessão sem que nada no registro indique isso. Sobre o que o endereço de rede de fato prova, e o que o CGNAT destrói, vale o artigo sobre [VPN, proxy e IP de datacenter](https://unifokal.com/blog/ip-de-vpn-proxy-e-datacenter). Cruzar as duas fontes tem um uso legítimo, e é outro: comparar a posição do navegador e a do IP do mesmo evento. Distância grande entre elas sinaliza manipulação de uma das duas, e isso é regra própria, com limiar próprio, sem relação com viagem. ## Os pisos que impedem a regra de gritar Mesmo com fontes homogêneas, a divisão precisa de dois pisos. Um piso de distância, e generoso. A saída de rede de uma operadora móvel costuma ficar num concentrador longe do assinante, então o mesmo cliente parado troca de posição aparente entre cidades sem sair do lugar, e a granularidade grosseira que a RFC 8805 assume garante que o dado nem tenta ser preciso nessa escala. Abaixo de uma distância mínima, o par não produz alerta. Um piso de intervalo. Dois eventos separados por poucos segundos dividem uma distância qualquer por um tempo próximo de zero, e o resultado é aritmética, não evidência. Parecem detalhe, e são o que separa uma regra usável de uma que a operação desliga na primeira semana. ## O aparelho compartilhado e a colisão de identificador A segunda regra clássica do monitoramento é o aparelho compartilhado: o mesmo identificador de dispositivo em várias contas distintas dentro de uma janela. É um bom sinal de fazenda de contas. É também o sinal em que identificador fraco se confunde com fraude real. Uma impressão digital derivada só do que o navegador entrega colide com facilidade: aparelho popular, navegador atualizado, configuração padrão, e muita gente produz o mesmo valor. O que o navegador consegue e o que não consegue entregar está detalhado em [sinais de dispositivo sem SDK nativo](https://unifokal.com/blog/sinais-de-dispositivo-sem-sdk). Existe um teste barato que separa os dois casos, e ele usa um segundo eixo em vez de um limiar maior: conte, na mesma janela, quantas contas distintas usaram aquele identificador e quantos prefixos de rede distintos apareceram junto. Muitas contas concentradas em poucas redes descrevem um operador com várias contas. Tantas redes quanto contas descrevem pessoas diferentes que por acaso produzem a mesma impressão digital: ruído, e alertar sobre ele enche a fila de gente honesta. ## Um sinal de sessão não recusa ninguém Monitoramento de sessão acontece depois da decisão: a conta existe, a pessoa já passou pelo cadastro, e o que chega agora é indício sobre comportamento, construído sobre localização declaradamente grosseira e sobre identificadores que colidem. Nada disso sustenta recusa automática. O desfecho correto é revisão humana, com a evidência anexada: quais foram os dois eventos, de que fonte vieram as posições, a distância, o intervalo e a velocidade calculada. Sem esses campos o analista recebe um rótulo e nenhum meio de discordar. As defesas para quando a conta legítima realmente cai estão em [tomada de conta](https://unifokal.com/blog/tomada-de-conta-account-takeover). É preciso controlar o volume, senão a regra se apaga por saturação: intervalo mínimo entre alertas do mesmo caso, teto diário por titular e teto diário por empresa. Com uma exceção deliberada, porém: o alerta de severidade mais alta não pode ser silenciado pelo teto de volume. Um limite que emudece o pior achado do dia trabalha para o atacante. ## Fontes citadas - W3C, Geolocation API, sobre permissão expressa, o erro PERMISSION_DENIED, a recomendação de limitar a permissão a uma sessão, as fontes de localização admitidas (inferência por endereço IP inclusive) e a ausência de garantia sobre a localização real do dispositivo: [w3.org](https://www.w3.org/TR/geolocation/). - RFC 8805, "A Format for Self-Published IP Geolocation Feeds", de agosto de 2020, submissão independente informativa publicada pelo RFC Editor, sobre o desalinhamento entre prefixo e lugar e a granularidade grosseira do dado: [rfc-editor.org](https://www.rfc-editor.org/rfc/rfc8805.html).