A lefedettségnek nem szabad egy szállítói kiadási ciklustól függnie

Van egy pillanat a digitális kriminalisztikai vizsgálatban, amelyet senki sem ír bele az eljárási kézikönyvbe. Egy vizsgáló megnyit egy kinyerést, talál egy alkalmazást, amelyet nem ismer, és megnézi, támogatja-e az eszköze. Nem támogatja. Az adat ott van, teljesen jelen, egy adatbázisban, amelynek a fájlnevét látja. És a válasz arra, hogy olvasható-e: ebben a negyedévben nem.

Ezt a pillanatot rendszerint támogatási kérdésként kezelik. Valaki jegyet nyit. Talán a szállító felveszi egy hátralékra, talán egy verzió megérkezik hat hónap múlva, talán az alkalmazás regionálisan elég népszerű ahhoz, hogy megérje egy mérnök idejét, és talán nem. Közben az ügyön őrzési határidő fut.

Ez nem támogatási kérdés. Szerkezeti tulajdonsága annak, ahogyan az iparág úgy döntött, hogy dolgozik, és ha egyszer így látja, a laboratórium napi bosszúságának nagy része egy okról szól.

A döntés máshol születik

Minden elterjedt kriminalisztikai elemző eszköz ugyanígy működik. Valaki a szállítónál visszafejti egy alkalmazás tárolási formátumát, értelmezőt ír hozzá, teszteli, és egy kiadásban adja ki. A vizsgáló ennek a munkának az eredményét képességként kapja meg.

Ez valóban nehéz mérnöki munka, és akik végzik, jók benne. A probléma nem a hozzáértés. A probléma az, hogy egy vizsgálat legkövetkezményesebb döntését, azt, hogy mely adat olvasható egyáltalán, olyan valaki kezébe teszi, aki nem tudja, hogy az ügy létezik.

Ez a személy ésszerű kereskedelmi ítéletet hoz. Azt nézi, hány ügyfél fog találkozni ezzel az alkalmazással, mennyire stabil a formátuma, mennyi mérnöki munkát igényel. Egy kétszázmillió felhasználós üzenetküldő alkalmazás nyilvánvalóan megéri a munkát. Egy regionális közösségi platform négyszázezer felhasználóval, pontosan abban a régióban összpontosulva, ahol az Ön szervezett bűnözői csoportja működik, sokkal nehezebb üzleti eset. A szállító helyzetéből a megvalósítás elutasítása helyes. Az Ön helyzetéből, a kinyerést a kezében tartva, ez az egész ügy.

A verziók a probléma nagyobbik fele

A nem támogatott alkalmazás története az, amelyet elmesélnek, de alulbecsüli a kérdést. A gyakoribb hiba finomabb: egy támogatott alkalmazás, amelynek a tárolási elrendezése megváltozott.

Egy alkalmazás frissül. Átrendez egy táblát, áthelyez egy fájlt, megváltoztatja, hogyan kódol egy időbélyeget. Az értelmezőt az előző verzióhoz írták, és most semmit sem ad vissza, vagy ami rosszabb, valami hihetőt és téveset ad vissza. Az eszköz támogatottként jelenti az alkalmazást, mert az is, és a vizsgálónak kell észrevennie, hogy a kimenet vékony.

Az alkalmazások kiadási ciklusait hetekben mérik. A kriminalisztikai eszközök kiadási ciklusait hónapokban. Ez a rés soha nem záródik, és senkinek sem a hibája. Számtan.

Mibe kerül, azokban a fogalmakban, amelyek számítanak

A költség rendszerint nem sikertelen vizsgálatként jelenik meg. Hatókörszűkülésként jelenik meg, csendben.

Egy vizsgáló, akinek három hete és negyven pecsétje van, nem tölt két napot egy ismeretlen SQLite-adatbázis kézi olvasásával, mellette nyitott hexaszerkesztővel, még ha meg is tehetné. Azt vizsgálja meg, amit az eszköz dekódolt, arról írja a jelentést, és a többit nem elemzettként jegyzi fel. Ez védhető szakmai döntés. Ez az a módja is annak, hogy a létező bizonyíték, egy olyan eszközön, amely már a szolgálatnál van, egy már nyitott ügyben, végül soha ne kerüljön megnézésre.

Szorozza meg egy ügyteherrel, és megkapja azt a számot, amely miatt a laboratóriumvezetők valójában aggódnak: a lefoglalt adatnak az az aránya, amelyet soha nem vizsgálnak meg. Ez nem előszűrési hiba. Lefedettségi hiba, amelyet előszűrésként soroltak át.

Az alternatíva kényelmetlen, de egyszerű

Ha a szűk keresztmetszet az, hogy az értelmezőket egy szállító írja, előre, az általa választott alkalmazásokhoz, akkor a javítás az, hogy ne legyen többé követelmény, hogy egy ember a szállítónál előre megírja őket.

Ez ma technikailag úgy megvalósítható, ahogyan öt évvel ezelőtt nem volt. Annak felismerése, mire való egy ismeretlen adatbázis, mit tartalmaznak a táblái, és hogyan képeződnek le azokra a fogalmakra, amelyekkel egy nyomozó dolgozik, beszélgetésekre, kapcsolatokra, helyszínekre, következtetési feladat a fájlútvonalak, a séma és a tartalom együttese felett. Pontosan az a fajta feladat, amelyben a generatív modellek szokatlanul jók, az osztályozók pedig nem.

A kézenfekvő ellenvetés a helyes. Nem hagyhatja, hogy egy modell döntse el, hogyan értelmezik a bizonyítékot, és egyszerűen megbízhat az eredményben. Ne tegye. Generálja a leképezést, ellenőrizze szerkezetileg, futtassa a valódi adatok egy mintáján, és mutassa meg a vizsgálónak a tényleges rekordok előnézetét, mielőtt bármit alkalmaznának. Ha a leképezés félreértette a forrást, az azonnal látható, mert az előnézet tele van értelmetlenséggel. A vizsgáló elfogadja, javítja egy vizuális szerkesztőben, vagy eldobja.

Ami változik, nem a bizonyítás mércéje. A vizsgáló továbbra is ellenőriz, és semmi sem kerül jelentésbe ellenőrizetlenül. Ami változik, az az, kinek kell elvégeznie az első megértés munkáját, és mikor történhet meg. Megtörténhet azon a napon, amikor az ügynek szüksége van rá, nem abban a negyedévben, amelyre egy szállító ütemezte.

Miért érdemes ezt hangosan kimondani

Minden laboratórium, amellyel beszéltünk, ugyanannak a történetnek egy változatát mondja, és mindegyik úgy meséli, mintha helyi bosszúság volna. Nem helyi. Ugyanaz a korlát minden szolgálatban, minden országban, és azért létezik, mert egy architekturális választás, amelyet az egész iparág korán meghozott, és soha nem vizsgált felül.

A megnevezése megváltoztatja, mit kér. Az a szolgálat, amely úgy gondolja, támogatási problémája van, gyorsabb kiadásokat kér a szállítójától, ami olyan kérés, amelyet senki sem tud teljesíteni. Az a szolgálat, amely felismeri a szerkezeti problémát, más kérdést tesz fel: mi kellene ahhoz, hogy a lefedettség ne legyen többé olyasmi, amire várunk.

Ez az a kérdés, amelynek megválaszolására a VERA épült, és ez az oka annak, hogy inkább a tételt érveljük, mint hogy a terméket írjuk le.