EuGH: Deutscher Sonderweg bei Cookies für unzulässig erklärt

[Luisehahne]

Thema geschlossen, bevor es weiter ausartet.

Dietmar

[evaki]

Überliest du die Erklärungen eigentlich bewußt

Die Erklärung, daß Apache oder MS oder xxx das serverseitig managen können, läßt Dich wieder ausrasten? Oha. Du erklärst zwar viel, aber nicht immer bemerkst Du die Widersprüche, die Dir unterlaufen. Außerdem Sachen wiederzukäuen, die längst in der Praxis widerlegt oder allseits bekannt sind, machen es auch nicht spannender. Deine Tour, mir Dramatik zu unterstellen, gehört mittlerweile zu den Langweilern, zumal der Grund für die Modifikation erläutert wurde. Ein paar Überbleiber aus dem Anwender nutzen es, und gut ist. Der Rest ist bekannterweise aus WB und Forks ausgestiegen. Du glaubst doch nicht, daß ich mich da noch weiter reinhänge, und auch noch Überzeugungsarbeit leiste. Aus diesem Job bin ich draußen, und stecke meine Energie wieder in berufliche Zweige.

Im übrigen macht ausgerechnet das von mir absolut ungeliebte WP vor, wie's gehen kann, nämlich ohne und bei Bedarf. Bedarfsweise auch mit einem externen Dienst (https ://usercentrics.com).   
MfG. Evaki

[Gast]

Da ist er ja wieder, der alte Dramatiker - Hilfe, die Welt geht unter - WB benutzt einen Cookie  *kreisch

Überliest du die Erklärungen eigentlich bewußt? Damit deine Weltuntergangsstimmung einen Boden hat?

WB setzt einen Cookie, der auf einer Seite ohne Extra-Funktionen unnötig scheint, allerdings in diesem Zustand auch keinerlei Daten enthält und damit keinerlei DSGVO-Zustimmung benötigt.

Dieser Cookie ist aber z.b. von Nöten, wenn man einen Frontend-Login benutzt, eine Registrierung und/oder einen Frontend-Edit, wie ihn einige Module anbieten
Dieser Cookie ist ebenfalls von Nöten, wenn der gleiche Rechner im Backend arbeiten möchte

Beide Dinge kannst du garnicht über eine serverseitige Session abwickeln, weil du zu einen dafür eine DSGVO-Zustimmung benötigst, zum anderem innerhalb kürzester Zeit eine Datenmenge sammelst, die u.U. dein Webspace sprengen könnte. Funktion wie RememberKey, SmartLogin, eine Farbschemaauswahl, wie sie einige Templates haben usw wäre dann vom Tisch, weil eben serverseitige Sessions im Allgemeinen nur kurzlebig wären und im Normalfall mit den Schließen des Browserfensters gekillt werden. Genau das wäre aber kontraproduktiv. Du warst doch auch einer derer, die am lautesten geschrienen haben, wenn deine Leute beim Schreiben eines langen Artikel automatisch ausgeloggt wurden, weil die Server-Session zu Ende war.
Und natürlich kannst du deinen Cookie killen, ist ein freies Land und ein OpenSource-CMS. Du wirst der Held sein bei deinen Leuten und der Arsch, wenn später festgestellt wird, das dies und das nun plötzlich nicht mehr funktioniert. Davon erfahren wir hier aber nichts.

Da ich weiß, wo das wieder endet, ist das Thema für mich beendet.

[evaki]

P.S.: ist schon traurig, das von offizieller Seite dazu kein Beitrag kommt

Merkwürdig ist die ganze Angelegenheit aus meiner Sicht allein schon deshalb, weil es ein servereigenes Sessionmanagement gibt, also auch ohne PHP eines besteht, das ein- und abschaltbar ist.
Ein CMS muß also nicht zwingend wie ein Klotz am Bein dastehen. Das tut es aber. Dafür ist/wäre eine DSGVO noch nichtmal vonnöten gewesen. Eine rein technische Betrachtung reicht. Irgendwie erinnert mich das an "codeX".

MfG. Evaki

[evaki]

Korrektur

Zur Zeit hängt ja anscheinend alles an WSession::Start(); in der initialize.php.

Das trifft auf den WB-Fork zu, bei dem das auch getestet wurde.

Über WB hab ich nix auf'm Zettel -  jep, das war nur mündliche Überlieferung, aber es dürfte sich vergleichsweise gestalten. Da werde ich wohl nochmal nachhaken müssen, wenn nicht vorher jemand aufklärt, wie's im WB abläuft.
Die Tests liefen jedenfalls zuletzt erfolgreich ausschließlich unter      2.12.2 r378

MfG. Evaki


MfG. Evaki

[evaki]

wenn ich nach jedem Klick im FE, den ich ja nicht mal selber machen muß, im BE rausgeworfen werde, weil der Cookie gelöscht wurde, ist das wenig hilfreich.

Genau das geschieht jetzt ja nicht mehr. Anfangs passierte das, wenn man mit ein und dem selben Browser arbeitete.  Aktuell ist, wenn jemand "drin ist", die Löschaktion nicht aktiv.
Man kann wie gewohnt arbeiten, ohne rausgeschmissen zu werden.

Das Thema schürt Unsicherheit bei den Benutzern, nicht nur bei diesem System - überall - und das Web ist voll von unnötigen Klickaktion aus reiner Angst und Vorsicht.

Weshalb man dieser Arie aus dem Weg gehen wollte. Die Anwender waren enorm genervt, auch darüber, daß die EU mal wieder nix zu Ende gebracht hat (e-privacy).

Ich bin da immernoch für eine zentrale Lösung, ein Setting mehr für den SuperAdmin

Das haben sich hier alle gewünscht, nur "mal auf die Schnelle" geht anscheinend nicht, da doch - soweit ich da Einblick hatte - mit erheblichem Aufwand verbunden, zumindest wenn das keinen Rattenschwanz an Modulen etc. nach sich ziehen soll. Zur Zeit hängt ja anscheinend alles an WSession::Start(); in der initialize.php.
Wenn man dann auch nicht weiß, wie die EU die ePrivacy-Verordnung gestalten wird, ist das aus Entwicklersicht verständlicherweise nicht umgehend angesagt.
Überlegungen dazu, also unabhängig von irgendwelchen EU-Entscheidungen, wären aber schon willkommen.
MfG. Evaki

[Gast]

erinnert mich an einen Bekannten, der fuhr, wie ich auch, einen mittlerweile Oldtimer aus den USA, hatte aber einen Rostschaden im Bereich der unteren A-Säule. Werkstatt 1 wollte 800 Euro + Steuer, Werkstatt 2 wollte 1100 Euro + Steuer. Ich hab ihm gesagt, ich repariere das für die Materialkosten, wären vielleicht 100 Euro gewesen.
Auf Grund einer Behinderung seiner Tochter benötigte er aber ein Fahrzeug, das eben auch einen Rollstuhl transportieren kann. Nix mit Rampe oder so, eher was kleines, zusammenfaltbar, halt nix für den Kofferraum einen Golf.
Also klapperte er die Autohäuser ab und fand, oh Wunder, natürlich einen Ersatzwagen. Es war wohl Liebe auf den ersten Blick, aber eine Summe in 5-stelliger Höhe. Der Oldtimer wurde verscherbelt.
Nun ist man mit einem schwerst behindertem Kind immer im Zwang, ein zuverlässiges Auto haben zu müssen und bis auf diese Rostsache war es der Oldtimer ja auch. Ich würde ja auch gern eines der neuesten Modelle fahren, schon allein wegen der ganzen Helferlein an Bord. Also sei es akzeptiert.
Unterm Strich stehen aber 25.000 gegen mein 100 Euro. Das neue Auto hat auch nur 4 Räder, die gleichen P.S., die gleichen Extras und muß auch alle zwei Jahre zum TÜV. Gewonnen hat er nix....

Der Fall hier ist ähnlich. Natürlich kann man die SessionCookies von WB killen, aber ist es z.b. nicht einfacher, das Anlegen einfach zu unterbinden?
Aber hier lasse ich das Argument: "ja nicht im Sourcecode fummeln" durchaus gelten, schon allein wegen der späteren Upgradefähigkeit, einmal ausgelöscht, soll der Status ja auch so bleiben bei einem Upgrade.

Das eine gewisse Abmahnangst besteht, kann ich ebenfalls nachvollziehen. Im Zweifel etwas mehr, spart ggf ein paar Euro. Da ich selbst schon für eine Abmahnung bezahlt hab, ist das eine Schiene, wo ich mitgehe.

Was mir nicht gefallen würde (und sieh das nicht als Meckerei, sondern eher als Meinung zum finden einer guten Lösung, ist, das man die WB-eigene Lösung killt, um eine eigene einzubauen. Aktuell fehlen wohl genügend Informationen dazu, um das ohne Bauchschmerzen zu erledigen, z.b. was passiert alles im Backend? Du hattest das oben schon angesprochen, wenn ich nach jedem Klick im FE, den ich ja nicht mal selber machen muß, im BE rausgeworfen werde, weil der Cookie gelöscht wurde, ist das wenig hilfreich. Neben den schon erwähnten Situationen "Display-Eigenschaft der Blöcke" gibt es ja noch mehr, was mit Cookies arbeitet, Status von Plus/Minus in der Seitenübersicht, der erwähnte Remember-Key usw. Noch nicht dabei sind Module. Auf Anhieb kann ich mich jetzt nicht erinnern, das in irgendeinem Code schon mal gelesen zu haben, aber sollte es da irgendwo drin sein, wurde es auch nie geändert.

Es würde mir widerstreben, statt der vorhandenen Lösung, die ggf den WB-eigenen Cookie benutzt, nun neue Dinge einzubauen, nur um diesen WB-Cookie weiterhin löschen zu können. Nicht falsch verstehen bitte, das er gelöscht wird, weil er garnicht benötigt wird, verstehe ich durchaus. Und selbst, wenn mir die aktuelle Rechtslage keine CookiePermission abverlangt, heißt das ja auch nicht, das dies ewig so bleibt.
Ich müßte nochmal eine der älteren Versionen aktivieren, 2.8.1 oder 2.8.2, da standen auf jeden Fall noch weitere Dinge drin, zumindest nach erfolgtem Login. Und soweit ich mich erinnere, war die Denke damals so: Ich habe einen SessionCookie, also nutz ich ihn auch, d.h. überall wo notwendig, würde dann in diesen Cookie geschrieben. Diese Technik beinhaltet aber auch, das ich, sollte der Cookie im Pfad nicht gefunden werden, diesen neu anlege, was dann aber dazu führen würde, das man eben doch den Core anfassen müßte.

Dazu kommt, das ich bei einer Cookieverwendung im FE, wo auch immer der anfällt,  das Opt-In auf jeden Fall benötige. Das wäre dann ein Haufen Arbeit umsonst.

P.S.: ist schon traurig, das von offizieller Seite dazu kein Beitrag kommt und sei es nur in Form von Informationen aus der Vergangenheit   
Das Thema schürt Unsicherheit bei den Benutzern, nicht nur bei diesem System - überall - und das Web ist voll von unnötigen Klickaktion aus reiner Angst und Vorsicht.
Ich bin da immernoch für eine zentrale Lösung, ein Setting mehr für den SuperAdmin

[evaki]

Na, ist doch nur folgerichtig.
!.) Webmaster will grundsätzlich keine Session-Cookies im FE, auch wenn SessionCookies aktuell ohne spezielle Erlaubnis anwendbar sind.
2.) Da für die ein oder andere Anwendung doch ein Cookie gleich welcher Art fällig wäre, und dies
entsprechend DSGVO der Zustimmung bedarf, braucht es für diese Situation eine Lösung, weil das von WB erzeugte Cookie ja gekillt wird. Also entweder klassisches Cookie oder localstorage/sessionstorage, wobei sich die Anwender für letzteres wg. der vorgebrachten Gründe entschieden haben.

Diese Situation ergibt sich also ausschließlich aus der Forderung nach "keine Session-Cookies im FE", sonst nie. Wenn das jemand so haben will, wird das - wenn's geht - eben so gemacht. Technik soll dem Anwender dienen, nicht umgekehrt. Welcher Rationalität soll man den Vorzug geben? Solange das CMS nicht "abkackt" is doch alles jut.

<offtopic>Ein Elektriker verweigert erst eine Ausführung, wenn eine allgemeine sowie indiviuelle Gefährung eintreten kann. Dem ist aber egal was Du an Deine Steckdosen anschließt. Es ist die EU die Dir faktisch vorgibt, daß Du keine Glühbirnen mehr einschraubst. Meinem Energieunternehmen ist es vollkommen Schnuppe mit welchen Krimskrams ich den Strom verbrauche, sogar wenn ich mit einem Tauchsieder den Gartenteich erhitze. </offtopic>
MfG. Evaki

[Gast]

ob nun mit einer Dauerschleife wie in deiner Lösung oder ganz gezielt.

Die Dauerschleife schmeißt gezielt die WBeigene Session raus, womit der Weg für eigene Sessions/Cookies frei wird, falls diese gebraucht werden.

da fehlt mir absolut der Sinn für, aber egal.
Ist alles gesagt, denk ich

[evaki]

ob nun mit einer Dauerschleife wie in deiner Lösung oder ganz gezielt.

Die Dauerschleife schmeißt gezielt die WBeigene Session raus, womit der Weg für eigene Sessions/Cookies frei wird, falls diese gebraucht werden. localstorage/sessionstorage kommt da als JS-Lösung wie gerufen, mal beiseite gelassen, was Browser damit anfängt.

Kuchen des Datensammelns möchte der Browser

Das liegt nahe, vielleicht bald 'nen EU-konformen Browser?  Da klingelt es bei mir dann aber auch sofort, wenn irgendwer vorschreiben will, was der Client zu empfangen hat und was nicht - natürlich nur zu meinem Besten.  Die Eu sollte gewährleisten, daß der Anwender sich es selbst aussuchen kann. Wenn nicht, kompiliert man sich was "eigenes". Andererseits, wenn sich DAU von Portalen vorschreiben läßt, was er - nicht - zu sehen hat, darf man an der Mündigkeit des Bürgers zweifeln.- na gut, statt Punkt ein "?".

Erst, wenn ich dann anmeldepflichtige Angebote nutzen möchte, 

Genauso sahen es wohl auch meine Anwender, als sie auf die Idee kamen.
Wobei ich deren Argumentation für localstorage/sessionstorage sehr gut verstehen kann, wenn es zutrifft, daß die entsprechenden DSGVOkonformen Formulare in Funktion, Ausführung und Gestaltung leichter zu realisieren sind. Man riet mir, mal mit FF-Web-Speicher-Inspektor auf Seiten zu gehen, wo sich so wunderschöne Auswahlformulare zur Datenerfassung befinden. Hab' ich gemacht localstorage/sessionstorage war dort dann dominant bis exklusiv.

Nochmal grundsätzlich. Diese "Problemlösung" war und ist nur als vorübergehende gedacht, bis die EU ihre Arbeit "auf die Reihe" kriegt und die Verordnungen fertigstellt. Diese Umschiffung tastet WB selbst nicht an.
Als Nebeneffekt eröffnet sie die Option für localstorage/sessionstorage, was für mich persönlich den eigentlichen Reiz darstellt.

Einen schönen Sonntag wünscht Evaki

[Gast]

Mein Vorschlag localstorage/sessionstorage war nur als technische Alternative zum bestehenden SessionCookie gedacht/gemeint, weil die bestehende Session durch den Trick ja immer wieder gekillt wird.

zum 1. auch einen Cookie im Localestorage kannst du ja killen, ob nun mit einer Dauerschleife wie in deiner Lösung oder ganz gezielt. Der einzige Unterschied ist ein anderer Speicherort, ohne localestorage im temp-Verzeichnis des Betriebssystems, mit localestorage in den Anwendungsdateien des jeweiligen Browsers. Persönlich glaub ich eh, das da mehr dahinter steckt - frei nach dem Motto "vom Kuchen des Datensammelns möchte der Browser auch etwas abhaben"
rein rechtlich spielt es keine Rolle, in der DSGVO gehts eher im das grundsätzliche Sammeln personenbezogener Daten.

Und wie bereits erwähnt, ein "echter" SessionCookie, wie er in WB mal verwendet wurde (Smart Login / Wiedererkennung / den Login im BE aufrecht erhalten), besteht ja jetzt nicht mehr

warum der spiegel.de keinen Cookie-Banner zeigt

weil diese Seite keine persönlichen Identifikationsmerkmale darin speichert, zumindest nicht in den frei zugänglichen Bereichen. Ich bin regelmäßiger Spiegel.de-Leser. Du bekommst beim ersten Besuch 21 Cookies übersandt. Gleich der erste in der Liste entspricht dem WB-Cookie, ein Timestamp des Besuches, nicht mehr. Erst, wenn ich dann anmeldepflichtige Angebote nutzen möchte, muß ich dieser DSGVO auch zustimmen und erst dann werden Cookies geschrieben, die personenbezogene Angaben enthalten, meinen Rechner also identifizieren können.

[evaki]

Ob ich nun einen Cookie der althergebrachten Form (Datei im temp-Verzeichnis des Besuchers) setze oder die gleichen Daten im localstorage verarbeite, ist z.b. meiner Meinung nach der gleiche Vorgang.

Weshalb ich diesen CookieAbklickwahn ja so hirnrissig finde. Entscheidende Juristen meinen ja, daß sich jeder im Internet so doof verhält, wie sie selbst (ja, ein Gemeinplatz - aber zu dem stehe ich.)
Mein Vorschlag localstorage/sessionstorage war nur als technische Alternative zum bestehenden SessionCookie gedacht/gemeint, weil die bestehende Session durch den Trick ja immer wieder gekillt wird.   

Ob nun der FE-Session-Kram in WB geändert wird bzw. geändert werden kann, oder ob jemals eine Änderung nötig wird,  steht aktuell noch vollkommen in den Sternen bzw. noch sind das ungelegte Eier.

Allein, daß eine Lösung für diese Problemstellung gesucht und anscheinend auch gefunden wurde, finde ich halt spannend. Für einige ist der Cookiekram einfach nur nervig und lästig, weshalb ich die Haltung dahinter nachvollziehen kann.

Ach ja, zum allgemeinen Vergnügen die Frage, warum der spiegel.de keinen Cookie-Banner zeigt.
Viel Spaß


ps. Die Regelung bei einer Dauerrot-Ampel ist auch nicht ohne.
Demnächst vielleicht nur noch mit einem Merkheft auf die Straße gehen?
Wir hatten hier am Bürgersteig eine Situation wo innerhalb von 5 Minuten 3 Ordnungswidrigkeiten zusammenkamen. Da bleibt ein Rentner sicherlich gleich zuhause.

MfG. Evaki

[Gast]

weil es eben die Alternative sessionstorage, localstorage gibt

Am Ende entscheidet wohl die Cleverness des Anwalts bis hin zum Alter des Richters darüber, was rechtlich relevant ist, aber eben nicht die Logik eines Technikers.

Ob ich nun einen Cookie der althergebrachten Form (Datei im temp-Verzeichnis des Besuchers) setze oder die gleichen Daten im localstorage verarbeite, ist z.b. meiner Meinung nach der gleiche Vorgang. So oder so schreibe ich Daten auf dem Rechner des Besuchers und weil ich den Wiedererkennungswert benötige, müssen dort eben auch personenbezogene Daten rein bis hin zur Browser-Identifikation.

Sessionstorage: Hier geht es nur darum, einen Zwischenspeicher für einen Zeitraum X zu schaffen, der i.d.R. recht kurz bemessen ist. Sessionstorage bezieht sich immer auf die aktuelle Sitzung (der Session) in genau diesem einen Browserfenster. Schließ ich das Fenster, ist die Session tot, d.h. es gibt keine Möglichkeit, Daten im Sinne eines Cookies zu erzeugen. Ich erzeuge wohl wiedererkennbare Daten, auf die aber niemand, außer dem Benutzer selbst, Zugriff hat - die aber ebenso nach Schließen des Tabs verschwunden sind. Meiner Meinung nach hat diese Variante auch nichts mit der DSGVO zu tun, weil der Betreiber diese Daten weder sammelt, noch verarbeitet.

Auf jeden Fall muß man betonen, das sessionstorage und die Session z.b. des Captchas außer dem Begriff "session" nichts miteinander zu tun haben. "Session" beschreibt in beiden Fällen eine Sitzung in einem einzigem Browserfenster
Ein gutes Beispiel für ein Sessionstorage wäre z.b. ein Warenkorbinhalt, inkl aller Berechnungen von Preisen, Steuer etc. Mit Schließen des Browserfensters ist der Inhalt dann gelöscht.
Das Captcha dagegen ist eine eher lokale Aufgabe auf dem Server, die möglichst kurzfristig erledigt sein muß, nämlich während des Ladens der Empfangsseite, der Warenkorb kann dagegen auch in aller Ruhe nach dem kompletten Laden der Seite eingelesen werden.

Zum Sicherheitswahn: Ich möchte betonen, das es KEIN Vorwurf an irgend jemanden war.
Mir ist schon klar, das die allermeisten Leute aus Angst Schutzmechanismen einbauen, die in den meisten Fällen überhaupt nicht nötig sind.
Nun gibt es Rechtsverdreher (und der Name passt hier wirklich), die machen aus klaren Situationen eine Fragwürdige. Stichwort Verkehrsampel: jeder weiß, bei Rot bleibe stehen. Nun ist das beileibe nicht so - man darf (und da fass ich mir mit der Hand an die Stirn) tatsächlich bei Rot fahren bis zu 2 Sec nach dem Umschalten. Jeder halbwegs normale Mensch, und da zähl ich mich dazu, sagt, ich habe die grün-gelb-Phase, Rot ist zu erwarten - so habe ich es gelernt. Der Verdreher sagt: bei grün-gelb darf ich aber noch fahren (was so auch richtig ist), dazu kommt 1 Sec Reaktionszeit des Fahrers + 1 Sec Verzögerung in der Ampelsteuerung, i.d.R. elektro-mechanisch durch Relais). Ich fahre z.b. oft die gleiche Strecke und oft mit Kiddies drin, ein 7-Sitzer-Van. Da kommt es schon des Öfteren vor, das ich vorn bei grün-gelb losfahre bzw eben im Fluß bin und die Kinder der hintersten Bank schreien: das war aber rot. Steht da ein Polizist, kommt es drauf an, wann er hinschaut und im Falle des Falles nehm ich mir dann doch eher den Rechtsverdreher als Anwalt

Analog der Webseiten. Für den (noch dazu) leeren WB-System-Cookie braucht es keine Einwilligung, aber dennoch wird er geschrieben und es findet sich sicher eine(r), der meint, das Schreiben allein ist schon der Punkt.
Es ist aktuell sowohl für einen Webmaster, der es DSVGO-gerecht machen muß, wie auch für einen Besucher, der die Tragweite eines Klicks in diesem Moment noch garnicht überschauen kann, unheimlich schwer und es wird noch komplizierter, wenn man versucht, eine Ein-Klick-Lösung anzustreben.
Ich nutze in einem Projekt Google Analytics + Google Adsense. Nach dem Urteil vom 12.10.19 ist klar, ich benötige ein Opt-In für beide Aktionen. Das Projekt beinhaltet ein Shop-System inkl. Besuchererkennung, Kontenverwaltung etc, dazu Kontaktformulare, eine OpenStreet-Anfahrtkarte usw.
Es ist nahezu unmöglich, das alles in einen einzigen Klick zu packen und es läuft wohl auf die Variante hinaus, das mit Anklicken des Opt-In-Fensters erst einmal ein Formular erscheint mit zig Checkboxen, zu jedem bisher nötigen Klick eine.
Und wenn der erste Einspruch zum Urteil eingeht, liegt die ganze Regelung auf Eis, so wie bei der Angabepflicht im Impressum. Auch nach 10 Jahren gibt es immernoch keine gültige  Rechtslage, was denn da nun wirklich rein muß.

Natürlich gibt es da auch einen Haken, die Daten, die Google Analytics dann noch bekommt, sind nahezu wertlos. Glaubt man den Studien dazu, verbieten jetzt schon auf den Seiten, die die Möglichkeit der Wahl lassen, mehr als 50% eine Nutzung von Analytics und es ist davon auszugehen, das dieser Prozentsatz steigt, je mehr Seiten die Abwahl ermöglichen. Analytics darf diesen Besuchern dann nicht mehr folgen und er erscheint mir in der Statistik als jemand, der nach Seite 1 sofort abgehauen ist. Und das betrifft dann plötzlich 50% meiner Besucher.
Analog bei Adsense. Im Prinzip investiere ich mein Geld dort nicht nur in ein paar Anzeigen auf Seite 1 der Suchergebnisse, sondern auch in der gezielten An- oder Bewerbung von Leuten, auch auf Seiten meiner Mitbewerber. Beispiel: Ich beschreibe und bewerbe eine Holzhackmaschine. Interessierte Nutzer stimmen der Adsense-Nutzung zu und bekommen nun in jeder erdenklichen Lage individuell ausgerichtete Werbung dazu, von mir und von art-ähnlichen Anbietern. Kennen wir alle. Such ich bei Ebay nach einem Fahhrad, erscheinen Vorschläge dazu auf jeder erdenklichen Webseite, meiner Lokalzeitung, dem Kicker usw.
Mit der Abwahl von Adsense ist mein investiertes Geld verloren, wenn die Leute, die potentielle Käufer gewesen wären, das Bewerben untersagen. Die Besucher werden dann eher Werbung der Mitbewerber erhalten, weil die noch nicht diese Ablehnmöglichkeit verbaut haben. So gesehen, bezahl ich dann sogar die Mitbewerber.

Ich persönlich war noch nie ein Freund von Analytics, Piwik & Co, aber mit solchen Studien muß man wohl auch den künftigen Sinn hinterfragen. Im beschriebenem Projekt bin ich nur Webmaster, der Eigner sah Analytics als seine Lösung an, Dinge zu hinterfragen, Inhalte zu ändern, Sachen zu testen, in der Hoffnung, das unterm Strich mehr Leute den KAUFEN-Button klicken. Ich sehe das immer ein wenig anders. Ich informiere mich gern über mögliche Varianten, aktuell über einen großen Fernseher. Ein 65-Zoll bekomm ich in meine Anbauwand, einen 75-Zoll könnt ich noch an die eine mögliche Wand hängen, alternativ vor der Anbauwand im Boden versenken. Brauch ich aber ein Taschentuch aus dem Fach hinter dem TV, muß ich den erst herunterfahren - doof, wenn das im WM-Finale passiert. Also lese und informiere ich mich gern. Und ich hätte gewiß schon mehr als 100 Geräte, würde ich überall auf Kaufen klicken.

Dem Endanwender (und nur die Wenigsten kennen die genaue Rechtslage) bleibt dann nur, auf Nummer Sicher zu gehen und im Zweifel eine Zustimmung zu Cookies einzubinden, die rechtlich aber oft garnicht notwendig ist. Auf meinen eigenen Webseiten habe ich diesen Klick mit der Zustimmung zu allen anderen anfallenden Cookies verknüpft, aber es befreit mich eben nicht von der Pflicht, in einem Kontaktformular den Opt-In für die Kenntnisnahme der DSGVO zu setzen, weil das schon wieder zwei unterschiedliche Punkte sind.
Der Klick im Formular unterrichtet den Besucher, das ich den Inhalt des Formulars bei mir speichere und auch verarbeite, z.b. weil ich ihm ja antworten möchte.

Im Grunde bräuchte es wohl ein Addon, das alle derzeit bekannten Datensammler beinhaltet, bequem per Liste erweiterbar ist und für jede Variante die Zustimmung oder Abwahl speichert. Für den User gibt es dann ein Popup oder Balken, Position frei wählbar im Backend, mit den Checkboxen, dem Link zur DGSVO usw wie man es aus dem großen Seiten (z.b. WP-Projekte) kennt.

[evaki]

 

Das "Problem" an eurer Lösung wäre halt: wenn doch mal eine (von mir aus auch optionale) Möglichkeit der weiteren Nutzung, auch inkl Permission durch den User integriert wird, seid ihr außen vor, da ihr den Cookie halt an anderer Stelle killt.

Genau, da war der anfängliche Gedanke das mit einem Zweittemplate zu lösen, was aber wieder verworfen wurde, weil es eben die Alternative sessionstorage, localstorage gibt, die zukünftig wahrscheinlich öfter mal zu sehen sein wird (html5). Darüber, ob damit dann alles abgedeckt würde habe ich mir aber noch keinen Kopf gemacht.

Ob ich aktuell nun das komplette Script habe, weiß ich immer noch nicht - zwischenzeitlich kam noch was dazu, das noch vor dem set header die vorhandene Session killen soll.

Ob das nun alles notwenig wird  wird wohl von der E-Privacy-Verordnung abhängen, wo dann sicherlich auch sessionstorage und localstorage dazugehört.

Ich finde es selbst nur spannend, daß sich Leute um sowas Gedanken machen und Lösungen dafür suchen, was mich selbst dann auch zum genaueren Hinschauen und Ausprobieren inspiriert. Bei mir hat's demzufolge (noch) nichts mit Sicherheitswahn zu tun. Der Gedanke dahinter ist ja meist, daß man den ganzen Klickschei... loswerden will, um ihn nur dort einzusetzen wo er wirklich erforderlich ist.

Erstmal gehe ich aber wieder in die Heia. Eine Impfung hat mich umgehauen. Alles ist furchtbar anstrengend. Also is jetz ersma Ände.

MfG. Evaki

[Gast]

Braucht das Captcha das Session-Cookie? Zumindest wird mir das aktuell so angezeigt.

Meines Wissens (und Manu möge mich korrigieren) braucht das Captcha lediglich eine (serverseitige + temporäre) Session, aber kein Cookie. Ein Cookie soll ja immer etwas dauerhaft speichern, z.b. eben die Entscheidung, ob Cookies angenommen werden dürfen oder nicht (cookie_permission).
Bei einem Captcha wäre solch Speicherung der Daten eher hinderlich. Das Captcha (die Matheaufgabe z.b.) wird temporär in der servereigenen Session gespeichert, dazu noch eventuell bereits eingegebene Formularfelder, um bei einem Fehler nicht nochmals alles tippen zu müssen.
Auf der Formularempfangsseite werden dann die Sessiondaten kontrolliert, nach erfolgreichem Versand werden die Sessiondaten per unset gelöscht.
Würde man sie nicht löschen oder gar speichern, wäre z.b. das Ergebnis der Aufgabe immer falsch, weil die Aufgabe bei jedem Reload wechselt, das Ergebnis bliebe aber gleich.
Nach dem Muster der temporären, serverseitigen Session arbeiten übrigens alle Frontendmodule, auch mpForm und Bakery.
Ausnahmen gibt es natürlich auch, z.b. in Templates mit Farbauswahl oder Modulen mit solchen Funktionen. Auch hier ist wieder der Sinn, das der User bei späterer Wiederkehr das gleiche Farbschema bekommt, also ganz im ursprünglichem Sinne der Cookies

Im Backend schaut es anders aus. Da erstellt z.b. die Optionsseite eigene Cookies, die dann beim Benutzer gespeichert werden und in diesem Fall den Status der Blocköffnungen speichern. Hat man z.b. den Block "Standardeinstellungen" geöffnet und verläßt dann die Seite, wird dieser Status gespeichert (bis der Cookie gelöscht wird). Kommt man irgendwann zurück, schaltet der Cookie genau die gleichen Blöcke wieder ein.

P.S.: soweit ich weiß, wird die WB-Systemsession (z.b. wb-8890-sid) für nix anderes mehr benutzt. Ich glaube, früher stand dort neben der Zeit des Betretens und dem letzten Access auch noch der Login drin zum Backend, ich glaube, das, was wir als Smart Login kennen.

Was allerdings ist:  der Cookie, den WB da erstellt, der wird bei jeder Aktion im Frontend (neu laden irgendeiner Seite dieser Domain) kontrolliert und erneuert bzw eben die last_Access-Zeitangabe aktualisiert. Wird der Cookie gelöscht, muß dann dann ebenfalls bei jedem Load passieren, aber ich denke, das ist in deinem Code schon drin.

Für mich als Endanwender stellt sich die Frage, ob ich überhaupt diesen System-Cookie setzen muß, wenn er doch im späteren Verlauf ungenutzt bleibt.
Das "Problem" an eurer Lösung wäre halt: wenn doch mal eine (von mir aus auch optionale) Möglichkeit der weiteren Nutzung, auch inkl Permission durch den User integriert wird, seid ihr außen vor, da ihr den Cookie halt an anderer Stelle killt.
Wie oben schon angeführt, ist es ein SystemCookie, ohne die Möglichkeit einer Identifikation und ohne Speicherung irgendwelcher persönlicher Daten und für diese Art Cookies braucht es immernoch kein Opt-In und das wird m.E. auch so bleiben, so gesehen also schon ein gewisser Sicherheitswahn

[evaki]

@jacobi22
Da die von mir angebotene Lösung auf dem Prüfstand steht, weil da noch Code fehlt(e) - krieg halt tolle Lösungen vorgestellt, aber nicht immer komplett oder auszugsweise, und steh' dann auf'm Schlauch, wenn's auf Anhieb nicht so funktioniert wie angepriesen, noch 'ne Frage, nachdem ich nun selbst drin wühle. Braucht das Captcha das Session-Cookie? Zumindest wird mir das aktuell so angezeigt. Damit ich nichts falsch interpretiere und nicht im Wald lande, wäre eine Antwort nicht schlecht. Aber auch 'ne Info, ob noch andere Module das Cookie benötigen, wäre willkommen.
MfG. Evaki

[Gast]

Das BE ist doch nicht öffentlich zugänglich. Und die paar Leute, die Zugang haben, sollten ja wohl mit einverstanden sein.

Sofern keine Sachen wie Google Analytivs, Piwik (Matomo) oder ähnliche Analysetools oder auch Google Maps etc mitlaufen, ist der leere, systembedingte WB-Frontend-Cookie immernoch einwilligungsfrei, weil dafür keine Daten erhoben werden.

[Concilla]

Jetzt muss ich noch einmal eine Frage stellen. Ich habe die Möglichkeit, einen RA diesbezüglich zu kontaktieren und nachzufragen, inwieweit unser WB-Session-Cookie einwilligungsfrei ist. Wenn ich es richtig verstanden habe, ist das Cookie für das FE nicht notwendig, wird aber trotzdem gesetzt, weil es im BE notwendig ist. Da es für das FE nicht notwendig ist, dürfte es nicht mehr einwilligungsfrei sein. Verstehe ich das richtig? Wie stelle ich also meine Frage an den RA?

[hgs]

Do you write a ticket for the next version so it doesn't get lost?
https://project.websitebaker.org/projects/wb-2-13/issues

[crnogorac081]

Sorry for english.

Maybe a little new feature in future release, a small bolean in users table if user wants or doesnt want login_cookie
So that you can choose in Users preferences -a dropdown - yes ( create cookie) , no(dont create)

It would be a small modification in code ,but it would satisfy gdrp for someones purposes..

[evaki]

@dbs
Bei dem Vorgang denke ich weniger an's Erlaubtsein im Sinne DSGVO, sondern auch an eine mögliche "strengere" E-Privacy-Verordnung, und natürlich an die, welche den "Kram" nicht haben wollen.

Ein Cookie mit der Kennzeichnung DELETE wird aktuell je nach Browser unterschiedlich interpretiert - verworfen oder ignoriert - , mit entsprechenden Tools natürlich "richtig" angezeigt.

Also wenn's die Browser nicht immer wissen, sollte man der EU Bescheid geben, wegen einer Browser-Verordnung, damit die Dinger endlich EU-tauglich werden. 

MfG. Evaki

[Concilla]

Wenn dieses Session-Cookie, welches notwendig, aber im Frontend ja eigentlich nicht notwendig ist, wirklich verschwinden würde, wäre das fantastisch. WB, eines der wenigen CMS, welches diesen ganzen Cookie-Schnickschnack mit lästigem Banner und einer A4-Seite in der DSE nicht braucht. Das wäre tatsächlich traumhaft

[dbs]

Wollte gar nicht "Logik" schreiben, hab nämlich keine. 
Der Session Cookie ist natürlich erlaubt, weil Session und nicht Tracking.
Session = notwendig, auch wenn bei uns nicht notwendig...

[evaki]

Damit sollte es janzwech sein, dat Plätzschen!!!

@dbs
Wenn Cookies bei EU gemeint sind, allein weil diese als Datei spezifiziert sind, liegts Du mit der Logik vorn. Aber wenn dieses ohne individuelles Merkmal daherkommt, da ist 'ne Session ohne Cookie ja jaaaanz persönlich dagegen , stimmt das nicht mehr inhaltlich.

Aber wir haben ja noch die Möglichkeit auch dieses Cookie zu unterbinden.
MfG. Evaki

[Concilla]

Das schicke ich Concilla mal per PM zum Testen zu.

Oh, das wäre ja ganz lieb von Dir