#actwithus

Neue Entwicklerwerkzeuge sagen zentralisierten Cloudservices den Kampf an. Doch wie praxistauglich sind dezentrale Datenbanken wirklich? Und welche Komplikationen ergeben sich, wenn es zur Speicherung personenbezogener Daten kommt?

Langsam aber sicher kommt das Web3 auch bei klassischen Webapplikationen an. Brandneue Initiativen wie juno.build oder Polybase setzen auf völlig neuartige technologische Fundamente. Wo einst Projekte die fest in der Cloud verankert waren, wie Firebase, Supabase oder ein anderes, aus der Vielzahl an vergleichbaren Projekten, mit dem Versprechen eines “serverless Backends” um die Gunst von Entwicklern warben, rückt nun eine neue Generation von Entwicklerwerkzeugen nach die sich dem Web3 und der Dezentralität verschrieben haben. Heute sind Tools wie Firebase aus der modernen Entwicklungslandschaft nicht mehr wegzudenken - doch gerade Technologie ist nie vor dem Wandel der Zeit gefeit. War man jahrelang auf Cloudservices angewiesen, geht das mittlerweile auch mithilfe von dezentralen Protokollen.

Die Prämisse klingt vielversprechend: kostengünstige Rechenleistung und Speicher mittels Web3-nativer Infrastruktur wie dem Internet Computer (ICP) und Storageprotokollen wie Filecoin, dem Interplanetary File System (IPFS), oder Arweave - und das alles dezentral und mit voller Kontrolle über die eigenen Daten und Services. Einen besonderen Anreiz bietet auch die enge Integration mit hochmodernen Authentifikationsmechanismen, wie beispielsweise der Internet Identity, die mit biometrischer Authentifizierung und ausgeklügelten Pseudonymisierungsverfahren auf kompromisslose Sicherheit und Schutz der Privatsphäre des Nutzers setzt. Werden hingegen Wallets zur Authentifikation genutzt, erschliesst der nahtlose Übergang zu kostengünstigen und einfach integrierbaren Zahlungsmöglichkeiten in der eigenen Applikation neue Wertschöpfungsquellen. Die Grundidee ist nicht neu - jedoch machen es Initiativen wie juno.build oder Polybase zunehmend einfacher auf diesen dezentralen Technologien aufzubauen.

Doch stellt sich die Frage inwieweit die Vereinbarkeit mit datenschutzrechtlichen Bestimmungen gegeben ist. Sowie diese neuen Frameworks beginnen vermehrt Fuss zu fassen, wird dies zunehmend auch eine Frage für Unternehmer, die selbst Softwareteams leiten oder Entwicklung von Software bei externen Dienstleistern in Auftrag geben. Wenn Sie Ihr Entwicklerteam mit einem Pitch für Web3-Technologien konfrontiert, stellt sich für Sie als Unternehmer die Frage, welche rechtlichen Risiken dies nach sich zieht.

Lassen Sie uns mal sehen - Web3 bedeutet in erster Linie Dezentralität. Wie gemeinhin bekannt, ist es eine neuartige, unveränderbare Datenstruktur - die Blockchain - die diese Dezentralisierung auf sichere Weise ermöglicht. Und sind Daten erstmal auf die Blockchain geschrieben worden, verbleiben sie auch auf ihr. Die Möglichkeit vergangene Einträge nachträglich zu modifizieren oder zu löschen besteht nicht. Inwieweit ist aber solch eine unveränderliche Datenstruktur überhaupt geeignet für die Speicherung von potentiell personenbezogenen Daten? Das wirkt zunächst etwas sinnbefreit. Um hier Licht in die Sache zu bringen muss zunächst präzisiert werden, wie Web3-native Datenbanken wirklich funktionieren. Kaum ein Blockchain-basierter Datenspeicher speichert die Daten direkt auf einer Blockchain - und zwar nicht nur aus Bedenken zum Datenschutz, sondern es wäre schlichtweg zu teuer: einen winzigen, 1 Megabyte grossen Datensatz auf der Ethereum-Blockchain zu persistieren entspräche Kosten von etwa USD 10’000.-.[https://polybase.xyz/docs/introduction] Dezentralisierte Datenbanken nutzen stattdessen on-chain Proofs in Kombination mit off-chain Speicherung der Daten. Die Daten selbst können hierbei auf unterschiedlichste Weise gespeichert werden - die datenschutztechnischen Implikationen von dezentralisierten Datenbanktechnologien lassen sich demnach nicht über einen Kamm scheren, sondern müssen nuanciert betrachtet werden.

Um dies am Beispiel der eingangs erwähnten Frameworks zu verdeutlichen: juno.build baut auf dem Internet Computer auf. Der sogenannte Canister Code (in groben Zügen vergleichbar mit einem Smartcontract) der im Hintergrund zum Einsatz kommt, kann Daten tatsächlich löschen - und die unveränderlichen Ledgereinträge sind nur kurzlebig. Nichtsdestotrotz nimmt die ICP-Infrastruktur out-of-the box keine Rücksicht auf DSGVO-Compliance. Das Thema wird aktuell aktiv in der Community diskutiert.[https://forum.dfinity.org/t/gdpr-compliant-nodes-and-subnets/18162/3] Hier geraten wir doch ein wenig in schwieriges Fahrwasser. Mehr Flexibilität hinsichtlich der Speichermodalitäten bietet hingegen Polybase: von Optionen zur dezentralisierten oder zentralisierten Speicherung von Daten - letzteres mag in diesem Kontext ein wenig antithetisch anmuten - bis hin zur Möglichkeit, dass besonders sensible Daten das Endgerät des Nutzers gar nicht erst verlassen.

Wie geht man aber nun konkret mit personenbezogenen Daten um, wenn eine dezentrale Speicherung für den eigenen Anwendungsfall die geeignetste Lösung darstellt? Dass Web3-native Authentifikationsmethoden die Benutzer zumeist pseudonymisieren, könnte uns in einem trügerischen Gefühl der Sicherheit wiegen. Am Beispiel der DSGVO wird jedoch ersichtlich: die Gesetzgebung zieht hier eine klare Trennlinie zwischen Pseudonymisierung und echter Anonymisierung. [https://commission.europa.eu/law/law-topic/data-protection/reform/what-personal-data_en] Eine reine Pseudonymisierung ist nicht zwingend gleichzusetzen mit unumkehrbarer Anonymisierung. Dies hängt jeweils von den Umständen und Implementationsdetails ab.

Ein viel besungener Aspekt von Web3-Plattformen ist die Selbstbestimmung der Nutzer über ihre eigenen Daten. Frameworks wie Polybase bieten den Softwareentwicklern die notwendigen Werkzeuge hierfür - fordern dies jedoch nicht ein und folgen lieber einem multimodalen Ansatz. Polybase macht es beispielweise einfach, die Daten mit einem Wallet zu verschlüsseln - und gibt einer Applikation dabei sowohl die Möglichkeit die Daten auf Applikationsebene mit einem Custodial Wallet zu verschlüsseln, oder auch jedem einzelnen Nutzer die Verschlüsselung selbst zu überlassen. Nur im letzteren Fall können sich die Nutzer absolut sicher sein, dass sie die alleinige Kontrolle haben, zu entscheiden wer ihre Daten lesen darf. Am Ende des Tages obliegt also den Applikationsentwicklern die Entscheidung, wie viel Eigenbestimmung sie ihren Nutzern überantworten wollen.

Zusammenfassend lässt sich sagen: ob personenbezogene Daten vor der Speicherung auf irreversible Weise anonymisiert werden, ist der ausschlaggebende Faktor. Ob Daten verschlüsselt oder pseudonymisiert werden hat für sich alleine gesehen noch keine Aussagekraft. Die vollständige Kontrolle des Nutzers über den Verschlüsselungsprozess ist demnach in diesem Sinne genauso bedeutend wie die Verschlüsselung der Daten selbst. Solange nur der Nutzer selbst die Daten entschlüsseln kann, ist eine vollständige Anonymisierung der sensiblen Daten gegeben. Ob die Möglichkeit hierfür gegeben ist, muss für jedes Framework im Einzelfall evaluiert werden. Polybase bietet sowohl die Option, Daten bei den Nutzern zu belassen, oder sie bei einer dezentralen Speicherung zunächst vom Nutzer selbst zu verschlüsseln. Im Gegensatz hierzu stehen Frameworks wie juno.build. juno.build und im erweiterten Sinne die ICP-Infrastruktur wird diese Fragestellung erst noch lösen müssen, um auch in Domänen, die datenschutzbewusst agieren, vorbehaltlos zum Einsatz kommen zu können.