Wie in unserem letzten Blog-Beitrag schon angekündigt, wollen wir in Part II der Reihe Privacy by Design auf die Umsetzung der Pseudonymisierung im Detail eingehen. Schauen Sie doch selbst!

Das besondere Merkmal der HPI Schul-Cloud

Jeder Schüler hat ein Recht auf seine Daten. Die HPI Schul-Cloud bietet dabei Inhalte von unseren Partnern, wie Cornelsen, Bettermarks oder Serlo an. In diesem Artikel widmen wir uns den technischen Grundlagen des Datenschutzes in der HPI Schul-Cloud, speziell den technischen Grundlagen für die Pseudonymisierung.

Der Cloud-Charakter ist hierbei das Entscheidende: Hier liegt die größte Stärke der HPI Schul-Cloud. Denn klassische Online-Plattformen setzen hohe Anforderungen an die Kompatibilität der Inhalte mit ihrer Plattform. Es müssen also im Falle einer Lern-Plattform spezifische Inhalte für die Plattform entwickelt werden. Google Docs ist beispielsweise nur kompatibel mit den Dokumentformaten, die von Google selbst bereitgestellt werden. Im Gegensatz dazu kann die HPI Schul-Cloud die Inhalte verschiedenster Anbieter zusammenführen. Wir bieten eine Schnittstelle für alle Partner von Lehrinhalten an, die bereit sind, mit uns zu kooperieren. Damit handelt es sich also nicht um eine Cloud im Sinne eines reinen Speichermediums. Der Cloudbegriff wird hier ausgedehnt, um Funktionen der Plattformen unserer Partner einzubinden, zusätzlich zu den Lehrinhalten. Aus diesem Grund hat jeder Schüler bei jedem unserer Partner ein eigenes Pseudonym, um auf die Inhalte problemlos zuzugreifen. Die Daten bleiben geschützt, wie beschrieben in unserem letzten Artikel.

Doch wie funktioniert das nun technisch?

Voraussetzung für die Pseudonymisierung

Im ersten Schritt müssen wir die Anbieter mit den Schülern verknüpfen. Jedes Pärchen aus der Nutzer ID (Identifikationsnummer) und der dazugehörigen Anbieter ID bekommt von uns im System eine eigene Kennzeichnung zugewiesen: Wir benutzen UUID (Universally unique identifier), um die Paare im System der HPI Schul-Cloud und im System der Anbieter zuzuordnen. Die UUID nimmt damit den Platz des Pseudonyms aus unserem ersten Artikel ein. Wenn wir Lerninhalte von einem Anbieter anfragen, dann geben wir dem Anbieter anhand der UUID die Information mit, für welchen Schüler wir diese Inhalte anfragen wollen. Das heißt, dass der Schüler zum Beispiel an seinem letzten Arbeitsblatt sofort weiterarbeiten kann. Zusammenfassend bedeutet das: Jeder Schüler wird innerhalb des Systems eindeutig identifiziert, seine wahre Identität bleibt allerdings verborgen.

Was passiert, wenn die Anbieter Feedback an die Lehrer zurücksenden möchten?

Verallgemeinernd unterteilen wir beim Programmieren zwischen zwei Fällen: Zum einen Anwendungen, die in der Software-Architektur auf dem Computer des Nutzers ablaufen (Frontend oder Clientseitig) und zum anderen allen Anwendungen, die im Hintergrund ablaufen (Backend oder Serverseitig). Im Standardfall interagiert der Client des Frontends mit dem Server der Anbieterplattform. Das besondere besteht bei unserer Form der Pseudonymisierung darin, dass der Client der HPI Schul-Cloud mit dem Backend der Anbieter interagiert, also die Browseranwendung mit dem dahinterstehenden Lerndaten im Besitz der Unternehmen oder Organisationen. Für die Kommunikation zwischen den beiden Systemen gibt es dann zwei Möglichkeiten:

1. Kommunikation über xAPI

Die einfache Variante ist es xAPI (Experience API) zu verwenden. xAPI ist eine Schnittstelle speziell für Lernsysteme. Die Feedbackdaten, die wir von unseren Partnern zurückbekommen, haben dann beispielsweise die Form:

Schüler A hat Aufgabe X mit großen/guten/mäßigen Erfolg bearbeitet.

xAPI ist daher ein Webservice, der es uns erlaubt alle Daten von den Anbietern für die Profile der Schüler in unserem System zurückzuübersetzen. Mit diesen Daten können wir automatisch einen Learning Record Store befüllen, in unserem Falle ist das LearningLocker. Hier werden alle Feedbackstände der Schüler zu den einzelnen Aufgaben zusammengefasst. Und der Lehrer kann die Informationen für jede Aufgabe einsehen und ist über die Fortschritte seiner Schüler informiert.

2. Kommunikation mittels clientseitiger Bibliothek

Die zweite Alternative wäre es eine Java Script-Bibliothek in ein IFrame einzubinden. Das IFrame selbst ist ein Fenster, in das die Nutzer beliebige Inhalte von externen Websites einbinden können, beispielsweise eine Google Maps-Karte oder ein Youtube-Video oder eben ein interaktives Lernspiel. Auch hier müssen wir dem Lehrer die Pseudonyme zurückübersetzen. Dafür benutzen wir eine Clientseitige Bibliothek, die es dem Lehrer ermöglicht, die richtigen Schüler zu finden. Der Lehrer muss sich dann jeweils gegenüber dieser JS-Library identifizieren, bzw. in der HPI Schul-Cloud eingeloggt sein. Eine Clientseitige-Bliblothek ist wie in der Einleitung beschrieben ein Codemodul, das erst im Browser ausgeführt wird. Das wirkt in der Praxis wie der Like-Botton von Facebook, den ihr auf externen Websites benutzen könnt, während ihr auf Facebook eingeloggt seid.*

Soweit zu den Grundlagen und der technischen Umsetzung des Datenschutzes. Bei Fragen zum Projekt könnt ihr Euch natürlich jederzeit an uns wenden unter bp2017m2@hpi.de.

*Warum müssen wir das so kompliziert machen? Cross-Site Scripting verhindert, dass unsere HPI Schul-Cloud Inhalte im IFrame verändern darf. Aus Sicherheitsgründen ist es in Webbrowsern generell verboten, Inhalte eines IFrames zu manipulieren, wenn in diesem IFrame eine andere Domain eingebunden ist. Es ist daher wichtig, dass die Anbieter unsere Bibliothek selbst einbinden.

Bildnachweis Titelbild: HPI/K. Herschelmann

Bildnachweis 2: HPI/O. Puck

Ein sprachlicher Hinweis der Redaktion: Es sind stets Personen männlichen und weiblichen Geschlechts gleichermaßen gemeint; aus Gründen der einfacheren Lesbarkeit wird an dieser Stelle nur die männliche Form verwendet.