"Haben Fehler korrigiert und uns entschuldigt"
- "Haben Fehler korrigiert und uns entschuldigt"
- Nicht alle Best Practices der Softwareentwicklung eingehalten
- Reaktion der Szene und ein vorläufiges Fazit der Luca-App-Affäre
- Auf einer Seite lesen
Patrick Hennig zu Fragen des Quellcodes, dem Missbrauch der Anwendung und zur Zukunft der Luca-App (Teil 3 und Schluss)
Angesichts der jüngsten Entwicklungen, der zusätzlichen Funktionen der Corona-Warn-App und der an Fahrt gewinnenden Impfkampagne: Welche Komponenten oder Bestandteile der Luca-App hätten Sie sich früher fertig gewünscht und wie sieht das Geschäftsmodell nach Corona aus?
Patrick Hennig: Ich glaube in der Tat, dass ein Austausch von Daten, wenn auch nur der allernotwendigsten, uns bei der Kontaktnachverfolgung im letzten Jahr sehr viel geholfen hätte. Trotzdem bin ich davon überzeugt, dass beide sinnvolle Tools für die Eindämmung der Pandemie sind.
Wir haben die Fachanwendung für die Gesundheitsämter entwickelt, um die Kontaktnachverfolgung zu vereinfachen. Persönlich hoffe ich vor allem, dass die Pandemie bald vorbei ist. Aber wenn wir den Wissenschaftlern glauben, wird uns das Thema noch eine Weile begleiten.
Wir wissen alle noch nicht, wie sich die Impfungen entwickeln und ob weitere Mutationen auftreten. Bei niedrigen Zahlen kann Luca am effizientesten wirken. Viele glauben uns das nicht, aber wir sind nicht mit einem Geschäftsmodell angetreten, sondern haben nach einer Lösung gesucht. Sollten solche Tools wie Luca weiterhin relevant sein, dann muss man darüber sprechen, aber aktuell ist das für uns wirklich überhaupt kein Thema.
Teil 1: CEO der Luca-App im "Kampf gegen Windmühlen"
Teil 2: Luca-App: Hilfe oder Belastung von Gesundheitsämtern?
Das ist gelungenes Framing und Bridging. Wikipedia definiert Framing als den "Prozess einer Einbettung von Ereignissen und Themen in Deutungsraster. Komplexe Informationen werden dadurch selektiert und strukturiert aufbereitet, sodass eine bestimmte Problemdefinition, Ursachenzuschreibung, moralische Bewertung und/oder Handlungsempfehlung in der jeweiligen Thematik betont wird". Die Schule des Sprechens führt aus: "Bridging wird von Medienprofis dann eingesetzt, wenn sie thematisch eine Brücke zu Inhalten schlagen, über die sie reden wollen".
Gefragt nach dem Geschäftsmodell "bridged" Hennig zu der These, mehr Datenaustausch habe geholfen. Er "glaubt" und spricht davon, dass "auch nur der allernotwendigste" Datenaustausch geholfen habe. Der neue Rahmen heißt: Es hat keinen oder zu wenig Datenaustausch gegeben, der Datenschutz ist also schuld an der Misere. Einer ähnlichen Rhetorik bedienen sich konservative Meinungsmacher wie Friedrich Merz oder Jan Fleischhauer.
Die Fakten sprechen eindeutig eine andere Sprache: Zum einen (siehe Lauterbachs Antwort bei Maischberger) stünden keinesfalls mehr Daten zur Verfügung, noch wären die Gesundheitsämter in der Lage diese zu verarbeiten, Apps hin oder her.
Zweitens stellt sich die Frage: Wenn die Luca-App nicht mit einem Geschäftsmodell angetreten ist, warum hat man dann das Sicherheitsmodell patentieren lassen und in Gastronomie-Fachzeitschriften Werbung geschaltet? Warum dann die Salami-Taktik bei der Veröffentlichung von Geschäftsgeheimnissen wie dem Code, der Datenschutzerklärung oder den Verträgen?
Wenn Nexenio, culture4life und die Macher der Luca-App keine Gewinnerzielungsabsicht hatten, kein Geschäftsmodell, dann haben sie das sehr ungeschickt verborgen – angesichts der hochkarätigen PR-Truppe erscheint das auch unwahrscheinlich. Vieles weist darauf hin, dass man mit Corona Geld verdienen wollte, und das ist auch nicht strafbar. Am wahrscheinlichsten ist jedoch die Monetarisierung durch Ticketverkäufe nach staatsfinanzierter Softwareentwicklung.
Vom Erfolg überwältigt
Wie die Corona-Warn-App hat auch Luca hohe Millionenbeträge von Bund und Ländern erhalten. Aber warum unterscheiden sich die Entwicklungsstrategien so enorm?
Patrick Hennig: Die Corona-Warn-App ist als ein Entwicklungsauftrag gestartet. Daher ist der Code auch von Beginn an Open Source. Luca ist als private, kleine Initiative selbst finanziert gestartet, die Ressourcen waren bei uns zu Beginn ganz andere. Es handelt sich bei Luca nicht nur um eine App: Die Länder haben eine Fachanwendung lizenziert, vom Bund haben wir gar kein Geld bekommen, Lizenznehmer sind die Länder, Kommunen und Landkreise. Das System ist komplex und hat hohe Kosten, (…)
Luca wurde also nicht in Open-Source entwickelt, weil die Firma zu Beginn klein und das System so komplex war. Finanzierung kam zwar auch von öffentlicher Seite, aber eben über Lizenzen. Der Rest der Antwort listet die Kosten auf, die mit dem Betrieb der App verbunden sind, erklärt aber nicht, warum Open-Source "nicht auf dem Radar" war.
Auch in dieser Antwort kann Hennig den Eindruck nicht entkräften, dass hier ein Start-up von dem Erfolg überwältigt wurde, den die politischen Rahmenbedingungen und die mediale Aufmerksamkeit plötzlich brachten. Den überraschenden Erfolg hatte man vermutlich wirklich nicht "befürchtet". Man versuchte, durch überstürztes Handeln zu korrigieren, was sich in vielen Anfänger- und Flüchtigkeitsfehlern in Architektur und Software zeigte. Wurde diese Argumentation mit der Zeit zum Selbstläufer?
Es gab zuletzt zahlreiche Fälle, in denen Funktionen der Luca-App missbraucht wurden, beispielsweise um Fake-Events zu veranstalten, Tracking-Daten auszulesen, Schlüsselanhänger zu missbrauchen oder wo Büros von Parlamentariern nachts mit SMS und Robo-Calls belästigt wurden. Wie konnte das passieren und warum wurden so viele Probleme bis heute nicht abgestellt?
Patrick Hennig: Grundsätzlich ist das immer eine Abwägung aus Verhinderung von Missbrauch und dem Grundrechtsschutz des Datenschutzes. In dem Fall von Jan Böhmermann wurde der Check-in-Code des Zoos veröffentlicht. Dann kann jemand einchecken, der nicht vor Ort ist: Die QR-Codes sind ein statisches Element.
Wir weisen darauf in unseren Schulungen für Betreiber:innen jetzt noch mal verstärkt hin. Dies ließe sich nur durch eine Überprüfung der Standortdaten oder des Personalausweises verhindern, würde aber der Idee der Datensparsamkeit widersprechen.
Beide Mittel stehen unserer Einschätzung nach absolut nicht in Relation. Wir alle müssen Verantwortung übernehmen, um unsere Freiheit zu erhalten. Andernfalls würden unser Grundrecht auf Datenschutz noch weiter eingeschränkt. Wir halten das für unverhältnismäßig.
Ein ähnliches Beispiel haben wir beim Verzicht auf die serverseitige Verifikation der Telefonnummer. Dadurch haben wir keine Zuordnung der Telefonnummer zum Check-in-Objekt. Wir sehen den dadurch möglichen Missbrauch, den Client zu verändern, als valide an, (…)
Der potenzielle Schaden ist aus unserer Sicht aber zu gering, um den anderen Weg zu gehen. Im Grunde fallen auch die gerade stark diskutierten Schlüsselanhänger in dieselbe Kategorie: Der QR-Code ist statisch, eine weitere Validierung nach der einmaligen Anmeldung erfolgt nicht, auch aus Gründen der Datensparsamkeit und der Zuordenbarkeit. (...)
Ein erneutes Framing: Der Datenschutz ist schuld an den nächtlichen Anrufen und SMS-Terror, nicht die Luca-App. Die Menschen, die die QR-Codes teilen, sind das Problem, nicht die Software-Fehler. Man könnte das alles ja sicherer machen, aber man darf das ja nicht, wegen des Datenschutzes.
"Datensparsamkeit" nennt Hennig das, um aber gleich darauf zu verweisen, das man ja auf der moralisch richtigen Seite stünde, nur die Hände seien gebunden.
Doch den hier konstruierten Gegensatz Datenschutz vs. Sicherheit gibt es so nicht, hier soll gezielt ein Feindbild erzeugt werden, das vom eigenen Fehlverhalten ablenkt. Der darauffolgende Versuch, sich als Verfechter der Datensparsamkeit zu positionieren, verdeutlicht nur PR-Geschick und solide rhetorische Qualitäten.
In dieser Antwort zeigt sich auch ein weiteres Muster der Luca-Entwickler: Nach dem Vorbild des alten Apple-Witzes "You are holding it wrong" versuchen Hennig und sein PR-Berater Bublitz, jedes der vielen fundamentalen, nicht änderbaren Sicherheitsprobleme als Fehlverhalten von Anwendern abzutun. Schuld wird abgewiesen, gleichzeitig aber gelobt man Besserung.