# Flash na prova de vida e segurança fotossensível Guia · UNIFOKAL · 2 de setembro de 2026 · 6 min de leitura · Produto e integração Liveness por flash de cores existe no mercado, e tela que pisca tem limite de segurança definido: o que diz o critério 2.3.1 do WCAG 2.2 e como fazer desafio ativo sem risco fotossensível. Uma família de técnicas de prova de vida usa a tela do celular como fonte de luz: o aplicativo pisca cores em sequência e a análise verifica se o reflexo no rosto corresponde, em cor e em tempo, ao que foi emitido. A ideia é engenhosa, um rosto tridimensional de verdade reflete luz do jeito que a física manda, e uma tela reproduzindo vídeo, não. Mas ela transforma a interface numa fonte de flashes, e flash em tela não é detalhe estético: é um risco documentado para pessoas com epilepsia fotossensível, com limite técnico publicado. Este artigo apresenta o limite, explica por que a tela de captura é o pior lugar possível para piscar e mostra que dá para desenhar prova de vida forte sem chegar perto dele. ## O limite existe e está escrito O WCAG (Web Content Accessibility Guidelines), do W3C, dedica um critério de nível A ao tema na versão 2.2, o 2.3.1: uma página não pode conter nada que pisque mais de três vezes em qualquer janela de um segundo, a menos que o flash fique abaixo dos limiares definidos de flash geral e de flash vermelho. O documento de apoio da W3C, o Understanding do critério, explica a razão: flashes acima desses limiares podem provocar crises em pessoas com transtorno convulsivo fotossensível, e a transição envolvendo vermelho saturado recebe limiar próprio por ser particularmente provocativa. Os limiares não olham só a frequência: consideram também a fração do campo visual ocupada pela área que pisca e a amplitude da variação de luminância. Existe ainda o critério 2.3.2, de nível AAA, mais duro: nada de piscar mais de três vezes em um segundo, ponto, sem a válvula de escape dos limiares. Para um fluxo que o usuário não visita por lazer, e verificação de identidade é obrigação de passagem, não entretenimento, a postura conservadora é mirar o nível AAA: a pessoa não escolheu estar ali e não pode simplesmente fechar a aba, porque do outro lado está a conta que ela precisa abrir. ## Por que a captura é o pior lugar para piscar Três características do momento de captura corroem a margem de segurança ao mesmo tempo: - Proximidade e área. Na selfie, o rosto está a um palmo da tela, e a região que pisca tende a ocupar o quadro inteiro. Quanto maior a fração do campo visual atingida, mais perto do limiar a mesma piscada chega; os limiares do WCAG são definidos justamente em função dessa área. - Brilho no máximo. Para o reflexo no rosto ser mensurável, a tela precisa ser a fonte de luz dominante, o que empurra o brilho para cima e aumenta a amplitude da variação de luminância entre uma cor e outra, o segundo termo que os limiares medem. - Ambiente escuro. A orientação clássica de captura, evitar luz forte atrás e ao redor, deixa a pupila adaptada ao escuro e o contraste percebido do flash ainda maior. Somando: uma sequência de cores que seria inofensiva num banner pequeno, numa tela distante e num ambiente claro pode se tornar um problema real exatamente na condição de uso que a captura recomenda. Quem adota desafio luminoso precisa medir a frequência, a área e a amplitude da sequência contra o critério 2.3.1, e não confiar na impressão de que "pisca pouco". ## Desafio ativo sem estroboscópio A boa notícia é que o espaço de desenho de prova de vida é grande, e a maior parte dele nem se aproxima do limite. A norma ISO/IEC 30107-1, que estrutura a detecção de ataque de apresentação (PAD, na sigla em inglês), descreve mecanismos passivos e de desafio e resposta; nada nela exige luz pulsada. As alternativas em uso: - Análise passiva. Textura de pele, artefatos de reapresentação, coerência de iluminação: tudo extraído da imagem que a captura já produz, sem pedir nada ao usuário. É a camada de melhor custo por atrito, como o artigo sobre [o custo de rodar prova de vida](https://unifokal.com/blog/custo-de-rodar-prova-de-vida) detalha. - Micromovimento natural. O jeito como o rosto e o fundo se deslocam entre quadros quando a mão e a cabeça se movem entrega volume tridimensional de graça, sem instrução e sem luz. - Desafio de ação lenta. Virar a cabeça devagar, aproximar o rosto: janela de tempo generosa, sem exigência de velocidade, sem flash. - Iluminação modulada com teto. Se a variação de luz da tela fizer parte do desenho, dá para mantê-la dentro do critério: transições lentas, três ou menos por segundo com folga, sem vermelho saturado, em área controlada e com brilho limitado. O que a camada luminosa agrega contra ataques de reapresentação e o que cada camada custa em latência é a conta de sempre da [prova de vida](https://unifokal.com/blog/prova-de-vida-liveness): defesa em profundidade, com cada camada barrando uma classe de ataque. O ponto deste artigo é que a camada estroboscópica não é obrigatória para nenhuma classe, e carrega um risco que as outras não têm. ## O que perguntar ao fornecedor Avaliar um fornecedor de captura nesse quesito cabe em quatro perguntas: - O desafio pisca? Se sim, quantas vezes por segundo, com que área de tela e que amplitude de luminância? A resposta aceitável é um número comparado ao critério 2.3.1, não um "está tudo certo". - Existe caminho alternativo sem flash, e ele é oferecido antes da sequência luminosa, não depois da crise? - Há aviso prévio ao usuário quando existe sequência de luz? Aviso é mitigação honesta, mas não substitui o limite. - O comportamento é o mesmo em brilho máximo e em ambiente escuro, que é a condição real de uso? Na UNIFOKAL, por exemplo, a resposta é pelo desenho: a prova de vida é passiva e usa o micromovimento natural da própria captura, sem desafio de flash estroboscópico. Dizer o que não se faz também é informação de produto: quem compara fornecedores tem o direito de saber se a segurança de um fluxo depende de fazer a tela piscar no rosto do usuário. O limite fotossensível não é inimigo da prova de vida; é uma restrição de projeto como qualquer outra, com número publicado e teste possível. Desenho bom passa longe dele e continua barrando ataque. Desenho preguiçoso terceiriza o risco para o usuário que menos pode absorvê-lo. ## Fontes citadas - WCAG 2.2, W3C, critérios 2.3.1 e 2.3.2: [w3.org](https://www.w3.org/TR/WCAG22/#three-flashes-or-below-threshold) - Understanding SC 2.3.1, Three Flashes or Below Threshold, W3C: [w3.org](https://www.w3.org/WAI/WCAG22/Understanding/three-flashes-or-below-threshold) - ISO/IEC 30107-1, Biometric presentation attack detection, Part 1: Framework, citada por nome