Este documento oferece orientações para selecionar identificadores apropriados para seu app com base no caso de uso.
Para ter uma visão geral das permissões do Android, consulte Visão geral das permissões. Para conhecer práticas recomendadas específicas de como trabalhar com permissões do Android, consulte Práticas recomendadas para permissões de apps.
Práticas recomendadas para trabalhar com identificadores do Android
Para proteger a privacidade dos usuários, use o identificador mais restritivo que satisfaçam ao caso de uso do seu app. Especificamente, siga estas práticas recomendadas:
- Escolha identificadores reconfiguráveis pelo usuário sempre que possível. O app pode atingir a maioria dos casos de uso, mesmo quando usa identificadores diferentes de IDs de hardware não reconfiguráveis.
Evite o uso de identificadores de hardware. Na maioria dos casos, você pode evitar usar identificadores de hardware, como o IMEI (Identidade de Equipamento Móvel Internacional), sem limitar a funcionalidade necessária.
O Android 10 (API de nível 29) adiciona restrições para identificadores não redefiníveis, que incluem IMEI e número de série. Seu app precisa ser um dispositivo ou um app do proprietário do perfil, ter permissões especiais para operadoras ou ter a permissão privilegiada
READ_PRIVILEGED_PHONE_STATE
para acessar esses identificadores.Use um código de publicidade apenas se for criar perfis de usuários ou em casos de uso de anúncios. Quando usando um ID de publicidade, sempre respeite o seleções relacionadas rastreamento de anúncios. Se você precisar conectar o identificador de publicidade a informações de identificação pessoal, faça isso apenas com o consentimento explícito do usuário.
Não conecte redefinições do ID de publicidade.
Use um ID de instalação do Firebase (FID, na sigla em inglês) ou um GUID armazenado de forma privada sempre que possível para todos os outros casos de uso, exceto para prevenção de fraude de pagamento e e telefonia. Na grande maioria dos casos de uso que não envolvem anúncios, um FID ou GUID deve ser suficiente.
Use APIs adequadas ao seu caso de uso para minimizar riscos relacionados à privacidade. Usar a API DRM para proteção de conteúdo de alto valor e a APIs Play Integrity para proteção contra abusos. As APIs Play Integrity são a maneira mais fácil de determinar se um dispositivo é genuíno sem incorrer em riscos relacionados à privacidade.
As demais seções deste guia detalham essas regras no contexto do desenvolvimento de apps para Android.
Trabalhar com códigos de publicidade
O código de publicidade é um identificador que pode ser redefinido pelo usuário e é adequado para casos de uso de anúncios, mas você deve ter em mente alguns pontos ao usá-lo:
Sempre respeite a intenção do usuário ao redefinir o código de publicidade. Não associe redefinições de usuário usando outro identificador ou impressão digital para vincular códigos de publicidade subsequentes sem o consentimento do usuário. A Política de conteúdo para desenvolvedores do Google Play afirma o seguinte:
"... Se for redefinido, o novo código de publicidade não poderá ser vinculado a um identificador anterior nem a dados derivados desse código sem o consentimento explícito do usuário."
Sempre respeite o sinalizador de anúncios personalizados associado. Códigos de publicidade são configuráveis de forma que os usuários possam limitar a quantidade de rastreamento associada a eles. Sempre use o método AdvertisingIdClient.Info.isLimitAdTrackingEnabled()
para garantir que você não esteja frustrando a vontade dos usuários. A Política de conteúdo para desenvolvedores do Google Play afirma o seguinte:
"... É preciso respeitar a configuração "Desativar publicidade com base em interesses" ou "Desativar a Personalização de anúncios" do usuário. Se um usuário tiver ativado essa configuração, o código de publicidade não poderá ser usado na criação de perfis de usuários para fins publicitários ou para segmentação de usuários com publicidade personalizada. As atividades permitidas incluem publicidade contextual, limite de frequência, acompanhamento de conversões, geração de relatórios e detecção de fraudes e segurança."
Esteja ciente de todas as políticas de privacidade ou de segurança associadas a SDKs que você usa e que estejam relacionadas ao uso de códigos de publicidade.
Por exemplo, se você transmitir true
para o método enableAdvertisingIdCollection()
do SDK do Google Analytics, leia e cumpra todas as políticas do SDK do Google Analytics aplicáveis.
Além disso, esteja ciente de que a Política de conteúdo para desenvolvedores do Google Play afirma que o código de publicidade "não pode estar vinculado a informações de identificação pessoal nem associado a qualquer identificador de dispositivo em tempo integral (por exemplo, SSAID, endereço MAC, IMEI etc.)"
Por exemplo, suponha que você queira coletar informações para preencher tabelas de bancos de dados com as seguintes colunas:
TABLE-01 | |||
timestamp |
ad_id |
account_id |
clickid |
TABELA-02 | |||
account_id |
name |
dob |
country |
Nesse exemplo, a coluna ad_id
poderia ser associada a PII por meio da coluna account_id
nas duas tabelas, o que seria uma violação da Política de conteúdo para desenvolvedores do Google Play se você não tivesse permissão explícita dos seus usuários.
Lembre-se de que a relação entre um código de publicidade e PII nem sempre é tão explícita. É possível ter "quase identificadores" que aparecem nas tabelas com chaves de ID de anúncios e PII, o que também causa problemas. Por exemplo, suponha que alteremos TABLE-01 e TABLE-02 da seguinte forma:
TABLE-01 | ||||
timestamp |
ad_id |
clickid |
dev_model |
|
TABLE-02 | ||||
timestamp |
demo |
account_id |
dev_model |
name |
Nesse caso, com eventos de cliques suficientemente raros, ainda é possível vincular o código de publicidade de TABLE-01 com as PII contidas em TABLE-02 usando o carimbo de data/hora do evento e o modelo do dispositivo.
Embora geralmente seja difícil garantir que nenhum desses quase identificadores exista em um conjunto de dados, você pode evitar os riscos de associação mais óbvios, generalizando dados exclusivos sempre que possível. No exemplo anterior, isso significaria reduzir a precisão do carimbo de data/hora para que vários dispositivos com o mesmo modelo aparecessem para cada carimbo.
Outras soluções incluem:
Não criar tabelas que vinculem explicitamente PII a códigos de publicidade. No primeiro exemplo acima, isso significa não incluir a coluna
account_id
em TABLE-01.Como segregar e monitorar as listas de controle de acesso para usuários ou funções que têm acesso a dados com chave de códigos de publicidade e PII. Ao controlar e auditar de forma rigorosa a capacidade de acessar as duas fontes simultaneamente (por exemplo, mesclando as tabelas), você reduz o risco de associação entre o código de publicidade e as PII. De um modo geral, controlar o acesso significa:
- manter listas de controle de acesso (ACLs, na sigla em inglês) para dados com chave de código de publicidade e PII desvinculadas para minimizar o número de indivíduos ou funções em ambas as ACLs;
- implementar o registro e a auditoria do acesso para detectar e gerenciar quaisquer exceções a essa regra.
Para ver mais informações sobre como trabalhar de forma responsável com os códigos de publicidade, consulte a referência da API AdvertisingIdClient
.
Trabalhar com FIDs e GUIDs
A solução mais simples para identificar uma instância de aplicativo em execução em um dispositivo é usar um ID de instalação do Firebase (FID, na sigla em inglês), e essa é a configuração na maioria dos casos de uso que não são anúncios. Somente a instância do app para a qual ele foi provisionado pode acessar esse identificador, e é (relativamente) fácil redefini-lo, porque ele persiste apenas enquanto o app está instalado.
Consequentemente, os FIDs oferecem propriedades de privacidade melhores em comparação com
IDs de hardware no escopo do dispositivo que não podem ser redefinidos. Para mais informações, consulte a
referência da API
firebase.installations
.
Nos casos em que um FID não é prático, você também pode usar uma personalização IDs globalmente exclusivos (GUIDs) para identificar de forma exclusiva uma instância de app. A maneira mais fácil de fazer isso é gerar o próprio GUID usando o código a seguir:
Kotlin
var uniqueID = UUID.randomUUID().toString()
Java
String uniqueID = UUID.randomUUID().toString();
Como esse identificador é globalmente exclusivo, ele pode ser usado para identificar uma instância de app específica. Para evitar preocupações relacionadas à vinculação do identificador entre os apps, salve os GUIDs em um armazenamento interno em vez de externo (compartilhado). Para ver mais informações, consulte a página Visão geral do armazenamento de dados e arquivos.
Não trabalhar com endereços MAC
Os endereços MAC são globalmente exclusivos, não podem ser redefinidos pelo usuário e persistem após uma redefinição para a configuração original. Por esses motivos, para proteger a privacidade do usuário, no Android 6 e versões mais recentes, o acesso a endereços MAC é restrito aos aplicativos do sistema. Apps de terceiros não podem acessá-los.
Mudanças na disponibilidade de endereços MAC no Android 11
Em apps direcionados ao Android 11 e mais recentes, a ordem aleatória de MAC para redes Passpoint é por perfil, gerando um endereço MAC exclusivo com base nos seguintes campos:
- Nome de domínio totalmente qualificado (FQDN)
- Reino
- Credencial, com base na credencial usada no perfil do Passpoint:
- Credencial do usuário: nome do usuário
- Credencial de certificado: certificado e tipo de certificado
- Credencial do SIM: tipo de EAP e IMSI
Além disso, os apps sem privilégios não podem acessar o endereço MAC do dispositivo. Somente
as interfaces de rede com um endereço IP ficam visíveis. Isso afeta os métodos
getifaddrs()
e
NetworkInterface.getHardwareAddress()
,
bem como o envio de mensagens Netlink RTM_GETLINK
.
Veja a seguir uma lista das maneiras que os apps são afetados por essa mudança:
NetworkInterface.getHardwareAddress()
retorna "null" (nulo) para cada interface.- Os apps não podem usar a função
bind()
em soquetesNETLINK_ROUTE
. - O comando
ip
não retorna informações sobre interfaces. - Os apps não podem enviar mensagens
RTM_GETLINK
.
A maioria dos desenvolvedores deve usar as APIs de nível superior
ConnectivityManager
em vez de
APIs de nível inferior, como
NetworkInterface
,
getifaddrs()
,
ou soquetes Netlink. Por exemplo, um app que precisa de informações atualizadas sobre as
rotas atuais pode receber essas informações detectando mudanças de rede usando ConnectivityManager.registerNetworkCallback()
e chamando a LinkProperties.getRoutes()
associada à rede.
Características do identificador
O SO Android oferece vários códigos com diferentes características de comportamento. O ID a ser usado depende de como as características a seguir funcionam com seu caso de uso. Essas características também trazem implicações de privacidade. Por isso é importante entender como essas características interagem umas com as outras.
Escopo
O escopo do identificador explica quais sistemas podem acessá-lo, e o do Android geralmente é dividido em três tipos:
- App único: o ID é interno ao app e não pode ser acessado por outros apps.
- Grupo de apps: o código pode ser acessado por um grupo predefinido de apps relacionados.
- Dispositivo: o ID pode ser acessado por todos os apps instalados no dispositivo.
Quanto mais amplo for o escopo concedido a um identificador, maior será o risco de ele ser usado para fins de rastreamento. Por outro lado, se um identificador só puder ser acessado por uma única instância de app, ele não poderá ser usado para rastrear um dispositivo em transações entre diferentes apps.
Capacidade de redefinição e persistência
A capacidade de redefinição e a persistência definem a duração da vida útil do identificador e explicam como ele pode ser redefinido. Acionadores de redefinição comuns incluem os seguintes tipos de redefinição: no app, por meio das configurações do sistema, durante a inicialização e durante a instalação. Os identificadores do Android podem ter durações variadas de vida útil, mas elas geralmente são relacionadas ao modo como o ID é redefinido:
- Somente sessão: um novo ID é usado sempre que o usuário reinicia o app.
- Redefinição na instalação: um novo ID é usado sempre que o usuário desinstala e reinstala o app.
- Redefinição para a configuração original: um novo ID é usado sempre que o usuário redefine o dispositivo para configuração original.
- Persistente à redefinição para a configuração original: o ID persiste após a redefinição para a configuração original.
A capacidade de redefinição dá aos usuários a capacidade de criar um novo ID que não esteja associado a informações de perfis existentes. Quanto mais longa e confiável for a persistência do identificador (por exemplo, um identificador que persiste após redefinições para a configuração original), maior será o risco de o usuário ser submetido a um rastreamento de longo prazo. Se o identificador for redefinido após a reinstalação do app, isso reduzirá a persistência e fornecerá uma forma de redefinir o ID, mesmo que o usuário não controle explicitamente essa redefinição pelo app ou pelas configurações do sistema.
Exclusividade
A exclusividade estabelece a probabilidade de colisões, isto é, a possibilidade de existirem identificadores idênticos no escopo associado. No nível mais alto, um identificador globalmente exclusivo nunca tem uma colisão, mesmo em outros dispositivos ou apps.
Caso contrário, o nível de exclusividade dependerá da entropia do identificador e da fonte de aleatoriedade usada para criá-lo. Por exemplo, a chance de uma colisão é muito maior para identificadores aleatórios sugeridos com a data de instalação do calendário (como 2019-03-01
) do que para identificadores sugeridos com o carimbo de data/hora Unix da instalação (como 1551414181
).
Em geral, identificadores de contas de usuário podem ser considerados exclusivos. Ou seja, cada combinação de dispositivo/conta tem um ID exclusivo. Por outro lado, quanto menos exclusivo for um identificador em uma população, maior será a proteção de privacidade, porque é menos útil para rastrear um usuário individual.
Proteção de integridade e não repudiabilidade
Você pode usar um identificador difícil de falsificar ou repetir para provar que o dispositivo ou a conta associados têm determinadas propriedades. Por exemplo, você pode provar que o dispositivo não é um dispositivo virtual usado por um criador de spams. Identificadores difíceis de falsificar também proporcionam a não repudiabilidade. Se o dispositivo assinar uma mensagem com uma chave secreta, será difícil afirmar que o dispositivo de outra pessoa enviou a mensagem. Não repudiabilidade pode ser algo que um usuário quer, por exemplo, ao autenticar um pagamento, ou uma propriedade indesejável, por exemplo, quando ele envia uma mensagem da qual se arrepende.
Casos de uso comuns e o identificador adequado a usar
Esta seção fornece alternativas para o uso de IDs de hardware, como IMEI. O uso de IDs de hardware não é recomendado, uma vez que o usuário não pode redefini-los, e eles estão no escopo do dispositivo. Em muitos casos, um identificador com escopo no app seria suficiente.
Contas
Status da operadora
Nesse caso, o app interage com a funcionalidade de smartphone e mensagens de texto do dispositivo usando a conta de uma operadora.
Identificador recomendado para uso:IMEI, IMSI e Line1
Por que essa recomendação?
O uso de identificadores de hardware é aceitável quando ele é necessário para funcionalidades relacionadas à operadora. Por exemplo, você poderia usar esses identificadores para alternar entre operadoras da rede celular ou slots do chip, ou para enviar mensagens SMS do computador (Line1) para contas de usuário baseadas em chip. Para apps sem privilégios, no entanto, recomendamos o uso de login da conta para recuperar informações do dispositivo do usuário no lado do servidor. Um dos motivos para isso é que, no Android 6.0 (API nível 23) e versões mais recentes, esses identificadores só podem ser usados por meio de uma permissão no tempo de execução. Como os usuários podem desativar essa permissão, seu app precisa lidar com essas exceções de forma apropriada.
Status da assinatura para dispositivos móveis
Nesse caso, você precisa associar a funcionalidade do app a determinados de assinaturas de serviço no dispositivo. Por exemplo, talvez você tenha o requisito de verificar o acesso a determinados recursos premium de apps com base no dispositivo móvel assinaturas pelo chip.
Identificador recomendado para uso: ID da assinatura API para identificar chips usados no dispositivo.
O ID da assinatura fornece um valor de índice (começando em 1) para identificar exclusivamente chips instalados (incluindo físicos e eletrônicos) usados no dispositivo. Com esse ID, o app pode associar a funcionalidade a várias informações de assinatura de um determinado SIM. Este valor é estável para um determinado chip. a menos que o dispositivo seja redefinido para a configuração original. No entanto, pode haver casos em que o mesmo O chip tem um ID de assinatura diferente em dispositivos diferentes ou outros chips têm o mesmo ID em dispositivos diferentes.
Por que essa recomendação?
Alguns apps podem estar usando o ID
ICC para essa
finalidade. Como o ID ICC é globalmente exclusivo e não pode ser redefinido, o acesso
foi restrita a apps com o READ_PRIVILEGED_PHONE_STATE
desde o Android 10. A partir do Android 11, o Android
restringiu ainda mais o acesso ao ICCID pela
API getIccId()
,
independente do nível da API de destino do app. Os apps afetados precisam migrar para
usar o ID da assinatura.
Logon único
Nesse caso, o app oferece uma experiência de logon único, permitindo que os usuários associem uma conta à sua organização.
Identificador recomendado para uso: contas compatíveis com o gerente de contas, como Vinculação da Conta do Google
Por que essa recomendação?
A vinculação de Contas do Google permite que os usuários associem uma Conta do Google existente a um app, oferecendo acesso simples e mais seguro aos produtos e serviços da organização. Além disso, é possível definir escopos personalizados do OAuth para compartilhar apenas os dados necessários, aumentando a confiança do usuário ao definir claramente como os dados são usados.
Anúncios
Segmentação
Nesse caso, o app cria um perfil dos interesses do usuário para mostrar a ele mais relevantes.
Identificador recomendado para uso: se o app usa um ID para anúncios e faz o upload ou a publicação no Google Play, esse ID precisa ser o ID de publicidade.
Por que essa recomendação?
Esse é um caso de uso relacionado a anúncios, o que pode exigir um ID disponível em diferentes apps da sua organização. Portanto, o uso de um ID de publicidade é a solução mais adequada. O uso do ID de publicidade é obrigatório para casos de uso de publicidade de acordo com a Política de conteúdo para desenvolvedores do Google Play, porque o usuário pode redefini-lo.
Se você coletar e usar dados do usuário no app para fins de publicidade, declare os fins de publicidade na seção "Segurança dos dados" da página Conteúdo do app no Play Console.
Avaliação
Nesse caso, o app cria um perfil de um usuário com base no comportamento dele nos apps da organização no mesmo dispositivo.
Identificador recomendado para uso: ID de publicidade ou APIs de referenciador de instalação do Google Play
Por que essa recomendação?
Este é um caso de uso relacionado a anúncios que pode exigir um ID disponível nos diferentes apps da organização. Portanto, o uso de um ID de publicidade solução mais apropriada. Se você usar um ID para casos de uso de publicidade, precisa ser o código de publicidade, porque o usuário pode redefini-lo. Saiba mais na Política de conteúdo para desenvolvedores do Google Play.
Conversões
Nesse caso, você está rastreando conversões para detectar se sua estratégia de marketing é bem-sucedida.
Identificador recomendado para uso: ID de publicidade ou APIs de referrer de instalação do Google Play
Por que essa recomendação?
Esse é um caso de uso relacionado a anúncios, o que pode exigir um ID disponível em diferentes apps da sua organização. Portanto, o uso de um ID de publicidade é a solução mais adequada. O uso do ID de publicidade é obrigatório para casos de uso de publicidade on-line, de acordo Política de conteúdo para desenvolvedores do Google Play, porque o usuário pode redefini-la.
Remarketing
Nesse caso, o app mostra anúncios com base nos interesses anteriores de um usuário.
Identificador recomendado para uso: ID de publicidade
Por que essa recomendação?
Esse é um caso de uso relacionado a anúncios, o que pode exigir um ID disponível em diferentes apps da sua organização. Portanto, o uso de um ID de publicidade é a solução mais adequada. O uso do ID de publicidade é obrigatório para casos de uso de publicidade on-line, de acordo Política de conteúdo para desenvolvedores do Google Play, porque o usuário pode redefini-la.
Análise de aplicativos
Nesse caso, o app avalia o comportamento de um usuário para ajudar a determinar o seguinte:
- Quais dos outros produtos ou apps da sua organização podem ser adequados para as usuário.
- Como manter o interesse dos usuários no seu app.
- Meça as estatísticas de uso e análises de usuários anônimos ou desconectados.
Possíveis soluções incluem:
- ID do conjunto de apps:um ID do conjunto de apps permite analisar o comportamento de um usuário em vários apps da sua organização, contanto que você não use dados do usuário para fins de publicidade. Se você segmentar dispositivos com a tecnologia do Google Play serviços, recomendamos o uso do ID do conjunto de apps.
- ID do Firebase (FID, na sigla em inglês): um FID tem como escopo o app que o cria, que impede que o identificador seja usado para rastrear usuários em vários apps. Também é podem ser redefinidos facilmente, já que o usuário pode limpar os dados ou reinstalar o app. O o processo de criação de um FID é simples. confira as instalações do Firebase guia.
Desenvolvimento de apps
Relatórios de erros
Nesse caso, o app coleta dados sobre quando e por que falha em uma dispositivos do usuário.
Identificador recomendado para uso: FID ou ID do conjunto de apps
Por que essa recomendação?
O escopo de um FID é o app que o cria, o que impede que o identificador seja usado para rastrear usuários em diferentes apps. Ele também é fácil de redefinir, já que o usuário pode limpar os dados do app ou reinstalá-lo. O processo de criação de um FID é simples. Consulte o guia de instalações do Firebase. Um ID do conjunto de apps permite analisar o comportamento de um usuário em vários apps que da sua organização, contanto que você não use dados do usuário para publicidade propósitos.
Relatórios de desempenho
Nesse caso, o app coleta métricas de desempenho, como tempos de carregamento e uso da bateria, para ajudar a melhorar a qualidade dele.
Identificador recomendado para uso: Monitoramento de desempenho do Firebase
Por que essa recomendação?
O Monitoramento de desempenho do Firebase ajuda você a se concentrar nas métricas mais importantes para você e para testar o impacto de uma mudança recente em seu aplicativo.
Testes de apps
Nesse caso, o app avalia a experiência do usuário com o app para fins de teste ou depuração.
Identificador recomendado para usar:FID ou ID do conjunto de apps
Por que essa recomendação?
O escopo de um FID é o app que o cria, o que impede que o identificador seja usado para rastrear usuários em diferentes apps. Ele também é fácil de redefinir, já que o usuário pode limpar os dados do app ou reinstalá-lo. O processo de criação de um FID é simples. Consulte o guia de instalações do Firebase. Um ID do conjunto de apps permite analisar o comportamento de um usuário em vários apps que da sua organização, contanto que você não use dados do usuário para publicidade propósitos.
Instalação em vários dispositivos
Nesse caso, o app precisa identificar a instância correta dele ao é instalado em vários dispositivos do mesmo usuário.
Identificador recomendado para uso: FID ou GUID
Por que essa recomendação?
Um FID foi criado explicitamente para esse fim. O escopo dele é limitado ao app, portanto, ele não pode ser usado para rastrear usuários em diferentes apps e é redefinido quando o app é reinstalado. Nos raros casos em que um FID é insuficiente, você também pode usar um GUID.
Segurança
Detecção de abuso
Nesse caso, você está tentando detectar vários dispositivos falsos que estão atacando seus serviços de back-end.
Identificador recomendado para uso:o token de integridade da API Google Play Integrity
Por que essa recomendação?
Para verificar se uma solicitação foi enviada por um dispositivo Android genuíno, em vez de um emulador ou outro dispositivo de falsificação de código, use a API Google Play Integrity.
Fraude de anúncio
Nesse caso, o app verifica se as impressões e ações de um usuário no app são genuínas e verificáveis.
Identificador recomendado para uso: ID de publicidade
Por que essa recomendação?
O uso do ID de publicidade é obrigatório para casos de uso de publicidade, de acordo com a Política de conteúdo para desenvolvedores do Google Play, porque o usuário pode redefini-la.
Gerenciamento de direitos digitais (DRM)
Nesse caso, o app quer proteger o acesso fraudulento à propriedade intelectual ou ao conteúdo pago.
Identificador recomendado:usar um FID ou GUID força o usuário a reinstalar o aplicativo para contornar os limites de conteúdo, que é uma carga suficiente para deter a maioria das pessoas. Se essa proteção não for suficiente, O Android fornece uma API DRM, que pode ser usado para limitar o acesso ao conteúdo, inclui um identificador por APK, o ID do Widevine.
Preferências do usuário
Nesse caso, o app salva o estado do usuário por dispositivo no app, especialmente para usuários que não estão conectados. É possível transferir este estado para outro app assinado com a mesma chave no mesmo dispositivo.
Identificador recomendado:FID ou GUID
Por que essa recomendação?
A persistência de informações após reinstalações não é recomendada, porque os usuários podem querer redefinir as preferências reinstalando o app.