Referência: Sinais de assinatura em PDF
Baixei 1.317 contratos federais publicados no PNCP e passei todos pelo motor. O agregado até lisonjeia: 89,8% em banda baixa, 0,4% em elevada, 9,8% em alta. Melhor que as duas populações aleatórias que eu tinha medido antes. E o agregado esconde a história inteira, porque basta dividir o mesmo corpus por uma pergunta, alguém assinou este documento?, para o motor mudar de figura.
| docs | low | elevated | high | |
|---|---|---|---|---|
| sem assinatura | 1.150 | 99,65% | 4 docs | 0 |
| assinados | 167 | 37 docs | 1 doc | 77% |
E o detalhe que fecha o diagnóstico: cada um dos 37 contratos assinados que saíram em banda baixa carrega exatamente uma revisão. Um signatário só. O gatilho da banda alta não é adulteração. É a segunda assinatura.
O mecanismo, sinal por sinal, e cada um está certo
É assim que o documento mais comum deste mercado vira o pior resultado do
relatório. A assinatura ICP-Brasil anexa uma revisão incremental por
signatário, ou seja, escreve um bloco novo no fim do arquivo em vez de
reescrever tudo. É o jeito correto, previsto na especificação, de assinar sem
invalidar a assinatura anterior. Só que os bytes do segundo signatário ficam,
por definição, depois do /ByteRange do primeiro, que é a faixa
de bytes que a assinatura dele cobre. A partir daí:
-
signature-coveragereporta emhighque as assinaturas não cobrem mais o arquivo inteiro. Verdade. -
cada assinatura é uma revisão, então
incremental-updatesreporta emhigh. Verdade. -
o
/ID[1]muda a cada revisão, entãoid-inconsistencyreporta emmedium. Verdade. -
e
signature-integrity, a família que de fato confere o digest, reporta eminfo: as assinaturas estão íntegras e o conteúdo assinado nunca foi alterado. Também verdade.
O mesmo relatório diz que as assinaturas são válidas e dá nota 100 ao documento. Cada frase individual está certa sobre os bytes. A conclusão composta está errada sobre o documento. E é justamente por ser um erro de composição, não de leitura, que ele é sério: nenhum parser mais cuidadoso resolve isso. O que resolve é uma recalibração de severidade.
Por que publiquei antes de corrigir
A regra da casa é que mudança de severidade vem depois de uma medição de corpus, nunca antes. Subtrair pontos de assinatura múltipla no dia em que a suspeita apareceu seria calibrar no palpite. É exatamente o defeito que este produto existe para criticar nos outros. A medição destes 1.317 contratos é a metade que já foi feita; a recalibração é a metade que ela agora autoriza.
Enquanto ela não sai, a página de
precisão diz com todas as letras: leia banda alta em PDF com múltiplas
assinaturas como não informativa. No lugar dela, leia as famílias
signature-integrity e signature-permissions, que
são as que respondem à pergunta que importa.
Do engine 1.32.0 em diante o relatório traz as revisões uma a uma. Mostra o que cada anexo escreveu, contado por tipo de objeto, com o veredicto da certificação por revisão. Num contrato com dois signatários, o revisor vê que a revisão 2 escreveu uma assinatura e nada de conteúdo de página. É a cara exata do caso legítimo. O número no topo ainda precisa da recalibração; a evidência para ler por baixo dele já está no relatório.
O que isso significa para quem avalia a ferramenta
Se você processa contratos brasileiros, este é o teste de honestidade que eu sugeriria aplicar a qualquer fornecedor, o nosso incluído. Pergunte qual é a taxa de falso positivo no documento mais comum do seu fluxo. E peça o número medido, com denominador. O nosso pior caso está publicado nesta página e na página de precisão, com o corpus nomeado e a data. Um fornecedor que não publica taxa nenhuma não tem taxa zero. Tem taxa desconhecida.
Veja o histórico de revisões de um PDF: grátis, sem conta, o arquivo é processado em memória e descartado com a resposta. Um contrato com uma revisão por signatário é normal. A pergunta interessante é o que cada revisão escreveu, e o relatório agora responde.