Das war tatsächlich die spannendste Frage in diesem Zusammenhang: Welche personenbezogenen Daten verarbeite ich eigentlich? Hier hat die DSGVO (Was das ist? Hier Teil 1) tatsächlich einen ihrer (für mich) größten Mehrwerte ausgespielt: Alle machen sich nun endlich einmal Gedanken darüber, was sie da eigentlich mit ihren Webseiten „anrichten“! Die Informationelle Selbstbestimmung hat ziemlich starke Gegner:

• Die recht einfache und unbedarfte Nutzung von CMS und anderen Tools (Teilweise reicht eine Domain, etwas Webspace und die "1-Click-Installation"-Angebote der Hoster – und Schwupps! – läuft da ein WordPress- Typo3-, Joomla-, Moodle- oder sonstiges System),
• die bisher recht "lasche" Strafverfolgung bei Datenschutzverstößen in Verbindung mit der Einschätzung, sein eigenes Online-Angebot sei ja "nicht böse",
• eine zu geringe Sensibilisierung der Verantwortlichen (und Betroffenen),
• evtl. den Post-Privacy-Trend (?),
• eine gewisse Portion technischen Unverständnisses (ja, Akismet ist standardmäßig bei WordPress dabei und funktioniert als Spam-Filter super. Aber dafür werden Namen, Kommentar-Texte und IP in ein Drittland übertragen. Darf das?), und nicht zuletzt:
• Bequemlichkeit und Aufwandsvermeidung der Verantwortlichen 😮

Die DSGVO zwingt die Webseitenbetreibenden nun also – spätestens beim notwendigen Verfassen der angepassten Datenschutzerklärungen – dazu, sich einmal detailliert anzusehen, was denn da eigentlich an Daten produziert, gespeichert, verarbeitet und weitergegeben wird. Finde ich ganz gut.

Für mich habe ich acht Baustellen identifiziert:

1. Cookies

Cookies sind kleine Textdateien, die von meiner Webseite auf den Besuchenden-Endgeräten abgelegt werden. Cookies können prinzipiell sinnvoll sein, z.B. bei Login-basierten Sitzungen ("Sessions"): Ohne den dabei angelegten Session-Cookie müsste man sich beim Wechsel der (Unter-) Seite wieder erneut anmelden. Interaktionen wie "Warenkorb bearbeiten" oder "Weiter zur Kasse", wie sie z.B. bei Online-Shops allgegenwärtig sind, würden unmöglich, da bei jedem Laden der neuen Ansicht erneut Login-Informationen abgefragt werden müssten. Cookies können normalerweise nur von der Webseite ausgelesen werden, die sie auch gesetzt hat.

Aber neben dem hohen Nutzen bestehen natürlich auch Gefahren, z.B. Tracking oder Identitätsdiebstahl. Und da Cookies personenbezogene Daten enthalten (können), sind sie eine Form der Verarbeitung personenbezogener Daten, und die Betroffenen müssen darüber informiert werden.

Bzgl. meiner WordPress-Instanz habe ich folgende (Standard-) Cookies ausgemacht:

1. wordpress_test_cookie:
   • Inhalt: "WP Cookie check"
   • Session-Cookie, wird zum Sitzungsende gelöscht
   • enthält keine personenbezogenen Daten, sondern lediglich den Text "‘WP Cookie check"; wird zum Testen der Möglichkeit zum Setzen von Cookies genutzt
2. wordpress_logged_in_[hash]
   • Inhalt: Anmeldename, Passwort (verschlüsselt)
   • Session-Cookie, wird beim Abmelden oder automatisch nach 14 Tagen gelöscht
   • bestätigt die erfolgreiche Authentifizierung; wird beim Login in den Redaktionsbereich gesetzt
3. wordpress_sec_[hash] (für /wp-admin)
   • Inhalt: Anmeldename, Passwort (verschlüsselt)
   • Session-Cookie, wird beim Abmelden oder automatisch nach 14 Tagen gelöscht
   • bestätigt die erfolgreiche Authentifizierung über eine verschlüsselte Verbindung, notwendig für die Nutzung des Redaktionsbereiches
4. wordpress_sec_[hash] (für /wp-content/plugins)
   • Inhalt: Anmeldename, Passwort (verschlüsselt)
   • Session-Cookie, wird beim Abmelden oder automatisch nach 14 Tagen gelöscht
   • bestätigt die erfolgreiche Authentifizierung über eine verschlüsselte Verbindung, notwendig für die Berechtigungen u.a. bzgl. Plugin-Installation und -Konfiguration
5. wp-settings-[User-ID]
   • Inhalt: WP-User-ID und verschiedene Einstellungen für den Redaktionsbereich
   • Lebensdauer: 1 Jahr
   • beinhaltet z.B., ob der Editor im WYSIWYG– oder im Quelltext-Modus läuft, oder ob Beiträge als Liste oder als Kursfassung angezeigt werden sollen, etc.
6. wp-settings-time-[User-ID]
   • Inhalt: WP-User-ID und Zeitstempel in Unixzeit.
   • Lebensdauer: 1 Jahr
   • beinhaltet das Datum und die Zeit der letzten Änderung von Benutzendeneinstellungen. Entspricht dem Datum, wann wp-settings-[UID] gesetzt oder geändert wurde
7. wp-saving-post
   • Inhalt: [Post-ID]-saved
   • Lebensdauer: 1 Tag
   • wird bei der automatischen oder aktiven Speicherung eines Beitrags oder einer Seite angelegt; bestätigt die erfolgreiche Speicherung und kontrolliert die Speicherfunktion und Versionskontrolle bei Verbindungsabbrüchen

Den Cookie (8.) wordpress_[hash], der laut Doku angelegt wird "to store your authentication details", kann ich auf meinen Geräten nicht finden.

Wo wir beim nächsten Thema wären: Beim Kommentieren können darüber hinaus ebenfalls Cookies gespeichert werden, wenn die Checkbox "Meinen Namen, E-Mail und Website in diesem Browser speichern, bis ich wieder kommentiere" aktiviert wird:

9. comment_author_[hash]
   • beinhaltet den Eintrag aus dem Feld "Name"
   • Lebensdauer: 1 Jahr
   • speichert den Namen der/s Kommentierenden und füllt das Feld bei erneutem Aufruf des Kommentarformulars automatisch aus.
10. comment_author_email_[hash]
    • beinhaltet den Eintrag aus dem Feld "E-Mail"
    • Lebensdauer: 1 Jahr
    • speichert die E-Mail-Adresse der/s Kommentierenden und füllt das Feld bei erneutem Aufruf des Kommentarformulars automatisch aus.
11. comment_author_url_[hash]
    • beinhaltet den Eintrag aus dem Feld "Webseite"
    • Lebensdauer: 1 Jahr
    • speichert die Webseite der/s Kommentierenden und füllt das Feld bei erneutem Aufruf des Kommentarformulars automatisch aus.

Ich nötige – auch im Vorgriff auf die kommende EU-ePrivacy-Verordnung – den Seitenbesuchenden zu einer Einwilligung in die mit dem Webseitenbesuch zusammenhängende Datenverarbeitung (mit Overlay, ohne dessen Wegklicken die Webseite nur sehr unkomfortabel nutzbar ist). Damit wird auch dem Speichern von Cookies zugestimmt. Ob das eine Forced Consent-Methode ist? Kann ich kaum beurteilen; vielmehr möchte ich darauf hinweisen, dass mind. ein paar wenige technisch notwendige Cookies zur Nutzung meiner Webseite notwendig sind.

Zum Angebot eines solchen Opt-Ins bin ich eventuell in mehrerlei Hinsicht nicht verpflichtet, kann ich aber nicht rechtssicher beurteilen:

• Zurzeit setzt meine Webseite ab Werk keinerlei zusätzliche Cookies (weder "First-Party-Cookies" noch "Third-Party-Cookies"). Die hier aufgeführten Cookies sind entweder
  • technisch notwendig (und ohne personenbezogene Daten, Cookie Nr. 1) oder
  • technisch notwendig und nur für mich (und evtl. Gastautor/innen) relevant (Redakteurs-/Admin-Bereich, Cookies Nr. 2 – 7) oder
  • freiwillig (Kommentare, Cookies Nr. 9 – 11).
• Noch gilt die "Cookie-Regelung" aus Art. 5 (3) RL 2002/58/EG (geändert durch Art. 2 Nr. 5 RL 2009/136/EG), evtl. i.V.m. § 15 TMG, die häufig als reine "Opt-out"-Regelung ausgelegt wird: Darin begründet sich die Form bisher gängiger Cookie-Banner mit dem sinngemäßen Hinweis "Durch Weiternutzung der Webseite stimmen Sie der Verarbeitung personenbezogener Daten zu", also der Annahme einer (stillschweigenden?) Einwilligung mit (hoffentlich) Aufklärung über eine Widerspruchsmöglichkeit.

Diese Auslegung der ePrivacy- und Cookie-Richtlinien und ihre Umsetzung in nationalem Recht (TMG) finde ich persönlich allerdings nicht so richtig überzeugend (s. auch Teil 1, Abschnitt "EU-Richtlinien"). Und die ePrivacy-Verordnung wird früher oder später wohl eine Opt-in-Lösung fordern. Und das Verhältnis von DSGVO zu EU-Richtlinien und TMG ist mir zu ungeklärt. Und überhaupt…

Das für den vorauseilenden Opt-in eingesetzte Plugin (GDPR Cookie Consent, früher auch Borlabs Cookie) speichert die Cookie-Einstellungen skurrilerweise in einem Cookie 🙂 – daher gibt es Nr. 12 – 14 auf meiner Liste:

12. viewed_cookie_policy
    • yes / no
    • Lebensdauer: 1 Jahr
    • beinhaltet die Information, ob die Datenschutzhinweise angezeigt wurden oder nicht
13. cookielawinfo-checkbox-necessary
    • yes / no
    • Lebensdauer: 1 Jahr
    • beinhaltet die Information, ob der Speicherung technisch notwendiger Cookies zugestimmt wurde (für meinen Einsatz nicht relevant)
14. cookielawinfo-checkbox-non-necessary
    • yes / no
    • Lebensdauer: 1 Jahr
    • beinhaltet die Information, ob der Speicherung von Cookies Dritter zugestimmt wurde (für meinen Einsatz nicht relevant)

Das war’s schon an Cookies.

Für technisch notwendige Pflicht-Cookies (Nrn. 1 – 7, 12 – 14) gilt als Rechtsgrundlage wohl Art. 6 (1) lit. f) DSGVO (berechtigtes Interesse), für freiwillige Cookies (Nrn. 9 – 11) dagegen Art. 6 (1) lit a), da ich bei der freiwilligen Aktivierung der Speicherfunktion ein Einverständnis voraussetze. Die Details (z.B. über Inhalt und Speicherdauer der Cookies) mache ich in der Datenschutzerklärung meiner Webseite transparent. Bei den Kommentar-Cookies (Nrn. 9 – 11) habe ich außerdem eine Checkbox (Pflichtfeld) eingebaut, welche die Kenntnisnahme der Datenschutzerklärung abfragt (zur technischen Umsetzung s. Teil 3 dieser Artikelserie).

2. Kommentare

Die nächste Baustelle ist die der Kommentarfunktion. Das Kommentieren ist prinzipiell freiwillig. Erst einmal würde ich daher annehmen, dass alle, die nicht mit dem Speichern von Kommentardaten einverstanden sind, davon Abstand nehmen 🙂

Trotzdem habe ich diese o.g. Checkbox in das Kommentarformular eingebastelt, um die Datenschutzerklärung zur Kenntnis nehmen zu lassen, in denen ich die Datenspeicherung bzgl. der Kommentardaten möglichst transparent erläutere (Umsetzung s. Teil 3).

Um hier "sauber" zu beginnen, habe ich alle bisherigen (Stand: Juli 2018) Kommentare gelöscht, da die betroffenen Kommentator/innen noch zu anderen Datenschutzbedingungen kommentiert haben. Die damalige Einwilligung ist zwar auch nach Inkrafttreten der DSGVO wirksam, ich habe aber den Nachweis über die Einwilligung nicht sauber dokumentiert / kann die Einwilligung nicht immer nachweisen, obwohl ich nach § 7 (1) DSGVO dazu verpflichtet bin. Ob man da wirklich so rigoros sein muss, weiß ich nicht genau. Aber der EG 171, Satz 3 DSGVO führt aus, dass Verarbeitungen, die auf einer früheren Einwilligung beruhen, bestehen bleiben, "wenn die Art der bereits erteilten Einwilligung den Bedingungen dieser Verordnung entspricht", womit wohl auch die Nachweisbarkeit gemeint ist, die ich nicht sicherstellen kann. 😮

Im Detail werden für jeden Kommentar vier Datengruppen gespeichert:

2.1 Daten, die von Kommentierenden eingegeben werden

Das sind

• der eigentliche Kommentar (Pflichtfeld, logisch),
• der Name (Pflichtfeld),
• die E-Mail-Adresse (Pflichtfeld) und
• die Webseite (freiwillige Angabe).

Dass der Kommentartext gespeichert wird, ist wohl nicht erläuterungswürdig. Die Angaben zu Namen und E-Mail-Adresse sind zwar Pflichtangaben, sind aber prinzipiell anonymisierbar bzw. pseudonymisierbar; die Angabe einer Webseite ist völlig freiwillig (= Rechtsgrundlage Art. 6 (1) lit. a) DSGVO). Auch darauf weise ich natürlich in der Datenschutzerklärung hin.

2.2 IP-Adressen

Die IP-Adressen werden von WordPress in der Datenbank unbegrenzt (!) mit dem Kommentar gespeichert. Nicht erst, seitdem (auch dynamische) IP-Adressen höchstrichterlich als personenbezogenes Datum gelten, sondern bereits die Speicherung der IP-Adresse in direkter Verknüpfung mit einem evtl. nicht pseudonymisierten Namen oder einer E-Mail-Adresse macht sie zu einem mindestens mittelbar personenbezogenen Datum.

Allerdings: Die IP-Adresse ist evtl. für Teile der Spamfilterung (s.u.) notwendig. Hier ist also eine Interessenabwägung geboten, ob also mein berechtigtes Interesse (nach Art. 6 (1) lit. f) DSGVO) an einem spam-freien Blog schwerer wiegt als die Einschränkung der Freiheitsrechte von Kommentator/innen. Ich würde diese Frage erst einmal zu meinen Gunsten bejahen, vor allem vor dem Hintergrund, dass die Auflösung einer IP-Adresse in einen Klarnamen für mich (und viele andere normalsterbliche WordPress-Admins, selbst mit Techniken wie Reverse IP/DNS oder IP Geolokalisierung / Geotargeting) nicht möglich ist. Allerdings ist das für Menschen mit mehr technischem Sachverstand und Strafverfolgungsbehörden sehr wohl möglich.

Und einer von entsprechenden Behörden an mich gerichtete Aufforderung, z.B. bei der "Verfolgung von Straftaten" oder der "Gefahrenabwehr" mitzuwirken, wenn ein entsprechender Richtervorbehalt anzuwenden ist, würde ich mich auch nicht widersetzen, wenn denn die IP-Adressen zu dem Zeitpunkt der Aufforderung noch irgendwo gespeichert ist.

Die IP-Adresse ist im o.g. Sinne allerdings nur für die Spam-Überprüfung selbst notwendig, eine dauerhafte Speicherung ist also nicht nur nicht erforderlich, sondern entspricht auch nicht dem Prinzip der Datensparsamkeit. Dafür zeige ich in Teil 3 der Artikelserie Möglichkeiten, mit der man

• entweder verhindert, dass die IP-Adresse gespeichert wird, oder
• erwirken kann, dass die IPs nach einer gewissen Zeit gelöscht werden.
• Außerdem zeige ich die Bereinigung der Datenbank für bereits gespeicherte Kommentare.

2.3 Metadaten

Metadaten meinen Zeitstempel und "User Agent". Den Zeitstempel finde ich sinnvoll und vertretbar, um die chronologische Reihenfolge von Kommentaren darstellen zu können, hier überwiegt m.M.n. mein berechtigtes Interesse (= Rechtsgrundlage § 6 (1) lit. f) DSGVO) an der korrekten und nutzendenfreundlichen Darstellung meines Webangebotes.

Den "User Agent" finde ich dagegen wiederum überflüssig, vor allem da aus der Kombination von Rechner, Betriebssystem, Browser und Sprachversion (vgl. Canvas Fingerprinting, Virtueller Fingerabdruck, etc.) durchaus schon Rückschlüsse auf die/den Betroffene/n möglich sind, die für den eigentlichen Verarbeitungszweck (Schreiben eines Kommentars, Anzeigen von Kommentaren) in dieser Form nicht notwendig sind. Was genau man dem "User Agent"-String entnehmen kann, weiß ich persönlich allerdings gar nicht.

In Teil 3 der Artikelserie gibt’s eine WP-Funktion, mit dem man verhindert, dass der User Agent gespeichert wird.

2.4 Gravatare

Das sind die "Globally Recognized Avatars" (Bildchen der Kommentierenden) des Automattic-Dienstes Gravatar. Bei der Nutzung würde meine WordPress-Installation mit einem Server des Anbieters (Automattic) kommunizieren und dabei abgleichen, ob zu der angegebenen E-Mail-Adresse der/des Kommentierenden ein Avatar verfügbar ist und diesen anzeigen, wenn verfügbar.

Welche Daten genau dafür mit Automattic getauscht werden, wie lange sie auf deren Servern gespeichert werden und was sonst noch damit angestellt wird, kann ich nur schwer beurteilen. Und obwohl der Anbieter dem EU-US Privacy Shield beigetreten ist (Automattic in der Privacy Shield List) und recht ausführliche Datenschutzhinweise zu seinen Diensten veröffentlicht hat, müsste vielleicht eine zusätzliche Einwilligung der Betroffenen (gem. Art. 6 (1) lit. a) DSGVO) eingeholt werden, vor allem, da die Betroffenen keinerlei Möglichkeit haben, diese Kommunikation (z.B. via Browser-Plugins, s. auch Abschnitt zu Schriftarten) zu unterbinden. Ein berechtigtes Interesse zu verargumentieren ("ist halt hübscher mit Avataren" oder so), fällt zumindest eher schwer. Daher habe ich diese Funktion im Admin-Bereich von WordPress abgeschaltet (s. Teil 3 der Artikelserie).

3. Spamfilter

Grundsätzlich werde ich auch weiterhin alle Kommentare moderieren (sprich: freigeben oder löschen), solange das Kommentaraufkommen in machbarem Umfang bleibt (wird es, glaube ich 🙂 ). Trotzdem setze ich einen Spamfilter ein (nämlich Antispam Bee von pluginkollektiv). Dieser bietet im Gegensatz zum Standard-Filter Akismet von Automattic einige DSGVO-konforme(re) Features an. Akismet schickt sowohl den Kommentartext als auch die IP des Kommentierenden an einen US-Server. (s. hier, hier, hier, …). Ob eine Checkbox zur Einwilligung in diese Datenverarbeitung und/oder das Plugin Akismet Privacy Policies ausreicht, vermag ich nicht zu beurteilen, will da aber auch kein Risiko eingehen.

Antispam Bee bietet die Möglichkeit einer lokalen Spam-Filterung ohne Kommunikation mit Dritten. Optional stehen auch "DSGVO-relevante" Prüfmechanismen (Geotargeting und automatische Sprachbestimmung) an, wodurch Daten mit externen Diensten ausgetauscht werden. Diese nutze ich vorerst nicht.

Sollte der Moderationsaufwand in Zukunft ins Unermessliche steigen, könnte eine erneute Abwägung meiner (dann: berechtigten) Interessen (§ 6 (1) lit. f) DSGVO) zu einer Anpassung der Einstellung führen.

4. Kommentarabonnements

Ich weiß gar nicht, ob die Funktion "Informiere mich über neue Kommentare / Antworten auf meinen Kommentar" jemals zum Standardfunktionsumfang von WordPress gehört hat: Wenn ja, ist sie seit geraumer Zeit nicht mehr vorhanden. Diese Funktion ist aber m.M.n. äußerst sinnvoll: Oft lande ich über eine Suchmaschine auf Blogs und verschwinde wieder, ohne mir ein Lesezeichen zu setzen. Die Seite / den Artikel finde ich dann ein paar Tage/Wochen später ja nicht mehr wieder. Habe ich kommentiert, interessieren mich natürlich auch die Antworten und der Verlauf der Diskussion, die Kommentarfunktion ist schließlich eine "Dialog"-Funktion… und kann ich Kommentare nicht abonnieren, kommentiere ich evtl. erst gar nicht… usw. Alles blöd.

Daher nutze ich das Plugin "Subscribe to Comments Reloaded". Das hat gleich mehrere Vorteile:

1. Double-Opt-In: Wenn ein Abonnement gewünscht ist, muss erst eine E-Mail-Adresse eingegeben, eine Bestätigungs-Mail abgewartet und ein entspr. Link angeklickt werden. So kann
   • einem Missbrauch fremder E-Mail-Adressen vorgebeugt werden und
   • man läuft keine Gefahr, in den Verdacht des Versands unrechtmäßiger Werbung (vgl. § 7 (2) Nr. 3 UWG) zu geraten;
2. dezidiertes Abonnement von Antworten auf den eigenen Kommentar oder von allen Kommentaren möglich,
3. Abonnement von Kommentaren ohne selbst zu kommentieren moglich und
4. eigenständige Verwaltung der Abonnements durch die Abonnent/innen möglich (= verwaltungsarm).

Dass dabei Daten gespeichert und verarbeitet werden, versteht sich. Dass diese Funktion freiwillig (gem. Art. 6 (1) lit. a) DSGVO) ist, auch, oder? Dafür weise ich in dem Zusammenhang (im Kommentarformular, auf der Abo-Seite und in der Bestätigungsmail) auf die Details in der Datenschutzerklärung hin.

Gespeichert werden (zeitlich unbeschränkt):

• die E-Mail-Adresse,
• die Artikel, von denen Kommentare abonniert wurden,
• Abonnement-Umfang (Alle Kommentare / Nur Antworten), und
• Zeitpunkt des Abonnements.

Gelöscht werden können diese Daten durch die Abonnent/innen selber. Die Daten werden übrigens bei Löschung durch die Betroffenen in der MySQL-Datenbank nicht nur als gelöscht markiert, sondern tatsächlich entfernt 🙂

5. Emojis

Hier: :-) macht 🙂 , :-( macht 🙁 , :-o macht 😮 , … klar, kennt man. Soo niedlich, die können doch nicht böse sein. Die Darstellung von Emojis an sich ist auch nicht verwerflich, wenn sie auch polarisiert: Viele finden sie albern und unseriös, manche glauben an ihre Chance als Esperanto–Nachfolger, auch Sprachwissenschaftler beschäftigen sich mit diesen modernen Hieroglyphen. Wie auch immer, Emojis in WordPress haben ein Datenschutzproblem. Wusste ich bis vor kurzem auch nicht, bis ich die Netzwerkanfragen (z.B. in Firefox, Chrome) meines Browsers in dem DSGVO-Zusammenhang kontrolliert hab:

Die technischen Hintergründe habe ich ehrlicherweise mal wieder nicht ganz durchblickt, aber das Skript wp-emoji-release.min.js (aus dem Ordner [wordpress]/wp-includes/js/) steht im Zusammenhang mit einem weiteren namens wp-emoji-loader.min.js. Und dieses wiederum lädt – allerdings scheinbar nur bei älteren Desktop-Browsern und bei ausgewählten Mobilgeräten – Emojis von einem sog. CDN nach, nämlich diese von https://twemoji.maxcdn.com/:

Darüber hinaus werden Emojis von einem weiteren Server geladen, nämlich von s.w.org bzw. s-origin.wordpress.org. Was beim Laden eines Emojis technisch genau passiert, kann ich nicht einschätzen; zur Auslieferung können aber z.B. die IP-Adresse oder ein sonstiges Datum (z.B. ein Geräte-Fingerabdruck) übertragen werden. 😮

Da Emojis, die ich durchaus gerne nutze, auch ohne diese CDN-Kommunikation funktionieren, zeige ich in Teil 3 daher eine WP-Funktion, mit der man diese Emoji-Nachlade-Routinen abstellt.

6. Schriftarten

In einer ähnlichen Liga wie Gravatare und Emojis spielen eingebettete Schriftarten (sog. Webfonts). Google Fonts, Adobe Typekit (neuerdings Adobe Fonts) und andere halten diverse – aus gestalterischer Sicht stilvolle – Schriftarten bereit, welche recht einfach in Webseiten eingebunden werden können. Das ist nicht nur ästhetisch, sondern auch technisch prinzipiell sinnvoll, da es Speicherplatz spart, technische Stolperfallen (geräte-, OS-, browser-übergreifende Lauffähigkeit) vermeidet, Updates automatisch durchgeführt werden und mehr.

Dem gegenüber steht wiederum die dafür notwendige Kommunikation des Besuchenden-Browsers mit externen Diensten, bei denen man (sprich: ich) nicht einschätzen kann, was da genau kommuniziert wird. Die Angaben (hier von Google Fonts, Adobe Typekit) sind nicht übermäßig zufriedenstellend.

6.1 Google oder Adobe?

Ich habe sowohl Google Fonts als auch Adobe Fonts zeitweise eingesetzt. Der Unterschied zwischen Google und Adobe als Anbieter von Webfonts liegt meiner bescheidenen Einschätzung nach im zu Grunde liegenden Geschäftsmodell. Google ist in seiner Struktur darauf angelegt, möglichst viele Daten zu möglichst individuellen Profilen zu verknüpfen, denn eines von Googles Hauptgeschäftsfeldern ist der Verkauf und die Verteilung von Werbung. Je spezifischer eine Zielgruppe für Targeted Advertising eingegrenzt werden kann, desto besser. Adobe ist dagegen eher im Bereich der Kreativ-Software und -Services tätig (oder?), hat also ein anders gelagertes Interesse an Betroffenendaten. Daher habe ich mich im Sinne dieser Betroffenendaten für Fonts von Adobe entschieden. Momentan setze ich zwei Google Fonts ein, die allerdings auf meinem eigenen Webspace gehostet sind, so dass keine Verbindung zwischen dem Endgerät des Webseitenbesuchenden und einem Server Dritter aufgebaut wird.

Beim Verwenden von externen Fonts kann als Rechtsgrundlage nur Art. 6 (1) lit. f) DSGVO in Frage kommen. Das berechtigte Interesse besteht meist in einer ansprechenden Darstellung der Webseite. Ob das recht oft bemühte berechtigte Interesse so weit tragfähig ist, wird die Zeit (in Form von Präzedenzfällen) zeigen. Hier ist also mindestens ein Hinweis in den Datenschutzerklärungen incl. Verweise auf die allgemeine Datenschutzerklärung von Adobe und die speziellere von Typekit (neue URL: Datenschutzhinweise für Adobe Fonts) bzw. auf die Datenschutzhinweise von Google anzugeben.

Im Gegensatz zur Kommunikation mit dem Gravatar-Dienst oder dem Emoji-Nachladen kann jede/r Betroffene diese Schriftarten-Nachlade-Funktion mittels Browser-Einstellungen oder -Plugins (Ghostery, NoScript, ScriptSafe, uMatrix o.ä.) unterbinden. Das ist für technisch weniger versierte Nutzende aber wohl nur ein schwacher Trost.

Spätestens die (eigentlich verpflichtende) Angabe zu Speicherdauer und Art der Datenverarbeitung ist aber eigentlich nicht leistbar, über diese Details schweigen sich die Anbieter externer Webfonts häufig aus. Man läuft also immer Gefahr, eine zwangsweise unvollständige Datenschutzerklärung zu haben.

6.2 Font Awesome

Darüber hinaus nutze ich ausgewählte Icons von Font Awesome. Diese sind allerdings auf meinem Webspace gehostet, so dass es zu keiner Kommunikation zwischen dem Besuchendenbrowser und dem Anbieter kommt.

7. Drittinhalte

Die "Einbetten"-Funktion vieler Plattformen ist toll. Man kopiert einfach einen vorkonfektionierten Code von z.B. YouTube, fügt ihn in den Code der eigenen Webseite ein und – Bäm! – ist das Video auf der eigenen Seite sichtbar. Technisch wird dabei quasi ein Fenster in der eigenen Webseite geöffnet, durch das man Teile einer weiteren Webseite sehen kann. Das ist für Seitenbesuchende allerdings insofern doof, weil bei dem Aufruf einer Web-Adresse erst einmal angenommen werden könnte, dass nur Daten von (und zu) dieser aufgerufenen Webseite übertragen werden. Allerdings ist das Laden eines iframes in etwa mit einem Besuch der eingebetteten Seite vergleichbar. Soll heißen: YouTube-Inhalte, die durch einen iframe geladen und angezeigt werden, können zu einem  ähnlichen Ergebnis führen wie der Besuch von https://www.youtube.com selbst. Das ist aus dem aufgerufenen Link oder der aufgerufenen Adresse allerdings nicht ersichtlich.

Vor allem das Thema Cookies (s.o.) spielt hier erneut eine Rolle, ein eingebettetes Video auf einer Unterseite meiner Domain medienmarmela.de (zum Zeitpunkt des Screenshots noch bemeo.de) setzt mind. vier Cookies von youtube.com:

Gleiches passiert z.B. auch bei Google Maps:

Das kann der/die interessierte Leser/in hier testen, aber

• YouTube-Test: https://medienmarmela.de/yt_test.html
• Google Maps-Test: https://medienmarmela.de/gm_test.html
• Seite aufrufen, mit F12 die "Entwicklertools" von Firefox, Chrome, Edge, Internet Explorer öffnen und unter
  • >Web-Speicher (Firefox),
  • >Application >Storage (Chrome),
  • >Debugger (Edge) oder
  • >Netzwerk (Internet Explorer) anschauen, welche Cookies gespeichert werden.

Dass Cookies nicht prinzipiell verwerflich sind, habe ich ja oben schon bemerkt. Allerdings auch, dass Cookies normalerweise nur von derjenigen Webseite ausgelesen werden können, die sie auch gesetzt hat. Heißt hier aber:

Da diese "Drittanbieter"- (auch "Third Party"-) Cookies von YouTube bzw. Google gesetzt wurden, können diese beim nächsten Besuch dieser entsprechenden Webseiten auch wieder ausgelesen werden. Damit setzt YouTube beim Besuch meiner Seite einen YouTube-Cookie und sammelt diese beim nächsten Besuch von YouTube (oder einem Besuch einer anderen Seite mit eingebettetem YouTube-Inhalt?) wieder ein. In Verbindung mit einem YouTube-Konto und/oder einem Geräte-Fingerabdruck können also Daten über besuchte Seiten mit gesehenen Videos und personenbezogenen Daten (Login, IP-Adresse oder Geräte-Merkmale) zu erstaunlich umfangreichen und genauen Benutzenden- / Interessensprofilen verknüpft werden. Das ist schon ziemlich krass und hat den Third-Party-Cookies an anderer Stelle die (m.M.n. berechtigte) Bezeichnung als Pest des Internetzeitalters eingebracht 😮

Und nein, Google/YouTube sind natürlich nicht die Einzigen, die so agieren. Neben Werbenetzwerken gehören wohl Facebook/Instagram, aber auch Vimeo, Slideshare, Giphy, Dailymotion, SoundCloud, Bandcamp, Scribd, Prezi, Sketchfab, Codepen und viele weitere in die Kategorie "Drittanbieter-Cookie-via-iframe-Setzer".

Um der Datensammlung entsprechender Anbieter nicht noch mehr Futter zu liefern, bietet z.B. das Borlabs Cookie-Plugin zwei nette Features an:

1. Erstens wird im Speziellen bei You-Tube die aufgerufene URL zur nocookie-Variante ("Erweiterter Datenschutzmodus"; findet man auch in der Standard-Einbettungsfunktion, allerdings etwas versteckt ganz unten) geändert.
2. Zweitens wird das Laden von iframes erst einmal verhindert; es bedarf dann einer Interaktion des Benutzenden, um diese Inhalte nachzuladen (sog. Zwei-Klick-Lösung). Vor diesem notwendigen zweiten Klick kann man dann einen Hinweis auf Drittanbieter-Cookies und einen Verweis auf weitere Details in der Datenschutzerklärung platzieren.

Da ich Borlabs nicht mehr einsetze, habe ich mich für eine Eigenentwicklung entschieden, die ich bei Zeiten noch mal dokumentieren muss hier beschreibe. Weitere Details gibt es in Teil 3 dieser Artikelserie.

8. Auftragsdatenverarbeitung

Letzter Punkt, den ich auch in der Form gar nicht auf dem Schirm hatte: Da meine WordPress-Installation incl. Datenbank ja nicht bei mir im Keller gehostet wird, ist mein Webhoster ein sog. Auftragsverarbeiter (gem. Art. 4 Nr. 8 DSGVO), manchmal auch Auftragsdatenverarbeiter. Mit diesem muss ich einen Auftragsverabeitungs-Vertrag (sog. AV-Vertrag; vgl. Art. 28 (3) DSGVO) abschließen. Viele Hoster bieten einen Vordruck zum Download an (meist im Kundenmenü auf der Webseite), der ausgefüllt, unterschrieben und zurückgesendet werden muss.

9. Fazit: Meine Hausaufgaben

1. Informationen für die Datenschutzerklärung zusammenstellen
2. Checkbox zum Kommentare-Formular hinzufügen (Einwilligung in die Datenverarbeitung beim Kommentieren, bei Kommentar-Abonnements, für Spam-Überprüfung)
3. Gravatare deaktivieren
4. User-Agent nicht speichern
5. Spam-Filter-Plugin installieren/konfigurieren
6. IP-Adressen (nach Spam-Prüfung) löschen
7. Kommentarabo-Plugin installieren/konfigurieren
8. Emojis deaktivieren
9. Drittinhalte-Blocker konfigurieren oder selber bauen
10. ADV-Vertrag abschließen

Umsetzungen der Hausaufgaben beschreibe ich in Teil 3 der Artikelserie.