Archiv der Kategorie: Digitalisierung

Scheinalternative Anwendungszoo

In Baden-Württemberg laufen einige Vereine und Verbände weiter Sturm gegen den Einsatz von Microsoft-Produkten in Schulen als handle es sich dabei um von Bill Gates persönlich verimpfte atomgetriebene Tunnelbahnhöfe der fünften Generation. Neben ätherischen Ideen wie WeltSchulfrieden, Datenschutz und digitaler Souveränität sowie abstrusen Prägungstheorien führen die Vereine als Argument auch angebliche Alternativen an (PDF):

„Mit Moodle (Lernplattform), BigBlueButton (Videokonferenzsystem), LibreOffice (Bürosoftware), Thunderbird (Mailprogramm) und Nextcloud (Dateiablage und Kooperation) stehen allen Schulen Anwendungen zur Verfügung, die den Funktionsumfang von MS 365 abdecken oder übertreffen.“

Eine Sprecherin des Kultusministeriums zitiert dagegen positive Erfahrungen und findet es „verwunderlich, dass die Verbände in ihrer gemeinsamen Stellungnahme die Bedürfnisse der Schulen und Praktiker vor Ort offenbar nicht zur Kenntnis nehmen und die Realitäten des Alltags verkennen.“ Ich teile ihre Verwunderung nicht, denn die Ansichten der Aktivisten lassen sich zwanglos mit einem engen Erfahrungshorizont erklären. Anscheinend hat keiner von ihnen in den letzten zehn Jahren eine moderne Office-Installation aus der Nähe gesehen.

Wer Microsoft Office hört, denkt zuerst an Word, Excel und PowerPoint. Kein Wunder, denn aus diesen Produkten schnürte Microsoft vor gut drei Jahrzehnten sein erstes Office-Paket. Bis heute sind sie in jeder Version enthalten, doch die Hauptrolle spielen sie nicht mehr. Microsoft Office heißt heute: Outlook und Skype for Business und OneNote und Teams sowie im Hintergrund in einer herkömmlichen On-Premise-Installation Exchange, SharePoint und Active Directory. Und das ist zusammen kein Zoo aus einzelnen Anwendungsgehegen, sondern eine integrierte Lösung, ein digitales Gondwanaland.

Eine Besprechung mit Microsoft Office geht ungefähr so: Zuerst sagst du Outlook, dass du gerne Leute einladen würdest, und suchst dir die Teilnehmer aus dem Adressbuch aus. Dein Adressbuch weiß, wo das Active Directory steht, deshalb findest du da jeden aus deiner Organisation. Outlook schaut dann selbständig in die einzelnen Kalender und schlägt dir Zeiten vor, die allen passen. Du schreibst deinen Einladungstext und klickst auf den Skype-Button, der einen Block mit den Zugangsdaten fürs Meeting in deine Nachricht einfügt. Das ist alles. Kein Wechsel zwischen Programmen, keine mentale Checkliste erforderlicher Fleißarbeiten – du schreibst einfach eine Einladung, der Rest geht mehr oder weniger von selbst. Wenn nicht gerade Pandemie ist und alle zu Hause bleiben, kannst du im Vorbeigehen auch einen freien Besprechungsraum suchen und reservieren.

Genauso unkompliziert legst du aus deinem Kalender einen Notizzettel in OneNote an, entweder für dich alleine oder auf dem Sharepoint-Server für alle. Auf diesem Notizzettel erscheinen von selbst die Metadaten zur Besprechung – Betreff, Datum, Uhrzeit, Teilnehmerliste und so etwas — und dann kannst du oder könnt ihr loslegen und zum Beispiel die Agenda entwerfen. Dir fällt dabei ein, dass du zur Vorbereitung unbedingt noch etwas erledigen musst? Kein Problem, aus OneNote heraus kannst du deine Outlook-Aufgabenliste befüllen und aus der Aufgabenliste kommst du selbstverständlich auch zurück zum Ursprung und ob du deine Aufgabe in Outlook oder in OneNote als erledigt abhakst, bleibt dir überlassen.

Kurz bevor die Besprechung losgeht, meldet sich Outlook mit einer Erinnerung. Daraufhin beginnst du nicht etwa hektisch im Kalender und deiner E-Mail nach den Einwahldaten zu suchen, sondern du klickst einfach den Beitreten-Button im Erinnerungsfensterchen an und setzt dein Headset auf, während Skype for Business die Verbindung aufbaut. Während der Besprechung kommt dann vielleicht mal PowerPoint zum Einsatz oder Excel oder was auch immer man gerade zum Arbeiten braucht. Das Protokoll schreibst du in OneNote, das dir die im Skype-Meeting erschienenen Teilnehmer in der Liste selbständig ankreuzt, damit du dich auf Wichtigeres konzentrieren kannst. Du berichtest im Meeting von einem Telefonat letzte Woche und kannst dich nicht mehr erinnern, wer dich da angeskypet hat? Guckst du Outlook, das merkt sich deine Chats und Anrufe aus Skype for Business.

Du bist oft unterwegs und willst lieber mit dem Smartphone? Dann nimmst du halt Outlook und OneNote und Skype for Business für Smartphones. So wird nicht nur die Cloud als Backend auf einen Schlag plausibel, sondern du bekommst auch noch gratis Office Lens dazu, das dir  Whiteboards und Flipcharts und Visitenkarten und Dokumente nach OneNote fotografiert und sie dabei entzerrt und zuschneidet. Und ja, wenn es sich um Drucksachen handelt, macht OneNote unaufgefordert OCR und du kannst später nach dem Inhalt suchen.

Das, und nicht Word/Excel/PowerPoint, ist ein zeitgemäßes Officepaket: eine integrierte Lösung für die Organisation, Kommunikation und Zusammenarbeit im Arbeitsalltag. Wer ganz oder teilweise im Manager Schedule arbeitet, viele verschiedene Vorgänge im Blick behalten muss oder aufgrund seiner Rolle mit vielen verschiedenen Menschen zu tun hat, erleichtert sich seine Arbeit damit ungemein. Gelungene Integration kommt unauffällig daher, hat jedoch einen großen Nutzen, denn sie beseitigt Reibungsverluste und Hürden. Fürs Wesentliche bleibt mehr Zeit, die Kommunikation und Zusammenarbeit läuft rund.  Dabei habe ich Microsoft Teams mangels eigener Erfahrung damit noch nicht einmal berücksichtigt.

In vielen Unternehmen funktioniert das so. Richtig klar wird einem das vielleicht erst, wenn man es mal selbst erlebt hat – und dann südwestdeutschen Querdünkel von Dateiablagen und LibreOffice schwärmen hört. Solche Alternativen spielen nicht in derselben Liga und auch nicht in der nächstniedrigeren. Google Workspace spielt in derselben Liga, aber das würde ihnen ja genauso wenig gefallen.

Selbstverständlich könnte man sich vornehmen, Ähnliches auf der Grundlage von Open-Source-Software selbst zu entwickeln. Vorher möge man jedoch kurz überschlagen, wie viele Jahre Vorsprung Microsoft und Google haben, wie viele Milliarden an Investitionen in ihren Produkten stecken und wie viele voraussichtlich noch hinzukämen, bevor man sie eingeholt hätte. Fünf Milliarden aus einem Digitalpakt würden dort kein ganzes und auch kein halbes Jahr reichen.

Gewiss, in die Hände von Grundschülern gehört ein digitaler Büroarbeitsplatz nicht. In die ihrer Lehrerinnen und Lehrer dagegen schon und dann bitte ordentlich, nicht als Modell 601S. Lehrerinnen und Lehrer haben nämlich allerlei zu planen, zu kommunizieren und zu organisieren. Gibt man ihnen vernünftige Werkzeuge dafür, können sie sich genau wie Büroarbeiter besser aufs Wesentliche konzentrieren. Ein paar jugendfreie Funktionen wie einfach zu nutzende Konferenzschaltungen für improvisierten Fernunterricht fallen dabei fast von alleine mit ab und vielleicht kann auch die Redaktion der Schülerzeitung etwas mit zeitgemäßen Werkzeugen anfangen. Von mir aus kann die gerne jemand anderes als Microsoft oder Google liefern, wenn es denn jemand anderes kann. Solche Diskussionen müssen aber auf dem Stand der Technik geführt werden und nicht auf der Basis von Fake News. Stand der Technik sind integrierte Lösungen, die Arbeit erleichtern, und nicht zusammengewürfelte Sammlungen halbgarer Me-too-Produkte. Mal schnell für ein paar Euro Open-Source-Software aufzusetzen, die gerade auf der Anwendungsebene oft hinterherhinkt, rettet uns nicht.


P.S. (2021-01-17) Im Golem.de-Diskussionsforum findet User Oktavian diese schöne Metapher:
„Als Bauherr möchte ich ein Haus. Der Bauträger bietet mir ein Haus gebaut nach meinen Wünschen an. Du möchtest mir einen Bagger liefern, Steine, einen Kran und Dachziegel. Daraus kann ich mir bestimmt ein Haus bauen, aber dann brauche ich noch Bauarbeiter, einen Plan, Genehmigungen, ein Grundstück, einen Architekten, einen Statiker und habe das Risiko, dass alles nicht funktioniert. Was glaubst Du wohl, wessen Angebot ich reizvoller finde?“
Und auch sonst dreht sich die Diskussion dort um die hier angesprochenen Punkte.

CoronApp-News November 2020

Wir sind jetzt nicht mehr so stolz auf unsere heimische Pandemiebekämpfung wie vor einigen Monaten und blicken mit einer Mischung aus Neid und Abscheu auf jene Länder, die es besser hinbekommen. Deren Erfolgsgeheimnis liegt wohl nicht in besseren Apps, sondern zum Beispiel in konsequenterer Quarantäne. Wie geht’s den Corona-Apps, die uns erlösen sollten?

  • Die Corona-Warn-App wird langsam weiterentwickelt.
    • Seit einigen Tagen ruft sie Benachrichtigungen mehrmals täglich vom Server ab. Unter der Haube wird das zugrundeliegende Exposure Notification Framework weiterentwickelt, so dass es künftig präzisere Informationen liefert.
    • Geplant sind für die nächste Zeit Erinnerungen, falls ein vorliegendes Testergebnis noch nicht geteilt wurde, Informationsangebote in der App als Anreiz, sie regelmäßig zu öffnen (Aber wozu?), eine Kontakttagebuchfunktion sowie nun doch auch eine Funktion zum Check-In in Restaurants etc. per QR-Code. Oder doch nur Links auf externe Angebote, mit denen das bereits geht? Wir werden sehen.
    • Nerds hatten für die Clusterverfolgung auf den Ansatz CrowdNotifier gehofft, doch der ist nur theoretisch geil, weil es in der Praxis auch für Menschen ohne App funktionieren muss, gerade bei Cluster-Ereignissen. Merkt man hat nicht, wenn man nur auf die Technik schaut.
  • Bastler mit Android-Geräten können jetzt eine Version der Corona-Warn-App verwenden, die ohne Google-Services auskommt und die an Googles Appstore vorbei installiert werden kann und muss.
  • Auch diesen Monat gibt es wieder technische Probleme Unannehmlichkeiten. Auf Geräten mit den nicht ganz frischen Android-Versionen 6 bis 7.1 funktioniert die Coroa-Warn-App gerade nicht. Zuvor und unabhängig davon gab es eine Sicherheitslücke im Server-Backend; ein Angreifer hätte darüber eigenen Programmcode einschleusen und auf dem Server ausführen lassen können. Anscheinend hat dies jedoch niemand versucht und alle sind stolz wie Oskar, dass sie die Lücke gefunden und behoben haben.
  • Ein heißes Thema bleibt der bisher wohl geringe Nutzen der App und die Frage, was man dagegen tun könne.
  • Einen Schuldigen haben viele bereits ausgemacht: den Datenschutz, das ungeliebte „Supergrundrecht“. In Wirklichkeit ist es wohl eher die Freiwilligkeit nicht nur der App-Nutzung, sondern auch vieler anderer Maßnahmen bis hin zur Quarantäne, die nicht ausreichend durchgesetzt werden. Die Freiwilligkeit betonen jedoch gerade jene, die auch Kompromisse beim Datenschutz ablehnen. Man mag die Forderung nach Datenschutzlockerungen für ein Zombieargument halten, doch davon verschwindet nicht der berechtigte Eindruck, dass die Corona-Warn-App in erster Linie Daten schützt, aber wenig gegen die Pandemie tut, oder dass die Einschränkung anderer Grundrechte einen leiseren Aufschrei verursacht. Auch sollte sich so eine Diskussion nicht auf die Corona-Warn-App fokussieren, sondern müsste ebenso fragen, wieso wir überhaupt so große Hoffnungen in diese Lösung gesetzt haben oder warum wir andere Länder nicht für Vorbilder halten sollen.
  • Die Forderung nach extremem Datenschutz wird in Bezug auf die Corona-Warn-App gerne damit begründet, er sei für das Nutzervertrauen essenziell und damit Voraussetzung für deren Akzeptanz. Ganz so einfach ist es wohl nicht. Die real existierende Corona-Warn-App wird dennoch wegen Datenschutzbedenken abgelehnt und in Wirklichkeit treiben persönliche Befindlichkeiten die Nutzung oder Nichtnutzung.
  • Seit sich zeigt, dass die Corona-Warn-App keine Wunder wirkt, rückt endlich die – den Sommer über offenbar nicht verbesserteIT-Ausstattung und Organisation der Gesundheitsämter ins Blickfeld. Nun sollen sie doch endlich alle SORMAS bekommen, aber mitten in der zweiten Welle ist ein schlechter Zeitpunkt, um neue Software einzuführen. Hier und da hat man auch selbst etwas entwickelt. Hätte uns doch nur rechtzeitig jemand gesagt, dass es SORMAS gibt, dass digitale Unterstützung der Pandemiebekämpfung verschiedene Formen annehmen kann und dass es auf die Anforderungsanalyse ankommt und nicht auf Architekturideologie.
  • Noch weniger Erfolg als die Corona-Warn-App hat die Datenspende-App des RKI. Dafür war sie schnell verfügbar und wirbelte wenig Staub auf. Eigentlich ein gelungenes Experiment, auch wenn das Ergebnis enttäuscht. Sollten wir öfter machen.
  • Die digitale Einreiseanmeldung ist keine App geworden, sondern eine einfache Website.
  • Mit der Aussicht auf bald beginnende Impfungen kommen auch digitale Impfpässe näher. Besonders die Luftfahrt hat Interesse an leicht und schnell zu prüfenden Impfnachweisen. Da alle Datenschutzaktivisten damit beschäftigt sind, die Corona-Warn-App zu verteidigen, könnte das ohne große Diskussion durchgehen.
  • Zu guter Letzt werden die britischen Apps zur Kontaktverfolgung miteinander vernetzt. Man könnte fast meinen, das Vereinigte Königreich wäre eine kleine EU.

Eigentlich ist also alles wie immer: Digitalisierung und Seuchenbekämpfung verkackt, Datenschutz hochgehalten, und weiterwurschteln. Bis zum nächsten Mal – am 31.12. feiert Covid-19 seinen ersten Geburtstag – wird sich daran wenig ändern.

Scheinalternative Manufaktur-EDV

„Es gibt sie noch, die guten Dinge“, wirbt ein Einzelhändler, der sich auf altmodische, handgefertigte Haushaltswaren spezialisiert hat. Wer es geil findet, einen Tischfernsprecher W 48 – außen Bakelit®, innen solide Nachkriegselektrik, Digitalkonverter separat erhältlich – in sein Wohnzimmer zu stellen oder den Rasen seines Anwesens mit einem handbetriebenen Spindelmäher kurz zu halten, wird dort zu gesalzenen Preisen fündig.

Nüchtern betrachtet ergibt solch ein Kauf wenig Sinn. In derselben Preisklasse bekommt man als Gegenwartstechnik ein Smartphone oder einen Mähroboter und damit viel mehr Leistung für sein Geld. Der bloße Kauf eines altmodischen Manufakturprodukts mag noch wie eine Geschmackssache wirken, in der man sich willkürlich so oder so entscheiden kann. Doch über die Nutzungsdauer betrachtet zahlt man beim Manufakturprodukt verglichen mit seinen zeitgemäßen Nachfolgern fortwährend drauf. Deswegen kaufen Menschen nur dann „die guten Dinge“, wenn ihnen diese Folgekosten egal sind, etwa weil es sich um ein Geschenk mit externalisierten Kosten handelt oder weil sie mit einem Statussymbol unaufdringlich Vermögen demonstrieren möchten.

„Es gibt sie noch, die guten Dinge“, behaupten auch Technik- und Kulturpessimisten, denen der Fortschritt zu schnell fortschreitet und ob das denn nötig sei und nicht am Ende unsere Jugend verdürbe. Die guten Dinge, das sind ihnen Telefonate statt Videokonferenzen, selbst betriebene Open-Source-Anwendungen, Endgeräte und Anwendungen ohne Telemetrie und dergleichen mehr. Der Rest der Welt hat sich derweil an Videokonferenzen gewöhnt, wartet sehnlichst darauf, dass öffentliche Einrichtungen wie Schulen und Ämter endlich in der IT-Gegenwart ankommen, und nutzt selbstverständlich Anwendungen und Plattformen aus der Steckdose.

Die angeblich guten Dinge ähneln ihren Vorbildern aus dem Reich der Haushaltswaren. Wäre das Telefon eine ebenbürtige Alternative zur Videokonferenz, gäbe niemand Geld für Videokonferenzdienste aus. Dass es doch alle tun, liegt daran, dass es sich eben nicht nur um eine Art Bildtelefon handelt, sondern um Anwendungen für multimediale 1:n- und m:n-Kommunikation. Wo das Telefon genügt, greifen Menschen von alleine zu diesem, aber das Telefon kann im Vergleich zur Videokonferenz ungefähr so viel wie ein Tischfernsprecher W 48 im Vergleich zum Smartphone.

Auch Telemetrie und Cloud Computing entspringen nicht etwa einem gemeinen Weltherrschaftsplan amerikanischer Überwachungskapitalisten, sondern schlicht technisch-ökonomischem Fortschritt, der selbst und autark betriebene Anwendungen nach und nach zu einem Thema für die Geschichtsbücher macht. Dahinter steckt ein Prozess der Kommoditisierung, den jede Infrastrukturinnovation durchläuft. Anwendungen wandern im aus denselben Gründen von eigenen Servern in die Cloud, aus denen einst Dampfmaschinen in Kraftwerke und die Inhalte von Sparstrümpfen auf Bankkonten wanderten: Weil es möglich wurde und sich als effizienter erwies.

Die Vorteile sind offensichtlich. Dieses Blog hier zum Beispiel läuft komplett in der Cloud, bei wordpress.com. Ich muss mich um nichts anderes kümmern als die Inhalte: keine Server betreiben, keine Software installieren, keine Updates einspielen, kein Backup machen, nicht nach Einbrüchen aufräumen. Ich muss mir nur mein Passwort merken und, wenn ich es schön haben möchte, jedes Jahr ein paar Euro bezahlen. Alles selbst zu machen, wäre in der Summe teurer bei einem schlechteren Ergebnis, deshalb lasse ich das.

Dass dieses Geschäft funktioniert, liegt an Skaleneffekten: Durch Massenproduktion sinken die Kosten pro Stück. WordPress.com betreibt mein Blog nicht auf dieselbe Weise, wie ich es tun würde, also mit einem dedizierten und individuell administrierten Server, sondern auf einer eine Plattform mit Millionen von Blogs und Benutzern. Die Grenzkosten für ein einzelnes Blog verschwinden praktisch. Deshalb kann wordpress.com jeden Aufwand unterbieten, den ich für die Leistung „funktionierendes Blog“ in derselben Qualität betreiben müsste. Manufaktur ist teurer als Massenproduktion, in der Anschaffung wie im Betrieb.

Der Trend zum Software-Service betrifft nicht nur Anwendungen, sondern auch das, was wir früher Betriebssystem nannten und was heute den Charakter eine Managed Platform hat. Früher baute man seine Computersysteme selbst: schaffte Hardware an, installierte Betriebssysteme darauf und schließlich Anwendungsprogramme, organisierte den Betrieb des teuren Geräts zum Beispiel mit regelmäßigen Datensicherungen und Virenscans. Wer wollte, konnte den Computer später für einen anderen Zweck verwenden, indem er diesen Prozess mit demselben oder einem anderen Betriebssystem und neuen Anwendungen erneut begann.

Heute sind Geräte austauschbar und Betriebssysteme eine Dienstleistung. Wir haben Benutzerkonten bei Apple/Google/Microsoft, die wir mal mit diesem, mal mit jenem Gerät nutzen. Kommt mal ein Gerät weg, tritt man es online aus allen Diensten raus, stellt ein neues hin und macht dort weiter, wo man aufgehört hatte. An der Software der Endgeräte herumzubasteln, macht noch weniger Sinn als ein eigener Anwendungsbetrieb.

Themen wie Telemetrie in Windows und Office oder auch Apples automatischer Sicherheitscheck beim Programmstart, der neulich einen kurzen Aufruhr auslöste, muss man in diesem Kontext betrachten. Es hat keinen Sinn mehr, sich über „nach Hause telefonierende“ Software zu erregen. Der Normalfall ist, dass Software in der Cloud läuft und dort betreut und weiterentwickelt wird; teilautonome Endgeräte werden stattdessen als Näherungslösung so an die Cloud angeschlossen, dass man ihren Benutzern trotzdem Stress mit der Systemadministration ersparen kann. Und das ist gut, denn inzwischen kann man auch Laien einen Internetapparat anvertrauen, ohne ständig auf sie aufpassen zu müssen.

In der konsequentesten Umsetzung bekommt man am Ende einen Thin Client wie Googles Chromebook als Interface zur Cloud, bei dem lokale Anwendungen keine Rolle mehr spielen. Dann bereitet das einzelne Gerät praktisch keinen Administrationsaufwand mehr, weil es nur noch einen Browser booten muss, der durch ein Benutzerlogin an einem Cloudservice personalisiert wird. Damit lässt sich zum Beispiel ein Laptopverleih organisieren, wie ihn die ULB Darmstadt anbietet. Einige sind der Ansicht, dass dies auch für den Schulbetrieb genau der richtige Ansatz sei.

Wer unbedingt in einem Gefühl digitaler Souveränität schwelgen möchte, kann das alles auch nachbauen. Das wird jedoch voraussichtlich ein teures und zeitraubendes Projekt. Man bekommt eben nicht dasselbe, indem man mal schnell einen Linux-Server mit ein paar Open-Source-Paketen aufsetzt, sondern müsste schon das ganze System und dessen Betrieb replizieren und außerdem in die Weiterentwicklung investieren wie ein etablierter Cloudversorger. Das kann man tun, aber es ist nicht die beste Idee, wenn man gerade etliche Jahre verschlafen hat und einen nun auch noch eine Viruspandemie zu schnellem Handeln zwingt. Obendrein hält ein in der Hinterhofwerkstatt aus Subprime-Software zusammengefrickeltes System in Sachen SIcherheit und Datenschutz nicht unbedingt, was seine Verfechter versprechen. So fiel die häufig genannte Videokonferenzsoftware Big Blue Button kürzlich mit langen Reaktionszeiten auf gemeldete Sicherheitsmängel auf. Dort hätte man also nachzuarbeiten.

Es gibt sie noch, die guten Dinge, doch sie sind gar nicht gut, sondern alt, rückständig, umständlich produziert. Dennoch empfohlen werden sie als Scheinalternative von Akteuren, denen niemand die Kosten ihrer Ratschläge in Rechnung stellt, die sich jedoch eigene – nicht-monetäre – Gewinne erhoffen. Datenschutzbeauftragte sollen schnellen Fortschritt in der IT nicht fördern, sondern bremsen und ihre Arbeit beruht auf Gesetzen und Traditionen, welche die Datenverarbeitung unter den Generalverdacht der Grundrechtsgefährdung stellen. Vereinsinformatiker können sich umso wichtiger fühlen, je komplizierter Informationstechnik zu nutzen ist, je exklusiver also ihre Expertise bleibt. Verbraucherschützer benötigen einen Antagonisten, und sei es ein erfundener wie die „Prägung“ von Schülerinnen und Schülern auf Microsoft-Produkte und die angebliche Vermarktung ihrer Verhaltensdaten durch Microsoft. All jene, die tatsächliche Kosten gegen den tatsächlichen Nutzen abwägen müssen, sind mit zeitgemäßen Services besser bedient als mit Manufakturalternativen. Wer nicht möchte, dass deren Anbieter Microsoft oder Google heißen, muss konkurrenzfähige Alternativen als Dienstleistung anbieten und nicht Software zum Selbermachen empfehlen.

CoronApp-News Oktober 2020

Jetzt bleiben wir wieder eine Weile zu Hause, ob bis zum Advent oder bis Ostern, ist noch nicht raus. Viel Zeit zum Lesen:

Die nächste Zusammenfassung gibt es, wenn das Klopapier alle ist.

Digitale Scharlatane

Chatbots gelten den EDV-Experten in deutschen Amtsstuben heute als so modern und zukunftsweisend wie einst die Blockchain-Technologie. Wieder einmal überschätzen sie banale Technik grandios, ohne sich um den Anwendungsnutzen und die Benutzerinteraktion zu scheren. Oder wissen sie, was sie tun und setzen Chatbots aus denselben Gründen auf, aus denen sich Kleinstadtbürgermeister bei feierlichen Eröffnungen neuer Spielplätze oder Radwege fotografieren lassen, nämlich um dabei gesehen zu werden? Immerhin gelten Chatbots in Deutschland als zukunftsträchtige KI, damit zeigt man sich gerne.

Die Bundesverwaltung zeigt sich aus aktuellem Anlass mit dem Chatbot C-19 zum Thema Coronavirus. Nach eigener Aussage hat man weder Kosten noch Mühen gescheut, um dieses zukunftsweisende Technologieprojekt umzusetzen:

„Hinter C-19 steht ein interdisziplinäres Team in den beteiligten Ministerien und Ämtern, beim Beauftragten der Bundesregierung für Informationstechnik und beim IT-Dienstleister des Bundes. Das Team besteht aus Programmiererinnen und Programmierern, Trainerinnen und Trainern, Redakteurinnen und Redakteuren, Softwarearchitektinnen und -architekten, Administratorinnen und Administratoren und weiteren Wegbegleiterinnen und Wegbegleitern sowie Fürsprecherinnen und Fürsprechern, die ihn mit Informationen versorgen, beim Lernen unterstützen und sich um das Wohlergehen von C-19 kümmern.“

Müsste ich raten, wo das Budget herkommt, würde ich auf die KI-Strategie der Bundesregierung tippen, denn die Bundesregierung möchte, dass wir KI-Weltmeister werden, und wenn die Regierung etwas möchte, dann ist das in den Amtsstuben Gesetz. Unter diesen Umständen kann man nicht nicht KI machen und so verspricht man das Blaue vom Himmel:

„In Form eines Chats kann C-19 mit Ihnen ein Gespräch führen und soll Ihnen als Bürgerinnen und Bürgern so den Zugang zu fachlichen Inhalten der Ministerien, Ämter und Institutionen des Bundes erleichtern. Er ist um Antworten nicht verlegen und ist sogar bereit, aus Ihren Fragen mehr zu lernen und seine Wissensbasis zu Corona stetig zu erweitern. Mit C-19 wird ein Prototyp für den Aufbau einer bürgernahen Kommunikation mit Hilfe einer lernenden Technologie entwickelt.“

Nicht nur diesem Anspruch wird C-19 nicht gerecht, sondern auch keinem anderen vernünftigen. Gespräche führen kann der „Chatbot“ schon mal nicht, das überfordert ihn:

screenshot-2020-10-13-at-22.01.21

Am besten füttert man C-19 einfach mit Stichworten wie eine Suchmaschine. Dann verhält er sich auch wie eine Suchmaschine und liefert Ergebnisse:

Screenshot 2020-10-14 at 00.30.30

Eine unmittelbare Antwort auf seine Frage bekommt man selten, auch wenn man eine formuliert, sondern in aller Regel einen Link und dazu einen Sermon unterschiedlicher Länge in schönstem Bürokratendeutsch:

Screenshot 2020-10-14 at 00.03.43

Manchmal bekommt man auch nur den Sermon und keinen Link dazu. Ob es sich auch um eine Antwort auf die gestellte Frage handelt, bleibt dabei Glückssache:

Screenshot 2020-10-13 at 12.20.27

Irgendwann muss auch dem interdisziplinären KI-Projektteam klargeworden sein, dass es sich bei seinem Chatbot in Wirklichkeit um eine banale Websuche handelt. Bietet C-19 weitere Informationen an, kann man direkt aus einem Menü wählen, welches dann – auf dem Umweg über ein inszeniertes Selbstgespräch des Bots – das Ergebnis liefert:

Screenshot 2020-10-13 at 22.03.53

C-19 ist also in Wirklichkeit eine Suchmaschine, die sich hinter einem chatartigen Interface verbirgt, dadurch umständlich zu nutzen ist und ihre Tarnung nur kurz durchhält. Das ist keine Kinderkrankheit, die sich irgendwann gibt, sondern Resultat eines Vorgehens, in dem Benutzerinteraktion und Anwendungsnutzen keine Rolle spielen. Das Entwicklungsziel lautete anscheinend nicht, eine sinnvoll und leicht verwendbare Anwendung, Funktion oder Informationsdarstellung anzubieten, sondern um jeden Preis mit einem Chatbot gesehen zu werden.

Wer sich nur ein wenig mit Interaktionsdesign beschäftigt, kommt schnell darauf, dass der Austausch wohlformulierte Sätze in natürlicher Sprache selten der geeignetste, einfachste  Modus der Mensch-Maschine-Interaktion ist. Eingaben werden nicht einfacher, wenn man ganze Sätze tippt, sondern anstrengender; diese Anstrengung bleibt vergebens, wenn der Computer am Ende doch nur auf Stichworte reagiert oder schlechte Antworten gibt.

Ausgaben müssen knapp und prägnant sein und dürfen wesentliche Informationen nicht in nutzlosem Rauschen verstecken. Styleguides für Benutzerschnittstellen sind deshalb voll von Empfehlungen, wie man Rauschen entfernt. Schon die Frage: „Möchten Sie mehr erfahren?” ist als Beschriftung eines Buttons zu lang, „Mehr erfahren“ oder auch nur „Mehr“ spart allen Zeit. Selbst bei kürzeren Texten sorgt die Chatdarstellung für eine geringe Informationsdichte auf dem Bildschirm und bietet keine Möglichkeit, alle relevanten Informationen oder eine übersichtliche Aufstellung derselben auf einen Schlag auf den Schirm zu bekommen.

Mit Vorteilen hat man sich diese Defizite nicht erkauft. C-19 lässt selbst offensichtlichste Gelegenheiten zur Interaktion ungenutzt. Erklärt etwa jemand der Suchmaschine, einige Symptome einer Infektion zu verspüren, böten sich Rückfragen nach weiteren Symptomen sowie umfassende, klare Verhaltensmaßregeln an. Doch so weit wollte niemand denken:

Screenshot 2020-10-13 at 22.37.00

Was stattdessen herauskommt, wenn man tatsächlich nützliche Informationen sinnvoll verfügbar machen möchte, die Benutzerinteraktion ausgehend von diesem Ziel gestaltet und über die erforderliche Designkompetenz verfügt, demonstriert Google. Dort muss man nicht einmal seine Anfrage selbst zu Ende tippen, sondern bekommt nach wenigen Wörtern den passenden Fortsetzungsvorschlag:

Screenshot 2020-10-13 at 12.30.17

Dessen Auswahl liefert ein sorgfältig aufbereitetes Ergebnis: Verhaltensmaßregeln in wenigen einfachen Hauptsätzen ohne ein überflüssiges Wort oder in Stichpunkte, Verweise auf weitere Informationen sowie leichter Zugang zu Antworten auf ähnliche Fragen, alles übersichtlich aufbereitet mit einer hohen Informationsdichte und schnell zu erfassen.

Screenshot 2020-10-13 at 12.31.35

Wer etwas allgemeinere Stichwörter als Suchbegriffe eingibt, bekommt so viel Information, wie sich auf einer Bildschirmseite unterbringen lässt:

Screenshot 2020-10-13 at 22.52.54

Auch auf die unspezifische Symptomschilderung liefert Google zwar keine Rückfrage, aber eine passende Antwort:

Screenshot 2020-10-13 at 22.56.15

Hinzu kommt, dass Google jeder kennt und dass das bis auf einige zwanghafte Nonkonformisten auch jeder dort sucht, während man vom Chatbot C-19 der Bundesverwaltung nur zufällig erfährt. Mich hat das Randgruppenmedium Twitter auf C-19 aufmerksam gemacht.

C-19 ist nutzlos. Der Chatbot ist keiner, seine Gestaltung lässt keine kompetenten Bemühungen um Nutzen und Usability erkennen und mit der Suchmaschine Google sind wir besser bedient. Das wird sich auch nicht ändern, wenn man weiter am Bot herumbastelt, denn der gewählte Ansatz ist nicht fortschrittlich, sondern unsinnig und kein Stück nutzerorientiert. Zu befürchten ist jedoch, dass man noch lange daran herumbasteln wird, aus denselben Gründen, aus denen man damit begonnen und sein Scheitern nicht bemerkt hat.

Kein Wunder, dass es mit der Digitalisierung der Verwaltung so schleppend vorangeht, wenn maßgeblichen Akteuren das Immunsystem gegen Scharlatanerie fehlt. Wir sind nicht mehr nur digital rückständig, wir verlieren langsam den Kontakt zur Realität. Zwischen dem „Chatbot“ der Bundesverwaltung und einem sinnvoll gestalteten User Interface nach dem Stand der Kunst liegen Welten und sie liegen nicht hinter, sondern vor dem Bot. So wird das nichts mit der digitalen Souveränität.

PS (2020-10-21): Wenigstens die Erfahrungen mit Karl Klammer alias Clippy sollte man kennen, wenn man was mit Chatbots machen möchte.

Open Source staatlich fördern?

In einem Beitrag auf Heise Online plädiert Julia Reda für eine europäische Förderung von Open-Source-Soft- und Hardware. Die Sprunginnovationsagentur pflichtet ihr bei und verweist auf ihr Förderprojekt Sovereign Cloud Stack. Open-Source-Projekte zu fördern, ist eine gute Idee, aber die damit verbundenen Erwartungen erscheinen mir überhöht und nicht klar genug. Open Source soll die Sicherheit verbessern, Europa unabhängiger von großen, ausländischen IT-Unternehmen machen, Alternativen zu erfolgreichen Onlinediensten von Cloud Computing bis Videokonferenzen bereitstellen und Demokratiebewegungen in anderen Ländern unterstützen [Klarstellung dazu]. In diesem Potpourri liegt die Gefahr, sich zu verzetteln und Blütenträume zu fördern.

Open-Source-Produkte nehmen wie ihre kommerziellen Konkurrenten auf der Angebotsseite am Marktgeschehen teil. Zwar kann man sie einsetzen, ohne eine Lizenzgebühr zu zahlen, doch steht die Wahl auf der Nachfrageseite jedem Anwender frei. Vernünftig handelnde Anwender werden sich für diejenige Lösung entscheiden, die gemessen an ihren Bedürfnissen das beste Kosten-Nutzen-Verhältnis verspricht. Repräsentiert das beobachtete Marktgeschehen die Ergebnisse vernünftiger Entscheidungen, können wir die Faktoren analysieren, die zu diesen Entscheidungen beitragen.

Der Markt zeigt immer wieder, dass Open-Source-Anwendungen nur in Nischen konkurrenzfähig sind. OpenOffice, Firefox, Linux als Desktop-Betriebssystem oder der Messenger Signal sind verfügbar, doch ihre Nutzerzahlen bleiben überschaubar, von Marktführerschaft keine Spur. Der Anonymisierungsdienst Tor zielt gar von vornherein auf eine Nische, er ist nur für Randgruppen relevant und für die Mehrheit nicht alltagstauglich. Besser schlägt sich Open-Source-Software dort, wo sie Anwender nicht zu Gesicht bekommen: Als Softwareinfrastruktur in Anwendungen verborgen und in Entwicklerwerkzeugen spielen Open-Source-Projekte wie Linux, die Apache-Projekte, OpenSSL, Eclipse und viele andere eine bedeutende Rolle. Das ist kein Zufall.

Der Markt für Softwareinfrastruktur lässt wenig Raum für dauerhafte Konkurrenz verschiedener Anbieter vergleichbarer Produkte, etwa verschiedener Webserver oder Unix-Kernel. Standardisierung, zum Beispiel von Protokollen, lässt wenig Raum für sinnvolle Produktdifferenzierungen. Zugleich bringen konkurrierende ähnliche Produkte kostspielige Kompatibilitätsprobleme mit sich, die wiederum zu Standardisierungsversuchen führen. Wer einmal Software zwischen verschiedenen Unix-Variantenportiert hat, kann ein Lied davon singen. Auch in der Qualität können sich unterschiedliche Anbieter nicht nennenswert voneinander abheben, weil die Anforderungen an alle dieselben sind.

Jede konzeptionell weitgehend ausentwickelte Komponente nur einmal statt in mehreren unabhängigen Varianten zu pflegen, ist deshalb optimal. Nicht optimal wären jedoch Herstellermonopole, die für das einzige Produkt seiner Art Mondpreise kassieren. Deshalb ist es für alle besser, Komponenten der Softwareinfrastruktur als eine Art Allmende zu behandeln, die allen zur Verfügung steht und alle zur Mitarbeit einlädt. Weil alle davon profitieren, gibt es wenig Förderbedarf. Es ist der Markt, der Open-Source-Software hier zum Erfolg führt. Die Linux-Foundation zum Beispiel wird von großen IT-Unternehmen und der Fondsgesellschaft BlackRock finanziert.

Anders funktioniert der Markt für Anwendungen und anwendungsnahe Dienste, denn sie bieten in vielen Merkmalen Differenzierungspotenzial und damit Raum für Konkurrenz. Deswegen kann man ERP-Systeme von SAP oder von Oracle kaufen, Browser von Google, Microsoft, Mozilla oder Brave, Office-Software von Microsoft oder Google und so weiter. Zu den wichtigen Merkmalen zählt nicht zuletzt der Preis, genauer die Gesamtkosten der Nutzung. Dass sich Open-Source-Alternativen hier selten durchsetzen können, deutet darauf hin, dass sie in der Gesamtsicht nicht das attraktivste Produkt liefern. Besonders deutlich wird dies, wo selbst betriebene Open-Source-Software gegen kommerzielle Anwendungsdienste antreten, etwa Jitsi und BigBlueButton gegen Zoom, aber auch im Vergleich verschiedener Dienste wie Signal gegen WhatsApp.

Von den Verfechtern der OSS-Alternativen gerne ignoriert oder kleingeredet, zeigen sich in vielerlei Hinsicht Defizite. So hinkte Signal im Funktionsumfang WhatsApp hinterher und ging seinen Nutzern auf die Nerven. Selbst gehostete Videokonferenzdienste verursachen Arbeitsaufwand und brauchen eine Vorlaufzeit, bis sie einsatzfähig sind, während man mit Zoom auf der Stelle loslegen kann. Ob man mit den Alternativen wirklich sicherer ist, liegt auch nicht so klar auf der Hand. Wer nüchtern hinschaut, findet die Gründe dafür, dass die Open-Source-Alternativen alternativ bleiben. Daran kann auch OMG-ihr-bezahlt-mit-euren-Daten!!1-Rhetorik bei kostenlos angebotenen Diensten nichts ändern, denn das ist offensichtlich für viele ein fairer Deal.

Analog gilt dies auch für hochwertige Clouddienste a.k.a. Platform as a Service (PaaS). Dort bekommt man für sein Geld nicht einfach Software, sondern eine Plattform, welche die Entwicklung und den Betrieb von Anwendungen erleichtert und den Einsatz von IT-Ressourcen flexibel anpassbar macht. Software ist dafür nur Mittel zum Zweck und die Dienstleistung steckt nicht im Programmcode.

Um es mit den etablierten kommerziellen Anbietern von Anwendungsdiensten und Cloudplattformen aufnehmen zu können, müsste man überlegene Dienste anbieten, ähnlich wie Airbus einst ein fortschrittliches Flugzeug auf den Markt gebracht hat. Open-Source-Software kann dafür Basiskomponenten gemäß dem oben skizzierten Allmendemodell bereitstellen, aber diese Baseline ist alleine gerade nicht konkurrenzfähig, sondern ein allgemein verfügbarer kleinster gemeinsamer Nenner. Den kann man lange fördern, ohne dass er sich je von irgend etwas positiv abhebt.

In keinem der beiden Segmente kann eine großzügige staatliche Förderung von Open-Source-Projekten den Markt umkrempeln. Stattdessen bekäme man künstliche Open-Source-Projekte wie die AusweisApp2 oder die Corona-Warn-App, die zwar Einblicke in den Quelltext und die Entwicklung gewähren sowie Community-Kontakte pflegen, letztlich aber Auftragsarbeiten bleiben. Das heißt nicht, dass es falsch wäre, öffentliche Entwicklungsprojekte so weit wie möglich zu öffnen, aber das bleibe eine eigene Spielart von Open Source.

Die Hoffnung, mit staatlich geförderten Open-Source-Projekten endlich die technologische Lücke von 1969 zu schließen, wird sich nicht erfüllen. Dennoch gibt es Potenziale für sinnvolle staatliche Förderungen. Die Strategien ergeben sich aus den beiden diskutierten Modellen.

Auf dem Gebiet der Softwareinfrastruktur kann der Staat als Stakeholder für wünschenswerte Eigenschaften wie Qualität, Sicherheit und Weiterentwicklung auftreten. Das FOSSA-Projekt der EU passt genau in dieses Muster. Europäische Alternativen und Europäische Souveränität entstehen dadurch jedoch nicht. Im Gegenteil, solange sich IT und Internet im Industriemaßstab eher außerhalb als innerhalb Europas abspielen, handelt es sich tendenziell um ein Geschenk an die Konkurrenz. Bleiben lassen muss man es deswegen nicht, aber mit realistischen Erwartungen herangehen.

Bei den Anwendungen und anwendungsnahen Diensten hat Förderung nur einen Sinn, wenn sie auf konkurrenzfähige Angebote zielt. Open Source wird dabei zum Nebenaspekt, im Vordergrund steht das Produkt aus Anwenderperspektive, das besser und kostengünstiger sein muss. Wer also Zoom oder WhatsApp doof findet, muss objektiv bessere Dienste objektiv preiswerter anbieten (und im Fall von WhatsApp noch mit den unvermeidlichen Netzwerkeffekten fertig werden). Es gibt sogar noch ein Spielfeld, auf dem es eher auf die Software als auf die Dienstleistung ankommt: Webbrowser. Chrome ist zurzeit unangefochtener Marktführer, Mozilla siecht dahin. Ein solide finanzierter unabhängiger Browser mit allem, was daran hängt, bleibt dringend nötig. Nebenbei bekäme man einen Träger für Datenschutztechnik, die uns das unsägliche Zustimmungsgeheische im Web erspart, und könnte bei der Webstandardisierung mitreden.

Keimzelle einer neuen europäischen Informationstechnikbranche wäre auch das nicht, aber es wäre sinnvoll. Im Gegensatz zum Versuch, spezifisch und strategielos das Attribut „Open Source“ zu fördern.

CoronApp-News (2020-08-23)

Der Sommer neigt sich dem Ende zu und langsam könnte eine Corona-Warn-App ihren Nutzen beweisen, aber anscheinend glaubt kaum noch jemand daran:

Nicht gehört habe ich in den letzten Tagen von den Bemühungen um eine europaweite Integration der nationalen Corona-Apps. Weiß man, wie es darum steht?

CoronApp-News (2020-08-09)

Corona-Apps füllen das diesjährige Sommerloch ganz gut  aus:

  • Ein Kommentar von Patrick Bernau zeigt noch einmal die Nebenwirkungen des rigiden technischen Datenschutzes im Exposure Notification Framework und der darauf basierenden Corona-Warn-App auf. Zudem macht er auf eine interessante Begründung aufmerksam: Eine weltweit verbreitete Plattform müsse auch in Gegenden mit geringer ausgeprägter Demokratie und Rechtsstaatlichkeit ohne Nebenwirkungen funktionieren. Apple und Google liefern uns als den technischen Datenschutz, den wir uns wünschen würden, lebten wir in einem Schurkenstaat.
  • Die Zeitschrift Connect hat die Corona-Warn-App auf Sicherheitsmängel untersuchen lassen, ohne dass dabei nennenswerte Probleme aufgetaucht wären. SAP ist stolz wie Oskar.
  • Unterdessen hakt es immer noch bei der Anbindung der Testlabore an die Infrastruktur der Corona-Warn-App. Anstelle des eigentlich vorgesehenen Verfahrens – beim Corona-Tets erhält man einen QR-Code, registriert damit seine App anonym als Empfänger für das Testergebnis und kann bei einem positiven unmittelbar eine Warnung an seine Kontaktpersonen auslösen – müssen App-Nutzer weiterhin häufig die Hotline bemühen, falls ihr Test positiv ausfällt und sie warnen möchten.
  • Was die App am Ende bringt und wie oft sie falsch liegt, ist auch unabhängig davon noch nicht geklärt. Eine Statistikprofessorin hat ein Modell entwickelt, mit dem man online spielen kann, um die theoretische Maximalleistung unter verschiedenen Annahmen zu ermitteln. Dieses Modell geht davon aus, dass alle Beteiligten die App nutzen.
  • Seit Anfang August hat auch Kanada eine App zur Kontaktverfolgung, COVID Alert.
  • Zu guter Letzt schreit auch die Erfassung von Kontaktdaten in Restaurants etc. weiter nach einer guten Lösung. In Baden-Württemberg müssen Restaurantbesucher jetzt keine E-Mail-Adresse mehr angeben – die Gesundheitsämter dürfen ihnen aus Datenschutzgründen ohne Einwilligung keine unverschlüsselte E-Mail schicken und E-Mail verschlüsseln kann kein Mensch, weil es keiner braucht.

Schönen Montag!

CoronApp-News (2020-07-19)

Neue Regierungen bekommen hundert Tage Zeit, neue Apps nur vier Wochen:

  • Einen Monat nach ihrem Start zieht das RKI eine positive Zwischenbilanz und meldet knapp 16 Millionen Downloads. Wie viele Menschen die App tatsächlich benutzen, bleibt unklar. Etwa 500 positiv Getestete hatten bisher die Möglichkeit, eine Warnung ihrer Kontakte auszulösen. Wie viele Warnungen an wie viele Kontaktpersonen tatsächlich verschickt wurden, weiß man jedoch nicht.
  • Die Entwicklungsarbeit an der Corona-Warn-App geht weiter. Neben Fehlern und den zugangsbeschränkenden Systemanforderungen der App – neben alten Smartphones bereitet auch das neueste iOS 14 Probleme – bleibt die Anbindung der Testlabore kritisch. Als Folge davon wurde noch kein einziger Corona-Test auf dem eigentlich vorgesehenen Weg per QR-Code in der App registriert. Die alternativen Meldewege führen zu Verzögerungen.
  • Zweifel gibt es weiter an der Verlässlichkeit der Bluetooth-Entfernungsmessung, die in die Risikobewertung von Kontakten einfließt. Auch funktionale Fragen tauchen immer wieder auf.
  • Auf sich warten lässt die EU-weite Integration der nationalen Warn-Apps. Auf der Smartphone- und Bluetooth-Seite gibt es wenig Integratioshindernisse zwischen jenen Apps, die ich auf das Exposure Notification Framework von Apple und Google stützen, doch die Vernetzung der Backends braucht offenbar etwas länger.
  • Langsam dämmert auch den Letzten, dass sich die Bundesregierung im April nicht so sehr für eine datenschutzfreundliche dezentrale Architektur entschieden hat, sondern tatsächlich wohl vor allem für das Framework von Apple und Google. Pragmatisch war das unter den gegebenen Umständen nahezu alternativlos, aber es handelt sich eben nicht um eine freie, souveräne Architekturentscheidung.
  • Zu guter Letzt bleibt jenseits der Coron-Warn-App das Thema Kontaktdatenerfassung in Restaurants etc. auf der Tagesordnung. Einige sind überrascht davon, dass in einigen Fällen die Polizei die gesammelten Daten für Ermittlungen nutzt, aber das ist wahrscheinlich erlaubt. Auf eine Erweiterung der Corona-Warn-App zur Erfassung solcher Besuche warten wir hingegen vergebens, ebenso auf einen flächendeckenden digitalen Ersatz für manuell ausgefüllte Formulare.

Bis nächstes Wochenende.

CoronApp-News (2020-07-12)

Eigentlich könnten wir uns in Sachen Corona-App zurücklehnen und abwarten, aber die Debatten gehen weiter:

Voraussichtlich wird es auch nächste Woche wieder Neues zu melden geben.

CoronApp-News (2020-06-28)

Der Wochenrückblick, wie immer nicht nach Erscheinungsdatum, sonder danach, wann ich über die Links gestolpert bin:

Das war’s für diese Woche.

CoronApp-News (2020-06-21)

Habemus Appam! Vielleicht genau zur rechten Zeit, denn die Fallzahlen steigen wieder.

Wie angekündigt ist die Corona-Warn-App seit Dienstag verfügbar und wurde nach Angaben des RKI bis gestern mehr als zehn Millionen Mal heruntergeladen. Falls sie danach auch von allen aktiviert wurde, entspricht das einem Verbreitungsgrad von 13%, womit jeder 65. zufällige Kontakt erkannt werden könnte. Den Datenverkehr der App wollen die Mobilfunk-Provider kostenlos spendieren. Wie man die App aktiviert und benutzt, erklärt unter anderem Heise Online. Eine Datenschutzfolgenabschätzung wurde kurz vor der App selbst veröffentlicht.

Die Bundesregierung ist stolz wie Oskar, weil die Entwicklung seit der Entscheidung für Apple, Google, SAP und Telekom ziemlich gut funktioniert hat, und das Projekt wird auch von anderen gelobt. Jedoch verstummt die Kritik nicht ganz. Der Verein Digitalcourage hält die App für ein Plazebo mit Nebenwirkungen, das Twitter-Echo darauf fiel jedoch eher negativ aus. Der Chef des VZBV empfiehlt die App, warnt jedoch noch einmal vor App-gestützten Einlasskontrollen. Diese Befürchtung wurde zum Release vielfach geäußert, hat sich bislang jedoch offenbar kaum bewahrheitet. Alvar Penning, Jonas Höchst und Bernd Freisleben kritisieren die relative Offenheit der Entwicklung als halbseiden, da ein wichtiges Teilsystem von Apple und Google bereitgestellt werde und eben nicht offen sei. So ganz Made in Germany ist die App eben doch nicht und anderswo fühlt man sich gar von Apple und Google bevormundet.

Wie sehr wir uns vor der Corona-Warn-App fürchten und warum, untersucht der Der Lehrstuhl Sozialpsychologie: Medien und Kommunikation der Universität Duisburg-Essen mit einer Umfrage.

Die App-Entwicklung ging manchen zu langsam und verlief anfangs holprig, wenn nicht gar als Drama mit entgleister Debattenkultur. Im Vergleich zu anderen öffentlichen IT-Projekten erscheint der Weg zu App dennoch recht reibunglos. Allerdings blieb sich auch die Komplexität vergleichsweise gering, nachdem die Smartphone-Plattformen den Lösungsweg und zentrale Komponenten vorgegeben hatten.

Einige Probleme gibt es dennoch. So klagen die Gesundheitsämter seit dem Start der App über unzählige Anrufe verwirrter Nutzerinnen und Nutzer. Auch im Hintergrund läuft noch nicht alles rund, denn viele Testlabore und Gesundheitsämter müssen erst noch angebunden werden, um App-Nutzern direkt Testergebnisse übermitteln zu können. Hier macht sich der Digitalisierungsstau im Gesundheitswesen und in der Verwaltung bemerkbar.

Auch sonst ist die Entwicklung der Corona-Warn-App noch lange nicht abgeschlossen. Neben Meldungen über Fehler und Unzulänglichkeiten sammeln die Entwickler auch Ideen für weitere Funktionen und zeigen ihre – noch recht knappen – Pläne für künftige Verbesserungen. Auch die europaweite Integration der nationalen Lösungen steht noch aus und wird einige Schwierigkeiten mit sich bringen.

International steht Deutschland plötzlich als leuchtendes Beispiel da. Fast zeitgleich mit dem Start hierzulande musste Norwegen seine schon länger bereitstehende App Smittestopp wegen Datenschutzbedenken auf Eis legen. Amnesty International hielt die norwegische App für eine der gefährlichsten weltweit und stellte sie in eine Reihe mit denen aus Bahrain und Kuwait. Das brexitanische App-Projekt versinkt unterdessen im Chaos und verschiebt seinen Release-Termin auf den nächsten Winter. Nachdem eine von Apples und Googles Exposure Notification Framework unabhängige Lösung bereits im Testbetrieb war, setzt man nun doch auf die Plattform-Lösung und stuft zugleich die Priorität der App herab. Die französiche App StopCovid, die ebenfalls ohne das Framework auskommt, scheint eher ein Flop zu werden.

Zu guter Letzt hat der Chef eines mittelständischen Betriebs in Köln so viel Angst vor der App, dass er sie seinen Beschäftigten rundweg verbietet.

 

#GaiaXFakten

Gaia-X soll der Chuck Norris unter den Clouds – nein, das passt nicht, zu wenig europäische Werte. Gaia-X soll die Abteilung für Informationswiederbeschaffung unter den Clouds werden, der Goldstandard, die digitale Mondrakete. Wäre Elon Musk Europäer, hätte er statt eines Tesla Gaia-X ins All geschossen. Gaia-X war einziger Teilnehmer eines Wettbewerbs der Agentur für Sprunginnovation und schloss diesen mit einem überdurchschnittlichen Ergebnis ab. Gaia-X heilt Krebs. Chatbots werden mit Gaia-X zu geistreichen Gesprächspartnern. Gaia-X wird alle Versionen des Trolley-Problems in einem Tweet lösen. Gaia-X transzendiert Raum, Zeit, Rechenzentren und Unternehmen. Gaia-X läuft nicht in der Cloud, sondern die Cloud läuft in Gaia-X. Gaia-X braucht kein Geschäftsmodell, sondern Geschäftsmodelle brauchen Gaia-X. Amazon kauft bei Gaia-X ein. Uber lässt sich von Gaia-X ein Taxi rufen. Gaia-X sitzt in den Aufsichtsräten aller europäischen Internet-Konzerne. Mit Gaia-X wird Deutschland E-Government-Weltmeister. Die Büros von Gaia-X arbeiten papierlos. Gaia-X hatte seine Corona-App schon vor der Schweinegrippe fertig. Die Konferenz der unabhängigen Datenschutzbehörden des Bundes und der Länder empfiehlt Videokonferenzen per Gaia-X als Alternative zur Briefpost.

PS (2020-06-11): Die Fortsetzung gibt’s häppchenweise bei Twitter.

CoronApp-News (2020-06-06)

Die Corona-App-Nachrichten der Woche:

Bis nächste Woche.

Nachtrag:

Gamifizierter Narzissmus

Mit der Industrialisierung entstanden Massenmedien. Bevor sie um die Gunst ihrer Leser, Hörer oder Zuschauer konkurrieren konnten, mussten sie sich erst einen der knappen Kanäle sichern. Teils hatte das technische Gründe, wie bei Funk und Fernsehen, teils wirtschaftliche, denn das Herausgeben einer Zeitung wie auch der Betrieb einer Rundfunk- oder Fernsehanstalt erfordern Kapital und deshalb einen Mindestumsatz pro Zeiteinheit.

Das Internet hat uns Jedermannmedien wie Twitter, Facebook oder Telegram gegeben. Dort kann jeder an alle senden, die ihm zuhören wollen. Begrenzt ist nur noch die Aufmerksamkeit des Publikums, um die sich alle balgen. Geld verdient dabei zunächst nur die Plattform, und zwar umso mehr, je mehr Aufmerksamkeit sie insgesamt binden kann. Dies gilt für die Werbung, die sich ein Stück vom Kuchen der Aufmerksamkeit abschneidet, ebenso wie für das Risikokapital, das sich eine Zeitlang mit schnell wachsenden Metriken als Gegenleistung begnügt.

Einige Plattformen, allen voran YouTube, geben einen Teil ihrer Einnahmen an ihre Sender weiter und nähern sich damit teilweise herkömmlichen werbefinanzierten Medien wie dem Privatfernsehen und -radio an, erlauben jedoch parallel dazu das unbezahlte Senden. Andere, wie Twitter und Instagram, ermöglichen ihren Nutzern keine direkte Monetarisierung ihrer Reichweite und erlangten Aufmerksamkeit; teils lässt sich diese mit externen Diensten wie Patreon oder der Nutzung als Werbeplattform für eigene Produkte kompensieren. Manche haben nicht einmal ein nachhaltiges Geschäftsmodell, so wie Telegram, das seine letzten Einnahmen mit dem Verkauf selbst erzeugter Blockchain-Token („ICO“) erzielte, bevor die amerikanische Börsenaufsicht dem ein Ende setzte.

Das Internet schafft damit einen Raum für Medienprodukte, die vom Narzissmus oder der Agenda der Sender sowie der Einfalt ihrer Gefolgschaft leben. Esoterik und Verschwörungstheorien, die in den letzten Wochen in Form von Demonstrationen aus dem Internet herausschwappten, stellen nur eine Ausprägung diese Modells dar. Dass sich Telegram in diesem Zusammenhang zum Kopp-Verlag unter den Messengern entwickelt hat, dürfte nicht zuletzt fehlenden Reichweitebeschränkungen zuzuschreiben sein.

So im jungen Internet jeder mit wenig Aufwand ein Spammer werden konnte (Stimmt die Zeitform oder gibt es immer noch so viel Spam und ich sehe ihn nur nicht mehr?), kann heute auch jeder ein Massenmedium sein. Er muss dafür nur Zeit investieren und veröffentlichen, was seiner Zielgruppe gefällt. Als Belohnung gibt es Likes, Reshares und manchmal eine „Hygienedemo“ besonders eifriger Anhänger. Etwas Besseres als ein folgsamer Mob kann den Sendern kaum passieren.

Vordergründig funktioniert dieser neue Medienmarkt zwar wie der Alte, der ebenfalls Aufmerksamkeit belohnt, doch fällt das Geld als Regulativ für Inhalte weitgehend weg – auch auf Seiten der Empfänger, die sich nicht mehr auf einige wenige mutmaßlich seriöse Quellen festlegen müssen, sondern sich aus einem Überangebot das herauspicken, was ihnen gerade gefällt. Zugleich verschwimmen die Grenzen zwischen Sendern und Empfängern. Alle machen alles und viele träumen davon, es vom Twitter-Ei zum Like- oder Follower-Millionär zu bringen.

Negative Konsequenzen haben die Jedermannmedien auch dort, wo keine böse Absicht im Spiel ist. Aktuelles Beispiel: Das deutsche Corona-Warn-App-Projekt arbeitet relativ offen auf GitHub. Dort kann jeder in die Dokumentation und den Programmcode schauen, Fragen stellen, Probleme melden und diskutieren. Die Entwickler reagieren darauf professionell und nachvollziehbar, sie sind in einem vernünftigen Maß – um fertig zu werden, muss man manchmal Prioritäten setzen und nicht alles entscheiden die Entwickler selbst – offen für Kritik und Verbesserungsvorschläge. Doch die Arbeitswoche beginnt für sie nach dem Feiertag damit, dass sie am Dienstag halb neun jemand per Twitter anpisst, weil ihm an ihrem Datenbankentwurf etwas nicht gefällt. Die genannten Merkmale stellen wahrscheinlich gar kein großes Problem dar, weil die Datenbank im Fall der Corona-Warn-App ohnehin nur der Koordination dezentraler App-Instanzen dient und die zentral anfallenden Informationen kaum etwas über identifizierbare  Personen aussagen. Trotzdem gibt’s zur Belohnung allgemeines Schulterklopfen. Den Entwicklern will er’s vielleicht später melden.

Dies ist das Resultat einer Plattform, die den Narzissmus ihrer Nutzer gamifiziert hat, um damit Geld zu verdienen. Hier kann jeder ein kleiner Trump sein und sich seine tägliche Dosis Bestätigung aus der eigenen Populismusblase holen. Im kleinen Maßstab ist das kein Problem, doch insgesamt kommen wir vielleicht nicht darum herum, den senderseitigen Aufwand wieder an die Reichweite zu binden und so die alte Trennung zwischen relativ aufwändiger Massen- und billiger Individualkommunikation geringer Reichweite wiederherzustellen.

Plattform, mit Betonung auf platt

Digitale Plattformwirtschaft gilt der Bundesregierung als großes Ding, seit sie bemerkt hat, dass wir keine eigene haben. Um diese Lücke zu schließen, fördert Berlin Plattformprojekte. Zum Universalleuchtturm Gaia-X, dessen Anwendungen von Chatbots für das eGovernment bis zur Krebsheilung reichen sollen, kommen die Themen der einzelnen Ressorts. Das Verkehrsministerium fördert, naheliegend, die Mobilitätsplattform Stadtnavi, die nicht weniger verspricht als Mobilität gemeinsam neu zu denken. Das Ergebnis ist Asche, nämlich ein notdürftig als Plattform verkleideter Karten- und Routenplanungsdienst, der seine Claims statt auf die Hauptsache direkt auf Nebengebiete wie Open Data, Open Source und Datenschutz legt. Zu kurz kommt wie so oft die Nutzerorientierung und damit das, was andere Plattformen erfolgreich macht.

Der Fairness halber sei gesagt, dass Stadtnavi nach eigener Aussage noch nicht fertig ist und das Projektbudget mit 370.000 Euro überschaubar bleibt. Gleichwohl lässt sich bereits eine Richtung erkennen. Stadtnavi bietet im Wesentlichen einen Karten- und Navigationsdienst, der verschiedene Verkehrsträger berücksichtigt und der mit Echtzeitdaten zum Beispiel über freie Parkplätze, Ladestationen, Mitfahrgelegenheiten, Busverspätungen und so weiter angereichert wird. Richtig verpackt sind solche Dienste unbestritten nützlich, das zeigen die Navigationssysteme in vielen Autos, Karten- und Navigationsapps für Smartphones sowie der DB Navigator. Anders als der DB Navigator, der auch Fahrkarten verkauft und Bahnreisende unterwegs unterstützt, bleibt Stadtnavi jedoch auf der Metaebene: Man kann sich dort über Mobilität informieren, sonst nichts.

Gemessen am eigenen Anspruch, für saubere Luft zu sorgen, wie auch an den Erfolgsvoraussetzungen für ein Plattformgeschäft drückt man sich vor der eigentlichen Herausforderung: Mobilität nutzerorientiert anders zu organisieren. Dazu müsste man nicht nur irgendwas mit Internet machen, sondern echte und konkurrenzfähige Mobilitätslösungen bieten. Messen lassen müssen sich solche Angebote am Auto, das bei vielen Menschen vor der Tür steht und darauf wartet, gefahren zu werden. Das Auto vor der Tür befriedigt bequem und flexibel eine breite Palette an Mobilitätsbedürfnissen. Wer sich einmal daran gewöhnt hat, einfach einzusteigen und loszufahren, findet kaum einen Anlass, sich überhaupt über Alternativen zu informieren. Wer es dennoch tut, wird häufig in seiner Entscheidung für das Auto bestärkt. Mit Ausnahme der Schnellbahnsysteme in Großstädten und Ballungsräumen bleibt der öffentliche Nahverkehr der individuellen Fortbewegung – einschließlich Fahrrad und Taxi – oft unterlegen.

So verwundert nicht, dass eine kommerzielle Plattform wie Uber, in deren Motivation saubere Luft so wenig eine Rolle spielt wie die Arbeitsbedingungen ihrer scheinselbständigen Fahrer, einen Taxidienst anbietet. Ein Ubertaxi ist so bequem wie das eigene Auto vor der Tür, erspart einem jedoch den Ärger damit und steht im Gegensatz zum eigenen Auto auch am Zielflughafen auf Wunsch vor der Tür. Ob man Uber deswegen auch gestatten sollte, an die Stelle der bisherigen Taxiwirtschaft mit ihrem vergleichbaren Angebot zu treten, sei dahingestellt. Jedenfalls bieten alte wie neue Taxis heute echte Mobilitätsplattformen mit einem Smartphone-Interface, die digital eine Schar mehr oder minder unabhängig arbeitender Dienstleister koordiniert.

Erfolgreiche Plattformen vernetzen Anbieter und Kunden so, dass für alle ein Mehrwert entsteht. Von Amazon zum Beispiel bekomme ich einen Online-Shop für fast alles, was man überhaupt kaufen kann. Manches liefert Amazon selbst, anderes kommt von unabhängigen Händlern, die (auch) über Amazon verkaufen. Mir erleichtert Amazon das Leben, weil ich einmal bestelle und dann in den nächsten Tagen Klemmstifte für die Heizung aus der Oberlausitz, Ersatzteile für meine Fahrradtaschen aus dem Schwarzwald und eine Fahrradbremse aus dem Amazon-Lager geliefert bekomme. Den Händlern nimmt es einen Teil des Shop-Betriebs ab und führt ihnen Kunden zu. Amazon sorgt dafür, dass das alles reibungslos funktioniert. Analog bekomme ich von Apple, Google oder Microsoft nicht einfach ein Gerät oder ein Betriebssystem, sondern Appstores, aus denen ich mir über viele Anbieter hinweg meine Anwendungslandschaft zuammenklicke und Updates bekomme.

Eine echte und nützliche Mobilitätsplattform müsste dasselbe tun und die Verkehrsbedürfnisse ihrer Nutzerinnen und Nutzer besser und einfacher befriedigen als ohne sie. Ein Ansatz dazu ist die echte Vernetzung verschiedender Verkehrsträger nicht nur in Form integrierter Navigation und Fahrplanauskunft, sondern zu einem nützlichen Mehrwertdienst. Möchte ich zum Beispiel nach Frankfurt oder über Frankfurt irgendwohin fahren, muss ich erst einmal zum Bahnhof kommen. Ich wohne zwischen zwei etwa gleich weit entfernten Strecken, auf denen jeweils S-Bahnen und Nahverkehrszüge und auf einer auch nutzbarer Fernverkehr fahren. Die ÖPNV-Anbindung ist in einer Richtung besser als in der anderen, und unabhängig davon etwa einen Kilometer Fußweg entfernt. Mit einem eigenen Fahrzeug, das ich am Bahnhof parke – egal ob Fahrrad oder Auto – beschränke ich mich für die Rückfahrt auf eine der beiden Strecken. Mit einem Rollkoffer im Schlepp fällt das Fahrrad aus und ein eigenes Auto habe ich gar nicht.

Möglicherweise könnte ich mich für eine Plattform begeistern, die mir in dieser Situation das Denken und Organisieren abnimmt. So einer Plattform würde ich einfach sagen, dass ich jetzt nach Frankfurt möchte. Daraufhin bekäme ich die Antwort: „Kein Problem, kostet 25 Goldstücke, Sie werde in zehn Minuten abgeholt. Dürfen wir Sie am Zielort noch irgendwo hinbringen?“, oder auch: „Um die Ecke steht ein freies Mietfahrrad. Wenn Sie darauf spätestens halb drei gen Westen reiten, bekommen Sie die nächste Regionalbahn oder notfalls ein paar Minuten später die nachfolgende S-Bahn. Möchten Sie das Rad bis dahin reservieren?“ Für die zweite Variante fehlt es meiner Kleinstadt an Mieträdern, die gibt es nur in der größeren Nachbarstadt. In der ersten wüsste der Fahrer, der mich abholt, dass ich mit der Bahn weiter möchte und zu welchem Bahnhof er mich bei der aktuellen Verkehrslage fahren soll. In beiden Fällen hätte sich jemand Gedanken gemacht, was mein Mobilitätsbedarf ist, wie er sich befriedigen lässt und wie das für mich möglichst einfach wird. Dafür jedoch etwas mehr nötig als nur Auskünfte.

Nützlich machen könnte sich eine Mobilitätsplattform auch in Ausnahmesituationen. Unsere alltägliche Mobilität ist stark von Gewohnheiten geprägt. Wir fahren so oft zur Arbeit, zum Einkaufen, zu Verwandten und Freunden oder zu regelmäßigen Freizeitbeschäftigungen, dass wir darüber nicht mehr nachdenken, sondern alles wie immer tun. So mancher ist schon versehentlich Samstags zur Arbeit gefahren, weil er irgendwohin wollte, der Anfang des Weges derselbe war und dann der innere Autopilot übernahm. Manchmal haben wir jedoch ungewöhnliche Bedürfnisse, müssen mehr transportieren als das Fahrrad schafft, organisieren eine Familienfeier mit dezentralen Übernachtungen und mehreren Ortswechseln oder müssen eine Zeit überbrücken, in der das eigene Fahrzeug nicht verfügbar ist oder aus sonst einem Grund alles nicht wie gewohnt funktioniert.

Mit intelligenten Angeboten für solche Situationen bekäme eine Mobilitätsplattform vielleicht auch bei jenen einen Fuß in die Tür, die sich sonst gewohnheitsmäßig ins eigene Auto setzen und das auch noch täten, wenn der Benzinpreis bei fünf Euro und die Höchstgeschwindigkeit auf Autobahnen bei 80 km/h läge. Denken wir noch einmal an Amazon: In seiner Jugend konnte der Konzern bei vielen Kunden damit punkten, dass er englischsprachige Bücher ohne Umstände lieferte. Heute sind dort noch viel mehr Dinge zu bekommen, die man in Geschäften und Kaufhäusern vor Ort vergebens sucht. Fotopapier, Feuerpoi, Fahrradständer – alles kein Problem. So etwas kommt heraus, wenn man mit einer Plattform Geld verdienen möchte, so dass man gezwungen ist, sich mit Nutzerbedürfnissen auseinanderzusetzen und echte Vorteile zu verkaufen. Aus ehrgeizarmen Förderprojekten kommt dagegen so etwas wie Stadtnavi, immer und immer wieder.

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.

CoronApp-Links (2020-05-09)

Auch diese Woche haben sich allerlei Meldungen und Artikel zum Thema Corona-App angesammelt:

Die deutsche App soll nach aktuellem Stand im Juni erscheinen. Das Thema wird uns also noch eine Weile begleiten.

Dezentrale Engstirnigkeit, zentraler Realismus

Auch in der automatischen Kontaktverfolgung per Smartphone-App traut sich Großbritannien, einen eigenen Weg zu gehen. Dort beginnt gerade der Testbetrieb einer Corona-App, der eine zentrale Datenverarbeitung zugrunde liegt. Die Briten verfolgen damit in jeder Hinsicht das Gegenteil des deutschen Ansatzes: Während dort eine zentrale Lösung weitgehend einsatzreif ist, hat man hier gerade dezentral von vorne angefangen, nachdem das bereits laufende Projekt PEPP-PT mit seiner Entscheidung gegen eine streng dezentralisierte Lösung politisch in Ungnade gefallen war. Die hierzulande mitschwingenden paneuropäischen Großmachtphantasien fanden auf der Insel naturgemäß ohnehin keinen Raum.

Die Gretchenfrage: „Zentral oder dezentral?“ entstand als Artefakt einer öffentlichen Debatte, weil sie zu Positionierungen einlud, ohne Sachkenntnis zu verlangen. Den Anschein überragender Bedeutung erlangte sie zum einen durch die im Nachhinein ungeschickt wirkende Ankündigung von PEPP-PT, den technischen Datenschutz in den Mittelpunkt zu rücken, zum anderen durch das eigennützige Handeln einiger Beteiligter. Während PEPP-PT im Laufe seiner Entwicklungsarbeit offenbar das Problem und den Lösungsraum besser verstand und sich vom dezentralen Extrem verabschiedete, spitzten dreihundert Professoren die ohnehin zu enge Fokussierung auf technischen Datenschutz noch zu. Als ginge es darum, unter idealisierten Voraussetzungen zwischen zwei einander widersprechenden Hypothesen die richtigere auszuwählen, konstruierten sie ein Entweder-Oder zwischen zentral und dezentral und gaben sogleich ohne Experiment die Antwort, selbstverständlich müsse es dezentral sein. Unterdessen sprangen Apple und Google auf den bereits abfahrenden Zug auf und präsentieren sich seither so geschickt als Retter der Privatsphäre, dass sogar Margrethe Vestager darauf hereinfällt und galant darüber hinwegsieht, wie das Duopol seine Plattform-Macht ausspielt.

Welche Erfolgsaussichten die Kontaktverfolgung per Smartphone und Bluetooth insgesamt hat, bleibt unabhängig von der technischen Architektur vorerst unklar. Setzt man diese Idee jedoch um, und sei es nur als Experiment, sollte man sich dabei um die bestmögliche Lösung bemühen. Was eine Lösung gut oder weniger gut macht, bestimmt dabei nicht ein zentrales technisches Detail, sondern der reale Nutzen im Anwendungskontext.

Für zentrale Elemente wie in Großbritannien spricht einiges. Erstens ist eine komplett dezentrale Architektur ohnehin nicht realistisch. Zum einen braucht man selbst bei Datenspeicherung auf den Endgeräten irgendeine zentrale Instanz zur Nachrichtenverteilung und Koordination, wenn man zugleich jede Datensammlung anonym halten und nicht Adressen wie zum Beispiel Telefonnummer für die spätere Benachrichtigung speichern möchte. Zum anderen gehören zu den verwendeten Plattformen unvermeidlich zentrale Instanzen wie Appstores und Telemetrie. Ausgehend von einem Aluhut-Bedrohungsmodell können sich Nutzerinnen und Nutzer in solch einer Umgebung sowieso auf keine Eigenschaft einer App verlassen, denn jederzeit könnte eine neue Version automatisch installiert werden, die alles ganz anders macht.

Zweitens gehören Feedbackmechanismen heute zum Stand der Technik. Seit Software nicht mehr auf Datenträgern in Pappschachteln, sondern online vertrieben und auf vernetzten Geräten benutzt wird, haben Entwickler die Möglichkeit, Telemetriedaten aus der Software selbst sowie Nutzerfeedback unmittelbar zu erhalten und auszuwerten. Das erleichtert und beschleunigt die Fehleerkennung und -behebung sowie die Weiterentwicklung enorm und erlaubt sogar interaktive Experimente mit realen Benutzerinnen und Benutzern. Beim Einsatz einer noch wenig getesteten Technologie sind Feedbackmechanismen besonders wichtig, denn sehr wahrscheinlich erlebt man Überraschungen und muss unerwartete Probleme lösen. Eine letztlich experimentelle App im Zuge der Pandemiebekämpfung einfach herauszugeben und dann sich selbst zu überlassen, wäre grob fahrlässig, zumal über das neue Coronavirus noch zu wenig bekannt ist.

Drittens kollidieren Anforderungen aus dem Anwendungskontext mit extremistischen Datenschutzkonzepten. Die Kontaktverfolgung ist kein belang- und folgenloses Smartphonespiel wie Pokémon Go, sondern sie soll reale Konsequenzen haben. Beim herkömmlichen Vorgehen gehören zu diesen Konsequenzen Quarantäneanordnungen der Gesundheitsämter. Solche Anordnungen benötigen einen Adressaten und im Rechtsstaat müssen sie auch begründet sein, um ggf. einer gerichtlichen Prüfung standzuhalten. Im Sozialstaat ist darüber hinaus geregelt, wer welchen Teil der Lasten trägt und wie beispielsweise eine quarantänebedingte Arbeitsunfähigkeit abgefedert wird. Die Verfechter eines dezentral-anonymen Ansatzes haben bis heute keine Vorschläge unterbreitet, wie das eine oder das andere funktionieren soll. Weder können die Gesundheitsämter damit irgend etwas durchsetzen, noch erhalten Betroffene eine ausreichende Begründung oder gar eine Bescheinigung zur Vorlage bei Vertragspartnern und öffentlichen Stellen.

Viertens drängen sich Nebenfunktionen einer für den Masseneinsatz bestimmten App geradezu auf. Eine offensichtliche ist die Erfassung statistischer Daten, um den Gesundheitsbehörden ein klareres Bild des Pandemieverlaufs zu vermitteln. Dazu muss man doch wieder Daten an eine zentrale Stelle übermitteln und es kann gut sein, dass sich dann aus einem integrierten Ansatz schnell Synergieeffekte ergeben.

In Großbritannien hat man sich offenbar mit den Anforderungen der Anwendung auseinandergesetzt, während Deutschland kontextarm über Technik stritt. Dort möchte man zum Beispiel besonders gute Virenverteiler anonym ausfindig machen und darauf Risikoeinschätzungen stützen. Ob das funktionieren kann, wird sich zeigen; um eine an der Oberfläche nicht offensichtliche Idee handelt es sich allemal. Ein zentralerer Ansatz ist auch nicht automatisch ein Zeichen für Nachlässigkeit oder Primitivität der Implementierung, er kann für alle realistischen Belange einen gleichermaßen effektiven Datenschutz gewähren. Nur eines haben die Briten ebenso versäumt wie die Bundesregierung: die entwickelte Technik rechtlich und organisatorisch mit vertrauensbildenden Maßnahmen zu flankieren. Ich wünsche ihnen dennoch viel Erfolg. Schneller fertig werden sie schon mal, wie auch einige andere Länder, die dem dezentralen Extremismus eine Absage erteilten.

Sündenböcke

Dass die Debatte um eine Corona-App zur Kontaktverfolgung entgleist ist, wird niemandem entgangen sein. Los ging es, als von einer App noch gar nicht die Rede war, mit dem Vorschlag, „irgendwas mit Händiortung zu machen“ und einer vorsorglichen Erlaubnis, die es dann doch nicht ins IfSG schaffte. Kurz darauf traten DP-3T und PEPP-PT auf den Plan, setzten den Fokus auf das Nebenthema Datenschutz unter Meidung einer sauberen Anforderungsanalyse und zerstritten sich über der Frage, welche Funktionen zentral und welche dezentral ablaufen sollten. Während dieser Streit weite Kreise zog, widmete die Öffentlichkeit den grundlegenden Problemen des Vorhabens und der lückenhaften Entwurfsarbeit wenig Aufmerksamkeit. Ein vorläufiges Ende setzte dieser wenig produktiven Diskussion die Bundesregierung mit ihrer Entscheidung, von SAP und der Telekom eine App auf der Grundlage von Gapples angekündigter Lösungsplattform entwickeln zu lassen, und sich schwierigeren Themen wie dem Immunitätspass zuzuwenden.

In einem Kommentar auf FAZ.NET macht Morten Freidel nun alleine „die Hacker“ für die Debatte und ihr Ergebnis verantwortlich. So sehr ich seinen Eindruck teile, dass organisierte Nerds etwa in Gestalt des CCC Expertentum und Aktivismus vermischen, ihr Auftreten in dieser Debatte keine Glanzleistung darstellt und ihre ewiggleichen Forderungen und Mahnungen manchmal mehr schaden als nützen, muss ich die Nerdaktivisten doch gegen den Vorwurf in Schutz nehmen, sie trügen die Hauptschuld am kommunikativen Desaster um die Corona-App.

Versagt hat zuerst die Bundesregierung. Sie hätte sich rechtzeitig Gedanken machen und einen Plan vorlegen sollen, ob und wie digitale Lösungen die Seuchenbekämpfung unterstützen sollen. Immerhin sitzt im Kanzleramt eine Staatsministerin für Digitalisierung, die jedoch wenig von sich hören lässt, seit Millionen Deutsche in ihren Heimbüros auf das Internet angewiesen sind. Stattdessen trieb die Öffentlichkeitsarbeit des PEPP-Konsortiums eine Zeitlang neben den Aktivisten auch die Bundesregierung vor sich her. Politisches Geschick zeigte die Regierung erst, als sie PEPP-PT seinen einzigen Claim vom Vertrauen durch technischen Datenschutz aus der Hand riss, gegen die Freischärler wandte und nebenbei noch die Entscheidung für Gapple und gegen eine eigene technische Basis ohne jeden Widerspruch durchsetzte.

Dass vorher aus PEPP-PT heraus ein Richtungsstreit „zentral vs. dezentral“ eskaliert war, ist ebenfalls nicht zuerst Nerdaktivisten anzulasten. Dieser Streit geriet in die Öffentlichkeit, als dreihundert Wissenschaftler in einem offenen Brief Partei ergriffen für eine forschungsnahe Technologieentwicklung („dezentral“) und gegen einen undogmatischen, zielorientierten Entwicklungsprozess*. Zu welchen Anteilen dieser offene Brief durch ehrliche Bedenken, auf die Gruppendynamik eines stabilen Beziehungsnetzes oder auf gekränkten Narzissmus zurückgeht, wissen nur die Akteure. Festzuhalten bleibt: 300 Wissenschaftler haben mit ihrer lautstarken Äußerung die falsche Dichotomie „zentral vs. dezentral“ gestärkt, offensichtliche Schwächen in der Anforderungsanalyse und im Entwurfsprozess hingegen übersehen und sich dann einen schlanken Fuß gemacht.

Einen schlanken Fuß macht sich auch die Bundesregierung, was gesetzliche Regelungen für die Kontaktverfolgung angeht. Kein Vorschlag liegt auf dem Tisch und man hat wohl auch nicht vor, dieses Thema in Zukunft zu regeln. Dabei hätte ein vertrauensbildender Regelungsvorschlag als Gegenpol zur technikfixierten PR von PEPP-PT einen weit konstruktiveren Beitrag zur Debatte geleistet als die letztendliche Richtungsentscheidung um ein technisches Detail.

Auf den engen datenschutztechnischen Fokus der Debatte eingestiegen zu sein und keine Ausweitung auf eine Gesamtsicht gefordert zu haben, mag man vielen Nerds vorwerfen. Historisch gesehen hat die Hacker- und Nerdaktivistenszene gewiss auch einen Anteil daran, dass Datenschutz inzwischen wichtiger scheint als Konzept und Funktion eines Systems. Die Verantwortung für das Scheitern der Corona-App-Debatte jedoch liegt primär bei anderen, bei PEPP-PT, bei der Bundesregierung und bei den eingeschnappten Professoren.

*) Ich spekuliere, da ich PEPP-PT nur aus den Nachrichten kenne. Auf mich wirkte es jedoch so, als habe man dort entwickelt und dabei gelernt; ich sehe gute Gründe, auf „dezentralen“ Extremismus zu verzichten.

Links zur Corona-App (2020-05-02)

Statt eines eigenen Kommentars heute einige Links zum Thema Kontaktverfolgung und Corona-App, die sich in der vergangenen Woche angesammelt haben:

Das sollte fürs Wochenende genügen.

Bonpflicht als Chance

Die Bäcker jammern: Ab Januar 2020 müssen sie zu jedem Einkauf einen Kassenbon erstellen (und zugleich ihre Kassen mit einer manipulationssicheren Protokollierung ausstatten). Das Bundesfinanzministerium antwortet mit dem Hinweis, dieser Pflicht können auch mit der Ausgabe elektronischer Belegen Genüge tun, woraufhin Medien von Lösungen per E-Mail oder Smartphone phantasieren. Dabei könnte alles sehr einfach sein.

Selbst das traditionelle Bäckerhandwerk entdeckt ganz, ganz langsam das elektrische Bezahlen. Das funktioniert heute kontaktlos und bei kleinen Beträgen ohne PIN-Eingabe. Kunden bekommen den zu zahlenden Betrag angezeigt, halten ihre Karte ans Terminal und finden später einen Nachweis auf ihrem Kontoauszug oder ihrer Kreditkartenabrechnung beziehungsweise in den entsprechenden Funktionen ihrer Online-Bank.

In dieses Verfahren ließen sich elektrische Kassenzettel gut integrieren. Aus Nutzersicht handelt es sich um eine detailliertere Version des Verwendungszwecks, der ohnehin übermittelt und angezeigt wird. Eines Tages könnten die für den Zahlungsverkehr eingesetzten Protokolle solch eine Funktion direkt unterstützen. Gegenwärtig tun sie dies vermutlich nicht und Standardisierungsbemühungen in der Finanzwirtschaft dürften etwas länger dauern.

Bis dahin könnte man sich mit einem Verfahren behelfen, das sich aktuelle Versionen des elektronischen Rezepts zum Vorbild nimmt. Bei allen Kartenzahlungen kämen die digitalen Kassenzettel dann in einen Cloudservice, der sie für eine gewisse Zeit, etwa sechs Monate, zum Abruf vorhielte. Käufer erhielten via Abrechnung zu jedem digitalen Kassenbon eine eindeutige, praktisch nicht erratbare Referenznummer, mit der sie ihn aus der Cloud abrufen könnten. Optional könnte man die Kassenbondaten sogar verschlüsseln (dann dürfte man jedoch zum Abruf nicht denselben Schlüssel verwenden wie zum Entschlüsseln).

Als MVP bekämen man also bei Kartenzahlung in der Abrechnung eine Zahlenkolonne zu sehen, mit der wir den Kassenbon abrufen könnten. Mit etwas gutem Willen und nach einigen Jahren Beratung in  verschiedenen Gremien könnte daraus eine Funktion im Online-Banking werden, mit der sich zu jeder Zahlung der zugehörige Kassenzettel abrufen ließe, wahlweise direkt aus der Cloud während der vorgesehenen Speicherdauer dort oder auf Wunsch aus einem automatisch geführten persönlichen Archiv mit selbst gewählter Speicherdauer und nützlichen Verwaltungsfunktionen zum Beispiel zur Erstellung von Steuererklärungen.

So ungefähr dächten wir über dieses Thema nach, wären wir digital auf der Höhe der Zeit. Wir sind es nicht und zahlen bei vielen Bäckern noch bar. Dazu passt der Bon auf Papier.

PS: Einen Monat später sehen das andere ähnlich. (2019-12-17)

PPS: Weitere anderthalb Monate später diskutiert Deutschland weiter über Kassenbons und zunehmend über digitale Lösungen. (2020-01-29)

PPPS: Das Handelsblatt hat herausgefunden, dass die Bonpflicht zu einem Innovationsschub im Handel führt. (2020-01-30)

Schnapsidee: Falschfahrerwarnung als Werbegag in der Radio-App

Der Radiosender Antenne Bayern hat sich von Bosch einen Werbegag für seine App bauen lassen und mir stehen die Haare zu Berge. Es handelt sich um eine neue Funktion in der App des Senders, eine Falschfahrerwarnung. Das noble Ziel: „Keine Verkehrstoten mehr durch Falschfahrer“, doch der Weg erscheint fragwürdig.

Die Warnfunktion besteht offenbar aus zwei Teilen. Der eine erkennt Falschfahrten daran, dass sich eine aktive Instanz der App in der falschen Richtung durch eine Autobahnauffahrt bewegt, und meldet dieses Ereignis an einen Clouddienst. Der andere empfängt Warnmeldungen und gibt sie aus. Nach eigenen Angaben hat man dabei auch an den Datenschutz gedacht. Technisch ist das so weit plausibel und den Datenschutz glaube ich einfach mal ohne Prüfung. Wenig Sinn ergibt jedoch das Konzept insgesamt, wenn als übliche Anforderungen an einen Sicherheitsmechanismus erstens Verlässlichkeit verlangt und zweitens die Anpassung der Technik an den Menschen.

Die Verlässlichkeit scheitert daran, dass sie Warnfunktion in einer Radio-App steckt. Erkannt werden nur Falschfahrer, welche die App benutzen und die Funktion aktiviert haben, gewarnt ebenso nur Nutzer der App mit aktivierter Warnfunktion. Laut den Mediadaten für Antenne Bayern hat die App im Monat knapp 300.000 „Unique User“. Das entspricht etwa der Einwohnerzahl von Bayerns drittgrößter Stadt Augsburg oder weniger als 2,5% der bayerischen Bevölkerung. Gehört ein Geisterfahrer nicht zu dieser Minderheit, warnt auch niemand vor ihm. Nach Angaben von Bosch steckt die Funktion noch in einigen anderen Apps, aber das ändert nichts am grundlegenden Problem, dass Entertainment-Apps kein guter Träger für Sicherheitsfunktionen sind.

Selbst wenn die Warnfunktion auf jedem bayerischen Mobiltelefon aktiv wäre, übersähe sie immer noch ausgerechnet ortsunkundige Auswärtige sowie jeden, der das Telefon zu Hause ließe, dessen Akkuladung zur Neige ginge oder der im Funkloch geisterführe. Umgekehrt hätten Bayern auswärts wenig von der Warnfunktion, nähmen sie per App zwar ihren Lieblingssender mit, begegneten jedoch in der Fremde falschfahrenden Saupreißn ohne App. Man müsste schon gewaltiges Glück in einem nicht sehr wahrscheinlichen Unglück haben, um aus der App überhaupt jemals eine gerechtfertigte und spezifische Warnung zu erhalten.

Nicht verlässlich scheint die App auch im Hinblick auf die Abdeckung relevanter Gefahrensituationen. Geisterfahrer im engeren Sinne können überall auftreten und zur Gefahr werden, wo Straßen getrennte Richtungsfahrbahnen haben und hohe Geschwindigkeiten gefahren werden. Laut Beschreibung erfasst die App nur Autobahnen und lässt damit Bundesstraßen und andere autobahnähnliche Schnellstraßen unberücksichtigt. Darüber hinaus würde mich interessieren, wie das System mit ausgedehnten und unkonventionellen Falschfahrten umgeht. Bei mir vor der Haustür schaffte ein betrunkener Lkw-Fahrer vor einem Jahr eine Geisterfahrt von einem Rastplatz über 21 Kilometer und ein Autobahnkreuz, bevor er gestoppt wurde. Wer nur Auffahrten überwacht, müsste sehr großflächig vor der Gefahr warnen, um alle Betroffenen erreichen zu können.

Unklar bleibt aus der kurzen Erläuterung, wie hoch das Risiko von Fehlwarnungen ist. Merkt es die App oder die Cloud dahinter, wenn etwa ein Bauarbeiter Antenne Bayern hört und sich bei der Arbeit falsch herum durch eine Autobahnabfahrt bewegt? Oder ein Autofahrer, der eine Panne hat und mit dem Händi in der Tasche ordnungsgemäß das Warndreieck aufstellt? Und wie steht es um Manipulationsmöglichkeiten? Was passiert, wenn jemand mit aktiver App in der falschen Richtung neben der Abfahrt herläuft? Wie ist der Clouddienst gegen das Einspeisen falscher Daten aus anderen Quellen als der echten App geschützt?

Daneben stellen sich bei einer solchen Funktion Fragen der benutzergerechten Gestaltung. Falls die App verlässlich warnen könnte, so müsste sie den betroffenen Fahrern – dem Geisterfahrer sowie jenen, denen er entgegenkommt – eine wirksame Warnung übermitteln. Da Geisterfahrten selten sind, wird es sich in der Regel um die erste Warnung dieser Art handeln, die der Fahrer erhält, und dann bleibt keine Zeit zum Nachdenken.

Unter diesen Umständen kommt eigentlich nur eine akustische Warnung mit einer direkten Handlungsanweisung in Frage. Vorbilder dafür liefert jedes moderne Flugzeugcockpit in unmittelbaren Gefahrensituationen. So warnt das Ground Proximity Warning System (GPWS) vor bevorstehendem Bodenkontakt und das Traffic Alert and Collision Avoidance System (TCAS) vor Zusammenstößen mit anderen Flugzeugen. Beide Systeme sagen den Piloten in knappen Worten, was sie tun sollen, denn für alles andere ist keine Zeit. Im Falle des TCAS wird die Anweisung zudem mit dem anderen Flugzeug koordiniert, so dass die Piloten des einen Flugzeugs zum Steigen und die anderen zum Sinken aufgefordert werden. Piloten werden zudem darauf trainiert, mit diesen Warnungen richtig umzugehen. Demgegenüber lenkt eine App auf dem Händi mit einer ungewohnten Warnung eher ab als dass sie hülfe und auf eine situationsabhängige Ausweichanweisung hoffen Betroffene wohl vergebens.

Im Auto und erst recht in einer Radio-App muss man sich außerdem noch Gedanken darüber machen, wie man wirklich wichtige Informationen aus dem Geplapper der Radiomoderatoren, des Navigationsgeräts oder des E-Mail-und-Kurznachrichtenvorlesers heraushebt. Vielleicht ist der Sprachkanal dann doch keine gute Wahl und es wäre besser, den entgegenkommenden Geisterfahrer im Head-Up-Display mit einem größer werdenden roten Punkt zu markieren.

In der vorliegenden Form ist die Falschfahrerwarnung in der Radio-App nichts weiter als ein Werbegag und daran änderte sich wenig, machten möglichst viele Menschen in Bayern mit, wie es sich der Sender wünscht. Eine sinnvolle Warnfunktion müsste Falschfahrten überall verlässlich, aber ohne Fehlarme und Manipulationsmöglichkeiten erkennen und in Gefahrensituationen verbal spezifische, umsetzbare Anweisungen zur Gefahrenabwehr geben. Dazu müsste sie zwingend in die Fahrzeugelektronik integriert sein – Hersteller Bosch sieht dies anscheinend als Alternative zum Smartphone vor – und zur Detektion von Falschfahrten auf absehbare Zeit zusätzlich auf Sensoren außerhalb der Fahrzeuge zurückgreifen. Wäre man darauf nicht angewiesen, könnte man gleich das Entwurfsziel ändern und überlegen, wie man Falschfahrer rechtzeitig stoppt, statt vor ihnen zu warnen.