Hallo,
eine gesonderte Verwaltung von Nutzern in Gruppen ist in größeren Sytemen (ab einigen hundert Nutzern)sinnvoll und notwendig. Diese Organisationen haben in allerRegel eine Nutzerverwaltung über eine Datenbank im PC. Darin werden auch Gruppen verwaltet (z.B. Klassen, Kurse, etc.). Jeder Versuch einer doppelten Datenhaltung ist a) unwirtschaftlich und b) fehlerbehaftet.
Aus diesem Grund hat moodle eine extrem ausgeprägte Anbindung an unterschiedlichste externe Datenbanken und Authentifizierungssysteme.
Mit einer der nächsten Versionen wird es die Option geben, dass ein moodle-System Authentifizierungen bei unterschiedlichen/mehreren Systemen abfragen kann. Damit ist auch der schulübergreifende Einsatz, den Maik ansprach, möglich.
Gruß
Ralf Hilgenstock
Hallo Ralf,
Doppelte Datenhaltung ist ineffizient. Zentralistische Datenhaltung birgt immer immense Gefahren im Hinblick auf den Datenschutz (vgl. Kreditkartenaffäre letztes Jahr) und sollte daher stets mit einer Aufklärung der Nutzer und einer Darlegung des zugrundeliegenden Sicherheitskonzeptes einhergehen. An Schulen sehe ich diese Kompetenz noch lange nicht - im Gegenteil: Der ausgeprägte "Schnüffelmodus" von Moodle weckt eher Begehrlichkeiten der Schulbehörden. Eine Schulleitung sieht sowas nicht.
Gruß,
Maik
Gruß,
Maik
In reply to Maik Riecken
Datenhaltung und Datenschutz; war: Gruppen anlegen außerhalb der Kurse möglich
by Ralf Hilgenstock -
Hallo Maik,
jetzt lass mal die Kirche im Dorf. Da gehen mir nun einige Dinge zu sehr durcheinander.
Zunächst einmal reden wir über die Speicherung von Namen, Adressen und Zuordnung zu Klassen und Fächern innerhalb einer Schule. Das ist dezentrale Datenhaltung. Zentral wäre, wenn das Kultusministerium diese Daten exklusiv für alle Schulen des Landes speichern und verwalten würde.
Die Speicherung der Schulleistungsdaten (Noten) ist nun etwas anders. Hierbei handelt es sich um sensible Daten. Die Schüler hinterlassen bei der Schule keine Kreditkarteninformationen.
Zunächst geht es nun darum, dass die Zuordnung des Schülers Klaus M. Klasse 8c, zum Aufbaukurs Englisch bei Lehrer Maik R. nicht an zwei Stellen erfolgen muß, da dies zu Fehlern führt. (Aktualisierung erfolgt an einer Stelle, aber an der anderen Stelle nicht. etc.)
Damit diese Form der Gruppenzuordnung von moodle genutzt werden sollten auch aus Datenschutzgründen nur die erforderlichen Daten an einen Authentifizierungsserver übergeben werden. Die wirklich sensiblen Daten der Schule (Noten) werden somit nicht an ein Online-System übergeben.
Damit kann auch der Kreis der zugriffsberechtigten Personen eingeschränkt werden. Ein wichtiges Kriterium für den Datenschutz.
Die Bildung und Zuordnung zu Gruppen und damit Kursräumen erfolgt damit über das Schulverwaltungssystem. Dies sichert auch ab, dass es ein und nicht mehrere Ordnungs-/Organisationssysteme gibt.
Eine gänzlich andere Frage ist das Entstehen von Leistungs- und Nutzungsdaten innerhalb von moodle. Mit Verlaub: den Begriff "Schnüffelmodus" halte ich für falsch und zudem für gefährlich. Er führt in die falsche Richtung.
Wenn ich den Gedanken weiterführe komme ich zu anonymen Postings in Diskussionen und später zur Frage, wie ich denn eine rassistische oder neonazistische anonyme Äußerung verfolgen kann. Gerade die neue Rechtssprechung (Fall Heise) über Haftung des Betreibers zu Postings, die ihm nicht bekannt sind, zeigt noch einmal dass dieser Weg nicht möglich ist.
Hier treffen im Moment verschiedene Anforderungen aufeinander:
- Datenschutz
- pädagogische Beobachtung des Lernverhaltens und Unterstützung
- Absicherung des Betreibers in strafrechtlicher Hinsicht
- Anforderungen des Tekekommunikationsrechts.
Diese sind nicht aufeinander abgestimmt und nicht gegeneinander gewichtet. Zu unterscheiden sind hier zudem noch, dass zwischen öffentlichen Diskussionsforen/Chats und geschlossenen Kursräumen, die von einer Schule betrieben werden, Unterschiede zu treffen sind.
Mein Standardbeispiel lautet: Wenn in einer Schulklasse ein Schüler einen Diskussionsbeitrag gemacht hat, haben dies 30 andere Personen gehört und sich gemerkt. Dies kann er anschließend nicht ungeschehen machen. Auch die Noten der Klassenarbeiten stehen im Klassenbuch, das für alle einsehbar ist.
Es gibt zwei Punkte, die Du herausgestellt hast und die ich ganz entschieden unterstütze "Aufklärung der Nutzer und Darlegung des zugrundeliegenden Sicherheitskonzeptes". Dies hat einen Effekt, der über die Nutzung der Lernplattform hinausgeht. Es handelt sich hier um einen Informations- und Aufklärungseeffekt, der für das individuelle Handeln in Netzen (z.B. Nutzung von google-Diensten auf dem heimischen PC) und der Welt (z.B. Datenhaltung im Versandhandel, etc.) insgesamt von Bedeutung ist.
Dies sollte Lehrinhalt der Schulen sein. Ja, wenn es denn die Lehrer selber wüßten.
In Bezug auf moodle heißt das:
- Einbindung einer Aufklärung vor dem ersten Login mit Informationen zur Datenerhebung, zum Einblick in Daten durch Lehrer, zur Speicherung, Löschung und Nicht-Weitergabe von Daten.
- Information zur Sicherheit und zum Schutz von Passwörtern.
- Verfahren zur erzwungenen Aktualisierung von Passwörtern.
Dies ist in moodle möglich, wird jedoch selten gemacht. Das liegt aber nicht an moodle, sondern an den Betreibern und deren Sensibilität.
Wie frühere Diskussionen hier zeigen ist das Feld E-Learning und Datenschutz ein weitgehend unbearbeitetes Feld. Ich habe selber in den letzten Wochen hierzu noch einmal recherchiert und überall nur ratlose Gesichter und Leerstellen gefunden. Es gibt gute Darstellungen zu Fragen von Urheberrechten und E-Learning, aber nahezu nichts zum Thema Datenschutz.
Gehen wir das Ganze pragmatisch an. Was sollte getan werden?
Gruß Ralf Hilgenstock
jetzt lass mal die Kirche im Dorf. Da gehen mir nun einige Dinge zu sehr durcheinander.
Zunächst einmal reden wir über die Speicherung von Namen, Adressen und Zuordnung zu Klassen und Fächern innerhalb einer Schule. Das ist dezentrale Datenhaltung. Zentral wäre, wenn das Kultusministerium diese Daten exklusiv für alle Schulen des Landes speichern und verwalten würde.
Die Speicherung der Schulleistungsdaten (Noten) ist nun etwas anders. Hierbei handelt es sich um sensible Daten. Die Schüler hinterlassen bei der Schule keine Kreditkarteninformationen.
Zunächst geht es nun darum, dass die Zuordnung des Schülers Klaus M. Klasse 8c, zum Aufbaukurs Englisch bei Lehrer Maik R. nicht an zwei Stellen erfolgen muß, da dies zu Fehlern führt. (Aktualisierung erfolgt an einer Stelle, aber an der anderen Stelle nicht. etc.)
Damit diese Form der Gruppenzuordnung von moodle genutzt werden sollten auch aus Datenschutzgründen nur die erforderlichen Daten an einen Authentifizierungsserver übergeben werden. Die wirklich sensiblen Daten der Schule (Noten) werden somit nicht an ein Online-System übergeben.
Damit kann auch der Kreis der zugriffsberechtigten Personen eingeschränkt werden. Ein wichtiges Kriterium für den Datenschutz.
Die Bildung und Zuordnung zu Gruppen und damit Kursräumen erfolgt damit über das Schulverwaltungssystem. Dies sichert auch ab, dass es ein und nicht mehrere Ordnungs-/Organisationssysteme gibt.
Eine gänzlich andere Frage ist das Entstehen von Leistungs- und Nutzungsdaten innerhalb von moodle. Mit Verlaub: den Begriff "Schnüffelmodus" halte ich für falsch und zudem für gefährlich. Er führt in die falsche Richtung.
Wenn ich den Gedanken weiterführe komme ich zu anonymen Postings in Diskussionen und später zur Frage, wie ich denn eine rassistische oder neonazistische anonyme Äußerung verfolgen kann. Gerade die neue Rechtssprechung (Fall Heise) über Haftung des Betreibers zu Postings, die ihm nicht bekannt sind, zeigt noch einmal dass dieser Weg nicht möglich ist.
Hier treffen im Moment verschiedene Anforderungen aufeinander:
- Datenschutz
- pädagogische Beobachtung des Lernverhaltens und Unterstützung
- Absicherung des Betreibers in strafrechtlicher Hinsicht
- Anforderungen des Tekekommunikationsrechts.
Diese sind nicht aufeinander abgestimmt und nicht gegeneinander gewichtet. Zu unterscheiden sind hier zudem noch, dass zwischen öffentlichen Diskussionsforen/Chats und geschlossenen Kursräumen, die von einer Schule betrieben werden, Unterschiede zu treffen sind.
Mein Standardbeispiel lautet: Wenn in einer Schulklasse ein Schüler einen Diskussionsbeitrag gemacht hat, haben dies 30 andere Personen gehört und sich gemerkt. Dies kann er anschließend nicht ungeschehen machen. Auch die Noten der Klassenarbeiten stehen im Klassenbuch, das für alle einsehbar ist.
Es gibt zwei Punkte, die Du herausgestellt hast und die ich ganz entschieden unterstütze "Aufklärung der Nutzer und Darlegung des zugrundeliegenden Sicherheitskonzeptes". Dies hat einen Effekt, der über die Nutzung der Lernplattform hinausgeht. Es handelt sich hier um einen Informations- und Aufklärungseeffekt, der für das individuelle Handeln in Netzen (z.B. Nutzung von google-Diensten auf dem heimischen PC) und der Welt (z.B. Datenhaltung im Versandhandel, etc.) insgesamt von Bedeutung ist.
Dies sollte Lehrinhalt der Schulen sein. Ja, wenn es denn die Lehrer selber wüßten.
In Bezug auf moodle heißt das:
- Einbindung einer Aufklärung vor dem ersten Login mit Informationen zur Datenerhebung, zum Einblick in Daten durch Lehrer, zur Speicherung, Löschung und Nicht-Weitergabe von Daten.
- Information zur Sicherheit und zum Schutz von Passwörtern.
- Verfahren zur erzwungenen Aktualisierung von Passwörtern.
Dies ist in moodle möglich, wird jedoch selten gemacht. Das liegt aber nicht an moodle, sondern an den Betreibern und deren Sensibilität.
Wie frühere Diskussionen hier zeigen ist das Feld E-Learning und Datenschutz ein weitgehend unbearbeitetes Feld. Ich habe selber in den letzten Wochen hierzu noch einmal recherchiert und überall nur ratlose Gesichter und Leerstellen gefunden. Es gibt gute Darstellungen zu Fragen von Urheberrechten und E-Learning, aber nahezu nichts zum Thema Datenschutz.
Gehen wir das Ganze pragmatisch an. Was sollte getan werden?
- Einbindung der Zustimmung zu einer Privacy-Erklärung in jedes System.
- Aufklärung der Dozenten
- Einstellung zur Speicherung von Statistiken bewusst verkürzen.
- Aufklärung der Teilnehmer/innen zum Umgang mit Passwörtern.
- Einstellung der erzwungenen Aktualisierung von Passwörtern.
- Sicherung und Löschung von Kursen nach Beendingung.
- Und bewusst zuletzt: Technische Sicherung des Verzeichnisschutzes
Gruß Ralf Hilgenstock
In reply to Ralf Hilgenstock
Re: Datenhaltung und Datenschutz; war: Gruppen anlegen außerhalb der Kurse möglich
by Dag Klimas -
Hallo Ralf,
das mit dem Datenschutz ist für fast alle Anbieter von Online-Inhalten (z.B. einfache Web-Site) bereits heute ein Problem.
Zum einen sind es die verschiedenen Gesetze die es zu beachten gilt
Zitat unter Datenschutzerklärung des Berliner Datenschützers:
Und noch eins: Wer als Lehrer/in ein "Schulnotenprogramm" zur Ermittlung von Zeugnisnoten einsetzt, speichert und verarbeitet auch personengebundene Daten. Dies gilt nach meiner Auslegung nicht Zeugnistexte/-noten (sofern nur Text und keine Auswertung ).
Dies waren die gesetzlichen Rahmenbedingungen - Datenschutz bedeutet aber auch technischer Schutz von Daten, egal ob persönlich oder Dokumente (Dateien).
In diesem Sinne liegt eine große Aufgabe vor uns. Die öffentlichen Bereiche unterliegen dabei anderen Merkmalen, als wir privaten Anbieter.
Und so etwas an einem Montag ... und so kurz vor Weihnachten ...
mfg
Dag
das mit dem Datenschutz ist für fast alle Anbieter von Online-Inhalten (z.B. einfache Web-Site) bereits heute ein Problem.
Zum einen sind es die verschiedenen Gesetze die es zu beachten gilt
- Teledienstegesetz (z.B. als Grundlage für das nächste) TDG
- Gesetz über den Datenschutz bei Telediensten TDDSG
- Bundesdatenschutzgesetz BDSG
- verschiedene Landesdatenschutzgesetze (z. B. für Berlin)
Zitat unter Datenschutzerklärung des Berliner Datenschützers:
"Speicherung von Zugriffsdaten
Bei jeder Anforderung einer Datei aus dem Angebot des Berliner Beauftragten für Datenschutz und Informationsfreiheit werden Zugriffsdaten gespeichert. Jeder Datensatz besteht aus:
- der Seite, von der aus die Datei angefordert wurde
- dem Namen der Datei
- dem Datum und Uhrzeit der Anforderung
- der übertragene Datenmenge
- dem Zugriffsstatus (Datei übertragen, Datei nicht gefunden etc.)
- einer Beschreibung des Typs des verwendeten Webbrowsers
Und noch eins: Wer als Lehrer/in ein "Schulnotenprogramm" zur Ermittlung von Zeugnisnoten einsetzt, speichert und verarbeitet auch personengebundene Daten. Dies gilt nach meiner Auslegung nicht Zeugnistexte/-noten (sofern nur Text und keine Auswertung ).
Dies waren die gesetzlichen Rahmenbedingungen - Datenschutz bedeutet aber auch technischer Schutz von Daten, egal ob persönlich oder Dokumente (Dateien).
In diesem Sinne liegt eine große Aufgabe vor uns. Die öffentlichen Bereiche unterliegen dabei anderen Merkmalen, als wir privaten Anbieter.
Und so etwas an einem Montag ... und so kurz vor Weihnachten ...
mfg
Dag
In reply to Dag Klimas
Re: Datenhaltung und Datenschutz; war: Gruppen anlegen außerhalb der Kurse möglich
by Ralf Hilgenstock -
Hallo Dag,
die Handhabung des Berliner Datenschutzbeauftragten für Informationen und Downloaddateien auf seiner Webseite ist sehr vorbildlich. Das kann so aber nicht mehr gelten wenn die Seite zu Kommunikations- und Lernzwecken genutzt wird. Hier ist eine Identifizierung und Speicherung zwingend erforderlich. Anonyme Tests oder anonyme Diskussionen nützen in unserem Kontext gar nichts. Anonyme Forenbeiträge sind für jeden Betreiber nach TDG sogar ein unkalkulierbares Risiko.
Nutzerprofile erstellen/auswerten: Jede Diskussion, auch unsere hier ist auswertbar. Z.B. Zahl der Rechtschreibfehler, Zahl der Diskussionsbeiträge, Inhaltsanalyse, Worthäufigkeiten, etc. Dafür gibt es sozialwissenschaftliche Auswertungsprogramme. Dies liegt in der Natur der Sache.
Wir sollten uns m.E. konzentrieren auf:
Ralf
die Handhabung des Berliner Datenschutzbeauftragten für Informationen und Downloaddateien auf seiner Webseite ist sehr vorbildlich. Das kann so aber nicht mehr gelten wenn die Seite zu Kommunikations- und Lernzwecken genutzt wird. Hier ist eine Identifizierung und Speicherung zwingend erforderlich. Anonyme Tests oder anonyme Diskussionen nützen in unserem Kontext gar nichts. Anonyme Forenbeiträge sind für jeden Betreiber nach TDG sogar ein unkalkulierbares Risiko.
Nutzerprofile erstellen/auswerten: Jede Diskussion, auch unsere hier ist auswertbar. Z.B. Zahl der Rechtschreibfehler, Zahl der Diskussionsbeiträge, Inhaltsanalyse, Worthäufigkeiten, etc. Dafür gibt es sozialwissenschaftliche Auswertungsprogramme. Dies liegt in der Natur der Sache.
Wir sollten uns m.E. konzentrieren auf:
- Welche rechtlichen, institutionellen Anforderungen gibt es?
- Welche pädagogischen Notwendigkeiten gibt es?
- Welche technischen Lösungen sollen voran getrieben werden?
Ralf
In reply to Ralf Hilgenstock
Re: Datenhaltung und Datenschutz; war: Gruppen anlegen außerhalb der Kurse möglich
by Maik Riecken -
Hallo Ralf,
Ich gehe einmal davon aus, dass die Schule bzw. die Unversität der Arbeitsplatz eines Schülers bzw. Studenten ist. An welchem Arbeitsplatz würde die Speicherung jedes Mausklicks geduldet, wenn diese nicht vorher vertraglich vereinbart worden ist?
Ich möchte einfach darauf hinwirken, dass das Logging bei Moodle standardmäßig komplett deaktiviert werden kann. Du hast den Draht zu Martin...
Nicht davon betroffen wären z.B. die Tests, da diese Daten pädagogisch wert- und sinnvoll sind. Das Testmodul verwaltet zudem seine Daten in einer eigenen Tabelle. Es wäre also schlichtweg schön und zudem ein Riesenschritt, wenn ich das Logging auf 0 Tage setzen *könnte* - der Programmieraufwand dafür wird sich auch in engen Grenzen halten. Bei einem Forenbeitrag steht sowieso immer bei, wer das nun war...
Und: Andere, auch kommerzielle Lösungen laufen auf die gleiche Problematik zu. Es wäre ein weitere großer Trumpf, wenn Moodle als erstes LMS die Abschaltung des Loggings erlaubte.
Gruß,
Maik
In reply to Maik Riecken
Re: Datenhaltung und Datenschutz; war: Gruppen anlegen außerhalb der Kurse möglich
by Dag Klimas -
Danke Maik!
Dieser Vorschlag wäre sicherlich schon einmal ein richtiger Einstieg. Jeder Betreiber könnte so selber entscheiden wieviel er loggt.
Aber auch Profildaten wie "letzter Zugriff" sollten damit deaktiviert werden können.
Viele Grüße
Dag
Dieser Vorschlag wäre sicherlich schon einmal ein richtiger Einstieg. Jeder Betreiber könnte so selber entscheiden wieviel er loggt.
Aber auch Profildaten wie "letzter Zugriff" sollten damit deaktiviert werden können.
Viele Grüße
Dag
In reply to Maik Riecken
Re: Datenhaltung und Datenschutz; war: Gruppen anlegen außerhalb der Kurse möglich
by Ralf Hilgenstock -
Hallo Maik,
Andre hat schon ein paar mal den Anlauf gemacht um die Anforderungen zu systematisieren.
Wir sollten hier zunächst einmal klar stellen, was erforderlich ist und das sauber spezifizieren. Es geht dabei nicht um die Eröffnung der großen Wunschliste (auch wenn bald Weihnachten ist).
An einer offiziellen Abstimmung mit Datenschutzfachleuten wäre mir dann gelegen.
Danach müssen wir klären, welchen Aufwand das bedeutet und was es kostet. Und wir müssen das Geld dafür auftreiben.
Ralf
Andre hat schon ein paar mal den Anlauf gemacht um die Anforderungen zu systematisieren.
Wir sollten hier zunächst einmal klar stellen, was erforderlich ist und das sauber spezifizieren. Es geht dabei nicht um die Eröffnung der großen Wunschliste (auch wenn bald Weihnachten ist).
An einer offiziellen Abstimmung mit Datenschutzfachleuten wäre mir dann gelegen.
Danach müssen wir klären, welchen Aufwand das bedeutet und was es kostet. Und wir müssen das Geld dafür auftreiben.
Ralf
In reply to Ralf Hilgenstock
Re: Datenhaltung und Datenschutz; war: Gruppen anlegen außerhalb der Kurse möglich
by Maik Riecken -
Hallo Ralf,
Ich habe nochmal lange nachgedacht. Zunächst zum Argument mit der rechtlichen Absicherung des Forenbetreibers bei nicht gesetzeskonformen Beiträgen:
Grundgedanke im Datenschutz ist immer die Vermeidung der Speicherung unnötiger Daten. Um z.B. einen Forenpost einem Benutzer zuordnen zu können, brauche ich folgende Angaben:
- Den Benutzernamen, den ich selbst durch geeignete Maßnahmen verifiziert habe
- nichts weiter, wenn ich meinen Job bei 1. gemacht habe
Gespeichert wird aber *weit* mehr. Auf dezidierten Systemen reicht dann ein Apachelog völlig aus.
Ich fange jetzt einmal nicht davon an, dass es unzählige Möglichkeiten gibt, meine Identität geheimzuhalten - auch die Vorratsdatenspeicherung der Provider nützt rein gar nichts, wenn ich über einen freien Proxy in Kasachstan surfe. Hier bin ich also als Moodlebetreiber gefordert, meine Nutzer geeignet zu verifizieren.
Jetzt nochmal zum Thema externe Authentifizierungsmethoden. Sie schaffen Bequemlichkeit, Fehlerfreiheit und in meinen Augen auch Unmündigkeit, weil ich damit implizit sage: Ein Nutzer ist zu doof, sich selbstständig innerhalb eines Moodlessytems zu bewegen. Eine Karte für alles. Wenn die Karte weg ist...
Was habe ich als Trainer denn für einen Stress, wenn ich die Nutzer entsprechend einweise? Die Realität sieht vielleicht so aus, dass sich die meisten Benutzer nicht einmal drei Passworte merken können - und wir weichen dann zurück und sagen dann: Brauchst du auch nicht, lieber Nutzer. Ist für mich auch viel einfacher, wenn ich das für dich mache. Deshalb nehme ich es ihm ab, dass er sich noch ein Passwort merkt, indem ich ihn an einem Generalschlüsselkonzept teilhaben lasse. Gleichzeitig habe ich keinen Stress damit. Aber ich wundere mich täglich, warum meine Schüler für Rechnungen im Zahlenraum bis Hundert (ganzzahlig) den Taschenrechner zücken oder zum Flicken ihres Fahrrades in die Werkstadt fahren.
Ok, es mag für Szenarien reizvoll sein, in dem mehrere Gruppen einen Kurs nutzen sollen. Aber dafür reichen die Moodlefunktionen zur Nutzerverwaltung bis jetzt selbst doch nicht mal im Ansatz aus. Ohne Krücken wird das mit Moodles archaischer Nutzerverwaltung eh nix. Arktur ist nicht umsonst so weit verbreitet, weil er das sehr gut kann.
Für mich als Systemverwalter ist das auch unglaublich reizvoll, unsere Leute über den Arktur zu authentifizieren, dessen Datenbestand zentral gepflegt wird. Aber so lange zwei von unseren 100 Kollegen damit arbeiten, ist das in meinen Augen verzichtbar.
Ganz nebenbei schaffe ich technisch eine Schnittstelle für zentralistische Ansätze und ein weiteres System, welches ich genauestens absichern muss.
Der Reiz an Moodle ist für mich sein freiheitlich-humanistischer Ansatz: Wenn jemand mit Moodle lernen will, dann *darf* er oder sie das tun. Ich zwinge keinen Schüler, meine Kurse zum z.B. Thema Facharbeit zu besuchen - die Themen rücke ich auch so heraus - aber sie selbst sehen einen Sinn darin, schon im Vorwege über das Forum jederzeit Fragen stellen zu können. Ich glaube daran, dass sie in der Lage sind, sich in einen Kurs ein- und auch wieder auszuschreiben. Und wenn sie das nicht können, glaube ich an mich, dass ich es ihnen beibringen kann, weil ich damit viel mehr beibringe als mit anderen Inhalten. Schlimmstenfalls exportiere ich den Kurs ohne Nutzerdaten und setze ihn dann für die nächste Gruppe ein.
Bis die z.B. Testfunktion soweit ist, dass ich sie als Lehrer in meine Bewertung einbeziehen darf, muss viel getan werden - Informatikunterricht außerhalb von Pascal, Java, Delphi, MS-Office und - ganz modern - "HTML" (aber ohne CSS bitte) wäre ein Anfang.
Ich persönlich habe Angst, dass Moodle zunehmend für Evaluationszwecke missbraucht und verkauft wird. Dann geht es mit als ergänzende Begleitung meines klassischen Unterrichts nämlich bald verloren.
Klar wird Blackboard bald mit einer Anbindung an M$-OpenDirectory aufwarten. Die Frage ist, ob das das entscheidende Kriterium für den Einsatz sein wird, denn die Lehrer müssen von dem System begeistert sein.
Meine Ansichten sind auch nicht realistisch. Wenn ich Moodle verkaufen will, brauche ich diesen externen Dingsbums (und auch ich weise darauf hin). Aber ich darf in zehn Jahren dann auch nicht jammern, wenn mir u.U. klar wird, dass ich neben der Bequemlichkeit und dem Komfort für mich noch weitere Dinge eingekauft habe. Alle jammern über teure Werkstätten, die einen übers Ohr hauen, verstehen aber nichts von Autos und wollen auch nichts davon verstehen, weil das ja gehen muss - Bequemlichkeit gibt es nie zum Nulltarif.
Maik
In reply to Maik Riecken
Re: Datenhaltung und Datenschutz; war: Gruppen anlegen außerhalb der Kurse möglich
by Ralf Hilgenstock -
Hallo Maik,
Du machst bestimmte Annahmen. Viele institutionelle moodle-Nutzer treffen andere Vorgaben oder haben andere Einschätzungen.
Es ist dabei gut, dass moodle mehrere Optionen hat.
Gruß
Ralf Hilgenstock
Du machst bestimmte Annahmen. Viele institutionelle moodle-Nutzer treffen andere Vorgaben oder haben andere Einschätzungen.
Es ist dabei gut, dass moodle mehrere Optionen hat.
Gruß
Ralf Hilgenstock
In reply to Maik Riecken
Re: "Deaktivieren" der Statistikfunktionen" ehemals Gruppen anlegen ...
by Christian Glameyer -
Hallo an alle, die sich, zu Recht, Gedanken um die
Datenschutzrechtlichen Bedingungen von moodle machen. Ich empfinde es durchaus gerechtfertigt, von einem Schnüffelmodus zu sprechen, insbesondere dann,w enn der Nutzer nicht weiss, was da über ihn zusammengetragen werden kann ... und gerade die Statistiken sind, anders als in anderen Systemen, ja von jedem Trainer, nicht nur vom Administrator, einsehbar. Hier eine kleine
Lösungen rund um das Thema Statistiken und Logfiles von moodle:
Wer die Log-Funktionen und damit auch die Statistikfunktionen von Moodle deaktivieren will, kann dies auf technisch recht einfachem Wege tun, indem er die Variable des Löschungszeitraums an geeigneter Stelle im Quellcode auf "fast 0" setzt. (Beschreibung siehe unten)
Der Effekt: Die Log-Einträge werden alle 60 Sekunden gelöscht. So können keine brauchbaren Statistiken mehr entstehen.
Der Vorteil: Sie können schon jetzt einen wichtigen Grund für eine Ablehnung einer Zustimmung zur Nutzung von moodle aufgrund Datenschutzrechtlicher Bedenken entkräften, bevor eine neue Version das Deaktivieren dieser Funktionen endlich auch über einen einfachen Mausklick bietet.
Das Last-Login ist hier nicht betroffen. Allerdings die Übersich der neuesten Aktivitäten insofern Sie keine Arbeitsergebnisse in Form von Forenbeiträgen oder Aufgabeneinsendungen betreffen.
HowTo:
Im Moodle-Hauptverzeichnis gibt es unter /admin die Datei cron.php. Hier werden mehrere Dienste zusammengefasst, die regelmässig ausgeführt werden. Hierunter fällt auch das Löschen der Logs aus denen die Statistiken aufgebaut werden.
Moodle lässt von Haus aus die Reduzierung der Lebensdauer dieser Daten nur auf minimal 30 Tage zu .... aber man kann hier den Wert auf wenige Sekunden reduzieren. Alsdann packt man dann die Funktion in den oberen Bereich der Datei, indem die Funktionen sich befinden, die bei jedem Aufruf der cron.php ausgeführt werden.
Entscheidend ist weiterhin aber noch, wie man den CRONJOB konfiguriert hat. Hier sollte man dann entsprechend einen niedrigen Wert der wiederholten Ausführung (beispielsweise 1 oder 2 Minuten) wählen.
Schritte:
/// Delete old logs to save space (this might need a timer to slow it down...)
if (!empty($CFG->loglifetime)) { // value in days
$loglifetime = $timenow - ($CFG->loglifetime * 3600 * 24);
delete_records_select("log", "time < '$loglifetime'");
}
flush();
Glücklicherweise wird die eigentliche Variable erst noch in Tage umgewandelt. Daher bringt das Löschen der Multiplikatoren den gewünschten Effekt, ohne dass Sie mehr davon verstehen brauchen
/// Delete old logs to save space (this might need a timer to slow it down...)
if (!empty($CFG->loglifetime)) { // value in days
$loglifetime = $timenow - ($CFG->loglifetime);
delete_records_select("log", "time < '$loglifetime'");
}
flush();
Setzen Sie nun die Komplette Funktion direkt über den folgenden Eintrag der cron.php. Dies stellt sicher, dass der Löschvorgang nicht nur sporadisch, sondern bei jedem Aufruf der cron.php durchgeführt wird.:
/// Delete old logs to save space (this might need a timer to slow it down...)
if (!empty($CFG->loglifetime)) { // value in days
$loglifetime = $timenow - ($CFG->loglifetime);
delete_records_select("log", "time < '$loglifetime'");
}
flush();
/// Run all core cron jobs, but not every time since they aren't too important.
/// These don't have a timer to reduce load, so we'll use a random number
/// to randomly choose the percentage of times we should run these jobs.
Als nächstes sollten Sie überprüfen, in welchen Abständen cron die cron.php aufruft. Rufen Sie dafür unter Linux crontab -e auf. Die Tabelle sollte den folgenden Eintrag enthalten:
*/1 * * * * lynx -dump http://www.Ihr-Server.de/admin/cron.php > /dev/null
oder auch:
* * * * * lynx -dump http://www.Ihr-Server.de/admin/cron.php > /dev/null
Dies bewirkt, dass cron die Datei cron.php einmal pro Minute ausführt.
Ändern Sie ggf. die Einträge. Hinweise hierfür bietet die Installationsanleitung von moodle. (Es ist der gleiche Prozess, der auch das Versenden der E-Mails anstösst).
Ich hoffe, der ein oder andere kann sich gerade im öffentlich/rechtlichen Bereich so dafür entscheiden, auf den gläsernen Studenten bzw. Schüler zu verzichten, wenn dies die Situation erfordert ! ! !
Wer die Log-Funktionen und damit auch die Statistikfunktionen von Moodle deaktivieren will, kann dies auf technisch recht einfachem Wege tun, indem er die Variable des Löschungszeitraums an geeigneter Stelle im Quellcode auf "fast 0" setzt. (Beschreibung siehe unten)
Der Effekt: Die Log-Einträge werden alle 60 Sekunden gelöscht. So können keine brauchbaren Statistiken mehr entstehen.
Der Vorteil: Sie können schon jetzt einen wichtigen Grund für eine Ablehnung einer Zustimmung zur Nutzung von moodle aufgrund Datenschutzrechtlicher Bedenken entkräften, bevor eine neue Version das Deaktivieren dieser Funktionen endlich auch über einen einfachen Mausklick bietet.
Das Last-Login ist hier nicht betroffen. Allerdings die Übersich der neuesten Aktivitäten insofern Sie keine Arbeitsergebnisse in Form von Forenbeiträgen oder Aufgabeneinsendungen betreffen.
HowTo:
Im Moodle-Hauptverzeichnis gibt es unter /admin die Datei cron.php. Hier werden mehrere Dienste zusammengefasst, die regelmässig ausgeführt werden. Hierunter fällt auch das Löschen der Logs aus denen die Statistiken aufgebaut werden.
Moodle lässt von Haus aus die Reduzierung der Lebensdauer dieser Daten nur auf minimal 30 Tage zu .... aber man kann hier den Wert auf wenige Sekunden reduzieren. Alsdann packt man dann die Funktion in den oberen Bereich der Datei, indem die Funktionen sich befinden, die bei jedem Aufruf der cron.php ausgeführt werden.
Entscheidend ist weiterhin aber noch, wie man den CRONJOB konfiguriert hat. Hier sollte man dann entsprechend einen niedrigen Wert der wiederholten Ausführung (beispielsweise 1 oder 2 Minuten) wählen.
Schritte:
- Wechseln Sie in das Verzeichnis /admin und legen Sie eine Sicherheitskopie von cron.php an.
- Öffnen Sie cron.php zum editieren
- Suchen Sie nach folgendem Eintrag:
/// Delete old logs to save space (this might need a timer to slow it down...)
if (!empty($CFG->loglifetime)) { // value in days
$loglifetime = $timenow - ($CFG->loglifetime * 3600 * 24);
delete_records_select("log", "time < '$loglifetime'");
}
flush();
Glücklicherweise wird die eigentliche Variable erst noch in Tage umgewandelt. Daher bringt das Löschen der Multiplikatoren den gewünschten Effekt, ohne dass Sie mehr davon verstehen brauchen
- Löschen Sie die Multiplikatoren:
/// Delete old logs to save space (this might need a timer to slow it down...)
if (!empty($CFG->loglifetime)) { // value in days
$loglifetime = $timenow - ($CFG->loglifetime);
delete_records_select("log", "time < '$loglifetime'");
}
flush();
Setzen Sie nun die Komplette Funktion direkt über den folgenden Eintrag der cron.php. Dies stellt sicher, dass der Löschvorgang nicht nur sporadisch, sondern bei jedem Aufruf der cron.php durchgeführt wird.:
/// Delete old logs to save space (this might need a timer to slow it down...)
if (!empty($CFG->loglifetime)) { // value in days
$loglifetime = $timenow - ($CFG->loglifetime);
delete_records_select("log", "time < '$loglifetime'");
}
flush();
/// Run all core cron jobs, but not every time since they aren't too important.
/// These don't have a timer to reduce load, so we'll use a random number
/// to randomly choose the percentage of times we should run these jobs.
Als nächstes sollten Sie überprüfen, in welchen Abständen cron die cron.php aufruft. Rufen Sie dafür unter Linux crontab -e auf. Die Tabelle sollte den folgenden Eintrag enthalten:
*/1 * * * * lynx -dump http://www.Ihr-Server.de/admin/cron.php > /dev/null
oder auch:
* * * * * lynx -dump http://www.Ihr-Server.de/admin/cron.php > /dev/null
Dies bewirkt, dass cron die Datei cron.php einmal pro Minute ausführt.
Ändern Sie ggf. die Einträge. Hinweise hierfür bietet die Installationsanleitung von moodle. (Es ist der gleiche Prozess, der auch das Versenden der E-Mails anstösst).
Ich hoffe, der ein oder andere kann sich gerade im öffentlich/rechtlichen Bereich so dafür entscheiden, auf den gläsernen Studenten bzw. Schüler zu verzichten, wenn dies die Situation erfordert ! ! !
In reply to Christian Glameyer
Re: "Deaktivieren" der Statistikfunktionen" ehemals Gruppen anlegen ...
by Ralf Hilgenstock -
Vielen Dank Herr Glameyer. Das ist sehr hilfreich.
In reply to Christian Glameyer
Re: "Deaktivieren" der Statistikfunktionen" ehemals Gruppen anlegen ...
by Jörg S. -
Das hört sich sehr sinnvoll und nützlich an !
Interessanter wäre es, wenn man den Zugriff auf die Logfiles nur den Administratoren geben könnte. Dann kann der Dozent seinen Studenten nicht hinterherschnüffeln - dem Admin bleiben aber die Logs um sein System zu überwachen...
Interessanter wäre es, wenn man den Zugriff auf die Logfiles nur den Administratoren geben könnte. Dann kann der Dozent seinen Studenten nicht hinterherschnüffeln - dem Admin bleiben aber die Logs um sein System zu überwachen...
In reply to Jörg S.
Re: "Deaktivieren" der Statistikfunktionen" ehemals Gruppen anlegen ...
by Ralf Hilgenstock -
Hallo
unter 1.7 kann dies auch durch eine Änderung in der Rolendefinition für Trainer realsiiert werden.
In reply to Ralf Hilgenstock
Re: "Deaktivieren" der Statistikfunktionen" ehemals Gruppen anlegen ...
by Maik Riecken -
... und das Logging lässt sich erfreulicherweise zusätzlich ganz deaktivieren!
Gruß,
Maik
Gruß,
Maik
In reply to Maik Riecken
Re: "Deaktivieren" der Statistikfunktionen" ehemals Gruppen anlegen ...
Hallo,
sehr interessante Diskussion! Ich denke auch, dass es zumindest möglich sein muss, auf das Protokollieren ganz zu verzichten.
Wo lässt sich in Version 1.7 das Logging komplett deaktivieren?
Als Admin habe ich Berichte, Sitzungsinformationen und Statistikinformation ausgeschaltet. Als Trainer kann ich im Kurs dennoch detailliert Berichte ausgeben.
Viele Grüße
Clemens Niederholtmeyer
sehr interessante Diskussion! Ich denke auch, dass es zumindest möglich sein muss, auf das Protokollieren ganz zu verzichten.
Wo lässt sich in Version 1.7 das Logging komplett deaktivieren?
Als Admin habe ich Berichte, Sitzungsinformationen und Statistikinformation ausgeschaltet. Als Trainer kann ich im Kurs dennoch detailliert Berichte ausgeben.
Viele Grüße
Clemens Niederholtmeyer
In reply to Clemens Niederholtmeyer
Re: "Deaktivieren" der Statistikfunktionen" ehemals Gruppen anlegen ...
by Jörg S. -
Hallo,
Sie können jeder Rolle gezielt das Recht zuweisen/entfernen, die Protokolle einzusehen.
Auf anhieb habe ich auch keine Funktion gefunden, die Logging generell ausschaltet. Unter Serveradministration kann man zwar das Logging per CronJob an- und ausschalten. Ausgeschaltet heißt hier aber wohl, dass die Statistiken einfach auf anderem Wege generiert werden...
Sollte es diesen Knopf dennoch geben, wäre ich über einen Hinweis, wo man ihn finden kann, auch sehr erfreut ;)
Bis dahin schalte ich das Einsehen in die Statistiken einfach für alle Rollen außer Admin ab (ein Admin sollte eh immer die Möglichkeit haben, Logs durchzusehen).
Viele Grüße
vom Schorsch
Sie können jeder Rolle gezielt das Recht zuweisen/entfernen, die Protokolle einzusehen.
Auf anhieb habe ich auch keine Funktion gefunden, die Logging generell ausschaltet. Unter Serveradministration kann man zwar das Logging per CronJob an- und ausschalten. Ausgeschaltet heißt hier aber wohl, dass die Statistiken einfach auf anderem Wege generiert werden...
Sollte es diesen Knopf dennoch geben, wäre ich über einen Hinweis, wo man ihn finden kann, auch sehr erfreut ;)
Bis dahin schalte ich das Einsehen in die Statistiken einfach für alle Rollen außer Admin ab (ein Admin sollte eh immer die Möglichkeit haben, Logs durchzusehen).
Viele Grüße
vom Schorsch
In reply to Jörg S.
Re: "Deaktivieren" der Statistikfunktionen" ehemals Gruppen anlegen ...
by Maik Riecken -
Bis dahin schalte ich das Einsehen in die Statistiken einfach für alle Rollen außer Admin ab (ein Admin sollte eh immer die Möglichkeit haben, Logs durchzusehen).
Genau so meinte ich das auch. In meinem Schulsystem sind Äußerungen und Aktionen immer an einen eindeutigen, nicht änderbaren Nutzernamen gekoppelt. Ich verweigere meinen SuS also bewusst die Anonymität (die sie mit ihren meist sehr eingeschränkten Kenntnissen sowieso nirgendwo im Netz besitzen).
Daher sehe ich für mich als Admin keinen Grund mehr, Logdateien von Moodleaktionen zu schreiben. Das wäre in meinen Augen bei unserem Setup reine "Vorratsdatenspeicherung". Für diese Logs sehe ich bei uns keinen technisch zu rechtfertigenden Grund.
Gruß,
Maik
Daher sehe ich für mich als Admin keinen Grund mehr, Logdateien von Moodleaktionen zu schreiben. Das wäre in meinen Augen bei unserem Setup reine "Vorratsdatenspeicherung". Für diese Logs sehe ich bei uns keinen technisch zu rechtfertigenden Grund.
Gruß,
Maik
In reply to Maik Riecken
Re: "Deaktivieren" der Statistikfunktionen" ehemals Gruppen anlegen ...
by Christian Glameyer -
Hallo Herr Riecken,
ich finde es nachwie vor wichtig, dass eine möglichst große Transparenz gegenüber der USer hergestellt wird in Bezug auf die Art der Datenverarbeitung von moodle. Und ich denke nicht, dass alles so bleiben kann, wie es jetzt ist. Ich habe dazu mal einen neuen Thread eröffnet.
Viele Grüße
Christian Glameyer
ich finde es nachwie vor wichtig, dass eine möglichst große Transparenz gegenüber der USer hergestellt wird in Bezug auf die Art der Datenverarbeitung von moodle. Und ich denke nicht, dass alles so bleiben kann, wie es jetzt ist. Ich habe dazu mal einen neuen Thread eröffnet.
Viele Grüße
Christian Glameyer
In reply to Jörg S.
Re: "Deaktivieren" der Statistikfunktionen" ehemals Gruppen anlegen ...
Vielen Dank für die Antwort und für die vielen Hinweise, die zu diesem Punkt im Forum zusammen kommen.
Über das Rollenmodell, Zuweisungen und Permissions kann ich jetzt in Moodle 1.7 Berichte und Logging eindeutig behandeln. Das funktioniert, so wie ich das bis jetzt beurteilen kann, auch ganz gut.
Ich werde die weitere Diskussion im neu aufgemachten Thread verfolgen.
Viele Grüße
Clemens Niederholtmeyer
Über das Rollenmodell, Zuweisungen und Permissions kann ich jetzt in Moodle 1.7 Berichte und Logging eindeutig behandeln. Das funktioniert, so wie ich das bis jetzt beurteilen kann, auch ganz gut.
Ich werde die weitere Diskussion im neu aufgemachten Thread verfolgen.
Viele Grüße
Clemens Niederholtmeyer