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