Viagem impossível: a regra que acusa o cliente honesto que negou a localização

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.

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.

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.

É 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.
• 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.