Aplicações não suportadas: o estrangulamento silencioso nos laboratórios forenses

As métricas de um laboratório medem o débito: lacres tratados, dias por exame, tamanho da fila. O que não podem medir é a prova que estava presente, nunca foi lida e por isso nunca se tornou uma constatação.

Esse número não existe em lado nenhum. Não pode, porque registá-lo exigiria saber o que estava na parte que ninguém abriu. Mas não é pequeno, e a sua maior causa isolada são aplicações que uma ferramenta não descodificou.

Quatro formas de uma aplicação ficar ilegível

É regional. Uma aplicação de mensagens ou social com algumas centenas de milhar de utilizadores num país não é uma prioridade para um fornecedor que vende em quarenta mercados. Pode ser extremamente relevante se esse país é onde a sua investigação está.

É nova. A distância entre uma aplicação tornar-se popular e aparecer nas notas de publicação de uma ferramenta forense mede-se em trimestres. A adoção criminal de um novo canal de comunicação mede-se em semanas, e é muitas vezes mais rápida do que a adoção legítima, porque o incentivo para mudar é mais forte.

Mudou. Esta é a categoria maior e a menos discutida. Uma aplicação suportada envia uma atualização que reorganiza o seu armazenamento, e o parser escrito para a versão anterior devolve resultados parciais ou nenhuns. A ferramenta continua a listar a aplicação como suportada. O examinador tem de reparar que o resultado é mais escasso do que devia, o que exige já saber aproximadamente o que esperar.

Nunca foi prioridade de ninguém. Aplicações de exercício, aplicações de notas, histórico de transporte por aplicação, aplicações de entregas, carteiras de pagamento, notas de voz. Raramente centrais, ocasionalmente decisivas, e individualmente nunca a valer um trimestre de um engenheiro.

Porque continua invisível

Três coisas impedem que isto apareça como um problema de que alguém é dono.

A primeira é que o relatório é exato. Um examinador que escreve que certos dados de aplicação não foram analisados documentou a limitação corretamente. Nada numa revisão de qualidade o assinalará.

A segunda é que a regra informal de âmbito é sensata. Examinar o que a ferramenta descodificou, examinar o que o investigador pediu em concreto, anotar o resto. Sob um volume de casos real, essa é a decisão profissionalmente correta, e produz a mesma redução de âmbito de cada vez.

A terceira é que ninguém sabe o que foi falhado. Um investigador que nunca fica a saber que uma conversa existia não pode perguntar porque não estava no relatório. A ausência é estruturalmente inobservável.

O que os examinadores fazem de facto

Os bons fazem alguma coisa, e isso não acompanha o volume.

Alguns abrem a base de dados à mão, percebem o esquema e escrevem uma consulta. Alguns mantêm uma coleção pessoal de scripts. Alguns conhecem um colega noutro serviço que já encontrou esta aplicação e enviam um e-mail. Em alguns laboratórios há uma pessoa, em geral uma, conhecida por estar disposta a fazê-lo, e a fila dela é o verdadeiro estrangulamento.

Cada versão disto tem os mesmos dois problemas. Custa horas que o caso não pode dispensar, e a compreensão produzida não é duradoura. Vive na cabeça de uma pessoa ou num ficheiro de rascunho, e quando essa pessoa segue em frente leva-a consigo. O examinador seguinte, no serviço seguinte, encontra a mesma aplicação seis meses depois e começa de novo.

A forma de uma correção

Se a restrição é que alguém tem de compreender um formato de armazenamento desconhecido antes de o conteúdo poder ser lido, só há duas saídas. Tornar essa compreensão mais barata de produzir, ou torná-la duradoura depois de produzida.

As duas estão disponíveis, e reforçam-se.

Produzi-la a baixo custo é agora um problema tratável. Perceber para que serve uma base de dados desconhecida, a partir do caminho do ficheiro, dos nomes das tabelas e das colunas e de uma amostra do conteúdo, é uma tarefa de raciocínio e não de correspondência de padrões, e é o tipo de tarefa que os modelos atuais tratam invulgarmente bem. A saída é um mapeamento: uma descrição de como ler esta fonte para os campos que uma vista espera.

Essa saída não pode simplesmente ser confiada, e não tem de o ser. Valida-se estruturalmente, corre-se contra uma amostra dos dados reais e mostra-se ao examinador uma pré-visualização de registos reais. Um mapeamento que compreendeu mal a fonte produz uma pré-visualização cheia de disparates, o que é óbvio em segundos. O examinador aceita-o, corrige-o num editor visual ou descarta-o.

Torná-lo duradouro é a metade mais fácil e a mais valiosa. Um mapeamento validado é um pequeno artefacto que não contém prova, apenas a descrição de como ler uma estrutura. Pode ser partilhado. Quando outro laboratório abre um lacre que contém a mesma aplicação, aplica-se automaticamente.

É nesse ponto que a economia muda. Hoje, o esforço de compreender uma aplicação é repetido em cada serviço que a encontra, e perdido de cada vez. Partilhado, paga-se uma vez.

A afirmação com que vale a pena ter cuidado

Há uma versão deste argumento que vai longe de mais, e vale a pena marcar a linha.

O mapeamento automático não significa que um examinador nunca tem de olhar para nada. Significa que a primeira compreensão é produzida pelo software e o papel do examinador passa a ser revisão e não construção. Alguns mapeamentos estarão errados. Algumas fontes são genuinamente ambíguas, e nenhum raciocínio sobre um esquema resolve o que uma coluna significa quando o nome é f4 e o conteúdo são inteiros.

O que muda não é o padrão. É quem faz a primeira passagem, e quanto tempo um laboratório espera por ela. Em vez de um trimestre, leva minutos, e o resultado é algo que o serviço conserva.