Kernpunkte:
- Schnittstellen für Webbrowser-Plug-ins
- „Soft Deletion“ in Datenbanken
- Data Mesh
10 Aus dem IT-Labor
10.1 Schnittstellen für Webbrowser-Plug-ins – Bedrohungen der Softwarevielfalt
Moderne Browser bieten die Möglichkeit, ihre Funktionalität mithilfe von Erweiterungen (sogenannter Plug-ins) zu ergänzen. Dabei handelt es sich um Programmergänzungen, die über definierte Schnittstellen mit dem Browser kommunizieren und so die Darstellung von Webseiten beeinflussen oder im Browser selbst Funktionen nachrüsten können. Die wohl bekannteste Form der Browsererweiterungen stellen Werbeblocker dar. Wegen der standardmäßigen Verknüpfung von Werbedarstellung und gleichzeitiger Übertragung von Nutzungsdaten sind Werbeblocker inzwischen ein wichtiges Werkzeug zum Selbstdatenschutz.
Google hatte bereits 2018 angekündigt, die für Werbeblocker essenzielle Schnittstellendefinition Manifest v2 grundlegend zu ändern. Ziel war dabei – nach Aussagen von Google – der bessere Schutz der Privatsphäre: Plug-ins erhalten bislang Vollzugriff auf die empfangene Webseite. Werbeblocker können dann die Inhalte filtern, aber bösartige Plug-ins können womöglich in der Seite enthaltene personenbezogene Daten auch stehlen oder korrumpieren. Mit den neuen Schnittstellen soll die Verarbeitung der Seite stets durch den Browser geschehen. Plug-ins müssen dann Filterwünsche an den Browser übermitteln. Und genau in dieser Übermittlung liegt das Problem: Google sieht bislang ein Maximum von 30.000 URLs vor, die geblockt werden können. Aktuelle Werbeblocker greifen jedoch auf Regelsätze mit über 300.000 Adressen zurück. Vereinfacht gesagt werden Werbeblocker unter den durch Manifest v3 festgeschriebenen Schnittstellen damit weniger effektiv.
Die amerikanische NGO Electronic Frontier Foundation (EFF) beschreibt daher das Manifest v3 als Beispiel für den „inhärenten Interessenkonflikt, der dadurch entsteht, dass Google sowohl den dominierenden Webbrowser als auch eines der größten Internetwerbenetzwerke kontrolliert“. Aus Sicht der Verbraucherschützer leistet Manifest v3 nichts für den Datenschutz, sondern schwächt ihn stattdessen.
Ein weiteres Problem erwächst aus dem Umstand, dass das dem Chrome-Browser zugrunde liegende Chromium-Projekt inzwischen die Basis diverser Browser darstellt, nicht nur desjenigen aus dem Hause Google. So setzt neben Brave und Vivaldi auch Microsoft Edge auf Chromium. Googles rigide Änderungen der Plug-in-Schnittstelle haben somit Auswirkungen nicht nur auf den eigenen Browser, sondern eine Vielzahl von Derivaten und damit einen gewaltigen Teil des gesamten Browsermarktes. Hier zeigt sich einmal mehr der Nachteil von Monokulturen im Softwarebereich: Der einzige Browser, der nicht auf Chromium basiert, ist Mozilla Firefox. Dort hat man bereits angekündigt, zwar Manifest v3 unterstützen zu wollen, gleichzeitig jedoch Version 2 weiter aktiviert zu lassen. Auf diese Weise können Filter-Plug-ins wie uBlock Origin zunächst weiterhin ihre Arbeit ohne Einschränkung verrichten.
Die langfristigen Folgen dieser Entwicklung sind schwer
abschätzbar. Brave hat hier eine bessere Ausgangsposition als viele
Konkurrenten, weil der hauseigene Werbe- und Tracking-Blocker im Network-Stack
eingebettet und vom eigentlichen Browser unabhängig ist. Allgemeine Erweiterungen
sind hingegen auf die entsprechend verfügbaren Schnittstellen angewiesen. So
dürfte es für einen Chromium-Abkömmling wie Brave schwer werden, die
v2-Kompatibilität aufrechtzuerhalten, wenn Google den Code vollständig
entfernt hat: Langfristig sind Erweiterungen, die die alte v2-Schnittstelle
benötigen, somit nicht mehr lauffähig. Eine Abspaltung des Programmcodes vom ursprünglichen Chromium-
Projekt (ein sogenannter Fork) würde langfristig viel Pflegeaufwand bedeuten,
weil alle künftigen sicherheitsrelevanten Änderungen im Fork manuell
nachgearbeitet werden müssten. Die Kompatibilität von Plug-ins unter den
verschiedenen Browsern wird zusätzlich leiden, und Entwickelnde müssen nicht
nur die Linien Chromium und Firefox bedenken, sondern künftig womöglich auch
Forks.
Ursprünglich hatte Mozilla die eigene Plug-in-Struktur mit der WebExtensions API näher an Chrome herangerückt, um die Entwicklung von Cross-Platform-Erweiterungen zu unterstützen. Nun könnten sich die Wege wieder trennen: Erweiterungen für Firefox könnten künftig weniger leicht portierbar sein, wenn die Browserwelten in Sachen Plug-in-Schnittstellen getrennte Wege gehen. Mozilla hat bereits angekündigt, bei der Umsetzung des Manifest v3 für Firefox Schnittstellen wie das WebRequest API, auf das Werbe- und Tracking-Filter angewiesen sind, weiterhin bereitzustellen.
Was
ist zu tun?
Wer einen Chromium-Abkömmling als
Browser verwendet, sollte die Berichterstattung über die Leistung der
verfügbaren Tracking-Blocker im Blick behalten und bei Bedarf die Browserplattform
wechseln. Für Nutzende von Firefox bzw. darauf basierenden Browsern ändert
sich nichts: Die Möglichkeiten, Tracking-Inhalte zu filtern, bleiben
unverändert gut.
10.2 „Soft Deletion“ in Datenbanken – warum dies kein Löschen ist
Für komplexe Datenbankanwendungen etabliert sich das Entwurfsmuster (Pattern) „Soft Deletion“. Hintergrund ist häufig, dass Löschungen in einer Datenbank so durchgeführt werden sollen, dass einzelne Datensätze einfach wiederhergestellt werden können. In einigen Szenarien sind Löschprozesse auch so zeitaufwendig, dass sie andere Datenbankprozesse erheblich beeinträchtigen.
Kernidee von „Soft Deletion“ ist es, das Löschen eines Datenbankeintrags durch eine „Löschen“-Markierung zu ersetzen: Beispielsweise wird eine neue Tabellenspalte „isDeleted“ angelegt und der Löschbefehl wird dadurch ersetzt, dass der jeweilige Wert „isDeleted“ auf „1“ gesetzt wird.
In Datenbanken mit vielen Bezügen der Datensätze untereinander müssen diese – anders als beim normalen Löschen – nicht überall aufgelöst werden, was sonst sehr aufwendig sein kann.
Mit „Soft Deletion“ sind aber einige Risiken und Hürden zu bedenken – nicht nur bei personenbezogenen Daten:
So müssen dauerhaft und konsequent alle Such- und Leseanfragen an die Datenbankanwendung überarbeitet werden, sodass Datensätze mit einem positiven „isDeleted“-Feld aussortiert werden.
Ist die Löschung eines Eintrags aus datenschutzrechtlichen Gründen geboten – z. B. aufgrund der zeitlichen Speicherbegrenzung (Art. 5 Abs. 1 e) DSGVO) oder des Rechts auf Löschen (Artikel 17 DSGVO) – so wird die Umsetzung mithilfe des Ansatzes „Soft Deletion“ in der Regel nicht der gesetzlichen Anforderung genügen können.
Nicht zuletzt ist zu bedenken, dass beim Einsatz von „Soft Deletion“ in einer Datenbankanwendung immer noch die Bezüge zu einem (nun gelöschten) Eintrag erhalten bleiben. Aus der Information, dass es bei einer betroffenen Person überhaupt einen solchen Bezug gegeben hat, könnte bereits ein Risiko für die Rechte und Freiheiten der betroffenen Person entstehen.
Was ist zu tun?
Der Einsatz von „Soft Deletion“ in
Datenbankanwendungen mit personenbezogenen Daten ist mit einigen schwer
absehbaren Risiken verbunden. Im Einzelfall muss geprüft werden, wie diese
Risiken minimiert werden können.
10.3 Data Mesh
Data Mesh ist ein relativ neuer Ansatz für eine dezentrale Datenarchitektur. Damit sollen beispielsweise Teams in der Softwareentwicklung die Möglichkeit haben, selbstständig Datenanalysen über das Verhalten von Nutzerinnen und Nutzern durchzuführen und diese mit anderen Teams auszutauschen. Das Prinzip ist übertragbar auf Organisationen mit fachlich stark spezialisierten Teams, die gemeinsam Erkenntnisse aus Datensammlungen gewinnen wollen.
Der Unterschied zu zentralen Datenarchitekturen wie Data Warehouses (ein physischer Datenbestand mit vereinheitlichten Daten aus mehreren Quellen) oder Data Lakes (ein System von Daten, die im Rohformat vorliegen) ist, dass anstelle einer zentralen Organisationseinheit jedes Team verantwortlich für die Datensammlung und -kuration ist – jeweils in dem eigenen Fach- bzw. Wissensgebiet (Domäne).
Mit der Idee eines Data Mesh (deutsch in etwa: Datengewebe), die auf der Theorie des „Domain-driven Design“ fußt, können die jeweils erfassten und aufbereiteten Daten als „Datenprodukte“ verstanden werden, die auch über mehrere fachliche Domänen hinweg genutzt werden können. Die dezentrale Datenverantwortung legt dabei auch eine dezentrale Speicherung nahe.
Der Begriff „Data Mesh“ wurde erst 2019 in einem Aufsatz von Zhamak Dehghani geprägt. Die von ihr beschriebenen Probleme von zentralen Datenarchitekturen und die von ihr eingeführten Prinzipien für die Umsetzung eines Data Mesh haben vielfach zu einem Paradigmenwechsel in Datenstrategien von Organisationen geführt.
Domain-driven Design
Mit Domain-driven Design wird eine
Herangehensweise an die Modellierung komplexer Software beschrieben, die einen
Schwerpunkt auf Fachlichkeit und Fachlogik und die Zusammenarbeit und
Einbeziehung von Fachleuten legt.
Sofern in einem Data Mesh auch personenbezogene Daten verarbeitet werden – wozu auch schon Daten zum Nutzungsverhalten zählen können –, müssen selbstverständlich die Vorgaben der Datenschutz-Grundverordnung eingehalten werden. So muss die datenschutzrechtliche Verantwortlichkeit geklärt werden und welche technischen und organisatorischen Maßnahmen für alle Beteiligten verbindlich vorgeschrieben werden – unabhängig von der beabsichtigten Selbstständigkeit der Teams.
Werden die Daten dezentral gespeichert und verarbeitet, müssen zudem Prozesse entwickelt werden, um die Wahrnehmung von Rechten der betroffenen Personen zu gewährleisten. Verfahren, die Betroffenen die Ausübung ihrer Rechte ermöglichen, beispielsweise des Auskunftsrechts oder des Rechts auf Löschung, sind dabei nicht immer trivial umzusetzen.
Daher bietet sich eine frühzeitige Anonymisierung und Aggregation von Daten an, um in weiteren Verarbeitungs- und Nutzungsschritten mehr Flexibilität zu erlangen. Dies kann schon bei der Datensammlung in den fachlich zuständigen Teams erfolgen.
Was
ist zu tun?
Verantwortliche, die eine Umsetzung
der Datenarchitektur „Data Mesh“ anstreben, müssen bei der Verarbeitung von
personenbezogenen Daten die datenschutzrechtlichen Anforderungen prüfen und gegebenenfalls
Maßnahmen ergreifen, um die Rechte und Freiheiten betroffener Personen zu
schützen.
Zurück zum vorherigen Kapitel | Zum Inhaltsverzeichnis | Zum nächsten Kapitel |