DSGVO (Allgemeine Datenschutzgrundverordnung) und MediaWiki-Software

This page is a translated version of the page GDPR (General Data Protection Regulation) and MediaWiki software and the translation is 94% complete.
Outdated translations are marked like this.

Die Allgemeine Datenschutzgrundverordnung (GDPR) (EU) 2016/679 ist eine Verordnung im EU-Recht zum Datenschutz und zum Schutz der Privatsphäre für alle Personen innerhalb der Europäischen Union und des Europäischen Wirtschaftsraums. Sie regelt zudem den Export personenbezogener Daten in Länder außerhalb der EU und des EWR. Die DSGVO zielt in erster Linie darauf ab, den Bürgern und Einwohnern die Kontrolle über ihre personenbezogenen Daten zu geben und das regulatorische Umfeld für internationale Unternehmen zu vereinfachen, indem die Vorschriften innerhalb der EU vereinheitlicht werden.

Die DSGVO ist am 24. Mai 2016 mit einer zweijährigen Übergangsfrist in Kraft getreten, die am 25. Mai 2018 endete. Seitdem sind alle Organisationen, die Daten von Personen mit Bezug zur EU sammeln, zur Einhaltung verpflichtet. Da die MediaWiki-Software auch von Nutzern in der EU verwendet oder Nutzern dort angeboten wird, stellten sich mehrere Fragen, wie MediaWiki mit der DSGVO konform gestaltet werden kann.


Bitte beachte, dass die folgenden Empfehlungen von betroffenen MediaWiki-Benutzern stammen, die keine Rechtsanwälte sind. Bitte gehe auf eigenes Risiko vor.

In diesem Artikel geht es NICHT darum, wie man die MediaWiki-Software ändert, um sie DSGVO-konform zu machen (falls überhaupt nötig), sondern um jede Website, die auf der MediaWiki-Software basiert. Hier geht es also um Erweiterungen, Skripte oder alles, was du dir vorstellen kannst, um die Website GDPR-konformer zu gestalten.

Eine absolute Einhaltung ist auf öffentlichen MediaWiki-Websites nicht möglich, zumindest nicht für die Website-Administratoren, da die meisten Inhalte von den Nutzern eingestellt werden. Der Titel lautet also, wie man es „MEHR“ DSGVO-konform gestaltet.

Bitte versuche, alles über allgemeine MediaWiki-Websites vorzuschlagen, was aufgrund der DSGVO ein Problem sein kann, und alle Möglichkeiten, dieses Problem zu beheben oder zumindest zu umgehen.

Ist mein MediaWiki überhaupt betroffen?

Wenn du ein öffentlich zugängliches und/oder bearbeitbares MediaWiki hast, das sich auf einem Server in der EU befindet oder auf das Personen aus der EU zugreifen können, musst du die DSGVO einhalten, denn auch IP-Adressen gelten als Daten, die dadurch geschützt sind. Da du nicht auf eine Website zugreifen kannst, ohne die IP-Adresse zu protokollieren, ist auch deine Website betroffen (Auch wenn du selbst die IP auf deiner Website nicht protokollierst, wird dein Hoster das in einigen Logdateien tun, von denen du keine Ahnung hast. In diesem Fall kannst du eine signierte ODP [Auftragsdatenverarbeitung] von deinem Hoster verlangen).

EtherMan on Wikipedia, MediaWiki, and the GDPR fear - opinion?:

MediaWiki is... special in this regard... On one hand, it is already compliant really as a software. GDPR basically says that you have to agree to any data that is stored. Well that's easy enough, MediaWiki only stores what you specifically supply it, and every single edit you make, comes with the clause that you are placing whatever you entered under a license which enables reuse. And the second part is that you have to be able to on request of the owner to release everything that is stored on you, to you. Well that's simple enough through MediaWiki by searching for any edits you made because that in theory, should be all data on you.

Leider ist es jedoch so, dass... Wikipedia nie damit einverstanden sein wird, denn technisch gesehen musst du ALLE Daten, die über DICH gespeichert sind, herausgeben... Nicht VON dir. Im Grunde alle Daten, die sie jemals über dich erhalten haben. Das heißt, alle privaten Arbcom-Mails, die sich auf einen Fall beziehen, an dem du beteiligt bist. Das bedeutet, dass du auf jeder Gesprächs- oder Artikelseite und so weiter erwähnt wirst. Das gilt sogar für alle Admins, die einen Zettel mit einer Liste ihrer meistgehassten Nutzer an ihrem Bildschirm haben, falls du dazu gehörst. Das ist alles abgedeckt...

Der Punkt ist, dass MediaWiki aus technischer Sicht es einem Unternehmen ermöglicht, konform zu sein. Doch Wikipedia wird es nie sein, weil es grundlegend inkompatibel ist und es einen RIESIGEN Arbeitsaufwand bedeuten würde, dies zu ändern. Zudem ist die gesamte Struktur nicht dafür ausgelegt, die Informationsfreiheit in den Prozessen zu gewährleisten, welche die DSGVO verlangt, doch das ist ein Problem von Wikipedia, nicht von MediaWiki.

Vorschläge/Lösungsmöglichkeiten

Vorhandene Werkzeuge und Mittel nutzen

Using existing tools and means

  • Bestehende Gesetze (wie z. B. die Cookie-Richtlinie der Datenschutz- und elektronische Kommunikationsrichtlinie 2002) gelten auch dann noch, wenn die DSGVO in Kraft tritt (wie in den letzten zwei Jahren). Wenn sich der Server deines Wikis also in der EU befindet und/oder du dich an Nutzer/innen in der EU wendest, solltest du Erweiterung:CookieWarning verwenden, wenn du es nicht schon tust. Der Text der Warnung/Erklärung muss eventuell entsprechend geändert werden.
  • Die DSGVO verlangt die Einführung angemessener, kosteneffizienter Kontrollen zum Schutz der personenbezogenen Daten von EU-Bürgern. Es ist immer noch umstritten, ob die DSGVO eine Verschlüsselung per se verlangt. Der Text verwendet die Wörter wie Verschlüsselung, kann Verschlüsselung beinhalten, gegebenenfalls (...) Pseudonymisierung usw. Es handelt sich also eher um Vorschläge als um eine Forderung. Aus Sicherheits- (und SEO-) Gründen ist es jedoch sehr wichtig, TLS für dein Wiki zu verwenden. Vielleicht bietet dein Host-Provider kostenlose Let's Encrypt-Zertifikate an?
  • Wenn in die SQL-DB deines Wikis eingebrochen wird, musst du den Behörden und deinen Nutzern mitteilen, welche Informationen betroffen/gespeichert wurden (in der Regel IP-Adresse für alle Bearbeiter) und E-Mail-Adresse, Vor- und Nachname, wenn du sie von deinem Nutzer für angemeldete Nutzer anforderst)
  • Du solltest deine Nutzer/innen fragen, ob sie bei der Anmeldung älter als 16 Jahre sind oder ob sie die Zustimmung ihrer Eltern haben.
  • Aktualisiere die Datenschutzerklärung des Wikis, falls noch nicht geschehen, dass IP-Adressen (für alle Bearbeiter), E-Mail-Adressen und Benutzernamen (für registrierte Benutzer) gespeichert werden, was technisch für die Nachverfolgung und das Zurücksetzen von Bearbeitungen erforderlich ist, und dass die Benutzer beim Einloggen oder Bearbeiten deines Wikis zustimmen, dass sie sich an wen wenden müssen, wenn sie ihren Account löschen lassen wollen usw. Ein DSGVO-konformer Datenschutzgenerator kann z. B. für private Zwecke verwendet werden:
    • Deutsch: Datenschutzerklärung Generator (leider nur auf Deutsch verfügbar)
    • Deutsch, Englisch und Französisch: Ratgeberrecht (Menü und Kontrollkästchen auf Deutsch)
    • Polnisch, Englisch: OODO (diese Tools sind zunächst kostenfrei - zuerst musst du einen Eintrag über die Datenverarbeitungsaktivitäten erstellen, dann eine Information/Klausel, die mit der DSGVO konform ist.)
    • Bitte füge hier Datenschutzgeneratoren für andere Sprachen hinzu
  • Wenn du beim Einloggen E-Mail-Adressen verlangt hast, informiere deine Nutzer/innen darüber, dass sie diese in ihren Benutzereinstellungen löschen können. Da eine E-Mail-Adresse für die Anmeldung nicht erforderlich ist, betrifft dies nur Wikis, die E-Mail-Bestätigung für die Bearbeitung verwenden (z. B. für Anti-Spam-Maßnahmen, YMMV).
  • Füge den Namen eines Admins/Mods in den Datenschutzartikel ein, falls jemand Informationen über seine gespeicherten Daten haben möchte. Ich würde einen Link hinzufügen, wie diese ihr Konto schließen können.
  • Füge hinzu, welche Datenschutzbehörde für dein Land zuständig ist (oder für Deutschland zu bestimmen ist), dies wird zudem von der DSGVO verlangt.
  • Verwende Hilfe:Versionslöschung , um IP-Adressen und Versionstexte zu verstecken, die früher persönliche Daten aus älteren Versionen enthielten.

Probleme ==

Die E-Mail-Adressen der Konten werden in MySQL-Datenbanken unverschlüsselt/im Klartext geladen

The account e-mail addresses are stored in MySQL databases unencrypted/in plain text

Das wird zu einem Problem, wenn die SQL-Datenbank geknackt wird.

Mögliche Lösung (vorgeschlagen von @Ciencia Al Poder) - dies sollte kein Problem sein, da

  • die E-Mail-Adressen nur für den Systemadministrator zugänglich sind.
  • Die MediaWiki-Software in der Lage ist, die E-Mail-Adressen zu entschlüsseln, auch wenn sie verschlüsselt sind, um sie für den Versand von E-Mails zu verwenden.
  • jeder, der Zugriff auf den MediaWiki-Code oder die Shell hat, sie mit der Software entschlüsseln kann
  • die Nutzer/innen die Kontrolle über ihre E-Mail-Adressen haben und diese löschen können, wenn sie wollen.

Benutzerkonten löschen

  • Mediawiki-Benutzer können ihr Konto nicht selbst löschen. Natürlich existieren Erweiterungen, die das Zusammenführen von Konten ermöglichen, und es existiert immer die Möglichkeit, die Einträge in SQL zu löschen, jedoch ist es im Allgemeinen nicht bevorzugt, Benutzer zu löschen
    • Allgemeine Warnung: Nimm keine Änderungen direkt an der Datenbank vor, wenn du nicht genau weißt, was du tust. Zudem kann das Entfernen von Zeilen aus der Benutzertabelle zu unerwarteten Fehlern führen, wenn Logs oder Seitenverläufe angezeigt werden, in denen der Benutzer auftaucht.

Bitte hinzufügen: Übersicht für SQL-Befehle zum Löschen von Konten oder Link zur bestehenden Dokumentation

  • Erweiterung:DisableAccount entfernt das Passwort und die E-Mail. Mit Handbuch:Benutzer umbenennen kannst du das Konto dann mit zufälligen Zeichen umbenennen. Du musst keine Änderungen direkt in der Datenbank vornehmen.
    • Wenn du das Gefühl hast, dass du auch den ursprünglichen Benutzernamen aus dem Protokoll ausblenden musst, kannst du ihn ausblenden, wenn du das Benutzerrecht deletelogentry hast.
  • Extension:RemovePII may be useful to do a more thorough removal.

The problem of deleting a user's contributions

Das Löschen der Beiträge eines Nutzers hinterlässt den Benutzernamen (oder die IP-Adresse, wenn der Nutzer nicht eingeloggt ist) im Löschungsprotokoll - es ist also kein sauberer Vorgang.
Der Eintrag des Benutzers im Verlauf der Version kann mit dem Manual:DeleteOldRevisions.php gelöscht werden.
Lies dieses Thema für weitere Informationen - Project:Support desk/Flow/2016/11#h-How_to_delete_deletion_history?-2016-11-10T06:33:00.000Z.
Zudem wurde Erweiterung:DeletePagesForGood empfohlen.
Auch kannst du direkt aus der Datenbank löschen (auch wenn das ein wenig riskant ist).

A user wants to remove any references to their username

Der Benutzername wird mit jeder Bearbeitung durch den Nutzer verknüpft. Der Nutzer hat keine Möglichkeit, diese Verweise zu entfernen.
Mögliche Lösung (auch von @Rocketpipe vorgeschlagen) - Es könnte ausreichen, wenn der Nutzer bei der Kontoerstellung auf diese Einschränkung hingewiesen wird.
Als Alternative könnte der Admin einen allgemeinen Benutzer namens "Deleted user" (oder etwas Ähnliches) festlegen und alle Bearbeitungen des Benutzers, der die Verweise mit Erweiterung:UserMerge entfernt haben möchte, mit dem allgemeinen Gelöschten Benutzer zusammenführen. Dies hat das Problem, dass ein Protokolleintrag existiert, der sich auf diesen Merge -> Username bezieht, die Details des Protokolleintrags jedoch ausgeblendet werden können.
Nutzer mit dem Recht hideuser können ein Konto mit "suppress" versehen, wodurch es aus den Seitenverläufen, Log-Einträgen und der Liste der Nutzerkonten entfernt wird.

Neue Versionen einer Seite, die persönliche Daten einer Person enthalten, wurden erstellt

Mögliche Lösungen:

Eine Seite, die persönliche Daten einer Person enthielt, wurde verschoben (= unter einer anderen URL veröffentlicht)

Not sure what the issue here is, moved as in information was copied to another wiki?

Google hat alte datenschutzrelevante Inhalte aus deinem Wiki zwischengespeichert, die inzwischen entfernt wurden

Ein Nutzer möchte seine Daten löschen oder übergeben

Mögliche Lösung (vorgeschlagen von @TheDJ):

  • Ein Benutzer kann seine E-Mail-Adresse löschen, indem er sie in den Einstellungen entfernt. Die E-Mail-Adresse wird von MediaWiki nicht benötigt.
    • Hinweis: Die Anforderung der E-Mail-Adresse bei der Kontoerstellung kann vom Systemadministrator mit LocalSettings.php festgelegt werden. Der erste Punkt der Lösung ist also möglicherweise nicht auf alle Websites anwendbar.
  • Der Nutzer veröffentlicht seine Beiträge unter der auf der jeweiligen Website genannten Lizenz.
  • Der Datenbankbenutzer kann bei Bedarf einen bestimmten Beitrag löschen.
    Bitte hinzufügen: Übersicht für SQL-Befehle zum Löschen von Konten oder Link zur bestehenden Dokumentation
    • Bitte verwende Hilfe:Versionslöschung , bearbeite die Datenbank nicht selbst, wenn du dir nicht absolut sicher bist, was du tust!

Entfernen des Feldes für den echten Namen im Einlogg-Formular

Ausblenden der Anzeige von IP-Adressen für anonyme Bearbeitungen

  • Abhilfe: Deaktiviere anonyme Beiträge ohne Benutzerkonto über $wgGroupPermissions['*']['edit'] = false; in LocalSettings.php
  • Indem du Manual:Hooks/HtmlPageLinkRendererBegin einfügst, wenn du feststellst, dass der Link zu einer IP führt, und die IP durch einen generischen Benutzernamen wie Anonymer Bearbeiter oder Nicht eingeloggter Benutzer ersetzt
  • Ersetze die IP-Adresse durch einen Hash, um sie zu anonymisieren, entweder während der Bearbeitung oder bei der Anzeige.

Die stillschweigende Zustimmung ist nicht mehr ausreichend

"Die Zustimmung muss durch eine eindeutige Handlung erfolgen, z. B. durch Anklicken eines Opt-in-Feldes oder durch Auswahl von Einstellungen oder Präferenzen in einem Einstellungsmenü." "Der bloße Besuch einer Website gilt nicht als Zustimmung."[1]

This is relevant in the following situations:

  • an extension to edit the sign-up form (for example to add a check box that a user is older that 16 years) or for adding a link to the privacy statement
  • a checkbox on the sign-up form to accept the privacy policy (registration is rejected if the check is not ticked). The value of this checkbox should be recorded in database.
  • a checkbox presented on the edit form for unregistered users, and users that registered before adding the checkbox on the sign-up form, to accept the privacy policy. If the checkbox is not ticked when saving the edit, the edit is rejected. If a registered user is presented with that checkbox and submits the edit, this is recorded in database and shouldn't be presented anymore.

List of solutions:

  • Extension:UserAgreement can be used to achieve compliance for registered users.
  • Partial solution: changes to registration page (by editing MediaWiki:Signupstart), anonymous editing (by editing MediaWiki:Anoneditwarning). This does not make the opt in explicit, but it improves matters.
  • Addition of a special page for existing users to accept the new privacy statement (requires a new extension).
  • Partial solution: use Extension:NewSignupPage to require explicit acceptance of privacy terms on registration. This does not address existing users or anonymous edits.
  • User:TimSC's fork of Extension:NewSignupPage available here: [1]. It asks anonymous editors to opt in to the terms of service. It allows user opt out of terms of service but the admin must still manually process data removal. It also prompts existing users that have not explicitly opted in to do so. All accept and reject actions are explicitly logged.

List of existing Extension which might be useful for compliance

List of required/missing functions

  • MediaWiki could use an extension where user can export their saved data as an XML or JSON file (still to be defined what that would includes besides the username, IP address etc what additional information was stored, if the changes/edits would have to be included), similar to Wordpress - although given the nature of how wikis works this might become a major headache (basically if a editor decides to have their personal data scraped, which is their right to do so, this means Wiki admins would have to change the user name to some anonymized version like deleted user or something, same for edits that were done by not logged in users where the IP is shown).
  • Mask IP addresses of unregistered users, by removing the last byte of IPv4 address (maybe by setting it to 0, for example, 192.168.1.5 would become 192.168.1.0), or the last 80 bits in case of a IPv6 address. This is what Google Analytics does for being compliant: IP anonymization on analytics. It may be done not only on display, but also on the information stored on the database. A maintenance script could be made to anonymize existing data.

Using Semantic MediaWiki as a tool for documenting GDPR compliance

Further reading

See also

Support desk threads