document.write ersetzen

[Yogilein]

Hallo,

zuerst einmal: Frohe Ostern!

Ich möchte für eine neue Umsetzung einer alten Idee folgendes Konstrukt nutzen:

<script>document.write("<script src='https://www.yogizaehler.de/Besucherzaehler/z_020_006.php?id=0000000000&&anz="+localStorage.getItem('YZ020')+"'><\/script>");</script>

Das funktioniert auch super, aber Google mahnt an, evtl. zukünftig so ein Konstrukt zu blocken, da die Zeile mit document.write erstellt wird.

Das Netz empfiehlt, so etwas mit innerHTML zu machen. Doch da wird weder </script> noch <\/script> akzeptiert.

Im Prinzip will ich an den Dateinamen xxx bei <script src='xxx'></script> eine Variable anhängen. Gibt's es dafür noch eine andere Möglichkeit?

 

[mikdoe]

Warum lässt du das äußere

<script>document.write("

und

");</script>

nicht einfach weg?

 

[Yogilein]

Weil dann die Variable nicht übertragen wird.

Mittlerweile habe ich aber eine etwas umständliche Lösung über Ajax gefunden, die ich aber sehr gerne ersetzen möchte.

 

[mikdoe]

Welche Variable wird wohin nicht übertragen?

 

[Yogilein]

Das angehängte localStorage.getItem('YZ020') wird nicht an die aufgerufene Datei z_020_006.php übermittelt.

Laut meiner Recherche ist dieses Verhalten auch richtig so, da normalerweise mit dem Befehl ausgelagertes Javascript geladen wird und da muss keine Übergabevariable übertragen werden, sondern diese ist nach dem Laden einfach vorhanden.

Ich rufe aber eine php-Datei auf, die dynamisches Javascript erzeugt. Das funktioniert super, nur wie gesagt, kann ich keine Variable übergeben. Festwerte dagegen gehen.

Und über das document.write wird eine neue Zeile erzeugt, bei der dann der Wert von localStorage.getItem('YZ020') steht und das wird daher nicht mehr als Variable gesehen. Nur Google warnt davor, dass diese Vorgehensweise zukünftig geblockt werden kann.

 

[mikdoe]

Du hast da ein komisches System. Das kapiere ich nicht.
Wie viele Jahre hast du das jetzt und musst ständig mit viel Zeitaufwand Krücken bauen. Gibt es da keine "normalen" Lösungen für?

 

[Yogilein]

O. k., ich hole mal etwas aus:

Ich erstelle hobbymäßig Besucherzähler. Ich bin dabei auch ganz gut nach oben gekommen, u. a. weil ich Features anbiete, die es sonst nirgendwo gibt.

Ein sehr beliebtes Feature war, dass der Stand nur dem Homepage-Betreiber angezeigt wird und alle anderen Besucher lediglich eine Uhr sehen. Umgesetzt hatte ich das Ganze damals über ein Cookie, das der Betreiber mittels eines Passwortes auf seinem Rechner anlegen konnte. Und immer wenn PHP das Cookie vorfinden konnte, lieferte es den Stand aus, ansonsten lediglich eine Javascript-Uhr. Das hat sehr gut funktioniert und ist auch sehr gut angekommen. Leider funktioniert seit geraumer Zeit diese Vorgehensweise nicht mehr, da die Browser mittlerweile die sogenannten Drittanbieter-Cookies blocken, wenn keine generelle Freigabe vorhanden ist. Somit habe ich viele Kunden verloren.

Ich wollte aber nicht aufgeben und bin auf die Idee mit den vom Browser gespeicherten Cache-Werten gekommen, denn diese werden nicht geblockt. Doch wie bringe ich diese nach PHP? Normalerweise lade ich den Zähler über <script src=... Hiermit rufe ich eine PHP-Datei auf, die den Zählercode komplett per Javascript generiert. Aber in PHP kann ich den Browser-Cache nicht abfragen. Also muss ich den Wert übertragen. Dieser Wert darf aber nicht fest vorgegeben sein (denn sonst würde er bei allen funktionieren), sondern muss per Variable übergeben werden, die natürlich nur beim Betreiber korrekt befüllt wird.

Das Anhängen von Variablen funktioniert aber nur, wenn ich die Code-Zeile per document.write erzeuge. Und es funktioniert aktuell wirklich sehr sehr gut. Aber Google warnt, dass diese Funktionalität zukünftig geblockt werden könnte. Dann wäre ich genauso dumm dran, wie jetzt mit den Cookies. Also suchte und suche ich eine andere, einfache Möglichkeit. Umgesetzt habe ich es jetzt so, dass der erste Aufruf ein Javascript erzeugt, das dann alle Daten per Ajax an den Server übermittelt. Ich sehe aber den Nachteil, dass somit zwei Requests stattfinden, einmal das Laden des Javascripts mit dem Ajax-Code und anschließend das Laden des Zähler-Codes. Gut, ich könnte auch den kompletten Ajax-Code zum Einbinden in die Homepage bereitstellen, aber das möchte ich nicht, da viele der Anwender schon bei einem Einzeiler Schwierigkeiten haben, diesen in ihrer Homepage unterzubringen.

 

[mikdoe]

...Browser mittlerweile die sogenannten Drittanbieter-Cookies blocken...

Was genau liegt in der allerneuesten Variante auf dem Kundenserver und was bei dir auf dem Server?

Was meinst du mit

...vom Browser gespeicherten Cache-Werten...

?

...Das Anhängen von Variablen...

Welcher Code hängt etwas an und wo geht das Ergebnis hin?

 

[Yogilein]

Was genau liegt in der allerneuesten Variante auf dem Kundenserver und was bei dir auf dem Server?

Auf dem Kundenserver liegt nur der Aufruf für die Ajax-Datei. Diese wird dann auf den Kundenserver geladen und ruft den eigentlichen Zähler auf.

Was meinst du mit ?

Man kann direkt im Browser-Cache Daten speichern. Entweder temporär für die Sitzung oder dauerhaft. Dauerhaft heißt bis zur Löschung des Caches, was i. d. R. der Browser selbst nicht macht. Somit habe ich eine Variante zu den Cookies. Allerdings wird der Browser-Cache nicht im Header - im Gegensatz zu Cookies - auf meinen Server übertragen.

Welcher Code hängt etwas an und wo geht das Ergebnis hin?

Gemeint hatte ich, dass ich bei <script src="... nur Festwerte vorgeben kann, z. B. <script src="meineSeite.php?farbe=rot'> Gebe ich nun zusätzlich die Variable an, die den Browser-Cache ausliest, funktioniert das nicht. Das sieht dann so aus <script src="meineSeite.php?farbe=rot"+&localStorage.getItem('YZ020')>
Erzeuge ich aber diese Zeile mit document.write, funktioniert es tadellos und der Browser-Cache-Wert wird mit übergeben. Google meint dazu aber in einer Warnmeldung:

A parser-blocking, cross site (i.e. different eTLD+1) script, https://www.yogizaehler.de/Besucherzaehler/z_020_006.php?id=0000000000&anz=null, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.

 

[Yogilein]

so sollte es heißen:

<script src="meineSeite.php?farbe=rot&anz="+localStorage.getItem('YZ020')>

 

[mikdoe]

Warum willst du unbedingt den Browser den request zu dir machen? Warum nicht vom Kunden-PHP zu dir?

Was du da im Moment machst ist sowieso nicht statthaft, weil der Browser mit deinem System kommuniziert und dafür bedarf es einer Datenverarbeitungsvereinbarung zwischen dir und deinem Zähler Kunden und der Endkunde mit dem Browser muss aktiv zustimmen, dass sein Browser Daten an dein System überträgt. Das ist das Thema mit dem Datenschutz und social media icons auf der Webseite, siehe auch https://www.heise.de/hintergrund/Ein-Shariff-fuer-mehr-Datenschutz-2467514.html , darunter müsste es allen Proggern geläufig sein.

 

[mikdoe]

Auf deiner Webseite ist in der Datenschutzerklärung einiges falsch!

Alle Zähler speichern keine personenbezogenen Daten (IP-Adressen) und geben selbst keine Daten weiter.

Browser geben immer Daten weiter. Da kannst du nichts gegen machen und das solltest du nicht schreiben.

Der Provider speichert IP-Adressen der Webseitenbesucher in sogenannten Logfiles zur Erkennung und Abwehr von Angriffen.

Welcher Provider ist gemeint? Wenn nicht du, dann hat das in deiner Daschu nichts zu suchen.

legen die YogiZähler-Besucherzähler keine Cookies an

Und was ist in deinen Augen localstorage?

Lediglich auf dem Server von YogiZähler werden für maximal 7 Tage die IP-Adressen in sogenannten Logfiles gespeichert

Wie verträgt sich das mit dem ersten Zitat hier?

 

[Yogilein]

Vielleicht habe ich mich schlecht ausgedrückt, aber gemeint ist folgendes:

Alle Zähler speichern keine personenbezogenen Daten (IP-Adressen) und geben selbst keine Daten weiter.

Hier beziehe ich mich auf die Zähler selbst. Diese speichern keine personenbezogenen Daten und werden auch nicht dafür genutzt, Daten zu sammeln und diese weiterzugeben.

Der Provider speichert IP-Adressen der Webseitenbesucher in sogenannten Logfiles zur Erkennung und Abwehr von Angriffen.

Der Provider ist mein Anbieter, der den Server bereitstellt. Und hier sage ich doch, dass Daten gespeichert werden. Das ist doch genau das, was du bei meiner ersten Aussage bemängelt hast. Ich habe nur aufgeteilt, was die Zählerlogik macht und was der Serveranbieter macht. Und du hast Recht, ich kann das nicht beeinflussen, deshalb habe ich es auch aufgeführt.

legen die YogiZähler-Besucherzähler keine Cookies an

Hm, ein interessanter Punkt. Cookies (im eigentlichen Sinne) werden nicht angelegt. Soweit stimmt es. Ich könnte aber ergänzen, dass beim Zähler "z_020" lediglich auf der Betreiberseite ein technisch notwendiges Speichern im Browser-Cache stattfindet. Oder kann man das besser ausdrücken? Zumindest werden auch hier keine personenbezogene Daten gespeichert, sondern einfach nur ein bestimmter Code. Ist dieser vorhanden, wird der Stand angezeigt, ansonsten eine Uhr.

Lediglich auf dem Server von YogiZähler werden für maximal 7 Tage die IP-Adressen in sogenannten Logfiles gespeichert

Hier beziehe ich mich auf das, was mein Anbieter macht und und gebe die Dauer der Speicherung bekannt.

Ist die Unterscheidung in "was machen die Zähler selbst" und "was macht der Provider" wirklich falsch? Ich wollte damit doch nur sagen, dass die Zähler selbst keine Datensammler personenbezogener Daten und Weitergeber sind, aber der Provider selbst bestimmte Speicherungen für einen bestimmten Zeitraum vornimmt.

Auf jeden Fall vielen Dank für die Durchleuchtung meiner Datenschutzerklärung.

 

[mikdoe]

Bezüglich der DaSchu liegst du komplett falsch mit deinen eigenen Definitionen. Das Thema ist in der Welt längst abgehandelt und es gibt spätestens seit der DSGVO Standards wie z. B. eine korrekte DaSchu, Auftragsverarbeitungs-Vertrag, Einbindung von Fremdanbieterlinks, Speicherart und -dauer von IP's, Löschungsfristen, Auskunftspflichten usw.
Übrigens ist diese hier beispielhaft recht gut gemacht: https://www.prosaldo-zwissler.de/impressum/datenschutzerklaerung
Und in etwa so müssen Fremdanbieterlinks gemacht sein: https://www.prosaldo-zwissler.de/pro-saldo-zwissler-trailer/

Du wirst weiterhin viel Glück brauchen damit durchzukommen. Sollte mal "der Falsche" eine Webseite durchleuchten auf der dein Zähler implementiert ist, wird es erst für den und dann für dich unbequem. Die Landesdatenschutzbeauftragten verhängen inzwischen ungemütliche Geldstrafen.
Ich rate dir dringend, dich auf aktuellen Stand zu lesen!

Und auf meinen Beitrag davor hast du leider nicht geantwortet. Denn wir könnten den Zähler höchstwahrscheinlich völlig datenschutzkonform machen durch einen Serverrequest.

 

[Yogilein]

Jetzt tue ich mir doch ein bisschen schwer, denn das was du sagst würde ja bedeuten, dass es überhaupt keine Fremdanbieter-Besucherzähler mehr geben dürfte, denn im Prinzip funktionieren sie alle gleich. Und ich kenne bis jetzt keinen einzigen Fall einer (berechtigten) Abmahnung, denn diese wäre das Aus aller solcher Zähler. Willst du also sagen, dass alle Anbieter, auch die kommerziellen, gegen die DSGVO verstoßen?

Die Vorgehensweise "Shariff" ist bei Besucherzählern absolut nicht anwendbar, da nur gezählt werden würde, wenn der Seitenbesucher dem zustimmt. Somit wäre der Sinn eines Zählers ad absurdum geführt.

Bei Facebook und Co. ist das aber passend, da Facebook ohne Zustimmung bereits (verbotenerweise) Daten auswertet und ein Like durch das zweimalige Drücken nicht verhindert wird. D. h. die volle Funktionalität bleibt erhalten.

Ich habe mich, als die DSGVO aufkam, natürlich schlau gemacht und bin damals zu folgendem Ergebnis gekommen:

Wenn ein Besucherzähler selbst keine personenbezogenen Daten verarbeitet (also speichert, auswertet oder weitergibt) bedarf dies keiner Zustimmung, sondern ist gleichzusetzen mit einem eingebundenen Bild. Auch hier wird ein anderer Server aufgerufen und die obligatorischen Daten werden übertragen. Funktioniert der Zähler auf dem Cookie-Prinzip bedarf dies auch keiner Zustimmung, wenn das Cookie nicht zu Tracking-Zwecken eingesetzt wird. Es ist daher als technisch notwendiges Cookie anzusehen.

Ist das jetzt alles falsch?

PS: Deine eine Antwort hatte ich tatsächlich überlesen. Deine Idee ist nicht umsetzbar, da viele Zähleranwender überhaupt kein PHP nutzen können.

 

[mo]

Matomo (https://matomo.org/) kann das wohl alles gut umsetzen.

 

[Yogilein]

Matomo ist kein Besucherzähler, sondern ein Analyseprogramm, das zudem auf dem Server des Anwenders betrieben wird. Das ist bei dem Klientel der klassischen Besucherzähler nicht möglich. Viele haben z. B. Jimdo-Seiten, bei denen kein PHP möglich ist.

Google Analytics wertet dagegen sehr wohl personenbezogene Daten (für eigene Zwecke) aus, analog Facebook. Das entspricht nicht der DSGVO, wenn dem nicht vorher zugestimmt wurde. Und bei Facebook ergibt selbst ein einfacher Klick auf den Like-Button nicht nur ein Like, sondern zieht auch eine userspezifische Auswertung nach sich und kann somit die Vorlieben des Users erkennen (das gefällt und das nicht), selbst wenn der User nicht einmal ein Facebook-User ist.

Und das ist der Knackpunkt, bei dem ich eng gesehen vielleicht falsch liege: Ein normaler Besucherzähler verarbeitet, im Gegensatz zu Analytics, Facebook und Co., aber gar keine personenbezogenen Daten. Und auch genau um das ging es damals bei heise.de. Nicht, dass der Facebook-Button angezeigt wird (auch hierzu werden bereits Daten übertragen), sondern dass diese übertragenen Daten im Sinne von Facebook weiterverarbeitet und ausgewertet werden.

 

[mikdoe]

Ist das jetzt alles falsch?

Ganz ehrlich kann ich es nicht verbindlich beantworten, weil das alles Theorie ist. Am Ende entscheidet immer der Richter und ich kann nicht in die Zukunft gucken.
Nach meiner Auffassung ist ein solcher Zähler im Browser nur unter vielen Bedingungen statthaft.

Allein um mich nicht angreifbar zu machen würde ich so einen Zähler nur serverseitig einsetzen. Und soweit eine Webseite kein PHP verfügbar hat kann das ja kaum ein Nichtverbraucher sein, eher die KiTa im 800 Seelen-Vorort Oder was für eine Firma/Selbständiger hat kein PHP auf dem Server?
Bei Verbrauchern zieht die DSGVO natürlich nicht und da braucht man sich m. E. keine Gedanken machen.

 

[Yogilein]

Und soweit eine Webseite kein PHP verfügbar hat kann das ja kaum ein Nichtverbraucher sein, eher die KiTa im 800 Seelen-Vorort Oder was für eine Firma/Selbständiger hat kein PHP auf dem Server?
Bei Verbrauchern zieht die DSGVO natürlich nicht und da braucht man sich m. E. keine Gedanken machen.

Haupt-Klientel sind private Anwender. (Größere) Firmen setzen i. d. R. keine fremden Zähler ein, außer vielleicht kleine Handwerker, die irgendwo eine Baukasten-HP haben. Viele meine Kunden haben z. B: ihre Seite auf Free-Jimdo gehostet hat. Dort gibt es kein PHP.

 

[mikdoe]

Hast du dich mal mit dem Cross-Origin Resource Sharing beschäftigt und ausprobiert?