Schlagwort-Archive: Corona-Warn-App

CoronApp-News (2020-05-23)

Der wöchentliche Nachrichtenüberblick zu Corona-Apps aller Art:

  • Der Deutschlandfunk fasst den aktuellen Stand in Sachen Corona-Warn-App zusammen und schaut dabei auch auf andere Länder: Warum Deutschland noch keine Corona-App hat.
  • Die Entwicklung schreitet jedoch voran. Apple und Google haben wie angekündigt ihre Schnittstellen zur Unterstützung von Contact-Tracing-Apps veröffentlicht. Dazu passend stellt das deutsche Corona-Warn-App-Projekt ein Architekturdokument sowie die ersten Quelltexte für den Warnserver bereit. Auch eine Anleitung zum Melden von Sicherheitsproblemen gibt es bereits und eine Werbeagentur denkt sich Sprüche aus.
  • Der Journalist Ranga Yogeshwar wird ungeduldig, hält Deutschland im Taz-Interview für ein hochnäsiges digitales Entwicklungsland und sieht durch Datenschutzdiskussionen technische Unfähigkeit vernebelt. Dabei können wir Technik vergleichsweise gut, aber auf der Anwendungsseite hapert es, wie Konstantin von Notz gegenüber dem Deutschlandfunk betont: „Das liegt daran, dass Deutschland sowieso bei IT-Großprojekten schlecht aufgestellt ist. Und dass man immer eine unglaublich bürokratische, sehr nutzerfeindliche Logik hat, sei das bei De-Mail, dem E-Perso, der elektronischen Gesundheitskarte.“
  • Yogeshwar meint auch, wir hätten besser die Südkoreaner nach ihrer Lösung fragen sollen statt selbst von vorne anzufangen. Wie das südkoreanische Modell funktioniert, welche Daten dort verwendet werden und wie die daraus erzeugten Warnmeldungen aussehen, erklärt die BBC. Dieses Vorgehen erscheint hierzulande vielen undenkbar, hat jedoch Vorzüge. Wozu die südkoreanische Kontaktverfolgung im Stande ist, zeigt ein Kurzbericht von Sukbin Jang, Si Hyun Han und Ji-Young Rhee: Cluster of Coronavirus Disease Associated with Fitness Dance Classes, South Korea. Deutsche Gesundheitsämter schaffen so etwas sicher auch, die Corona-Warn-App in der geplanten Form hingegen sicher nicht.
  • Zweifel am Nutzen der Corona-Warn-App äußern der Sächsische Ministerpräsident Kretschmer und die Grünen-Politikerin Rößner. Indirekt an der Notwendigkeit einer App zweifelt der Thüringer Ministerpräsident Ramelow. Er möchte landesweite Vorschriften zu Kontaktbeschränkungen und Mindestabständen sowie die Mundschutzpflicht bereits in zwei Wochen aufheben.
  • Der Kultur- und Medienwissenschaftler Roberto Simanowski braucht gar keine funktionierende App. Er kann schon der Debatte um die App Positives abgewinnen und meint, die Gesellschaft übe sich darin im medienwissenschaftlichen Diskurs.
  • Einblicke in die Arbeit der Gesundheitsämter gibt ein Twitter-Thread von @stadtwildnis. Wir erfahren dort unter anderem, dass die Gesundheitsbehörden fast so dezentral organisiert sind, wie sich das manche von einer Corona-App wünschen. Dies hat zur Folge, dass an der Kontaktverfolgung häufig mehrere Ämter beteiligt sind, weil die Kontaktpersonen in verschiedenen Zuständigkeitsbereichen wohnen.
  • Neben dem RKI hat auch die Max-Planck-Gesellschaft gemeinsam mit der Universität Tübingen eine Datenspende-App zu Forschungszwecken entwickelt. CoroNotes soll ohne Fitnesstracker funktionieren, ist gegenwärtig jedoch aufgrund technischer Probleme nicht verfügbar.
  • Aus dem Bundescoronahackathon hervorgegangen ist der Verein Quarano, das an einer gleichnamigen Quarantäne-App arbeitet. Wie weit die Entwicklung fortgeschritten ist, bleibt auf der Website unklar. In seinem Podcast UKW spricht Tim Pritlove mit Oliver Drotbohm, einem der Entwickler. In der Slowakei erscheint sich die dortige Quarantäne-App als vergleichsweise grundrechtsschonend: wer sie benutzt, darf seine Quarantäne zu Hause statt in einem nicht allzu komfortablen staatlichen Quarantänezentrum verbringen.
  • Zu guter Letzt erregen Gästelisten in Restaurants, Friseurgeschäften und anderen Einrichtungen die Gemüter: Rechtsanwalt Niko Härting sieht darin einen Ausdruck ausufernder Vorratsdatenspeicherung, ein Bochumer Anwalt klagt wegen nach seiner Auffassung mangelnden Datenschutzes gegen die Erfassung. In Schleswig-Holstein zeigt das ULD, dass sich jedes Datenschutzproblem in Papier einwickeln lässt und stellt ein Musterformular vor, das pro Person eine ganze Seite braucht – oder sogar zwei, wenn die Betroffenen eine Kopie der Datenschutzhinweise mit nach Hause nehmen möchten. Einige Wirte helfen sich selbst, indem sie der Einfachheit halber die Ausweise ihrer Gäste fotografieren, und stehen dabei mit einem Bein im Gefängnis. Eine App anstelle von Formularen könnte die Erfassung vereinfachen und gleichzeitig den Gästen helfen, später ihre Betroffenenrechte wahrzunehmen, denn wer notiert sich schon im Alltag, wo er überall seine Kontaktdaten hinterlässt? In der entstehenden Corona-Warn-App hat solch eine Funktion jedoch vorerst keinen Platz.

Wäre es am Ende doch schlau gewesen, erst einmal die Aufgaben, Funktionen und Erfolgsaussichten einer Corona-App zu diskutieren und sich dabei Vorbilder aus anderen Ländern anzuschauen?

Geschichten erzählen

Das deutsche Corona-Warn-App-Projekt hat einen ersten Anforderungskatalog vorgelegt. Von den politischen Belastungen seiner Vorgeschichte kann es sich nicht lösen. Die Entwickler skizzieren ein Minimum Viable Product ausgehend von den bekannten willkürlichen Festlegungen. Auf eine ergebnisoffene Einbindung der Stakeholder in die Anforderungsanalyse warten wir weiter vergebens.

Für die deutsche Corona-Warn-App, die im Auftrag der Bundesregierung von SAP und der Telekom entwickelt wird, liegt jetzt ein erster Anforderungskatalog vor. Große Überraschungen finden sich darin nicht, die Entwickler bleiben in den politisch vorgezeichneten Bahnen. Das ist verständlich, aber schade, denn so unterbleibt weiter die Auseinandersetzung mit dem Anwendungskontext und den realen Bedürfnissen der Nutzer und Stakeholder. Dass die Anforderungen als User Stories formuliert sind, lässt die daraus resultierenden Defizite deutlich hervortreten.

Eine User Story beschreibt eine funktionale Anforderung an ein System in der Form: „Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>“, oder ähnlich. Das Wie spielt zunächst keine Rolle. Als Informationsobjekte werden User Stories im Entwicklungsprozess zu verschiedenen Zwecken verwendet. Entwickler und Designer knüpfen daran ihre Entwurfsarbeit, das Produktmanagement kann damit in Abstimmung mit den Stakeholdern Ziele und Prioritäten festlegen und das agile Projektmanagement steuert mit Hilfe eines priorisierten Backlogs noch nicht umgesetzter User Stories die Entwicklungsarbeit.

Damit User Stories gut werden, muss man sich bei ihrer Formulierung ernsthaft mit seinen künftigen Nutzern auseinandersetzen, das heißt intensiv mit ihnen interagieren. Dazu gibt es eine Reihe von Methoden von Fragebögen über Interviews  und Workshops bis zu frühen Usability-Tests mit Papierprototypen. Ohne diese Interaktion läuft man Gefahr, spekulative Vorstellungen zu entwickeln, die sich später als falsch erweisen. In der echten agilen Entwicklung muss man allerdings nicht alles vorher klären, weil man den Nutzern regelmäßig neue Versionen einer Anwendung zur Verfügung stellt und sich dazu jeweils Feedback holt.

Die veröffentlichten User Stories für die Corona-Warn-App (in der Fassung vom 14. Mai 2020) zeigen drei Auffälligkeiten:

(1) Geringe Nutzerorientierung. Die Entwickler wandeln die Schablone ab zu: „Als <Stakeholder> möchte ich <Handlung durchführen>, um <gewünschtes Ergebnis zu erzielen>.“ Aus dem Ziel wird eine Handlung, aus dem Nutzen ein gewünschtes Ergebnis. Dieses subtil abgewandelte Format erleichtert es, aus der Luft gegriffene Gestaltungsideen den Stakeholdern gewissermaßen in den Mund zu legen, indem man sie als User Story ausgibt.

Das tun die Entwickler auch sogleich und formulieren zum Beispiel: „Als App-Nutzer möchte ich beim erstmaligem Applikationsstart über die Nutzungsbedingungen und Datenschutzbestimmungen (Data Protection Screen) informiert werden und meine Zustimmung geben, um über den Umgang mit meinen Daten innerhalb der Anwendung aufgeklärt zu sein.“ (E01.02) oder: „Als App-Nutzer möchte ich das Impressum der Applikation einsehen können, um zu sehen, wer für Entwicklung und Inhalte der Applikation verantwortlich ist.“ (E02.04). Das ist Käse, Datenschutz-Formalia und Impressum wollen nicht die Nutzer haben, sondern die Daten- und Verbraucherschützer. Nutzer freuen sich darüber so sehr wie über ein Cookie-Banner auf einer Website.

In diesem Stil geht es auch bei den Kernaufgaben der App weiter: „Als App-Nutzer möchte ich, dass bei Vorliegen meines positiven Testergebnisses nach meiner Zustimmung die pseudonymisierten IDs, unter denen ich an den vergangenen Tagen für andere App-Nutzer sichtbar war, an den Warn Server übermittelt werden, damit Kontaktpersonen durch ihre Apps gewarnt werden können.“ (E06.03), oder: „Als App-Nutzer möchte ich die Möglichkeit zur Eingabe einer TAN innerhalb der App haben, damit ich die mir telefonisch mitgeteilte TAN zur Zuordnung meines Testergebnisses zu der von mir genutzten Instanz der App nutzen kann.“ (E06.05). Das sind keine lösungsneutralen Ziele realer Nutzer, sondern Gestaltungsideen der Entwickler.

(2) Fehlende Stakeholder. Als Stakeholder sind nur App-Nutzer, Hotlines sowie das Robert-Koch-Institut (RKI) genannt. Hingegen fehlen die zuständigen Gesundheitsämter sowie auch der verantwortliche Betreiber der gesamten Anwendung und damit mittelbar die Öffentlichkeit.

Zu den seit dem Aufkommen der App-Idee geflissentlich ignorierten Anforderungen der Gesundheitsämter hat sich der Landkreistag vor einiger Zeit bereits geäußert. Von dort bekäme man User Stories wie: „Als Beamter einer Gesundheitsbehörde möchte ich Kontaktpersonen identifizieren, um ihnen Empfehlungen und Anordnungen zu übermitteln.“, oder: „Als Beamter einer Gesundheitsbehörde möchte ich Quarantäneanordnungen aussprechen, die einer gerichtlichen Prüfung standhalten.“ Dass es solche Anforderungen gibt, heißt nicht, dass man sie zwingend umsetzen müsste. Wer sie gar nicht erst erfasst, drückt sich jedoch davor, wichtige Aspekt des Problems überhaupt zur Kenntnis zu nehmen.

Um die Errichtung oder Beauftragung einer verantwortlichen Betreiberinstitution drückt sich seit ebenso langer Zeit die Bundesregierung. Ein verantwortlicher Betreiber hätte unter anderem die Aufgabe, den Systembetrieb zu überwachen und die Öffentlichkeit darüber auf dem Laufenden zu halten, wie gut oder schlecht die automatische Kontaktverfolgung funktioniert. Von einem Verantwortlichen bekäme man User Stories wie: „Als Verantwortlicher möchte ich die Arbeit des Systems fortlaufend überwachen, um Fehler und Probleme schnell zu erkennen.“, „Als Verantwortlicher möchte ich täglich aktuelle Statistiken über die verteilten Warnungen erhalten, um die Öffentlichkeit zu informieren.“, oder: „Als Systembetreiber möchte ich Nutzerfeedback einholen, um die App fortlaufend verbessern zu können.“ Hier läge übrigens auch der passendere Kontext für Anforderungen wie das Impressum oder den unvermeidlichen Datenschutz-Sermon.

(3) Unvollständige Anforderungen. Während sich viele User Stories mit sekundären Themen wie dem Installationsprozess, der Konfiguration und der Barrierefreiheit beschäftigen, bleibt der Kern der App sehr dünn. Ausführlich und mit zu vielen technischen Details wird der Erhalt eines Testergebnisses und das darauf folgende Auslösen einer Warnung beschrieben. Allerdings fehlt die Möglichkeit zur Entwarnung etwa für den Fall, dass ein Testergebnis falsch gemeldet oder zugeordnet wurde.

Für den Kontaktfall – ein App-Nutzer wird über eine mögliche Ansteckung irgendwie, irgendwo, irgendwann benachrichtigt – müssen hingegen ganze zwei User Stories genügen. Im Wesentlichen sagen sie: Der Nutzer erhält eine Nachricht und kann daraufhin Verhaltensempfehlungen aufrufen. Aus Nutzersicht gibt es an dieser Stelle noch einiges zu klären. Grundidee der Corona-Warn-App ist, dass sich die Informierten umgehend selbst isolieren, bis klar ist, ob sie sich angesteckt haben, also entweder ein verlässliches negatives Testergebnis vorliegt oder aber Symptome auftreten.

Ich vermisse hier User Stories wie: „Als Kontaktperson eines Infizierten möchte ich schonend und mitfühlend erklärt bekommen, dass ich möglicherweise mit einem potenziell tödlichen Virus infiziert bin, damit ich mich nicht mehr als unvermeidlich aufrege.“, „Als Kontaktperson eines Infizierten möchte ich wissen, wo ich mich testen lassen kann, um möglichst schnell Klarheit über eine Ansteckung zu erlangen.“, oder: „Als benachrichtigter App-Nutzer, der sich umgehend in Quarantäne begibt, möchte ich einen Nachweis zur Vorlage bei Arbeitgebern, Behörden und Gerichten abrufen, um meine Abwesenheit beziehungsweise verpasste Termine zu entschuldigen.“

Neben solchen praktischen Fragen stellen sich an dieser Stelle auch grundsätzliche. Eine Befehlsgewalt über Menschen erhält das Smartphone nicht, da alles freiwillig sein soll. Wie aber muss eine Benachrichtigung aussehen, damit sie für die Nutzer plausibel ist und die daran geknüpften Verhaltensempfehlungen freiwillig befolgt werden? Ich könnte mir vorstellen, dass das mit ein paar Details besser funktioniert: „Jemand aus Ihrer Sportgruppe, die sich am Montag getroffen hat, ist infiziert.“, oder: „Sie saßen vorgestern im ICE von Frankfurt nach Mannheim im gleichen Wagen wie ein Corona-Infizierter.“ Solche Aussagen sind konkret und der persönliche Bezug nachvollziehbar, während die Warnungen der geplanten App vage bleiben.

Nun muss man bei agiler Entwicklung nicht von Anfang an alles richtig machen. Ausgehend von einer vagen Idee kann man die Einzelheiten und allerlei unerwartete Fragen nach und nach entdecken, denn agile Entwicklung ermöglicht und impliziert eine empirische Anforderungsanalyse über die gesamte Entwicklungszeit hinweg. Angesichts der Vorgeschichte sowie des Zeitdrucks – einige sprechen schon vom „digitalen BER“ (https://www.mdr.de/nachrichten/politik/inland/corona-tracing-app-warten-100.html), obwohl das weit übertrieben scheint – habe ich jedoch den Eindruck, dass man hier einfach mit politisch geformten Vorgaben in einen kleinen Wasserfallprozess geht. Daran ändert ein an User Stories erinnerndes Gerüst für die vorbestimmten, an willkürlichen technischen Entscheidungen ausgerichteten Anforderungen wenig.

Schon vor einem Monat, als das Projekt der Stunde noch PEPP-PT hieß, war zu erkennen, dass ein nur auf perfekten technischen Datenschutz fokussierter Ansatz die Anforderungsanalyse zu kurz kommen lassen würde. Nicht zuletzt den am Projekt Beteiligten selbst fiel dies anscheinend auf und sie verabschiedeten sich vom dezentralen Extremismus. Genaueres weiß die Öffentlichkeit nicht, denn PEPP-PT erlaubte keine Einblicke in den Entwicklungsprozess. Zumindest dies hat der zweite Anlauf verbessert. Ob das bloße Vorzeigen jedoch etwas am absehbaren Ergebnis ändert, bleibt offen.