Danskere, der har en Android-telefon med den danske Smittestop-app installeret i lommen, kan komme ud for, at applikationen har problemer med at hente data om smitteeksponeringer.
Det skriver Computerworld, der har fået problematikken bekræftet hos Sundhedsministeriet.
Det betyder i værste fald, at danskere, med kombinationen af en installeret Smittestop-app og en Android-telefon, kan risikere gå glip af notifikationer om, at de har været eksponeret for corona-smitte.
Dermed kan de gå rundt i uvidenhed om, at de har befundet sig tæt på en, der nu er konstateret smittet, og dermed bliver app'ens reelle funktion været særdeles tvivlsom.
Koblet op på Europa
Udmeldingen fra Sundhedsministeriet bliver ikke mindre kritisk set i lyset af, at den dansk applikation for kort tid siden officielt blev koblet op på den fælleseuropæiske gateway, der skal sikre, at de europæiske landes nationale smitteapps kan "tale sammen".
Men effekten af det samarbejde kan måske også blive begrænset, hvis app'en ikke modtager og videreformidler information om, at man har været eksponeret for smitte via eksempelvis tyskeren, der stod foran i køen til pølser på færgen, der nu er smittet.
- Denne artikel
- Nu virker Smittestop i Tyskland: Danmark er koblet på fælleseuropæisk gateway for corona-app's
- Blev lanceret som "pro bono": Smittestop-appen koster 35 millioner kroner i 2020 - prisen for næste år er ukendt
- Beslutningen er taget: Dansk corona-app kobles til tværeuropæisk løsning i november
- Smittestop-appen gav ingen varsel til familien, da Pia Allerslev fik corona
- Hver ottende corona-smittet bruger Smittestop-app
- Mange danskere udelukket fra Smittestop-app
- 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
Hej René
Jeg arbejder som journalist for det nystartede techmedie Radar. Jeg vil høre, om du vil tale med mig om dine erfaringer fra IT-branchen i forhold til, hvem der vinder udbud?
Min mail er mats@radarmedia.dk, men du kan også skrive på mit telefonnummer 24917900.
Venlig hilsen Mats Magnussen
I praktis viser det sig dog at man kan lave to fuldstændig ens GET requests og først få et 204 svar og derefter en 200 med data
Ser du noget mønster? Meldes der fx konsekvent 204 fra midnat til kl 8? Eller er der en 50/50 fordeling på 200 og 204? i så fald kunne det jo være at der er to servere og data kun er tilgængelig på den ene.
Ikke sikker på hvordan din log-fil skal læses da sortering ser ud til at gå i begge retninger. Har du mulighed for at logge http request GET og http response code med prefixet tidsstempel?
Eksempel:
2020-11-19 18:00:00 GET /API/v2/.._1.zip 200 2020-11-19 18:00:10 GET /API/v2/.. 2.zip 200 2020-11-19 18:00:20 GET /API/v2/.._3.zip 204
Den gamle API til Smitte|Stop-app'en (v1) har jeg løbende scrapet for "Temporary Exposure Key" (TEKs) og den har været nogenlunde stabil. Jeg tæller 6 timeouts i løbet den sidste måned (jeg laver ca 14 GET requests hver halve time).
Den nye udgave af appen henter TEKs fra et nyt endpoint ("v2"). Som jeg læser deres kode [1], så leder app'en efter et "204 No Content"-svar og så ved den at der ikke er flere batches af TEKs den forespurgte dag - så langt så godt! I praktis viser det sig dog at man kan lave to fuldstændig ens GET requests og først få et 204 svar og derefter en 200 med data!
Exempel: app'en kalder "GET 2020-11-15_1_dk.zip" (første "dk" batch fra 2020-11-15) og får "204", den tror at der ikke findes nogle batches fra 2020-11-15 og springe en hel dag over indtil næste sync...
Det virker som en fejl, men jeg har ikke noget godt gæt på hvad der går galt (caching måske?). Hvis der er nogen som vil grave videre i det, så har jeg en fil med lidt output her: https://xn--sb-lka.org/smittestop/v2-output.log
Gid der dog var et sted man kunne åbne et issue og se kodebasen med kommentarer og forklaringer.
[1] https://github.com/NicolaiSoeborg/SmitteStop-kildekode/blob/v2.0-132/NDB.Covid19.cs#L9309-L9336
Er der evidens for at der er 'Android' der blokerer eller er det ikke bare dårligt udviklingsarbejde af NetCompany !!
Prøvede lige at starte min app op. Fortalte mig at den nu virker flere steder uden for DK, og så bad den mig give "consent". Jeg ved ikke om det er nye betingelser, eller en opdatering til dem jeg oprindelig har accepteret, men det lignede mistænkeligt at app'en troede det var første gang jeg startede den op?
Jeg husker at jeg fik et 1-2 notificeringer i starten, som en status eller reminder om den kørte. Men dem har jeg ikke set meget meget længe. Hvis det er meningen den skal ligge med en fast process i baggrunden, så undrer det mig at jeg ikke kan se det i status-linien? Jeg mener det er et krav i nyere Android versioner at "persistent processes" er synlige i status-linien? Men måske er der andre måder at lave sporing på, f.eks. at lade app'en trigges til opstart når BT kan komminikere med andre telefoner (hvis det er muligt)?
Men har i hvert fald på fornemmelsen af at min app nok ikke har kørt. Og jeg har endda en Pixel som skulle være en af telefonerne med mindst aggresiv strøm-styring.
Men vil det løse problemet med at app'ens daglige check ikke går i gang igen efter en restart af telefonen?Hvis Smittestop-appen får denne permission (hvilket den ikke havde i den version jeg senest har decompilet, men den er gammel) løser det nok en hel del problemer.
I det scenarie er det tilsyneladende nødvendigt at åbne SmitteStop app'en for at få gang i sagerne.
Ja, det kunne godt tænkes at være relateret til batteriforbrugs-optimeringer. Da hver producent laver sine egne varianter af Android kan det måske også være interessant at vide hvilke fabrikanter der mest aggresivt slår apps/processor ihjel for at spare strøm. Der er forsøgt lavet vurdering af det her:https://dontkillmyapp.com/
Idet den tyske pendant er open source, kan vi se i Manifestet at den har følgende permission:
<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />
Hvis Smittestop-appen får denne permission (hvilket den ikke havde i den version jeg senest har decompilet, men den er gammel) løser det nok en hel del problemer.
Det tyske modstykke CoronaWarn er bevis på at det kan lade sig gøre også på Android. Med den kræves der ikke underlige besværgelser for at undgå at checket går i stå. CoronaWarn henter+checker troligt de smittedes nøgler en gang i døgnet.
Det kunne være rart at få belyst miserens omfang og at sikre sig at en evt. fejlrettelse virker.
For at finde ud af det kunne man undersøge hvor mange forskellige telefoner, der hvert døgn kontakter serveren for at downloade de smittedes nøgler. Det tal skal så sammenholdes med antallet af gange app'en er installeret. Ugens gennemsnit kunne passende oplyses på status-siden
Problemet starter og slutter med den på måde det offentlige indkøber på.
Der er mange flere ting som kendetegner Det offentliges indkøbsproces, men i meget korte træk fortrækker Det offentlige ”væg-til-væg” leverandører, ligesom der skal på forhånd skal være indgået rammekontrakter og flerårlige aftaler med videre.
Ser vi på IT konsulentbranchen så ligger udviklingstyngden klart i selskaber med mindre end 50 ansatte.
Men de som vinder opgaven via udbuddet, er ofte mastodonter med tusindvis af ansatte og som har en masse folk ansat som ingen rigtig ved hvad laver, udover de har fine hjørnekontorer, går dyrt klædt og kører i dyre biler.
Jeg er ikke i tvivl om at der i Danmark findes specialiserede IT konsulenthuse som kunne havde lavet den Smittestopapp på for en 1/5 af prisen og til tiden.
Primært fordi de ikke har samme ”fedtlag” på deres organisation som f.eks. KMD eller Netcompany.
Selvom mastodonten hyrer et specialiseret selskab til opgaven, så forsvinder 50% let i det tillæg som mastodonten beregner sig ift. slutkunden. Jeg har set at mastodonter tager en faktor 3+ ift. til det selskab som faktisk udfører opgaven for slutkunden.
Danmark burde gøre som i Storbritannien som for omkring 10 år siden nåede til samme konklusion og derfor opdeler udbuddene indenfor IT-konsulentydelser så de små kan være med, fordi den engelske samfund på den måde sparer penge ved at gå udenom ”fedtlaget”.
Det som i Storbritannien svarer til nemid er i dag opdelt på fem leverandører, hvoraf den største vistnok har omkring 40 ansatte og den mindste omkring 10 ansatte. De afregnes via mikrobetaling, således at hver gang du svinger din nemid så får de en mikrobetaling.
Med dette system er det et spørgsmål om f.eks. Nets Danid overhoved ville kunne overleve i den konkurrence, fordi det er borgeren som vælger den service som via nøglekortet skal bekræfte identiteten.
Det lille flueben som hedder husk indstillinger, vil gøre ondt i lang tid efter der har været nedbrud.
Jeg forstår simpelthen ikke hvordan man kan betale for et produkt med disse vasnekligheder.. Har virksomheden bag overhovedet testet appen før den blev udgivet?