This blog post is about the German Corona-Warn-App and its communication strategy. So i’ll stick to German for it.

Am 16. und 17. Dezember wurden auf dem offiziellen Blog der Corona-Warn-App zwei Blog-Eintrag veröffentlicht. Der erste kündigt die neue Version 1.9 der App an, der zweite erklärt, wie in der neuen Version Begegnungen und Risiko berechnet werden.

Beide Blog posts sind meiner Meinung nach technisch ungenau, irreführend oder schlichtweg falsch. Der zweite Blog-Eintrag wurde auch nur nötig, weil der erste wenig über die tatsächlichen Änderungen aussagt, sodass viele Nutzer am Ende darüber verwirrt waren.

Erster Blog-Eintrag

Über die nächsten 48 Stunden wird die neue Version 1.9 der Corona-Warn-App auf alle Geräte ausgerollt und stellt damit vor allem auf Version 2 des Exposure Notification Frameworks (ENF) um, das von Apple und Google zur Verfügung gestellt wird. [16. Dezember, 18:30]

Schon der erste Satz des ersten Blog-Eintrag enthält gleich zwei inhaltliche Fehler.

• Es gibt das Exposure Notification Framework und dessen Version 2 nur für iOS. Unter Android gibt es die Google API für Exposure Notifications und dessen aktuelle Version der ist 1.7(.2), welche tatsächlich auch von der Corona-Warn-App genutzt wird.
• Die Version 1.9.1 der Corona-Warn-App für Android wurde erst am 18. Dezember, 12:20 im Quellcode markiert und ist für die meisten Nutzer auch 48 Stunden nach dem Blog-Eintrag nicht verfügbar. Etwa 17 Stunden nach der Veröffentlichung des ersten Corona-Warn-App-Blog-Eintrags Aussage eine neue Vorabversion (1.9.1-RC2) für Android erschienen. Die Entwicklungen für Android waren also zum Zeitpunkt des Blog-Eintrags noch gar nicht abgeschlossen.

In dem ersten Blog-Eintrag wird schon angekündigt, dass mit der neuen Version die “epidemiologische Risikobewertung nun noch genauer” wird. Insbesondere, dass mehrere Begegnungen mit niedrigem Risiko jetzt zu einem hohen Risiko führen können.

Unerwähnt bleibt zunächst, das Begegnungen mit sehr niedrigem Risiko jetzt vollständig verschwiegen werden. Das hat nach Veröffentlichung für einige Verwirrung gesorgt, da Nutzer annahmen ihre App sei kaputt – schließlich waren vor dem Update noch mehrere Begegnungen mit geringem Risiko angezeigt worden und jetzt keine mehr. Die Entwickler der Corona-Warn-App sahen sich in der Folge genötigt, eine Erklärung zu den Änderungen zu veröffentlichen.

Zweiter Blog-Eintrag

Im zweiten Blog-Eintrag wird auch wiederholt von der Version 2 des ENF von Apple und Google geredet, obwohl es dies nur für Apple gibt. In Anbetracht der Tatsache, das Google Android Nutzer ohnehin keine neue App haben, ist das aber sicherlich verschmerzbar.

Bisher konnte die in der App angezeigte Anzahl der unkritischen Begegnungen nicht weitergehend gefiltert werden. […] Unter dem Exposure Notification Framework in Version 2 werden vom Betriebssystem Begegnungen erfasst, die ein geringeres Risiko als „niedriges Risiko“ (grün) aufweisen. Diese sind aus aktueller epidemiologischer Sicht nicht relevant und werden von der Corona-Warn-App herausgefiltert.

In dem Eintrag wird jetzt eine völlig irreführende Erklärung gegeben, wie es dazu kommt, dass weniger Begegnungen angezeigt werden. Tatsächlich erfasst die neue Version der Schnittstellen (und das gilt sowohl für ENF version 2 als auch für den ExposureWindow mode der Google API) genau die gleichen Begegnungen wie die alte Version. Und auch in der alten Version hätte man Filter benutzen können, um Begegnungen mit sehr geringem Risiko zu verstecken. Tatsächlich wäre die im Blog-Eintrag weiter beschriebene Trennung zwischen sehr niedrigem, niedrigem und hohem Risiko auch mit der alten Version möglich gewesen, über die Informationen die in ENExposureInfo (Apple) bzw ExposureInformation (Google) bereitgestellt werden.

Die Entscheidung, Begegnungen mit niedrigem Risiko weiter aufzuschlüsseln und solche mit sehr niedrigem Risiko komplett zu verstecken ist zwar vielleicht sinnvoll, sie ist aber von der Nutzung des Apple ENF version 2 oder des ExposureWindow mode der Google API völlig unabhängig. Indem sie hier einen Zusammenhang konstruieren, versuchen die Entwickler die Probleme in ihrer vorhergegangenen Kommunikation auf Google/Apple zu schieben.

Fazit

Insgesamt scheint es dem Projekt an Transparenz zu mangeln. Die Kommunikation erfolgt quasi erst dann, wenn es Probleme gibt, statt proaktiv zu erläutern, wenn etwas geändert wird.

Noch schlimmer sieht es übrigend bei der Kommunikation mit externen Entwicklern aus. Im GitHub wird zeitgleich an den Versionen 1.9, 1.10 und 1.11 entwickelt, ohne das klar ist, wofür jede dieser Versionsnummern stehen. Die Version 1.8 wurde kommentarlos übersprungen, obwohl dazu Entwicklerversionen veröffentlicht wurden. Berichtete Probleme werden vom öffentlichen GitHub in ein privates Fehler- und Projektverwaltungssystem verschoben und dort teilweise unter Ausschluss der Öffentlichkeit und des Melders bearbeitet. Das ist insbesondere deshalb bedauerlich, da bei besserer Integration der Open-Source-community Funktionen wie das Kontakt-Tagebuch heute wahrscheinlich schon verfügbar wären. Aber das ist ein Thema für einen eigenen Blog-Eintrag…