Neu Cookie Manager zum EuGH Urteil zum selbsteinbau

[MichaelH]

Interessant ist das viele Webseiten auf das gar nicht reagieren, siehe die großen Player wie NewsPortale usw.

Das ist richtig, es gibt nur wenige Ausnahmen.
Doch wir müssen hier bei JTL sicherlich frühzeitig dranbleiben damit wir auch etwas bekommen. 😉

Nach meiner Meinung sollte ein Shop der in der EU vertrieben wird dieses Plugin automatisch mitliefern, zumindest für den Shop und die Plugin die der Shop selbst enthält - also ausgenommen zugekaufte die nicht in der Lizenz enthalten sind.
Ansonsten kann der Shop gar nicht rechtssicher in der EU verwendet werden.

Beispiel:
Ich kann ein Radarwarngerät kaufen, ganz legal, aber ich darf es nicht verwenden ohne eine Strafe zu riskieren.
So ähnlich wäre es dann mit dem JTL-Shop. 😉
OK, das Beispiel hinkt etwas ...

 

[hula1499]

Hier wären dann Vorschalt-Lösungen an den entspr. Stellen z.B. auf der Zahlarten-Seite geeigneter. Aber ist die Frage, ob Amazon / PayPal hier mitspielen und in welchem Rahmen man hier Änderungen vornehmen darf, ohne gegen deren AGBs oder Markenrecht zu verstoßen.
Vorgeschaltete Opt-Ins für die Sichtbarkeit von Payment-Buttons würden auch deren Conversion-Rate deutlich verschlechtern

? Versteh ich überhaupt nicht.
Ich entscheide ob ich PP/Ama Pay anbiete und wenn es eben Pflicht sein sollte, dass der Kunde da einwilligt, steht es mir frei, den Dienst nicht anzubieten (und wie in meinem Beispiel ein JTL Plugin zu haben, das mir dann zb. Ama Pay session bedingt abdreht).
Was soll da gegen irgendwelche AGBs oder Markenrechte verstossen?

Na selbstverständlich verschlechtert dass die Conversion. Meine aber genauso, wenn ich hier irgendwelche Klickorgien veranstalten muss.

WENN! Ama/PP/etc nicht erlaubt ist, nutzt irgendein externes 5 zeilen Script sowieso nichts, dann muss ein JTL Plugin her (von wem auch immer).

Nachtrag: hier müssen sich die ganzen Zahlungsanbieter auf die Beine stellen. Es ist in deren interesse, dass alles "erlaubt" ist.
Es kann ja dann auch passieren, dass PP Wall abgedreht wird, oder wie auch schon hier jemand sagte -> dann dreh ich komplett Ama Pay ab und brauch keine Klickorgie beim Kunden oder dahinter irgendwas spezielles.

 

[david]

Wir hatten vor längerer Zeit bei einem Zahlungsplugin im Entwicklungsprozess eine eigene Payment-Button-Grafik inkludiert, farblich leicht an das Evo-Theme angepasst und datenschutz-freundlich.
Wir mussten die Lösung entfernen und durch die entspr. JavaScript-Widgets ersetzen, das Plugin wäre sonst nicht abgenommen worden. Als Entwickler muss man sich an die Vertragsdetails halten.
Ich nenne den Namen des Anbieters nicht. Ist im Prinzip auch egal, die Brand Usage Guidelines und Vertragsdetails sind bei allen großen Anbietern recht strikt.
Auch wenn ihr euch eine solche angepasste Lösung selbst baut - das Risiko ist, dass diese Lösung nicht von dem jew. Anbieter abgenommen wird.
Der Druck auf Zahlungsdienstleister und auch auf Big Player wie Google / Facebook wird jetzt allerdings größer - durch euch und durch die Politik. Das ist auch gut so.

Die einzig sinnvolle Lösung ist aus meiner Sicht, Third-Party-JavaScript-Widgets wieder durch selbst-gehostete Button-Grafiken zu ersetzen.
Mit Vorschalt-Lösung meinte ich so etwas: https://www.heise.de/ct/artikel/2-Klicks-fuer-mehr-Datenschutz-1333879.html
D.h. bei Klick auf die Buttongrafik öffnet sich die jew. Datenschutz-Information und dann kann den Dienst dann aktivieren oder es immer noch ablehnen. Bei Aktivierung wird der Button durch den JS-Button ersetzt. Die Benutzerwahl wird dann für die Session gespeichert.

 

[MichaelH]

Diese Lösung sieht super aus und kann auch jeder Kunde / Nutzer rasch verstehen, sofern sie sich auch durchsetzt.

Allerdings gibt es unterschiedliche Cookies.
Und daher ist immer noch ein Cookie-Manager nötig ?

Wie schon geschrieben, mir fehlt die Gesamtübersicht und wer macht oder liefert was für den JTL-Shop in seinem "Standard" und den mitgelieferten Plugin.
Wird es hier ein Update von JTL geben ?
Wenn ja, wann ?
Wenn nein, warum nicht ?
- Und wenn nein, warum ist das in der Wartung nicht enthalten, wenn dies zum Lieferumfang gehört und es eine rechtliche Software-Anforderung in der EU ist ohne deren Erfüllung man den Shop gar nicht verwenden kann ?
- Es ist kein Inhalt, wie ein Impressum & Co, sondern Programmcode.

 

[hula1499]

@david
Ich schätze ja deine Erfahrung und Meinung sehr, aber hier liegst du wirklich falsch - oder wir reden komplett aneinander vorbei.

Bei meinem "Lösungsvorschlag/ansatz" verstosst du in keinster Weise gegen irgendwelche Vertragsdaten, AGB´s, Gentleman agreements oder was auch immer.
Hier gehts lediglich um ein/ausblenden und nicht um ein Verändern der CI. Da gibts 0 Risiko und keinerlei Bedarf auf irgendeine Abnahme von Ama Pay/PP oder wem auch immer.

Wer natürlich Zahlungsbuttons optisch verändert und somit nicht mehr CI konform geht und/oder freigegebenes geschütztes Material verändert -> ja natürlich sind das gleich - auch rechtlich - mehrere Verstösse, hat aber auch gar nichts damit zu tun, was ich geschrieben hab.

Ob jetzt eine Lösung wie von mir angedacht:
1.) Kunde bekommt KEIN! cookie (ausser JTL, technisch notwendig) vorab und muss sofort entscheiden für tracking, retargeting, PP, Ama Pay etc
oder
2.) eine reinen Blindbutton, der, erst durch klick, einen Cookie Hinweis einblendet und um Bestätigung ersucht
ist beides ok, mit Vor- und Nachteilen.

Vorteil Variante 1: man ist nicht wieder auf die einzelnen Pluginhersteller abhängig, Ihren langen Laufzeiten, erforderlichen Absprachen mit Firma Y und Z - viel flexibler.
Recht "schnell", Plugin unabhängig einsetzbar (solang sich Verkünpfungen und session bedingtes deaktivieren einrichten lassen).
Nachteil Variante 1: Klickorgie und möglicher Conversionverlust

Vorteil Variante 2: optisch schöner, intuitiver und weniger "nervig" für den Kunden.
Nachteil Variante 2: Abhängig von JTL und Solution360 + allen Anbietern von CC (Mollie, wirecard, payone usw usw usw). Java.

Für beides gibts nichts - kein Pluginhersteller, weder JTL mit PP noch Solution360 mit Ama Pay, hat sich noch konkret darüber geäussert.

Sollten wir jetzt wirklich nicht das Ama Cookie haben dürfen und das PP Wall Cookie, dann sind natürlich die jeweiligen Anbieter in der Pflicht, hier Lösungen bereit zu stellen.

Jeder ordentliche Kaufmann muss schaden von seiner Firma abwenden und - sollte es nichts geben (und es Pflicht sein/werden, was wir ja noch nicht wirklich konkret wissen), darf keiner der Shops mehr diese Sachen anbinden/einbinden.
Wers doch macht, handelt halt grob fahrlässig.

 

[david]

Ja, wir haben aneinander vorbeigeredet 😉 Ich suche eigentlich nur nach einer benutzerfreundlichen Lösung, die ich bei diesen Consent-Manager-Ansätzen aktuell stark vermisse.
Rein technisch sind die von dir vorgeschlagenen Lösungsvarianten beide machbar, allerdings kann man im Fall von PayPal/Amazon halt nicht explizit nur deren Cookies aussperren.
Man kann das initiale Laden der Lösungen unterbinden - also rein technisch. Dann würde man standardmäßig kein PayPal und kein Amazon sehen, bis der User seine Einwilligung dazu gegeben hat.

 

[MichaelH]

"Dann würde man standardmäßig kein PayPal und kein Amazon sehen, bis der User seine Einwilligung dazu gegeben hat. "

Ja, aber kann man das nicht sichtbar machen mit Text oder so irgendwie und wenn der User klickt also sein OK gibt, dann wird das Plugin mit PiPaPo erst geladen ?
Man kann die Zahlungsart ja anführen und wenn der Kunde dann PayPal will dann gibt er seine Zustimmung und es geht normal weiter.

Denn dein Ansatz mit "Aktivierung durch Klick" finde ich gut, statt vorab schon alle Cookies abzufragen.

Es ist nun mal ein Hürdenlauf geworden, nun müssen wir wieder einen Weg auf die freie Bahn finden.

Auch wenn hier Änderungen im Shopcode nötig sind, dann sollte das JTL aber nicht davon abhalten es auch zu tun.
Es geht hier doch um Einiges !

 

[martinwolf]

Denn dein Ansatz mit "Aktivierung durch Klick" finde ich gut, statt vorab schon alle Cookies abzufragen.!

Das obligt dann aber dem Anbieter des jeweiligen Plugins, da kann JTL nicht viel machen. Beesonders bei Amazon Pay ist die Implementierung anders als eine herkömmliche Zahlungsart.

 

[hula1499]

Beesonders bei Amazon Pay ist die Implementierung anders als eine herkömmliche Zahlungsart.

Bis alle SP, einzeln, da irgendwas gemacht haben, alles den Zahlungsanbietern vorgelegt haben etc. dauert das wieder "Jahre".
Dann wird noch das (interne) Argument kommen: dafür wurden wir von Paymentanbieter X nicht extra bezahlt... usw

Ein übergreifendes Plugin wär hier effizienter und flexibler.

 

[eRock Marketing]

Ein Plugin welches eines der Cookie Tools (oder wegen mir zwischen den 2-3 "besten" entscheiden lässt) ist schnell gebaut.
(Wenn ihr mir 2-3 gewünschte Cookie Anbieter nennt bau ich das gerne zusammen, auch ohne den nervigen Hook 140, sodass wir trotzdem performant bleiben)

Aktuell kann man dies mit etwas Know-How ja auch selbst machen, via:
- Dropper
- Template Anpassung
- Plugin Individual Code
- oder auch möglich (aber unschön): Über die Boxenverwaltung im z.B. Footer eigenes HTML (respektive die JavaScript Snippets) einbinden

aber ich werde mit der ganzen Sache insgesamt noch nicht warm. Nach meiner Auffassung wird keiner zusätzliche freiwillige Cookies akzeptieren.
Demnach ist der richtigere Weg eigentlich die Cookies (bis auf für das System notwendige) zu eleminieren - ist im Endeffekt gleich, da es wie angesprochen sowieso kaum einer akzeptieren wird.
Die Schwierigkeit: Was ist dann mit den Funktionen? Und wenn es "nur" das Tracking ist. Die SEA Agenturen schreien hier auf "wir brauchen das, sonst können wir gar nichts mehr optimieren".

Kurzum: Als Plugin Fremdlösungen für die Cookies zu integrieren ist schnell gemacht. Ein eigenes Plugin welches auch die Cookie-Richtlinie selbst (ohne Fremdlösung) realisiert, hätte die gleichen Schwierigkeiten wie externe Lösungen: Man kann nicht alle Cookies kennen. Denn die Cookies vom Shop sind essentiell, es geht daher eher um die Cookies die von Templateanpassungen und/oder Plugins generiert werden, und die kann ein Servicepartner auch nicht alle kennen.
Ich tendiere aktuell zur Lösung nicht notwendige Cookies zu eleminieren.

 

[hula1499]

Ich tendiere aktuell zur Lösung nicht notwendige Cookies zu eleminieren.

Definitionssache.
Was ist wichtig, was nicht und für WEN ist was nicht wichtig 🙂

Tracking = wichtig
Remarketing = super wichtig (ich will gar nicht in meine Listen schaun, wie viele Tage/Wochen ich allein für unser remarketing verwendet hab)
conversion tracking = mega wichtig (tja, das wird noch blöd werden...das mag rechtlich kein relevantes sein, aber wenn ich da den kunden um erlaubnis fragen muss, kann ich AdWords/Bing etc gleich ausbauen...)

Zahlungsanbieter = ultra super mega wichtig 😀

 

[eRock Marketing]

Wichtig != Notwendig.

Natürlich ist Remarketing super wichtig, verstehe ja auch den Aufschrei der SEA Agenturen, wie soll man profitable Kampagnen entwickeln? Wie häufig schließen wir Suchbegriffe auf Grund der Statistikdaten aus. Mit diesen würde sich die ganze Kampagne nicht lohnen. Hier kann man noch ein wenig mit arbeiten, die Parameter können ausgewertet werden. Aber in Remarketing Kampagnen wäre es das k.o.

Ich gehe dabei wie gesagt davon aus: Keiner wird z.B. die Marketing-Cookies aktivieren, demnach: Ist es wie als wäre das Tracking dafür erst gar nicht implementiert.

Zahlungsarten ja absolut: Das muss aber ohne Cookies gehen. Ist es nicht z.b. für Solution360 eine Möglichkeit das Plugin noch als kostenpflichtige Version "Ohne Cookies" anzubieten?
Die Schwierigkeit hierbei liegt natürlich definitiv daran wann ziehen die SP nach. Was mir nicht ganz bekannt ist: Können die Plugins nicht ohne Cookies arbeiten? Sprich wie wäre es mit einem Lösungsansatz dass gewisse Cookies einfach wieder gelöscht werden (sprich keine Einverständnisabfrage vom Kunden, sondern diese unmittelbar wieder entfernen, anders machen es die Cookie Plugins ja auch nicht).

 

[martinwolf]

Sprich wie wäre es mit einem Lösungsansatz dass gewisse Cookies einfach wieder gelöscht werden (sprich keine Einverständnisabfrage vom Kunden, sondern diese unmittelbar wieder entfernen, anders machen es die Cookie Plugins ja auch nicht).

Dann müsste das Löschen mit jedem Seitenaufruf passieren. Jenachdem was das Cookie dann genau macht, wurden hier ggf. schon Daten gesammelt und gesendet und erst dann gelöscht. Bringt also nichts. Will man gewährleisten, dass Cookies keinerlei Funktion erfüllen, dürfen diese erst garnicht gesetzt werden.

 

[eRock Marketing]

Richtig, genau das machen auch die externen Cookielösungen wie cookiebot.
Gegen das vorherige "setzen" kommt man nicht an, außer den "Verursacher" zu eleminieren (was bei manchen nicht möglich sein wird).

Ein Cookie an sich sendet ja nichts, erst Skripte die es dann verarbeiten.

 

[hula1499]

Wenn ich keine Cookies für AdW/Bing/FB/IG etc. mehr setzen darf automatisch und den User wirklich danach fragen muss (nochdazu ohne automatisch gleich "aktiviert" angekreuzt zu haben)...
Wie du vollkommen richtig sagst, wirds keiner freiwillig anklicken (mach ich ja natürlich auch nirgends) = wertlos und kann komplett ausgebaut werden.

Jo, ein Cookie darf gar nicht gesetzt werden, wie Martin schon sagt, du wurdest damit ja schon protokolliert, es muss daher generell unterbunden werden gesetzt zu werden, bei einem "nein".

 

[eRock Marketing]

Jo, ein Cookie darf gar nicht gesetzt werden, wie Martin schon sagt, du wurdest damit ja schon protokolliert, es muss daher generell unterbunden werden gesetzt zu werden, bei einem "nein".

Einzige Lösung: Das Plugin nicht einsetzen. Die Erstellung des Cookies kann nicht unterbunden werden, außer im Plugin/Skript/... ist der Code für das setzen vom Cookie nicht mehr vorhanden (oder steht hinter einer Abfrage ob diese Art von Cookies erlaubt sind). Solch eine allgemeine Lösung kann leider keiner bieten (nach meinen Kenntnisstand)

 

[hula1499]

Darauf wirds auch rauslaufen, wenn keiner was baut 😉
Alle Plugins (sobald mal rechtssicherheit dafür überhaupt besteht) müssen deaktiviert werden.

Laut meinem Kenntnissstand kann man sehr wohl mit einem Plugin ein anderes Plugin - session technisch - unterbinden/deaktivieren.
Somit wär das mal kein Problem bei Ama Pay und PP Wall, Kreditkarten iframes, Klarna etc.

Behebt aber natürlich nicht das desaster mit AdW/Bing/conversion tracking.

 

[eRock Marketing]

Mir ist diese Funktion nicht bekannt, Cookies generell zu verbieten, wäre dann auch für das Session-Cookie nicht hilfreich.
Mal unabhängig davon dass man diese Cookies braucht, geht man davon aus das voll zu unterbinden:

Cookies können ja aus 2 Quellen stammen:

PHP
Im Ablauf von PHP wird ein Cookie gesetzt. Das ist kein Speichervorgang wie man sich das z.B. bei einer Datenbank vorstellen kann.
Via PHP wird vom Plugin gesagt "ich will das Cookie testcookie erstellen". All diese Cookies werden dann in den "Header" (nicht HTML head, sondern die mitgesendete Kopfzeile einer Webseite) gespeichert der vor der ersten Zeile Ausgabe gesendet wird.
Hier könnte man in der Tat noch vor der Ausgabe sagen "so aus den 4 zu setzenden Cookies entferne mir 3 Stück". Dann kommt nur 1 Cookie beim Besucher wirklich an und auch nur dieser wird gesetzt.
Als Plugin gäbe es 2 Ansätze: Alle zu entfernenden Cookies angeben, oder eben alle zu speichernden Cookies angeben. Problem: Der eigentliche Shopbetreiber kann damit nichts anfangen, da es zu technisch ist. Der PLuginhersteller hingegen kann nicht alle Cookies kennen, auch nicht die "notwendigen" den ein Plugin selbst kann ja auch wirklich notwendige Cookies erstellen für seine Pluginfunktion. *
Aber auch das ist nicht ganz sicher, beispiel im Ablauf:
- Plugin A setzt ein Cookie
- Plugin B hat keine Cookies ist aber im Shop aktiv
- Plugin Z löscht alle Cookies (bis auf notwendige).
- Header wird gesendet & Shopseite wird ausgegeben

Wenn nun in Plugin B eine Ausgabe erfolgt (durch einen Bug, oder auch bewusst), dann wäre es:
- Plugin A setzt ein Cookie
- Plugin B hat keine Cookies ist aber im Shop aktiv
- Plugin B hat für eine minimale Ausgabe gesorgt, damit wird der Header gesendet und das Cookie beim Besucher gespeichert!
- Plugzin Z löscht alle Cookies (bis auf notwendige)
- Shopseite wird ausgegeben

Hier kann man nichts machen, zudem hat der JTL Shop auch mehrere Weiterleitungen drin. Da kann das gleiche Problem auftreten:
- Plugin A setzt ein Cookie
- Shop leider auf den Warenkorb weiter, da ein Artikel in den Warenkorb gelegt wurde und eingestellt wurde dass er dann auf den Warenkorb weiterleitet
- Plugin B,... Z kommen nicht zum Einsatz, da vorher abgebrochen wurde
Diese Weiterleitung wird ebenfalls nicht "sofort" gemacht sondern an den Besucher geschickt "hey du willst Seite x Aufrufen, die sagt aber ich soll dich weiterleiten: hier ist die URL auf die du dich nun bitte begibst"
Und genau das passiert wieder im Header des Dokuments, in dem auch der Cookie aus Plugin A drin steht. => Hier kann ebenfalls kein Setzen verhindert werden.


JavaScript
Diese werden gesetzt während die Seite geladen wurde (oder im Ladevorgang selbst). Und diesen Vorgang kann man nicht unterbinden, wenn hier der Befehl kommt "ich will ein Cookie xy" dann wird es sofort gesetzt, ohne Eingriff oder ähnliches. Ggf. kann man die Standardfunktionen von JavaScript überschreiben welche Cookies setzen wollen, das könnte man noch prüfen - sicher bin ich mir aber nicht und man kommt wieder zu den gleichen Problem wie oben.

Kurzum: Ich bin insgesamt nicht der Meinung dass es Lösungen gibt das zu unterbinden. Ansätze ggf. ja, aber nicht ausreichend. Sicher ist nur die Lösung es wieder zu löschen wenn es gesetzt wurde.

* P.S.: Ich kann leider nicht genau definieren wo notwendige Cookies anfangen und wo diese aufhören. Wie ist es z.B. mit der Auflösung? Mobil ja/nein haben ja mehrere drin (als Cookie) - gehört der zu den "notwendigen Cookies"? Gleiches zählt z.B. für Cookies die technisch gesetzt werden (wir setzen z.b. ein http2push cookie ein).

 

[301Moved]

Wenn ich keine Cookies für AdW/Bing/FB/IG etc. mehr setzen darf automatisch und den User wirklich danach fragen muss (nochdazu ohne automatisch gleich "aktiviert" angekreuzt zu haben)...
Wie du vollkommen richtig sagst, wirds keiner freiwillig anklicken (mach ich ja natürlich auch nirgends) = wertlos und kann komplett ausgebaut werden.

Aber genau das ist ja jetzt passiert? Tracking Cookie für Ads/Bing/Facebook/etc darf man nicht mehr setzen und nicht mehr als aktiviert angekreuzt haben. Damit ist das Theme meiner Meinung nach komplett wertlos...

 

[david]

Hier eine Einschätzung der IT-Recht-Kanzlei, was als "technisch notwendig" gilt und was nicht:
https://www.it-recht-kanzlei.de/notwendige-nicht-notwendige-cookies.html#abschnitt_2

Die Zahlungsanbieter-Cookies stehen dabei in der Rubrik technisch notwendig. Ein genaueres Statement dazu gibt es im Kommentar hier.

Tracking/Affiliate/Remarketing/Retargeting-Dienste und deren Cookies sind grundsätzlich verboten, es sei denn man holt eine informierte Einwilligung beim Besucher ein.
Um genau diese Art von Cookies ging es im jüngsten EuGH-Urteil.

Ein Consent-Manager für diese Art von Diensten/Cookies ist natürlich diskutabel.
Ob so ein Konstrukt zur Begrüßung seiner u.U. teuer bezahlten Besucher in einem Shop überhaupt Sinn macht, ist auch diskutabel.