DSGVO/GDPR-relevante Module

Ja das mit dem Sanitizer ist ein Problem. Mich würde auch interessieren wo der unterschied zwischen sanitize und anonymize liegt. Außerdem müssen wir überlegen, wo wir GDPR stehen lassen müssen und wo wir DSGVO stehen lassen können. Beispiele hierfür unter folgendem Link:

https://localize.drupal.org/translate/languages/de/translate?project=gdp...

@balu Ertel. It's just a draft. as the UI Texts currently are. and there some errors within the strings as well. I agree, that we have to check them against the gdpr wisely and with cautiousness. Also we have to monitor this issue as new module versions came alogn. It would be great if the DA will mention them in their monthly newsletter. So it wíll be very easy to monitor them.

TO bring in an Idea to #10 mailchimp aka Drupal Newsletter will be a good place. I'll do my best to track and revise all 5 at least monthly.

EU Cookie Compliance wird vom GDPR Modul referenziert und sollte daher dringend ebenfalls übersetzt werden. Ich habe den Issue soeben entsprechend geändert

Kein Problem Ich verwende ohnehin lieber gdpr Compliance. Dafür könnten wir noch einen Reviwer mehr brauchen.

GDPR: Die hier bitte löschen oder freigeben: https://localize.drupal.org/translate/languages/de/translate?project=gdp...

Den Rest muss ich mir noch mal ansehen, um auch wirklich die im Gesetz abgebildeten Termen verwenden zu können.

GDPR Consent

Hier müssen wir noch einmal drüber:

https://localize.drupal.org/translate/languages/de/translate?project=gdp...

Die DSGVO bezeichnet Zustimmungen zu Vereinbarungen als Einwilligung.

Drängeln ist kein gutes Wort für das erzwingen einer Einwilligung. auch wenn dieses, genauso wie das stillschweigende Einwilligung in eine Bedingung eigentlich unterbleiben sollte.

https://www.e-dsb.de/erwgrund/ds-gvo-erwaegungsgrund-32/

Mir gefällt die Formulierung Drängeln überhaupt nicht. Ich habe daher auch hier die noch einmal zu Prüfenden Zeichenfolgen gelöscht. Sind diese erneut übersetzt und zugelassen sollte das Modul sicherheitshalbe in der UI noch einaml einer Review unterzogen und an den entsprechenden Stellen abgeändert werden.

@hass
So sollte das besser passen. auch zu
https://dsgvo-gesetz.de/art-7-dsgvo/

Das Erzwingen einer zustimmung sollte ohnehin vermieden werden. Aber hier sind offenbar Fälle gemeint, in denen sich dies nicht ohne weiteres vermeiden lässt.

Ich habe die Übrigen Strings entsprechend angepasst. Sollte jetzt freigabewürdig sein.

https://localize.drupal.org/translate/languages/de/translate?project=gdp...

Danke für die Korrektur. Zustimmung und Einwilligung hier auseinanderzuhalten, bzw. richtig zu verwenden, ist extrem schwierig. jetzt sollten die Strings aber passen.

Hier war noch ein großes I Der Rest ist ok.

https://localize.drupal.org/translate/languages/de/translate?sid=2671317

Bitte Korrekturen zulassen unter anderem wurde fehlerhaftes HTML entfernt.

https://localize.drupal.org/translate/languages/de/translate?project=gdp...

@hass hab ich gesehen und bin auch noch mal drüber. Da waren schon noch einige Hämmer dabei. Tobias Korrektur muss ich noch in die D7 Variante übernehmen, sobald ich Zeit finde.

Bitte freigebn, dann ist das GDPR-Modul fertig

https://localize.drupal.org/translate/languages/de/translate?project=gdp...

Gesehen und freigegeben. Rest von mir bitte löschen.

Ich mach den einfach zu, da abgesehen von EU Cookie compliance ohnehin alles erledigt ist und die String Review wohl noch länger auf sich warten lässt.

Kurzes Update zur Lage an der DSGVO-Front.

Die DSGVO ist nun schon etwas älter und auch die Rechtswirksamkeit ist schon eine weile gegeben.

Leider sind wir an der Ecke zumindest in der deutschen Übersetzung und auch technisch in der Programmierung nicht so weit, dass ich mit gutem Gewissen sagen könnte, wir sind hier fertig.

Im Folgenden möchte ich euch gerne am Beispiel von Facebook einmal die Schmerzpunkte aufzeigen, die wir aktuell noch beseitigen müssen.

Facebook bietet uns Webmastern im Grunde 3 Dienstleistungen an, die (fast) jede Website im Drupalversum auf die ein oder andere Weise nutzt.

1. Share-Buttons
2. Single-Sign-On
3. Widgets

Share Buttons

In Punkto Share Buttons gibt es grundsätzlich 2 Lösungen:

1. Der Heise Ansatz mit Shareiff

Bei diesem Ansatz wird der Nutzer nach Klick auf den Button um einen Login auf der Plattform gebeten, nachdem er auf den Teilen Button geklickt hat. Ein Datenaustausch im schutzwürdigen Sinne findet hier also erst nach dem Einloggen durch Bestätigung des Nutzers über den Login auf der Plattform des Drittanbieter statt.

Rechtlich ist dies bei entsprechend ausformulierten Datenschutzbedingen unbedenklich.

2. Der Einsatz normaler Shareing-Buttons ohne Shareiff

Bei der zweiten Methode haben wir die Situation, dass ab dem Moment, in dem die externen Skripte der Plattform geladen werden ein Datenaustausch stattfindet.

Das ist ohne weitere Maßnahmen, sprich das vorherige Einloggen einer Zustimmung über eine Checkbox und einen Hinweis auf die entsprechende Stelle in der Datenschutzerklärung rechtlich nicht zulässig.

Genau an dieser Ecke hakt es momentan auch noch in der deutsche Übesetzung

Module wie Blizz-Vanisher EU Cookie Compeliance und einige andere bieten hier eine rechtskonforme Lösung an, bei der der Nutzer erst dazu aufgefordert wird eine Einverständniserklärung abzugeben und im Anschluss an diese Einwilligung die entsprechenden Skripte und Plug-Ins nachgeladen werden.

Alle mir bekannten Lösungen auf Drupal.org sind entweder schlecht dokumentiert (Blizz-Vanisher) oder nicht vollständig Übersetzt (EU-Cookie Compelliance)

Tatsächlich kann EU-Cookie Cmpeliance, dass eigentlich nur einen Cookie-Hinweis ausgeben soll aber auch genau solche Drittanbieter-Skripte blocken, bis der Nutzer dem Nachladen dieser Skripte zugestimmt hat.

Bei aller Diskussion um die Modulnamen, dem durchaus erkennbaren Nutzen einer Übersetzung von Distributionen wie Varbase und DE-Gov, die durch die Vielfalt an Modulen einfach einen positiven Synergieeffekt auf alle anderen Drupal-Installationen haben, bin ich doch der Meinung, dass wir dringend die Module, die DSGVO-relevant sind zu aller erst übersetzen sollten. Gerade EU Cookie Compelliance sollte so zeitnah wie Möglich fertig werden, damit Module, die auf der Funktionalität aufbauen externe Skripte zu Blockieren, bis eine Einverständniserklärung durch den Nutzer erfolgt, zeitnah nachgezogen werden können.

Außnahmsweise auch für Drupal 7

Hier gilt auch tatsächlich die Ausnahme von der Regel nur noch für Drupal 8 zu übersetzen. Datenschutz muss sowohl in Drupal 8 als auch in Drupal 7 gewährleistet seien, bis sichergestellt ist, dass niemand mehr Drupal 7 verwendet, weil er entweder die Vorteile von Drupal 8/9 erkannt hat oder so frustriert ist, dass er die Plattform wechselt.

Sigle-Sign-On-Plgins

Single-Sign-On-Plugins, wie sie beispielsweise Social-Auth zur Verfügung stellt und wie sie auch in Distributionen wie Open Socrial und Varbase integriert sind, sind datenschutzrechtlich im Grunde ein absolutes No-Go. Hier kann die Einwilligung des Nutzers nämlich erst in der Datenbank von Drupal abgelegt werde, nachdem bereits der Austausch der notwendigen Profildaten stattgefunden hat.

Eine Registrierung über einen externen SSO-Dienst wie Facebook, unter der Verwendung von Social-Auth kann man also aktuell mit Drupal Boardmitteln nicht anbieten, da das Speichern der Einwilligung vor der Verwendung des SSO-Buttons in Drupal nicht möglich ist. Der Nutzer meldet sich schließlich erst über den SSO-Button an, wir auf das Registrierungsformular weitergeleitet und erstellt anschließend ein Konto.

Eine Anforderung der Profildaten

• UUID im sozialen Netzwerk,
• Name,
• E-Mail-Adresse
• und eventuell sogar des Profilbildes, dass der Nutzer dort abgelegt hat

ist zu diesem Zeitpunkt aber bereits abgeschlossen. In der Regel wird das Registrierungsformular mit diesen Daten bereits vorab ausgefüllt, um dem Nutzer den Registrierungsvorgang so angenehm wie möglich zu machen.

Der Einsatz eines Moduls wie Social-Auth ist also aktuell erst nach Registrierung über die systeminterne Methode möglich (Login mit SSO Ja. Erstellen von Benutzerkonten mit SSO, Nein)

Einsatz von Drittanbieter-Widgets

Auch der rechtskonforme Einsatz von Drittanbieter-Widgets, wie beispielsweise dem Facebook Page Plugin ist erst nach Einholen der Zustimmung seitens des Nutzers und den anschließende nachladen der Daten möglich.

Leider bietet momentan kein Modul eine all inclusive und bzw. out of the box Lösung für alle Datenschutzrelevanten Vorgänge in Verbindung mi Drupal-Websites.

Ich habe bereits im Vergangenen Jahr eine Verschmelzung des GDPR-Moduls und des Blizz-Vanishers in beiden Issue Queques angeregt. Beide Issues sondern schlicht ignoriert worden.

Aus meiner Sicht bedeutet dass, dass dieser Issue hier vorrangig vor allen anderen behandelt werden sollte, um eine Grundlage zu haben, die Programmierer dieser Datenschutzlösungen an einen Tisch zu bekommen.

Ich kann wirklich erst dann eine wirksame Botschaft an alle Modulentwickler, die sich mit dem Thema beschäftigen, senden wenn ich auf der Grundlage argumentieren kann, dass wir alle verfügbaren Module zu dem Thema 100 % ig übersetzt haben und trotz der dadurch gegebenen Transparenz für den Endanwender ein wirksamer Datenschutz im Hinblick auf die DSGVO mit Drupal immer noch nicht möglich ist. Wobei möglich hier ganz klar bedeutet, dass der Endanwender in der Lage ist, ohne viel Schmerzen eine Website, die er mit Drupal erstellt Datenschutzkonform abzusichern.

Schmerzen bedeutet gerade in diesem Fall aber auch ohne die Notwendigkeit selbst in den Code von Drupal eingreifen zu müssen oder gar Module on Drittanbietern zu nutzen, die mit Hilfe eines gültigen Dateverarbeitungsauftrags und einer eigenen API dafür sorgen, dass z. B. Single-Sign-On auch Datenschutzkonform möglich ist.

Machbar ist das jetzt schon übe das Modul One All Scial Login.

Dieses setzt aber sowohl die Bereitschaft für ein monatliches Abomodell, als auch einen gültigen Datenverarbeitungsauftrag voraus. Für Firmen mit genug Jahresumsatz ist das auch vollkommen in Ordnung. Für Vereine und Privatpersonen ist ein solches Modul aber keine Option. Daher werde ich tatsächlich alles stehen und liegen lassen, was hier in der Issue-Queque noch so rumgeistert, bis wir in Punkto GDPR-Module-Suite und Third Party-Modules zu diesem Thema alle Strings in Drupal 8 und Drupal 7 übersetzt haben.

Auch an dieser Stelle werde ich Drupal 8 natürlich bevorzugt behandeln. Es gibt für mich keinen logisch nachvollziehbaren Grund mehr Zeit und Mühe in Drupal 7 zu stecken, obwohl Drupal 9 so kurz vor der Tür steht. Wenn mir 200 Drupal Nutzer garantieren, sich im Hinblick auf die eventuelle Verlängerung des Supports für Drupal 7 und daran anschließende Paid Support Programme um Drupal 7 zu kümmern und regelmäßig zu übersetzen, dann werde ich eventuell noch mal darüber nachdenken, ob ich meine Zeit für Drupal 7 aufwende.

Bei der aktuellen Lage, in der mir maximal 2 - 5 Übersetzer einfallen, die regelmäßig Drupal übersetzen und sich wirklich darauf eingerichtet haben, wöchentlich ein Stündchen in die Übersetzung zu investieren bin ich persönlich aber nicht bereit an diesem Entschluss etwas zu ändern. Das würde sich nachteilig für Drupal 8 und Drupal 9 auswirken.

Trotzdem beiße ich persönlich sehr gerne in den sauren Apfel und übersetze datenschutzrelevante Module Zeichenfolge für Zeichenfolge, bis kein String mit dem Status Untranslated has no Suggestion/has Suggestion mehr da ist.

Das haben wir mit dem Core von Drupa 8 und Drupal 7 hinbekommen und das bekommen wir auch mit allen DSGVO Modulen auf die Reihe. Die sind insgesamt nämlich nicht ansatzweise so umfangreich.

Wer mich dabei unterstützen möchte, der kann sich in diesem Issue gerne kurz melden. Auf Grund der Erfahrungen aus dem letzten Jahr rechne ich zwar nicht mit einem einzigen Kommentar, freue mich aber bestimmt über jede Reaktion auf diesen Beitrag.

Macht's gut und traut euch die Issue Queque wieder regelmäßig zu benutzen. Bis Dann!

Joachim