Source: https://medienmarmela.de/welche-daten-verarbeite-ich-dsgvo-pt-2/
Timestamp: 2019-07-20 21:48:27
Document Index: 54849981

Matched Legal Cases: ['Art. 5', 'Art. 2', '§ 15', 'Art. 6', 'Art. 6', '§ 7', '§ 6', 'Art. 6', '§ 6', 'Art. 6', '§ 6', '§ 7', 'Art. 6', 'Art. 6', 'Art. 4', 'Art. 28']

Veröffentlicht am 03. Juli 2018 von Martin Smaxwil, einsortiert in Onlinekram, verschlagwortet mit Cookies, Datenschutz, DSGVO, iframes, wordpress.
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:
Kommentarabonnements,
Drittinhalte und die
Auftragsdatenverarbeitung (durch meinen Hoster).
a. Daten, die von Kommentierenden eingegeben werden
d. Gravatare
a. Google oder Adobe?
b. Font Awesome
7. Drittinhalte
Fazit: Meine Hausaufgaben
Cookies meiner WordPress-Installation
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:
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
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
wordpress_sec_[hash] (für /wp-admin)
bestätigt die erfolgreiche Authentifizierung über eine verschlüsselte Verbindung, notwendig für die Nutzung des Redaktionsbereiches
wordpress_sec_[hash] (für /wp-content/plugins)
bestätigt die erfolgreiche Authentifizierung über eine verschlüsselte Verbindung, notwendig für die Berechtigungen u.a. bzgl. Plugin-Installation und -Konfiguration
wp-settings-[User-ID]
Inhalt: WP-User-ID und verschiedene Einstellungen für den Redaktionsbereich
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.
wp-settings-time-[User-ID]
Inhalt: WP-User-ID und Zeitstempel in Unixzeit.
beinhaltet das Datum und die Zeit der letzten Änderung von Benutzendeneinstellungen. Entspricht dem Datum, wann wp-settings-[UID] gesetzt oder geändert wurde
Inhalt: [Post-ID]-saved
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.
Auch die Funktion "Angemeldet bleiben" setzt dieses Cookie nicht. Vielleicht hängt das mit der WP-Version zusammen? Wer das weiß, schreibt's bitte in die Kommentare.
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:
beinhaltet den Eintrag aus dem Feld "Name"
speichert den Namen der/s Kommentierenden und füllt das Feld bei erneutem Aufruf des Kommentarformulars automatisch aus.
beinhaltet den Eintrag aus dem Feld "E-Mail"
speichert die E-Mail-Adresse der/s Kommentierenden und füllt das Feld bei erneutem Aufruf des Kommentarformulars automatisch aus.
beinhaltet den Eintrag aus dem Feld "Webseite"
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 über eine Opt-In-Möglichkeit zu persönlichen Cookie-Einstellungen. Ohne diese Einstellung vorzunehmen, ist eine Benutzung der Webseite nicht wirklich möglich; die Option "nur technisch notwendige Cookies zulassen" führt aber zu keinerlei Nachteilen. Daher ist das auch keine Forced Consent-Methode; 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 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 (Borlabs Cookie) speichert die Cookie-Einstellungen skurrilerweise in einem Cookie 🙂 - daher gibt es eine Nr. 12 auf meiner Liste:
reject all / first-party / all
Lebensdauer: 1 Woche
beinhaltet die individuelle Voreinstellung der Besuchenden zu Cookies (nur absolut notwendige Cookies zulassen / Cookies dieser Seite / Auch Drittanbieter-Cookies)
Das war's schon an Cookies.
Für technisch notwendige Pflicht-Cookies (Nrn. 1 - 7, 12) 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).
Weitere von meiner Webseite gesetzte Cookies sind mir nicht bekannt. Wenn Du einen entdeckst, sag mir doch bitte Bescheid!
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. 😮
Im Detail werden für jeden Kommentar vier Datengruppen gespeichert:
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 § 6 (1) lit. a) DSGVO). Auch darauf weise ich natürlich in der Datenschutzerklärung hin.
Kommentare werden mit Name, E-Mail-Adresse und IP-Adresse gespeichert. Nicht gerade Datenvermeidung at its best...
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 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.
Beispiele für User Agents in der Datenbank
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.
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).
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.
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:
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;
dezidiertes Abonnement von Antworten auf den eigenen Kommentar oder von allen Kommentaren möglich,
Abonnement von Kommentaren ohne selbst zu kommentieren moglich und
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):
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 🙂
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:
Was zum Teufel tut das WP-Emoji-Skript?
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/:
Quelle: https://twemoji.maxcdn.com/2/test/preview.html
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.
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.
Ich habe sowohl Google Fonts als auch Adobe Typekit zweitweise 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.
Rechtsgrundlage ist hier Art. 6 (1) lit. f) DSGVO. Mein berechtigtes Interesse besteht in einer ansprechenden Darstellung meiner 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 meiner Datenschutzerklärung incl. Verweise auf die allgemeine Datenschutzerklärung von Adobe und die speziellere von Typekit (neue URL: Datenschutzhinweise für Adobe Fonts) fällig.
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. Darüber hinaus kann ich auch hier nur auf Adobes Mitgliedschaft beim Privacy Shield hinweisen.
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.
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 setzt mind. vier Cookies von youtube.com:
YouTube Cookies via iframe
Gleiches passiert z.B. auch bei Google Maps:
Google Maps Cookies via iframe
Das kann der/die interessierte Leser/in hier testen, aber
Dadurch werden Cookies auf Deinem Endgerät gespeichert. Klar, oder?
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 und viele weitere in die Kategorie "Drittanbieter-Cookie-via-iframe-Setzer". Um der Datensammlung entsprechender Anbieter nicht noch mehr Futter zu liefern, bietet das Borlabs Cookie-Plugin zwei nette Features an:
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.
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:
Weitere Details gibt es in Teil 3 dieser Artikelserie.
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.
Informationen für die Datenschutzerklärung zusammenstellen
Checkbox zum Kommentare-Formular hinzufügen (Einwilligung in die Datenverarbeitung beim Kommentieren, bei Kommentar-Abonnements, für Spam-Überprüfung)
Gravatare deaktivieren
User-Agent nicht speichern
Spam-Filter-Plugin installieren/konfigurieren
IP-Adressen (nach Spam-Prüfung) löschen
Kommentarabo-Plugin installieren/konfigurieren
Drittinhalte-Blocker konfigurieren
ADV-Vertrag abschließen
Umsetzungen der Hausaufgaben beschreibe ich in Teil 3 der Artikelserie.
Der Text Welche Daten verarbeite ich? incl. der Abbildungen von Martin Smaxwil ist lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz. Weitere Infos gibt es unter https://medienmarmela.de/Lizenzen.