Segurança dos dados no Google Play e privacidade na App Store: como preparar as respostas

O endereço de email não é o único dado a procurar

Uma aplicação de formação permite consultar aulas antes de criar conta. Quem gere o negócio olha para o ecrã inicial e conclui que, nessa fase, não há recolha de dados. A conclusão parece natural, mas pode estar errada: o serviço de diagnóstico ou de estatísticas pode já ter recebido informação.

Não é preciso transformar o responsável pelo produto num especialista de redes. É preciso dar-lhe uma forma de fazer perguntas verificáveis à equipa. O problema começa quando o formulário da loja é tratado como uma tarefa administrativa que se resolve com respostas aproximadas.

Vamos usar uma aplicação de formação como exemplo hipotético. Não se trata de um caso de cliente da Appfyl nem de aconselhamento jurídico. O objetivo é chegar à publicação com factos claros e com alguém responsável por os confirmar.

Comece pela lista de serviços que estão realmente ativos

Peça à equipa de desenvolvimento os serviços incluídos na versão que será publicada. A lista deve indicar a função de cada um, as opções ativas e os campos adicionais enviados pelo código da aplicação.

Um SDK é uma biblioteca integrada no produto, por exemplo para notificações ou análise de falhas. Dizer apenas o nome da biblioteca não explica o seu comportamento. Duas aplicações podem utilizar o mesmo fornecedor e enviar informações diferentes.

A documentação Firebase para as declarações nas plataformas Apple ajuda a perceber os produtos do fornecedor. Não inspeciona a sua aplicação. É necessário confrontá-la com a configuração concreta e com os dados que a própria equipa acrescentou.

Verifique também se existem opções alteradas à distância. Uma nova recolha pode começar sem uma atualização visível da aplicação. Por isso, o inventário não deve ficar limitado à versão do ficheiro instalado.

Passe dos nomes técnicos aos percursos do utilizador

Depois da lista de serviços, percorra as tarefas do aluno: ver uma aula, guardar o progresso, receber um lembrete e enviar uma dúvida. Pergunte que informação sai do dispositivo em cada momento, quem a recebe e o que acontece a seguir.

Esta tabela prepara a investigação; não é uma classificação oficial pronta a copiar. Acrescente a versão analisada, a data e a pessoa que confirmou cada resposta. Quando faltar uma informação, assinale a dúvida em vez de a esconder numa frase vaga.

A sessão da Apple sobre a Privacy Nutrition Label tem uma transcrição útil e explica esta abordagem a partir das funcionalidades. Vale a pena lê-la como método de trabalho. As regras atuais devem ser confirmadas na documentação em vigor.

Perceba o que significa estar ligado a uma pessoa

Um identificador que ninguém consegue ler facilmente pode continuar associado a uma conta. Transformar uma referência ou aplicar-lhe uma função de hash não demonstra, por si só, que a informação se tornou anónima.

Pergunte se o sistema consegue juntar esse valor a um aluno, dispositivo ou histórico. No exemplo da formação, o progresso de uma aula pode parecer um simples número. Quando esse número fica ligado à conta que comprou o curso, a relação merece ser analisada.

Não tente resolver esta questão apenas através da aparência do dado. A equipa deve explicar as relações existentes e a finalidade do tratamento. Depois, quem preenche o formulário aplica as definições da plataforma a esses factos.

Responda às duas lojas sem copiar as caixas de seleção

A Apple e a Google organizam as perguntas de maneira diferente. A Apple distingue, entre outros aspetos, dados associados ao utilizador e dados usados para rastreamento. A Google define recolha e partilha com condições e exceções próprias.

O processamento temporário fora do dispositivo é um exemplo importante. O formulário da Google pede que seja avaliado; certas situações podem não aparecer da mesma forma na informação pública quando cumprem as condições indicadas. Não conclua que a ausência de armazenamento permanente elimina a pergunta. Consulte as instruções de Segurança dos dados.

Para a Apple, use as definições de App Privacy. O inventário de base pode ser comum, mas as respostas dependem também das diferenças reais entre as versões para iOS e Android.

Se as declarações tiverem respostas diferentes por uma razão válida, registe essa razão. Uma revisão futura não deve uniformizá-las apenas porque parecem duas versões do mesmo documento.

A política de privacidade não faz o trabalho das permissões

A política de privacidade da aplicação explica as práticas num documento mais amplo. A declaração da loja apresenta informação em categorias próprias. A permissão do sistema permite um acesso específico. A avaliação das obrigações de consentimento é outra parte do trabalho.

Pense num aluno que envia uma fotografia ao apoio. A escolha da imagem no telemóvel não explica quem poderá consultá-la no serviço externo nem durante quanto tempo será conservada.

Estas partes devem ser coerentes, mas não são substitutos umas das outras. Uma frase numa política não torna necessária uma transmissão excessiva. E o formulário da loja não certifica automaticamente o cumprimento de todas as obrigações legais.

Uma opção facultativa tem de funcionar quando é recusada

Teste uma instalação nova antes de qualquer escolha. Repita o percurso depois de recusar uma função opcional e depois de alterar a preferência nos ajustes. Observe o comportamento, não apenas o estado visual do botão.

As operações pendentes merecem atenção. Um envio preparado antes da mudança de preferência pode ter um tratamento diferente de um evento criado depois. A equipa deve definir esse comportamento e conseguir demonstrá-lo.

Use contas de teste e exemplos que não exponham alunos reais. Registe os passos, a versão e o resultado. A utilidade da evidência está em permitir que outra pessoa reproduza a observação, não em guardar grandes quantidades de informação.

Uma gravação de rede curta não cobre tudo. Funções menos usadas, envios adiados e processamento no servidor também podem importar. Os testes de eventos em GA4 e Firebase ajudam numa parte deste percurso, mas não mostram necessariamente todos os usos posteriores.

Retire o que não tem uma finalidade clara

A preparação das declarações é uma oportunidade para simplificar. Se a equipa quer contar aulas terminadas, precisa mesmo de enviar o texto livre de uma mensagem de apoio juntamente com o evento?

A pergunta evita uma reação pouco útil: descobrir um campo desnecessário e preocupar-se apenas com a categoria onde o declarar. Primeiro decida se deve existir. Se não houver uma finalidade justificada, investigue a sua remoção e confirme o comportamento após a alteração.

Também aqui convém separar decisões técnicas e jurídicas. A equipa de produto explica a necessidade; o desenvolvimento explica a implementação; a avaliação adequada determina os requisitos aplicáveis. Nenhuma destas partes deve ter de inventar as respostas das outras.

Entregue um dossier pequeno a quem publica

A pessoa responsável por preencher App Privacy no App Store Connect e Segurança dos dados no Play Console deve receber o inventário confirmado, as configurações relevantes e o endereço atual da política. Deve saber igualmente quem aprova as respostas.

Depois da submissão, reveja a apresentação pública. Um utilizador consegue conciliar o que lê na loja com o que acontece na aplicação? A linguagem das categorias não é igual à de uma política, mas a realidade descrita deve ser a mesma.

Guarde as respostas e a data de revisão com as evidências. Se surgir uma questão, será possível perceber se mudou o produto, a configuração ou a declaração. Para leitura complementar sobre estes formatos, existe um estudo que compara a compreensão das etiquetas Apple e Google; não substitui as regras atuais das lojas.

Corrija a origem de uma discrepância e mantenha o registo

Quando uma revisão aponta uma transferência não declarada, identifique primeiro o serviço e a função envolvidos. Pode faltar informação no formulário, pode existir um comportamento que não deveria acontecer, ou podem verificar-se ambas as situações.

Corrigir a declaração não resolve um envio indevido. Corrigir o código também não dispensa rever o que ficou publicado. Faça as alterações necessárias e volte a testar o percurso afetado.

As afirmações sobre eliminação de conta exigem o mesmo cuidado: devem corresponder a um processo real nos sistemas envolvidos. Não basta uma frase tranquilizadora no final de um documento.

Para as próximas versões, nomeie uma pessoa para rever mudanças em serviços e finalidades. Uma nota curta com «revisto, sem alterações necessárias» já demonstra uma decisão. Se preparar esta fase com a Appfyl, inclua no brief do projeto os serviços conhecidos e as dúvidas por esclarecer. É uma base concreta para trabalhar, não uma promessa de aprovação automática.

Perguntas frequentes