<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">Data-Protection-Compliant Learning Analytics for the Use of External Resources in Learning Portals in Schools</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Jan</forename><surname>Renz</surname></persName>
						</author>
						<author>
							<persName><forename type="first">Dominik</forename><surname>Glandorf</surname></persName>
						</author>
						<author>
							<persName><forename type="first">Christoph</forename><surname>Meinel</surname></persName>
						</author>
						<title level="a" type="main">Data-Protection-Compliant Learning Analytics for the Use of External Resources in Learning Portals in Schools</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">B424B8C175FEAC98CE9A1E79CEB22E88</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-25T00:55+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<textClass>
				<keywords>
					<term>Schule</term>
					<term>Learning Analytics</term>
					<term>Datenschutz</term>
					<term>Pseudonymisierung</term>
					<term>xAPI</term>
					<term>OER</term>
				</keywords>
			</textClass>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>Learning Analytics becomes more expressive by combining results of various educational resources. However, the usage of a single resource might generate sensitive personal data. To facilitate the application of a broad range of learning tools with regard to data protection, school clouds are able to pseudonymise user identities. This work examines the impact on both the legal and technology when using educational resources pseudonymised. It reports on experiences with a prototypical implementation created collaborating with resource providers. Finally, it takes a look at the required market conditions for data-minimising and cooperative learning analytics.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Einführung</head><p>Fast jeder deutsche Schüler ist online. <ref type="foot" target="#foot_3">4</ref> Gleichzeitig ist die durchschnittliche Internetanbindung von deutschen Schulen schlechter als die eines durchschnittlichen Privathaushaltes, und das obwohl hier hunderte Nutzer statt nur einiger weniger versorgt werden. <ref type="foot" target="#foot_4">5</ref>Doch diese technisch-infrastrukturellen Rahmenbedingungen stellen nur eine der Ursachen dar, warum die Kluft zwischen digitaler Lebenswirklichkeit und Schulalltag immer breiter wird. Den Schulbuchverlagen ist es bislang genauso wie OER-Produzenten (Open Educational Resources) nicht gelungen, die Digitalisierung der Schulen effizient voranzutreiben.</p><p>Digitalisierung hat den Auftrag domänenspezifische Vorteile und Mehrwerte zu erschließen und zu generieren. Im schulischen Kontext sind dies bspw. einfacher Zugriff, Interaktivität, Binnendifferenzierung und die damit verbundene Möglichkeit zum "Fordern und Fördern". Durch diese Anforderungen ergibt sich der Einsatz von Learning Analytics. Im Markt der digitalen Lerninhalte führt dies dazu, dass die interessanten und zukunftsweisenden Angebote keine digitale Variante von im Wesen analogen Inhalten sind, sondern die Mehrwerte der digitalen Welt tatsächlich ausreizen: Individualisierung, Interaktivität und eine nutzungsspezifische Adaptivität. So erkennen Lerntools durch intelligenten Einsatz von Learning Analytics den Fortschritt des Lernenden und bieten einen auf seine Bedürfnisse zugeschnittenen Lernpfad an. Damit können sie Lehrer im Klassenzimmer durch wertvolle Informationen über die spezifischen Stärken und Schwächen der Lernenden unterstützen. Doch dazu müssen diese interaktiven Lerntools Daten über den Lernenden erfassen und speichern.</p><p>In Folge dessen kommt es zur Verarbeitung von personenbezogenen Daten, sodass zwischen der Schule und jedem Anbieter dieser Lerntools komplexe Auftragsdatenverarbeitungsverträge entstehen und von jedem Lerner und ggf. seinen Erziehungsberechtigten dem Anbieter ein Einverständnis erklärt werden muss. Dies verkompliziert den Einsatz moderner digitaler Lehrmittel ungemein und behindert gleichermaßen beide Seiten, die Nutzer und die Anbieter. Selbst wenn in den jeweiligen Schul-Gesetzen die Nutzung von digitalen Lernplattformen eingeschlossen wäre, so fehlt darin die Datenweitergabe an Dritte, also die Anbieter der Lerntools. Daher müssen Lösungen gefunden werden, die es den Inhalteanbietern ermöglicht, mit ihren Lerntools und Inhalten Schülern ganz individuell fordern und fördern zu können, ohne dazu vor hochkomplizierten Vertragssituationen mit umfangreichen Zustimmungserfordernissen zu stehen. Die aktuell stattfindenden Initiativen zur Errichtung von Cloud-Lösungen für die schulische Nutzung, wie sie in <ref type="bibr" target="#b4">[Me17]</ref> beschrieben werden, bieten die Chance moderne und zukunftsweisende Konzepte zu implementieren.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">Anonyme und interne Learning Analytics</head><p>Im Datenschutz wird zwischen der Anonymität und Pseudonymität eine deutliche Unterscheidung gemacht<ref type="foot" target="#foot_5">6</ref> . Grundsätzlich gilt die Datenschutz-Grundverordnung (DS-GVO) nur für personenbezogene (also nicht-anonyme) Daten, wie in ErwG 26 erläutert wird: Wie von Drachsler und Greller in <ref type="bibr" target="#b0">[DG16]</ref> erläutert ist eine perfekte Anonymisierung schwierig, selbst wenn entsprechende Checklisten und Frameworks verwendet werden. Gerade zum Zeitpunkt der Erfassung der Daten sind diese fast immer auf eine Person zu beziehen. Allein die beim Konsumieren eines Web-Inhaltes eingesetzten Mechanismen (Cookies, Browser-Fingerprints, IP-Adressen) reichen dafür aus. Zwar kann später dafür gesorgt werden, dass dieser Personenbezug entfernt wird, aber bei einem Einsatz im schulischen Kontext soll der Personenbezug oft explizit beibehalten werden, etwa wenn die Learning-Analytics-Daten Grundlage für Unterstützung des Lehrenden sind. Die bei der Auslieferung anfallenden personenbezogenen Daten können alternativ durch ein Hosting der Inhalte und Tools beim Schul-Cloud-Betreiber geschützt werden. Dadurch kann vermieden werden, dass personenbezogene Daten bei den Inhalte-und Tool-Anbietern anfallen. Learning-Analytics-Daten können in diesem Falle direkt innerhalb der Schul-Cloud erfasst und verarbeitet werden. Für Open-Source-Tools und -Inhalte (OER) ist dieser Ansatz durchaus praktikabel. Für kommerzielle Anbieter wie Schulbuchverlage, bei denen die Auslieferungsplattformen Teil des Geschäftsmodells und als solche besonders schützenswert sind, oder auch für innovativere OER-Initiativen, die komplexere Auslieferungsumgebungen benötigen, ist eine solcher Ansatz nicht praktikabel. Demnach wird auch für solche Inhalte eine Lösung nötig, welche im folgenden Kapitel diskutiert wird.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3">Integration von externen Lerntools</head><p>Lerntools müssen zur Entfaltung ihres Potenzials (Adaptivität, Benutzerkomfort) den Nutzer wiedererkennen. Um einen Kompromiss zwischen Anonymität und direktem Personenbezug zu schließen, sollte die Nutzerkennung nur in pseudonymisierter Form an die Anbieter der Inhalte gelangen. Dazu wird ein vertrauenswürdiger Mittler zwischen Nutzer und Anbieter nötig. Eine Schul-Cloud kann diese Rolle einnehmen und die Identität des Nutzers schützen. Für Anbieter, die entweder in ihrem Inhalt oder bei der Rückmeldung von Ergebnissen, Nutzernamen verwenden, entstehen dadurch neue Bedürfnisse, die mit der sicheren Rückübersetzung der Pseudonyme zusammenhängen. Pseudonymisierte Learning-Analytics-Ergebnisse müssen wieder dem richtigen Nutzer zugeordnet werden. Wenn ein Lehrer zum Beispiel innerhalb der Lernsoftware einem Schüler eine Aufgabe zuweisen möchte, ist ihm verborgen, welcher Nutzer sich hinter einem Pseudonym verbirgt.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1">Authentifizierung und Pseudonymisierung</head><p>Beim erstmaligen Abruf des Lerntools wird dem Nutzer das Tool per URL entweder in einem eigenen Fenster oder in einem Iframe angezeigt. In beiden Fällen wird im Browser eine Webseite abgerufen, die in einer anderen Domäne liegt. Deshalb muss sich der Cloud-Nutzer beim Anbieter authentifizieren. Zum einen kann der Nutzer so die personalisierten Inhalte erhalten und zum anderen der Anbieter den Zugriff auf seine Inhalte kontrollieren. In Moment der Authentifizierung entscheidet sich, mit welcher Zeichenfolge der Nutzer referenziert wird.   </p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head></head><label></label><figDesc>[...] Die Grundsätze desDatenschutzes sollten daher nicht für anonyme Informationen gelten, d. h. für Informationen, die sich nicht auf eine identifizierte oder identifizierbare natürliche Person beziehen, oder personenbezogene Daten, die in einer Weise anonymisiert worden sind, dass die betroffene Person nicht oder nicht mehr identifiziert werden kann. Diese Verordnung betrifft somit nicht die Verarbeitung solcher anonymer Daten, auch für statistische oder für Forschungszwecke.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_1"><head>der</head><label></label><figDesc>Abb. 1: Ablauf der Feedback-Auslieferung über die Schul-Cloud</figDesc><graphic coords="7,157.63,268.69,280.10,220.00" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_0"><head>xAPI-basierte Learning Analytics und LernCockpit Die</head><label></label><figDesc>Hierfür eindeutige Zeichenketten wie die E-Mail-Adresse oder die Telefonnummer zu verwenden, würde die Identität des Nutzers offenlegen. Daher wird in diesem Moment eine Pseudoidentität geschaffen. Es wird nach dem UUID-Standard 7 eine zufällige, global eindeutige Zeichenfolge, das Pseudonym generiert und in der Schul-Cloud-Domäne mit dem Nutzer verknüpft. Durch das Pseudonym sinkt die Schutzwürdigkeit der Daten auf Anbieterseite, da diese ohne die Zuordnungstabelle nicht mehr unmittelbar auf reale Personen bezogen werden können. Damit wird erschwert, dass durch den Zusammenschluss von Nutzungsprofilen verschiedener Tools ein umfangreiches Profil eines Nutzers geschaffen wird. Dazu müssten einzelne Nutzer durch eine tiefergehende Analyse in verschiedenen Angeboten identifiziert werden. Es wird durch eine eindeutige Kennung eines Nutzers die ursprüngliche Adaptivität innerhalb des einzelnen Inhalts weiterhin gewährleistet. Im Rahmen der Authentifizierung werden ebenfalls weitere Schnittstellen-Parameter zwischen Schul-Cloud und Anbieter ausgetauscht wie die URL Endpunkten für xAPI oder Rostering. Zur Authentifizierung können unter anderem LTI und OAuth2 genutzt werden. Bei Nutzung von LTI nach [IMS12] wird der einzelne Nutzer mit seinem Pseudonym durch den user_id-Parameter referenziert. Bei Freigabe der OpenID via OAuth2 wird ebenfalls das Pseudonym statt einer realen Identität verwendet. Aufgabe 3) abgespeichert werden. Die Statements sind formal nicht weiter beschränkt. Für die einzelnen Komponenten existieren jedoch Ideen für Schemata. So hat die [XAPI Community] eine kurierte Sammlung von möglichem Vokabular verfasst. Die Statements werden in einem Learning Record Store (LRS) gespeichert, der die xAPI-Spezifikation unterstützt. Dazu eignet sich die Open-Source-Lösung LearningLocker 8 , welche von Haus aus Diagramme für die Analyse der Statements anbietet. Bezüglich des Datenschutzes ist das Abspeichern in einem LRS, der sich in der Schul-Cloud-Domäne befindet, unproblematisch. Beim Einfügen der Daten wird das Pseudo-nym zum echten Nutzer und das gesendete Statement dem Anbieter zugeordnet. Außerdem kann noch eine Zuordnung zum Kurs geschehen, in dem der Inhalt eingesetzt wird. Datenschutzrechtlich wird das Auslesen aus dem LRS komplizierter. Es bietet einen Mehrwert, wenn Anbieter ein interdisziplinäres Profil eines Nutzers erhielten. Dazu müssten sie auf mehr Statements zugreifen als die selbst generierten. Dies ist jedoch widersprüchlich zum angebotsspezifischen Pseudonym, weshalb hier ein Kompromiss eingegangen werden muss. In jedem Fall muss für den Nutzer transparent sein, welche Daten ein Anbieter erhält. Auch allein über den LRS ist eine Tool-Anpassung an den Nutzer möglich. So kann er im Extremfall ganz auf anbieterseitige Speicherung von Nutzungsprofilen verzichten, sofern alle relevanten Nutzungsdaten im LRS gespeichert und nur anhand dieser Daten personalisiert wird. Dies wäre im Sinne der Datensparsamkeit wünschenswert. Konzeptionell enthält der LRS die relevanten Informationen für die Personalisierung. Den allgemeinen Workflow für die De-Pseudonymisierung veranschaulicht Abbildung 1. Der Lehrer erhält dort Feedback sowohl vom Lerntool (3.) als auch von der Schul-Cloud (5.). Das Lerntool-Feedback wird über den Zwischenschritt (4.) erst beim Lehrer de-pseudonymisiert. Das Feedback von der Schul-Cloud wird bereits beim Eintreffen vom Lerntool de-pseudonymisiert und im LRS mit Klarnamen gespeichert. Die Pseudonyme müssen also spätestens bei der Anzeige auf dem Endgerät des Lehrers wieder zurückübersetzt, im Folgenden de-pseudonymisiert, werden. Dies darf aufgrund des Datenschutzes nicht in der Domäne des Anbieters geschehen. Damit bleiben lediglich der Server der Schul-Cloud und der Browser des Lehrers als mögliche Stellen. Die erste Variante entspricht einem Proxy. Die Inhalte werden dabei anstatt vom Anbieter aus der Schul-Cloud abgerufen. Diese stellt die Anfrage an den Anbieter und ersetzt in Datenschutzkonforme Learning Analytics bei externen Materialien in Lernportalen</figDesc><table><row><cell>Datenschutzkonforme Learning Analytics bei externen Materialien in Lernportalen</cell></row><row><cell>Das Pseudonym ist angebotsspezifisch. 3.2 Rostering</cell></row><row><cell>3.3</cell></row><row><cell>7 https://tools.ietf.org/html/rfc4122</cell></row></table><note>Der Begriff Roster beschreibt ursprünglich die Auflistung von Mitgliedern eines Sport-Teams. Im Lerntool-Kontext werden darunter Metadaten über die Rollen und Assoziationen der Nutzer verstanden. Beim Rostering wird übertragen, welcher Lehrer für welchen Schüler zuständig ist oder welcher Klasse ein Schüler angehört. [IMS17] beschreibt mit OneRoster 1.1 einen Standard, der zum Austausch von diesen Informationen zwischen dem Studenten-Informationssystem und dem Lerntool dient. Das Tool sollte die Rostering-Informationen dazu nutzen, dass ein Lehrer nur die Analysen zu seinen eigenen Schülern sehen kann. Rostering funktioniert technisch mit Pseudonymen statt Klarnamen auf dieselbe Weise. Problematisch wird es jedoch, wenn die vermeintlichen Namen im externen Tool anzeigt werden. Damit Nutzernamen im Tool verwendbar sind, muss eine De-Pseudonymisierung stattfinden (siehe Abschnitt 3.4). Experience API (xAPI) ist ein Standard zur Erfassung von Lernprozessen, der in [xAPI13] spezifiziert wurde. An die Schnittstelle können Daten von allen Geräten gesendet werden. Beim Auftreten eines Lernereignisses wie ,,John hat Aufgabe 3 korrekt gelöst'' kann ein Statement der Form Subjekt (John) -Verb (lösen) -Objekt (Das LernCockpit ist die Analyse-Oberfläche für Lehrer. Die Statements im LRS können hier ohne Einschränkungen auf bestimmte Anbieter ausgewertet werden. Ohne bildungswissenschaftlichen Hintergrund kann bereits ein Aktivitätenlog einen Mehrwert für den Lehrer darstellen. So kann er anhand der Aktivität abschätzen, welche Schüler langsamer vorankommen und Hilfe benötigen. Bisher problematisch ist die mangelnde Kompatibilität der xAPI-Daten der verschiedenen Anbieter und die mangelnde Verknüpfung mit Kompetenzen. Dazu sind die einzelnen Inhalte oft sehr umfangreich und an komplette Bücher angelehnt, sodass ein Mapping von Kompetenzen oder ähnlichen Meta-Daten aufwendig ist. Dadurch wird die angebotsübergreifende Auswertung zunächst oberflächlich bleiben. Einen wirklichen Mehrwert bietet es, wenn sich Anbieter auf eine Standardisierung der übertragenden Metadaten, bspw. in Bezug auf Kompetenzen einigen. De-Pseudonymisierung von anbieterspezifischen Learning Analytics Es gibt Anbieter, die dem Lehrer inhaltsspezifische und fortgeschrittene Auswertungen der Lernleistung zur Verfügung stellen. Dies passiert als Teil des Geschäftsmodells innerhalb der Anbieter-Domäne. Aufgrund der Pseudonymisierung sind alle Auswertungen, die sich auf einzelne Nutzer beziehen, für den Lehrer dort aber unbenutzbar. Damit der Lehrer weiter gezielt auf die Stärken und Schwächen einzelner Schüler eingehen kann, muss dieser Bezug wiederhergestellt werden.</note></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_1"><head></head><label></label><figDesc>Iframe Hier wird anstelle des Pseudonyms ein kleines Iframe angezeigt, worin eine spezielle URL der Schul-Cloud abgerufen wird, die das Pseudonym enthält. Da die Iframe-Seite in der Schul-Cloud-Domäne liegt, kann sie die für den eingeloggten Nutzer autorisierten Pseudonyme anzeigen. Aufgrund der same-origin policy kann der Anbieter technisch keine Namen aus dem Iframe lesen<ref type="bibr" target="#b5">[SNM17]</ref>. Die same-origin policy kann von technisch versierten Nutzern aufgeschaltet werden. Dann kann der Anbieter aber nur die Klarnamen im Rechtebereich des aktuellen Nutzers auslesen. Datenklau einer Großzahl von nichts-ahnenden Nutzern ist auf diese Weise schwer möglich. Er kann jedoch auch keinen Einfluss auf die Darstellung nehmen, wodurch das Layouting problematisch wird. Eine Lösung ist, ein anbieterspezifisches CSS einzubinden. SVG Die SVG-Lösung ist ähnlich zur Iframe-Lösung, nur dass SVG-Grafiken problemlos skaliert werden können. Sie sind zudem einfach zu generieren und in ihnen kann grafisch gekennzeichnet werden, dass es sich um einen Inhalt aus der Schul-Cloud handelt (durch ein stempelartiges Symbol).Datenschutzrechtlich besteht dasKonstrukt aus drei Elementen. Das erste Element besteht in der Datenschutzerklärung. Dort ist unter Absatz IV (Weitergabe von Daten an Inhalte-Anbieter) beschrieben, dass und warum beim Einsatz von Drittanbieter-Software Pseudonyme verwendet werden. Außerdem wird auf die Auftragsdatenverarbeitung hingewiesen und die nach DS-GVO bestehenden Rechte für den Nutzer auch bei den Drittanbietern. Darüber hinaus findet sich im Anhang 2, Verzeichnis aller Empfänger der personenbezogenen Daten eine Liste von "Inhalte-Anbieter[n], die aufgrund von Kooperationsverträgen pseudonymisierte nutzungsbezogene Daten erhalten". Dort sind alle Anbieter mit Adresse aufgeführt.Drittens gibt es entsprechende vertragliche Regelungen zwischen den einzelnen Anbietern und der Schul-Cloud. Erwähnenswert ist noch, dass je nach Alter eine Einverständniserklärung der Erziehungsberechtigten, den Erziehungsberechtigten und dem Schüler oder nur dem Schüler abgegeben werden muss. Je nach Bundesland kann es gesetzliche Löschfristen geben. Darüber hinaus sieht auch die DS-GVO in Artikel 17 vor, dass ein Nutzer jederzeit die Löschung seiner personenbezogenen Daten einfordern kann. Dies erfordert, dass auch die bei den Inhalteanbietern abgelegten mit dem Pseudonym verknüpften Daten gelöscht werden müssen. Dafür müssen alle Anbieter ein (vorzugsweise) elektronisch automatisierten Workflow implementieren, der die Löschung durchführt. Einfacher ist es hingegen, lediglich das angebotsspezifische Pseudonym aus der Mapping-Tabelle zu entfernen. Dies muss nur in der Schul-Cloud erfolgen, nicht aber auf Anbieterseite. Dafür muss jedoch ausgeschlossen sein, dass die xAPI-Statements personenbezogene Daten in den Verb-und Objektinformationen enthalten. Dadurch sind die erfassten Daten auf Anbieterseite nicht länger de-Die Vermeidung von personenbezogenen Daten ist insbesondere für anspruchsvolle interaktive Inhalte nicht praktikabel. Eine Wiedererkennung von Nutzern, wie sie auch für personenbezogene Learning Analytics Funktionen notwendig ist, lässt sich mit angebotsspezifischen Pseudonymen realisieren. Rechtlich gesehen, handelt es sich immer noch um personenbezogene Daten, jedoch sind sie anbieterseitig nicht mehr ohne weiteres auf reale Identitäten zu beziehen. Deshalb sinkt das Schutzniveau der Daten, sodass eine indirekte Einverständniserklärung, welche als Teil der Einverständniserklärung mit der einbettenden Plattform abgeschlossen wird, ausreichend sein kann. Während einfache eventbasierte Learning-Analytics-Funktionen angebotsübergreifend auf Basis pseudonymisierter xAPI-Events erfolgen kann, erfordern fortgeschrittene angebotsspezifische Learning Analytics eine Auswertung auf Seite des Anbieters. Diese kann unter Verwendung der Pseudonyme erfolgen, wobei eine De-pseudonymisierung zur Laufzeit im Browser (bspw. des Lehrers) erfolgt und somit bei entsprechender Implementierung (Iframe oder Proxy) ein Zugriff auf die de-pseudonymiserten Daten durch den Anbieter ausgeschlossen werden kann. Problematisch bleiben vom Nutzer erzeugte personenbezogene Daten. Erlaubt bspw. ein Lerninhalt das Anlegen von Kommentaren oder Notizen, kann dies dazu führen, dass diese Daten auch in den dazugehörigen xAPI-Events auftauchen. Sofern nicht schon die Erfassung unterbunden werden kann, sollten diese Daten zumindest in den Learning Analytics Daten gefiltert werden. Parallel zu der Einführung der hier bereits im Prototyp implementieren Ansätze gilt es zudem solche Ansätze weiter zu verfolgen, personenbezogene Inhalte auf Seite des Anbieters vermeiden. So ist denkbar, dass Anbieter Algorithmen oder Laufzeitumgebungen anbieten, die an den in der Schul-Cloud liegenden Learning Record Store angebunden werden. Hierzu bedarf es allerdings eines Paradigmenwechsels bei den Anbietern. Auch Verschlüsselung für vom Nutzer in den Lernlösungen erfasste Daten kann in diesem Zuge angegangen werden. Gemeinsam mit den Inhalteanbietern sollte eine Standardisierung und Erweiterung der zu übermittelnden xAPI-Daten angestrebt werden, wobei bis dato Schulbuchverlage hierzulande nicht durch Kollaboration hervorstechen. Noch sind die vorgestellten Konzepte nicht vollständig in Produktion ausgerollt, auch da die Abstimmung mit den Facharbeitskreisen der Landesdatenschützer und den zuständigen Landesdatenschützern noch nicht abgeschlossen ist. Es wird sich daher zeigen, ob ggf. noch Anpassungen vorzunehmen sind, bevor die geschilderten Lösungen zum flächendeckenden Einsatz kommen können.</figDesc><table><row><cell></cell><cell>Datenschutzkonforme Learning Analytics bei externen Materialien in Lernportalen</cell></row><row><cell cols="2">pseudonymisierbar und fallen dann als anonymisierte Daten nicht mehr unter die DS-</cell></row><row><cell>GVO.</cell><cell></cell></row><row><cell cols="2">5 Zusammenfassung und Ausblick</cell></row><row><cell cols="2">4 Das datenschutzrechtliche Konstrukt</cell></row><row><cell>4.1</cell><cell>Löschung von Daten</cell></row></table></figure>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="1" xml:id="foot_0">Universität Potsdam, Hasso-Plattner-Institut, jan.renz@hpi.de</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="2" xml:id="foot_1">Universität Potsdam, Hasso-Plattner-Institut, dominik.glandorf@student.hpi.de</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="3" xml:id="foot_2">Universität Potsdam, Hasso-Plattner-Institut, christoph.meinel@hpi.de</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="4" xml:id="foot_3">98\%, Quelle: Deutsches Institut für Vertrauen und Sicherheit im Internet., 2014</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="5" xml:id="foot_4">Quelle: Eigene Auswertung in Kooperation mit iServ</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="6" xml:id="foot_5">Fokusgruppe Datenschutz des Digital-Gipfels<ref type="bibr" target="#b1">[Fo17]</ref> </note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="8" xml:id="foot_6">https://learninglocker.net</note>
		</body>
		<back>
			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<analytic>
		<title level="a" type="main">Privacy and Analytics: It&apos;s a DELICATE. Issue a Checklist for Trusted Learning Analytics</title>
		<author>
			<persName><forename type="first">H</forename><surname>Drachsler</surname></persName>
		</author>
		<author>
			<persName><forename type="first">W</forename><surname>Greller</surname></persName>
		</author>
		<idno type="DOI">10.1145/2883851.2883893</idno>
		<ptr target="http://doi.acm.org/10.1145/2883851.2883893" />
	</analytic>
	<monogr>
		<title level="m">Proceedings of the Sixth International Conference on Learning Analytics &amp; Knowledge. LAK &apos;16</title>
				<meeting>the Sixth International Conference on Learning Analytics &amp; Knowledge. LAK &apos;16<address><addrLine>Edinburgh, United Kingdom, S</addrLine></address></meeting>
		<imprint>
			<publisher>ACM</publisher>
			<date type="published" when="2016">89-98. 2016</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<monogr>
		<ptr target="01.06.2018" />
		<title level="m">Schutz und Vertrauen für Gesellschaft und Wirtschaft im Rahmen des Digital-Gipfels 2017</title>
				<imprint>
			<date type="published" when="2017">2017</date>
		</imprint>
	</monogr>
	<note>Whitepaper zur Pseudonymisierung der Fokusgruppe Datenschutz der Plattform Sicherheit</note>
</biblStruct>

<biblStruct xml:id="b2">
	<monogr>
		<ptr target="https://www.imsglobal.org/specs/ltiv1p1/implementation-guide,Stand:19.06.2018" />
		<title level="m">IMS Global Learning Consortium</title>
				<imprint>
			<date type="published" when="2012">2012</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<monogr>
		<ptr target="20.06.2018" />
		<title level="m">IMS Global Learning Consortium</title>
				<imprint>
			<date type="published" when="2017">2017</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<monogr>
		<author>
			<persName><forename type="first">C</forename><surname>Meinel</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Renz</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Grella</surname></persName>
		</author>
		<author>
			<persName><forename type="first">N</forename><surname>Karn</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Hagedorn</surname></persName>
		</author>
		<title level="m">Die Cloud für Schulen in Deutschland: Konzept und Pilotierung der Schul-Cloud</title>
				<meeting><address><addrLine>Potsdam</addrLine></address></meeting>
		<imprint>
			<publisher>Universitätsverlag</publisher>
			<date type="published" when="2017">2017</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b5">
	<analytic>
		<title level="a" type="main">Same-Origin Policy: Evaluation in Modern Browsers</title>
		<author>
			<persName><forename type="first">J</forename><surname>Schwenk</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Niemietz</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Mainka</surname></persName>
		</author>
		<ptr target="https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/schwenk" />
	</analytic>
	<monogr>
		<title level="m">26th USENIX Security Symposium (USENIX Security 17)</title>
				<meeting><address><addrLine>Vancouver, BC, S</addrLine></address></meeting>
		<imprint>
			<publisher>USENIX Association</publisher>
			<date type="published" when="2017">2017</date>
			<biblScope unit="page" from="713" to="727" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<monogr>
		<ptr target="Stand:20.06.2018" />
		<title level="m">XAPI Community</title>
				<imprint/>
	</monogr>
	<note>XAPI Community</note>
</biblStruct>

<biblStruct xml:id="b7">
	<monogr>
		<ptr target="20.06.2018" />
		<title level="m">Experience API Working Group</title>
				<imprint>
			<date type="published" when="2013">2013</date>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
