Applikationer uden understøttelse: den stille flaskehals i kriminaltekniske laboratorier

Laboratoriets mål måler gennemstrømning: behandlede forseglinger, dage pr. undersøgelse, bevisophobningens størrelse. Det, de ikke kan måle, er det bevismateriale, der var til stede, aldrig blev læst og derfor aldrig blev et fund.

Det tal findes ikke nogen steder. Det kan det ikke, fordi det at registrere det ville kræve, at man vidste, hvad der var i den del, ingen åbnede. Men det er ikke lille, og dets største enkeltårsag er applikationer, et værktøj ikke afkodede.

Fire måder, en applikation ender ulæselig på

Den er regional. En besked- eller social applikation med nogle hundrede tusind brugere i ét land er ikke en prioritet for en leverandør, der sælger ind i fyrre markeder. Den kan være særdeles relevant, hvis det land er der, hvor Deres efterforskning er.

Den er ny. Afstanden mellem, at en applikation bliver populær, og at den optræder i et kriminalteknisk værktøjs udgivelsesnoter, måles i kvartaler. Kriminel ibrugtagning af en ny kommunikationskanal måles i uger, og den er ofte hurtigere end den legitime ibrugtagning, fordi incitamentet til at flytte er stærkere.

Den ændrede sig. Det er den største kategori og den mindst omtalte. En understøttet applikation udsender en opdatering, der omorganiserer dens lagring, og den parser, der blev skrevet til den foregående version, returnerer delvise resultater eller ingen. Værktøjet angiver stadig applikationen som understøttet. Analytikeren skal opdage, at outputtet er tyndere, end det burde være, hvilket kræver, at vedkommende allerede nogenlunde ved, hvad der kan forventes.

Den var aldrig nogens prioritet. Fitnessapplikationer, noteapplikationer, historik fra kørselstjenester, leveringsapplikationer, betalingspunge, stemmememoer. Sjældent centrale, lejlighedsvis afgørende og hver for sig aldrig et ingeniørkvartal værd.

Hvorfor det forbliver usynligt

Tre ting holder dette fra at fremstå som et problem, nogen ejer.

Den første er, at rapporten er korrekt. En analytiker, der skriver, at bestemte applikationsdata ikke blev analyseret, har dokumenteret begrænsningen korrekt. Intet i en kvalitetsgennemgang vil markere det.

Den anden er, at den uformelle omfangsregel er fornuftig. Undersøg det, værktøjet afkodede, undersøg det, efterforskeren specifikt spurgte om, og notér resten. Under en reel sagsmængde er det den fagligt korrekte beslutning, og den frembringer den samme reduktion af omfanget hver eneste gang.

Den tredje er, at ingen ved, hvad der blev overset. En efterforsker, der aldrig erfarer, at en samtale fandtes, kan ikke spørge, hvorfor den ikke var i rapporten. Fraværet er strukturelt uobserverbart.

Hvad analytikere faktisk gør ved det

De dygtige gør noget, og det skalerer ikke.

Nogle åbner databasen i hånden, finder ud af skemaet og skriver en forespørgsel. Nogle vedligeholder en personlig samling af scripts. Nogle kender en kollega i en anden tjeneste, som har mødt denne applikation før, og sender en e-mail. I nogle få laboratorier er der en person, som regel én, der er kendt for at være villig til at gøre dette, og vedkommendes kø er den virkelige flaskehals.

Enhver udgave af dette har de samme to problemer. Det koster timer, sagen ikke kan afse, og den forståelse, der frembringes, er ikke holdbar. Den lever i ét menneskes hoved eller i en kladdefil, og når vedkommende går videre, følger den med. Den næste analytiker i den næste tjeneste møder den samme applikation om seks måneder og begynder forfra.

Formen på en afhjælpning

Hvis begrænsningen er, at nogen skal forstå et ukendt lagringsformat, før dets indhold kan læses, er der kun to veje ud. Gør den forståelse billigere at frembringe, eller gør den holdbar, når den først er frembragt.

Begge er til rådighed, og de forstærker hinanden.

At frembringe den billigt er nu et håndterligt problem. At finde ud af, hvad en ukendt database er til, ud fra dens filsti, dens tabel- og kolonnenavne og en prøve af dens indhold, er en ræsonnementsopgave frem for en mønstermatchningsopgave, og det er den slags opgave, nuværende modeller håndterer usædvanligt godt. Outputtet er en mapping: en beskrivelse af, hvordan denne kilde læses ind i de felter, en visning forventer.

Det output kan ikke blot stoles på, og det behøver det ikke. Validér den strukturelt, kør den mod en prøve af de virkelige data, og vis analytikeren en forhåndsvisning af de faktiske poster. En mapping, der har misforstået kilden, frembringer en forhåndsvisning fuld af nonsens, hvilket er tydeligt på få sekunder. Analytikeren accepterer den, retter den i en visuel editor eller kasserer den.

At gøre den holdbar er den lettere halvdel og den mere værdifulde. En valideret mapping er et lille artefakt, der ikke indeholder bevismateriale, kun beskrivelsen af, hvordan en struktur læses. Den kan deles. Når et andet laboratorium åbner en forsegling, der indeholder den samme applikation, anvendes den automatisk.

Det er det punkt, hvor økonomien ændrer sig. I dag gentages arbejdet med at forstå en applikation i hver tjeneste, der møder den, og går tabt hver gang. Delt betales det én gang.

Den påstand, det er værd at være omhyggelig med

Der findes en udgave af dette argument, der rækker for vidt, og det er værd at markere grænsen.

Automatisk mapping betyder ikke, at en analytiker aldrig skal se på noget. Det betyder, at den første forståelse frembringes af softwaren, og at analytikerens rolle bliver gennemgang frem for konstruktion. Nogle mappings vil være forkerte. Nogle kilder er reelt tvetydige, og ingen mængde ræsonnement om et skema vil afklare, hvad en kolonne betyder, når dens navn er f4, og dens indhold er heltal.

Det, der ændrer sig, er ikke standarden. Det er, hvem der laver den første gennemgang, og hvor længe et laboratorium venter på den. I stedet for et kvartal tager det minutter, og resultatet er noget, tjenesten beholder.