Stefan Zörner
12.05.2021
Ich diesem Beitrag geht es um das im Softwareentwurf recht nützliche Konzept der Architekturprinzipien. Illustriert anhand einer aktuellen Debatte.
Mit dem ersten Infektionsfall in Bayern begann Ende Januar 2020 offiziell die Ausbreitung des neuartigen Coronavirus SARS-CoV-2 in Deutschland. Schon früh wurden sogenannte Corona-Apps als eine Möglichkeit der Kontaktverfolgung und damit als ein Mittel zur Unterbrechung von Infektionsketten diskutiert.
Im April 2020 veröffentlichte der Chaos Computer Club (kurz CCC) seine Prüfsteine für die Beurteilung von „Contact Tracing“-Apps. Corona-Apps sollten sich nach Ansicht der bekannten Hackervereinigung an diesen Kriterien messen lassen.
Und tatsächlich: Die offizielle Corona-Warn-App der Bundesregierung (kurz CWA) wurde ebenso in diesem Rahmen diskutiert wie später Alternativen der Privatwirtschaft wie die Luca App oder DarfIchRein.
Die Prüfsteine des CCC sind spezielle Architekturprinzipien. Und um solche soll es in diesem Beitrag gehen. Illustriert anhand der aktuellen Debatte um Tracing-Apps, wo diese Prüfsteine wichtige Argumente darstellen.
In diesem Beitrag
Echte Prüfsteine
Prüfsteine für Contact Tracing-Apps
Gesellschaftliche Anforderungen
Technische Anforderungen
Architekturprinzipien
Apps an den Prüfsteinen reiben
Prinzipien, die passen
Geht es Euch wie mir? Der Begriff “Prüfstein” war zwar in meinem passiven Wortschatz vorhanden, aber ich hätte nicht erklären können, wo diese Metapher ihren Ursprung hat. Ganz anders bei “Meilenstein” (einen Meilenstein erreichen) oder “Prüfstand” (etwas auf den Prüfstand stellen). Was genau ist ein “echter” Prüfstein?
Ich musste nachschlagen … (Wikpedia: Prüfstein)
Ein Prüfstein ist ein kleiner Reibstein, der zur Feststellung der Zusammensetzung und des Reinheitsgrades von Edelmetallen benutzt wird.
Hintergrund: Das Ziehen einer Linie etwa mit Gold auf einem Prüfstein hinterlässt eine sichtbare Spur. Da verschiedene Legierungen von Gold unterschiedliche Farben haben, kann die unbekannte Probe mit Proben bekannter Reinheit verglichen werden.
Die Methode wird seit dem Altertum verwendet, später wurde sie durch den Einsatz von Säuren verfeinert. Heute könnt Ihr solche Prüfsteine inklusive spezieller Säuren bei Amazon klicken. Typische Einsatzorte: Goldschmieden, Juwelier- und Schmuckgeschäfte.
Im übertragenen Sinn ist ein Prüfstein ein Kriterium, mit dem die Gültigkeit oder der Wert eines Konzepts überprüft werden kann. So gibt es Prüfsteine für Wahlprogramme – die Antworten der Parteien auf diese Fragen füttern den Wahl-O-Mat.
Die Prüfstein-Metapher ist im Deutschen seit der frühen Neuzeit gebräuchlich und auch im Englischen bekannt (als Touchstone).
Die ethischen Prinzipien des CCC stehen nach eigener Aussage für Privatsphäre und Dezentralisierung - und gegen jede Form von Überwachung und Zwang.
Contact Tracing-Apps sieht der CCC naturgemäß als Risikotechnologie an. Seine 10 Prüfsteine für die Beurteilung von „Contact Tracing“-Apps stellen aus Sicht der Vereinigung Minimalanforderungen für die Wahrung der Privatsphäre bei der Implementierung derartiger Technologien dar.
Die folgende Abbildung zeigt die gesellschaftlichen und technologischen Anforderungen des CCC im Überblick.
Im Folgenden habe ich, ausgehend vom Originaltext des CCC, zu jeder der Anforderungen Fragen formuliert, um die Prüfsteine zu illustrieren. Für eine konkrete Umsetzung sollte die Antwort “ja” lauten, um dem jeweiligen Prüfstein zu genügen.
1. Epidemiologischer Sinn & Zweckgebundenheit
Hilft „Contact Tracing“ tatsächlich die Infektionszahlen signifikant und nachweisbar zu senken?
Wird das Sammeln von Daten für andere Zwecke als die Pandemiebekämpfung technisch und rechtlich unterbunden?
2. Freiwilligkeit & Diskriminierungsfreiheit
Ist die Nutzung kostenlos und unvergütet?
Ist die App temporär zu deaktivieren und dauerhaft zu deinstallieren?
Erfahren Menschen, die sich der Nutzung verweigern, keine negativen Konsequenzen?
3. Grundlegende Privatsphäre
Stellen belegbare technische Maßnahmen wie Kryptografie und Anonymisierung die Privatsphäre der Nutzer sicher?
4. Transparenz und Prüfbarkeit
Ist der komplette Quelltext frei und ohne Zugangsbeschränkungen verfügbar?
Ist überprüfbar, ob die heruntergeladene App aus dem Quelltext gebaut wurde?
5. Keine zentrale Entität, der vertraut werden muss
Erfolgt ein vollständig anonymes “Contact Tracing” ohne allwissende zentrale Server?
6. Datensparsamkeit
Werden nur minimale und für den Anwendungszweck notwendige Daten und Metadaten gespeichert?
Werden nicht mehr benötige Daten gelöscht?
Sind über den eigentlichen Zweck hinausgehende Datenerhebungen zu Forschungszwecken transparent und freiwillig?
7. Anonymität
Sind die gesammelten Daten zur Deanonymisierung der Nutzer ungeeignet?
Ist die Nutzung ohne Erfassung oder Ableitung persönlicher Daten möglich?
8. Kein Aufbau von zentralen Bewegungs- und Kontaktprofilen
Unterbindet das System eine Standortverfolgung und den Aufbau von auf Individuen zurückführbare Muster häufiger Kontakte?
9. Unverkettbarkeit
Ist es unmöglich generierte IDs mit der Identität des Nutzers zu verknüpfen?
Ist ausgeschlossen, dass gesammelte Daten etwa zu Kontaktereignissen über längere Zeiträume verkettet werden können?
10. Unbeobachtbarkeit der Kommunikation
Wird verhindert, dass aus übermittelten Nachrichten auf die Infektion einer Person oder den Kontakt zu Infizierten geschlossen werden kann?
Hinweis: Die Fragen illustrieren den jeweiligen Prüfstein. Ihre Beantwortung mit “Ja” ist aus meiner Sicht notwendig für ein positives Ergebnis, aber nicht zwingend auch hinreichend. Zur Vertiefung empfehle ich die Lektüre des Originaldokumentes des CCC.
Die beschriebenen Prüfsteine sind ein Beispiel für Prinzipien. Im Softwareentwurf gibt es viele davon.
Vermutlich kennt Ihr so griffige Dinge wie KISS (Keep it simple, stupid), YAGNI (You Aren’t Gonna Need It) und DRY (Don’t repeat yourself) oder die SOLID-Prinzipien (die Buchstabern des Wortes SOLID sind die Anfangsbuchstaben von fünf Design-Prinzipien).
Prinzipien sind Grundsätze, an denen sich ein Entwurf und damit verbundene Entscheidungen orientieren. Die Beispiele oben versuchen Good Practices und Erfahrungswissen in einem Entwurf unterzubringen. Sie tun das in einer sehr allgemeinen Form – Prinzipien sind haltbarer als Muster oder konkrete Entscheidungen.
Beim Entwurf der Softwarearchitektur in Eurem Vorhaben könnt Ihr Euch bewusst auf die Einhaltung bestimmter Prinzipien einigen. Das ist praktisch, da Entscheidungen dann alle in die gleiche Richtung gehen, obwohl unterschiedliche Menschen in mitunter unterschiedlichen Teams sie treffen.
Oft “erbt” Ihr mit der Anwendung eines Architekturstils bestimmte Prinzipien mit. Bei Microservices sind dies etwa die lose Kopplung oder die dezentrale Datenhaltung.
Mein Kollege Stefan Toth differenziert in seiner Neuen Schule der Softwarearchitektur zwischen Regeln und Prinzipien. Regeln machen andere, geben sie vor und tragen auch die Verantwortung für ihre Sinnhaftigkeit. Prinzipien sind offener, und die Verantwortung liegt beim Team, was sich bei seinen Entwurfsentscheidungen an den Prinzipien orientiert.
Im frühen Stadium eines Vorhaben – bei embarc sprechen wir von der Architektur-Vision - stellen bewusst gewählte Prinzipien gerne erste Lösungsansätze zum Erreichen der Architekturziele dar. Bei der Deutschen Corona-Warn-App stand der Datenschutz ganz oben. Prinzipien wie Datensparsamkeit oder der dezentrale Ansatz passen da sehr gut.
Wenn wir jetzt die Corona-Warn-App der deutschen Bundesregierung, Kontaktverfolgungen anderer Länder, die aktuell viel beachtete Luca-App oder andere privatwirtschaftliche Lösungen an den Prüfsteinen des CCC reiben – bleibt Gold hängen?
Vorab: Die Entwicklung hätte bereits unter den Prinzipien erfolgen können. Die Prüfsteine sind früher veröffentlicht worden, als die Entwicklung der meisten Apps begann. Vorausgesetzt, der Ersteller “adoptiert” sie.
Tatsächlich gab es vor dem Entwicklungsstart der Corona-Warn-App beim Prüfstein 5 (“Keine zentrale Entität, der vertraut werden muss”) ein Umdenken. Bund und Länder entschieden zunächst im April 2020 mit ihrer App einen zentralen Ansatz zu verfolgen, schwenkten aber nach massiver Kritik, unter anderem vom CCC, um.
Hier ein Beitrag der Tagesschau vom 26.04.2020 dazu.
Der CCC hat bei der Veröffentlichung der Prinzipien klargestellt, dass er selbst keine Apps überprüfen wird (das sollten unabhängige Dritte tun) und entsprechend keine Prüfsiegel verteilt oder Empfehlungen für eine Lösung ausspricht. Die Verwendung von Apps, welche die Prüfsteine nicht erfüllen, lehnt er ab.
Das Entwicklungsteam der Corona-Warn-App (federführende Auftragnehmer: SAP und Telekom) diskutiert in seiner offiziellen Dokumentation ihre eigenen Lösungsansätze im Kontext der Prüfsteine und ist überzeugt, die techischen Anforderungen zu erfüllen. Und tatsächlich hat sich auch der CCC bezüglich dieser Umsetzung zumindest sehr wohlwollend geäußert.
Die zum Einchecken etwa in Läden immer verbreitetetere Luca-App hingegen steht bei Datenschützern in der Kritik. Der CCC forderte sogar eine Bundesnotbremse, um die “staatliche Alimentierung” der privatwirtschaftlichen Lösung zu stoppen. Hintergrund: Aus Sicht der Hackervereinigung erfüllt die App keinen einzigen der 10 Prüfsteine für Tracing-Apps. Insbesondere folgt der zentrale Ansatz von Luca (im Gegensatz zur dezentralen Corona-Warn-App) nicht Prüfstein 5 – im Gegenteil.
Nun muss man der Luca-App bei aller berechtigter Kritik gerade bezüglich handwerklicher Fehler doch mildernde Umstände einräumen. Sie kann bestimmte CCC-Prüfsteine nicht erreichen und gleichzeitig seine funktionalen Anforderungen erfüllen. Ihre Aufgabe ist laut Mission Statement eine “lückenlose Kontaktrückverfolgung im Austausch mit den Gesundheitsämtern”. Die App sammelt Daten über Nutzer, um sie zu melden. Dass sich das mit bestimmten Prüfsteinen des CCC beißt, ist quasi eingebaut.
Die Corona-Warn-App der Bundesregierung verfügt seit April 2021 ebenfalls über eine Eincheck-Funktion per QR-Code zur Clustererkennung. Gefordert wurde das schon lange. Etwaige Warnungen erfolgen über die gleichen Mechanismen wie zuvor bei direkten (also über Bluetooth erkannten) Kontakten. Direkt, ohne Gesundsheitamt. Der dezentrale Ansatz wird nicht aufgegeben.
Um diese datenschutzfreundliche (datensparsame) Lösung in der Gastronomie als Alternative zur Luca-App einsetzen zu können, sind Änderungen in den Bestimmungen der Länder nötig. Namentlich die verpflichtende Dokumentation zur Kontaktnachverfolgung – in der Regel (das ist in den Ländern unterschiedlich geregelt) mit Gastname und Telefonnummer.
Einige Prüfsteine waren bei der CWA im Sinne der methodischen Softwarearchitektur eher Regeln denn Prinzipien, vorgegeben durch den Auftraggeber. Besonders prominent der dezentrale Ansatz. Viele andere Prüfsteine hatten und haben aber sehr wohl Einfluss auf konkrete Entscheidungen in der CWA-Entwicklung und auch auf die digitalen Kontaktverfolgungen anderer Länder.
Ein Beispiel zum Abschluss: Prüfstein 4 (“Transparenz und Prüfbarkeit”) ist schwerer zu erreichen, als es auf den ersten Blick aussieht. Den Quelltext frei zur Verfügung zu stellen (wie bei der CWA auf GitHub) ist nur die halbe Miete. Interessierte müssen die App auch selber bauen und überprüfen können, ob die heruntergeladene App der von ihnen gebauten 1:1 entspricht. Diese Seite beschreibt für die Schweizer Warn-App SwissCovid die Lösungsansätze für einen “Reproducible Build”. Für die deutsche CWA steht das aktuell noch aus (siehe Diskussion bei GitHub und Anfrage bei FragDenStaat).
Am 24. Juni 2021 findet bei embarc ein geselliger Sommernachmittag mit tollen Menschen, spannenden Vorträgen und vielen interaktiven Formaten statt.
Ich zeige dort, wie Ihr einen prägnanten, kompakten Architekturüberblick für Eure Softwarelösung anfertigt. Am Beispiel der Corona-Warn-App. Ihr erfahrt dort unter anderem auch, mit Hilfe welcher Architekturprinzipien die anderen Qualitätsziele der CWA-Lösung (neben Datenschutz u.a. Zuverlässigkeit und Erweiterbarkeit) erreicht wurden. Weitere Informationen zum Midsommar plus kostenlose Anmeldung hier …