Como implementar device fingerprint no front sem quebrar a experiência

Device fingerprint no front é um script que coleta atributos do aparelho, gera um identificador e envia esse sinal junto com o evento de decisão. Ele roda de forma assíncrona e não bloqueia a renderização da página.

Quem implementa pela primeira vez erra em dois extremos. De um lado, coleta tudo o que a plataforma expõe e acaba com um inventário de dado pessoal sem finalidade. De outro, coleta quase nada por receio jurídico e produz um sinal que não separa caso nenhum.

O caminho útil tem nome: coleta proporcional à finalidade. Você coleta o que serve para decidir sobre risco, escreve por que cada atributo serve e descarta o resto. É exigência da Lei 13.709/2018 e boa engenharia.

Onde o script entra no fluxo

O script precisa estar presente antes do evento que você quer proteger. Os pontos usuais são quatro: cadastro, login, alteração de dado sensível da conta e operação de valor. Em marketplace, some criação de anúncio e troca de conta de recebimento. Em telecom, portabilidade e troca de titularidade.

A ordem importa. Carregue o script de forma assíncrona junto com a página, deixe a coleta acontecer enquanto o usuário preenche o formulário e leia o resultado no envio. Assim a coleta usa o tempo que já existe e não acrescenta espera. A regra que evita a maior parte dos problemas: nenhum passo da coleta pode estar no caminho crítico de renderização. O script é um observador, não um portão.

O que dá para coletar em web e em aplicativo

• Ambiente de exibição. Web: Resolução, densidade, fuso, idioma. Aplicativo: Modelo, versão de sistema, densidade. Para que serve na decisão: Compor o identificador e detectar ambiente inconsistente.
• Renderização. Web: Assinatura de desenho gráfico e de áudio. Aplicativo: Capacidades do aparelho. Para que serve na decisão: Diferenciar aparelhos com configuração parecida.
• Integridade do ambiente. Web: Automação de navegador, inconsistência entre atributos. Aplicativo: Emulador, acesso privilegiado, clonagem de aplicativo. Para que serve na decisão: Detectar evasão deliberada.
• Rede. Web: Endereço de origem, tipo de conexão. Aplicativo: Endereço de origem, operadora, tipo de conexão. Para que serve na decisão: Contexto de origem, tratado em device fingerprint vs IP.
• Armazenamento local. Web: Identificador gravado pelo script, com vida curta. Aplicativo: Identificador fornecido pelo sistema operacional, por aparelho e por desenvolvedor do aplicativo. Para que serve na decisão: Reconhecer retorno recente.

Em aplicativo o terreno é mais firme, porque o SDK acessa sinais que o navegador não expõe. Em web a coleta é mais instável, e o desenho precisa aceitar confiança variável.

Vale dizer o que não entra: conteúdo digitado em campo de formulário, lista de contatos, leitura de área de transferência, localização precisa por GPS e qualquer dado sem relação direta com a decisão de risco. Coletar isso não melhora a decisão e cria exposição desnecessária.

Passo a passo para colocar a coleta em produção

1. Escolha os pontos de coleta. Liste os eventos que quer proteger e confirme que o script está presente em cada um antes do envio.
2. Declare a finalidade por atributo. Monte uma tabela com atributo, finalidade e tempo de guarda. O que não tiver finalidade escrita sai antes de qualquer linha de código.
3. Ajuste o aviso de privacidade e a base legal. Prevenção à fraude costuma ser tratada sob legítimo interesse, com registro da avaliação. Se houver consentimento em outra camada de rastreamento, separe os fluxos.
4. Carregue o script de forma assíncrona. Sem bloqueio de renderização, com tempo limite curto e falha silenciosa.
5. Leia o resultado no envio. Anexe identificador e sinais ao mesmo evento que dispara a decisão, para que decisão e contexto viajem juntos.
6. Trate o caso vazio. Defina o que acontece sem identificador: seguir com confiança reduzida, exigir passo adicional ou encaminhar para análise. Nunca travar sem resposta.
7. Valide em campo antes de ligar regra. Rode em modo de observação, meça cobertura e estabilidade, e só então ligue a regra que recusa.
8. Instrumente a coleta. Meça sessões sem identificador, tempo de coleta e taxa de sinal de evasão. Coleta sem monitoramento apodrece em silêncio.

Por que identificador persistente puro não sobrevive

A tentação de gravar um identificador no navegador e tratá-lo como chave primária eterna termina rápido. O WebKit apaga todo armazenamento gravável por script após sete dias de uso do Safari sem interação do usuário com o site, regra em vigor desde o Safari 13.1 (WebKit, 2020). Limpeza de dados, navegação privativa, troca de navegador e reinstalação de aplicativo produzem o mesmo efeito por outros caminhos.

A consequência de projeto é aceitar que o identificador é uma hipótese com grau de confiança, não um fato. O desenho robusto combina três camadas: o identificador gravado, quando existir; a assinatura derivada dos atributos, que sobrevive à limpeza mas tem colisão; e o histórico de relação entre conta, aparelho e rede no servidor, que dá lastro às duas primeiras.

Há um ganho embutido: o esforço de evasão é observável. Sessão com atributos incompatíveis entre si, automação declarada, emulador ou identificador que muda a cada visita não é anônima, é atípica, e isso entra na decisão.

Consentimento, base legal e coleta proporcional

Três pontos precisam estar resolvidos com o jurídico antes da produção.

O primeiro é a base legal. Tratamento para prevenção à fraude não depende necessariamente de consentimento, mas exige finalidade específica, registro da avaliação e transparência no aviso de privacidade. Quem decide é o jurídico com o encarregado, e a decisão precisa estar documentada.

O segundo é a proporcionalidade, prevista no princípio da necessidade do art. 6º, III da Lei 13.709/2018: o tratamento se limita ao mínimo necessário para a finalidade. Por isso a tabela do passo 2 não é burocracia, é a evidência que sustenta a coleta em uma fiscalização.

O terceiro é a fronteira com dado sensível. Atributo de dispositivo não é dado biométrico, e misturar os dois no mesmo aviso enfraquece as duas bases. Se o seu fluxo também usa biometria facial, mantenha os avisos separados, conforme LGPD e biometria facial.

Como enviar o sinal sem travar a página

Envie o sinal no mesmo evento da decisão, não em uma chamada solta antes dela. Isso evita uma ida extra à rede e mantém no registro da decisão o contexto que foi visto no momento.

Se a coleta passar do limite definido, envie o que estiver pronto com marca de coleta parcial. Se falhar, envie o evento mesmo assim. Decisão tomada com menos sinal e registrada como tal é melhor que usuário parado esperando script de terceiro. A leitura correlacionada desses sinais é o tema de device fingerprint, IP e comportamento.

O que fazer agora

1. Marque em que telas o script já está presente e quais eventos de risco ficaram descobertos.
2. Monte a tabela de atributo, finalidade e tempo de guarda e leve ao encarregado antes de escrever código.
3. Meça sessões sem identificador estável e tempo de coleta no seu público real, separando web e aplicativo.
4. Defina por escrito o comportamento quando o sinal não chega, incluindo o que acontece com o usuário e o que fica registrado.

Perguntas frequentes

Device fingerprint precisa de consentimento do usuário? Nem sempre. Prevenção à fraude costuma ser tratada sob legítimo interesse, com finalidade específica, registro da avaliação e transparência. A definição é jurídica e precisa passar pelo encarregado.

A coleta deixa a página mais lenta? Não precisa deixar. O script carrega de forma assíncrona, coleta enquanto o usuário preenche o formulário e é lido no envio. Nenhum passo deve estar no caminho crítico de renderização.

O identificador some quando o usuário limpa o navegador? O valor gravado some, e o WebKit já apaga o armazenamento gravável por script após sete dias de uso do Safari sem interação do usuário com o site, desde o Safari 13.1 (WebKit, 2020). Por isso o desenho combina identificador gravado, assinatura derivada de atributos e histórico no servidor.

Funciona em aplicativo nativo? Melhor que em web. O SDK acessa sinais mais firmes e detecta emulador, aparelho com acesso privilegiado e clonagem, o que aumenta a estabilidade do identificador.

O que fazer quando o sinal não chega? Definir a regra antes: seguir com confiança reduzida, exigir passo adicional de verificação ou encaminhar para análise. Travar o usuário sem resposta não é opção, e a ausência de sinal deve ficar registrada no evento.

Para avaliar como isso se aplica à sua operação, fale com o time comercial da Shiel ID.