Multiparty Session Types for GDPR Purpose Compliance
Dieses Paper führt ein formales Framework auf Basis von Multiparty Session Types ein, das die Zweckbindung der DSGVO als strukturierte Interaktionsprotokolle modelliert und dadurch eine rigorose Laufzeitverifikation der Zweckkonformität in verteilten Systemen durch ein Typsystem ermöglicht, welches sicherstellt, dass wohltypisierte Implementierungen strikt ihre deklarierten Datenverarbeitungszwecke einhalten.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich eine Welt vor, in der Ihr digitales Leben eine geschäftige Stadt ist, und jedes Mal, wenn Sie ein Stück Information übergeben – wie Ihren Namen, Ihre Krankengeschichte oder Ihre Adresse –, ist das so, als würden Sie einem Kurier einen versiegelten Umschlag übergeben. In dieser Stadt gibt es ein sehr strenges Regelwerk namens DSGVO (Datenschutz-Grundverordnung). Dieses Regelwerk besagt, dass jeder Umschlag ein spezifisches „Zweck-Etikett“ tragen muss, wie zum Beispiel „Nur zur Diagnose“ oder „Nur für die Abrechnung“. Die Regel ist einfach: Wenn Sie einem Kurier einen Umschlag mit der Aufschrift „Diagnose“ geben, darf er ihn nicht öffnen, um später Ihre Adresse für einen „Marketing“-Flyer zu lesen. Das wäre ein Verstoß.
In der realen Welt der Software sind diese „Zweck-Etiketten“ jedoch oft nur Klebezettel auf einem Schreibtisch. Es sind informelle Versprechen, die der Computer-Code tatsächlich nicht liest oder befolgt. Der Code könnte versehentlich den falschen Umschlag öffnen, oder ein Kurier könnte sich verlaufen und die Daten an das falsende Gebäude liefern. Dies ist ein großes Problem, besonders in komplexen Systemen, in denen Daten zwischen vielen verschiedenen Menschen und Computern reisen. Um dies zu beheben, versuchen Wissenschaftler, eine neue Art von „Verkehrskontrollsystem“ zu bauen. Sie wollen diese vagen Klebezettel in eine starre, unbrechbare Anweisung verwandeln, die der Computer-Code befolgen muss, um sicherzustellen, dass Daten niemals für etwas anderes verwendet werden, als ursprünglich versprochen wurde.
Dieses Papier mit dem Titel „Multiparty Session Types for GDPR Purpose Compliance“ ist der Entwurf für den Bau dieses Verkehrskontrollsystems. Die Autoren, ein Team der Universität Zypern, schlagen einen Weg vor, diese „Zweck-Etiketten“ mathematisch zu modellieren, sodass Softwareentwickler beweisen können, noch bevor die Software überhaupt läuft, dass sie niemals gegen die Regeln verstößt. Sie verwenden ein Konzept namens „Multiparty Session Types“, was einer choreografierten Tanzroutine für Computer gleicht. In diesem Tanz weiß jeder Teilnehmer (wie ein Patient, eine Pflegekraft oder ein Labor) genau, wann er einen Schritt macht, was er sagt und welche Daten er anfassen darf.
Das Papier führt eine neue Sprache ein, in der „Zwecke“ nicht nur Text sind, sondern strukturierte Interaktionsprotokolle. Stellen Sie sich das wie ein Skript für ein Theaterstück vor, bei dem die Daten eine Requisite sind. Das Skript (der „Global Type“) schreibt vor, dass der „Patient“ eine Requisite an die „Pflegekraft“ übergibt, die sie dann nur dann an das „Labor“ weiterreicht, wenn eine bestimmte Bedingung erfüllt ist. Wenn der „Arzt“ versucht, die Requisite für eine andere Szene (wie Marketing) zu greifen, wird das Skript diese Handlung schlichtweg nicht zulassen. Die Autoren haben ein „Typsystem“ entwickelt – ein strenges Regelwerk –, das prüft, ob eine Software dem Skript folgt. Sie haben mathematisch bewiesen, dass, wenn ein System diese Prüfung besteht, es garantiert beim Skript bleibt. Es kann nicht vom Skript abweichen und es kann auch nicht in einer Endlosschleife stecken bleiben, in der es nicht weiß, was als Nächstes zu tun ist.
Um zu zeigen, wie dies funktioniert, sind die Autoren durch ein realistisches Szenario gegangen: einen medizinischen Diagnose-Workflow. In ihrem Beispiel sendet ein Patient seine Symptome an eine Pflegekraft. Die Pflegekraft überprüft die Daten und entscheidet, ob ein Labortest erforderlich ist. Wenn ja, gehen die Daten an das Labor; wenn nein, gehen sie direkt an einen Arzt. Die Autoren zeigten, dass ihr System in der Lage war, eine Version dieses Workflows, der die Regeln perfekt befolgte, erfolgreich zu verifizieren. Sie zeigten aber auch, dass, wenn sie den Code so manipulierten, dass der Arzt die Laborergebnisse lesen wollte, bevor der Test überhaupt durchgeführt wurde (ein Verstoß gegen den Zweck), das System dies sofort als Fehler meldet und ablehnt.
Das Papier behauptet nicht, alle Datenschutzprobleme der Welt gelöst zu haben, noch sagt es, dass es ein fertiges Produkt ist, das morgen von jedem Softwareunternehmen genutzt werden kann. Stattdessen legt es ein formales Fundament. Es beweist, dass es möglich ist, den „Zweck“ als eine harte, mathematische Einschränkung und nicht als eine weiche Empfehlung zu behandeln. Die Autoren schlagen vor, dass dieser Ansatz schließlich in Standard-Software-Design-Tools integriert werden könnte, wie etwa die Diagramme, die Ingenieure zur Planung von Systemen verwenden, wodurch „Privacy by Design“ (Datenschutz durch Technikgestaltung) zu einer praktischen Realität statt nur zu einem Schlagwort wird. Indem sie vage Absichten in strikte, verifizierbare Protokolle umwandeln, bieten sie einen Weg, um sicherzustellen, dass in der digitalen Stadt Ihre versiegelten Umschläge immer ihr beabsichtigtes Ziel erreichen und niemand sie aus dem falschen Grund öffnet.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.