LdN208 - Langsame Corona-Warn-App

Sorry Leute, aber nachdem ihr beide in dem Chor derjenigen, die die Datensparsamkeit der CWA so hoch gelobt habt, laut und deutlich mitgesungen habt, solltet ihr erst mal kurz nachdenken, bevor ihr euch ebenso laut und deutlich über glasklar erklärbare und begründbare Folgen dieser sehr stark auf Anonymität und Datensparsamkeit ausgelegten Architektur mokiert.

Worauf spiele ich an? Auf die Kommentare zu den Erfahrungsberichten in LdN208, denen zufolge es zu lange dauerte, bis a) ein positiver Test an die betreffende Person selbst in der CWA übermittelt ist, und b) bis nach Meldung einer Infektion der einen Person andere, die eindeutig Kontakt hatten (in dem Fall Lebenspartner) eine Warnung bekommen. Letztere Phase waren wohl 36 Stunden, was recht lang ist, aber jetzt nicht so weit weg von den architekturbedingt 12-24h, die voll und ganz zu erwarten sind - und die euch vermutlich auch nicht zufriedengestellt hätten, da ihr ja offenbar Push-Nachrichten-Geschwindigkeit erwartet.

Da die Diskussion zur technischen Funktionsweise offenbar zu lange zurück liegt, hier nochmal ein kurzer Abriss, der das Phänomen erklären sollte. Was die App tut, ist eben kein Push, sondern sogenanntes Polling. Und zwar pollt sie in regelmäßigen Intervallen von meines Wissens derzeit 24h den CWA-Server und fragt den nach neuen Keys infizierter Personen. Der Server wiederum sammelt eingehende Keys, paketiert immer eine Stunde an Keys zu einem Block, und übermittelt einer anfragenden App die Stunden-Blöcke seit ihrer letzten Abfrage, also in der Regel der letzten 24h. Es ergibt sich dadurch also eine Verzögerung von im Schnitt 12h plus 30min für die Paketierung, also 12h30m, von einem neuen positiven Key-Upload bis zur Warnung einer Kontaktperson. Und da das ein statistisches Mittel ist, können es im Extremfall eben auch mal 25h sein, ohne dass man irgendwie konstatieren könnte, dass da irgendwo eine unerklärliche Verzögerung im System gewesen sei.

Das ist nun mal der Trade-Off bei Polling-basierten Systemen: sie reagieren nur so schnell, wie die Polling-Frequenz erlaubt, und diese lässt sich nicht beliebig weit beschleunigen, da die Systemlast sowohl auf Client- als auch Serverseite sich mit jeder Halbierung des Intervalls verdoppelt. Hier ist vermutlich die Serverseite eher unkritisch, limitierender Faktor dürfte die Batterie des Smartphones sein, denn wie wir gesehen haben fällt die Akzeptanz einer Corona-App ins Bodenlose, wenn das Ding deutlichen Einfluss auf die Laufzeit des Handys hat (wir wissen dass das so ist, weil es unter Android zu Beginn ja einige Bugs gab, bei denen einzelne Geräte erheblich mehr Akku als beabsichtigt gezogen haben wenn die App aktiviert war).

Und dasselbe Problem gibt’s in grün bei der Übermittlung der Testergebnisse durch die App: auch da wird aus Datenschutzgründen Polling verwendet, das heißt jede App fragt in einem Intervall den Server nach Ergebnissen zu einem Test mit einem bestimmten Identifikationsschlüssel, und gibt es eins, kriegt sie es zurück, sonst halt nur die Info dass keines vorliegt. Ich kenne das Intervall hier nicht, vermute aber, dass das in ähnlicher Dimension wie bei den Infektions-Keys liegt, also 24h. Und jetzt kommt das beste: die App fragt auch dann, wenn man überhaupt nicht auf ein Testergebnis wartet, regelmäßig den Server mit einem erfundenen Identifikationsschlüssel nach den Ergebnissen eines nicht existenten Tests, damit nicht von außen anhand des Traffics festgestellt werden kann, dass eine Person auf einen Test wartet. Man hat also noch nicht mal die Möglichkeit, die Polling-Frequenz temporär so lange jemand auf ein Ergebnis wartet deutlich zu erhöhen - das würde denjenigen ja verraten! Nein - die App muss stur bei einer für alle Nutzer dauerhaft erträglichen, und daher langsamen, Abfragerate bleiben.

Überraschung: Datenschutz und Datensparsamkeit gibt’s nicht kostenlos! Systeme, die derartige sehr wünschenswerte und absolut erstrebenswerte Ziele bereits in ihrer Grundarchitektur umsetzen, erkaufen sich das mit Nachteilen in anderen Aspekten, hier der Reaktionsgeschwindigkeit. Technologie und Engineering besteht immer aus Trade-Offs, und man kann nicht auf der einen Seite maximalen Fokus auf Datenschutz fordern und sich dann fünf Minuten später über die Folgen dieser Forderung empören! Bzw. man kann natürlich, man offenbart dabei aber schlicht Unkenntnis bezüglich der technischen Gegebenheiten des fraglichen Systems und eine gewisse Naivität bzw. einen nicht durch Fakten gestützten, „magischen“ Technologieglauben - und sorry, das steht euch nicht. Daher hoffe ich, dass ihr euch Forderungen wie „da muss doch SOFORT eine Push-Nachricht an denjenigen rausgehen!“ vielleicht nochmal überlegt, bevor ihr die in den Äther pustet, denn ich will ganz sicher nicht den ganzen schönen Datenschutz damit unterlaufen, dass dann doch wieder der allwissende Server in der Mitte mein Smartphone und damit mich identifizieren kann, um mir gezielt irgendwelche Meldungen über positive Tests oder positive Kontaktpersonen zu pushen. Wäre das möglich, wär die Corona-App garantiert nicht mehr lange auf meinem Telefon, und ihr wärt vermutlich auch die allerersten, die diesen Umstand verurteilen und mehr Datenschutz fordern würdet.

4 „Gefällt mir“

Wir haben die CWA-App sehr differenziert diskutiert und auch deutlich darauf hingewiesen, dass eine CWA bei zentraler Architektur - wie sie zunächst geplant war - besser funktionieren dürfte. Dafür durfte ich persönlich mir harte Angriffe aus der Aluhut-Fraktion anhören, bis hin zu Unterstellungen einzelner, die Lage sei von der CIA und/oder dem BND unterwandert.

Und zwar pollt sie in regelmäßigen Intervallen von meines Wissens derzeit 24h den CWA-Server und fragt den nach neuen Keys infizierter Personen.

Die Akkubelastung eines kurzen HTTPS-Requests dürfte gegenüber dem ganzen Spotify-Streaming und Youtube-Schauen und auch gegenüber dem Bluetooth-Kontakt-Monitoring selbst überhaupt nicht ins Gewicht fallen. Alle 24h eine Abfrage zu senden ist daher ganz offensichtlich viel zu selten. Das ist ein klarer Design-Fehler.

dasselbe Problem gibt’s in grün bei der Übermittlung der Testergebnisse durch die App

Nein, hier könnte man durchaus Push einsetzen, ohne die Privatsphäre zu beeinträchtigen, weil die Tests ohnehin personalisiert sind. Ich würde nach meiner eigenen Erfahrung mit der App auch davon ausgehen, dass das längst Push ist, nur werden die Daten eben viel zu selten und viel zu träge an den Server dahinter übermittelt.

2 „Gefällt mir“

Es geht aber nicht nur um einen HTTPS-Request, es geht auch um die Verarbeitung der Antworten, also das Errechnen zehntausender Schlüssel aus tausenden von abgerufenen Tageskeys und den Abgleich mit den lokal gespeicherten Keys. Das ist ein weit größerer Brocken, und so weit ich das bei mir beobachtet habe, ist die App in der Hinsicht intelligent genug konstruiert, dass sie diese aufwendigen Tasks zu machen scheint, wenn das Telefon am Strom hängt - zumindest bei mir wird das Kontaktprotokoll immer nachts überprüft, wenn das Gerät in der Ladeschale liegt. Und das ist bei den meisten Leuten vermutlich ähnlich: es gibt einmal am Tag nachts die Gelegenheit, das ohne Einfluss auf die Akkulaufzeit zu machen, was der Grund dafür gewesen sein dürfte, hier einen 24h-Intervall zu forcieren (meines Wissens wird der auch gar nicht mal durch die App forciert, sondern zumindest unter iOS von Apple im Betriebssystem bereits erzwungen, so dass die richtigen Adressaten bezüglich einer Diskussion, ob das eine gute Wahl oder zu restriktiv ist - die man sicher führen kann, versteht mich da nicht falsch - auch eher Apple/Google als die Autoren der CWA sind).

Die Tests sind personalisiert, aber das heißt noch lange nicht, dass jedes beteiligte System die Personendaten auch bekommen muss! Meines Wissens soll der CWA-Server eben genau keine Information darüber haben, wer hinter einem positiven oder negativen Test steht, und erst recht nicht die Fähigkeit zur Identifikation eines konkreten Endgerätes (das ja wiederum indirekt einer Person zuzuordnen ist) als Adressat eines konkreten Testergebnisses. Das wäre aber zwingend nötig, um als Auswirkung des Eingangs eines Ergebnisses eine Push-Mitteilung über die dafür von Apple/Google vorgesehenen Systeme zu leiten - dazu muss der Server wissen, an welches Gerät diese Nachricht gehen soll, und er hat somit wieder eine am konkreten Endgerät hängende und somit „personengebundene“ Identifikation in seinem Zugriff.

Daher eben auch hier ein Polling-Verfahren, bei dem man die Identität des Endgeräts aus Sicht des Servers unbekannt halten kann. Daran kommt man nicht vorbei, und meinem Kenntnisstand zufolge ist das auch die aktuell in Betrieb befindliche Umsetzung. Einzig was den Abfrageintervall angeht bin ich unsicher, ob der auch bei 24h liegt - an dieser Stelle wäre die Argumentation „ist ja nur ein kurzer HTTPS-Request, den kann man sich doch öfters leisten“ nämlich deutlich besser im Sinne einer häufigeren Abfrage zu führen, weil der anschließende Verarbeitungsprozess viel banaler ist, der ist nämlich entweder nicht existent (wenn die App gerade gar kein Testergebnis erwartet) oder besteht nur in einem schnellen Check auf das Vorhandensein eines erwarteten Ergebnisses. Daher kann ich mir gut vorstellen, dass hier jetzt schon kürzere Intervalle gelten - aber dass da mit klassischen Push-Nachrichten gearbeitet wird halte ich ohne konkrete Nachweise in der Richtung für ein Gerücht - und für eine schlechte Idee obendrein, aus obengenannten Gründen.

2 „Gefällt mir“

Das dürfte bei der Leistungsfähigkeit moderner mobiler CPUs einige Sekunden dauern - was angesichts der sonstigen Nutzung von Handys doch wirklich nicht ins Gewicht fällt.

Die Tests sind personalisiert, aber das heißt noch lange nicht, dass jedes beteiligte System die Personendaten auch bekommen muss!

Natürlich nicht, das wäre aber auch nicht nötig, denn es könnten ja alle angefunkt werden, deren Ergebnis vorliegt, ungeachtet des Inhalts des Tests. Das wiederum ginge nach Testnummern, und die müssen bei dem Server ohnehin vorliegen, von dem das Polling die Ergebnisse abruft. Polling bietet daher keinerlei Privatsphären-Vorteile gegenüber Push, aber die geringe Polling-Frequenz stellt das ganze System in Frage.

Noch ein Nachtrag hierzu: ich habe mir die entsprechende Stelle im Podcast nochmal angehört, und die Forderung, dass da doch sofort eine Push-Nachricht rausgehen muss, bezog sich eindeutig NICHT auf die Testergebnisübermittlung, sondern auf die Situation, dass sich jemand als positiv getestet meldet, seine Keys freigibt und jemand, der mit dieser Person ganz eindeutig Kontakt hatte, nicht sofort eine Alarmmeldung bekommen hat. Die Annahme, dass die Testergebnisübermittlung per Push funktionieren würde, hat auf diesen Prozess also definitiv keinen Einfluss; die Forderung nach einer instantanen Push-Nachricht ist daher selbst unter dieser Annahme nicht vertretbar.

2 „Gefällt mir“

Wenn das Handy im Hintergrund regelmäßig pollen würde, dann könnte es ja auch eine lokale Benachrichtigung anzeigen. Ob das nun Push im engeren Sinne ist oder lokal, das ist mir ehrlich gesagt gleichgültig, Hauptsache das Handy checkt wenigstens alle paar Stunden, ob man einen gefährlichen Kontakt hatte, und zeigt das dann auch an.

Mir ist ehrlich gesagt nicht ganz klar, warum du so haarspalterisch versuchst, diese doch ganz offensichtlich nicht durchdachte App-Gestaltung gesundzubeten. Denn zu jedem technischen Problem findet sich auch eine Lösung, wenn man das will - und dass es so nicht weitergeht scheint mir doch ziemlich klar zu sein.

Hallo,
die Aktualisierung scheint unabhängig vom Ladezustand immer eher Nachts/Früh Morgens stattzufinden. Mein Smartphone wird immer nur tagsüber geladen. So smart ist die App auf dieses Thema bezogen wohl nicht, bzw. es ist ja oft so das die Geräte Nachts geladen werden, dass haben sich vielleicht auch die Entwickler gedacht.
Mit freundlichen Grüßen
Gabriel

Weil es einen gewaltigen Unterschied gibt zwischen einer grundlegend untauglichen Systemarchitektur und einer an und für sich guten, bei der lediglich einige Parameter Optimierungsbedarf haben. Dieser Unterschied ist oft nicht so leicht zu sehen, und Aussagen wie „da muss SOFORT eine Push-Nachricht rausgehen!“ angesichts eines Systems das bewusst ohne Push-Nachrichten konstruiert wurde, um sehr hohe Datenschutzstandards zu erfüllen, deuten nun mal ziemlich stark darauf hin, dass jemand glaubt, er habe einen Fall des ersteren Problems identifiziert und rufe nach fundamentalen Überarbeitungen. Faktisch hat man aber einen Fall der letzteren Art vor sich, ein System, bei dem man eher Optimierungen an Details vornehmen müsste, und die große Gefahr besteht hierbei darin, dass dann gern das Kind mit dem Bade ausgeschüttet wird, die große Überarbeitung wird angestoßen, alles wird neu gemacht, das Ergebnis ist nachher ein grundlegend schlechteres System, an dem man dann so lange Details optimieren kann, wie man will, man kommt damit auf keinen grünen Zweig mehr.

Du magst diese Unterscheidung „haarspalterisch“ nennen, und ich verstehe auch, dass es aus Nutzer-Sicht so wirken mag, aber ich baue beruflich an Systemen in der Größenordnung von so einer CWA und habe schon mehrfach obig beschriebenen Prozess der katastrophalen Verschlimmbesserung erlebt, und Ausgangspunkt war immer eine falsche Einschätzung, auf welcher Abstraktionsebene die Ursache für wahrgenommene Defizite der Systeme zu suchen und zu beheben ist.

2 „Gefällt mir“

Danke für die Erläuterungen!

Was spricht denn aus Privatssphäresicht dagegen, wenn der Server eine Pushnachricht an alle sendet, sobald er einen neuen Key-Stundenblock zusammen hat? Dann könnte das Polling auf Clientseite komplett entfallen und es könnte 1x pro Stunde der Status neu berechnet werden.

Oder wenn man Push unbedingt vermeiden will, was spricht dagegen, die Polling-Frequenz auf z.B. eine Stunde zu reduzieren, sodass man wenigstens dann 1x pro Stunde den aktuellsten Stundenblock kriegt (und alle ggf. verpassten)? Die Serverkapazät entsprechend zu steigern, kann ja nicht wirklich ein Problem sein.

Dass das Berechnen des Status viel Akku braucht, glaube ich nicht. Nach meiner Erfahrung auf meinem Handy geht das innerhalb weniger Sekunden, kann also prinzipiell nicht viel Strom brauchen.

Gerade weil die WarnApp hakt (und die Gesundheitsämter gerade ebenfalls über dem Limit laufen), kommt es auf die individuelle Verantwortung und schnelles Handeln eines jeden Einzelnen an. So haben ich es in unmittelbarer Umgebung erlebt: Ein Arbeitskontakt meiner Frau rief an und informierte sofort über einen positiven Test. Also begibt man sich als vernünftiger Mensch in Quarantäne. Problem: Rein rechtlich gesehen, darf man der Arbeit allerdings nicht fernbleiben – natürlich kann man mit vielen Arbeitgebern sprechen, trotzdem ist es eine Lücke im System. Ohne Symptome bekommt man keine Arbeitsunfähigkeitsbescheinigung, so die KV. Quarantäne greift in Bezug auf ein Arbeitsverhältnis erst dann, wenn das Gesundheitsamt sie anordnet.

Das Problem mit der Corona-Warn-App und der Benachrichtugung von Kontakten schein sogar noch etwas weiter zu gehen. Wenn ich das richtig verstanden habe, sammelt das Backend der Corona-Warn-App offenbar alle positiven Diagnose-Schlüssel und schnürt sie zu einem Paket zusammen. Dieses wird soweit ich weiß jede Nacht um 1 oder 2 Uhr (je nach Sommer- oder Winterzeit) bereitgestellt.

Jede App bezieht nur einmal pro 24 Stunden (immer zur in etwa gleichen Uhrzeit) alle aktuell verfügbaren Pakete mit Diagnoseschlüsseln (das schon genanne Polling Prinzip) und gleicht die selbst gesammelten Kontakte damit ab. Das heißt, es kann zu sehr ungünstigen Konstellationen kommen, wenn die Abrufzeit sehr lange nach der Bereitstellungszeit liegt. Anscheinend ist dieses Problem auch schon seit Juni (!!) bekannt, aber noch nicht behoben: Unnecessary delay in exposure notification due to delayed fetching of Diagnosis Keys? · Issue #466 · corona-warn-app/cwa-documentation · GitHub

In meinem Fall war der Ablauf dann beispielsweise so (meine App hat sich immer am späten Abend, circa gegen 23 Uhr upgedated):

  • Mein Kontakt hat Donnerstag morgen sein positives Ergebnis eingetragen. Die Information ist on-hold und wird am Freitag morgen im nächsten “Diagnose-Schlüssel-Paket" bereitgestellt.

  • Meine App updated sich am Donnerstag Abend gegen 23. Uhr. Meine App enthält den positiven Schlüssel meines Kontakts noch nicht, da dieser erst mit dem nächsten Paket kommt.

  • Freitag 2 Uhr geht der Schlüssel meines Kontakts “online”

  • Freitag morgen habe ich immer noch keine Nachricht, da meine App nur einmal pro 24h updated und somit noch bis Abends wartet

Freitag Abend habe ich dann selbst mein Testergebnis eingetragen. Bis dahin (34 Stunden seitdem mein Kontakt seinen positiven Test der App mitgeteilt hat), war meine App auf ‚grün‘. Zu den folgenden Schritten ist es dann nicht mehr gekommen. Ich gehe aber davon aus dass es so passiert wäre. (Unter dem GitHub link, gibt auch eine Beschreibung des Worst-Case-Szenario)

  • Freitag Abend updated sich meine App mit den neuesten Schlüsseln, es ist aber recht spät und ich sehe die Notification nicht mehr am selben Abend

  • Samstag morgen: Meine App wird rot

Kontakte von haben ebenfalls zu sehr unterschiedlichen Zeitpunkten (ebenfalls teilweise 2 Tage) eine Warnung in der App erhalten. Allerdings glaub ich teilweise mit einer Push Mitteillung die etwas a la „Ihr Corona Risiko Status hat sich geändert“.

Das bedeutet, das im Worst-Case Szenario (welches wohl bei mir der Fall war) es noch fast 48 Stunden dauern kann bis die Corona-Warn-App Alarm schlägt, nachdem ein positives Ergebnis eingetragen wurde. In meinen Augen ein riesen Problem, da die Verspätung sich recht wahrscheinlich mit einen Zeitraum deckt, in dem man oft noch keine Symptome hat aber schon infektiös ist. (Tage 3-5 nach der Ansteckung).

Trotz allem: Immer noch schneller als das Gesundheitsamt, welches sich wegen meinem Kontakt zu einer positiv gestesteten Person erst gar nicht gemeldet hat. Nach meinem positiven Testergebnis hat es ebenfalls 4 Tage gedauert, bis ich kontaktiert wurde. Was heißt dass eine Nachverfolgung frühestens am 5. Tag startet.

Dagegen spricht, dass Push prinzipiell ungeeignet ist für die Informationsübermittlung an viele Empfänger, vgl. die Diskussion des Warntages (Sirenen und GSM Cell Broadcast als geeignete, Push-Nachrichten in Warn-Apps wie NINA als ungeeignete Methoden) in LNP359 ab Minute 37:14.

Das scheint mir nicht zu stimmen. Die New York Times zum Beispiel hat überhaupt kein Problem damit, innerhalb weniger Minuten viele Millionen App-Installationen mit einer Push-Nachricht zu versorgen. Die Frage ist einfach, ob man sein Backend im Griff hat.