Konstruktive Kritik zum Vorschlag für ein Gesetz zur Einführung und zum Betrieb einer App-basierten Nachverfolgung von Infektionsrisiken mit dem SARS-CoV-2 (Corona) Virus
PM vom 4.5.2020: Gesetzesvorschlag geht in die richtige Richtung, hat aber an wesentlichen Punkten noch dringenden Nachbesserungsbedarf
Einleitung und Motivation
Wir AutorInnen der DSFA zur Corona-App[0] stehen einem Tracing-App-Vorhaben nach wie vor kritisch gegenüber[1]. Damit jedoch im Falle der Einführung eine minimal eingriffsintensive Variante eingesetzt wird, äußern wir uns konstruktiv zu einem ersten Gesetzegebungsvorschlag, der hier[2] veröffentlicht wurde. Dabei greifen wir nur die unserer Ansicht nach wichtigsten Punkte auf.
Kernpunke unserer Kritik
-
Bei der Ankunft der Infektionsdaten (im Entwurf: „pseudonyme Kennung“) auf dem Server muss der Personenbezug bereits gekappt sein. Ein simpler Verzicht des Loggens ist bei weitem nicht ausreichend, siehe Kommentar zu E-§ 5.
-
Eine Tracing-App zur Pandemie-Bekämpfung darf nicht für weitere Zwecke außer dem Tracing selbst genutzt werden. Die „Optimierungsfunktionen“ müssen daher klarer definiert und streng begrenzt werden, siehe grundsätzliche Überlegungen.
-
Die Freiwilligkeit der App-Nutzung darf nicht durch einen Anspruch auf Testung und damit Privilegierung der NutzerInnen konterkariert werden, siehe Kommentar zu E-§ 10.
Grundsätzliche Überlegungen
Der Einsatz einer App zur Pandemiebekämpfung bedarf eines klaren gesetzlichen Rahmens. Der vorgelegte Entwurf ist ein Einzellfallgesetz, was im Falle der Pandemieeindämmung nicht die vorzugswürdige Form ist. Eine allgemeine Regelung, die das Diskriminierungs- und Privilegierungsverbot beachtet, ist vorzuziehen (Art. 19 GG).
Im aktuellen Entwurf ist die Verbesserung der App in E-§ 12 (Verbesserung der Genauigkeit der Risikowarnungen) so unklar formuliert, dass eine Zweckentfremdung bis hin zu einer Datenspende-Funktion zu befürchten ist. Eine Datenspende-Funktion muss jedoch in einer anderen App mit einer anderen Rechtsgrundlage geregelt werden. Daher sind die „Parameter der Begegnungen“ in E-§ 12 genau zu spezifizieren. Eine Vermengung mehrerer Zwecke in einer App lehnen wir ab. Eine Datenspende-App muss funktionsbedingt weit mehr Daten speichern, als eine Infektionswarnungs-App bräuchte (Datenminimierung). Eine App zur Pandemiebekämpfung muss sich an einen möglichst großen NutzerInnenkreis richten, also möglichst einfach nutzbar und insbesondere übersichtlich gestaltet sein. Aktuelle App-Entwürfe zeigen bereits, wie Dark-Patterns verwendet werden können, um dem Tracing weitere Zwecke unterzuschieben.[3]
Ebenso wäre es sinnvoll und hilfreich, das Risiko für die Betroffenen bereits gesetzlich als „hoch" einzustufen. Dadurch würden wichtige Schutzvorkehrungen festgelegt, wie beispielsweise die Implementation eines Datenschuz-Managementsystems und die Durchführung einer Datenschutz-Folgenabschätzung (DSFA). Soweit in dem Verfahren personenbeziehbare Daten verarbeitet werden, ist gesetzlich festzulegen, dass diese nicht, insbesondere nicht serverseitig, verarbeitet werden. Zudem muss gesetzlich sichergestellt werden, dass insbesondere für pseudonymisierte Daten durch technische und organisatorische Maßnahmen eine Rück-Beziehbarkeit der Daten weitestgehend ausgeschlossen wird.
Konkrete Paragraphen
-
Zu E-§ 4 (Betreiber) Abs. 4: Es fehlt die Berücksichtigung des Rechts auf Abstreitbarkeit der Nutzenden und Nicht-Nutzenden als Ausdruck der Freiwilligkeit im Sinne von E-§ 3 Abs. 2.
-
Zu E-§ 5 (Verfahren): In Abs. 3 sollten die Anforderungen nicht nur technisch, sondern umfassend formuliert werden. Wir verweisen insoweit sinngemäß auf die Empfehlungen in unserer DSFA (siehe DSFA-Kapitel 9 – Empfehlungen [0]): Eine De-Anonymisierung oder sonstige Identifikation der App-Nutzenden ist zu untersagen. Dies ist durch rechtliche, organisatorische und technische Maßnahmen zu verhindern. Als BetreiberInnen kommen nur solche Organisationen in Frage, die kein eigenes Interesse an den Daten haben. Sie müssen vor Pflichten zur Herausgabe von Daten geschützt sein, auch gegenüber Sicherheitsbehörden. Organisatorisch müssen die Verantwortliche strategisch und die BetreiberInnen operativ eine Mischstruktur etablieren, um dieses Ziel zu erreichen. Die Verantwortliche – also das RKI – kann etwa strategisch mehrere unterschiedliche BetreiberInnen auswählen: eine betreibt die Eingangsknoten im Netzwerk, die andere die Server, auf denen gespeichert wird und optional eine dritte, die zwischen App und Eingang ein Mix-Netz betreibt. Operativ sollte die Abtrennung des Personenbezuges innerhalb der Organisationen durch eine zweckdienliche Abteilungsstruktur, Funktionstrennung und Rollentrennungen etc sichergestellt werden. Letztlich dürfen auf dem Server gar keine pseudonymen Kennungen ankommen, sondern allein „infektions-indizierende Daten ohne Personenbezug“, siehe den Begriff „iDoP“ in [0]. Es fehlt zudem die Feststellung, dass von dem Verfahren ein „hohes Risiko" für die betroffenen Personen im Sinne der DSGVO ausgeht.
-
Zu E-§ 6 (Löschung der Daten): Ziel des Verfahrens muss es primär sein, dass keine personenbezogenen Daten auf der Serverinfrastruktur vorliegen (Datenminimierung). Wenn dort personenbezogenen Daten vorliegen, so versagt die Anonymisierung und das System ist nicht einzusetzen.
-
Zu E-§ 8 (Datenschutz-Beauftragter, Datenschutz-Management und Datenschutz-Folgenabschätzung): Folgende Aspekte sollten präziser gefasst bzw. erweitert werden. Die Verantwortliche ist zu verpflichten, dem Bundesbeauftragten für Datenschutz und Informationsfreiheit (BfDI) eine Datenschutz-Beauftragte gem. DSGVO zu melden. Die Verantwortliche weist dem BfDI nach, dass dieser ein wirksames Datenschutz-Management im Sinne des Art. 32 Abs. 1 lit. d DSGVO in Verbindung mit einem IT-Sicherheitsmanagement für dieses Verfahren betreibt. Das Datenschutz-Management hat dabei die Funktion, Regelverstöße zu erkennen, unverzüglich Korrekturmaßnahmen durchzusetzen und die DSFA kontinuierlich fortzuführen. Die Verantwortliche ist zu verpflichten, dem BfDI die DSFA im Sinne des Art. 35 DSGVO, in Verbindung mit Art. 5 DSGVO als Kriterien zur Modellierung der zu betrachtenden Risiken zur Verfügung zu stellen. Zugleich ist die DSFA in geeigneter Form zu veröffentlichen. Das BSI ist zu verpflichten den Prüfbericht dem BfDI zur regelmäßigen Auditierung und Zertifzierung vorzulegen.
-
Zu E-§ 10 (Recht auf Test und Vorgehen im Falle eines Positivtests): Der Anspruch auf einen unverzüglichen Test durch die warnende App ist ein Widerspruch zur höherrangigen Freiwilligkeit laut E-§ 3 Abs. 2, denn dort findet sich „Es ist unzulässig, unmittelbare oder mittelbare Vor- oder Nachteile an das Vorhandensein oder das Fehlen der App auf dem mobilen Endgerät von Nutzenden zu knüpfen.“ Ein Anspruch auf Testung ist jedoch ein solcher Vorteil, dieser muss demnach aus dem Vorschlag weichen, da gem. E-§ 3 (Freiwilligkeit) aus der Nutzung der App keine Vorteile erwachsen dürfen.
-
Zu E-§ 11 (Alternative Apps): Die alternativen Apps sind zusätzlich einer Prüfung durch das BSI gem. E-§ 8 Abs 2 zu unterziehen und der Prüfbericht ist dem BfDI zur regelmäßigen Auditierung und Zertifizierung vorzulegen und in aussagekräftiger Form zu veröffentlichen. Über ihre Zulassung darf nicht allein das RKI in Selbstkontrolle entscheiden, weil die Zulassung nicht nur Fragen zu IT-Sicherheit und Protokollkonformität umfasst, sondern auch Datenschutzfragen. Das RKI hat als Forschungsinstitut ein eigenes Interesse an einem höheren Nutzungsumfang, also Datenaufkommen, der Apps.
„Der Einsatz einer App zur Pandemiebekämpfung darf nicht dem freien Spiel des Marktes überlassen bleiben – insbesondere nicht den großen Plattformbetreibern. Sie muss daher gesetzlich klar geregelt werden. Dabei müssen diese Regelungen vorausschauend, theoretisch sowie praktisch informiert und technikneutral konzipiert werden. Dazu will dieser Kommentar konstruktiv beitragen.“ kommentiert Kirsten Bock, Datenschutzrechtsexpertin vom FIfF abschließend.
Verweise
Kontakt bezüglich dieser Pressemitteilung
Rainer Rehak: E-Mail: rainer [punkt] rehak [ät] fiff.de
Betreff: „CWA-Gesetz – PM vom 4.5.2020“
PGP: 0D66 63E5 70A3 964A EE60 D927 4427 CFE5 8C19 AE19
Das Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung (FIfF) e. V.
Das Forum InformatikerInnen für Frieden und gesellschaftliche Verantwortung (FIfF) e. V. ist ein deutschlandweiter Zusammenschluss von gut 700 Menschen, die sich kritisch mit Auswirkungen des Einsatzes der Informatik und Informationstechnik auf die Gesellschaft auseinandersetzen. Unsere Mitglieder arbeiten überwiegend in informatiknahen Berufen, vom IT-Systemelektroniker bis hin zur Professorin für Theoretische Informatik. Das FIfF wirkt seit 1984 in vielen technischen und nichttechnischen Bereichen der Gesellschaft auf einen gesellschaftlich reflektierten Einsatz von informationstechnischen Systemen zum Wohle der Gesellschaft hin. Zu unseren Aufgaben zählen wir Öffentlichkeitsarbeit, sowie Beratung und das Erarbeiten fachlicher Studien. Zudem gibt das FIfF vierteljährlich die „FIfF-Kommunikation – Zeitschrift für Informatik und Gesellschaft“ heraus und arbeitet mit anderen Friedens- sowie Bürgerrechtsorganisationen zusammen.