Es wurde zur DS-GVO alles gesagt, nur noch nicht von jedem. Also sag ich auch was dazu, aber auf der praktischen Seite. Es geht um die Themen WordPress und die VG Wort, eingebettete Tweets und die Einbindung von Werbenetzwerken.
Das sind drei Themen, zu denen ich selber noch nicht so viel mit abschließendem Ergebnis gelesen habe, dass ich sie für erörtert halten möchte.
1. VG Wort
Diese Verwertungsgesellschaft ermöglicht allen Schreibenden, Tantiemen für kaum verhinderbare Zweitnutzungen zu beziehen. Bei Zeitungsartikeln sind das Tantiemen für Kopien, bei Büchern Tantiemen für den Ausleih in Büchereien und bei Texten im Internet Tantiemen für das Speichern, Ausdrucken etc. der Texte.
Dazu wird in den Texten ein Zählpixel abgelegt, den wir dem Text eindeutig zuordnen. Der Pixel liegt auf einem Server der VG Wort. Bei allen Zugriffen auf das entsprechende Posting hier im Blog wird auch einmal der Pixel vom Server der VG Wort geladen. Damit jeder Leser nur einmal gezählt wird, wird auch ein Cookie gesetzt. Der Cookie kann unter Umständen – in Verbindung mit der IP-Adresse aus den Logs des Webservers der VG Wort beispielsweise – auf eine Person bezogen werden. Das ist zwar sehr, sehr aufwändig, aber möglich.
Da das Erheben der gesetzlich garantierten Tantieme für Internet-Texte auf einem Blog nur auf diesem Weg möglich ist, benötigen sowohl die VG Wort als auch wir Blogger nach Art. 6 Abs. 1 lit. b-f keine Einwilligung, denn „die Verarbeitung ist zur Wahrung der berechtigten Interessen des Verantwortlichen oder eines Dritten erforderlich“. Es spielt dabei keine Rolle, ob die Verarbeitung durch die VG Wort im Rahmen eines Vertrages für mich erfolgt oder ob die VG Wort die Verarbeitung für ihre eigenen Zwecke durchführt (wovon ich ausgehe).
Problematisch ist, dass die Adressen der Zählpixel, die viele andere Mitglieder genau wie ich erhalten haben, auf unverschlüsselte Server zeigen. Also Server, die mit „http://“ angesprochen werden. Der Inhalt der Kommunikation – woher kommt der Aufruf, was steht im Cookie, wie ist die Adresse des Pixels – ist offen auf der Leitung lesbar. Und das ist nach der DS-GVO nicht zulässig.
Inzwischen können die Pixel auch per https verschlüsselt abgerufen werden. Die VG Wort hätte nun die erforderlichen Zertifikate auf den vorhandenen Servern installieren und mit einer Direktive im Webserver https erzwingen können, aber das wäre zu einfach gewesen. Man hat lieber neben den 10 bisherigen „Pixel-Servern“ einen neuen mit https eingerichtet.
Bei neuen Texten kann man das berücksichtigen und beispielsweise die Adresse „http://vg06.met.vgwort.de…“ durch „https://ssl-vg03.met.vgwort.de…“ ersetzen, wenn man den Pixel aus der Liste kopiert. Aber bei alten Texten?
Dafür gibt es glücklicherweise Tools, die ein „Suchen & Ersetzen“ über alle Texte ermöglichen. Ich habe beispielsweise Das Plugin Search & Replace dafür installiert, weil es sehr umfangreiche Möglichkeiten hat. Beispielsweise kann man nahtlos mit diesem Tool die Datenbank vor dem Ändern sichern, einzelne Tabellen auswählen etc.
Per Plugin muss man innerhalb aller Postings (die Tabelle, die man bei Search & Replace auswählen sollte, heißt meistens „wp_posts“) zehnmal ans Werk gehen und alle unverschlüsselten Serveradressen von „http://vg01.met.vgwort.de“ bis „http://vg10.met.vgwort.de“ durch „“https://ssl-vg03.met.vgwort.de“ ersetzen.
Und – zack! – verschwinden nicht nur die Warnungen, dass das mit https verschlüsselte eigene Blog unsichere Inhalte nachlädt, sondern man ist auch in Sachen DS-GVO etwas sicherer.
2. Eingebettete Tweets
Wenn man Tweets einbettet, dann lädt der Blogleser automatisch Daten von Twitter nach. Twitter kann also tracken, wer über welche Website welchen eingebetteten Tweet gelesen hat. Das ist unschön, so lange es keine verbindliche Aussage zur DS-GVO gibt, dass Twitter eben keine personenbezogenen Daten erhebt. Zumindest kenne ich keine solche Aussage.
Auch hier hilft „Search & Replace“. Twitter nutzt ein JavaScript, um die Daten nachzuladen, und das sieht im Quelltext so aus:
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
Per Search & Replace ersetzt man diese Zeile in allen Postings durch
<!-- script async src="//platform.twitter.com/widgets.js" charset="utf-8"--><!-- /script -->
und macht aus den Scriptaufrufen kurzerhand Kommentare. Die Tweets sehen jetzt nicht mehr so schön aus, aber der Text und Links auf Medien sind enthalten und ein Link auf das Original auch. Wenn sich die Frage, ob Tweet-Einbettungen DS-GVO-kompatibel sind, geklärt hat, kann man alles wieder zurück ändern.
3. Werbenetzwerke
Da wird es knifflig. Werbung als kleiner oder größerer Zuschuss zum nunmal nicht kostenfreien Betrieb eines Blogs ist an und für sich auch von Art. 6 Abs. 1 lit. b-f gedeckt – aber. Die Frage ist, ob es nicht datensparsamer geht als mit Netzwerken wie Google Adsense und Amazon. Und tatsächlich: Es geht. Wenn man selber bei möglichen Werbetreibenden darum bettelt, Banner setzen zu dürfen und Geld dafür zu bekommen. Dann sind die einzigen Cookies die Eures Blogs, die Impressions werden wie a.d. 1998 vom Banner-Plugin gezählt und Eintreiben müsst Ihr das Geld selber.
Sowohl Amazon als auch Google laden die Werbung per JavaScript oder iframe von ihren eigenen Servern, was dazu führt, dass die IP-Adressen und die Tatsache, dass von dort aus Euer Blog besucht wurde, dem Werbenetzwerk gegenüber offengelegt wird. Und sie setzen auch Cookies, um Besucher pro Besuch nur einmal zu zählen und nicht einmal pro Reload der Seite. Und im Zweifel auch, um zu tracken, wo die Besucher sonst so waren und was für Reklame interessant sein könnte.
Mit etwas JavaScript und einem Plugin, das auch gleich eine Cookie-Erlaubnis einholt, kriegt man das hin.
Das Plugin heißt GDPR Cookie Compliance und kann schon recht viel. Zunächst können wir einen Cookie-Hinweis mit der Möglichkeit, „Ja“ zu Cookies zu sagen, implementieren. Wenn man an dieser Stelle dann auf die Cookies von Google, Amazon & Co hinweist, sind die Einwilligungen eingeholt. Es wird ein auch Cookie gesetzt, um die Frage beim nächsten Besuch zu vermeiden.
Zudem kann man einen Dialog einbinden, in dem zwischen „Erforderlichen Cookies“, Cookies von Dritten und Weiteren Cookies differenziert werden kann. Tatsächlich speichert das Tool für alle drei Kategorien (im eigenen Cookie) ab, ob die Cookies erlaubt sind.
Bloß – wie setze ich das mit der Erlaubnis um?
Ich selber sage klar: Wer keine Cookies der VG Wort und denen, die mit WordPress zu tun haben, haben will, soll sie im Browser generell abklemmen oder im Internet was anderes lesen. Kann man auch in freundlichen Worten in den Cookie-Hinweis einbinden. Lustigerweise merkt sich das Plugin, wenn man die differenzierte Auswahlmöglichkeit aktiviert, dass die „Erforderlichen Cookies“ verboten sind, es macht aber nichts.
Bei den Werbecookies ist das anders. Zum einen lege ich damit Google & Co offen, wer meine Website besucht – da soll jeder selber entscheiden können – und ich muss verhindern, dass sie vor Beantwortung der Cookie-Frage geladen werden.
Das ist relativ einfach. GDPR Cookie Compliance gibt uns die Möglichkeit, Scripte zu definieren, die ausgeführt werden, wenn in seinem Cookie des jeweiligen Browsers die Cookies von Dritten erlaubt wurden. Über diese Scripte kann man Werbung einschalten. Und das geht so:
Amazon beispielsweise packt die Reklame in einen iframe. Das sieht dann in HTML so aus:
<iframe src="https://rcm-eu.amazon-adsystem.com/e/cm?o=3&p=14&l=ez&f=ifr&linkID=2997759c925c65dae5381a4f074978d7&t=olk02d-21&tracking_id=xxxxxxx" width="160" height="600" scrolling="no" border="0" marginwidth="0" style="border:none;" frameborder="0"></iframe>
Damit der iframe nur angezeigt wird, wenn der Cookie es erlaubt, müssen wir in zwei Schritten vorgehen.
- Definieren eines Platzes auf der Website. Idealerweise in einem HTML-Widget über die Einrichtung der Themen, dann wird der Platzhalter nicht beim nächsten Themen-Update gelöscht:
<p id='amazonad'></p>
- Im Script, das bei gesetztem Cookie ausgeführt wird, muss nun stehen:
document.getElementById('amazonad').innerHTML = '<iframe src="https://rcm-eu.amazon-adsystem.com/e/cm?o=3&p=14&l=ez&f=ifr&linkID=2997759c925c65dae5381a4f074978d7&t=olk02d-21&tracking_id=xxxxxx" width="160" height="600" scrolling="no" border="0" marginwidth="0" style="border:none;" frameborder="0"></iframe>';Dadurch wird der Inhalt des Objekts mit der ID „amazonad“ durch den in den einfachen Anführungszeichen rechts vom Glechheitszeichen stehenden iframe von Amazon ersetzt. Das ist schon alles. Hat man mehrere iframes mit Werbung eingebunden, muss man für jeden iframe ein solches eindeutig benanntes Feld definieren und für jedes Feld einen solchen Befehl in das Script-Feld schreiben.
Ich habe diese Scripte im Plugin in das Feld eingetragen, das im Header der Website ausgeführt wird. Vergesst nicht, vor all diese Befehle einmal „<script>“ und hinter ihnen einmal „</script> zu schreiben. Und achtet auf die Anführungszeichen. Im iframe werden welche benutzt. Werden – wie bei Amazon – doppelte benutzt („), dann schließt den gesamten Text in einfache Anführungszeichen (‚) ein und umgekehrt.
Bei Google Adsense ist das noch einfacher. Aktiviert dort die automatisch platzierten Anzeigen und fügt den von Google gelieferten Code in das Feld, das nach dem Body des HTML-Dokumentes ausgeführt wird:
<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<script>
(adsbygoogle = window.adsbygoogle || []).push({
google_ad_client: "xxxxxxxxxx",
enable_page_level_ads: true
});
</script>
Und fertig, AdSenseCode wird erst geladen, wenn der Besucher das erlaubt hat, und dann von AdSense selber optimiert auf Eurem Blog eingebunden.
