Genau - der Button „alles akzeptieren“ ist explizit nicht zulässig. Der User muss selbstständig die Cookies anwählen und dann akzeptieren.
Laut
Aus Usability-Sicht natürlich ziemlich doof, aber rechtlich nun notwendig.
Ein sehr verbreitetes Tool von usercentrics (https://usercentrics.com/), die sich dem Thema verschrieben haben, hat auch einen „Alles akzeptieren“ Button. Hier entscheidet der User sich ja explizit mit seiner Einwilligung, dass er alle Cookies akzeptiert – ich denke das ist rechtlich auf jeden Fall ok, zudem das Tool auch von e-Recht24 propagiert wird.
Bitte macht zumindest einen Konfiguration in das Plugin, dass sich der Button „Alle akzeptieren“ optional anzeigen lässt. So wie das Tool jetzt geplant ist, ist es usability-technisch ein Gau. Da wäre es besser auf sämtliche Tracking- und Marketing-Cookies zu verzichten, nur damit der Wahnsinn nicht angezeigt werden muss. Ich denke wenn der User die Einstellungen generell selektiv vornhemen muss, wird er eher immer auf „Ablehnen“ klicken und das ganze Tracking und Marketing ist ohnehin hinfällig.
Ich werde das mal mit unserer Rechtsberatung besprechen. Aber das Urteil sagt klar aus, dass jeder Cookie aktiv zugelassen werden muss. Selbst wenn es so einen Button gibt, müsst ihr jedes Tracking und dessen Zweck einzeln aufführen und beschreiben, denn das muss bei Akzeptierung bekannt sein, eine Verlinkung auf die Datenschutz Erklärung reicht da nicht. Also wird der Hinweis dann schnell 1/3 der Seite einnehmen. Unsere empfohlene Lösung wird das nicht sein.
Schon klar, dass jeder Cookie einzeln aufgeführt werden muss und eine selektive Zustimmung möglich sein muss, aber das kann jeder ja unter den Details machen wenn gewünscht. So wie das auch bei dem Beispiel von usercentrics ist. Ihr könnt ja den Button optional anbieten, per default auf off und mit (nicht empfohlen) kommentieren, dann kann jeder selber entscheiden ob er das will
Ich bin mal gespannt wie die Conversion Rate runtergeht. Das man alles manuell zustimmen muss und nicht sagen kann passt scho ist zum k… wer wird dann da anklicken dass Analytics okay ist? Richtig: niemand.
Denke ich auch mal, dass das kaum noch einer anklickt! Dann kann man sich im Prinzip auch die Analyse-Tools sparen und das Consens-Tool auch.
Ach ja, da war ja noch was: Google Analytics wird von Firefox blockiert! Tracking wozu denn noch?
Ich weiß nicht, ob das generell so ist - also in der Grundeinstellung. Aber ich habe das Problem in den eigenen Browsern (Firefox und Chrome). Bei der Installation auf den Geräten wurde die Privatsphäre eingestellt.
Dadurch kann ich kaum herausfinden, welche Cookies auf der eigenen Seite gesetzt werden und ob die blockierten aufgrund des Consenttools blockiert sind oder durch den Browser. Die Anzeige im Browser ist generell nicht zuverlässig. Da werden mir bekannte Cookies manchmal angezeigt und manchmal nicht. Sie müssten aber dauerhaft da sein… (Livechat z.B.)
Ich verwende ein Consenttool aus dem Store. Nach dem letzten Update stehen im ersten Fenster drei Buttons zur Auswahl (Alle akzeptieren, alle ablehnen und konfigurieren) und eine kurze Auflistung der Cookies, die mit „alle aktzeptieren“ akzeptiert werden. In Konfigurationsfenster ist dann alles ausführlich.
Wenn ich die Cookies auf der eigenen Seite nun noch zuverlässig finden würde, wäre alles gut…
Um das Ganze ad absurdum zu treiben, auch PayPal und AmazonPay setzen Cookies. Ich kann nicht beurteilen, ob diese rein technisch bedingt oder ob hier auch welche zu Marketing-Zwecken im Einsatz sind.
In der Konsequenz würde das dann heißen, dass auch die diversen Zahlungsweisen erst mal gesperrt werden müssen, falls hier Tracking- und Marketing Cookies zu Einsatz kommen. Die User, die Cookies verweigern haben dann am Schluss evtl. nur noch Vorkasse und Nachnahme
Wir werden jetzt auf jeden Fall erst mal Analytics entfernen, damit es nicht jetzt schon zur Abmahnung kommt, das Consent-Tool dauert ja scheinbar noch ein wenig.
Soweit ich weiß, gehören die Cookies der Zahlarten zu den “technisch notwendigen” Cookies.
Um Bestellungen zu generieren bedingt ein Onlineshop nunmal gängige Zahlarten.
Aktuell arbeiten wir mit dem Plugin von @codiverse in der aktuellsten Version ganz gut.
Das Tracking wird erst aktiviert, sobald das Cookie-Consent durch den Besucher (Hinweis auf Cookies inkl. Einverständnis) bestätigt hat.
Aktuell listen wir auf der Datenschutz-Seite detaillierte Cookie Informationen auf, bis die Lösung von Shopware umgesetzt wurde.
Soweit ich weiß, gehören die Cookies der Zahlarten zu den „technisch notwendigen“ Cookies.
Um Bestellungen zu generieren bedingt ein Onlineshop nunmal gängige Zahlarten.
So hat es die ITR auch kommuniziert. Bei Stripe und dem „alten“ Paypal-Plugin werden die Cookies erst auf der Zahlungsseite gesetzt.
Ein versierter User hier hat aber festgestellt, dass das neue Plugin von PP von Anfang an etwas trackt. Daher kommt es bei uns nicht zum Einsatz. Es gibt einen größeren Thread zu diesem Plugin hier im Forum.
Soweit ich weiß, gehören die Cookies der Zahlarten zu den „technisch notwendigen“ Cookies.
Um Bestellungen zu generieren bedingt ein Onlineshop nunmal gängige Zahlarten.
ja, aber wie kann man sicher sein, dass PayPal & Co. neben den technisch notwendigen nicht noch Cookies für Tracking- und Marketing-Zwecke einsetzt.
Aktuell habe ich von PayPal eine ganze Latte an Cookies drin stehen, einen auch mit value „google“
Soweit ich weiß, gehören die Cookies der Zahlarten zu den „technisch notwendigen“ Cookies.
Um Bestellungen zu generieren bedingt ein Onlineshop nunmal gängige Zahlarten.
So hat es die ITR auch kommuniziert. Bei Stripe und dem „alten“ Paypal-Plugin werden die Cookies erst auf der Zahlungsseite gesetzt.
Ein versierter User hier hat aber festgestellt, dass das neue Plugin von PP von Anfang an etwas trackt. Daher kommt es bei uns nicht zum Einsatz. Es gibt einen größeren Thread zu diesem Plugin hier im Forum.
Das wäre aber auch für einen Abmahner nicht ganz risikofrei sich auf die Payment-Cookies einzuschießen. Hier müsste vor Gericht dann sehr aufwändig nachgewiesen werden, dass PayPal hier mehr als eine technisch notwendige Funktionalität zur Verfügung stellt. Das wird ohne „Zeugenaussage“ von PayPal oder ein teures technisches Sachverständigengutachten ncht möglich sein. PayPal-Cookies dürften sich für einen Shopbetreiber relativ leicht als „technisch notwendig“ argumentieren lassen, so dass ein Abmahner Gefahr läuft sich vom Gericht eine Ohrfeige einzufangen und abzublitzen.
Bei Facebook und Analytics ist der Fall halt klar und damit relativ risikoarm für einen Abmahner. Bei den Zahlungsdiensten begibt sich ein Abmahner selbst auch auf dünnes Eis, weil er hier schon glaubhaft darlegen muss, wo die technische Notwendigkeit aufhört und das Marketing-Tracking anfängt.
Vom “neuen” PayPal würde ich die Finger lassen. PayPal bekundet für *sich* zwar ein “berechtigtes Interesse”, aber so geht das nicht. ICH als Seitenbetreiber muss MEIN “berechtigtes Interesse” für die PayPal-Kekse definieren und auch erklären können - geht aber nicht, weil ich nicht sagen kann, für was PayPal diese Keksorgie benötigt.
Ob ein Cookie technisch “notwendig” ist, lässt sich alleine schon dadurch feststellen, dass man sie mal blockt. Ich blocke eh schon seit Jahren *Drittcookies* - also auch die vom PayPal im Shopware-Schnüffelplugin. Und was soll ich sagen: Ich kann dennoch in Shopware-Shops mit PayPal bezahlen, auch wenn sie “Unified” einsetzen.
Es geht ja nicht nur darum, dass PayPal ggf. den Kunden tracked. Sofern das Iframe in den Details, im Listing oder der Canvas-Cart für den Express-Button geladen wird, kann PayPal ein wertvolles Profil zum Shop anlegen. Und das PayPal diese Daten zu Geld macht, ist ja kein Geheimnis. Noch kritischer ist aber das AMAZON-Plugin. Wer das einsetzt, lässt für AMAZON die Hosen runter.
Aber das ist ja schon zum Erbrechen im “Datenpetzen-Thread” ausdiskutiert
@sonic wir nutzen das neue PayPal-Plugin, binden es aber ohne iFrame ein. Heißt man wird erst nach Bestellabschluss zum externen PayPal-Login weitergeleitet. So bekomme ich keinen einzigen Cookie im Shop von PayPal.
Ich finde lexoffice (www.lexoffice.de) hat das gut gelöst. Eine Vorauswahl der notwendigen Cookies, den Rest kann man auswählen. Erklärung gibt es auch dazu mit Klick auf weitere Informationen. Man kann die Auswahl bestätigen oder alles auswählen und bestätigen.
@Tineu das was die da machen bei lexoffice wird aber vermutlich nicht reichen, denn es muss wohl jedes einzelne Cookie aufgeführt werden. Eine Zusammenfassung von mehreren Cookies als “Tracking” wird beispielsweise wohl nicht reichen.
Also ich finde die Lösung wie bei Lexoffice gut, wo hast Du die Information her das man jedes einzelne Cookie benennen muss @FloC3?
Es ging doch viel mehr darum, das der Seitenbetreiber vorauswahl gemacht hat und der Kunde so nicht direkt zugestimmt hat. Ehr als Bequemlichkeit einfach auf weiter geklickt hat.
Wenn man das wie hier macht, mit erklärung in form eines PopUp. Muss der Kunde sich damit beschäftigen und lesen, alles andere steht doch in einer Ordentlichen Datenschutzerklärung.
@sonic wir nutzen das neue PayPal-Plugin, binden es aber ohne iFrame ein. Heißt man wird erst nach Bestellabschluss zum externen PayPal-Login weitergeleitet. So bekomme ich keinen einzigen Cookie im Shop von PayPal.
Diese Strategie ist laut Trusted Shops wiederum abmahnbar, da für den Kunden nicht ersichtlich ist, wann die Bestellung wirklich ausgelöst wird
In unserem TS Audit wurde das als Problem angeführt. Wir haben extra von Secupay auf Stripe als Kreditkartenanbieter gewechselt, um dieses Problem zu beseitigen.
Also gibt es anscheinend keine komplett rechtssicheren Lösungen. Man muss sich eben entscheiden, welches Risiko man eingeht. Ohne Risiko gehts nicht.
Deshalb lassen wir erstmal die Cookies der Zahlungsanbieter drin. Vielleicht ändern Paypal und Amazon ja noch ihre Plugins entsprechend.
Lt. unserer Rechtsberatung ist ein anhaken von „Gruppen“ ohne die Möglichkeit einzelne Funktionen (bspw. Google Analytics) abzuwählen nicht mehr erlaubt. Entsprechend werden wir das auch so nicht umsetzen. Den „Alles akzeptieren“ Button wird es wohl geben, aber dann mit Hinweis, dass man den Einsatz mit seiner Rechtsberatung abklären muss.
Beim Amazon Pay Plugin liegt die Schuld meiner Meinung nach beim Entwickler (BestIT). Statt sich an die Konventionen zu halten, wie sie Shopware mit dem PayPal-Plugin vorgibt und bestimmte Javascripts nur zu laden, wenn diese benötigt werden (Express-Button sichtbar bzw. im Checkout), lädt das Amazon Pay Plugin einfach immer den ganzen Kram.
Ich habe inzwischen den JS-Code (der übrigens echt nicht gut ist) selbst angepasst, um das Laden der JS-Dateien vom Amazon-Server zu verhindern, wenn keine Buttons angezeigt werden. Vorteil: Erst ab Warenkorb (und Warenkorb-Overlay) wird das alles geladen. Bonus: Die Seite ist schneller. Nachteil: Die Anpassungen muss ich bei jedem Update wieder einspielen.
Beim PayPal-Plugin von Shopware reicht es den Express-Button nicht auf Detailseite und in den Kategorien anzuzeigen. So wird auf diesen Seiten nichts vom PayPal-Server geladen.
Rein rechtlich ist es wohl nicht das „Problem“ des Shopbetreibers, welche Cookies über die Zahlungsarten-Anbieter gesetzt werden, solange das in einem eigenen iframe passiert. Das ist natürlich wenig tröstlich, weil ich diese Art des kompletten Ausspionierens auch nicht leiden kann. Das Entfernen der Express-Buttons von allen Seiten, die nichts mit dem Kaufprozess zu tun haben (und das Sicherstellen, dass auch wirklich nichts geladen wird), ist aus meiner Sicht die einzig sinnvolle Konsequenz. Es hat übrigens nichts an unserer Conversion-Rate geändert.
