Apps de viagem na Ásia coletam seus dados mesmo depois que você volta
Pesquisa da Surfshark revela que 97% dos apps essenciais para viagens na Ásia coletam dados do usuário, e 72% continuam rastreando mesmo após o retorno para cas
Uma pesquisa recente da Surfshark analisou 65 apps populares usados por turistas na Ásia, e o resultado é preocupante: 97% deles coletam dados do usuário, e 72% continuam rastreando informações mesmo depois que você já voltou para casa. Se você é dev e usa o smartphone como ferramenta de trabalho em viagens, ou se está pensando em construir apps com permissões de localização e acesso a dados, vale entender o que está acontecendo aqui.
Contexto técnico
Quando falamos em "coleta de dados" em apps mobile, estamos falando de permissões que o app solicita no Android ou iOS, como acesso a GPS, câmera, contatos, identificador do dispositivo (device ID), histórico de navegação e muito mais. Cada app pode declarar no App Store ou Google Play quais dados coleta e por qual motivo.
O problema identificado pela Surfshark é duplo:
Coleta excessiva: mais da metade dos apps coletam pelo menos 2 tipos de dados além do necessário para funcionar. Um app de táxi, por exemplo, precisa de localização para funcionar. Coletar também seu histórico de compras ou lista de contatos é coleta excessiva.
Linked data com terceiros: mais da metade dos apps vincula dados como device IDs e perfis de usuário a terceiros, geralmente para publicidade direcionada ou data brokers (empresas que compram e vendem dados pessoais em larga escala).
Para ilustrar a diferença de comportamento: o app Grab (categoria transporte) coleta 27 de 35 tipos de dados possíveis. O Rapido, que oferece o mesmo serviço, coleta apenas 4. Mesma categoria, abismos diferentes de privacidade.
Impacto para devs
Se você desenvolve apps mobile ou trabalha com integrações que lidam com dados de usuário, esse estudo serve como um alerta direto sobre boas práticas:
Princípio do menor privilégio aplicado a permissões:
// Ruim: pedir tudo de uma vez na inicialização
requestPermissions(arrayOf(
ACCESS_FINE_LOCATION,
READ_CONTACTS,
CAMERA,
READ_CALL_LOG // por quê um app de táxi precisa disso?
))
// Bom: pedir só o necessário, no momento necessário
// Localização só quando o usuário acionar o mapa
requestPermissions(arrayOf(ACCESS_FINE_LOCATION))
O que isso muda no dia a dia:
- Se você integra SDKs de analytics ou publicidade (Firebase, Meta SDK, Amplitude), saiba que esses SDKs podem coletar e transmitir dados por conta própria. Revise o que cada SDK faz antes de incluir no projeto.
- Ao usar third-party SDKs, você herda a política de privacidade deles. Se o SDK vaza dados, é o seu app que aparece na lista de infratores.
- Apps que continuam rodando em background (serviços de localização, por exemplo) precisam de justificativa clara. O caso citado no artigo, de um app de café canadense que rastreava localização mesmo fechado, é exatamente o tipo de comportamento que resulta em multas de LGPD/GDPR e reviews negativas.
Checklist mínimo de privacidade para devs:
[ ] Solicitar só as permissões realmente necessárias
[ ] Pedir permissões no contexto certo (não na abertura do app)
[ ] Revisar todos os SDKs de terceiros incluídos no projeto
[ ] Implementar opção de exclusão de conta e dados
[ ] Parar coleta de localização quando app for fechado
[ ] Testar o app com permissões negadas (não deve quebrar)
Conclusão
O problema não é só de usuário final. Cada vez que um dev inclui um SDK sem revisar, pede permissões desnecessárias ou não implementa lógica de limpeza de dados, contribui para esse ecossistema de coleta excessiva. A LGPD no Brasil e o GDPR na Europa já punem esse tipo de comportamento. Mais do que isso: usuários estão cada vez mais atentos a quais apps pedem o quê. Construir com privacidade em mente desde o início é mais fácil do que corrigir depois de um vazamento.