Contao - Setzen von Cookies verhindern / DSGVO + ePrivacy 2018

Hallo,

Contao setzt standardmäßig "Sessions Cookies" beim Aufruf einer Website ein und über externe Erweiterungen je nach Anwendungsfall ggfs. auch "Persistent Cookies", welche dauerhaft (bis zur Löschung) im Browser gespeichert werden.

Es gibt mittlerweile zahlreiche Erweiterungen, über welche ein "Cookie Hinweis" oder eine "Cookie Bar" mit individuellen Texten eingeblendet werden können, diese haben aber nur Informationscharakter und keinen technischen Einfluss. Nach DSGVO und ePrivacy-Verordnung ist aus meiner Sicht noch nicht ganz klar, ob künftig ein Opt-Out für Cookies ausreicht bzw. ob in der Nutzung zwischen "Session Cookies" und "Persistent Cookies" von Drittanbietern unterschieden wird. Selbst eine Cookie Bar benötigt ein Cookie, um den Status der Einblendung zu speichern, weshalb die Thematik natürlich irgendwie widersprüchlich ist.

Könnte man das Setzen von temporären (Core) Cookies in Contao irgendwie praktikabel und erweiterungssicher verhindern? Würde sich ggfs. auch das Setzen von weiteren Cookies per Opt-In steuern lassen? Dienste wie cookiebot.com bieten hierfür anscheinend eine externe Lösung.

Soweit ich die neue Verordnung interpretiere, sind Session Cookies ohne Einwilligung des Benutzers erlaubt, sofern das Session Cookie für die Benutzung der Website unbedingt erforderlich ist. Hier wird die Differenzierung schwierig.

Zitat:

---

Zitat von Spooky

Soweit ich die neue Verordnung interpretiere, sind Session Cookies sind ohne Einwilligung des Benutzers erlaubt, sofern das Session Cookie für die Benutzung der Website unbedingt erforderlich ist. Hier wird die Differenzierung schwierig.

---

Ja, es gibt leider eine Menge Lücken und Unklarheiten in den Formulierungen, was evtl. auch so gewollt ist. Zudem ist der Beratungsprozess anscheinend auch noch immer im Fluss, weshalb sich (noch) keine konkreten technischen Vorgaben / Maßnahmen ableiten lassen. Aus diesem Grund wäre es natürlich gut, wenn man mit dem System zumindest theoretisch flexibel auf verschiedene Szenarien reagieren könnte. Wäre der Einsatz von Session Cookies z.B. plötzlich wettbewerbsrechtlich abmahnfähig, würde sich ein größeres Problem ergeben.

Leider wird das Thema "Privacy by Design" meinem Empfinden nach bei Contao momentan kaum beachtet oder diskutiert. Das betrifft bspw. auch die standardmäßige Speicherung von personenbezogenen Daten in den Log-Files oder DB-Einträgen.

Hallo,

bei der Wirtschaftskammer Österreich habe ich dazu folgendes gefunden:
https://www.wko.at/service/unternehm...nd-Cookies.pdf

Unter Punkt 5 heißt es, das Setzen eines Cookies ist ohne Einwilligung zulässig nach dem Ausnahmetatbestand des § 96 Telekommunikationsgesetz (TKG) (für Österreich, aber ich denke in DE wird es ähnlich sein), wenn es für die Erbringung des vom Benutzer gewünschten Dienstes unbedingt erforderlich ist.

Am Beispiel eines Onlineshops, können mehere Waren ohne Cookies z.B. nicht in den Warenkorb abgelegt werden.

Nur bezogen auf die DSGVO habe ich leider nichts gefunden, bzw. eine äquivalente Ausnahme/Aussage in Verbindung mit dem deutschen TKG. Vielleicht findet sich da ja noch etwas.

Bezogen auf die Grundfrage, ob das setzen von Cookies verhindert/gesteuert werden kann, habe ich ebenfalls festgestellt, dass bereits bei normalen Seitenaufrufen eine SessionID erstellt wird. Um nun bei einer einfachen Webseite ohne Webshop/Warenkorb gegenüber dem TKG konform zu bleiben, wäre es nicht auch möglich die SessionID erst beim Login zu setzten.
Und wenn nicht, welche technische Begründung gibt es für die SessionID, die schon beim betreten der Webseite erstellt wird? (Z.B. für Formulare?)

Danke und beste Grüße
christophK

Ahoi,

zu dem Thema gab es vor ein paar Tagen schon einmal eine lebhafte Diskussion.
Ich verlinke hier einfach mal den letzten Beitrag von @lucina, der meiner bescheidenen Meinung nach das ganze Ding auf den Punkt bringt ;)
https://community.contao.org/de/show...l=1#post464707

--
das Internet wurde konzipiert um einen Atomschlag zu überstehen - aber an Juristen hat damals keiner gedacht ... :cool:

Oh, okay. Den Beitrag habe ich schon gelesen. Auch die Hinweise über das Hinzuziehens eines RA.
Ich wollte eigentlich nur wissen, aus technischer Sicht wozu die SessionID schon beim betreten der Webseite erstellt wird. Ich denke das wird hier nicht beantwortet. Inwieweit ich das dann nun mit der WKO und/oder einem RA auf Konformität abkläre, lasse ich eh bei mir. Trotzdem danke für den Link. :)

Zitat:

---

Zitat von christophK

Ich wollte eigentlich nur wissen, aus technischer Sicht wozu die SessionID schon beim betreten der Webseite erstellt wird.

---

Das würde mich auch interessieren. Ohne Shop, ein mehrseitiges Formular oder den Sprachwechsler gibt es m. E. keinen zwingenden Grund für den Einsatz eines temporären Session Cookies. Vielleicht könnte man irgendwo dokumentieren, wie man das Setzen des Session Cookies in Contao 3.5.x und 4.x am saubersten deaktivieren kann.

Auch wenn rechtlich wahrscheinlich zwischen temporären Session Cookies und Persistent Cookies unterscheiden wird, sollte man künftig trotzdem relativ sparsam mit deren Einsatz umgehen. Siehe hierzu http://eur-lex.europa.eu/legal-conte...EX:52017PC0010 (Blatt 20, Nr. 21 und 22)

Wie das Thema künftig bei Tracking Cookies (bspw. Google Analytics) mittels Opt-In zu handhaben ist, steht noch auf einem ganz anderen Blatt. Wahrscheinlich werden die technischen Details auch erst mit Einführung der ePrivacy-Verordnung im Detail definiert.

Ich teile deine Meinung bird. Ich würde in Zukunft auch gerne sehr sparsam mit Cookies umgehen, und wenn ich sie einsetzte, möchte ich wissen wofür.

Das hat auch gestalterische Auswirkungen. Kommt eine Webseite ohne Cookies aus, muss ich mich erst gar nicht der Frage stellen, ob ich im Sinne der DSGVO darauf hinweisen muss oder Banner schalten muss. Und kommt die Seite ohne Cookies nicht aus, kann ich dies mit dem RA/WKO durchsprechen und gegebenenfalls auf der Datenschutzerklärung darauf hinweisen warum der Cookie gebraucht wird.

Die meisten Äußerungen zum Thema Cookies und DSGVO stützen sich auf Artikel 6, Absatz f):
"die Verarbeitung ist zur Wahrung der berechtigten Interessen des Verantwortlichen oder eines Dritten erforderlich, sofern nicht die Interessen oder Grundrechte und Grundfreiheiten der betroffenen Person, die den Schutz personen* bezogener Daten erfordern, überwiegen"

Ich habe dazu diesen Link gefunden wonach Analytic-Tools ohne opt-it erlaubt sind, auch nach der e-privacy:
https://www.kloos.at/blog/google-ana...undverordnung/

Bei der Verwendung von Cookies im allgemeinen nach will man sich hier allerdings nicht festlegen:
https://www.it-recht-kanzlei.de/cook...l#abschnitt_22

Sind wir also wieder bei dem Punkt: Nehmt euch einen Rechtsanwalt.

Ich würde allerdings gerne mit der technischen Information in das Gespräch gehen, wofür dieser Cookie nun gebraucht wird, da es dann ja auch sein kann, dass Artikel 6, Absatz f gar nicht zu tragen kommt, wenn keine Sprachenwechsler und keine mehrseitigen Formulare zum Einsatz kommen. Dann bräuchte ich womöglich einen unnötigen opt-in für einen unnötigen cookie. :D

Gruß
Christoph

Hier gibt es auch einen lesenswerten Artikel dazu: https://www.onlinehaendler-news.de/r...9-cookies.html
Die ePrivacy-Verordnung könnte dies also wieder kippen. Allerdings kommt die nun nicht vor Mitte 2019, weshalb man ggf. nur eine Lösung für drei Jahre benötigt (2 Jahre Übergangsfrist).

Langfristig gesehen wird es wahrscheinlich eher wieder gelockert & ich vermute, dass die Industrie in der Übergangszeit nicht ihre Geschäftsmodelle aufgeben wird. Das ist inzwischen auch der Regierung und der EU klar geworden, da diese dann auch zu den Verlierern gehören. Glaube also nicht, dass hier in der Zwischenzeit so hart von den Aufsichtsbehörden durchgegriffen wird (nur im Bezug auf die Cookies - bei vielen Themen der DSGVO wurde bereits angekündigt, dass hart durchgegriffen wird - auch bei den KMU). Sind natürlich alles nur Vermutungen, die sich auch als falsch heraus stellen können. Von daher sollten Betroffene da in jedem Fall einen Anwalt zu rate ziehen (auch wenn einige selber noch viele Fragezeichen sehen).

Grundsätzlich wäre ich aber auch dafür, dass Contao Privacy by Default & by Design größer schreiben würde. Viele Freelancer und Agenturen werden sicherlich Anfragen von Kunden bekommen, wieso deren kleine Seite ohne Shop oder sonstiger Logik einen Cookie setzt. Meiner Meinung nach eine berechtigte Frage.

Sehe ich auch so, falls es keine zwingende Notwendigkeit gibt, den Session-Cookie auch bei Seiten ohne mehrseitige Formulare, Shops, Mitgliederanmeldung etc zu setzen, sollte man ihn deaktivieren können im BE. Mir ist bei Tests mit im Browser deaktivierten Cookies auf mehreren Kundenseiten nichts Negatives aufgefallen.
Ich war letztens bei einem Vortrag zum Thema DSGVO. Es war einigermaßen beunruhigend, in mehrerer Hinsicht. Erstens natürlich die ziemlich drastischen Geldstrafen, dann auch die nicht immer klaren (maßlose Untertreibung :)) Formulierungen, die fast mehr Fragen aufwerfen als sie beantworten. Und zum Schluss noch die unangenehme Vorstellung, dass Abmahnkanzleien und zur Abmahnung berechtigte Vereine bereits mit den Hufen scharren. Und ja, auch für Rechtsanwälte ist es derzeit nicht klar, was im Detail noch erlaubt ist und was nicht. Wie immer bei solchen Gesetzesänderungen wird man das wohl erst nach höchstinstanzlichen Entscheidungen wissen. Bis dahin kann man potenziell schon eine ganze Menge Strafe und Kosten aus Abmahnungen bezahlt haben. Also im Zweifel auf Nummer sicher gehen und einen Rechtsanwalt mit einer guten Glaskugel hinzuziehen.

Technisch hat das wohl auch mit dem Thema zu tun, das hier diskutiert wurde (Stichworte "So what now?" und "What would be the right solution?"). Sehe ich das richtig?

Ich würde dringend darum bitten optional das Session Cookie ausschalten zu können, gerade in dem Wissen das dann auch Google Webfonts und andere Dienste (Matomo) nicht zum Einsatz kommen dürften, da dann wieder der Datenschutzhinweis benötigt wird. (Webserver-Logs ausschalten bzw. IP nicht erfassen)

Im Übrigen sollte der dann notwendige Datenschutzhinweis den Link zum Impressum nicht überdecken.

Dazu musst du hier einen Feature Request machen: https://github.com/contao/core-bundle

Zitat:

---

Zitat von servpoint

Im Übrigen sollte der dann notwendige Datenschutzhinweis den Link zum Impressum nicht überdecken.

---

Was meinst Du damit?

So etwas wie hier: https://alfahosting.de
Cookiebar überdeckt den Datenschutzlink, AGB und Impressum wenn man ganz nach unten scrollt. :D

Zitat:

---

Zitat von christophK

So etwas wie hier: https://alfahosting.de
Cookiebar überdeckt den Datenschutzlink, AGB und Impressum wenn man ganz nach unten scrollt. :D

---

ah jetzt, ja ;)

Wenn ich die Diskussion auf GitHub richtig interpretiere, besteht eine solche Möglichkeit bereits. Wie sieht diese technisch konkret aus? Zumindest die (Core) Cookies, die nicht zwingend für die Funktionalität im FE erforderlich sind, sollten sich irgendwie steuern lassen. Wäre super, wenn es ein Feedback des Core Entwickler-Teams geben würde.

https://github.com/contao/core-bundle/issues/1398

Anhang 20573
Rechts unten.

Zitat:

---

Zitat von christophK

Anhang 20573
Rechts unten.

---

Das ist doch die Sitzungsdauer für BE-User, oder nicht?

Nein, das gilt für beides.

Zitat:

---

Zitat von christophK

Anhang 20573
Rechts unten.

---

Über die Verfallszeit der Session kann ich das Setzen des Cookies aber nicht verhindern. Setzt man diesen Wert auf 0, wird trotzdem ein Cookie gesetzt, es ist jedoch kein Login im BE mehr möglich.

Zitat:

---

Zitat von bird

Über die Verfallszeit der Session kann ich das Setzen des Cookies aber nicht verhindern.

---

Wurde ja auch nicht behauptet. Die Frage auf GitHub war (unter Anderem):

Zitat:

---

It's also a nice idea, to have the posebility of setting expiry dates of the cookies.

---

Nochmal zusammengefasst.

1. Frage: Setzt Contao im Core ohne Erweiterung im FE mehr als den Session Cookie?
   
   • Ja
   • FE_USER_AUTH (Nach einem Login und im Backend zum Aufbau des Suchindexes) [von jk1]
   • FE_AUTO_LOGIN (Nach einem Login mit der "Passwort merken" Funktion) [von jk1]
   • ...
2. Frage: Welche Funktionen hat der Session Cookie im FE? (und gegebenenfalls andere Cookies, sofern es denn welche gibt)
   
   • FE-Login, alle Formulare (auch für einseitige Kontaktformulare), Newsletter
   • (bei den zwei oben genannten Funktionen könnten einfache Seiten daher auch ohne Session Cookie auskommen)
   • Wert = Dateiname des Cookies auf dem Server z.B. tmp/sess_123xyz Inhalte der Datei: z.B. Sprache, CSRF-Token, Captcha-Eingaben, Flashback-Meldungen, sowie Werte aus Erweiterungen und alles andere was über $objSession->set() gesetzt wird [von jk1]
   • ...
3. Frage: Kann der Session Cookie im FE deaktiviert werden? (und gegebenenfalls andere Cookies, sofern es denn welche gibt)
   
   • Nein, derzeit nicht. https://github.com/contao/core-bundle/issues/1398
4. Muss sich der Entwickler einer Erweiterung um die Möglichkeit erweiterter Einstellungen für seine Cookies selber kümmern?
   
   • Diese Frage würde ich jetzt mal mit einem JA beantworten.
   • Die Frage bezog sie auf den ersten Post von bird und die Tatsache, dass nach dem DSGVO die Speicherzeiten von Daten eine westliche Rolle spielen. Die Cookiebar-Erweiterung braucht z.B. zwingend einen Cookie. Siehe Bild. Verfallszeit ist hier auf 1 Jahr gestellt. Nach diesem Link müssen Einverständniserklärung nach einem halben Jahr erneuert werden: https://piwikpro.de/blog/eu-dsgvo-is...iserklaerungen

Zitat:

---

It's also a nice idea, to have the posibility of setting expiry dates of the cookies.

---

war auf Punkt 4 bezogen. Weniger auf die Session.


Anhang 20590

Man muss ja auch nochmal unterscheiden zwischen einem "normalen" Browser-Cookie und einem Session-Cookie.
Die Inhalte des Session-Cookies werden auf dem Server in einer Textdatei gespeichert & die Inhalte der Browser-Cookies in einer Textdatei (Chrome nutzt hier SQLite) auf dem Rechner.


Browser-Cookie:
Contao setzt die Browser-Cookies in der System.php über die Methode "setCookie", welche letztendlich die PHP-Funktion "setcookie" aufruft. Dort gibt es einen Callback/Hook mit gleichem Namen über den ein Entwickler das setzen eines Cookies abfangen könnte. Ein negativer Ablauf würde diesen Cookies also gar nicht erst setzen bzw. bereits gesetzte löschen.

Hier könnte ich mir eine Erweiterung vorstellen, die aus einem Backend-Modul besteht. Als Core-Funktion wäre es sicherlich auch sehr cool. Das könnte ein weiterer Grund für Nutzer sein, auf Contao zu setzen.
Auf jeden Fall könnte man in diesem BE-Modul beliebig viele Einträge erstellen, die aus einem internen Namen und dem eigentlichen Cookie-Key bestehen.
Den Cookie-Key könnte man als Nutzer über den Browser herausfinden. Es könnten aber auch vorgefertigte Keys bereit stehen - ggf. mit Erläuterungen, was dann nicht mehr funktioniert. Die Backend-Cookies sollten wohl abgefangen werden, damit man sich nicht ausschließt.
Über die erwähnte Hook könnte die Erweiterung dann die gespeicherten Cookie-Keys durchgehen. Wenn der geradezu setzende Cookie-Key übereinstimmt, wird der Expire-Parameter auf z.B. time() - 3600 gestellt, was das setzen des Cookies verhindern würde.

Ob Dritt-Entwickler die Contao-Funktion zum Setzen von Cookies nutzen, kann man natürlich nicht immer wissen. Aber das ist ein anderes Thema. Das gleiche gilt natürlich auch für Cookies oder LocalStorage Objekte, die über JavaScript gesetzt wurden.


Session-Cookie:
Diesen nutzt Contao für Formulare, den Frontend-Login oder jegliche andere Logik im Front- und Backend.
Wenn man nun nur noch einen Session-Cookie nutzt, muss aber auch hier der Browser irgendwie erkannt werden, weshalb auch hier ein Cookie bei dem Benutzer/Browser gespeichert wird. Dieser beinhaltet aber nur den Namen "PHPSESSID" mit einer Kennung.
Visitenkarten-Websites oder andere kleine Seiten ohne jeglicher Logik könnten aber auch darauf verzichten.

Der Session-Cookie wird über die PHP-Funktion session_start gesetzt und haut normalerweise auch direkt noch den besagte Cookie raus.
Das ist eigentlich auch super. Einige werden sich noch an Applikationen (z.B. Foren) von früher erinnern, wo dann die Session-ID über Links weitergegeben wurden. Wenn man dann den Link seinem Kumpel gegeben hat, war derjenige unter deiner Identität eingeloggt.

Den Session-Cookie kann man in der app/config/config.yml deaktivieren:

Code:

---

framework:
  session:
    use_cookies: false

---

Damit wäre Contao im Frontend bereits komplett frei von Cookies. Ein Anmelden oder sonstige Logik wird nicht funktionieren, da der Anfrage-Token aus Formularen nicht übertragen werden kann -> Fehlermeldung.
Das ist allerdings eine globale Symfony Einstellung. D.h. ein Login ins Backend ist auch nicht mehr möglich.
Auch wenn Session-Cookies kein Problem für die DSGVO sind, fände ich dies nur für das Frontend ein interessantes Privacy-Feature.
Hierfür müsste aber der Contao-Core entsprechend umgebaut werden.
Und das ist nicht gerade wenig, wenn man danach sucht.

Ich vermute aber auch, dass dies zumindest bis zur neuen e-Privacy Verordnung egal ist.
Ich schreibe "vermute", weil ich kein Anwalt bin & niemand auf mich hören darf. Aber die Quellen [1] [2] sagen genau dies aus.
Ein Session-Cookie ist zwar personenbezogen, aber als Websitebetreiber darf ich diese Daten verarbeiten da sie zur Wahrung der berechtigten Interessen des Verantwortlichen gehören. Ich habe ein berechtigtes Interesse, dass der Nutzer ohne Sicherheitsbedenken meine Formulare nutzen kann. Außerdem werden dadurch keine Interessen, Grundrechte oder Grundfreiheiten des Website-Besuchers verletzt.

Viel mehr würde ich mir Gedanken um die externen Cookies machen. Also weg mit den Youtube-Iframes und Apis. Und raus mit den Social-Plugins. Lieber ein Bild vom Video/Social-Dienst, dass es in einem neuen Fenster öffnet, oder per JavaScript erst aktiviert. In dem Fall muss aber auch die Datenschutzerklärung wasserfest sein. Und über Google-Fonts (oder andere Datensammlerdienste) können wir uns sicher noch ausgiebig in einem anderen Thema unterhalten :D

Zitat:

---

Zitat von jk1

Diesen nutzt Contao für Formulare, den Frontend-Login oder jegliche andere Logik im Front- und Backend.

---

ich hab das mal ergänzt. Vl. finden sich ja noch mehr Infos.

Zitat:

---

Zitat von jk1

Auch wenn Session-Cookies kein Problem für die DSGVO sind, fände ich dies nur für das Frontend ein interessantes Privacy-Feature.

---

ich würde die Interessenabwägung, sofern kein Cookie für die FE-Seite benötigt wird (und das tut er nicht bei einfachen Webseiten ohne mehrseitigen Formularen, FE-Login oder sonstige "Logik im FE") in Richtung der zu schützenden personenbezogenen Interessen abwägen. Kurz: wird der Cookie nicht gebraucht, darf auch keiner gesetzt werden. Nach E-Privacy: https://www.kloos.at/blog/google-ana...undverordnung/ darf in weiterer Folge auch nur dann ein Cookie ohne Einwilligung gesetzt werden wenn es technisch notwendig ist.

Aber auch ich bin kein Anwalt. Die Möglichkeit, nicht benötigte Cookies zu deaktivieren, wäre jedoch ein Schritt in Richtung DSGVO- und E-Privacy-compliance und ein Schritt weg aus dem Graubereich.

Nuja, wenn du es nicht verhindern kannst, dann ist es für dich technisch notwendig, weil sonst keine Website ausgeliefert würde, wenn du Contao deinstallierst. ;)

Aus heutiger Sicht kann ich es nicht verhindern, wenn ich Contao verwende, da hast du recht. Notwendig wäre er für oben genanntes aber nicht zwingend. :D

Zitat:

---

Zitat von jk1

Viel mehr würde ich mir Gedanken um die externen Cookies machen. Also weg mit den Youtube-Iframes und Apis. Und raus mit den Social-Plugins. Lieber ein Bild vom Video/Social-Dienst, dass es in einem neuen Fenster öffnet, oder per JavaScript erst aktiviert. In dem Fall muss aber auch die Datenschutzerklärung wasserfest sein. Und über Google-Fonts (oder andere Datensammlerdienste) können wir uns sicher noch ausgiebig in einem anderen Thema unterhalten :D

---

gerne, ich weiß nur nicht inwieweit dies erwünscht ist siehe:

Zitat:

---

Zitat von Stefko

Ahoi,
zu dem Thema gab es vor ein paar Tagen schon einmal eine lebhafte Diskussion.
Ich verlinke hier einfach mal den letzten Beitrag von @lucina, der meiner bescheidenen Meinung nach das ganze Ding auf den Punkt bringt ;)
https://community.contao.org/de/show...l=1#post464707

---

Das Thema

Zitat:

---

Zitat von tab

Bisher gehe ich davon aus, dass man die Daten nur auf Anfrage auch in maschinenlesbarer Form zur Verfügung stellen muss. Also nicht als Export-Button auf der Website. Zur Verfügung stellen muss man sie ja auf Anfrage auch bisher schon, nur nicht unbedingt in maschinenlesbarer Form.

---

&

Zitat:

---

Zitat von TobiasAlke

Wenn für jede Anfrage ein Mitarbeiter im eigenen Unternehmen tätig werden muss, verliert das CMS seinen Wert in seiner Arbeitserleichterung!
Im CMS klicke ich auf einen Button und es wird in ein paar Sekunden generiert und wenn es erst einer manuell formatieren muss, ist er/sie je nach Kunde zwischen ein paar Minuten oder im Extremfall auch Stunden beschäftigt. Und da Kunden im Login Bereich schon auf ihre Daten Zugangsbeschränkt werden, wieso soll es so kompliziert sein hier einen Exportfilter für eben diese Daten einzurichten!?!

---

ließe sich z.B. sicher über SQL-queries lösen. Passt jetzt nicht daher, an Themen zur Problemlösung gerade in Hinblick auf DSGVO- und E-Privacy-compliance & contao wäre ich aber grundsätzlich interessiert.

Zitat:

---

Zitat von jk1

Den Session-Cookie kann man in der app/config/config.yml deaktivieren:

Code:

---

framework:
  session:
    use_cookies: false

---

---

Danke für den Tipp. Newsletter und Kontaktformulare brauchen auch den Session Cookie. Hab es oben ergänzt.
Bin jetzt schon ganz zufrieden mit den Infos.

Grüße

Zitat:

---

Zitat von christophK

Danke für den Tipp. Newsletter und Kontaktformulare brauchen auch den Session Cookie. Hab es oben ergänzt.
Bin jetzt schon ganz zufrieden mit den Infos.

Grüße

---

Denke daran, dass du dann auch nicht mehr ins CMS kommst. Also wirklich brauchbar ist das nicht unbedingt - es sei denn du hast eine Website "fertig", niemand wird sie aktualisieren & du machst alles dicht. ;)

Zitat:

---

Zitat von jk1

Man muss ja auch nochmal unterscheiden zwischen einem "normalen" Browser-Cookie und einem Session-Cookie.
Session-Cookies werden auf dem Server in einer Textdatei gespeichert & die Browser-Cookies in einer Textdatei auf dem Rechner.

---

<oberlehrer>Cookies werden immer im Browser gespeichert. Was Du meinst sind die zugehörigen Session-Daten, die auf dem Server gespeichert werden. In einem Session-Cookie steht dann "nur" die Session-ID aber keine weiteren Daten.</oberlehrer>

Achso, ist eh wieder draussen. War nur zum testen. :D

Zitat:

---

Zitat von fiedsch

<oberlehrer>Cookies werden immer im Browser gespeichert. Was Du meinst sind die zugehörigen Session-Daten, die auf dem Server gespeichert werden. In einem Session-Cookie steht dann "nur" die Session-ID aber keine weiteren Daten.</oberlehrer>

---

Danke, ist korrigiert.

Glaub so war es nicht gemeint. Alle Cookies werden im Browser gespeichert. Auch der Session Cookie. Am Server werden dann die Informationen zu dem Session Cookie (Session-Daten) gespeichert.

Ja, so habe ich es auch gemeint. Wenn es immer noch unverständlich geschrieben ist, kann ja weitergelesen werden.
Zurück zum Thema:

Zitat:

---

Zitat von christophK

ich würde die Interessenabwägung, sofern kein Cookie für die FE-Seite benötigt wird (und das tut er nicht bei einfachen Webseiten ohne mehrseitigen Formularen, FE-Login oder sonstige "Logik im FE") in Richtung der zu schützenden personenbezogenen Interessen abwägen. Kurz: wird der Cookie nicht gebraucht, darf auch keiner gesetzt werden. Nach E-Privacy: https://www.kloos.at/blog/google-ana...undverordnung/ darf in weiterer Folge auch nur dann ein Cookie ohne Einwilligung gesetzt werden wenn es technisch notwendig ist.

---

Zitat:

---

Zitat von tab

Nuja, wenn du es nicht verhindern kannst, dann ist es für dich technisch notwendig, weil sonst keine Website ausgeliefert würde, wenn du Contao deinstallierst. ;)

---

Das werden mit Sicherheit irgendwann dann mal die jeweiligen Argumente der Anwälte vor Gericht sein ;) Bin gespannt, wie entschieden wird.

Zitat:

---

Zitat von christophK

Frage: Setzt Contao im Core ohne Erweiterung im FE mehr als den Session Cookie?

---

Im Frontend habe ich drei gefunden. Im Backend sind das noch ein paar mehr - aber das ist ja hierfür unwichtig.

• PHPSESSID (Wert = Dateiname des Cookies auf dem Server z.B. tmp/sess_123xyz Inhalte der Datei: z.B. Sprache, CSRF-Token, Captcha-Eingaben, Flashback-Meldungen, sowie Werte aus Erweiterungen und alles andere was über $objSession->set() gesetzt wird)
• FE_USER_AUTH (Nach einem Login und im Backend zum Aufbau des Suchindexes)
• FE_AUTO_LOGIN (Nach einem Login mit der "Passwort merken" Funktion)

Das finde ich eine gute Lösung: https://github.com/ToX82/cookie-bar:

• Cookie-Hinweis
• Cookies akzeptieren
• Cookies akzeptieren oder ablehnen (bei Ablehnung werden alle Cookies - außer Sitzung - sofort nach dem Setzen gelöscht)

Und die Texte lassen sich in den Language files anpassen.

Zitat:

---

Zitat von christophK

Aus heutiger Sicht kann ich es nicht verhindern, wenn ich Contao verwende, da hast du recht. Notwendig wäre er für oben genanntes aber nicht zwingend. :D

---

Nuja, schaun mer mal.... Ich war gerade auf der Seite bfdi.bund.de, das ist die Seite der Bundesdatenschutzbeauftragten. Eine Information, dass Cookies verwendet werden habe ich nicht gesehen (jedenfalls keine Cookie-Bar oder dergleichen, in die Datenschutzerklärung habe ich nicht reingeschaut. Da dachte ich mir: "Schau doch spasseshalber mal nach, ob die Seite ein Cookie setzt". Gedacht, getan. Und tatsächlich, die Seite setzt ein Cookie, das erst gelöscht wird, wenn der Browser geschlossen wird. Also nicht schon nach dem Schliessen des entsprechenden Tabs. Soviel zur Brisanz des Session-Cookies.

Ignoriert sogar die "Do Not Track" Einstellungen.

Anhang 20605

Und wofür sind in Contao nun die Browser-Cookies zuständig?

"Nur" um irgendeine Session ID zu setzen welche wiederum auf die Session-Daten am Server referenziert?

Bedeutet das in der Folge, dass wenn jemand die Browser-Cookies deaktiviert, er dann Formulare, Newsletteranmeldung etc. nicht mehr nutzen kann?

ja

Danke für die Antwort.

Eine Frage noch: Sehe ich das richtig dass Contao (3.5.x) das Session Cookie per default immer setzt und man dieses auch nicht deaktivieren kann (außer auf Clientseite natürlich, aber das meine ich nicht)?

Alle Contao Versionen machen das (bis jetzt), ja.

Ein Session-Cookie ist auch kein Problem. Es beinhaltet lediglich einen Hash. Es geht bei der Verordnung um Tracking Cookies u.a.

Das Thema Cookie-Banner war in Deutschland nie rechtlich verbindlich und der Großteil der Cookie-Banner ist auch rechtlich sinnfrei, da es nur eine Info ist. Im Normalfall müsste man eine Seite ohne Cookies haben, dann per Banner über jede Art Cookie informieren und dann erst Cookies setzen. Sollte der Benutzer irgendwelche Cookies ablehnen, darfst du auch keine setzen.

Aber wie gesagt: es geht seitens der GDPR nicht pauschal darum, Cookies zu verbieten ...
Es geht um Datensparsamkeit und darum, nur benötigte Daten zu erfassen. Das Erfassen einer IP-Adresse bei Abgabe eines Kommentars oder Versand eines Formulars ist für mind. 30 Tage interessant, um ggfs. meiner Nachweispflicht nachzukommen. Danach werden die Infos nicht mehr benötigt, da auch das Telekommunikationsunternehmen dann auch keine Infos mehr hat.

Contao ist schon sehr gut gewappnet im Hinblick auf GDPR und wir arbeiten noch an ein paar Sachen, aber meist liegt das Problem nicht an Contao, sondern eher an anderen Sachen! ;-)

fg
nicky


Gesendet von iPhone mit Tapatalk Pro

Hi Leute,

Wie finde ich heraus, welche Cookies mit Contao gesetzt und verwendet werden?

Mir geht es um die DSGVO-Geschichte. Hab da mal in den Datenschutzerklärungen der großen Unternehmen herumgestöbert, wie die das so machen und da ist mir aufgefallen,
daß die Cookies genau aufgelistet werden und was die damit machen.

Beispiel hier: Beispiel Coockies. Quelle: Datenschutz von Mercedes-Benz / Daimler

Zitat:

---

Zitat von Schnippel

Wie finde ich heraus, welche Cookies mit Contao gesetzt und verwendet werden?

---

Wie immer: <F12> drücken. Dann kannst Du Dir den Session-Cookie anschauen.


Gesendet von iPad mit Tapatalk

Das hier ist vielleicht auch hilfreich. Da bekommt man dann scheinbar die Möglichkeit in seine Datenschutz- oder Cookieerklärung deren Script einzubinden, welches alle verwendeten Cookies automatisch auflistet & die bekannten auch erläutert. Die Ausgabe kann man hier als Beispiel sehen.

Bringt aber bestimmt einen weiteren Cookie mit sich :D

Danke für die Infos.

Zitat:

---

Wie immer: <F12> drücken. Dann kannst Du Dir den Session-Cookie anschauen.

---

Und wie lassen sich die temporäre/permanente Cookies anzeigen?
Woher weiß ich, welcher Cookie was macht?

Anhang 20743

Wie kann ich in Contao selber steuern, welche Cookies angezeigt / genutzt werden sollen?
Wie ist das beim Einsatz von Google-Analytics?

Was Du da siehst ist ein so genannter CSRF-Cookie, der - grob gesagt - verhindert, dass jemand die Benutzersession des jeweiligen Surfers kapert und fremde Inhalte einbindet (wie beispielsweise hier: http://lucina.weitsicht.org/2008/05/31/secret-service/).

Zu den Hintergründen ganz interessant: https://stackoverflow.com/questions/...ens-in-cookies

Zitat:

---

Zitat von Schnippel

Und wie lassen sich die temporäre/permanente Cookies anzeigen?

---

Du siehst dort das Ablaufdatum.

Zitat:

---

Zitat von Schnippel

Woher weiß ich, welcher Cookie was macht?

---

Das erfährst du nur, wenn du dir den PHP Code ansiehst, der das Cookie erzeugt.

Zitat:

---

Zitat von Schnippel

Wie kann ich in Contao selber steuern, welche Cookies angezeigt / genutzt werden sollen?

---

Gar nicht.

Zitat:

---

Zitat von Schnippel

Wie ist das beim Einsatz von Google-Analytics?

---

Das musst du einen Rechtsexperten fragen ;).

@ jk1

Zitat:

---

Das hier ist vielleicht auch hilfreich. (https://www.cookiebot.com)

---

Hab darüber mal eine Analyse gemacht und bekam als Antwort, daß "Cookies sind nicht klassifiziert und erfordern eine manuelle Klassifizierung und
eine Zweckbeschreibung."

Ich vermute mal, daß man das so wie hier in einer Datenschutzerklärung von Daimler aufführen muß, oder?

Anhang 20746
Quelle: https://www.mercedes-benz.de/content...owcplayer.html

Für mich stellt sich jetzt die Frage, wie kann ich Cookies klassifiszieren und deren Zweck beschreiben?
Woher bekomme ich die entsprechende Informationen, wie
- was ist das für ein Cookie?
- was macht dieser Cookie?
- wie lange ist dieser Cookie auf dem Endgerät des Users, bzw. wie bekomme ich das Ablaufdatum heraus, sodaß es in die Datenschuterklärung aufgeführt werden kann?

Welche Cookies setzt Contao und evtl. Erweiterungen, Kontaktfromular, Logins etc. automatisch?
Wie muß man das machen, wenn man Google-Analytic einsetzt? Da gibt es ja die UAxxx-Nummer..

Den Contao-Cookie kennst Du ja jetzt. Die PHP-Session darin gilt nur für den aktuellen Besuch der Seite und wird beim Schliessen des Browsers gelöscht, da das Ablaufdatum in der Vergangenheit liegt.

Für alle anderen denke ich, dass Du ja bestimmst was Du einbindest, und dann auch wissen solltest was es macht.

Zur rechtlichen Frage: Suche Dir fachjuristischen Rat.

Nachbemerkung: Eine Seite wie Cookiebot ist ja ganz nett, allerdings versucht Sie etwas zu verkaufen. Für mich klingt das in der Aufmachung so als möchte man mögliche Panikgefühle nutzen und damit Geld verdienen. Und das für Dinge, die man normalerweise auch selbst weiss (oder zumindest wissen sollte). Mir persönlich ist auch nicht bekannt, dass man Cookies 'klassifizieren' muss. Mir ist bekannt, dass man 'informieren' muss, welchen Cookie man zu welchem Zweck setzt oder setzen lässt. Konsens ist wohl: Unproblematisch sollte alles sein, was technisch bedingt ist (wie ein Session-Cookie oder ein technischer Schutz gegen Missbrauch). Was Fremdcookies wie beispielsweise Google Analytics angeht, so sehe ich das - wie bisher auch - einigermassen kritisch. Möglicherweise wirst Du da zu Beginn die Zustimmung des Nutzers einholen müssen, mithin auch einen Mechanismus benötigen, der externe Cookies eben nicht setzt, wenn keine Zustimmung vorliegt. Für mich persönlich ist das ein weiterer Grund, so ein Tool eher nicht einzusetzen sondern auf weiterhin selbstgehostete Analysetools, bei denen ich die Anonymisierung von Benutzerdaten selbst in der Hand habe, zu setzen. Da weisst Du auch, was zu welchem Zweck gemacht wird und kannst Enduser entsprechend informieren und um Einwilligung bitten.

Zitat:

---

Für alle anderen denke ich, dass Du ja bestimmst weisst, was Du einbindest..

---

Verstehe ich das richtig, daß solche Dinge wie die vom Google-Tag-Manager erzeugten Tracking-ID`s und so berücksichtig werden müssen?
Dies hat doch auch was mit Cookies zu tun, oder?

Zitat:

---

...sondern auf weiterhin selbstgehostete Analysetools, bei denen ich die Anonymisierung von Benutzerdaten selbst in der Hand habe, zu setzen. Da weisst Du auch, was zu welchem Zweck gemacht wird und kannst Enduser entsprechend informieren und um Einwilligung bitten

---

Welche Tools für die Webanalyse sind empfehlenswert?
Gibt es Tools, die auch als Erweiterung für Contao vorhanden sind, die z.B. automatisch eine Zusammenfassung liefern, welche Cookies aktiv sind?

Du wirst für alles, was analysiert oder Cookies speichert, eine Einwilligung Deiner Benutzer benötigen. Auch für Google Analytics. Du wirst dazu auch eine Vereinbarung zur Auftragsdatenverarbeitung mit Google schliessen wollen. Das bietet Google ja auch an. Möglicherweise wirst Du Dir ein paar Gedanken machen müssen, wie Du mit einer Löschanfrage bei teilanonymisierten Daten umgehen kannst. Finde ich persönlich spannend, genauso wie die Frage, ob ein Tool wie Salesforce nach dem 25. Mai noch legal zu betreiben ist. Datensparsamkeit ist das Gebot der Stunde.

Frage 2: Matomo. Open Source, Selfhosting. Die wirklich interessanten Plugins sind inzwischen kostenpflichtig, aber das sollte Dich nicht abhalten.

[QUOTE=jk1;466498]Man muss ja auch nochmal unterscheiden zwischen einem "normalen" Browser-Cookie und einem Session-Cookie.
Die Inhalte des Session-Cookies werden auf dem Server in einer Textdatei gespeichert & die Inhalte der Browser-Cookies in einer Textdatei (Chrome nutzt hier SQLite) auf dem Rechner.


Browser-Cookie:



Session-Cookie:


Den Session-Cookie kann man in der app/config/config.yml deaktivieren:

Code:

---

framework:
  session:
    use_cookies: false

---

gibt es noch andere Möglichkeit ,um das setzen von coockies zu verhindern?

Es wird doch gar nicht nötig sein, Session Cookies bzw. "Strictly necessary cookies" zu unterbinden oder Einverständniserklärungen dafür einzuholen. Lies mal diesen Blog über die Cookie-Arten und die aktuelle sowie die zu erwartende Rechtslage: https://rickert.net/blog/cookies-aktuelle-rechtslage/

Zitat:

---

sowie die zu erwartende Rechtslage: https://rickert.net/blog/cookies-aktuelle-rechtslage/

---

Den letzten Absatz find ich ja echt lustig :-)
"Lehnt der Nutzer das Setzen von Cookies ab, darf er nicht für die Website gesperrt sein oder andere Nachteile dadurch erhalten"

Für mich stellt sich die Frage, wie kann ich als normaler Contao-CMS-Nutzer all diese Dinge noch überblicken und praktisch handeln..
Wird es dazu eine Erweiterung geben, die einem das Leben vereinfacht?

Wie lässt sich das alles steuern
a) welche Cookies werden automatisch gesetzt
b) welche Cookies setze ich gezielt ein (z.B. durch Google-Analytic mit dem UA_xxx ??)
c) welche Cookies landen durch Fremdes zutun auf meine Seite, für die ich zur Verantwortung gezogen werde?
d) welche Technik, Tools etc. kann ich verwenden um den Anforderungen der Deaktivierung gerecht zu werden?

Bei mir türmt sich nen rießiger Berg auf, deren Spitze ganz im Nebel hängt.

Wahrscheinlich läuft es dann doch erstmal auf nen Notfall-Plan hinaus:
Am 24.05. Seite vom Netz nehmen und die nächsten Tage abwarten, was da so passiert, wenn die Horden der Abmahnvereine übers Internet herfallen. :-)

Zitat:

---

Zitat von Schnippel

Wie lässt sich das alles steuern
a) welche Cookies werden automatisch gesetzt
b) welche Cookies setze ich gezielt ein (z.B. durch Google-Analytic mit dem UA_xxx ??)
c) welche Cookies landen durch Fremdes zutun auf meine Seite, für die ich zur Verantwortung gezogen werde?
d) welche Technik, Tools etc. kann ich verwenden um den Anforderungen der Deaktivierung gerecht zu werden?

---

a) nur das Session-Cookie von Contao
b) das solltest Du wissen -- Du hast es ja selbst eingebaut -- und damit leicht zu klären sein.
c) keine. Du musst dazu schon selbst etwas einbauen (z.B. JS-Code einer anderen Domain oder ein Youtube-Video o.Ä.).
d) das kann man wohl nicht pauschal sagen. Die "Anbieter" der Cookies, die betroffen sind sollten auch eine Lösung dafür bieten. Bei Piwik/Matomo z.B. hier https://matomo.org/faq/general/faq_20000/).

Alle Angaben "natürlich" ohne Gewähr.

Zitat:

---

Zitat von Schnippel

d) welche Technik, Tools etc. kann ich verwenden um den Anforderungen der Deaktivierung gerecht zu werden?

---

Schau mal hier: https://github.com/ToX82/cookie-bar

Hmmmmm. Und wie verhindert Cookie-Bar, dass ein Cookie gesetzt wird?

Zitat:

---

Zitat von tab

Hmmmmm. Und wie verhindert Cookie-Bar, dass ein Cookie gesetzt wird?

---

Zitat:

---

How it works?

cookieBAR is a drop-in and forget, pure vanilla javascript plugin, with no jQuery nor any other dependency needed. It shows up when needed and stay silent when not: if a website has a cookie or some localStorage data set then the bar is shown, otherwhise nothing happens.

Once user clicks Allow Cookies cookieBAR will set a cookie for that domain with a name cookiebar that will expire in 30 days. What this means is that the plugin will only show up once month (this duration is configurable).

If a user decides to click Disallow Cookies, cookieBAR will simply remove all cookies and localStorage data (and will show up again the first time a cookie is detected).

Having a cookiebar cookie makes it simple to developers to check the user decision before activating external scripts (such as Google Analytics, or anything else). See http://cookie-bar.eu for more informations.

---

Steht alles da - einfach mal lesen, bitte.

Die Abfrage müsste eigentlich kommen, BEVOR irgendein Cookie gesetzt wird. Ok, wenigstens wird es bei Ablehnung hinterher wieder gelöscht. Man kann also immerhin hoffen, dass man damit durchkommt, wenn der zuständige Richter den Geist der Verordnung im Hinterkopf hat und nicht den Buchstaben. Aber streng genommen ... auch wenns Blödsinn ist.

Zitat:

---

Zitat von Anke

Schau mal hier: https://github.com/ToX82/cookie-bar

---

Dieses Script verhindert nicht das Setzen von Cookies. Es löscht sie nur im Nachhinein.

Ja, es setzt dann zusätzlich zum unproblematischen Sitzungscookie halt noch einen eigenen, aufgrund dessen Du dann reagieren kannst. Im Grunde genommen müsstest Du für alles, was dann selbst gesetzt wird, nochmal kapseln (wenn Zustimmung da, dann darfst Du die anderen setzen und Dienste nutzen). Das hängt dann aber auch vollkommen davon ab was Du da an Diensten nutzt.

Ach wie schön, wenn man für alles und jedes die Open Source-Alternativen nutzt die man selbst unter Kontrolle hat ... ;-)

Zitat:

---

Zitat von lucina

Ach wie schön, wenn man für alles und jedes die Open Source-Alternativen nutzt die man selbst unter Kontrolle hat ... ;-)

---

Ja, von "drop-in and forget" sind wir da allerdings ein gutes Stück entfernt. ;)

Hi Leute,

hab mal mit dem Chrome die Coockies anzeigen lassen:

Anhang 20795

Jetzt meine Anfängerfrage:

- PHPSESSID ist das Cookie, welches das System setzt, oder?
Die Ablaufzeit wäre dann wann? Da steht was von 1969-12-31...

- Wie finde ich heraus, was die anderen Cookies sind, wo die genau eingebunden sind /sich verstecken und was die machen?

Das Ganze ist für mich noch wie ein Buch mit sieben Siegeln...

Die Ablaufzeit ist so gesetzt, dass das Cookie in jedem Fall bereits abgelaufen ist. Vor dieser Zeit gibt es unter Unix nicht. Damit wird es beim Schliessen des Browsers gelöscht.
Die anderen Cookies stammen von Google Analytics, siehe z.B. https://developers.google.com/analyt...kie-usage#gajs

Hallo,
ich bin hier auch etwas überfragt bzgl. dem ganzen Handling. Es gibt einfach zu viele schwammige Erläuterungen etc.
Schön wäre es, wenn es einfach eine Art "Contao DSVGO-Checkliste" geben würde, in welcher einfach Infos gesammelt werden.

Jetzt habe ich auch noch mitbekommen, dass scheinbar letzte Woche eine Opt-In Pflicht beschloßen wurde:

https://www.wbs-law.de/internetrecht...quenzen-77046/

Ich habe die Cookie-Bar im Einsatz, aber das wird ja nicht mehr genügen, oder?

Außerdem habe ich viele YouTube-Videos über das CE eingefügt. Gibt es da eine Möglichkeit in Contao 3.5 einfach auf die YouTube NoCookie-Version zu verlinken?
Vielen Dank im voraus für Hilfe!

Zitat:

---

Zitat von Thanatos

Außerdem habe ich viele YouTube-Videos über das CE eingefügt. Gibt es da eine Möglichkeit in Contao 3.5 einfach auf die YouTube NoCookie-Version zu verlinken?
Vielen Dank im voraus für Hilfe!

---

Mit der youtube_iframe Extension über Composer.

Hat nicht auch Youtube einen Punkt zum Aktivieren ?
Sollten da nicht die Cookies deaktiviert sein?

Anhang 20833

Ja, genau diese Option ist damit gemeint.