Práticas recomendadas para identificadores exclusivos

Este documento oferece orientações para selecionar identificadores apropriados para seu aplicativo com base em seu caso de uso.

Para ter uma visão geral das permissões do Android, consulte Visão geral de 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

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

1: Evite o uso de identificadores de hardware. Na maioria dos casos, você pode evitar o uso de identificadores de hardware, como SSAID (Android ID) e IMEI, sem limitar a funcionalidade necessária.

2: Use um código de publicidade apenas se for criar perfis de usuários ou em casos de uso de anúncios. Ao usar um código de publicidade, sempre respeite as escolhas dos usuários em relação ao rastreamento de anúncios. Além disso, certifique-se de que o identificador não possa ser conectado a informações de identificação pessoal (PII, na sigla em inglês) e evite transmitir redefinições do código de publicidade.

3: Use um código de instância ou um GUID armazenado de forma privada sempre que possível para todos os demais casos de uso, exceto prevenção de fraude de pagamento e telefonia. Para a grande maioria dos casos de uso que não incluem anúncios, um código de instância ou GUID deve bastar.

4: Use APIs adequadas ao seu caso de uso para minimizar riscos relacionados à privacidade. Use a API DRM para proteção de conteúdo de alto valor e as APIs SafetyNet para proteção contra abuso. As APIs SafetyNet são a maneira mais fácil de determinar se um dispositivo é verdadeiro sem incorrer em riscos relacionados à privacidade.

As demais seções deste guia detalham essas regras no contexto do desenvolvimento de apps Android.

Identificadores no Android 8.0 e versões posteriores

Os endereços MAC são globalmente exclusivos, não podem ser redefinidos pelo usuário e persistem após uma redefinição de fábrica. Por esses motivos, geralmente não é recomendado usar um endereço MAC para nenhuma forma de identificação do usuário. No Android 6.0 (API nível 23) e em versões posteriores, os endereços MAC de dispositivos locais, como Wi-Fi e Bluetooth, não estão disponíveis por meio de APIs de terceiros. O método WifiInfo.getMacAddress() e o método BluetoothAdapter.getDefaultAdapter().getAddress() retornam 02:00:00:00:00:00.

Além disso, você precisa ter as seguintes permissões para acessar os endereços MAC de dispositivos externos próximos disponíveis por meio de verificações de Bluetooth e Wi-Fi:

Método/propriedade Permissões necessárias
WifiManager.getScanResults() ACCESS_FINE_LOCATION ou ACCESS_COARSE_LOCATION
BluetoothDevice.ACTION_FOUND ACCESS_FINE_LOCATION ou ACCESS_COARSE_LOCATION
BluetoothLeScanner.startScan(ScanCallback) ACCESS_FINE_LOCATION ou ACCESS_COARSE_LOCATION

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 de redefinir o código de publicidade. Não associe redefinições de usuários usando outro identificador ou impressão digital para vincular códigos de publicidade subsequentes sem o consentimento do usuário. A Política do 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. Os códigos de publicidade são configuráveis, porque os usuários podem limitar o nível de rastreamento associado ao código. Sempre use o método AdvertisingIdClient.Info.isLimitAdTrackingEnabled() para garantir que você não esteja contornando a vontade dos seus 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ódigo de publicidade. Por exemplo, se você passar true para o método enableAdvertisingIdCollection() a partir do SDK do Google Analytics, leia e cumpra todas as políticas do SDK do 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 pessoais de identificação 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:

TABELA-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 em ambas as tabelas, o que seria uma violação da Política de conteúdo para desenvolvedores do Google Play, se você não obtivesse 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úncio e PII, o que também causa problemas. Por exemplo, suponha que alteremos a TABELA-01 e a TABELA-02 da seguinte forma:

TABELA-01
timestamp ad_id clickid dev_model
TABELA-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 da TABELA-01 com as PII contidas na TABELA-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 significaria não incluir a coluna account_id na TABELA-01.

  • 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 rigorosamente 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:

    1. 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;
    2. 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 códigos de publicidade, consulte o artigo Código de publicidade da Central de Ajuda.

Trabalhar com códigos de instância e GUIDs

A solução mais simples para identificar a instância de um app executado em um dispositivo é usar um código de instância. Essa é a solução recomendada na maioria dos casos de uso que não incluem anúncios. Somente a instância do app para o qual ele foi fornecido pode acessar esse identificador, e é (relativamente) fácil redefini-lo, porque ele persiste apenas enquanto o app está instalado.

Consequentemente, códigos de instância têm propriedades de privacidade melhores em comparação a códigos de hardware com escopo no dispositivo, que não podem ser redefinidos. Para mais informações, consulte o guia que responde à pergunta: O que é código de instância?

Nos casos em que um código de instância não é viável, você também pode usar códigos personalizados globalmente exclusivos (GUIDs) para identificar de maneira 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 Opções de armazenamento.

Características do identificador

O SO Android oferece vários códigos com diferentes características de comportamento. O código 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 código é 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 código 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. Os 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 código é redefinido:

  • Somente sessão: um novo código é usado sempre que o usuário reinicia o app.
  • Instalação-redefinição: um novo código é usado sempre que o usuário desinstala e reinstala o app.
  • Redefinição FDR: um novo código é usado sempre que o usuário redefine o dispositivo para configuração original.
  • Persistente à FDR: o código persiste após a redefinição para configuração original.

A capacidade de redefinição dá aos usuários a capacidade de criar um novo código 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 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 código, 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 código exclusivo. Por outro lado, quanto menos exclusivo for um identificador em uma população, maior será a proteção de privacidade, porque ele é 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, como ao autenticar um pagamento, ou uma propriedade indesejável, como quando ele envia uma mensagem da qual se arrepende.

Casos de uso comuns e o identificador adequado a usar

Esta seção fornece alternativas ao uso de códigos de hardware, como IMEI. O uso de códigos 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.

Rastrear as preferências de usuários desconectados

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

Use: código de instância 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.

Rastrear as preferências de usuários desconectados entre apps com a mesma chave de assinatura

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

Use: SSAID

Por que essa recomendação?

No Android 8.0 (API nível 26) e versões posteriores, o SSAID fornece um identificador comum entre apps assinados pela mesma chave de desenvolvedor. Ele permite que você compartilhe o estado entre esses apps, sem exigir que o usuário faça login em uma conta.

Rastrear o comportamento de usuários desconectados

Nesse caso, você criou um perfil de um usuário com base no comportamento dele em diferentes apps/sessões no mesmo dispositivo.

Use: código de publicidade

Por que essa recomendação?

O uso do código 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.

Gerar análises de usuários desconectados ou anônimos

Nesse caso, você está medindo estatísticas de uso e análises de usuários desconectados ou anônimos.

Use: código de instância ou um GUID, se um código de instância for insuficiente

Por que essa recomendação?

O escopo de um código de instância ou de um GUID é o app que o cria, o que impede que o identificador seja usado para rastrear usuários em diferentes apps. Além disso, é fácil redefinir esse tipo de código, porque o usuário pode limpar os dados ou reinstalar o app. O processo de criação de códigos de instância e GUIDs é simples:

  • Criação de um código de instância:

    Kotlin

        val iid: String = InstanceID.getInstance(context).id
        

    Java

        String iid = InstanceID.getInstance(context).getId();
        

  • Criação de um GUID:

    Kotlin

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

    Java

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

Se você informou o usuário que os dados coletados são anônimos, não conecte o identificador a PII ou a outros identificadores que possam estar vinculados a PII.

Você também pode usar o Google Analytics para apps para dispositivos móveis, que oferece uma solução de análise por app.

Rastrear conversões de usuários desconectados

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

Use: código de publicidade

Por que essa recomendação?

Esse é um caso de uso relacionado a anúncios, o que pode exigir um código disponível em diferentes apps. Portanto, o uso de um código de publicidade é a solução mais adequada.

Lidar com várias instalações em diferentes dispositivos

Nesse caso, você precisa identificar a instância correta do app quando ele está instalado em vários dispositivos do mesmo usuário.

Use: código de instância ou GUID

Por que essa recomendação?

O código de instância foi criado explicitamente para esse fim. O escopo desse tipo de código é limitado ao app e, por isso, 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 código de instância é insuficiente, você pode usar um GUID.

Antifraude: aplicar limites de conteúdo gratuito e detectar ataques Sybil

Nesse caso, você quer limitar a quantidade de conteúdo gratuito, por exemplo, artigos, que o usuário pode ver em um dispositivo.

Use: código de instância ou GUID. No Android 8.0 (API nível 26) e versões posteriores, o SSAID também é uma opção, porque tem como escopo a chave de assinatura do app.

Por que essa recomendação?

O uso de um GUID ou código de instância força o usuário a reinstalar o app para contornar os limites de conteúdo, o que é um empecilho suficiente para a maioria das pessoas. Se essa proteção não for suficiente, o Android fornecerá uma API DRM, que pode ser usada para limitar o acesso ao conteúdo e inclui um identificador por APK, o código Widevine.

Funcionalidade da operadora

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

Use: 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 posteriores, esses identificadores só podem ser usados por meio de uma permissão de tempo de execução. Como os usuários podem desativar essa permissão, seu app precisa lidar com essas exceções de forma apropriada.

Detecção de abuso: identificar bots e ataques DDoS

Nesse caso, você está tentando detectar vários dispositivos falsos que estão atacando seus serviços de back-end.

Use: API SafetyNet

Por que essa recomendação?

Um identificador isolado não ajuda a saber se um dispositivo é verdadeiro. Você pode verificar se uma solicitação vem de um dispositivo Android verdadeiro (e não de um emulador ou de outro código que falsifica um dispositivo) usando o método SafetyNet.SafetyNetApi.attest(mGoogleApiClient, nonce) da API SafetyNet para verificar a integridade de dispositivos que fazem solicitações. Para ver informações mais detalhadas, consulte a documentação da API SafetyNet.

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

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

Use: por natureza, a prevenção contra fraudes exige sinais específicos que podem mudar com o tempo e, portanto, estão fora do escopo deste documento. No entanto, os identificadores de hardware, como IMEI e IMSI, podem ser facilmente modificados em dispositivos com acesso root ou emulados e, portanto, não são indicadores confiáveis de fraude.