General Community > Off-Topic

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

<< < (8/11) > >>

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

jacobi22:

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

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 Formularempfangssei te 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 "Standardeinstellung en" 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:
 (Y) (Y) (Y)

--- Quote ---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.
--- End quote ---

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

jacobi22:

--- Quote ---weil es eben die Alternative sessionstorage, localstorage gibt
--- End quote ---

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 Wiedererkennungswer t 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:

--- Quote ---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.
--- End quote ---
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ß :D


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 Ordnungswidrigkeite n zusammenkamen. Da bleibt ein Rentner sicherlich gleich zuhause.

MfG. Evaki

Navigation

[0] Message Index

[#] Next page

[*] Previous page