Flash na prova de vida e segurança fotossensível

UNIFOKAL6 min de leituraProduto 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 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: 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
  • Understanding SC 2.3.1, Three Flashes or Below Threshold, W3C: w3.org
  • ISO/IEC 30107-1, Biometric presentation attack detection, Part 1: Framework, citada por nome