Myndigheder erkender fejl i Smittestop-appen

Illustration: weedezign, BigStock
Sundheds- og Ældreministeriet erkender, at en fejl i Smittestop-appen har betydet, at eksempelvis samboende personer ikke har fået advarsler om smitte fra hinanden.

Sundheds- og Ældreministeriet erkender nu, at der er en teknisk fejl i Danmarks nationale app til smitteopsporing.

Det skriver DR.

Den tekniske fejl har betydet, at de personer, som er meget nære kontakter, og som eksempelvis bor sammen, ikke har fået meddelelser om mulig smitterisiko fra hinanden. Ifølge ministeriet er problemet afgrænset til at omfatte de allertætteste kontakter, og derimod ikke dem, som man er sammen med i kortere tid.

Ministeriet har i den seneste uge forsøgt at teste appen, og nu vurderer ministeriet, at man har fundet en mulig årsag til problemerne. Derfor er der sat gang i at få bekræftet fejlen, inden arbejdet starter på at sende en opdatering ud.

Overfor DR påpeger teknisk projektleder i Sundheds- og Ældreministeriet Lene Ærbo, at det stadig er uvist, hvor lang tid fejlen har været i appen.

»Vi ved det ikke endnu. Der er løbende blevet lavet om i app’en – også i Google/Apple API’erne – så vi kan ikke fast sige nu, om den har været der fra start eller den er opstået for nyligt. Vi blev opmærksomme på det, efter at der begyndte at komme spørgsmål i supporten,« siger Lene Ærbo til DR.

Læs også: Smittestop-appen gav ingen varsel til familien, da Pia Allerslev fik corona

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Christian Nobel

.. men hvordan skal en app, som man hævder autonomt kan registrere om to BT forbindelser har været tættere på hinanden end 1½ meter i over 15 minutter, være i stand til at kunne registrere at de to forbindelser er meget nære kontakter?

Er der lidt sort magi og auratydning involveret?

  • 5
  • 2
#4 Niels Madsen

Et gæt kunne være at der er tale om telefoner som tidligere har været "paired", og derfor allerede "kender" hinanden. Uden adgang til sourcekoden kan man jo kun gisne om det, men måske routes pakkerene anderledes i software stacken i sådanne tilfælde, så de ikke havner hos corona app'en. De omgår måske en slags peer discovery funktionalitet som systemet kunne tænkes at bygge på.

I denne mulige forklaring indgår selvfølgelig ikke nogen tidsfaktor, men der kunne nok være et stort sammenfald i mellem folk som tilbringer meget tid sammen, og folk som har "pairet" deres telefoner med hinanden.

  • 3
  • 0
#6 Niels Madsen

Hvor tit pairer du din telefon med andre telefoner i husstanden - jeg kan ikke erindre at have gjort det på noget tidspunkt, som i aldrig.

Ikke så tit, men jeg tror da stadig at der er mange som fra tid til anden overfører fotos og video via Bluetooth. Om sådanne gensidige authenticationer af to telefoner over for hinanden helt formelt kaldes "pairing" i BT forstand ved jeg ikke.

Et andet bud kunne være at fejlen skyldes overflow i den variable som holder styr på hvor lang tid telefonerne har været tæt på hinanden. Men det ville alligevel være for pinligt til at kunne være sandt.

  • 3
  • 0
#7 Ditlev Petersen

Et andet bud kunne være at fejlen skyldes overflow i den variable som holder styr på hvor lang tid telefonerne har været tæt på hinanden. Men det ville alligevel være for pinligt til at kunne være sandt.

Eller bare klokkeslæt men ikke dato? Dvs. hvis to telefoner har "opholdt sig" tæt fra kl. 14 til kl. 12 næste dag, så er det mindre end 15 minutter.

Men både denne og den med de pairede telefoner kan jo godt forekomme så tit, at det giver en række fejl. Selv om det måske er sjældent. Sjældent gange mange = problem.

  • 5
  • 0
#9 Anders Høgsbro Madsen

Måske registrerer app'en kun første gang 2 givne telefoner har kontakt. Ved tætte/ofte kontakter vil det så typisk være så længe siden, at det er før den smittede udgjorde en smitterisiko. At man også sås dagen før er så ikke registreret.

Hvis det er årsagen kan det skyldes en fejl men kan måske også skyldes en - uhensigtsmæssig - optimering for at undgå mange registreringer af kontakter mellem de samme to telefoner.

I forhold til inspektion af kildekode og rebuild kan det jo vanskeliggøres af, at udviklerne måske ikke har adgang til kildekoden for de api'er fra Apple (og Google) der benyttes.

  • 2
  • 1
#12 Torben Rune

Et gæt kunne være at der er tale om telefoner som tidligere har været "paired", og derfor allerede "kender" hinanden.

Hvis man tager et kig i Apple/Google Bluetooth Specification, Contact Tracing kan den fejlkilde (pairing med kendt device) helt udelukkes.

Specifikationen ligger her: https://blog.google/documents/58/Contact_Tracing_-_Bluetooth_Specificati...

Contact Tracing kører BLE og har sin egen Bluetooth SIG UUID (0xFD6F). Det fremgår desuden at "Advertisements are to be non-connectable undirected", og da man har en unik UUID vil kun Contact Tracking applikationer have mulighed for at høre hinanden, helt uafhængugt af hvad telefonen i øvrigt foretager sig på Bluetooth.

Specifikationen udnyttes så i Exposure Notifications System (ENS), som stiller en række APIer til rådighed. Versionskontrollen med disse er i øvrigt meget omhyggelig og er dokumenteret her: https://developers.google.com/android/exposure-notifications/doc-change-log

  • 9
  • 0
#13 Morten Andersen

Alt det der med at man ikke kan teste for og undersøge fejl p.g.a. den super sikre protokol er naturligvis noget vrøvl. Det lyder jo som om de kan reproducere problemet. Og som udgiver af app'en og indehaver af koden kan de (burde tage max få timer) lave en debug udgave af app'en der udskriver alle ID'er der broadcastes samt alle ID'er der modtages og som tillige har vinduer til visning af den samlede lagrede liste af generede ID'er (som jo sendes ind til serveren ved spredning) samt alle observerede ID'er (som der tjekkes op imod når serveren kontaktes). Udover ID'erne lagres naturligvis observation/broadcast tidspunkt. Med denne information må det være muligt helt entydigt at fastlå hvor i processen det er gået galt så der ikke sendes notifikationer til (ud fra det oplyste) "nære kontakter". Er det fordi app'en ikke samler broadcasts op overhovedet fra de enheder (fordi telefonerne er paired som en foreslog)? Bliver det samlet op og lagret lokalt men forsvinder/overskrives igen f.eks. p.g.a. fejlberegning i.f.t. datoer eller lignende som andre foreslog? Eller bliver de lagret men ikke brugt til sammenligning ved check for smitte stop? Eller hvad er problemet. Pointen er at al relevant information problemfrit er tilgængelig for den der har udgivet app'en. Man kan lave et både større og mindre kompliceret setup til analyse af disse data men jeg ville forvente - som absolut minimum - en debug udgave der gav denne indsigt. Navnlig for en professionel app til 20 mio. der tjener et samfundskritisk formål. Det med API'erne harændret sig er også noget vrøvl - de har jo ikke ændret sig således at gamle udgaver af app'en ikke længere fungerer, så de kan frit teste enhver version af egen app de måtte ønske.

Bemærk at alt hvad jeg beskrev ovenfor så vidt jeg kan se kan lade sig gøre allerede med de officelle Google/Apple API'er og hvad de giver adgang til. Men man kan også tage det et ekstra lag og mocke disse API'er (igen i en debug app) så man har 100% kontrol over alle data som app'en behandler og fodres med og derfor nemt kan reproducere alle tænkelige scenarier, herunder kortvarige og langvarige kontakter og iøvrigt tillade automatisk test og continous integration. Også denne type integrationstests ville jeg tænke burde være helt standard for en app af denne kritikalitet. Men det er det måske ikke for et firma alle synes er fantastisk fordi de har lavet noget CRUD i en database.

Som jeg læser artiklen har de ikke fundet fejlen endnu men kan kun reproducere den "manuelt". Det med at det er nære kontakter må derved også hvile på gisninger. Men en forklaring kan som nævnt være beregninger i.f.t. timestamps. Forklaringen findes meget sandsynligt i området indenfor lagring og behandling/tjek af de indkommende ID'er.

  • 4
  • 1
#16 Jan Heisterberg

Nej, det er ikke normalt.

Den sædvanlige telefon app, på iPhone, bruger (naturligvis) grøn til opring og rød til afslut. Desuden, naturligvis, et pictogram. Andre må svare for Android.

Og Rejsekortet bruger blå til checkin og til checkud - hvilket er topmålet af svagt design. Der er end ikke et pictogram, men istedet små, sorte, bogstaver.

  • 2
  • 0
#17 Michael Erichsen

Her er så en IT-fejl. Den ansvarlige udpeges som den pågældende myndighed. Sådan er det ret konsekvent for tiden, når leverandøren hedder Netcompany.

Netcompany er efterhånden sluppet uden navns nævnelse, selv om de - naturligt nok - har haft lige så mange problemer som alle andre leverandører.

Men hvis det havde været KMD, DXC eller IBM, havde leverandørens navn stået i overskriften med en bemærkning om "endnu en...".

I 80'erne kunne IBM gå på vandet. Derefter var det CSC. Så KMD. Så NNIT. Og nu Netcompany.

Nu får vi se, hvorlænge deres usynlighed varer ved.

  • 5
  • 0
#18 Søren Laursen

Afstanden til kontakten skønnes ud fra signalstyrken af de modtagne Bluetooth LE beacons. Der er en betydelig variation telefoner imellem og reflektioner og dæmpning i omgivelserne øger også usikkerheden.

Vil man selv nørde med at undersøge forholdene, er der her en app, man kan donwloade:

https://medium.com/@christine_10050/bluetooth-le-signal-strength-b7c175a...

Andre undersøgelser:

https://arxiv.org/abs/2006.06822

https://arxiv.org/abs/2006.08543

  • 1
  • 0
#19 Andrew Rump

Er source code ikke i et versions styrings system, og dependencies styret af dependency management? Det burde være en simpel sag at trække en specifik version ud af bygge systemet og køre en test for at konstatere om en fejl er tilstede i en ældre version.

Problemet er at Smittestop-app'en kun er en del af systemet. Resten er det Exposure Notification API, som app'en kommunikere med, som Apple og Google har implementeret - og som de kan opdatere når de vil (ligesom (resten af) operativ systemet).

Der er ihvertifald 3 scenaier: 1) App'en har en fejl som ikke blev opdaget - så den har været der hele tiden. 2) App'en har en fejl som først blev synlig ved en API opdatering 3) API'et har en fejl/uhensigtsmæssighed (det vi populært kalder en feature), som ikke er blevet afdækket før opdateringen af API'et.

  • 0
  • 0
#21 Peter Kyllesbeck

Og Rejsekortet bruger blå til checkin og til checkud - hvilket er topmålet af svagt design. Der er end ikke et pictogram, men istedet små, sorte, bogstaver.

Hvilken app? Hvis det er standerne, du refererer til, er forklaringen givet her og andre steder utallige gange. Rød og grøn må ikke bruges på togperroner. (Blå var også problematisk i busser, men blev dog godkendt (kunne forveksles med udrykningslys))

  • 0
  • 0
#22 Morten Andersen

For det første skriver jeg jo ikke om at idriftsætte noget på basis af den antagelse vi taler om at teste for at finde ud af hvilken version af deres egen app der introducerede problemerne så synes "famous last words" er malplaceret. Men selv hvis API versioner skulle være en faktor er der jo intet til hinder for at teste det også... men jeg ville mene det er rimeligt i første omgang som minimum at teste forskellige versioner af egen app op imod nyeste release af Android og iOS med mindre der foreligger positiv viden om o/s er en faktor men det er ikke nævnt og som sagt kan dette også testes. Så køber ikke deres undskyldning!

  • 1
  • 1
Log ind eller Opret konto for at kommentere