Applikasjoner uten støtte: den stille flaskehalsen i kriminaltekniske laboratorier

Laboratoriets måltall måler behandlingstakt: segl behandlet, dager per undersøkelse, størrelsen på beviskøen. Det de ikke kan måle, er beviset som var til stede, aldri ble lest, og derfor aldri ble et funn.

Det tallet finnes ikke noe sted. Det kan det ikke, fordi det å registrere det ville kreve å vite hva som lå i delen ingen åpnet. Men det er ikke lite, og den største enkeltårsaken er applikasjoner et verktøy ikke dekodet.

Fire måter en applikasjon ender uleselig på

Den er regional. En meldings- eller sosial applikasjon med noen hundre tusen brukere i ett land er ikke en prioritet for en leverandør som selger til førti markeder. Den kan være ytterst relevant hvis det landet er der etterforskningen Deres er.

Den er ny. Gapet mellom at en applikasjon blir populær og at den dukker opp i versjonsnotatene til et kriminalteknisk verktøy, måles i kvartaler. Kriminell bruk av en ny kommunikasjonskanal måles i uker, og den er ofte raskere enn legitim bruk, fordi insentivet til å flytte er sterkere.

Den endret seg. Dette er den største kategorien, og den minst omtalte. En applikasjon med støtte leverer en oppdatering som omorganiserer lagringen, og parseren skrevet for forrige versjon returnerer delvise resultater, eller ingen. Verktøyet fører fortsatt opp applikasjonen som støttet. Analytikeren må merke at resultatet er tynnere enn det burde være, noe som krever at vedkommende allerede vet omtrent hva en skal vente.

Den var aldri noens prioritet. Treningsapplikasjoner, notatapplikasjoner, historikk fra apper for bestilt transport, leveringsapper, betalingslommebøker, talememoer. Sjelden sentrale, av og til avgjørende, og hver for seg aldri verdt en ingeniørs kvartal.

Hvorfor det forblir usynlig

Tre ting hindrer at dette viser seg som et problem noen eier.

Det første er at rapporten er riktig. En analytiker som skriver at visse applikasjonsdata ikke ble analysert, har dokumentert begrensningen korrekt. Ingenting i en kvalitetsgjennomgang vil markere det.

Det andre er at den uformelle omfangsregelen er fornuftig. Undersøk det verktøyet dekodet, undersøk det etterforskeren spesifikt spurte om, noter resten. Under en reell saksmengde er det den faglig riktige avgjørelsen, og den gir den samme innsnevringen av omfanget hver eneste gang.

Det tredje er at ingen vet hva som ble oversett. En etterforsker som aldri får vite at en samtale fantes, kan ikke spørre hvorfor den ikke var i rapporten. Fraværet er strukturelt uobserverbart.

Hva analytikere faktisk gjør med det

De gode gjør noe, og det skalerer ikke.

Noen åpner databasen for hånd, finner ut av skjemaet og skriver en spørring. Noen holder en personlig samling av skript. Noen kjenner en kollega i en annen tjeneste som har møtt denne applikasjonen før, og sender en e-post. I noen få laboratorier finnes det en person, vanligvis én, som er kjent for å være villig til å gjøre dette, og køen deres er den virkelige flaskehalsen.

Hver variant av dette har de samme to problemene. Det koster timer saken ikke kan avse, og forståelsen som produseres, er ikke varig. Den bor i hodet til én person eller i en kladdefil, og når den personen slutter, følger den med. Neste analytiker i neste tjeneste møter den samme applikasjonen om seks måneder og begynner på nytt.

Formen på en løsning

Hvis begrensningen er at noen må forstå et ukjent lagringsformat før innholdet kan leses, finnes det bare to veier ut. Gjøre den forståelsen billigere å produsere, eller gjøre den varig når den først er produsert.

Begge er tilgjengelige, og de forsterker hverandre.

Å produsere den billig er nå et håndterbart problem. Å finne ut hva en ukjent database er til, ut fra filstien, tabell- og kolonnenavnene og et utvalg av innholdet, er en resonneringsoppgave heller enn en mønstergjenkjenningsoppgave, og det er den typen oppgave nåværende modeller håndterer uvanlig godt. Resultatet er en mapping: en beskrivelse av hvordan denne kilden skal leses inn i feltene en visning forventer.

Det resultatet kan ikke bare stoles på, og det trenger det ikke. Valider det strukturelt, kjør det mot et utvalg av de virkelige dataene, og vis analytikeren en forhåndsvisning av faktiske poster. En mapping som misforsto kilden, produserer en forhåndsvisning full av vrøvl, noe som er åpenbart på sekunder. Analytikeren godtar den, retter den i en visuell editor, eller forkaster den.

Å gjøre den varig er den lettere halvdelen, og den mer verdifulle. En validert mapping er et lite artefakt som ikke inneholder bevis, bare beskrivelsen av hvordan en struktur skal leses. Den kan deles. Når et annet laboratorium åpner et segl som inneholder den samme applikasjonen, brukes den automatisk.

Det er der økonomien endrer seg. I dag gjentas arbeidet med å forstå en applikasjon i hver tjeneste som møter den, og går tapt hver gang. Delt betales det én gang.

Påstanden det er verdt å være varsom med

Det finnes en versjon av dette argumentet som går for langt, og det er verdt å markere grensen.

Automatisk mapping betyr ikke at en analytiker aldri må se på noe. Den betyr at den første forståelsen produseres av programvaren, og at analytikerens rolle blir gjennomgang heller enn konstruksjon. Noen mappinger vil være feil. Noen kilder er genuint tvetydige, og ingen mengde resonnering om et skjema vil avklare hva en kolonne betyr når navnet er f4 og innholdet er heltall.

Det som endres, er ikke standarden. Det er hvem som gjør første gjennomgang, og hvor lenge et laboratorium venter på den. I stedet for et kvartal tar det minutter, og resultatet er noe tjenesten beholder.