Resumo

  • Matcha aproxima a criação de rótulos de privacidade do código e dos SDKs que moldam as práticas de dados, mas deixa com os desenvolvedores a interpretação das sugestões.
  • Em um estudo, a maioria de 12 participantes produziu rótulos mais precisos; a ferramenta demorou mais que o formulário da loja e não certifica a exatidão em escala de plataforma.

As informações de privacidade ficam ao lado do botão de download, enquanto o trabalho para produzi-las costuma ocorrer em um formulário separado do ambiente de desenvolvimento. Essa distância importa. O formulário pede que alguém classifique o que o aplicativo coleta, compartilha e utiliza; as evidências podem estar espalhadas pelo código próprio, por bibliotecas de terceiros, pela configuração e pelo servidor. A equipe pode conhecer a finalidade do aplicativo sem saber exatamente o que uma dependência faz.

Apple e Google adotaram sistemas diferentes. As respostas de App Privacy da Apple são feitas por aplicativo, incluem as práticas de parceiros terceirizados e devem ser atualizadas quando essas práticas mudam. A seção Data safety do Google Play é uma declaração global por pacote, que abrange versões ainda distribuídas e as práticas relevantes dos SDKs. O Google diz que apenas os desenvolvedores têm as informações necessárias para fazer declarações completas e corretas; a revisão da loja não foi concebida para verificar essa precisão. As taxonomias e os processos não são intercambiáveis. (Apple; Google Play)

Levar a evidência para perto do código

Lorrie Cranor atua na interseção entre engenharia de privacidade, políticas públicas e segurança utilizável. O laboratório CUPS, da Carnegie Mellon, informa que Patrick Gage Kelley liderou a equipe de design do rótulo nutricional de privacidade e que Cranor integrou o grupo. O objetivo era tornar as práticas mais fáceis de entender e comparar; não se trata de uma criação individual de Cranor. (CUPS da CMU; perfil na CMU)

Um artigo de 2024 assinado por Cranor, Tianshi Li, Yuvraj Agarwal e Jason Hong apresenta o Matcha, um plug-in do Android Studio para rótulos do Google Play. Ele procura sinais no código próprio por meio de chamadas de API e palavras-chave, ajuda a anotar acesso e transmissão de dados e usa um arquivo XML editável para registrar práticas de SDKs terceirizados. Ao final, gera um CSV que pode ser importado no Play Console. A decisão central é mostrar as pistas no ambiente em que o desenvolvedor já inspeciona o código, para que possa revisar, corrigir ou rejeitar cada sugestão. (Artigo do Matcha; versão aberta; página do projeto)

Mais precisão custa tempo

No estudo, 12 desenvolvedores criaram rótulos para seus próprios aplicativos; 11 obtiveram maior precisão com o Matcha do que com o formulário do Play Console. Os participantes trabalharam com seis apps do Google Play. A tarefa levou em média 30 minutos com o Matcha, contra 9,8 minutos com o console. É uma troca relevante: naquele estudo, um fluxo mais fundamentado consumiu cerca de três vezes mais tempo.

O resultado sustenta uma proposta de fluxo de trabalho, não uma promessa de precisão universal. Os autores observam que fazer a tarefa do console primeiro pode ter ajudado na segunda, que a referência para identificar erros era incompleta e que os resultados talvez não se apliquem a grandes equipes. A análise de código também não determina toda retenção ou uso posterior no servidor depois que os dados deixam o dispositivo. O desenvolvedor ainda precisa fornecer contexto e revisar a saída.

O rótulo da loja espelha, portanto, o que suas regras supõem que o desenvolvedor sabe. O Matcha tenta tornar essa expectativa viável ao ligar pistas de código e SDK à declaração. Ele não transforma a declaração em auditoria. Seu valor duradouro é criar um ponto em que a incerteza e a divergência possam aparecer e ser corrigidas antes de chegar à página pública.