Hallo Miteinander,
Ich möchte mich auf die technische Kritik aus LdN211 min. 21:40 von Ulf gegenüber der Corona-Warn-App beziehen und etwas Kontext geben. Ich bin selbst Software-Entwickler und promoviere im Informatikbereich, habe aber selbst mit der Entwicklung der App nichts zu tun. Ich möchte lediglich Hintergrundinformationen liefern, da sie öffentlich zugänglich sind, aber unter Umständen nicht direkt gefunden werden.
In der Folge wird Kritik an der nierigen Aktualisierungsfrequenz der IDs geübt. In dem [cwa-documentation-Repository] (neue Nutzer können nur 2 Links hinzufügen, daher kein link hier) können viele technische Details nachgeschlagen werden. Unter anderem unter Data Transfer and Data Processing:
In order to prevent load peaks in the back end, the downloads need to be spread evenly across the set time interval (currently an hour).
Es scheint also schon so geplant zu sein, dass die App stündlich Aktualisierungen herunterlädt. Warum sie das in einigen Fällen nicht tut ist wirklich fraglich.
Letzte Aktualiserung des Dokuments: 16.07.2020
Des Weiteren kann bei dem CWA-Server Distirbution Service nachgelesen werden, dass die „diagnosis keys“ (keys der positiv getesten) stündlich aggregiert und ausgeliefert werden:
The distribution service is triggered by a CRON scheduler, currently set to 1 hour. However, this will change, since the Exposure Notification APIs have a rate-limiting in place (Apple: 15 files/day, Google 20 API calls/day).
Letzte Aktualiserung des Dokuments: 21.10.2020.
Insofern scheint die Architektur und Aktualisierungsfrequenz schon so wie gefordert implementiert worden zu sein. Warum das bei einigen/manchen/vielen nicht funktioniert kann hingegen wirklich kritisiert werden.
Liebe Grüße,
Dennis
PS für Nerds: Ich die Überschlagsrechnung bzgl. Bandbreite in dem cwa-documentation-Repository unter „Bandwidth Estimations“ (link habe ich wieder entfernt, da neue Nutzer nur 2 Links hinzufügen können) interessant. Ich gebe mal das volle Zitat:
While each set of 14 diagnosis keys only has the small size of 392 bytes, all newly submitted diagnosis keys of a time period need to be downloaded by all mobile phones having the application installed. When considering 2000 new cases for a day, a transmission overhead (through headers, handshakes, failed downloads, etc.) of 100% and 30 million clients, this adds up to approximately 1.5MB per client, i.e. 42.8TB of overall traffic. If a day is split into 24 chunks (one per hour), this results in a total number of 720 million requests per day. If the requests are evenly spread throughout the corresponding hour, approximately 8,500 session requests per second need to be handled. Detailed descriptions of the connections can be found in the chapter „Data transfer and data processing“. Those number exclude possible interoperability with other countries.
Ich setze mal aktuellere Zahlen ein, da das Dokument seit Juli nicht mehr aktualisiert wurde. Ich halte mich hier an die Zahlen, die ihr im Podcast genannt habt:
Active clients: 16 Mio.
New cases (28.10.): ~15 Tsd. (20% haben die App und 60% davon geben Warnungen weiter) → 1,8 Tsd.
Key Size: 392 bytes
Transmission Overhead: 100%
→ 392 bytes * 2 (overhead) *1800 new cases / Tag ~ 1,41 MB / Client / Tag
→ 392 bytes * 2 (overhead) *1800 new cases / Tag * 16 Mio devices ~ 22,6 TB / Tag (ich komme mit einer analogen Rechnung mit deren Zahlen allerdings nicht auf 42.8TB / Tag, sondern auf ~ 47 TB / Tag).
Bei stündlichen Anfragen von 16 Mio devices kommt man auf 384 Mio. Requests/Tag bzw. 4.444 Requests/Sekunde.