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

[evaki]

EuGH Entscheidung
Vorläufige Lösung:
In WB den mehrmals vorgeschlagenen Header einsetzen, um jegliches Plätzchen beim Zugriff zu vermeiden. Bei Anwendungen wo Cookies erforderlich sind, kann auf zweites Template umgeschaltet werden - mit den geforderten Informationen und Auswahlmöglichkeite n.

Der Adminbereich sollte per Robots.txt und Sitemap ausgeschlossen werden.
Die WB-Mitbenutzer sollten entsprechend informiert werden.

Das alles wurde schon einmal gesagt, und? 
MfG. Evaki

[dbs]

Shice Thema.
Hättest noch paar Links reinpacken können. Ich weiß nicht mehr wo was steht.

Eigentlich habe ich bis jetzt nur einen einzigen Cookie-Banner verbaut und da hat man die Wahl zwischen OK und Nein.
Aber da ist nur der WB Session-Cookie, trotzdem sollte ein Banner zu sehen sein (auf Wunsch).
Den hatten wir mal als notwendigen Cookie eingestuft, oder? Aber das spielt jetzt keine Rolle mehr. Weil der Cookie nicht notwendig ist im Frontend und weil trotzdem gefragt werden muss vor dem Anlegen.

[evaki]

Vorerst, bevor uns irgend jemand noch schlauer macht, gilt es wohl nur für Tracking-Cookie 
Zwingend vorgegeben ist hierbei Opt-In.

Für Session-Cookie gilt wohl weiterhin der Ausnahmegrund bei berechtigten Interessen, wo einer der Gründe die Funktionsfähigkeit der Website herhalten soll/muß.
Das ist aus technischer Sicht aber nicht zwingend. Es braucht beim ersten Zugriff zur Session kein Cookie. Aus der Session heraus läßt sich immer noch ein dazugehöriges Plätzchen plazieren.

Es ist also garnicht soooooo unwahrscheinlich, daß in einer weiteren Richtlinie auch hierbei ein Opt-In vorgeschrieben wird. Es würde aber auch ohne Vorschriften Websitebetreibern gut zu Gesicht stehen.

Sehe in letzter Zeit häufiger Sites, die Auswahlmöglichkeite n offerieren, wo Session-Cookies per Kreuzchen zwar voreingestellt, aber trotzdem abwählbar sind. Es geht also.
 
MfG. Evaki

[evaki]

Hättest Du sicherlich auch gefunden; dieser war der erste ausführliche, der mir sich zeigte.

Code: [Select]

https://datenschutz-generator.de/eugh-cookie-einwilligung-banner-detailinformationen-pflicht/Interessant die Anmerkung im Kommentar:
"Die Regelung, wann ein Cookie unbedingt erforderlich ist, lässt sich dem. Art. 5 Abs. 3 der ePrivacy-RL nicht eindeutig entnehmen."

MfG. Evaki

[dbs]

Ja, hätte ich sicher gefunden. Ich meinte Links hier im Forum. 
Aber eigentlich beruhigt mich das schon wieder, wenn es nur um Tracking geht.
Sowas mache ich kaum, und wenn, wie bei Google Analytics, kommt der Banner rein mit Ja/Nein.
Social-Plugins verwende ich nicht, nur Links zu deren Seiten.
Wenn uns die Frontend-Session-Cookies nicht auf die Füße fallen, ist alles gut.

[dbs]

Eine Abfrage ob Ja/Nein zu Cookies ist inzwischen klar, aber wie sieht es mit Dokumentation aus.
Muss das nachweisbar irgendwo gespeichert werden wer wann wie wegen Cookies gestimmt hat?
Wenn dann wahrscheinlich wer Ja gesagt hat und wann.

[evaki]

Eine derartige Dokumentationspflic ht wird m.E. aufgrund Masse technisch nicht realisiert werden können. War da nicht auch was mit Datensparsamkeit?
- "Wen sein Cookie wech is", kann aber bei der NSA anfragen. 
So gehe ich davon aus, daß wenn Cookies genutzt werden, die Funktion der Unterrichtung entsprechend DSGVO/e-privacy-Verordnung gewährleistet sein muß bzw. sollte, so wie man sowieso zur regelmäßigen Überprüfung einer Website angehalten ist, was nicht wenige "vergessen" (cms läuft ja  ).
MfG. Evaki

[evaki]

Bin ich - ups - nicht drauf eingegangen:

Muß das nachweisbar irgendwo gespeichert werden...

Dann wäre die Speicherung von individueller IP, Zeit etc. nötig, was nicht erlaubt ist.
Zu alledem würde sich wie bei der sogenannten Vorratsdatenspeiche rung die Frage nach der Aufbewahrungszeit, wie auch dem Löschzeitpunkt stellen.
MfG. Evaki
 

[dbs]

Es geht wahrscheinlich nur um Tracking-Geschichten.
Wenn es hier zu rechtlichen Auseinandersetzunge n kommt, stehst du mit Beweisen besser da (könnte ich mir vorstellen).
ala: Der Kläger hat seine Einwilligung gegeben am Tag x um Uhrzeit x mit dieser IP und diesem Gerät zu diesem Consent-Text.

Wer erhellt uns?

[evaki]

Der Knackpunkt ist allein schon die erfaßte IP.
Hier greift die DSGVO, wo dem Websitebetreiber die nicht anonymiserte Erfassung nicht erlaubt ist.

Was für ein Rechtsfall schwebt Dir da vor, wo eine Erfassung der gesetzten Cookies sinnvoll sein soll?
Gruß, Evaki.

[offtopic]Gucke gerade Beitrag zu Synchrotronstrahlun g Brauche so'n Gerät für auf'n Schreibtisch[/offtopic]

[dbs]

Ich komme überhaupt erst darauf, weil ein Shopbesitzer eine Info vom Händlerbund erhielt mit diesem Link:
https://www.haendlerbund.de/de/news/aktuelles/rechtliches/3144-wichtige-fragen-rund-um-die-cookie-entscheidung-des-eugh

Darin wird ein Consent-Tool empfohlen (https://usercentrics.com/de/). Eine Plattform, die ein Script bereitstellt zur Einbindung auf der eigenen Webseite um die verschiedenen Cookies zu erlauben/zu verbieten und zu managen. Diese Plattform speichert das.
Zitat aus dem Punkt Dokumentation:

"Gemäß Art. 7 Abs. 1 DSGVO müssen sämtliche Einwilligungen dokumentiert werden. Website-Betreiber unterliegen nach DSGVO einer Beweispflicht und müssen im Falle einer Abmahnung oder eines Audits der Datenschutzbehörde die Einwilligungshistor ie vollständig vorlegen können.

Damit die Einwilligung einer Prüfung standhält, sollten diverse Datenpunkte mitgeschrieben werden, zum Beispiel Timestamp, User-Agent oder die Version der Einwilligungstexte. Auch abgesetzte URL-Calls sollten geloggt werden, um nachzuweisen, dass keine Cookies ausgespielt wurden, bevor die Einwilligung nicht vorlag."

[evaki]

Da rückt Deine Vermutung in den Vordergrund.

Es geht wahrscheinlich nur um Tracking-Geschichten.

Davon gehe ich aus, z.B. bei einem Shop - eine datenverabeitende Stelle mit diversen Pflichten - , wo Du nicht nur ein Session-Cookie setzt, sondern auch unter anderen eines oder mehrere für die Verkaufsabwicklung, inkl. für die Dokumentation. Aber eben nur dafür, wobei hier nach aktueller Rechtsprechung trotzdem vorher eine Einwilligung eingeholt werden muß.

Wo ich aber Bedenken habe bzw. hätte -Bedenken - bin nun mal kein Anwalt, und habe z.Z. keine Rechtsabteilung in meinem Arbeitsumfeld - , wenn eine derartige Einwilligung schon beim Betreten der Website gefordert wird, nicht erst beim Klick für den Kaufvertrag.

MfG. Evaki

[dbs]

Der Händlerbund empfielt ein paar OnlineTools. Darunter auch kostenlose.
Tools Überblick

Eins davon ist zum Selbsthosten: https://www.oiljs.org
Das werd ich mir mal ansehen

[evaki]

Hab' leider - noch - keine Zeit zum reingucken.
Jedenfalls sind die Vorstellungen gut genug, um beachtet zu werden, solange in WB Cookies nicht an-, ab- oder zuwählbar sind. Session Cookies fallen bei WB trotzdem an. Ob das dann einen Mehrwert hat? Fällt bei Fremdhosting nicht die Erwähnung in der Datenschutzerklärun g und ein Auftragsdatenverarb eitungsvertrag an? Da war doch was. Bin schon wieder zu lange aus diesem Thema raus.
MfG. Evaki
ps. Session Cookies sind mir persönlich und auch einigen Anwendern "ein Dorn im Auge". Sollte hier eine "Verschärfung" eintreten - ist ja immer noch nicht restlos geklärt - ist es mit provisorischen Übergangslösungen vorbei.

[dbs]

Ja, denke mal muss erwähnt werden. Wer nichts trackt braucht solche Tools wohl nicht.Braucht man Google Analytics? Ich mags nicht. Die Google WebmasterTools werden dafür immer besser.

[evaki]

[offtopic]
Ist eher an DEV gerichtet, aber nun: Gibt es eine einfache Möglichkeit für FE und BE getrennte Cookie-ID zu generieren (wb1234-id-FE session / wb1234-id-BE samesession) ?
[/offtopic]

[evaki]

Noch'n Wort zum Topic (Header setzen)
Mittlerweile wurde diese Vorgehensweise mehrfach wiederholt, weil auch das Agrument "setzt Cookies ohne Inhalt" ausgeräumt ist. Man kann das Plätzchen löschen. Das BE betrifft es sowieso nicht, weil dort "alles wie gehabt" abläuft.
Die Vorbehalte, daß Module oder das FE-Login nicht mehr funktionieren würden, treffen nicht zu.
Sind dann doch noch Sessions mit und ohne Speicherung in einzelnen Modulen gefragt, läß sich das per sessionstorage bzw. localstorage realisieren (zusätzliches JS)  Im Netz gib es einiges zu "HTML5 Web Storage".

Aktuelle Browserliste:
https ://caniuse.com/#feat=namevalue-storage
HTML5 Web Storage:
https ://www.w3schools.com/html/html5_webstorage.asp

Um überhaupt mal "HTML5 Web Storage" in Aktion zu sehen, gibt's z.B. das
https ://www.smashingmagazine.com/2019/08/shopping-cart-html5-web-storage/#lostcats

MfG. Evaki

[evaki]

Man kann das Plätzchen löschen.

Soll heißen: Man kann das eigentlich vorgesehene Plätzchen vor der Ausgabe an den Browser löschen.

[Concilla]

Vorläufige Lösung:
In WB den mehrmals vorgeschlagenen Header einsetzen, um jegliches Plätzchen beim Zugriff zu vermeiden.

Was für ein Header ist denn hier gemeint? Ich kann leider nichts dazu finden oder weiß nicht wirklich, was gemeint ist :- (

Danke im Voraus.

[evaki]

Gemeint sind diese Beiträge:
List Header
Re: Cookies
Bei den dort angegebenen wird das Cookie auf DELETED gesetzt.
Werden die Parameter derart gesetzt, daß erst gar keine Ausgabe erfolgt, also nicht den Client erreicht, gilt es das HTML zu puffern - sinnvollerweise - steht so auch irgendwo in phpnet, wenn ich recht erinnere.
MfG. Evaki

[Concilla]

Super! Vielen Dank. Ich habe dieses so

Code: [Select]

header("Set-Cookie: wb-5727-sid=0; token=deleted; path=/; Max-Age=-0;  expires=Thu, 01 Jan 1970 00:00:00 GMT");
umgesetzt und habe damit keine Session-Cookies mehr vom WB auf meiner Seite. D.h., da die Seite auch keine anderen Cookies hat, hat sie nun 0 Cookies. D.h. auch, man kann nun den gesamten Schnickschnack in der DSE was Cookies betrifft weglassen, denke ich mal...

[evaki]

habe damit keine Session-Cookies mehr

So ist es ein DELETED, also ein Cookie ohne jeglichen Inhalt.
Darüber, ob dies, weil nur eine leere Datei beim Zielrechner ankommt, die also jegliche Funktion verloren hat, noch eine rechtliche Bedeutung hat, nur weil es ein Cookie ist, kann bezweifelt werden.
Wie erwähnt, läßt sich das Cookie auch ganz unterdrücken.

Wählt bzw. gebraucht man z.B. für eine Session die Alternative sessionstorage, bekommt man die Session ohne Cookie. 
Das kann man dann individuell auf z.B. ein Modul beschränken.
MfG. Evaki

Nachtrag Was fehlt:
if($wb->is_authenticated()) {
  } else{ header("Set-Cookie: wb-5727-......................................................);   }


Das is_authenticated() ist gesetzt für den Fall, daß man mit ein und demselben Browser in beides geht, also FE und BE. Wenn im FE gelöscht wird, bekommst Du zwangsläufig Probleme im BE - keine wirklichen, aber es nervt seeeeeehr  .

[evaki]

gesamten Schnickschnack in der DSE was Cookies betrifft weglassen, denke ich mal...

Nicht ganz, denn das BE benutzt und braucht sinnvollerweise nach wie vor die Cookies.

Abhilfe:
Zugang per robots.txt "verwehren", und die Besucher/Nutzer unterrichten, brauchts aber nur auf der BE-Zugangsseite.

MfG. Evaki

[dbs]

Darüber, ob dies, weil nur eine leere Datei beim Zielrechner ankommt, die also jegliche Funktion verloren hat, noch eine rechtliche Bedeutung hat, nur weil es ein Cookie ist, kann bezweifelt werden.

Also hier sagt meine Logik, dass es immer um Cookies ging und nicht um deren Inhalt. Da würdest du bestimmt verlieren.
Die if-Abfrage könnte helfen.
Irgendwann gibt’s auch mal eine Unterscheidung zwischen Frontend- und Backenduser, aber soweit sind wir noch nicht.

[Concilla]

Sorry, das verstehe ich jetzt nicht ganz. Da bin ich technisch zu wenig bewandert.

dbs schreibt:

Die if-Abfrage könnte helfen.

Kann ich mit so einer Abfrage denn das eine einzige Session-Cookie verhindern? Im Frontend zumindest? Also so?

Code: [Select]

if($wb->is_authenticated()) {
  } else{ header("Set-Cookie: wb-5727-sid=0; token=deleted; path=/; Max-Age=-0;  expires=Thu, 01 Jan 1970 00:00:00 GMT");   }