Kattavuuden ei pitäisi riippua toimittajan julkaisusyklistä

Digitaalisessa rikosteknisessä tutkinnassa on hetki, jota kukaan ei kirjoita menettelyohjeeseen. Analyytikko avaa poiminnan, löytää sovelluksen, jota ei tunnista, ja tarkistaa, tukeeko hänen työkalunsa sitä. Ei tue. Aineisto on siinä, kokonaan läsnä, tietokannassa, jonka tiedostonimen hän näkee. Ja vastaus siihen, voidaanko se lukea, on: ei tällä neljänneksellä.

Tuota hetkeä pidetään tavallisesti tukiasiana. Joku tekee tukipyynnön. Ehkä toimittaja lisää sen kehitysjonoon, ehkä versio saapuu kuuden kuukauden kuluttua, ehkä sovellus on alueellisesti tarpeeksi suosittu ollakseen insinöörin ajan arvoinen ja ehkä ei. Sillä välin asialla on säilytysmääräaikansa.

Tämä ei ole tukiasia. Se on rakenteellinen ominaisuus siinä, miten ala päätti työskennellä, ja kun sen näkee niin, suuri osa laboratorion päivittäisestä turhautumisesta osoittautuu yhden syyn aiheuttamaksi.

Päätös tehdään muualla

Jokainen valtavirran rikostekninen analyysityökalu toimii samalla tavalla. Joku toimittajalla takaisinmallintaa sovelluksen tallennusmuodon, kirjoittaa sille jäsentimen, testaa sen ja toimittaa sen julkaisussa. Analyytikko saa tuon työn tuloksen kykyinä.

Tämä on aidosti vaikeaa insinöörityötä, ja sitä tekevät ihmiset ovat siinä hyviä. Ongelma ei ole osaaminen. Ongelma on, että se panee tutkinnan seurauksellisimman päätöksen, sen, mikä aineisto ylipäätään voidaan lukea, jonkun käsiin, joka ei tiedä asian olevan olemassa.

Tuo henkilö tekee kohtuullisen kaupallisen arvion. Hän katsoo, kuinka moni asiakas kohtaa tämän sovelluksen, kuinka vakaa sen muoto on, kuinka paljon insinöörityötä se vaatii. Viestisovellus, jolla on kaksisataa miljoonaa käyttäjää, on ilmeisesti työn arvoinen. Alueellinen sosiaalinen alusta, jolla on neljäsataatuhatta käyttäjää, keskittyneenä juuri siihen alueeseen, jossa järjestäytynyt rikollisryhmänne toimii, on paljon vaikeampi liiketoimintaperuste. Toimittajan näkökulmasta sen toteuttamatta jättäminen on oikein. Teidän näkökulmastanne, poiminta kädessä, se on koko asia.

Versiot ovat ongelman suurempi puolisko

Tukemattoman sovelluksen tarina on se, joka kerrotaan, mutta se vähättelee ongelmaa. Yleisempi epäonnistuminen on hienovaraisempi: tuettu sovellus, jonka tallennusasettelu muuttui.

Sovellus päivittyy. Se järjestää taulun uudelleen, siirtää tiedoston, muuttaa tapaa, jolla se koodaa aikaleiman. Jäsennin kirjoitettiin edellistä versiota vasten, ja nyt se ei palauta mitään tai, pahempaa, palauttaa jotakin uskottavaa ja väärää. Työkalu ilmoittaa sovelluksen tuetuksi, koska se on, ja analyytikon on huomattava, että tuotos on ohut.

Sovellusten julkaisusyklit mitataan viikoissa. Rikosteknisten työkalujen julkaisusyklit mitataan kuukausissa. Tuo väli ei koskaan sulkeudu, eikä se ole kenenkään syy. Se on aritmetiikkaa.

Mitä se maksaa, niillä ehdoilla, joilla on merkitystä

Kustannus ei tavallisesti näy epäonnistuneena tutkintana. Se näkyy hiljaisena rajauksen kaventumisena.

Analyytikko, jolla on kolme viikkoa ja neljäkymmentä sinettiä, ei käytä kahta päivää lukemalla käsin vierasta SQLite-tietokantaa heksaeditori auki vieressä, vaikka hän voisi. Hän tutkii sen, minkä työkalu tulkitsi, kirjoittaa raportin siitä ja merkitsee loput analysoimattomiksi. Se on puolustettavissa oleva ammatillinen päätös. Se on myös se tapa, jolla todistusaineisto, joka on olemassa, laitteella, joka yksiköllä jo on, asiassa, joka on jo auki, päätyy siihen, ettei sitä koskaan katsota.

Kertokaa se asiamäärällä, ja saatte luvun, josta laboratorion johtajat oikeasti huolestuvat: sen osuuden takavarikoidusta aineistosta, jota ei koskaan tutkita. Se ei ole esikarsinnan epäonnistuminen. Se on kattavuuden epäonnistuminen, joka on luokiteltu uudelleen esikarsinnaksi.

Vaihtoehto on epämukava mutta yksinkertainen

Jos pullonkaula on se, että jäsentimet kirjoittaa toimittaja etukäteen, sovelluksille, jotka se valitsi, korjaus on lakata vaatimasta, että ihminen toimittajalla kirjoittaa ne etukäteen.

Tämä on nyt teknisesti mahdollista tavalla, jolla se ei ollut viisi vuotta sitten. Sen tunnistaminen, mihin vieras tietokanta on tarkoitettu, mitä sen taulut sisältävät ja miten ne vastaavat käsitteitä, joiden kanssa tutkija työskentelee, keskusteluja, yhteystietoja, sijainteja, on päättelytehtävä tiedostopolkujen, skeeman ja sisällön yli yhdessä. Se on juuri sellainen tehtävä, jossa generatiiviset mallit ovat poikkeuksellisen hyviä ja luokittelijat eivät.

Ilmeinen vastaväite on oikea. Mallin ei voi antaa päättää, miten todistusaineistoa tulkitaan, ja vain luottaa tulokseen. Älkää siis antako. Tuottakaa kartoitus, tarkistakaa se rakenteellisesti, ajakaa se otosta vasten todellisesta aineistosta ja näyttäkää analyytikolle esikatselu todellisista tietueista, ennen kuin mitään sovelletaan. Jos kartoitus on ymmärtänyt lähteen väärin, se näkyy heti, koska esikatselu on täynnä hölynpölyä. Analyytikko hyväksyy sen, korjaa sen visuaalisessa editorissa tai hylkää sen.

Mikä muuttuu, ei ole näytön taso. Analyytikko tarkistaa yhä, eikä mikään päädy raporttiin tarkistamatta. Mikä muuttuu, on se, kenen on tehtävä ensimmäisen ymmärtämisen työ ja milloin se voi tapahtua. Se voi tapahtua sinä päivänä, jona asia sitä tarvitsee, eikä sillä neljänneksellä, jolle toimittaja sen aikataulutti.

Miksi tämä kannattaa sanoa ääneen

Jokaisella laboratoriolla, jonka kanssa olemme puhuneet, on versio samasta tarinasta, ja jokainen niistä kertoo sen kuin se olisi paikallinen ärsytys. Se ei ole paikallinen. Se on sama rajoite jokaisessa yksikössä jokaisessa maassa, ja se on olemassa, koska koko ala teki varhain arkkitehtuurivalinnan eikä palannut siihen.

Sen nimeäminen muuttaa sen, mitä pyydätte. Yksikkö, joka luulee, että sillä on tukiongelma, pyytää toimittajaltaan nopeampia julkaisuja, mikä on pyyntö, jota kukaan ei voi myöntää. Yksikkö, joka tunnistaa rakenteellisen ongelman, kysyy toisen kysymyksen: mitä vaadittaisiin, jotta kattavuus lakkaisi olemasta jotakin, jota odotamme.

Se on kysymys, johon vastaamaan VERA rakennettiin, ja se on syy, miksi väittelisimme mieluummin teesistä kuin kuvaisimme tuotetta.