Melhores práticas para identificadores únicos

Este documento fornece orientação para seleccionar identificadores apropriados para o seu pacote com base no seu caso de utilização.

Para uma visão geral das permissões do Android, consulte Permissionsoverview. Para melhores práticas específicas para trabalhar com as permissões do Android, veja Melhores práticas de permissões do aplicativo.

Best practices for working with Android identifiers

Ao trabalhar com identificadores Android, siga estas melhores práticas:

1. Evite usar identificadores de hardware. Na maioria dos casos de uso, você pode evitar usar identificadores de hardware, como o SSAID (Android ID), sem limitar a funcionalidade requerida.

   Android 10 (API nível 29) adiciona restrições para identificadores não reinicializáveis, que incluem tanto IMEI quanto número de série. Seu aplicativo deve ser um dispositivo ou um perfil de proprietário,ter permissões de portadora especiais,ou ter a permissão READ_PRIVILEGED_PHONE_STATE privilegiada para acessar estes identificadores.

2. Apenas use um ID de Publicidade para perfis de usuários ou casos de uso de anúncios. Ao utilizar um ID de Publicidade, respeite sempre as seleções dos usuários em relação ao adtracking. Além disso, certifique-se de que o identificador não possa ser conectado a informações pessoalmente identificáveis (PII), e evite fazer o Bridging Advertising ID resets.

3. Utilizar um Firebase installation ID (FID) ou um GUID privado sempre que possível para todos os outros casos de uso, exceto para prevenção de fraude de pagamento e telefonia. Para a grande maioria dos casos de não uso deads, um FID ou GUID deve ser suficiente.

4. Utilizar APIs que sejam apropriadas para o seu caso de uso para minimizar o privacyrisk. Use o DRM API para proteção de alto conteúdo e o SafetyNet APIs para proteção de abuso. As APIs SafetyNet são a maneira mais fácil de determinar se um dispositivo é genuíno sem incorrer em risco de privacidade.

As seções restantes deste guia elaboram essas regras no contexto do desenvolvimento de aplicativos Android.

Trabalhar com IDs de publicidade

O ID de publicidade é um identificador reinicializável pelo usuário e é apropriado para casos de uso de publicidade. Há alguns pontos-chave a ter em mente, no entanto, quando você usa este ID:

Sempre respeite a intenção do usuário ao redefinir o ID de publicidade. Não faça uma ponte entre o usuário reinicializa usando outro identificador ou impressão digital para links IDs de publicidade subseqüentes, juntamente com o consentimento do usuário. O Google Play Developer ContentPolicy afirma o seguinte:

“…se reinicializado, um novo identificador de publicidade não deve ser conectado a um identificador de publicidade anterior ou dados derivados de um identificador de publicidade anterior sem o consentimento explícito do usuário”

Sempre respeite a bandeira de Anúncios Personalizados associada. Os identificadores publicitários são configuráveis na medida em que os usuários podem limitar a quantidade de rastreamento associado com o identificador. Use sempre o método AdvertisingIdClient.Info.isLimitAdTrackingEnabled() para garantir que você não está contornando os desejos de seus usuários. O GooglePlay Developer ContentPolicy declara o seguinte:

“…você deve respeitar a configuração ‘Opt out of interest-based advertising’ ou ‘Opt out of Ads Personalization’ de um usuário. Se um usuário tiver ativado essa configuração, você não poderá usar o identificador de publicidade para criar perfis de usuários para fins de publicidade prévia ou para direcionar usuários com publicidade personalizada. As atividades permitidas incluem publicidade contextual, limitação de freqüência, rastreamento de conversão, relatórios e detecção de segurança e fraude”

Esteja ciente de quaisquer políticas de privacidade ou segurança associadas aos SDKs que você usa que estejam relacionadas ao uso de IDs de publicidade.Por exemplo, se você passar true para o método enableAdvertisingIdCollection() do SDK do Google Analytics, certifique-se de revisar e aderir ao allapplicable Analytics SDKpolicies.

Além disso, esteja ciente de que o Google Play Developer ContentPolicy requer que o ID de Publicidade “não deve estar conectado a informações pessoalmente identificáveis ou associado a qualquer identificador de dispositivo persistente (por exemplo:SSAID, endereço MAC, IMEI, etc.),).”

Como exemplo, suponha que você queira coletar informações para preencher as tabelas de banco de dados com as seguintes colunas:

Neste exemplo, a coluna ad_id poderia ser unida ao PII através da coluna account_id em ambas as tabelas, o que seria uma violação da Política de Conteúdos para Desenvolvedores de Jogos do Google, se você não obtivesse permissão explícita dos seus usuários.

Cuidado que os links entre o ID do Anunciante e PII nem sempre são tão explícitos. É possível ter “quase-identificadores” que aparecem em ambas as tabelas com teclas PII e Ad ID, o que também causa problemas. Por exemplo, suponha que mudamosTABLE-01 e TABLE-02 como se segue:

Neste caso, com eventos de clique suficientemente raros, ainda é possível aderir entre a TABELA-01 do Anunciante e o PII contido na TABELA-02 usando o timestamp do evento e o modelo do dispositivo.

Embora seja muitas vezes difícil garantir que não existam esses quase-identificadores num conjunto de dados, você pode evitar os riscos mais óbvios de junção generalizando dados únicos sempre que possível. No exemplo anterior, isto significaria reduzir a precisão do timestamp para que vários dispositivos com o mesmo modelo apareçam para cada timestamp.

Outras soluções incluem o seguinte:

• Não desenhar tabelas que liguem explicitamente PII com IDs de Publicidade. No primeiro exemplo acima, isto significaria não incluir a coluna account_id na TABELA-01.

• Segregar e monitorar listas de controle de acesso para usuários ou funções que têm acesso tanto aos dados chaveados do ID de Publicidade quanto aos IDs de Publicidade. Geralmente falando, controlar o acesso significa fazer o seguinte:

  1. Keep access control lists (ACLs) for Advertiser ID keyed data and PIIdisjoint to minimize the number of individuals or roles that are in bothACLs.
  2. Implement access log and audit to detect and manage any exceptionsto this rule.

Para mais informações sobre como trabalhar de forma responsável com IDs de publicidade, veja o AdvertisingIdClient Referência API.

Trabalhar com FIDs e GUIDs

A solução mais direta para identificar uma instância de aplicativo rodando no adevice é usar um ID de instalação do Firebase (FID), e esta é a solução recomendada na maioria dos casos de não uso deads. Apenas a instância de aplicação para a qual foi provisionado pode acessar esse identificador, e é (relativamente) fácil de instalar porque ele só persiste enquanto a aplicação estiver instalada.

Como resultado, os FIDs fornecem melhores propriedades de privacidade em comparação com os IDs de hardware com tomon resetável, com escopo de dispositivo. Para mais informações, veja a referênciafirebase.installationsAPI.

Em casos onde um FID não é prático, você também pode usar IDs (GUIDs) customglobally-unique para identificar uma instância de aplicação de forma única. A maneira mais simples de o fazer é gerar o seu próprio GUID usando o seguinte código:

var uniqueID = UUID.randomUUID().toString()

String uniqueID = UUID.randomUUID().toString();

Porque o identificador é globalmente único, ele pode ser usado para identificar uma instânciaapp específica. Para evitar preocupações relacionadas à ligação do identificador entre aplicativos,armazene GUIDs em armazenamento interno ao invés de armazenamento externo (compartilhado). Para mais informações, consulte a página Data and file storageoverview.

Não trabalhar com endereços MAC

Endereços MAC são globalmente únicos, não reinicializáveis pelo utilizador, e sobrevivem a factoryresets. Por estas razões, para proteger a privacidade do usuário, nas versões 6 e superiores do Android, o acesso aos endereços MAC é restrito aos aplicativos do sistema. Aplicativos de terceiros não podem acessá-los.

MAC address availability changes in Android 11

Em aplicativos com Android 11 e superior, a randomização MAC para Passpointnetworks é por perfil Passpoint, gerando um endereço MAC único com base nos campos seguintes:

• Nome de domínio totalmente qualificado (FQDN)
• Real
• Credencial, baseado na credencial utilizada no perfil Passpoint:
  • Credencial do usuário: nome do usuário
  • Credencial do certificado: cert e tipo de cert
  • Credencial do SIM: Tipo EAP e IMSI

Além disso, aplicações não privilegiadas não podem acessar o endereço MAC do dispositivo; somente interfaces de rede com um endereço IP são visíveis. Isto impacta os métodosgetifaddrs() eNetworkInterface.getHardwareAddress(), assim como o envio de mensagens RTM_GETLINK Netlink.

A seguir está uma lista das formas como os aplicativos são afetados por esta alteração:

• NetworkInterface.getHardwareAddress() retorna nulo para cada interface.
• Os aplicativos não podem usar a função bind() nos soquetes NETLINK_ROUTE.
• O comando ip não retorna informações sobre interfaces.
• As aplicações não podem enviar RTM_GETLINK mensagens.

Nota que a maioria dos desenvolvedores deve usar as APIs de nível superior deConnectivityManager em vez de APIs de nível inferior comoNetworkInterface,getifaddrs(),ou soquetes Netlink. Por exemplo, um aplicativo que precisa de informações atualizadas sobre as rotas atuais pode obter essas informações ouvindo as mudanças na rede usando ConnectivityManager.registerNetworkCallback() e chamando os associados da redeLinkProperties.getRoutes().

Características do identificador

O sistema operacional Android oferece um número de IDs com diferentes características de comportamento. Essas características também vêm com implicações de privacidade, no entanto, é importante entender como essas características interagem com cada outra.

Escopo

Escopo do identificador explica quais sistemas podem acessar o identificador. O escopo do Androididentifier geralmente vem em três sabores:

• Aplicação única: O ID é interno ao aplicativo e não acessível a outros aplicativos.
• Grupo de aplicativos: O ID é acessível a um grupo pré-definido de aplicativos relacionados.
• Dispositivo: O ID é acessível a todos os aplicativos instalados no dispositivo.

Quanto maior o escopo concedido a um identificador, maior o risco de que ele seja utilizado para fins de rastreamento. Por outro lado, se um identificador só pode ser acessado por uma única instância de aplicativo, ele não pode ser usado para rastrear um dispositivo através de transações em diferentes aplicativos.

Restabilidade e persistência

Restabilidade e persistência definem a vida útil do identificador e explicam como ele pode ser redefinido. Os gatilhos comuns de reset incluem: reinicialização em inicialização, reinicialização viaSystem Settings, reinicialização no lançamento e reinicialização na instalação. Os identificadores Androididentifiers podem ter diferentes durações, mas a vida útil está normalmente relacionada com a forma como o ID é reinicializado:

• Somente sessão: Um novo ID é usado toda vez que o usuário reinicia o aplicativo.
• Reinicialização da instalação: Um novo ID é usado toda vez que o usuário desinstala e reinstala o app.
• FDR-reset: Um novo ID é usado toda vez que o usuário reinstala o dispositivo.
• FDR-persistente: O ID sobrevive ao reset de fábrica.

Resettabilidade dá aos usuários a capacidade de criar um novo ID que é desassociado de qualquer informação de perfil existente. Quanto maior, e mais confiável, o anidentificador persistir, tal como um que persiste através de reinicializações de fábrica, maior o risco de que o usuário possa ser submetido a um rastreamento de longo prazo. Se o anidentificador for reinicializado ao reinstalar o aplicativo, isso reduz a persistência e fornece um meio para que o ID seja reinicializado, mesmo que não haja um controle explícito do usuário para reinicializá-lo de dentro do aplicativo ou das Configurações do Sistema.

Uniquidade

Uniquidade estabelece a probabilidade de colisões; ou seja, que os identicalidentifiers existem dentro do escopo associado. No nível mais alto, um identificador globalmente único nunca tem uma colisão, mesmo em outros dispositivos ou aplicações. Caso contrário, o nível de exclusividade depende da entropia do identificador e da fonte de aleatoriedade usada para criá-lo. Por exemplo, a chance de acúmulo é muito maior para identificadores aleatórios semeados com a data de instalação do calendário (como 2019-03-01) do que para identificadores semeados com o Unixtimestamp da instalação (como 1551414181).

Em geral, os identificadores de contas de usuário podem ser considerados únicos. Ou seja, a combinação eachdevice/account tem uma identificação única. Por outro lado, quanto menos único um identificador estiver dentro de uma população, maior é a proteção de privacidade porque é menos útil para rastrear um usuário individual.

Proteção de integridade e não-repúdio

Pode usar um identificador que é difícil de falsificar ou repetir para provar que o dispositivo ou conta associada tem certas propriedades. Por exemplo, você pode provar que o dispositivo não é um dispositivo virtual usado por um spammer. Os identificadores difíceis de usar também fornecem não repudiabilidade. Se os dispositivos assinam uma mensagem com uma chave secreta, é difícil afirmar que o dispositivo de outra pessoa enviou a mensagem. A não-repudibilidade pode ser algo que um usuário deseja, como autenticar um pagamento, ou pode ser uma propriedade indesejável, como quando eles enviam uma mensagem que lamentam.

Casos de uso comum e o identificador apropriado para usar

Esta seção fornece alternativas para usar IDs de hardware, como o IMEI. O uso de IDs de hardware é desencorajado porque o usuário não pode reinicializá-los, e eles são copiados novamente para o dispositivo. Em muitos casos, um identificador com o app-scoped seria suficiente.

Preferências do usuário assinadas pelo track

Neste caso, você está salvando o estado por dispositivo no lado do servidor sem uma conta de usuário.

Utilizar: FID ou GUID

Por que esta recomendação?

Informação per-device através de reinstalações não é recomendada porque os usuários podem querer redefinir suas preferências reinstalando o app.

Track sign-out preferências do usuário entre aplicativos com a mesma chave de assinatura

Neste caso, você está salvando o estado por dispositivo no lado do servidor e transferindo-o entre diferentes aplicativos que estão assinados com a mesma chave no mesmo dispositivo.

Utilizar: SSAID

Porquê esta recomendação?

No Android 8.0 (API nível 26) e superior, o SSAID fornece um identificador que’scommon entre aplicativos assinados pela mesma chave de assinatura do desenvolvedor. Ele permite o estado de toshare entre esses aplicativos sem exigir que o usuário acesse uma conta.

Track sign-out comportamento do usuário

Neste caso, você criou um perfil de um usuário baseado no seu comportamento em diferentes aplicações/sessões no mesmo dispositivo.

Utilizar: ID da publicidade

Porquê esta recomendação?

O uso do ID da publicidade é obrigatório para casos de uso de publicidade por parte do GooglePlay Developer ContentPolicy porque o usuário pode redefini-lo.

Gerar análise de usuários assinados ou anônimos

Neste caso, você está medindo estatísticas de uso e análise para usuários assinados ou anônimos.

Utilizar: FID, ou um GUID se um FID for insuficiente

Por que esta recomendação?

Um FID ou GUID é escopado para o aplicativo que o cria, o que impede que o identificador seja usado para rastrear os usuários entre os aplicativos. Também é fácil de configurar, pois o usuário pode limpar os dados da aplicação ou reinstalar a aplicação. O processo de criação de FIDs e GUIDs é simples:

• Retrieving an FID: Veja o guia de instalações do Firebase.

• Criar um GUID: Implemente a lógica em seu aplicativo, como mostrado no seguinte códigonippet:

  Kotlin

  val uniqueID: String = UUID.randomUUID().toString()

  Java

  String uniqueID = UUID.randomUUID().toString();

Esteja ciente de que se você disse ao usuário que os dados que você está coletando são anônimos, você deve se certificar de que você não está conectando o identificador ao PII ou outros identificadores que possam estar ligados ao PII.

Você também pode usar o Google Analytics para MobileApps, que oferece asolução para análise per-app.

Track sign-out conversões do usuário

Neste caso, você está rastreando conversões para detectar se sua estratégia de marketing é bem sucedida.

Utilizar: ID Publicidade

Por que esta recomendação?

Este é um caso de uso relacionado a anúncios que pode exigir um ID que está disponível em diferentes aplicativos, então usar um ID Publicidade é a solução mais apropriada.

Pega múltiplas instalações em diferentes dispositivos

Neste caso, você precisa identificar a instância correta do aplicativo quando ele é instalado em vários dispositivos para o mesmo usuário.

Utilizar: FID ou GUID

Por que esta recomendação?

Um FID é projetado explicitamente para este fim; seu escopo é limitado aoapp para que ele não possa ser usado para rastrear usuários através de diferentes aplicativos, e é reinstalado ao reinstalar o aplicativo. Nos raros casos em que um FID é insuficiente, você também pode usar um GUID.

Associar funcionalidade com assinaturas de serviços móveis

Neste caso, você precisa associar a funcionalidade do aplicativo a certas assinaturas de serviços móveis no dispositivo. Por exemplo, você pode ter um requisito para toverificar o acesso a certos recursos de aplicativos premium com base nas assinaturas de celular do dispositivo via SIM.

Utilizar: Assinatura IDAPI para identificar SIMs que são usados no dispositivo.

A Assinatura ID fornece um valor de índice (a partir de 1) para identificar exclusivamente SIMs instalados (incluindo físicos e eletrônicos) usados no dispositivo. Através deste ID, a sua aplicação pode associar a sua funcionalidade com informação de subscrição variouss para um determinado SIM. Este valor é estável para um determinado SIM a não ser que o dispositivo seja reinicializado na fábrica. Entretanto, pode haver casos onde o mesmoSIM tem um ID de Assinatura diferente em dispositivos diferentes ou SIMs diferentes têm o mesmo ID em dispositivos diferentes. se o ID de Assinatura não for suficientemente único é recomendado concatenar o ID de Assinatura com SSAID.

Por que esta recomendação?

Algumas aplicações podem estar atualmente usando o ICCID para este propósito. Como a ICC ID é globalmente única e não reiniciável, o acesso foi restrito a aplicativos com a permissão READ_PRIVILEGED_PHONE_STATE desde o Android 10. Começando com o Android 11, o Google restringe ainda mais o acesso ao ICCID através de getIccId()API, independentemente do nível de API do aplicativo alvo. Aplicativos afetados devem migrar o ID da Assinatura em vez disso.

Anti-fraude: Aplicar limites de conteúdo livre e detectar ataques Sybil

Neste caso, você quer limitar o número de conteúdo livre, como artigos, que um usuário pode ver em um dispositivo.

Utilizar: FID ou GUID. No Android 8.0 (nível 26 da API) e superior, o SSAID é também uma opção, pois é escopo para a chave de assinatura do aplicativo.

Por que esta recomendação?

Usar um GUID ou FID força o usuário a reinstalar o aplicativo para contornar os limites de conteúdo, o que é um fardo suficiente para dissuadir a maioria das pessoas. Se isso não for proteção suficiente, o Android fornece um DRMAPI, que pode ser usado para limitar o acesso ao conteúdo, inclui um identificador por-APK, o Widevine ID.

Funcionalidade da operadora

Neste caso, seu aplicativo está interagindo com o telefone do dispositivo e a funcionalidade de mensagens de texto usando uma conta de operadora.

Utilizar: IMEI, IMSI e Line1

Porquê esta recomendação?

Alavancar identificadores de hardware é aceitável se for necessário para a funcionalidade relacionada com a portadora. Por exemplo, você poderia usar esses identificadores para comutar entre operadoras de celular ou slots SIM, ou para entregar mensagens SMS sobre IP (para a Line1) – contas de usuário baseadas em SIM. Para aplicativos sem privilégios, no entanto, recomenda-se usar um login de conta para recuperar informações do dispositivo do usuário no lado do servidor. Uma razão para isso é que, no Android 6.0 (nível 23 da API) andhigher, esses identificadores só podem ser usados através de uma permissão de tempo de execução. Os usuários podem desviar essa permissão, então seu aplicativo deve lidar com essas exceçõesgraciosamente.

Detecção de uso: Identificando bots e ataques DDoS

Neste caso, você está tentando detectar vários dispositivos falsos atacando yourbackend services.

Utilizar: A API SafetyNet API

Por que esta recomendação?

Um identificador isoladamente faz pouco para indicar que um dispositivo é genuíno. Você pode verificar que uma solicitação vem de um dispositivo Android genuíno – como oposto a um anemulador ou outro código falsificador de outro dispositivo – usando a API do SafetyNetattest()método para verificar a integridade de um dispositivo fazendo uma solicitação. Para obter informações mais detalhadas, consulte a documentação API do SafetyNet.

Detecção de fraude e abuso: Detecção de credenciais roubadas de alto valor

Neste caso, você está tentando detectar se um único dispositivo está sendo usado várias vezes com credenciais roubadas de alto valor, como para fazer pagamentos fraudulentos.

Utilizar: Por sua natureza, a prevenção de fraude requer sinais proprietários que podem mudar com o tempo e, portanto, estão fora do escopo deste documento. No entanto, note que os identificadores de hardware, tais como IMEI e IMSI, podem ser facilmente modificados dispositivos onrootados ou emulados, pelo que não são indicadores fiáveis de fraude.

>