Metadados de foto no onboarding: o que o EXIF entrega e por que a ausência não acusa

O analista abre a imagem que o cliente enviou, roda uma ferramenta de metadados, não encontra nada e escreve na ficha: "metadados removidos, indício de manipulação". Essa frase, repetida por uma esteira inteira, produz recusa de gente honesta em escala. A ausência de metadados EXIF numa foto de onboarding é o resultado normal de um caminho normal, não a assinatura de um fraudador.

O EXIF, de Exchangeable Image File Format, é o bloco de informação que uma câmera grava junto com a imagem: data e hora de captura, fabricante e modelo do aparelho, parâmetros de exposição, orientação e, quando o aparelho registra, coordenadas de GPS. Ele é especificado pela CIPA, a Camera and Imaging Products Association, no documento DC-008.

Este artigo é sobre foto. A anatomia equivalente em arquivo de documento está em como saber se um PDF foi editado, e a conclusão é parecida nos dois formatos: metadado é sinal fraco por natureza. A diferença é que, na foto, o sinal costuma nem existir.

O metadado mora ao lado da imagem, não dentro dela

Vale entender o mecanismo antes de discutir a interpretação. O formato de arquivo JPEG mais usado é padronizado na Recomendação ITU-T T.871, publicada também como ISO/IEC 10918-5, o JFIF. O item 6.5 dessa norma trata dos segmentos de marcador de aplicação e diz o essencial numa frase: segmentos adicionais podem ser usados para guardar informação específica de aplicação que não afeta a capacidade de decodificar ou exibir o arquivo.

Essa é a definição arquitetural do problema. O bloco de metadados é uma gaveta paralela ao dado comprimido. Remover a gaveta não muda um pixel, e reescrever o conteúdo dela também não. Nada no formato amarra o que está escrito ali ao que está desenhado na imagem.

Compare com o que uma amarração de verdade exige. O item 4.1 do DOC-ICP-15, do Comitê Gestor da ICP-Brasil, define assinatura digital como aquela vinculada ao documento eletrônico de tal modo que qualquer alteração subsequente neste seja plenamente detectável. É esse vínculo que o bloco de metadados de uma foto nunca teve.

Por que o metadado some sozinho

O caminho que uma foto percorre até chegar ao seu servidor passa por etapas que reconstroem o arquivo. A mais comum, e a mais fácil de provar, é o desenho em canvas dentro do navegador.

O padrão HTML descreve, na seção de serialização de bitmap para arquivo, o que acontece quando a página transforma um canvas em imagem: o agente de usuário cria um arquivo no formato pedido, e os dados de pixel desse arquivo devem ser os dados de pixel do bitmap. O único metadado que o algoritmo menciona é a resolução, que deve ser gravada como 96 dpi quando o formato suportar. Nada mais atravessa. O arquivo que sai é uma construção nova feita a partir de pixels.

Qualquer etapa que redimensione, recorte, comprima ou converta a imagem tem o mesmo efeito, a menos que o código copie o bloco de propósito. Uma captura feita pela câmera dentro da página nunca teve EXIF para começar, porque não veio de um arquivo de câmera: veio de quadros desenhados e depois serializados.

A conclusão prática é direta. Metadado ausente é o desfecho esperado de um fluxo web comum. Usar a ausência como sinal de risco é punir o usuário pelo comportamento do navegador dele, e o efeito de uma regra dessas é medido na fila de recusa, não na de fraude.

A orientação é o metadado que quebra coisa de verdade

Há um campo do EXIF que não é opcional na prática: a orientação. O navegador consome esse campo por padrão. A propriedade image-orientation, especificada pelo W3C no módulo CSS Images de nível 3, tem valor inicial from-image, e a especificação explica que, se a imagem tem orientação declarada nos metadados, como no EXIF, esse valor equivale ao ângulo que os metadados indicam como necessário para orientar a imagem corretamente. Sem metadado de orientação, o valor calculado passa a ser none.

O resultado é uma armadilha clássica de esteira: a imagem aparece certa na tela, porque o navegador aplicou a rotação, e chega girada no serviço que vai processá-la, porque a decodificação do lado do servidor ignorou o campo. Detector de rosto em imagem girada encontra menos rosto, ou encontra e extrai um vetor pior. O sintoma chega como queda de aprovação sem causa aparente.

A defesa é aplicar a orientação de forma explícita na entrada, antes de qualquer recorte ou comparação, e registrar que ela foi aplicada. Vale para toda a cadeia: o que sai do upload precisa chegar normalizado ao passo seguinte, e não confiar no acaso de cada decodificador.

Metadado presente informa, mas não prova

Invertido o raciocínio, a pergunta seguinte é o que fazer quando o bloco está lá. A resposta honesta: use como contexto, nunca como prova.

Tudo que está no bloco foi escrito por algum programa, e pela norma citada acima aquele conteúdo não interfere na decodificação, então editá-lo não deixa rastro na imagem. Um campo de data e hora é uma afirmação de quem gravou o arquivo, não uma medição. Isso não o torna inútil: torna-o insumo de priorização, do tipo que entra num score explicável com peso pequeno, e nunca um portão de recusa.

Há ainda um custo de coleta. Se as coordenadas de GPS vierem, você passou a tratar dado de localização de uma pessoa identificada, que é dado pessoal na definição do inciso I do artigo 5º da Lei 13.709/2018, a LGPD. Guardar isso exige finalidade, base legal e prazo, e a alternativa mais barata quase sempre é descartar o bloco na borda, como em reduzir o dado antes de enviar ao fornecedor.

O que colocar na esteira

Traduzindo tudo em regra operacional:

1. Nunca reprove por ausência de metadado. Ela não distingue fraudador de usuário de navegador comum.
2. Aplique a orientação declarada antes de recortar, comparar ou indexar, e registre isso no log do processamento.
3. Trate campo presente como sinal fraco, com peso pequeno, sempre acompanhado de outros sinais.
4. Decida explicitamente se guarda GPS. Se não tem finalidade, descarte antes de armazenar.
5. Guarde no registro o que foi observado e o que foi decidido, porque metadado é justamente o tipo de evidência que ninguém consegue reconstruir depois.

E a nota final, que reposiciona o problema inteiro: o ataque sério contra captura remota não passa pelo arquivo. Ele injeta quadros direto no caminho da câmera, como em injeção de câmera, e aí o arquivo pode até vir com metadados plausíveis. Quem defende essa superfície olha os sinais do dispositivo e a coerência da sessão, numa esteira de antifraude em camadas. O bloco EXIF é o último lugar onde essa resposta está.

Perguntas frequentes

Foto sem EXIF é sinal de fraude?

Não. Qualquer etapa que reconstrói o arquivo elimina o bloco, e o padrão HTML define a serialização de um canvas a partir dos dados de pixel do bitmap, sem transportar metadado de origem. Ausência é o resultado esperado de um fluxo web comum, não um indício.

Dá para confiar na data de captura do EXIF?

Não como prova. O item 6.5 da Recomendação ITU-T T.871 descreve esses segmentos como informação de aplicação que não afeta a decodificação, então reescrevê-los não deixa marca na imagem. A data serve como contexto de priorização, com peso pequeno, nunca como portão de decisão.

Por que a foto aparece certa na tela e girada no servidor?

Porque o navegador aplica a orientação do EXIF por padrão: a propriedade image-orientation do CSS Images nível 3 tem valor inicial from-image, que equivale ao ângulo indicado pelos metadados. Um decodificador do lado do servidor que ignore esse campo entrega a imagem na rotação bruta.

Fontes citadas

• Recomendação ITU-T T.871, publicada também como ISO/IEC 10918-5, JPEG File Interchange Format, item 6.5, sobre segmentos de marcador de aplicação: itu.int
• CIPA, Camera and Imaging Products Association, documento DC-008, especificação do Exchangeable Image File Format (EXIF), citada por nome como a norma que define o formato de metadados.
• HTML Standard, do WHATWG, seção 4.12.5.5, serialização de bitmap do canvas para arquivo: html.spec.whatwg.org
• W3C, CSS Images Module Level 3, seção 5.1, propriedade image-orientation e o valor from-image: w3.org
• DOC-ICP-15, Visão Geral sobre Assinaturas Digitais na ICP-Brasil, versão 4.0, item 4.1, usado como contraste sobre o que é vínculo detectável entre assinatura e conteúdo: gov.br
• Lei 13.709/2018, a LGPD, artigo 5º, inciso I, definição de dado pessoal, no portal do Planalto: planalto.gov.br