DSGVO-Anpassungen #1512
Comments
|
Wäre hier ein freies Textfeld eventuell flexibler? Link zur Datenschutz-Seite kann man ja via Insert-Tag einbinden. Damit bleibt die (rechtlich korrekte) Schreibweise der Checkboxbeschriftung beim Betreiber der Seite und man kann auch komplexere Texte abbilden die auch noch auf AGBs usw. verweisen. |
|
Soweit ich weiß, wird IP Anonymisierung bei Piwik/Matomo nur serverseitig festgelegt – also nicht im Tracking Code, sondern in der Piwik-Instanz. Mir ist jedenfalls keine Config-Möglichkeit im Tracking Code bekannt. Man könnte aber überlegen, ob man den Piwik Opt-out standardmäßig als Content Element anbietet (https://matomo.org/docs/privacy/#step-3-include-a-web-analytics-opt-out-feature-on-your-site-using-an-iframe) |
Kann man da nicht einfach einen Tiny zur Verfügung stellen? Da hat man dann auch ein "ordentlichen" Linkpicker, Mit Inserttag ist immer so ... naja ... aber grundsätzlich find ich die Idee gut, dass der Seitenbetreiber es selbst einarbeiten muss.
Yep ... hatten wir vorgesehen, aber da bleibt die Frage wegen der Rückportierung auf 4.4
Ich hatte bei meiner Recherche der Optionen Ende letzten Jahres keine Nocookie-Option bei Vimeo gefunden. Ich habe gerade eben nochmal geschaut, ob ich dazu etwas finde, aber ich habe nichts zu einer solchen Option bei Vimeo gefunden. Somit haben wir sowas nicht bei Vimeo und wir sollten uns auch hier überlegen, ob wir eine Meldung einblenden.
Naja ... ich fände es direkt im Template auch besser, weil die Checkbox ja nur greift, wenn das originale Template benutzt wird. Das hatte ich letztens bei einem Kunden, der der Meinung war, dass die IP's anonymisiert gespeichert werden, weil die Checkbox in den Einstellungen aktiviert war. Er hatte aber den kompletten Code im Template mit seinem eigenen Template ersetzt, deshalb war die Option völlig egal.
Die Frage ist, ob wir die Option überhaupt weiterhin anbieten sollten. Wenn jemand Google Webfonts einbinden möchte, dann muss er ja nur einfach auf die Website von Google Fonts gehen, seine Schriften zusammensuchen, den Einbett-Code kopieren und als eigenen Head-Tag in ein Layout einfügen. Der die Google-Webfonts nicht via Google einbinden möchte, muss sie sowieso lokal einbinden und vorher über Websites wie z.B. https://google-webfonts-helper.herokuapp.com/fonts seine Fonts zusammenstellen, herunterladen, einbinden und den generierten Code in seine CSS übernehmen. Aber ein Hinweis sollten wir auf jeden Fall machen, wenn wir die Option weiterhin zur Verfügung stellen.
Wäre hier ggfs. auch ein Hinweis sinnvoll, wenn die Scripte via CDN eingebunden werden? -- Wir hatten ja in unserem Gespräch mit Peter die Option einer Übersicht besprochen, die bei der Installation gezeigt werden könnte (mit Infos zu Speicherzeiten, Speicherorten etc.). Grundsätzlich inde ich diese Idee super. Es wäre nur die Frage, ob wir das irgendwo sinnvoll eingebaut bekommen?! |
|
Analog zum Newsletter-Modul benötigen wir das Feld auch für das Kommentarmodul, da hier auch die IP-Nr. gespeichert werden. Was ja auch bedingt Sinn macht, diese bei z.B. Hasskommentaren für den Zeitraum der Nachverfolgungszeit zur hand zu haben, falls man nachweisen muss, über welche IP der entsprechende Beitrag eingestellt wurde. |
|
Die Google Fonts könnten wir über Contao routen und cachen, dann kann man immer noch einfach nur die Checkbox aktivieren (UX👌🏻) aber die IP die Google kriegen würde wäre nur die des Servers und würde somit den Besucher schützen. Man verliert dadurch natürlich den CDN-Effekt (tut man allerdings ja auch wenn man die Dateien erst herunterladen und selber einbinden muss) und ob es GDPR-technisch sinnvoll ist, weiss ich nicht, aber ich würde mich zur Verfügung stellen das für die 4.6 einzubauen. |
|
@Toflar dafür eventuell interessant: DaAwesomeP/php-offline-fonts Leider liefert Google unterschiedlichen CSS-Code abhängig vom User-Agent aus was das routing und caching unnötig aufbläht... 😕 |
|
Das verkompliziert die Sache halt etwas, aber ich denke es wäre immer noch machbar. Kannst ja helfen 😄 |
Reicht das? Über youtube-nocookie.com werden zwar nicht die youtube.com Cookies an Google gesendet - Google kann aber zumindest die IP eines Besuchers deiner Website sofort erfahren. @netzarbeiter und ich diskutieren gerade über eine Möglichkeit für die youtube_iframe extension, dass man, ähnlich wie jetzt bei dlh_googlemaps zuerst (optional) ein Overlay hat, und erst bei Bestätigung der iframe eingebunden wird. Oder der Server lädt das Vorschaubild von YouTube und zeigt erst nur das an und dann on-click wird der iframe eingebunden. Oder man benutzt ein hinterlegtes Vorschaubild etc. Bei anderen Maßnahmen wie zB. bzgl. jQuery, MooTools & Google Fonts geht es ja auch darum erst mal keinen Request des Clients zu einem externen Service zu verursachen. Das müsste man dann ja konsequent auch bei Video iframes machen, unabhängig von der verwendeten Domain. |
Das habe ich schon ein paar mal bei Kunden eingebaut und lässt sich sehr einfach mit einem Poster-Image und einer Zeile Javascript machen. Beispiel unter https://www.referenzpreise-nein.ch |
|
Was ist denn mit Contao 3.5? Und 3.5 hat ja noch Support bis Mitte 2019. Wenn die DSGVO-Änderungen bei 3.5 nicht implementiert werden, könnt ihr den Support für 3.5 auch sofort einstellen. Das ist ja dann damit tot. Es kann ja nicht Sinn der Sache sein, dass nun viele abgemahnt werden, die noch 3.5 haben und zeitlich oder technisch noch nicht umstellen können und sich darauf verlassen haben, dass man es bis Mitte 2019 nutzen kann.
Jo, am besten wäre ne Textarea mit TinyMCE, haben wir im Shopsystem auch so gelöst. Aber vielen Dank auf jeden Fall an Leo, dass er das Thema hier eröffnet hat und eine Liste aufgeschrieben hat, so hat man auf jeden Fall noch mal zusätzliche Erkenntnisse! |
Security Support only. |
|
Das weiß ich. Aber die Wahrscheinlichkeit gehackt zu werden, weil ich 3.5.30 statt 3.5.35 z.B. benutze, ist schätzungsweise 10000 mal geringer als wegen der DSGVO-Geschichte abgemahnt zu werden. Also kurzum: Was bringen mir Sicherheitsupdates, wenn die Seite juristisch massiv angreifbar ist? |
Aber dafür ist trotzdem nicht Contao zuständig, denn auch Contao kann nichts dafür, wenn das Impressum fehlerhaft ist. Wir als Contao können auch nichts dafür, dass sich ein Gesetz ändert. Aber du solltest auch sehen, welcher Aufwand dahinter steckt. Also ich kann Dich schon ein Stück weit verstehen, aber es ist halt verzwickt. |
|
Ich verstehe die Aufregung nicht (3.5). Fast alle von Leo aufgeführten Punkte sind doch im Wesentlichen Default-Werte, die eh schon leicht angepasst werden können. Und wer unbedingt die Checkboxen in den Formularen braucht, kann das doch mit minimalen Änderungen umsetzen oder gleich eine Erweiterung installieren bzw. in Auftrag geben, sofern es diese noch nicht gibt. |
|
@m-vo bei der Kommentar Funktion ist das nicht so leicht machbar. |
Finde ich auch die einfachste Lösung. Findest du, dass so etwas in den core wandern sollte? Oder doch nur per Extension/Eigenentwicklung? |
|
Würde ich sofort einbauen, sollte aber wohl auch in die Anpassung von @frontendschlampe 😉 |
|
kein Problem |
|
Für das Registrierungsformular hat Christian Barkowsky eine Erweiterung erstellt: Wenn es in den Core kommt umso besser. |
|
@Total-Reality und alle anderen: https://github.com/friends-of-contao/contao-privacy helft mit, kommentiert mit, testet mit ... |
|
So, wir haben heute versucht, die notwendigen Änderungen als Bundle umzusetzen (siehe https://github.com/friends-of-contao/contao-privacy). Es ist aber so, dass es keine Möglichkeit gibt, die drei neuen Felder (Kommentare, Newsletter, Registrierung) mittels DCA und Hooks hinzuzufügen. Beim Registrierungsmodul könnte man sich noch mit einem eigenen Widget behelfen, aber in der @aschempp @Toflar Bitte zeigt uns doch zeitnah einen vertretbaren Lösungsweg auf, damit wir das Bundle rechtzeitig fertigstellen können. Andernfalls sehe ich nur die Möglichkeit, dass wir die Änderungen auch für die 4.4 direkt in den Core übernehmen – inklusive SemVer-Verstoß und allen weiteren angedrohten Konsequenzen. |
|
@leofeyer @aschempp @Toflar ich glaube das mit den Kommentaren lässt sich lösen. Man müsste "nur" folgendes machen:
$this->import('Brkwsky\PrivacyConsentBundle\Contao\Comments', 'Comments');
parent::compile();Innerhalb von Allerdings wird das natürlich nicht automatisch für alle Fälle reichen. Wenn jemand bzw. eine Extension auch schon vom |
|
Ich habe jetzt in mehreren Commits (siehe oben) alle DSGVO-Anpassungen für Contao 4.6 implementiert, die laut aktuellem Kenntnisstand erforderlich sind:
Das einzige was definitiv noch brauchen und nicht haben ist die Möglichkeit des Datenexports. Ich habe dazu ein neues Ticket aufgemacht: contao/contao#5648 |
Wie ist das mit den ausstehenden Bestätigungen? Also Interessent meldet sich am Newsletter an, aber bestätigt nicht die DOI-Mail. Sein Eintrag bleibt ewig stehen. Hier wäre es eigentlich sinnvoll, dass der Token irgendwann inaktiv wird (weiß nicht, ob das schon der Fall ist) und dass mit Deaktivierung des Tokens auch der Eintrag gelöscht wird. Ich dachte, es gab dazu schon mal ein Ticket?! Aber es könnte auch sein, dass ich da mit jemandem drüber gesprochen habe. Kann ich Adhoc nicht sagen. Ggfs. müsste man mal noch prüfen, ob wir an anderer Stelle ein ähnliches Verhalten haben (z.B. Kommentare abonnieren). |
|
Guter Punkt. Ich habe entsprechende Cronjobs in contao/comments-bundle@d1cc415 und contao/newsletter-bundle@05f9c68 hinzugefügt. Müssen wir auch Registrierungen löschen, wenn ein Mitglied die Bestätigungsmail nicht anklickt? |
Kann er sich ohne Bestätigung denn anmelden? Wenn ja, dann müsste er irgendwie unbedingt bestätigen oder gewarnt werden, dass er gelöscht wird, wenn er nicht bestätigt. Wenn er sich nicht anmelden kann ohne Bestätigung (also erst wenn er bestätigt hat, kann er sich auch anmelden), dann könnte man ihn einfach löschen. |
Nein, sonst wäre die Bestätigung mit Token ja überflüssig?
Ggf. sollten wir dann aber die Meldungen anpassen (Nachricht mit Gültigkeitsdauer versehen, evtl. Meldung wenn ein ungültiger Link geöffnet wird generischer). |
|
Ich habe einen Cronjob in 0bf62d1 hinzugefügt. |
|
Hat die Mail mit dem Link auch einen Hinweis erhalten, dass dieser nur 24h gültig ist? Die Crons werden ja i.d.R. nur ausgeführt, wenn die Seite regelmäßig aufgerufen wird. |
|
Grundsätzlich obliegt es dem Redakteur, den Text der Mail anzupassen. Ich habe trotzdem einen entsprechenden Hinweis ergänzt.
Du solltest wenn möglich einen echten Cronjob einrichten und Dich nicht auf den Poor Man's Cron verlassen. |
|
Da zwischenzeitlich einige Monate vergangen sind, wäre es aus meiner Sicht nochmals sinnvoll zu prüfen, welche Datenschutz-Features künftig in den Contao Core übernommen werden sollten. Wenn mittlerweile Einigkeit darüber besteht, dass IP-Adressen (ohne zwingenden Grund) max. 7 Tage gespeichert bleiben dürfen, warum muss die entsprechende Lösch-Option bei den Kommentaren dann in einen externen Cronjob ausgelagert werden? Wäre es nicht sinnvoll, die Anregungen aus diesem Ticket in den Contao Core zu übernehmen? friends-of-contao/contao-privacy#20 Zudem wäre es wahrscheinlich nicht verkehrt, alle Core Features, die automatisch und ohne Hinweis / Widerspruchsmöglichkeit Kommunikationsdaten eines Nutzers an externe Quellen senden, einzubremsen. Ich denke hierbei bspw. an den optionalen Splash-Screen für YouTube oder Vimeo Videos vor deren tatsächlicher Einbettung. |
Beachte bitte dass vielleicht in Deutschland Einigung besteht. Oder vielleicht in der EU (was ich sehr stark bezweifle). Aber Contao wird weltweit eingesetzt, und vielleicht nicht alle wollen entsprechende Information gelöscht haben! |
Unabhängig davon, ob sich die deutsche Rechtsprechung auf europäischer Ebene durchsetzen wird, geht es in dem zitierten Beitrag nicht unbedingt darum, 7 Tage als feste Löschfrist für alle Contao Nutzer zu hinterlegen, sondern darum, über Contao einen manuellen oder automatisierten Zugriff auf die Speicherdauer dieser Daten zu erhalten. Es gibt in den Einstellungen bereits einige Speicherfristen (bspw. Logs, Versionen, Session), die individuell definiert werden können. |
Trotz der aktuell nicht gegebenen Rechtssicherheit in Bezug auf die DSGVO gibt es Maßnahmen, die wir umsetzen können, um den Datenschutz in Contao zu verbessern (Stichwort "Privacy by Design").
Was zu tun wäre
Die Einstellung "Google Analytics anonymisieren" in den Backend-Einstellungen kann weg. Stattdessen sollte die Anonymisierung im Template fest vorgegeben sein.
Auch im Piwik-Template sollte die Anonymisierung standardmäßig aktiv sein.
Bei den Elementen "YouTube" und "Vimeo" sollte der Datenschutz-Modus standardmäßig aktiv sein.
Bei der Registrierung sollten wir optional die Möglichkeit bieten, dass eine Datenschutzerklärung akzeptiert werden muss (siehe DSGVO und die Registrierung #1491). Technische Umsetzung: Ein Page-Picker-Feld, mit dem man die Datenschutz-Seite aus der Seitenstruktur auswählen kann.Beim Newsletter-Abonnement sollten wir optional die Möglichkeit bieten, dass eine Datenschutzerklärung akzeptiert werden muss (siehe Add a checkbox for module newsletter subscribe #1499).Beim Kommentieren sollten wir optional die Möglichkeit bieten, dass eine Datenschutzerklärung akzeptiert werden muss (siehe DSGVO-Anpassungen #1512 (comment)).Ergänzung des Standard-Textes für das Opt-In beim Newsletter-Abonnement um einen Hinweis auf jederzeitige Küdigung (Opt-Out)
Was wir bereits haben
Die Session-Cookies speichern keine personenbezogenen Daten.
Die IP-Adressen im System-Log werden anonymisiert (aber Achtung: zur gezielten Sperrung eines Angreifers muss dessen vollständige IP-Adresse bekannt sein -> berechtigtes Interesse).
Die Log-Einträge werden nur 14 Tage lang vorgehalten.
Das FE-Modul "Konto löschen" ermöglicht es einem Mitglied, sein Konto zu löschen.
Die Registrierung erfolgt mittels Double Opt-In (sofern aktiviert).
Assets wie MooTools oder jQuery können lokale geladen werden anstatt von einem CDN.
Was jeder selbst tun muss
Anpassung der Datenschutzerklärung
AV-Vertrag mit Google abschließen falls Google Analytics genutzt wird
Was noch zu diskutieren wäre
Die Verwendung von Google Webfonts ist aktuell offenbar noch nicht DSGVO-konform möglich, daher könnten wir einen Hinweis im Backend anzeigen, wenn Google Webfonts genutzt werden.Ggf. sollten wir den Export aller zu einem Nutzer gespeicherten Daten anbieten. Leider gibt es noch keinen einheitlichen Standard zur Datenportabilität (siehe https://stiftungdatenschutz.org/themen/datenportabilitaet/), daher könnten wir vorerst nur ein proprietäres Format nutzen.
Umsetzung
Die Punkte, die nicht diskutiert werden müssen, können wir direkt in Contao 4.6 implementieren. Die Änderungen müssen dann im Rahmen eines Bundles für Contao 4.4 und 4.5 zurückportiert werden.
Gibt es eurerseits weitere Hinweise?
The text was updated successfully, but these errors were encountered: