Myndigheder erkender fejl i Smittestop-appen

25. september 2020 kl. 09:1122
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.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

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.

Artiklen fortsætter efter annoncen

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.

22 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
22
28. september 2020 kl. 21:14

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!

19
28. september 2020 kl. 09:40

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.
18
26. september 2020 kl. 12:11

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-b7c175af9e54

Andre undersøgelser:

https://arxiv.org/abs/2006.06822

https://arxiv.org/abs/2006.08543

17
26. september 2020 kl. 11:06

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.

16
26. september 2020 kl. 10:15

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.

14
25. september 2020 kl. 19:05

ja, den er "arvet" fra Rejsekortet - utroligt men sandt.

Jeg konstaterer, at aktivering sker med en RØD knap. er de farveblinde eller bare dumme ?

Hvem kender andre apps som aktiveres med en RØD knap......

13
25. september 2020 kl. 18:01

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.

12
25. september 2020 kl. 17:59

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_Specification_v1.1_RYGZbKW.pdf

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

10
25. september 2020 kl. 16:17

at den var gratis ... nå nej ...

9
25. september 2020 kl. 14:20

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.

8
25. september 2020 kl. 13:05

Jeg må nok erkende at appen virker ubrugelig, lige før man vil slette den, men så igen, så er man vel en god borger... Hvis en med Corona står 1,5m tæt på mig i 15 minutter, så er jeg nok smittet.

7
25. september 2020 kl. 13:00

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.

6
25. september 2020 kl. 12:22

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.

4
25. september 2020 kl. 11:52

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
25. september 2020 kl. 11:24

.. 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?

1
25. september 2020 kl. 10:57

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.