New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log-Einträge / IP-Anonymisierung #96
Comments
Hallo @birdmedia , prinzipiell sehen wir von einer Einstellung in der Systemwartung ab, da wir oft die Erfahrung gemacht haben, dass diese gerne komplett geleert werden, obwohl nur eine Checkbox angehakt werden sollte (Unbeabsichtigter Verlust - DSGVO Artikel 5 Paragraph 1). Die Einwilligungen lassen sich derzeit nur über das Log in der Cookiebar-Verwaltung im Backend über Mehrfachauswahl löschen. Eine Anonymisierung gibt es schon und lässt sich über die config.yml ausschalten: Sofern die Cookiebar schon vor Einführung der Anonymisierung installiert wurde (Anfang 2021), lassen sich die bereits bestehenden Log-Einträge über die Kommando-Zeile anonymisieren: Dies dient nicht als Grundlage einer Rechtsberatung, hier sollten Sie für die Richtigkeit einen Anwalt kontaktieren:https://github.com/oveleon/contao-cookiebar#user-content-%EF%B8%8F Auszug aus der Datenschutzgrundverordnung Artikel 5
Und hier ein weiterer Eintrag bezüglich Einwilligungen: |
Vielen Dank für das Feedback. Ich sehe den grundsätzlichen Nutzen der Funktion, wenn ich aber bspw. eine Website betreibe, welche ausschließlich die zwei technisch notwendigen Session Cookies von Contao setzt, kann das Log schnell zu einer "Datenmüllhalde" ohne jeglichen Mehrwert werden. Inwieweit die IP-Anonymisierung der letzten Ziffer eine "Beschränkung auf das notwendige Maß" darstellt, kann ich nicht beurteilen. Ich fände es praktisch, wenn man per Checkbox pro Cookiebar entscheiden könnte, ob die Logging-Funktion aktiviert werden soll. Das würde nur einen minimalen Anpassungsaufwand darstellen. Zudem wäre es praktisch, wenn man ergänzend zur IP-Anonymisierung über Symfony ggf. auch die Kürzung auf 2 Stellen oder 0.0.0.0 als Option auswählen könnte. |
In that case you should evaluate whether you need to or even should collect consent in the first place. |
Ja, auch das ist ein Punkt, der in der Praxis bisher jedoch völlig unterschiedlich ausgelegt wird. Mir ging es um die Fragestellung, ob durch das Logging nicht eine zusätzliche Datenschutz-Baustelle eröffnet wird, da personenbezogene Daten auf Vorrat gesammelt werden, obwohl dies (evtl. im Widerspruch zu Dokumentationspflichten) gar nicht in allen Fällen in dem gegebenen Umfang erforderlich ist. Daher auch die Frage, ob man die Speicherung nicht optional anbieten sollte, unabhängig von den Inhalten des Datensatzes. Zudem stellt sich bei einer Speicherung ohne zeitliche Begrenzung die Frage, wie lange die Verhältnismäßigkeit der Maßnahme gegeben ist. Die gesammelten Datensätze nach mehreren Jahren manuell löschen zu müssen, stellt je nach Projekt auch in 500er-Schritten keine optimale Lösung dar. Grundsätzlich bezieht sich der datenschutzrechtliche Ansatz auch nicht nur auf Cookies alleine, weshalb bspw. auch das Token aus dem Local Storage als technisch notwendiger Eingriff auf dem Gerät des Nutzers / der Nutzerin gesehen werden kann, was entsprechende Dokumentationspflichten erfordern würde. |
Technisch notwendige CookiesHier würde ich auf folgenden Beitrag verweisen:
Laut Paragraph 25 Absatz 2 des TTDSG:https://www.gesetze-im-internet.de/ttdsg/__25.html
Sofern also nur technisch notwendige Cookie genutzt werden, ist derzeit keine Einwilligung, somit auch keine Cookiebar notwendig. Speicherung der EinwilligungenLaut Paragraph 25 Absatz 1 des TTDSG:https://www.gesetze-im-internet.de/ttdsg/__25.html
VERORDNUNG (EU) 2016/679 DES EUROPÄISCHEN PARLAMENTS UND DES RATES vom 27. April 2016 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten, zum freien Datenverkehr und zur Aufhebung der Richtlinie 95/46/EG (Datenschutz-Grundverordnung)https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=celex%3A32016R0679 Absatz 42:
"Zudem stellt sich bei einer Speicherung ohne zeitliche Begrenzung die Frage, wie lange die Verhältnismäßigkeit der Maßnahme gegeben ist. Die gesammelten Datensätze nach mehreren Jahren manuell löschen zu müssen, stellt je nach Projekt auch in 500er-Schritten keine optimale Lösung dar." Hier stimme ich dir zu. Eine Möglichkeit der Speicherdauer der Cookies mit nachfolgender Löschung der Einträge im Einwilligungslog (Nach Ablauf der Zeit) ist auf jeden Fall ein gutes Feature. Wie lange die Einwilligungen derzeit gespeichert werden müssen ist aber noch unklar. |
Vielen Dank für die Erläuterungen, welche ich als rechtlichen Rahmen für die Erweiterung absolut nachvollziehen kann. Wie bereits geschrieben, ist im Zweifelsfall immer alles eine Frage der Verhältnismäßigkeit, weshalb ich die bisherige Umsetzung auch nicht kritisieren will, sondern lediglich überlege, welche Modifikationen sinnvoll sein könnten, ohne dabei in Nischenthemen abzudriften. Ich fasse die Punkte in einer Feature-Wunschliste zusammen und evtl. lässt sich das ein oder andere Themen umsetzen:
Danke für die Zeit, die Du in diese Erweiterung steckst! |
Ich denke, für Punkt 1 sollte keine Cookiebar eingesetzt werden, ein Störer/Overlay/Popup sollte hier genügen. Die Punkte 2-4 sind abhängig von der Gesetzeslage, sollte es hier neue Erkenntnisse geben, kannst du uns diese gerne mit Quelle zur Verfügung stellen und das Ticket erneut öffnen. Sollten entsprechende Anpassungen notwendig sein, würden wir diese natürlich berücksichtigen wollen. Vorerst werden wir aus besagten Gründen allerdings keine der genannten Punkte umsetzen. |
Hallo und vielen Dank für diese sehr praktische Erweiterung.
Ist eine Einstellung geplant, über welche sich die Erstellung von Logs in der tl_cookie_log
insgesamt oder pro Cookiebanner aktivieren / deaktivieren lässt? Zudem wäre es hilfreich, die tl_cookie_log über die Systemwartung bzw. das BE vollständig leeren zu können.
Ergänzend wäre es optimal, wenn man hinsichtlich der IP-Adresse größeren Einfluss auf den Grad der Anonymisierung bzw. die Speicherung (ja / nein) nehmen könnte.
The text was updated successfully, but these errors were encountered: