Um WebView é vendido como «apenas um navegador». Para sua equipe de fraude e risco, é uma roleta de identidade de dispositivo. A página carrega, o usuário toca em pagar e, em algum lugar, um motor de risco pontua a solicitação. O que ele não vê é que o «dispositivo» que ele pontua muda toda vez que o app abre uma view nova ou um modo privado apaga o cookie jar. A mesma pessoa vira um dispositivo diferente — e sua taxa de falsos negativos é a conta.

Três partições, três formas de perder identidade

O problema não é um bug; são três decisões de partição independentes se somando. No iOS, a Prevenção de Rastreamento (ITP) da WebKit particiona o LocalStorage e IndexedDB de terceiros por primeiro partido e limita a sete dias os cookies de cliente definidos via document.cookie. O próprio documento de prevenção da Apple afirma que a política de cookies padrão proíbe terceiros de escrever cookies a menos que já os tenham, e que o armazenamento particionado se torna efêmero. Além disso, um WKWebView configurado com WKWebsiteDataStore.nonPersistent() — o modo padrão de implementar sessões «privadas» ou descartáveis — não grava nada em disco e descarta tudo ao fechar a view. No Android, o problema oposto: o CookieManager é de nível de processo, então não há forma honesta de dar a um WebView uma sessão isolada sem limpar de forma destrutiva os cookies compartilhados com todos os outros WebViews do app. A realidade multiplataforma é um remendo onde a identidade às vezes é particionada, às vezes efêmera e às vezes compartilhada — e nunca sob seu controle.

O que o motor de risco vê

As pilhas de fraude e KYC dependem de um sinal estável de dispositivo ou instalação para separar um bom cliente recorrente de um fraudador abrindo contêineres novos. Quando esse sinal é um valor de cookie ou localStorage que o sistema operacional particiona, expira ou apaga, o mesmo usuário real se apresenta como um dispositivo novo e anônimo a cada sessão. Esse é justamente o padrão que os modelos de risco tratam como alto: dispositivo novo, sem histórico, geo ou comportamento que não bate com a última sessão boa conhecida. A plataforma não quer bloquear o cliente; simplesmente não o reconhece. Enquanto isso, um fraudador real com um contêiner limpo é indistinguível do seu melhor cliente abrindo o app após uma limpeza por ITP.

O custo é real e não é o fraude

O dinheiro perdido com falsos negativos supera o perdido com fraude. A pesquisa da indústria compilada por analistas de recuperação de pagamentos coloca a receita de e-commerce perdida por falsos negativos em cerca de 443 bilhões de dólares por ano, com cerca de 58% de todos os negativos sendo falsos positivos e cerca de 13 dólares perdidos por falso negativo para cada 1 dólar perdido com fraude. Um relatório da Raconteur e Riskified mostrou que só em 2023, 1,57 trilhão de dólares em vendas de e-commerce dos EUA ficaram expostos a falsos negativos, com 81 bilhões estimados como perda permanente, e 47% dos varejistas disseram que os falsos negativos prejudicam severamente a satisfação do cliente. Um cliente falsamente negado raramente reclama — ele apenas vai embora, e cerca de um terço não volta. Quando a deriva de cookies do seu WebView fabrica silenciosamente esses falsos positivos, o runtime custa mais do que qualquer fraudador.

A pressão por privacidade piora tudo

A partição agressiva de armazenamento reduz o rastreamento entre sites, mas pesquisadores de segurança há anos avisam que empurra a web para a impressão digital opaca — sinais derivados de hardware e configuração que o usuário não vê nem controla. Dentro de um WebView, isso significa que equipes de fraude, privadas de cookies de primeira parte confiáveis, dependem mais da impressão digital, que é justo o que os regimes de privacidade (GDPR e a própria postura da Apple) tentam restringir. Você acaba escolhendo entre reconhecer seus próprios clientes e respeitar as regras de privacidade, com o comportamento de partição do WebView forçando-o ao pior dos dois.

A solução do runtime

Um runtime próprio do host não pede ao navegador que lembre quem é o usuário. Ele emite uma identidade de dispositivo ou instalação estável, assinada e com consentimento a partir da camada do host, e a injeta deterministicamente em cada view e cada solicitação — o mesmo identificador quer o WebView seja efêmero, particionado ou compartilhado. A reconciliação de sessão no servidor vincula essa identidade à conta real, então clientes recorrentes são reconhecidos mesmo após uma limpeza por ITP, e fraudadores reais abrindo contêineres novos continuam se destacando. A identidade vira uma propriedade que o runtime garante, não uma moeda no ar dentro do armazenamento particionado.

DimensãoWebViewRuntime próprio do host
Armazenamento iOSITP particiona por primeiro partido; teto de cookies de 7 diasIdentidade estável injetada pelo host
Views efêmerasnonPersistent() descarta toda identidadeMesma ID assinada em views efêmeras
Armazenamento AndroidCookie jar de nível de processo; sem isolamento por viewID por instalação, não depende de CookieManager
Pontuação de riscoIdentidade deriva por sessão → falsos positivosSinal de dispositivo consistente → menos falsos negativos
PrivacidadeEmpurra para impressão digital opacaCom consentimento, primeira parte, auditável

O fio condutor desta série é o controle. Um WebView entrega à sua pilha de fraude uma identidade de dispositivo que não possui e não pode confiar. Um runtime deixa você emitir uma. Para um catálogo de páginas alheias que transacionam dentro do seu app, essa diferença é a fenda entre um checkout que converte e um que afasta silenciosamente bons clientes.

Fontes