Android-telefoner kan blokere for dansk corona-app

Sundhedsministeriet bekræfter, at der er problemer med, at Android-systemet kan blokere for Smittestop-app'en. Illustration: Version2
Styresystemet Android kan blokere for, at den danske corona-app, Smittestop, på korrekt vis henter de relevante data. Det skriver it-mediet Computerworld.

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.

Læs også: Blev lanceret som "pro bono": Smittestop-appen koster 35 millioner kroner i 2020 - prisen for næste år er ukendt

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.

Læs også: Nu virker Smittestop i Tyskland: Danmark er koblet på fælleseuropæisk gateway for corona-app's

Læs også: Beslutningen er taget: Dansk corona-app kobles til tværeuropæisk løsning i november

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

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.

  • 21
  • 0
#3 Søren Laursen

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

  • 10
  • 0
#4 Malthe Høj-Sunesen

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.

  • 8
  • 0
#6 Søren Laursen

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.

Men vil det løse problemet med at app'ens daglige check ikke går i gang igen efter en restart af telefonen?

I det scenarie er det tilsyneladende nødvendigt at åbne SmitteStop app'en for at få gang i sagerne.

  • 0
  • 0
#7 Stig Nygaard

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.

  • 4
  • 0
#9 Nicolai Søborg

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

  • 10
  • 0
#10 Thomas Kjeldsen

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
  • 1
  • 0
Log ind eller Opret konto for at kommentere