General Community > Off-Topic

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

<< < (9/11) > >>

jacobi22:

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

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


--- Quote ---warum der spiegel.de keinen Cookie-Banner zeigt
--- End quote ---

weil diese Seite keine persönlichen Identifikationsmerk male 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:

--- Quote ---ob nun mit einer Dauerschleife wie in deiner Lösung oder ganz gezielt.
--- End quote ---
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.
--- Quote ---Kuchen des Datensammelns möchte der Browser
--- End quote ---
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 "?".


--- Quote ---Erst, wenn ich dann anmeldepflichtige Angebote nutzen möchte, 
--- End quote ---
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





jacobi22:

--- Quote from: evaki on October 27, 2019, 07:53:40 AM ---
--- Quote ---ob nun mit einer Dauerschleife wie in deiner Lösung oder ganz gezielt.
--- End quote ---
Die Dauerschleife schmeißt gezielt die WBeigene Session raus, womit der Weg für eigene Sessions/Cookies frei wird, falls diese gebraucht werden.

--- End quote ---

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

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

jacobi22:
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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version