Webfonts wie Google Fonts sind von kaum einer modernen Website wegzudenken. Doch werden diese Schriftarten über einen externen Anbieter geladen, führt dies zu datenschutzrechtlichen Problemen und ggfs. Schadensersatzansprüchen, wie ein aktuelles Urteil zeigt. Wir erklären Ihnen, wie Sie die Schriften auf Ihrer Website testen und als Webfonts rechtskonform einbinden.
Was ist das Problem bei Webfonts?
Viele Anbieter von Webfonts, sprich typografischer Gestaltungen in Form von Schriftarten, hosten diese selbst. Darunter auch Google als größter Anbieter einer Schriftbibliothek unter dem Namen Google Fonts. Die einfachste Methode Schriften auf der Website einzubinden, erfolgt durch eine verlinkte URL mittels eines href-Attributs im Backend der Website. Viele Templates für Content-Management-Systeme wie etwa WordPress nutzen diese Funktion.
Dadurch wird auf dem Internetauftritt vieler Websitebetreiber immer noch auf den Fremdinhalt der Google-Server verlinkt. Wird die Website aufgerufen, erfolgt eine automatische Verbindung zum entsprechenden Google-Server, der die Schriften ausliefert und im Frontend des Besuchers anzeigt.
Problematisch dabei ist, dass Server standardmäßig Eventdaten im Rahmen des Zugriffs mitschreiben und speichern. Sobald der Rechner des Endnutzers über die aufgerufene Website mit dem Google-Server kommuniziert, werden entsprechende Zugriffsdaten erhoben, die auch die IP-Adresse des anfragenden Geräts enthält. Da die Rechtsprechung IP-Adressen als personenbezogene Daten erachtet, ist der datenschutzrechtliche Anwendungsbereich eröffnet und das Verarbeiten selbiger grundsätzlich rechtfertigungsbedürftig. Eine Übermittlung ist daher an bestimmte Anforderungen geknüpft.
Was müssen Websitebetreiber tun?
Zunächst sollten Websitebetreiber prüfen, ob sie die IP-Adressen ihrer Besucher durch den Einsatz von Webfonts übermitteln. Ob die Einbindung von Schriften zentral (selbst gehostet) oder dezentral (fremd gehostet) erfolgt, kann am bequemsten über den Entwicklermodus oder den Seitenquelltext im Browser eingesehen werden.
- Für erstere Funktion drückt man im Falle von Windows F12 auf der Tastatur und wählt dann den Bereich Netzwerkanalyse.
- Für Letztere Funktion klickt man auf Strg + U.
- Beides kann alternativ auch durch Klick mit rechter Maustaste auf einer Webseite erreicht werden.
In der Netzwerkanalyse des Entwicklermodus werden die von der Website ausgelösten Serveranfragen aufgelistet.
Im Quelltext gelangt man mit Strg + f in die Suchfunktion, worüber man nach dem Stichwort „Fonts“ suchen kann.
Wird in der Netzwerkanalyse oder im Seitenquelltext eine Bezugsquelle mit href-Attribut, wie z.B. „fonts.googleapis“ oder „fonts.gstatic“ angezeigt, und man gelangt mittels Klick hierauf auf eine neue Website, handelt es sich um die externe Lösung, wodurch Google (oder ein anderer Anbieter wie Adobe) an die IP-Adresse der Websitebesucher gelangt.
Sind dem Quelltext selbst zahlreiche Fonts direkt zu entnehmen, ohne einen entsprechenden Referenzlink, kann dagegen von einer lokalen Einbindung ausgegangen werden.
Wer zusätzliche Informationen abfragen will, kann im Entwickler-Cockpit sowohl unter „Netzwerk(analyse)“, als auch unter „Quellcode“, eingebundenen Fremdcode ausfindig machen. Hierbei werden entweder die verschiedenen Hosts der Inhalte oder die fremden Domänen in eigenen Ordnern angezeigt. Sind die Schriften lokal eingebunden, dürfen hierin keinerlei Google-Quellen mehr auftauchen.
Auch gängige Browser Addons können entsprechenden Netzwerkverkehr auslesen. Dies können Browserfirewalls oder aber spezielle Analysetools sein. Die Bandbreite solcher Tools ist groß.
Abhilfe: Lokale Einbindung, Anonymisierung oder Einwilligung
Gängige Webfonts können grundsätzlich frei zugänglich und quelloffen heruntergeladen werden. Die einfachste Lösung, Webfonts datenschutzkonform einzubinden, ist daher die direkte Auslieferung vom eigenen Server. Eine Kommunikation mit einem fremden Server und somit auch ein Datenfluss entstehen erst gar nicht. Auch Google selbst bietet seine Bibliothek zur freien Nutzung an.
Sobald man die Auswahl seiner Fonts getroffen hat, kann man dieses meist im Zip-Format herunterladen und auf dem eigenen Server hochladen. Der (CSS-)Code wird im Grunde nur im Backend der Website über die Entwickleroberfläche selbst als Fremdcode oder über ein Plugin eingefügt. Dem Browser wird der entsprechende Speicherort dann mittels CSS-Befehl mitgeteilt.
Im letzten Schritt muss der ursprüngliche Referenzlink zu Google entfernt werden. Dafür ist oft eine Anpassung des verwendeten Templates notwendig. Nicht selten findet man in der Praxis eine hybride Form der Umsetzung.
Will man auf die dezentrale Lösung partout nicht setzen – argumentiert wird zumeist mit einer zu großen Belastung der eigenen Server – wird man um die Einbindung über ein Consent-Tool nicht herumkommen. D.h., dass die Schriften technisch erst dann nachgeladen werden dürfen, wenn der Websitebesucher diesem Dienst ausdrücklich zustimmt. Bis zu einem entsprechenden informierten Opt-in, darf die Seite keine Daten an Drittserver übermitteln. Ist der Besucher also trotz des nicht bestätigten Consent-Banners auf der Website unterwegs, kann dies Auswirkungen auf die grafische Darstellung haben.
Zusätzlich sei hier nochmals auf die nicht gelöste Drittlandproblematik hingewiesen, sollten die ausliefernden Server – wie dies beispielsweise bei Google der Fall ist – in einem unsicheren Drittland wie den USA stehen.
Selten wird man auf den Fall stoßen, dass Daten skriptseitig vor Übermittlung an Google anonymisiert werden. Zumindest für das Nachladen nur von Schriften wird ein solcher Aufwand nicht betrieben werden. Der Rückgriff auf die lokale Umsetzung ist einfacher und praktikabler.
Fazit: Lokale Einbindung als Win-Win für Websitebetreiber
Neben den rechtlichen Gründen, auf eine lokale Einbindung zu setzen, gibt es kaum mehr Gründe für eine dezentrale Realisierung. Auch muss nicht mehr zwingend auf Google-Server zurückgegriffen werden, um bereits auf im Cache des Nutzers gespeicherte Fonts zurückgreifen zu können. Bessere Ladezeiten gehen damit nicht zwingend einher, im Gegenteil kann das lokale Laden von (nicht allzu vielen) Schriftarten die Website-Performance sogar steigern. Websitebetreiber sparen sich zudem Zeit für die Konfiguration ihrer Consent-Lösungen, welche immer mit der dezentralen Lösung einhergehen müssen.
Als goldene Regel können Websitebetreiber mitnehmen, dass aus datenschutzrechtlicher Sicht alle eigens gehosteten Dienste in der Regel immer datenschutzfreundlicher und damit rechtsicherer sind. Eine Rechtsgrundlage wird dann nämlich in diesem Fall nur für das Erheben selbst und nicht zusätzlich für die Übermittlung benötigt.
Rechtsunsicherheiten bestehen bei der dezentralen Lösung darüber hinaus auch in Hinblick auf die Konstellation zwischen Websitebetreiber und Empfänger der Daten. Denn ob beispielsweise Google die gewonnenen Daten mit Drittquellen zusammenführt und zu eigenen Zwecken weiterverarbeitet, wird man nicht ausschließen können. Eine für die Übermittlung freiwillige und informierte Einwilligung des Besuchers scheint jedenfalls fragwürdig. Auch an eine möglicherweise notwendige vertragliche Konstellation zur Nutzung der Daten nach Art. 26 bzw. 28 DSGVO wird man schwierig herankommen.
Bestellen Sie jetzt einen unserer Experten als externen Datenschutzbeauftragten für Ihr Unternehmen und profitieren von der DSGVO-Compliance zum Flatratepreis!