search

contao / core-bundle

[READ-ONLY] Contao Core Bundle
GNU Lesser General Public License v3.0
123 stars 58 forks source link

DSGVO-Anpassungen #1512

Closed leofeyer closed 6 years ago

leofeyer commented 6 years ago

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

Was wir bereits haben

Was jeder selbst tun muss

Was noch zu diskutieren wäre

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?

aschempp commented 6 years ago
ausi commented 6 years ago

Bei der Registrierung sollten wir optional die Möglichkeit bieten, dass eine Datenschutzerklärung akzeptiert werden muss (siehe contao/core-bundle#1491). Technische Umsetzung: Ein Page-Picker-Feld, mit dem man die Datenschutz-Seite aus der Seitenstruktur auswählen kann.

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.

bezin commented 6 years ago

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)

frontendschlampe commented 6 years ago

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.

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.

Die Datenschutz-Version bei YouTube/Vimeo sollte ja mit dem Pull-Request von @frontendschlampe sowieso kommen, die Checkbox kann man da aus meiner Sicht defaultmässig aktivieren (aber ein deaktivieren sollte möglich sein).

Yep ... hatten wir vorgesehen, aber da bleibt die Frage wegen der Rückportierung auf 4.4

Bei den Elementen "YouTube" und "Vimeo" sollte der Datenschutz-Modus standardmäßig aktiv sein.

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.

Warum sollten wir die Checkbox zur IP-Anonymisierung entfernen? Sie ist doch bereits standardmässig aktiv? Ich bin einverstanden dass es eigentlich in's Template gehört (dass man eh anpassen muss um ne ID rein zu schreiben), aber was passiert mit bestehenden Templates wenn der Wert nicht mehr da ist?

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 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.

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.

Assets wie MooTools oder jQuery können lokale geladen werden anstatt von einem CDN.

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?!

stefan-at-work commented 6 years ago

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. siehe hier (Abschnitt Kommentarfunktion): https://datenschmutz.net/dsgvo-checkliste-fuer-blogs/

Toflar commented 6 years ago

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.

ausi commented 6 years ago

@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... 😕

Toflar commented 6 years ago

Das verkompliziert die Sache halt etwas, aber ich denke es wäre immer noch machbar. Kannst ja helfen 😄

fritzmg commented 6 years ago

Bei den Elementen "YouTube" und "Vimeo" sollte der Datenschutz-Modus standardmäßig aktiv sein.

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.

aschempp commented 6 years ago

@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.

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

Total-Reality commented 6 years ago

Was ist denn mit Contao 3.5? Wir haben noch nicht alle Kunden auf 4.4 umgestellt.

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. Oder auf der anderen Seite kann es ja nicht sein, dass nun jeder selbst noch was in die Core-Erweiterungen Newsletter und Comments hinein programmieren muss. Weitere Alternative wäre, dass man die Registrierung, Kommentare, Newsletter usw. komplett abschaltet. Super, dann kann man einige Websites auch gleich fast Offline nehmen :D

"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."

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!

bytehead commented 6 years ago

Und 3.5 hat ja noch Support bis Mitte 2019.

Security Support only.

Total-Reality commented 6 years ago

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?

frontendschlampe commented 6 years ago

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.

m-vo commented 6 years ago

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.

fritzmg commented 6 years ago

@m-vo bei der Kommentar Funktion ist das nicht so leicht machbar.

fritzmg commented 6 years ago

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

Finde ich auch die einfachste Lösung. Findest du, dass so etwas in den core wandern sollte? Oder doch nur per Extension/Eigenentwicklung?

aschempp commented 6 years ago

Würde ich sofort einbauen, sollte aber wohl auch in die Anpassung von @frontendschlampe 😉

frontendschlampe commented 6 years ago

kein Problem

planepix commented 6 years ago

Für das Registrierungsformular hat Christian Barkowsky eine Erweiterung erstellt: https://github.com/christianbarkowsky/contao-privacyconsent-bundle

Wenn es in den Core kommt umso besser.

frontendschlampe commented 6 years ago

@Total-Reality und alle anderen:

https://github.com/friends-of-contao/contao-privacy helft mit, kommentiert mit, testet mit ...

leofeyer commented 6 years ago

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 Comments-Klasse sind die Eingabefelder hartcodiert.

@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.

fritzmg commented 6 years ago

@leofeyer @aschempp @Toflar ich glaube das mit den Kommentaren lässt sich lösen. Man müsste "nur" folgendes machen:

  1. Eine neue Comments Klasse bauen, die die Anforderungen erfüllt.
  2. Von allen Modulen/Inhaltselementen ableiten, die $this->import('Comments') verwenden (das wären ModuleEventReader, ContentComments, ModuleComments, ModuleFaqReader, ModuleNewsReader) und die ursprünglichen Module/Inhaltselemente im DCA ersetzen.
  3. Die compile() Methode überschreiben mit folgendem Inhalt: 
    $this->import('Brkwsky\PrivacyConsentBundle\Contao\Comments', 'Comments');
parent::compile();

    Innerhalb von parent::compile() wird zwar nochmals $this->import('Comments') ausgeführt - das macht jedoch nichts, da diese Methode nur dann das Comments objekt instanziert, wenn es noch nicht vorhanden ist (sofern man es nicht über einen parameter forciert) - und in diesem Fall haben wir ja für 'Comments' schon eine Instanz vom Typ Brkwsky\PrivacyConsentBundle\Contao\Comments.

Allerdings wird das natürlich nicht automatisch für alle Fälle reichen. Wenn jemand bzw. eine Extension auch schon vom ModuleNewsReader ableitet bspw. mit einer eigenen compile() Methode, muss dort dann natürlich auch die richtige Comments Klasse verwendet werden.

joke1 commented 6 years ago

Bzgl.

Bei der Registrierung sollten wir optional die Möglichkeit bieten, dass eine Datenschutzerklärung akzeptiert werden muss [...]

und den anderen Checkbox-Einwilligungen könnte ggf. noch überlegt werden, es anders herum zu machen & die Checkbox in den Modul-Einstellungen als Standard zu aktivieren. Macht sich gut beim Thema Privacy by default & Privacy by design und könnte zusätzlich ein gutes Aushängeschild für Contao sein.

leofeyer commented 6 years ago

Die genauerer Beschäftigung mit dem Thema offenbart auch, wie sinnlos die aktuellen Einstellungen bezüglich der IP-Anonymisierung sind. Der einzige Grund warum wir die IP-Adresse überhaupt Speichern ist ja, damit wir a) Angreifer gezielt sperren und b) die Verfasser von beleidigenden Kommentaren verfolgen können.

Beides geht genau nicht, wenn man von Anfang an den letzten Block auf Null setzt! Da könnten wir die IP-Adressen auch genauso gut ganz weglassen.

Sinnvoll wäre ein Cronjob, der die vollständig gespeicherten IP-Adressen automatisch nach eine bestimmten Zeitraum (z.B. 7 Tagen) anonymisiert. Das müsste nach allgemeiner Ansicht DSGVO-konform sein und die Speicherung der IP-Adressen würde wieder den eigentlichen Zweck erfüllen.

zonky2 commented 6 years ago

@aschempp

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

ggf. vor und nach dem <img> ein <noscript> mit einem <a ... target="_blank"> und direkte Verlinkung zu YT als Fallback, wenn JavaScript nicht da/nicht geht...

davidmaack commented 6 years ago

Müssten nicht auch nicht bestätigte Registrierungen, also wenn der User den Aktivierungslink nie anklickt wurde, nach einer gewissen Zeit gelöscht werden? Einige Datenschutzbeauftrage sehen das so, das die Zweckbindung zur Datenspeicherung nicht gegeben ist, der Account ist ja de facto nicht benutzbar.

zonky2 commented 6 years ago

Sammelposting mit Erweiterungen: https://community.contao.org/de/showthread.php?70804-DSGVO-Erweiterungen

Sascha07 commented 6 years ago

Das Akzeptieren einer Datenschutzerklärung scheint nicht immer sinnvoll -> https://www.datenschutz-guru.de/datenschutzhinweise-bei-der-registrierung-im-online-shop/

Gilt nicht nur für Online-Shops.

Einfache Möglichkeit zur Kenntnisnahme wohl besser...

zonky2 commented 6 years ago

vom Wettbewerb: WP DSGVO https://www.golem.de/news/datenschutz-wordpress-unterstuetzt-anforderungen-der-dsgvo-1805-134471.html

backbone87 commented 6 years ago

Wir haben jetzt bzgl. der DSGVO Umsetzung für Kommentare eine ganze Menge Möglichkeiten evaluiert und sind mit keiner wirklich zufrieden. Ein Hook um das (ad-hoc zusammengesetzte) DCA für das Kommentar-Formular anpassen zu können wäre extrem hilfreich. Ungefähr an dieser Stelle: https://github.com/contao/comments-bundle/blob/master/src/Resources/contao/classes/Comments.php#L245 Dies würde die Umsetzung extrem vereinfachen, wenn dieser Hook für die 3.5 und ab 4.4 noch hinzufügt werden könnte. Im Prinzip ist dies auch ein Bugfix, da sich die Kommentarfunktion fast überhaupt nicht DSGVO konform umbauen ließe ohne alle Reader-Module zu erweitern und eine eigene Comments-Klasse zu erstellen (vgl. Ansatz von @fritzmg)

Toflar commented 6 years ago

Ich bin ja gegen Features in aktuellen LTS-Versionen aber Hooks wären im vorliegenden Fall vertretbar. Bereite mal einen entsprechenden PR vor mit allen Hooks die du brauchst, dann kann man sich das mal konkret ansehen.

Sascha07 commented 6 years ago

Zwei-Klick-Lösung zur DSGVO-konformen Einbettung von YouTube- und Vimeo-Videos.

https://github.com/a-v-l/dsgvo-video-embed

backbone87 commented 6 years ago

@Toflar ich hab ein PR für contao 3.5 erstellt. sobald der aktzeptiert wurde, würde ich auch einen für 4.4 bereitstellen. (allerdings kann ich kein composer update für das contao/comments-bundle machen, weil kein provider für php-http/client-implementation required wird?)

aschempp commented 6 years ago

@backbone87 wenn die Änderung in 3.5 auch in 4.4 passt musst du keinen zweiten PR machen, es wird ja Upstream gemergt.

kroerig commented 6 years ago

Welche der o.g. Anpassungen sind denn jetzt schon umgesetzt? Und in welcher Version verfügbar?

leofeyer commented 6 years ago

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

frontendschlampe commented 6 years ago
  • Zum Nachweis eines Opt-Ins speichern wir die IP-Adressen bei Newsletter-Abonnement und Kommentar-Abonnements vollständig zusammen mit den anderen personenbezogenen Daten wie z.B. der E-Mail-Adresse.

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).

zonky2 commented 6 years ago

@frontendschlampe https://github.com/contao/core-bundle/issues/1512#issuecomment-390135878

leofeyer commented 6 years ago

Guter Punkt. Ich habe entsprechende Cronjobs in contao/comments-bundle@d1cc415df67504d03febb6115877fe979337b644 und contao/newsletter-bundle@05f9c6821bd3b454c5a6c107ba6dfc6d2f4b5a50 hinzugefügt. Müssen wir auch Registrierungen löschen, wenn ein Mitglied die Bestätigungsmail nicht anklickt?

frontendschlampe commented 6 years ago

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.

m-vo commented 6 years ago

Kann er sich ohne Bestätigung denn anmelden?

Nein, sonst wäre die Bestätigung mit Token ja überflüssig?

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.

Ggf. sollten wir dann aber die Meldungen anpassen (Nachricht mit Gültigkeitsdauer versehen, evtl. Meldung wenn ein ungültiger Link geöffnet wird generischer).

leofeyer commented 6 years ago

Ich habe einen Cronjob in 0bf62d1bf1245f0494d4ca11532157f1897fdc0b hinzugefügt.

kroerig commented 6 years ago

Hat die Mail mit dem Link auch einen Hinweis erhalten, dass dieser nur 24h gültig ist? Und wie wird sichergestellt, dass die Links auch nur 24h lang funktionieren, und die offene Registrierung auch sicher gelöscht wird?

Die Crons werden ja i.d.R. nur ausgeführt, wenn die Seite regelmäßig aufgerufen wird.

leofeyer commented 6 years ago

Grundsätzlich obliegt es dem Redakteur, den Text der Mail anzupassen. Ich habe trotzdem einen entsprechenden Hinweis ergänzt.

Die Crons werden ja i.d.R. nur ausgeführt, wenn die Seite regelmäßig aufgerufen wird.

Du solltest wenn möglich einen echten Cronjob einrichten und Dich nicht auf den Poor Man's Cron verlassen.

birdmedia commented 5 years ago

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? https://github.com/friends-of-contao/contao-privacy/issues/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.

aschempp commented 5 years ago

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?

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!

birdmedia commented 5 years ago

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.