Os utilizadores de aplicações não estão à venda!

· ~7 min de leitura

Somos engenheiros de software e sabemos como é ridiculamente fácil recolher os seus dados. Acrescentar uma biblioteca de rastreamento a uma aplicação leva umas quatro linhas de código e uma tarde. A partir daí, o telemóvel envia um relatório para o servidor de um desconhecido sempre que se toca num botão. Vem no modelo. Toda a gente faz isso.

É esse o problema. Depois de anos a ver o «toda a gente faz isso» transformar-se em manchete atrás de manchete, decidimos construir aplicações ao contrário. Este artigo explica porquê, em palavras simples e sem jargão sempre que possível.

Uma breve e incompleta história do «ups»

Provavelmente lembra-se de alguns destes casos. Na altura, cada um parecia um caso isolado.

  • 2018, Cambridge Analytica. Cerca de 270 mil pessoas fizeram um teste de personalidade no Facebook. Através das listas de amigos, o teste recolheu discretamente dados de até 87 milhões de pessoas, que foram depois usados para segmentação política (Wikipedia). Mais tarde, o Facebook pagou nos EUA uma multa de 5 mil milhões de dólares. A maioria desses 87 milhões nunca tocou no teste.
  • 2018, Strava. A aplicação de fitness publicou um bonito «mapa de calor» dos sítios onde os seus utilizadores correm. Esse mapa também mostrava os contornos de bases militares secretas, porque os soldados também correm.
  • 2020, Muslim Pro. Descobriu-se que a popular aplicação muçulmana de oração enviava os dados de localização dos seus utilizadores para o corretor de dados X-Mode, que tinha entre os seus clientes empresas contratadas pelas forças armadas dos EUA. As pessoas instalaram-na para saber as horas de oração.
  • 2021, 533 milhões de números de telefone. Números de telefone e nomes de mais de meio milhar de milhões de utilizadores do Facebook apareceram num fórum de hackers. Os dados tinham sido recolhidos em massa através de uma funcionalidade de «encontrar amigos».
  • 2023, uma multa recorde. A Meta foi multada em 1,2 mil milhões de euros na UE por transferir dados de europeus para os EUA. Na altura, foi a maior multa de sempre ao abrigo do RGPD.
  • 2025, Gravy Analytics. Hackers invadiram um corretor de dados de localização. A fuga enumerava milhares de aplicações comuns (jogos, aplicações de encontros, monitores de fitness) cujas localizações dos utilizadores tinham ido parar ali, muitas vezes sem que os criadores das aplicações soubessem. Os dados tinham saído através do sistema de publicidade.
  • 2025, o truque do localhost. Num estudo chamado «Local Mess», investigadores descobriram que o código de rastreamento da Meta em sites passava informação às aplicações do Facebook e do Instagram no mesmo telemóvel Android. Assim, a Meta conseguia associar a navegação «anónima» à conta real do utilizador, mesmo em modo privado.

Não é preciso decorar os pormenores. O que importa é o padrão: os dados que são recolhidos acabam, mais cedo ou mais tarde, por ser usados, vendidos, divulgados numa fuga ou alvo de multa. Normalmente, mais do que uma destas coisas.

Quer a versão longa? A Federal Trade Commission (FTC), a autoridade de defesa do consumidor dos EUA, mantém uma lista dos seus processos em matéria de privacidade e segurança, a sociedade de advogados CMS gere o GDPR Enforcement Tracker com todas as multas publicamente conhecidas ao abrigo da lei europeia de proteção de dados, e a Wikipedia mantém uma lista de fugas de dados sempre atualizada. Fica o aviso: as três são longas, e as três estão em inglês.

O problema da lanterna

Este é o nosso exemplo preferido, precisamente por ser tão pequeno. Em 2013, a FTC dos EUA avançou contra uma aplicação de lanterna extremamente popular, a Brightest Flashlight Free. Uma lanterna. Enviava a localização exata e o identificador do dispositivo dos seus utilizadores para redes de publicidade.

Do ponto de vista de um engenheiro, isto é absurdo. Num telemóvel Android atual, ligar a lanterna não exige uma única autorização. Não há nenhuma razão técnica para uma lanterna saber onde o utilizador está, quem tem nos contactos ou o que mais tem no telemóvel.

Mas os dados valem dinheiro, por isso as aplicações pedem-nos na mesma. A aplicação de meteorologia quer a localização a toda a hora, e não apenas quando se consulta a previsão. O jogo quer os contactos. O teclado quer «acesso total». Na maior parte das vezes, não é para a funcionalidade. É para a recolha de dados de alguém, e quanto mais, melhor, porque isso aumenta o seu valor para anunciantes e outros interessados.

Como acontece (raramente há um vilão)

Para sermos justos com os nossos colegas do setor: a maior parte disto não é obra de vilões de banda desenhada. Acontece uma decisão de aparência razoável de cada vez:

  • «Vamos pôr análises para sabermos que botões as pessoas usam.»
  • «A biblioteca de publicidade paga as contas, e é só uma linha.»
  • «Vamos registar tudo, para o caso de precisarmos mais tarde.»
  • «Vamos obrigar as pessoas a registar-se, para lhes podermos enviar novidades.»

Cada passo faz sentido por si só. Somados, temos uma empresa sentada em cima de uma pilha de dados pessoais de que não precisa realmente, guardada por quem teve tempo de configurar o servidor nessa semana. Cada base de dados é uma futura fuga à espera da sua data.

Por isso, escrevemos algumas regras para nós próprios

Quando começámos a fazer aplicações móveis na EiBPM, escrevemos o que íamos fazer em vez disso. Dez regras, sem exceções. Aqui estão, agrupadas pela sua finalidade.

É o cliente, não o produto

  • Sem publicidade. Quando cobramos por uma aplicação, esse preço é todo o modelo de negócio. Ninguém nos paga por fora pela atenção do utilizador.
  • Sem rastreadores. Sem bibliotecas de análise, sem fingerprinting, sem chamadas discretas a terceiros. As quatro linhas de código da introdução? Não as escrevemos.

Sem nada para entregar, nada pode fugir

  • Sem contas. Sem registo, sem endereço de e-mail, sem palavra-passe para esquecer ou para ser roubada. Instala-se e funciona.
  • Sem recolha de dados. Os seus dados ficam no seu dispositivo, porque não temos nenhum servidor para onde possam ir. Não podemos perder o que nunca tivemos.
  • Sem espionagem de localização. Se uma aplicação precisar da sua localização, por exemplo para calcular a que horas nasce o sol onde está, as contas são feitas no seu dispositivo. Nunca vemos o resultado.

A internet é a exceção, não a regra

  • Offline por predefinição. As nossas aplicações funcionam sem ligação. Só se ligam à internet quando uma funcionalidade não consegue mesmo funcionar de outra forma, e nesse caso dizem-no.
  • Privacidade por predefinição. Só pedimos uma autorização quando uma funcionalidade precisa mesmo dela. Tudo o que é opcional começa desativado, e é o utilizador que o ativa.

Respeito pelo seu dispositivo e pelo seu tempo

  • Design claro. Layouts honestos, texto legível, sem dark patterns a empurrar para o botão «Aceitar tudo».
  • Baixo consumo. Código que bebe aos golinhos, não de um trago. Num relógio, a autonomia da bateria é uma funcionalidade, e uma aplicação que não está sempre a ligar para casa gasta muito menos.
  • Sem aplicação complementar. As nossas aplicações de relógio funcionam por si só. Uma aplicação de telemóvel obrigatória é uma das formas clássicas de recolher dados que o relógio, sozinho, nunca teria entregado.

«Não conseguimos» vale mais do que «não vamos»

Esta é a ideia de engenharia no centro de tudo. Uma política de privacidade é uma promessa: não vamos usar indevidamente os seus dados. As promessas quebram-se. As empresas são compradas, os orçamentos são cortados, os servidores são atacados, as políticas são «atualizadas».

Por isso, apostámos na arquitetura em vez de promessas: não conseguimos usar indevidamente os seus dados, porque não os temos. E quando dizemos nada, é mesmo nada. Nem sequer temos uma lista de clientes. Quando compra uma das nossas aplicações, o Google Play trata do pagamento, e tudo o que nos chega é um número de encomenda, o país de onde veio e, em alguns países, um código postal para efeitos fiscais. Nenhum nome, nenhum endereço de e-mail, nenhuma ideia de quem é.

Se amanhã alguém invadisse os nossos sistemas, sairia de mãos a abanar. Não há nada para vender, nada para divulgar, nada para entregar a um tribunal.

O que isto nos custa (com toda a franqueza)

Isto não nos sai de graça, e não vamos fingir que sim.

  • Não sabemos que funcionalidades usa mais. Quando queremos saber, temos de lhe perguntar, como em 1995.
  • Quando algo avaria, muitas vezes só sabemos quando nos diz. (O Google Play mostra a todos os programadores contagens anónimas de falhas. É o sistema da Google, não algo que tenhamos incorporado, e não vai além disso.)
  • Não lhe podemos enviar e-mails do género «Temos saudades suas!», porque não temos o seu endereço de e-mail. Consideramos isso uma funcionalidade.
  • E temos de cobrar dinheiro a sério, porque nos recusamos a recuperá-lo vendendo-o a si.

Achamos que é uma troca justa. Pode concordar ou não, mas pelo menos sabe exatamente em que consiste a troca.

Três coisas que pode fazer hoje contra a economia dos dados, com qualquer aplicação

Não é preciso ser engenheiro para resistir um pouco:

  1. Pergunte: «Para que é que isto precisa daquilo?» Quando uma aplicação pede uma autorização, pergunte-se se a funcionalidade que quer precisa mesmo dela. Uma lanterna não precisa da sua localização. Uma calculadora não precisa dos seus contactos. Na dúvida, toque em «Não permitir» e veja se a aplicação continua a funcionar. Normalmente, continua.
  2. Consulte a secção «Segurança de dados» na Play Store antes de instalar. Não é perfeita, mas uma longa lista de «dados partilhados com terceiros» diz muito.
  3. Desconfie um pouco do «grátis». Nem todas as aplicações gratuitas o estão a vender, mas alguém paga os servidores e os programadores. Se não é o utilizador, vale a pena perguntar quem é.

A versão curta

Como utilizadores de aplicações, cansámo-nos de ser o produto, por isso decidimos não fazer o mesmo a mais ninguém. As aplicações da EiBPM fazem o seu trabalho, no seu dispositivo, e depois deixam-no em paz. Sem publicidade, sem rastreadores, sem contas, sem um servidor cheio da sua vida.

E, sinceramente, nada disto devia ser especial. Aplicações que respeitam o utilizador deviam ser a norma, e não um nicho para os mais preocupados com a privacidade. O seu ritmo cardíaco, o seu sono, onde esteve esta manhã: isso é a sua vida. Pertence ao seu dispositivo e ao seu controlo, não ao servidor de outra pessoa, à espera do próximo «ups».

Cada aplicação construída com base em princípios como os dez acima devolve-lhe um pouco desse controlo. Adorávamos que todo o setor seguisse o exemplo. Até lá, vamos continuar a construir aplicações que provam que é possível. Os nossos dez princípios estão na página inicial.

Voltar ao blog