A análise de dois aplicativos de relacionamento voltados ao público gay mostra como distâncias, ordenação de perfis e contas auxiliares podem reduzir proteções de privacidade e permitir estimativas de localização com precisão de metros em determinadas condições.
| Componente | Recursos de geolocalização e ordenação por proximidade em dois aplicativos de relacionamento gay com mais de 10 milhões de downloads; um deles é o Hornet. |
| Vetor | Abuso de distâncias exibidas, ordem de resultados por proximidade e contas auxiliares com localização controlada para estimar a distância até um perfil-alvo e aplicar trilateração. |
| Impacto | Determinação aproximada da posição de usuários, mesmo quando a distância direta é ocultada ou randomizada, com medições que chegaram a erro médio de 24 metros em um cenário de teste do Hornet antes das medidas corretivas observadas. |
| Prioridade | Reduzir precisão de localização no servidor, evitar ordenação determinística por distância curta, auditar APIs de presença e validar se ocultar distância realmente impede inferência por ranking. |
| Artefatos | O primeiro aplicativo codificava coordenadas em geohash de 12 dígitos, mas arredondava latitude e longitude para três casas decimais antes da codificação, limitando a precisão prática a uma área com lado maior de aproximadamente 110 metros. |
| Mitigação | No Hornet, medidas adicionais foram observadas antes da publicação e reduziram significativamente a precisão com que coordenadas de usuários podiam ser determinadas. |
Aplicativos de relacionamento usam localização para mostrar pessoas próximas, ordenar perfis por distância e aumentar a chance de encontros presenciais. Essa funcionalidade cria uma superfície de privacidade quando o serviço revela, direta ou indiretamente, a distância entre usuários. Mesmo quando a coordenada exata não aparece na interface, a combinação de distância aproximada, ordenação dos resultados e contas controladas por um observador pode permitir inferência espacial. O problema é mais sensível em aplicativos voltados a comunidades que podem sofrer perseguição, discriminação ou violência, porque a exposição da posição de um perfil pode transformar um recurso de conveniência em risco físico e operacional.
A análise cobriu dois aplicativos populares de relacionamento gay, ambos com mais de 10 milhões de downloads e citados em estudos anteriores sobre vazamento de geolocalização. Os dois permitem desativar a exibição da distância, mas isso não encerra necessariamente o risco se o backend ainda usar proximidade como sinal de ranking ou se as respostas da API preservarem relações suficientes para estimar posição. No primeiro aplicativo, a precisão foi reduzida por arredondamento das coordenadas antes da codificação em geohash. No Hornet, a proteção dependia de randomização da distância exibida e de recursos para ocultar distância, mas os testes mostraram que essas medidas eram insuficientes em determinadas condições antes de mudanças corretivas observadas posteriormente.
O ponto central é a trilateração, técnica que estima coordenadas desconhecidas a partir de distâncias conhecidas entre o alvo e pontos de referência. Em um serviço de relacionamento, esses pontos de referência podem ser contas controladas, posicionadas logicamente em locais diferentes. A defesa esperada seria impedir que o observador obtenha distâncias precisas ou ordenação confiável o bastante para resolver a posição. O problema é que a própria busca por usuários próximos pode funcionar como canal lateral: se dois perfis com distância conhecida aparecem ao redor de um perfil-alvo na lista, a distância aproximada até o alvo pode ser inferida pela posição relativa no ranking.
No primeiro aplicativo analisado, as coordenadas eram transmitidas como geohash de 12 dígitos. Um geohash nessa granularidade pode representar retângulos pequenos, mas o aplicativo arredondava latitude e longitude para três casas decimais antes da codificação. Esse arredondamento degradava a precisão teórica para uma área cujo lado maior ficava em torno de 110 metros. Essa abordagem não elimina a inferência de área, mas reduz bastante a precisão em comparação com o envio de coordenadas mais detalhadas. Para uma equipe defensiva, a lição é que a proteção relevante não é apenas a forma de codificação, e sim a precisão real preservada antes de qualquer transformação.
No Hornet, as coordenadas precisas eram enviadas ao servidor, enquanto a distância apresentada ao usuário era randomizada. Quando a distância não era desativada, os testes indicaram que ela podia ser transmitida com granularidade de até 10 metros, mas os valores variavam entre requisições e nem sempre correspondiam à ordem exibida nos resultados. A aplicação também podia alterar a ordem quando a diferença entre dois usuários ficava abaixo de um limiar estimado em aproximadamente 50 metros. Essas medidas introduzem ruído, mas não impedem inferência se o atacante puder repetir medições, controlar contas auxiliares e observar a posição relativa do alvo na lista.
A técnica testada usou contas adicionais com localização controlada para estimar a distância até o alvo sem depender de usuários reais próximos. Em medições entre pontos aleatórios separados por 1 a 2 quilômetros, os erros ficaram abaixo de 0,5 metro no melhor caso e chegaram a 49 metros no pior caso. A distribuição mostrou que o ruído associado ao limiar de 50 metros não era uniforme o bastante para bloquear a inferência: cerca de 30% das medições ficaram na faixa de 0 a 6 metros. Em um cenário de trilateração com grupos de pontos de referência ao redor de uma área de 10 quilômetros de diâmetro, os resultados produziram erro máximo de 350 metros, erro mínimo de 2 metros e média final a 24 metros do ponto-alvo.
A superfície afetada envolve qualquer fluxo que combine geolocalização de perfil, busca por proximidade, ranking espacial e presença recente. Mesmo que a interface ofereça um controle para ocultar distância, a API e o algoritmo de ordenação podem continuar expondo relações espaciais. O risco aumenta quando o serviço permite que contas modifiquem a própria localização ou quando a presença online influencia a probabilidade de aparecer nos resultados. No caso analisado, foi observado um endpoint de notificação de presença online usado em testes para manter o usuário visível na lista de perfis próximos, o que demonstra como sinais de disponibilidade podem interagir com privacidade de localização.
Usuários que deixam a distância visível ficam expostos a medições diretas, ainda que randomizadas. Usuários que desativam a distância podem continuar expostos se a posição no ranking revelar proximidade relativa. Ambientes urbanos densos, áreas pequenas e cenários em que o observador já conhece a cidade ou região geral do alvo tornam a inferência mais viável, porque reduzem o espaço inicial de busca. O contexto também é crítico para pessoas LGBTQ+ em regiões onde exposição de identidade ou presença física pode gerar risco social, legal ou físico.
- Aplicativos de relacionamento que ordenam resultados por proximidade mesmo quando ocultam a distância exibida.
- Perfis que aparecem com frequência em listas de usuários próximos por estarem online ou recentemente ativos.
- APIs que aceitam ou processam coordenadas precisas no servidor sem reduzir granularidade antes da lógica de ranking.
- Controles de privacidade que afetam a interface, mas não removem canais laterais criados por ranking, presença e repetição de consultas.
A detecção defensiva deve tratar esse tipo de abuso como inferência por consulta repetida, não como exploração tradicional com payload. O sinal mais relevante é comportamento anômalo de contas que consultam listas de usuários próximos em volume elevado, alternam coordenadas declaradas ou simuladas e fazem requisições repetidas em curtos intervalos para os mesmos alvos ou regiões. Em aplicações móveis, esse padrão pode aparecer em logs de API, trilhas de sessão, eventos de atualização de localização, respostas de busca e uso de recursos de presença.
Equipes de engenharia devem correlacionar mudanças de localização com frequência de busca, distância percorrida implausível, criação de contas auxiliares e padrões de consulta que varrem uma região em torno de um perfil. Também é importante medir se a randomização realmente altera a ordenação, e não apenas o número apresentado na interface. Se o servidor mantém ranking estável para diferenças pequenas, a lista continua funcionando como um canal lateral. Testes de privacidade devem incluir usuários que ocultam distância, usuários online, usuários recém-online e cenários com baixa densidade de perfis, porque cada condição pode alterar a precisão da inferência.
- Sequências de requisições de busca com muitas coordenadas diferentes associadas à mesma conta ou ao mesmo dispositivo.
- Consultas repetidas a listas de proximidade em janelas curtas, especialmente quando o conjunto de perfis retornados se mantém quase igual.
- Eventos de presença usados em conjunto com buscas de proximidade para aumentar a chance de um perfil aparecer nos resultados.
- Diferenças entre distância exibida, distância usada no ranking e ordem real dos perfis retornados pela API.
- Contas recém-criadas que alternam localização e consultam perfis em uma área geográfica restrita.
A mitigação precisa ocorrer no servidor, antes que coordenadas precisas sejam usadas para ranking ou respostas de API. Arredondar coordenadas, aplicar zonas de privacidade, agrupar usuários por células maiores e introduzir limites mínimos de resolução são medidas mais robustas do que apenas esconder o número de distância na interface. Quando a distância é desativada, o serviço deve avaliar se o perfil também precisa sair de rankings estritamente ordenados por proximidade ou aparecer apenas em grupos amplos, sem relação espacial refinada. Randomização isolada pode reduzir precisão, mas não deve ser considerada suficiente se medições repetidas convergem para valores úteis.
Para engenharia de produto, o controle de privacidade deve ter semântica verificável: ocultar distância deve impedir inferência razoável da posição, não apenas remover um campo visual. Isso exige testes automatizados de privacidade com contas controladas, medições repetidas e validação estatística dos resultados. Também é necessário limitar mudanças frequentes de localização, monitorar abuso de presença online e impor rate limiting por conta, dispositivo, rede e região. Antes de liberar alterações, a equipe deve comparar a precisão obtida por trilateração contra um limite aceitável de privacidade e documentar o comportamento em áreas densas e pouco densas.
Usuários com risco elevado devem desativar a exibição de distância quando o aplicativo oferecer esse recurso e revisar permissões de localização no sistema operacional. Essa ação reduz exposição direta, mas não garante proteção se o aplicativo continuar usando proximidade como canal lateral. A responsabilidade principal permanece no serviço, que controla granularidade, ranking, APIs e telemetria. No caso do Hornet, uma reavaliação antes da publicação identificou que medidas necessárias já haviam sido adotadas para reduzir significativamente a precisão da determinação de coordenadas, mas a classe de risco continua aplicável a qualquer aplicativo que combine localização precisa e descoberta social por proximidade.
- Reduzir a precisão das coordenadas no servidor antes de ranking, cache, busca ou qualquer resposta de API.
- Substituir ordenação fina por distância por agrupamentos amplos quando o usuário ocultar distância ou ativar modo de privacidade.
- Aplicar rate limiting e detecção comportamental para contas que fazem medições repetidas com localização variável.
- Auditar endpoints de presença para impedir que eles aumentem a previsibilidade de aparição de um perfil em buscas próximas.
- Executar testes de trilateração internos com contas controladas e bloquear lançamentos que permitam precisão de metros para localização de usuários.
0 Comentários