Da sich jüngst sehr viele Parteien (politische wie unpolitische) sich zum Thema Corona-App äußern, die - für mein Empfinden - nicht wirklich was von den Hintergründen verstehen, habe ich mir gedacht, dass ich da auch noch meinen Senf dazugeben kann; Ich beschäftige mich ja immerhin durchaus viel mit Daten... ;-)
Alle Aussagen zu Zielen, juristischen Hintergründen etc.basieren auf meinen laienhaften Annahmen!
Worüber reden wir bei einer "Corona-App" überhaupt?
Ziel aller Maßnahmen, die unsere "Bürgerrechte" derzeit "beschränken", ist es bekanntlich, die Zahl der (täglichen) Neuinfektionen mit COVID-19 so weit herunter zu drücken, dass in jedem Einzelfall die Infektionskette zurückverfolgt werden kann. Die Kontakte einer nachgewiesen infizierten Person müssen dann in Quarantäne, bis sie negativ getestet sind. Bei einem positiven Test eines Kontakts geht dieser Vorgang mit dessen Kontakten von vorne los etc. pp.
Die geplante App soll zwei Ziele verfolgen:
- Den Gesundheitsämtern eben jene Verfolgung der Kontakte vereinfachen
- Den Benutzern die Möglichkeit geben, selber zu sehen, ob sie mit einer infizierten Person Kontakt hatten
Durch die App soll die Nachverfolgung so effektiv werden, dass ein "weitgehend normales" Leben möglich wird.
Was muss gespeichert werden, und welche Ansätze gibt es?
Bei einer Inkubationszeit von 14 Tagen kommen selbst mit den derzeitigen Kontaktbeschränkungen so einige Kontakte zusammen. Lieschen Müller hat wahrscheinlich (well, hoffentlich) nur Kontakt zu
- ihrer engsten Familie (häufig, i.e., laufend)
- Personal in Supermarkt/Drogerie/... (ein bis zwei pro Woche?)
- ein Schnack mit dem Nachbarn (ein bis zwei pro Woche?)
Das Personal im Einzelhandel aber hat schon Hunderte oder Tausende Kontakte pro Tag.
Jetzt gibt es zwei Ansätze, den zentralen und den dezentralen.
Der zentrale Ansatz
Die Idee beim zentralen Ansatz wäre letztlich, dass alle App-Benutzer ihren Aufenthaltsort laufend an einen Server übermitteln. Dort kann dann das Bewegungsprofil eines Infizierten mit den Bewegungsdaten aller anderen Benutzer abgeglichen werden, um Kontakte daraus zu generieren. Ein Beispiel (mit Schiffsdaten) für so etwas findet sich z.B. in diesem Vortrag auf Seite 22.
Um möglichst alle Kontakte zu erfassen, sollte m.E. so ca. alle 10-15 Sekunden eine Position erfasst werden. Das wären bei 15 Sekunden 5760 Datensätze pro Tag und Person, für 14 Tage und 80 Mio. Einwohner also 6.451.200.000.000 Datensätze. In PostgreSQL/PostGIS könnte man jeden Datensatz in 56 Bytes speichern (angenommen, es wird ein halbwegs sicherer Hash für die Nutzer-ID verwendet):
# SELECT pg_column_size(sha256('abc')) hash, pg_column_size('timestamp') zeitstempel, pg_column_size('geography') ort;
┌──────┬─────────────┬─────┐
│ hash │ zeitstempel │ ort │
├──────┼─────────────┼─────┤
│ 36 │ 10 │ 10 │
└──────┴─────────────┴─────┘Realistisch sind, bedingt durch die Ausrichtung an 8-Byte-Grenzen und die Metadaten aber eher ~ 96 Bytes, sagen wir 100. Das wären dann:
# SELECT pg_size_pretty(4*60*24*14*80000000::bigint*100); ┌────────────────┐ │ pg_size_pretty │ ├────────────────┤ │ 587 TB │ └────────────────┘
Ja Bingo!, und das soll dann auch noch laufend analysiert werden?!? Ich kann mir schon vorstellen, wie dem Oracle-Key-Accounter für's Gesundheitsministerium das Messer in der Hose aufgegangen ist...
Ok, also nochmal drüber nachgedacht... die allermeisten Menschen halten sich stets an denselben Orten auf, zuhause, auf der Arbeit, beim "significant other". Selbst ohne Kontaktbeschränkungen (und das soll ja das Ziel sein!) könnte man also Zonen deklarieren, wo keine Erfassung erforderlich ist. Dann verbleibt vielleicht noch durchschnittlich eine Stunde pro Tag und Person, macht:
# SELECT pg_size_pretty(4*60*14*80000000::bigint*100); ┌────────────────┐ │ pg_size_pretty │ ├────────────────┤ │ 24 TB │ └────────────────┘
Das ist zumindest händelbar, wenngleich da noch keine Indexe berücksichtigt sind. Die Reports wären trotz allem eine ganz ordentliche Herausforderung. Aber wer 700k€ für einen App-Prototyp über hat, braucht sich ja über beefy Hardware keine Sorgen zu machen...
Und diese Eckdaten erklären wohl auch, warum man ausgerechnet SAP mit in's Boot geholt hat, denn die werden ja nicht müde zu betonen, dass ihr Produkt mit solchen Auswertungen kein Problem hat.
Der dezentrale Ansatz
Der jetzt favorisierte dezentrale Ansatz soll wohl regelmäßig die Umgebung des Telefons scannen, welche Bluetooth-Geräte in der Nähe sind, und diese (anonymisiert, also gehasht) auf dem Gerät speichern. Wenn eine Infektion festgestellt wird, wird der entsprechende Hash des eigenen Geräts an einen zentralen Server gemeldet, dieser verteilt die gesammelten Hashes der Infizierten an alle anderen Geräte und diese können dann also den Abgleich vornehmen ("habe ich diesen Infizierten in den letzten 14 Tagen in meiner Umgebung gesehen?").
Das bedeutet, pro Kontakt werden ein Hash, ein Zeitstempel und ggfs. ein Ort (?) gespeichert. Bei 1000 Kontakten/Tag plus 1000 Neuinfektionen/Tag, die von der zentralen Instanz übermittelt werden, wären das selbst bei uneffektiver Speicherung auf dem Mobilgerät ein bis zwei Megabytes.
Die zu verteilenden Daten sind gemessen an z.B. Netflix o.ä. nicht weiter erwähnenswert. Und den lokalen Abgleich ("Ist unter den 1000 Neuinfektionen ein Hash, den ich in den letzten 14 Tagen gesehen habe?") kann selbst das schwächste heutzutage genutzte Mobilgerät locker vornehmen, die Batterie wird also auch nicht leer gesaugt oder ähnliches. Ok, Bluetooth und GPS laufen halt dauernd, aber das ist ja fast Standard heutzutage.
Kritik
Der zentrale Ansatz
scheitert m.E. wie eben gesehen schon an der technischen Machbarkeit. Was aber viel kritischer gesehen wurde und wird ist die Tatsache, dass hier Bewegungsprofile von Millionen von Bürgerinnen und Bürgern erstellt werden könnten.
Wenn man jetzt mal das Aluhütchen aufsetzt und annimmt, dass als "ID" eben kein Zufallswert (z.B. eine UUID) dahergenommen wird, sondern z.B. die IMEI des Mobilgeräts da rein fließt und der genutzte Hash-Algorithmus bekannt ist, ist die Verknüpfung von Mobilfunk-Vertragsdaten, Vorratsdatenspeicherung bei den Providern, den Corona-Daten und z.B. Melderegistern, Polizeicomputern etc. gedanklich nicht mehr weit. Und wenn man die Nachrichten verfolgt, weiß man, dass es da gewisse Schwierigkeiten gibt... und wenn nur ein geschiedener Sachbearbeiter im Gesundheitsamt herausfinden will, wo denn der "significant other" der Verflossenen wohnt, ist das noch harmlos!
Ich möchte solche Daten auf jeden Fall nicht in den Händen eines potentiell sehr großen und unübersichtlichen Personenkreises sehen.
Der dezentrale Ansatz
wiederum hat auch durchaus Knackpunkte.
Fragen, die sich mir (derzeit) stellen:
- Wer meldet den Verdacht bzw. die Infektion? Ärzte sind m.W. nach den Seuchenbekämpfungsgesetzen verpflichtet, Infektionen namentlich an die Gesundheitsämter zu melden (logisch). Wenn gleichzeitig die Corona-App-ID des betroffenen gemeldet wird, ist es mit der Anonymität natürlich schnell dahin. Zudem müssten die Ärzte mit entsprechender Software ausgestattet werden.
Oder aber man muss in der App ein "Knöpfchen drücken". Dann wiederum weiß man, dass eben nicht nur die Ehefrau informiert wird, sondern auch die Geliebte und die Nachbarn. Beim Tracking durch das Gesundheitsamt kann man evtl. noch auf Diskretion hoffen, aber das passiert letztlich ja zwangsweise.
Auf jeden Fall weiß man, dass das eigene Melden in "richtiger", strenger Quarantäne münden wird. Was auf jeden Fall eine enorme Hemmschwelle darstellt.
Also doch der Arzt? Wie kommt der an meine "ID"/meinen Hash? Muss er seine Praxis abscannen?
Und was, wenn ich in der App die Meldung bekomme, dass ich Kontakt mit einem Infizierten hatte? Dann bedeutet das ja auch für mich potentiell Quarantäne! In Anbetracht der enormen Unvernunft, die man seit Beginn der Lockerungen beobachten kann ("Warum soll ich denn immer noch Abstand halten, ich trage doch ne Maske!?!"), regen sich bei mir deutliche Zweifel, dass die Leute das (konsequent) nutzen würden.
Wie kommt dann also das Gesundheitsamt an diese so wichtige Information? Dann müsste die App im Fall der möglichen Infektion automatisch Rückmeldung geben ("Dieses Gerät war nah am Infizierten"). Wie erkenne ich dann den Nutzer? Wie erreiche ich ihn? Darf in so einem Fall ohne explizites Einverständnis des Nutzers z.B. die IMEI und/oder die Telefonnummer übermittelt werden? - Wenn die Entwicklung wirklich offen stattfindet (um Gottes willen, ja, bitte!), ist der Hash-Algorithmus bekannt. Das heißt aber auch, dass z.B. Arbeitgeber relativ einfach Tabellen mit Hashes ihres Personals anlegen könnten. Damit wiederum muss sichergestellt sein, dass die Hashes der Infizierten nicht öffentlich abgerufen werden können (damit die hoheitliche Aufgabe des Trackings auch hoheitlich bleibt).
Da wünsche ich viel Erfolg mit, zumindest sind damit schonmal alle gerooteten Geräte (auf denen man TLS-Proxies installieren könnte) außen vor, denn die könnten den Traffic der App einfach mitschneiden und hätten die Daten "frei Haus". - Was passiert, wenn Trolle das System "fluten"? Irgendwelche selbsterklärten "Freiheitskämpfer", die mit dutzenden Wegwerf-Telefonen (oder - Gott bewahre - über eine schlecht implementierte API!) massenhaft "false positives" in das System spülen? Oder mit Bluetooth-Dongles in Supermärkten bundesweit Infizierte "simulieren"?
"Fazit"
In Summe ist jeder Ansatz ein datenschutztechnischer Albtraum. Eine zentrale Datensammlung verbietet sich m.E. von vornherein, schlicht weil aus der Vergangenheit bekannt ist, welche Begehrlichkeiten ein solcher Daten-"Schatz" weckt.
Der dezentrale Ansatz hat wiederum offensichtliche Probleme beim "Rückkanal", also der Verfügbarmachung der Informationen an die zuständigen Stellen (Gesundheitsämter). Der Faktor "Mensch" ist das Hauptproblem, den kann man wiederum eigentlich nur aushebeln, wenn man datenschutzrechtlich einige sehr grenzwertige Kompromisse macht.
Dann stellt sich mir (natürlich!) die Frage, warum man etwas, das a) funktionieren soll und b) dies auch noch möglichst in diesem Jahrzehnt und c) meine o.g. Bedenken vernünftig und (halbwegs) rechtskonform löst, ausgerechnet von T-Systems und SAP implementieren lassen will. Bis einer dieser Konzerne gedanklich so weit kommt (i.e., bis die fähigen Leute ihr Management so weit gebracht haben) wie ich bei einer Tasse Kaffee, dauert es zwei Monate. Bis das schriftlich festgehalten wurde, ist es Herbst. Und dann kommt ja noch der jeweils andere Konzern und (mind.) ein Ministerium, der Bindesdatenschutzbeauftragte, das BSI, Apple, Google etc. dazu!
Und am Ende kommt fast garantiert etwas heraus, dass unlogisch zu bedienen ist (courtesy SAP), langsam und nur wenn die T-Cloud gerade funktioniert (courtesy T-Systems), das unsichere Verschlüsselung benutzt ("muss auch auf 8 Jahre alten Geräten funktionieren"), vom Datenschutzbeauftragten massiv kritisiert wird, vom BSI nur wegen einer Dienstanweisung aus dem Innenministerium ("wir wollen diese Daten auch!") zähneknirschend abgenommen wurde und - natürlich - Milliarden an Euronen verschlingt (vielleicht kann Herr Scheuer einen Kontakt zu Eventim erstellen, da liegt noch ein Vertragsentwurf rum, der nur leicht angepasst werden muss...).
Das ganze Ding basiert auf Vertrauen, es gibt nur einen Versuch. Wenn erstmal die App über einen - per z.B. nicht vernünftig abgesicherter API - eingeschleusten "Super-Infizierten" große Teile der Bevölkerung verunsichert hat, war sie eine Totgeburt.
Pro-Tipp: je größer das umsetzende Unternehmen ist, desto höher die Wahrscheinlichkeit, dass sowas passiert...
Ich halte den Ansatz, mittels einer App die "Normalität" für einen Großteil der Bevölkerung wiederherzustellen, für gut. Ich hoffe nur inständig, dass keine dummen Fehler gemacht werden. Erfahrungen aus der Vergangenheit lassen mich an Letzterem aber leider zweifeln... seufz!