

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.
- emailE-mail
- linkKopier link

...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.
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
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!
- more_vert
- insert_linkKopier link
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))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.
- more_vert
- insert_linkKopier link
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.
Famous last words ;-) enhver opdatering kan indeholde nye fejl eller afdække uhensigtmæssigheder/features.
- more_vert
- insert_linkKopier link
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:
- App'en har en fejl som ikke blev opdaget - så den har været der hele tiden.
- App'en har en fejl som først blev synlig ved en API opdatering
- 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.
- more_vert
- insert_linkKopier link
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:
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
Det er da vist meget normalt.Hvem kender andre apps som aktiveres med en RØD knap......
Men nu er jeg også rød-grøn farveblind, så du skal nok ikke tillægge mine observationer den store værdi.
- more_vert
- insert_linkKopier link
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......
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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
- more_vert
- insert_linkKopier link
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.
Protokollen lavet sådan, at ingen - heller ikke den anden telefon - i praksis kan sammenkæde to forskellige id-er før der foreligger en smitte-melding, og de id-er skifter hvert 10-15 minutter.
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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.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.
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.
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
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.Et gæt kunne være at der er tale om telefoner som tidligere har været "paired"
Jeg pairer til mit headset/handsfree, og til nød kan jeg finde på at paire til min computer for at fiske billeder ud, men ellers - nej.
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link
.. 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?
- more_vert
- insert_linkKopier link
Så vidt jeg har læst andetsteds er det netop dette, som er et problem.konstatere om en fejl
- more_vert
- insert_linkKopier link
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.
- more_vert
- insert_linkKopier link