Sinais de dispositivo sem SDK nativo: o que o navegador realmente entrega

Quem integra verificação de identidade por página web, sem aplicativo instalado, chega cedo a uma pergunta: dá para saber alguma coisa sobre o aparelho do outro lado? A resposta é sim, mas bem menos do que a literatura de mercado sugere, e a diferença entre o que o navegador entrega e o que só um SDK nativo alcança define o que faz sentido pedir a um fornecedor.

O erro comum não é técnico, é de expectativa. Times pedem ao fluxo web sinais que ele estruturalmente não tem, recebem aproximações, e passam a tratar aproximação como fato. Daí nascem regras que reprovam gente honesta por causa de um atributo que nunca serviu para isso.

Este texto separa três camadas: o que o navegador entrega de forma direta, o que exige código rodando fora do navegador, e como usar responsavelmente o pedaço frágil do meio, os sinais de automação.

O que o navegador entrega sozinho

Sem qualquer permissão especial, uma página lê um conjunto razoável de atributos, todos documentados no MDN Web Docs:

• User-Agent, a cadeia clássica com navegador, versão aproximada e plataforma.
• User-Agent Client Hints, a família de cabeçalhos e a API navigator.userAgentData, especificada pela WICG, grupo comunitário do W3C, fora da trilha de Recomendação, que substitui a leitura da cadeia por campos estruturados. Os itens de baixa entropia (marca, plataforma, se é dispositivo móvel) chegam por padrão; os detalhados, como a versão completa da plataforma, só são enviados se o servidor pedir explicitamente.
• Idioma e fuso horário, este último obtido pela API de internacionalização do próprio JavaScript, e útil menos pelo valor em si e mais pela coerência com o resto.
• Dimensões e densidade de tela, resolução da janela e proporção de pixels.
• Capacidade de mídia: quais formatos o aparelho decodifica, se há câmera disponível e, depois que o usuário concede permissão, os rótulos dos dispositivos de captura. Antes da permissão, o MDN é explícito: a enumeração devolve os dispositivos com rótulo vazio.
• Presença de sensores, como acelerômetro e giroscópio, que em navegadores móveis modernos dependem de permissão do usuário para efetivamente reportar leituras.

Note a natureza desses dados: quase todos são declarados pelo próprio cliente. O navegador informa o que diz ser. Isso não os torna inúteis, torna-os corroborativos: eles valem pela consistência do conjunto, não pela autoridade de cada campo. Um aparelho que se anuncia como iPhone e decodifica formatos que aquele hardware não decodifica está dizendo duas coisas incompatíveis, e a incompatibilidade é o sinal, não o rótulo.

O que exige SDK nativo, e portanto não existe na web

Há uma categoria inteira de sinal que simplesmente não está disponível numa página, e nenhum fornecedor entrega por JavaScript:

• Detecção confiável de root ou jailbreak. Depende de inspecionar o sistema de arquivos, binários e integridade do sistema, coisas que o navegador isola por projeto.
• Detecção de emulador. Exige ler características de hardware e do sistema que a web não expõe.
• Atestação de integridade do aplicativo, que por definição pressupõe um aplicativo.
• Vínculo estável e duradouro com o aparelho. Sem armazenamento nativo, qualquer identificador se apoia em cookies e armazenamento local, que o usuário apaga em três toques.

Isso não condena o fluxo web. Significa apenas que o desenho precisa deslocar peso para sinais que a web tem de fato: coerência dos atributos, comportamento durante o preenchimento, qualidade da captura, e verificação de posse de canais, como e-mail ou telefone. Quem exige garantia de aparelho não confiável em fluxo web está pedindo ao meio errado.

Sinais de automação e por que se escondem fácil

Boa parte da fraude em escala não é uma pessoa preenchendo formulário, é um roteiro automatizado. Detectar essa automação é possível, e é o território mais escorregadio do assunto.

O sinal mais conhecido é a propriedade navigator.webdriver, definida na especificação WebDriver do W3C. Ela existe para que a página saiba que está sob controle remoto, e é justamente essa a limitação: a especificação a apresenta como uma forma padronizada de um agente COOPERATIVO informar que está sob controle do WebDriver. Cooperativo é a palavra que decide tudo, e a conclusão é nossa, não da norma: quem controla o binário do navegador controla o valor que ele reporta, porque o valor vem do próprio navegador e de mais lugar nenhum. Presença do sinal é informação forte; ausência não prova nada.

Sinais comportamentais envelhecem melhor: tempo total de preenchimento incompatível com digitação humana, campos preenchidos em ordem fixa a cada tentativa, ausência completa de eventos de movimento antes do clique, repetição do mesmo padrão em muitas tentativas. Nenhum deles identifica um robô isoladamente, e um usuário de teclado ou de tecnologia assistiva pode produzir padrões atípicos legítimos, razão pela qual ataques de automação em cadastro se combatem melhor com sinais agregados na janela de tempo do que com veredito por sessão.

O rótulo isolado que quase reprovou gente honesta

Vale uma lição prática, dessas que só aparecem em produção. Numa esteira de verificação com selfie, é tentador olhar o rótulo do dispositivo de câmera devolvido pelo navegador e tratar nome sugestivo, com palavras como virtual, como prova de injeção de câmera. A regra parece esperta e é ruim: o rótulo é escolhido pelo fabricante e por drivers legítimos, softwares de videoconferência e utilitários de fabricante instalam câmeras virtuais em máquinas de pessoas absolutamente comuns, e o usuário nem sabe que existem.

O desenho correto separa dois pesos:

• Sinal fraco é o que tem explicação inocente frequente. Rótulo de dispositivo, fuso incomum, navegador raro. Sinal fraco soma pontos e, no limite, encaminha para revisão humana. Nunca reprova sozinho.
• Sinal forte é o que praticamente não tem explicação inocente, como a evidência direta de que o conteúdo entregue não veio do sensor da câmera, ou de que o navegador está sob controle de automação declarada.

Essa hierarquia é o que impede a regra de virar um gerador de injustiça, e é a mesma lógica que sustenta um score de risco explicável: cada sinal com peso conhecido, contribuição registrada e explicação legível depois.

Proporcionalidade, base legal e o direito de revisão

Coleta de sinal de dispositivo é tratamento de dado pessoal, porque o conjunto se conecta a uma pessoa identificável, e por isso a Lei 13.709/2018 se aplica. O artigo 6º, inciso III, impõe o princípio da necessidade: o tratamento deve se limitar ao mínimo necessário para a finalidade. Na prática isso pede três disciplinas simples: coletar os atributos que a regra de fato usa, e não tudo que a API oferece; guardar pelo prazo que a finalidade antifraude justifica; e escrever na política de privacidade, em português claro, que sinais técnicos do dispositivo são coletados para prevenção à fraude. Os limites jurídicos do assunto estão detalhados em device fingerprinting e LGPD.

Há ainda o artigo 20 da mesma lei, que garante ao titular solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem seus interesses. Uma reprovação de cadastro decidida só por sinal de dispositivo cai exatamente nessa hipótese, o que reforça, por via jurídica, a conclusão que a engenharia já tinha chegado por outro caminho: sinal fraco pesa, sinal forte reprova, e um caminho de revisão precisa existir dos dois lados.

Fontes citadas

• WebDriver, especificação do W3C, definição da propriedade navigator.webdriver.
• User-Agent Client Hints, especificação da WICG.
• MDN Web Docs, documentação das APIs de navegador citadas (navigator.userAgentData, MediaDevices.enumerateDevices e sensores), citado por nome no texto.
• Lei 13.709/2018 (Lei Geral de Proteção de Dados Pessoais), artigo 6º, inciso III, e artigo 20, citada por nome no texto.