Ja eingebundene Bilder und Skripte sind generell so ein Problem. Das Partner-Logo von Idealo ist auch so ein Übeltäter, welcher Analytics-Cookies setzt und die Besucher des Onlineshops analysiert.
Problematischer sind die Zahlungsplugin(s)
welche wären das denn? Habe noch nicht gesehen, dass PayPal, Klarna & Co Cookies setzen…
meinst du das Plugin hier? Das ist ja nicht so gut bewertet…
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“) prüft ihr das zeitnah intern mit Trusted Shops und Anwalt?
Was den “Shop” selber betrifft, sehe ich auch mit dem Urteil noch keine Probleme.
Aber was Plugins betrifft, könnte es jetzt wirklich kritisch werden. Da denke ich direkt wieder an die Datenpetze “PayPal Unified”. Die per iframe nachgeladenen Buttons setzen ja dutzende Trackingcookies. Und die sind technisch NICHT notwendig. Auch wenn man alle Kekse von PayPal blockiert, funktioniert der checkout. Auch das von “PayPal” angeführte “berechtigtes Interesse” kann nicht greifen, da PayPal gar kein “berechtigtes Interesse” auf fremden Seiten für sich reklamieren kann.
Also zumindest bei “PayPal” der neuen Generation und auch den AMAZON-Buttons würde ich jetzt aber sowas von hellhörig werden 
@sonic aber wenn ich PayPal klassisch einbinde, habe ich ja keine Cookies oder?
diesen komischen PayPal-Button haben wir nicht drin. Auch kein PayPal Express.
was die Shop-Funktion angeht, hast du vermutlich recht. Das fällt ja alles unter „technisch für den Betrieb nötig“.
Google Analytics / Tag Manager ist halt katastrophal wenn man das extra angeben und aktivieren muss… das aktiviert doch niemand, und damit ist Tracking quasi fürn A****
Also php-seitig funktioniert der Cookie Modus schon so, dass er auch bei Plugins automatisch greift.
Wenn Daten von einer anderen Seite kommen (iframe, javascript) usw. muss das explizit implementiert werden.
Werde das die Tage mal durchsprechen
Kann ich nichts zu sagen, ich habe nach wie vor das alte 3.5.x im Einsatz.
Wenn aber kein Expresscheckout im Artikel/Listing oder im Warenkorb vorhanden ist, also keine Buttons eingebunden werden, dürfte es OK sein. Einfach mal alle Seiten bis zu Confirm durchgehen und gucken, ob Kekse auftauchen.
@sonic ja da hab ich echt keine Cookies so, passt. Aber wären nicht Zahlungsarten eigentlich “technisch für den Betrieb notwendig” ?
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”) ist die Frage was ist, wenn man dieses Plugin nutzt? Das bindet halt den Tag-Manager ein …
Ja… aber auch nein
Man muss da immer gucken, was passiert wann.
Solange ich eine Zahlungsart nicht verwende (ich = Kunde), besteht technisch keine Notwendigkeit, dass Cookies gesetzt werden.
Im Fall PayPal ist es technisch nicht notwendig, dass PayPal schon im Listing oder Artikel bei jedem Seitenaufruf Cookies setzt - und javascript nachlädt, auch nicht im Warenkorb (insbesondere in der Canvas Cart,die wird ja auf JEDER Seite geladen - also Tracking durch PayPal, wie Kunde sich im Shop bewegt).
Es geht schlicht auch ohne, somal an dieser Stelle ja auch nicht feststeht, ob diese Zahlart gewünscht ist. Schon vor dem Urteil war dieses Plugin schon umstritten.
Warum muss für eine Zahlart ein gesondertes Cookie gesetzt werden? Die Zahlung wird ja nicht im Shop, sondern auf der Seite des Anbieters (Amazon, Stripe, Paypal) abgewickelt. Was DORT passiert, hat dann ja nichts mit meiner Seite zu tun. Die “technische Notwendigkeit” ein Keks zu setzen, nur weil ich einen (Express-)Button einbinden möchte, dürfte im Streitfall schwer zu belegen sein.
Aber zu meinem Lieblingsplugin “PayPal” gibt es ja hier das Datenpetzen-Thema 
1 „Gefällt mir“
Bei uns mit Shopware 5.5.10, Datenschutz-Einstellungen für den Cookie-Banner “Technisch notwendige Cookies erlauben (Browser-Sitzung, CSRF), restliche nach Erlaubnis setzen”, sieht’s so aus dass mit dem ersten Aufruf der Seite bereits 35 Cookies geladen werden, bevor man im Cookie-Banner “Ablehnen” oder “Einverstanden” geklickt hat.
Die meisten davon stammen von PayPal, aber es ist auch Amazon und Facebook dabei (FB-Pixel über dieses Plugin eingebunden) und abmr.net sowie eine Handvoll von unserer eigenen Domain, wobei ich bezweifle dass die alle technisch notwendig sind, weil da auch welche dabei sind die vom Namen auf Amazon oder PayPal Funktionen schließen lassen.
So wie sich das für uns gerade darstellt ist die Cookie-Einstellung von Shopware alles andere als safe.
Ja, da müssen sich die Plugins auch alle reinhängen.
Paypal macht das aktuell denke ich nicht, wie die anderen Plugins das Handhaben, keine Ahnung.
Es gibt auch keine andere Lösung als die, dass es jedes Plugin selbst machen muss - wir setzen einen Cookie, wenn Cookies erlaubt sind und anhand dessen, kann ein Plugin entscheiden, ob es die eigenen Cookies setzen darf. Gerade Facebook, Amazon und Paypal setzen die Cookies i.d.R. über ein Iframe, heißt hier konkret, man müsste überall die Buttons ausblenden, solange es kein Opt-in gibt.
Für Paypal hab ich das mal aufgenommen: Shopware Issuetracker
Alles andere müsstet ihr den jeweiligen Herstellern melden. Ein Beispiel wie man das umsetzen kann, gibt es ja bspw. bei der aktuellen Version von SwagGoogle.
eigentlich ist das echt ein Supergau wenn das so durchgeht… Drittanbieter-Plugins nutzen ist damit wohl erstmal vom Tisch, außer die Hersteller reagieren alle…
PayPal nutzen wir wie ich oben beschrieben habe, so gibts auch keine Cookies. Nicht mal im Checkout. Weiterleitung zu PayPal am Ende der Bestellung reicht ja eigentlich aus.
einzige Sorge die wir haben, ist das Thema Google Analytics und Tag Manager.
die IT-Recht-Kanzlei schreibt ja das hier:
1.) Informationen und Auswahlmöglichkeiten für alle eingesetzten Cookies
Wird ein Banner oder Tool beim erstmaligen Aufruf einer Website angezeigt, muss in diesem Banner für jedes eingesetzte Cookie eine sprachlich einfach gefasste Information darüber ergehen,
- welche Verarbeitungsvorgänge mit dem Cookie vorgenommen werden,
- welche Akteure an den Verarbeitungsvorgängen des Cookies beteiligt sind und
- welche Funktionen diese Akteure erfüllen
Jedes Banner oder Tool muss über ein Auswahlmenü verfügen, bei dem jedes eingesetzte Cookie einen eigenen aktivierbaren Menüpunkt darstellt. Keine Auswahlmöglichkeit darf voraktiviert bzw. „angetickt“ sein.
und so eine Funktion hat der Cookie-Layer von Shopware ja gar nicht. Er informiert ja nur, man kann nicht wählen welche Cookies man will und welche nicht.
Dann müssen wohl @codeenterprise für das Facebook-Pixel Plugin ran, und natürlich alle weiteren Plugin-Programmierer die in irgendeiner Weise Dienste einbinden die Cookies setzen.
Sonst setzen die alle den Shopbetreiber einem enormen Rechtsrisiko aus. Wie sieht’s da eigentlich jusristisch aus, in Sachen Haftung? Wenn sich ein Plugin nun nicht an die Cookie-Settings der Shopware Datenschutz-Einstellungen hält und es deswegen zu einer Abmahnung kommt: kann der Programmierer dafür haftbar gemacht und in Regress genommen werden?
Oooh Mann… die EU legt uns allen ein Ei nach dem anderen und bemüht sich mit aller Vehemenz das Internet abzuschaffen. So ein Mist… welcher habwegs normale Shopbetreiber soll das alles noch umsetzen können, wenn selbst die Programmierer es nicht schaffen? Ich meine, dass sich nicht mal das SWAG-PayPal Plugin an die Settings hält und das SWAG Google Plugin auch erst seit der vorletzten Version seit letzter Woche, macht mich als Anwender echt nachdenklich welchem Risiko ich da ausgesetzt bin, und es nicht in der Hand habe für Abhlfe zu sorgen. (Außer den Shop abzuschalten)
Ja, da müssen sich die Plugins auch alle reinhängen
Die Shopware selbst aber auch, nicht mal das funktioniert zuverlässig. Ich hab gerade den Cookie-Hinweis testweise umgestellt auf „Cookies erst nach Erlaubnis setzen“ und trotzdem werden beim ersten Laden der Seite (alle Cookies und Cache gelöscht, in neuem Inkognito Fester geöffnet) schon über 20 Cookies gesetzt, davon 5 oder 6 von unserer eigenen Domain, der Rest von extern wie PayPal usw.
Es ist ein Unding, dass die Shopware Cookies platziert obwohl man als Shop-Betreiber anhand der Einstellungen etwas anderes gewählt hat, auf das man sich auch gern verlassen würde. Damit bringt ihr den Shopbetreiber u.U. in echte Schwierigkeiten.
*hmm*
Zumindest 7 bei mir: “erst nachfragen” eingestellt, cache geleert (Shop Konfiguration, Template und HTTP), alle Cookies gelöscht, Browser geschlossen, Aufruf der Seite - Overlay und… :
Das sollte so aber nicht sein!
ich sehe schon… da kommt was auf uns zu … und ich hoffe dass Shopware uns hier nicht alleine lässt. Ich bin zwar Programmierer, hab aber keine Lust den “Murks” von Shopware zwecks Cookies gerade biegen zu müssen, irgendwo dirty im Core. Ganz zu schweigen davon, dass ich als Agentur das allen unseren Kunden ja berechnen muss… wer mir das wohl bezahlen will… ist doch ein “Standard-Feature”.
nicht zuletzt die Nicht-Programmierer, die haben hier ja gar keine Chance das korrekt zu machen.
*hmm*
Zumindest 7 bei mir: „erst nachfragen“ eingestellt, cache geleert (Shop Konfiguration, Template und HTTP), alle Cookies gelöscht, Browser geschlossen, Aufruf der Seite - Overlay und… :
Das sollte so aber nicht sein!
Also das eine ist schonmal ein Backend-Cookie. Und der x-cache-context-hash wird erst nach dem Login gesetzt. Glaube da ist was in deinem Test schief gelaufen.
Auf der Detailseite gibt es glaube aktuell noch einen Bug, den schauen die Kollegen sich gerade an, aber auch da geht es glaube nur um den Session Cookie.
Ich hoffe, egal was ihr findet, was in die richtige Richtung korrigiert wird, auch noch in Shopware 5.5 oder 5.6 kommt. Wegen sowas ein großes Upgrade auf Shopware 6 zu machen, würden dann viele Shopbetreiber vermutlich wahnsinnig machen.
Das steht ja außer Frage, dass es eine Anpassung in Form eines Patch-Release geben wird. Haben wir bisher ja immer so gemacht.
So:
Plugins auf “Sicherheitsmodus” gestellt, im Performance-Modul alle Caches gelöscht.
Aus dem Backend abgemeldet.
Im Chrome alle Cookies zur Seite gelöscht, Browsercache geleert.
Browser beendet. Chrome neu gestartet.
Startseite von meinem Testshop aufgerufen: Alle obigen Cookies - bis auf das Backend-Cookie - sind wieder da, inkl. x-cache-content-cache.
Wüsste nicht, was ich derzeit noch alles “falsch” machen könnte.
Wo der Browser dann immer das “lastCheck…” ausgegraben hat, bleibt mir ein Rätsel.
Request URL: https://testshop.demmoritz.bekannt/
Request Method: GET
Status Code: 200
Remote Address: 85.13.142.132:443
Referrer Policy: no-referrer-when-downgrade
age: 231
cache-control: no-cache, private
content-encoding: gzip
content-type: text/html; charset=UTF-8
date: Tue, 01 Oct 2019 17:17:15 GMT
server: Apache
set-cookie: x-cache-context-hash=deleted; expires=Tue, 01-Oct-2019 17:17:15 GMT; Max-Age=0; path=/; httponly
set-cookie: nocache=deleted; expires=Tue, 01-Oct-2019 17:17:15 GMT; Max-Age=0; path=/; httponly
status: 200
vary: Accept-Encoding
x-content-digest: en93c01e0a86a171581f46b6b8ac2319ceff2cc55e552b7ff9070ffde5362b15aa
Schau einer *guck*
Der Moritz lässt sich die Cookies via Console anzeigen, ich aber per “Rechtsclick auf dem Schloss in der URL-Bar”.
Dort bekomme ich Cookies angezeigt, in der Console nicht. *Was mir zu Denken gibt*
Aber im Response sieht man ja auch, das zumindest zwei gesetzt werden.