Teledatasagen: Unikke IMEI-numre har været udsat for afrunding

Illustration: profit_image / bigstock
Konverteringsfejl i Rigspolitiets it-systemer har ført til, at efterforskere ikke umiddelbart har fået adgang til IMEI-numre, og at forkerte mobiltelefoner er blevet inddraget i efterforskningsarbejdet.

Først den ene fejl og så den anden fejl.

Konsulenthuset Deloitte peger nu på, at Rigspolitiets problemfyldte it-system til konvertering af teledata også har lavet fejl, når det har skulle levere oplysninger til politiets efterforskere om en mobiltelefons unikke identifikationsnummer - det såkaldte IMEI-nummer.

Det fremgår af en undersøgelse, som konsulenthuset har udarbejdet for Rigspolitiet og Rigsadvokaten. Undersøgelsen har haft til formål at afklare den usikkerhed, der er opstået om anvendelsen af teledata i straffesager.

I rapporten konkluderer Deloitte, at Rigspolitiets it-system i flere tilfælde har fejlkonverteret og fejlformateret IMEI-numre.

Det har betydet, at der er blevet lavet mastesug på forkerte mobiltelefoner, og at der er IMEI-numre, som politiets ansatte umiddelbart ikke har modtaget, når de har været i gang med deres egne efterforskninger.

Fejlformatering og tab

Til undersøgelsen har Deloitte gennemgået den rådata, som teleselskaberne har sendt til Rigspolitiets konverteringssystem i perioden fra 2011 til 2019.

Derefter har konsulenthuset sammenlignet rådata med de konverterede data, som er kommet ud af Rigspolitiets system i samme periode.

I alt har konsulenter fundet frem til 2.043 teledataudtræk fra landets selskaber - såkaldte rekvisitioner - hvor Rigspolitiets it-system har lavet fejl, så der er opstået uoverensstemmelser mellem IMEI-numrene i rådata og i den konverterede data.

Deloitte peger blandt andet på, at der er IMEI-numre, som er blevet tabt i konverteringsprocessen, og at IMEI-numrene er blevet vist i forskelligt format.

Fejlformateringen har ifølge Deloitte ført til, at identifikationsnummeret »ikke er umiddelbart tilgængeligt for efterforskeren i en given sag.«

Konsulenthusets repræsentanter pointer dog, at efterforskerne i disse tilfælde stadig vil have mulighed for at finde IMEI-nummeret ved at gå til Rigspolitiet og bede om at få udleveret rådataen, og derfor mener Deloitte ikke, at denne fejltype har en betydning i praksis.

Afrunding kan have ført til misforståelser

Konsulenterne har også fundet en anden fejl. I nogle af de konverterede IMEI-numre er de sidste to tal blevet afrundet til hele nærmeste tier.

Fordi IMEI-numrene er unikke og bruges til at identificere en bestemt enhed, kan afrundingsfejlen betyde, at der er sket misforståelser i forhold til, at for eksempel en irrelevant telefon er blevet inddraget i en bestemt sag.

»Fejlen kan derfor betyde, at en anden enhed end den faktiske involverede inddrages i en given sag,« skriver Deloitte.

Få numre påvirket

Afrundingsproblemet kan som sagt have konsekvenser, men ifølge Rigspolitiet og Deloitte er det et fåtal, der er blevet påvirket af dette problem.

Det skyldes, at IMEI-numre kan bestå af op til 16 cifre, men det er kun de første 14, der anvendes, oplyser Rigspolitiet i en redegørelse om sagen (side 71).

Ifølge Deloitte er det langt størstedelen - 99 procent - af IMEI-numrene, der har 16 cifre, og derfor vil afrundingen af de to sidste cifre ikke have afgørende konsekvenser i disse tilfælde.

Men i de tilfælde, hvor nogle af de 14 vigtige cifre kan være blevet ændret på grund af afrundet, så kan det have haft konsekvenser, påpeger Deloitte.

»I det begrænsede antal rekvisitioner, hvor afrundingen kan have påvirket de 14 anvendte cifre, kan fejlen have medført, at en anden enhed end den faktisk involverede inddrages i en sag, f.eks. i forlængelse af et mastesug,« skriver konsulenterne.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (23)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jan Heisterberg
  • hvordan fejlene kan have eksisteret siden 2012 og først - ifølge det oplyste - påpeges EF een politikreds i januar 2018 ?

Vil det vise sig, at langt, langt de fleste oplysninger er uden betydning (og åbenlyse fejl ikke opdages) eller har brugerne - dvs. Forsvarer og Anklagere OGSÅ svigtet ?

  • 6
  • 0
Hans Nielsen

Så det er Microsoft skyld :-)
Det vil politiet da hurtigt få det spindet til.

Hvis det er bare lidt om snakken.

Rigtigt god overskift, v2 må gerne bruge den.

Men håber nu ikke, at det er hvad der er sket.
Med det kan vel også være sket lokalt, tænkt på den måde at personen som har søgt, har brugt et afrundet IMEI-nummer.

Men det vil vel også give mange positiver ?

Personen har været på gerningsstedet, på gerningstidspunktet... Samt i Skagen, Aahus og Køge.

  • 2
  • 0
Mogens Lysemose

It har skylden: heltal/integers fås i forskellige bitlængder (typisk 8,16,32,64 bits) og signed/unsigned. Hvis den stakkels uvidende inkompetente programmør/systemkonsulent så tror at en lang tekst fuld af af tal er et heltal og gemmer den som sådan uden at sikre sig at der er plads, så sker et tab af præcision ("afrunding"). Altså er det IT der har skylden hvilket klart fritager den uvidende & inkompetente programmør/systemkonsulent for alt ansvar...

;)

  • 4
  • 0
Hans Nielsen

At bruge csv til noget vigtigt er at bede om problemer:


Vil nu ikke give dig helt ret, hvis man har styr på data, så er det da lige som med en text fil, det mest simple.
Dermed også det som giver færest fejl muligheder.

Hvis du tager et rigtigt database format, så kan det da først gå helt galt. Når man tænker på versioner, patche, små fejl samt måske inlejret 3parts som micosoft basic.

Men som med text filer, så skal man igen ikke bruge Micosoft - Her tænkes der på notepad. Som kan gemme en text fil i et "format", mens det konsekvens vises i et andet.

Så læren må være ikke at bruge Microsoft produkter, men noget som overholder standarter. Og nej der skal ikke grines.

Personligt tror jeg en rigtigt database fil er farligt, da der jo er stor forskled på data, og visning. I samme felt kan man jo bare prøve at se hvordan nooget ser ud, hvis man vælger et af de utalige dato formater ?
Som vel også er en vigtigt del her.

Så tror jeg det er bedre at have data i en text fil som csv er, hvis man vel at mærke har styr på data, da det er gennemskuligt. Det er vel også grunden til at man bruger det til udvæksling mellem forskellige systemer.

  • 0
  • 1
Claus Bruun

*Systemerne og den tilhørende infrastruktur kan kort beskrives som utidssvarende og kompleks og omfatter en række forskelige systemer, integrationer mellem systemer og dataoverførsler. IT-miljøet har løbende været udviklet i takt med at nye dataformater, behov mv. er opstået. Udviklingen kan bedst beskrives som ’knopskydning’.

*Undersøgelsen viser, at den samlede systemplatform, herunder procedurer for udvikling og drift, er på et helt utilstrækkeligt niveau.

Jeg er ikke overrasket :-)

  • 3
  • 1
Magnus Jørgensen
magnus@desktop:~$ node  
> 0xffffffffffffff00 == 0xffffffffffffffff  
true
magnus@desktop:~$ python  
Python 2.7.16 (default, Jul  9 2019, 16:43:02)   
[GCC 8.3.0] on linux2  
Type "help", "copyright", "credits" or "license" for more information.  
>>> 0xffffffffffffff00 == 0xffffffffffffffff  
False
  • 0
  • 0
Mogens Lysemose

hvis man har styr på data, så er det da lige som med en text fil, det mest simple. Dermed også det som giver færest fejl muligheder.
...
ikke at bruge Microsoft produkter, men
Noget som overholder standarter. Og nej der skal ikke grines.

Er der en standard for tekstiler???
Skal tegnsættet være ascii, utf-8 eller utf-16 eller...?
Skal linjeskift være CR LF som på Windows, LF som på UNIX eller (LF?) CR som på mac?
Hvordan håndteres linjeskift og komma i tekstværdier?
Skal decimaltal være med komma som på europæisk eller punktum som på amerikansk?
Er exponentiel notation tilladt for bedst præcision?

At det er simpelthen menneskeligt læsbart er vi enige om men ikke at det er et entydigt og fejlsikkert format.

CSV bruges oftest til import og export imellem forskellige systemer, hvor afsender og modtager tit ikke har styr på ovenstående.

  • 8
  • 0
Hans Nielsen

https://www.ibm.com/support/knowledgecenter/en/SSEP7J_11.1.0/com.ibm.swg...

"At det er simpelthen menneskeligt læsbart er vi enige om men ikke at det er et entydigt og fejlsikkert format."

Hvis vi snakker meget mere end æ,ø,å og simple coloner og rækker så mener jeg ikke at former af CSV (coma, tabulator,..) er et godt format, men det er stadigt det som skal vælges først, hvis vi taler data udvæksling.

Selv med dine pointer om fejl muligheder, så er det langt det bedste format til at håndtere data udvæksling.
Da man jo også manulet kan kontrolere data, og validere det. Det kan væres svært i andre formater.

Man skal vel altid have samme styr på data som land, valuta, tid, dato,.. i et regneark, som i CSV eller programering.

I programerings sprøgsmål har jeg altid været lidt doven (er ikke programmør og bliver det aldrig) og kun brugt 2 typer.
int til løkke, tæller og long_64 til alt andet. Så behøves man ikke altid at tænke sig om.

Der er sikkert mange andre, langt bedre og dokumenteret løsninger. Men når jeg selv bruger CSV typer, så bruger jeg selv de første 3 eller 4 colonner til verifisering og oplysning, også for at gøre det nemt for mig selv, når jeg skal se hvad noget er efter 10-20 år.
Den 4 kolone indeholder et eksemple, som jeg typisk skriver ud, sammen med 1 kolone, Som kontrol.
Som i dette simple eksemple.

1 Kolonne navn på kolonne : Fornavn EfterNavn Født
2 kolone Forklaring : fornavn på personer, efter navn på person, fødselsår
3 kolone til format og evt uddybende note note : text test tal-fødselsår som jeg har fået oplyst ifølge dåbsatest
4 Anne Magrete 1934

Udskrift
Fornavn:Anne
Efternavn:Magrete
Født:1934

Det vigtigste i den her sammenhæng, er vel at man også om 10-30 år kan læse dette format korrekt. Måske skal man gætte sig til at der er brugt Dansk tegnsæt. Det vil ikke altid være tilfældet med et andet format.
Så burde man også kunne gøre det nu.

Men derfor er jeg ening i nogle af dine betrakninger, at politiet i denne sag har være nogle amatøragtigt klamphukker.
OG selv om minister mener noget andet.
Så bør alle som har været inden over denne sag, og ikke har hånteret det rigtigt, de skal fyres.
Uden løn og pention hvis det er bevis for bevis fejl og manger, hvis der er muligt.
Det vil virke uretfædigt, og er det sikkert. Men man må her offre den enkelt for helhede for

At vise at det er konsekvenser hvis man ikke passer sit arbejde ordenligt

Samt at vise offenligheden den samme, så tilid til systemet kan genoprettes
Her tænkes der ikke på mobildata, men det offenlig..

PS. Så blev det igen for langt og rodet.

  • 1
  • 1
Jan Heisterberg

Jeg tror denne debat er afsporet af kommentar nr. 2: "Sådan går det når man bruger Excel", idet mange efterfølgende kommentarer uden videre forfølger dette "spor".

CSV er et gammelt format, som har været bekvemt og simpelt til dataudveksling. Mange programmer kan genere CSV, og mange kan læse / skabe CSV - blandt andet Excel (men det er bare eet eksempel).
Blandt de problemer jeg normalt møder er især decimal-angivelsen med "." eller "," - men det retter jeg så manuelt; også datoer kan give problemer.

HVIS de rette, definerede, specifikationer lægges til grund, så er der ikke noget galt med CSV-formatet.
HVIS man bruger formatet hovedløst, så kan det gå galt på mange måder.

I den konkrete sag synes eet af problemerne især at være, at der aldrig er lavet en definition af feltindholdets format og indhold (eksempel IMEI's længde eller positionernes standard). Yderligere er der vist forskelle på felternes antal og rækkefølge (de 100 formater i tidens løb).
Intet af dette har med CSV at gøre - det har med dårlig specifikation / standard at gøre.

At der så yderligere ikke - ifølge det oplyste - er benyttet nogen form for datamængde-kontrol (antal rækker, antal tegn totalt) føjer jo kun spot til skade - der blev mistet 5,8% af rækkerne i rådata.

Derfor, som skrevet andetsteds, det virker som om en 13-årig skoleelev, uden synderlig (naturligvis) erfaring har startet det her: "Send os bare en CSV-fil ....". Og 100 forskellige formater senere, så .....
De bedste beskrivende superlativer ville måske medføre en anklage for injurier og ærekrænkelse.......

  • 9
  • 0
Mogens Lysemose

Jeg tror denne debat er afsporet af kommentar nr. 2: "Sådan går det når man bruger Excel",


Præcis. Det var ikke en værdiskabende kommentar. Excel har mange faldgruber og mange kvaliteter; lige som mange andre værktøjer.

HVIS de rette, definerede, specifikationer lægges til grund, så er der ikke noget galt med CSV-formatet.

Præcis. Men der er bare bedre standarder til det - f.eks. XML, som stadig er programmør-læsbart. Og selv Excel og de fleste andre værktøjer kan åbne XML-filer.

Selv XML-datoformatet er entydigt defineret i XML
(f.eks. 2019-10-07T13:14:55) og alle ulovlige tegn kan og skal escapes.

problemerne især at være, at der aldrig er lavet en definition af feltindholdets format og indhold (eksempel IMEI's længde eller positionernes standard). Yderligere er der vist forskelle på felternes antal og rækkefølge (de 100 formater i tidens løb).
Intet af dette har med CSV at gøre - det har med dårlig specifikation / standard at gøre.

Præcis! Og så kom vi på sporet igen!

  • 4
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize