Eine Website besteht heute oft nicht mehr nur aus Dateien, die auf dem eigenen Server liegen. Viele Websites binden zusätzliche Dienste von anderen Unternehmen ein: Google Maps für eine Karte, Google Fonts für die Schrift, YouTube für ein Video oder Analyse-Tools für Statistiken.
Technisch ist das schnell gemacht. Datenschutzrechtlich sollte man allerdings genauer hinschauen.
Was ist überhaupt ein Drittanbieter?
Ein Drittanbieter ist zunächst ganz einfach ein Unternehmen oder Dienst, dessen Inhalte oder Funktionen von einer anderen Website eingebunden werden.
Das kann zum Beispiel sein:
- Google Maps
- Google Fonts
- YouTube
- Google Analytics
- ein Newsletter-Dienst
- ein Consent-Tool
- externe JavaScript-Bibliotheken
- Schriftarten oder andere Dateien von einem CDN
Dabei muss nicht einmal ein Cookie gesetzt werden. Bereits das Abrufen einer Datei von einem fremden Server kann datenschutzrechtlich relevant sein, wenn dabei personenbezogene Daten übertragen werden. Genau deshalb ist die Frage „Setzt dieser Dienst Cookies?“ alleine zu kurz gedacht.
Das Problem beginnt oft schon beim Laden
Nehmen wir eine Google-Maps-Karte:
Eine einfache Einbindung kann dazu führen, dass der Browser beim Aufruf der Website direkt Dateien von Google abruft. Der Besucher hat dann bereits mit Google kommuniziert, obwohl er vielleicht noch gar nicht mit der Karte interagiert hat.
Bei Google Maps werden unter anderem Ressourcen von Google und Google Fonts geladen. Damit können auch die datenschutzrechtlichen Probleme externer Google Fonts relevant werden.
Genau deshalb reicht es nicht unbedingt, einfach einen Hinweis neben die Karte zu schreiben.
Auch „Preload“ ist keine Datenschutzlösung
Ein häufiger technischer Gedanke ist, externe Inhalte einfach vorher zu laden, damit sie später schneller angezeigt werden.
Das kann für die Performance sinnvoll sein – am Datenschutzproblem ändert es aber nichts.
Wenn der Browser durch einen preload bereits eine Ressource von einem Drittanbieter anfordert, findet die Kommunikation mit diesem Drittanbieter eben schon statt. Der Inhalt wurde dann nicht erst „bei der Nutzung“ geladen.
Für eine datenschutzfreundliche Einbindung ist deshalb entscheidend, wann die Verbindung zum Drittanbieter tatsächlich aufgebaut wird.
Bei einem Dienst, für den eine Einwilligung erforderlich ist, muss die entsprechende Einwilligung also vor dem Abruf erfolgen. Ein technisch anders benannter Abruf wird dadurch nicht automatisch notwendig oder erlaubt.
Google Fonts als ein gutes Beispiel
Google Fonts lassen sich direkt von Googles Servern laden:
Der Browser muss dafür eine Verbindung zu Google herstellen und die benötigten Dateien abrufen.
Genau diese externe Einbindung ist aus Datenschutzsicht problematisch. Das Landgericht München I hat bereits 2022 die Übermittlung der IP-Adresse beim dynamischen Laden von Google Fonts als unzulässig bewertet. Das Urteil ist inzwischen rechtskräftig.
Und gibt es eine sehr einfache technische Alternative: Die Schrift kann lokal auf dem eigenen Webserver gespeichert und von dort ausgeliefert werden.
Dann muss der Browser für die Schrift keine Verbindung zu Google herstellen. Google Fonts können also weiterhin verwendet werden, ohne sie von Googles Servern laden zu müssen.
Das ist ein gutes Beispiel dafür, dass Datenschutz und Technik nicht immer gegeneinander arbeiten. Manchmal ist die technisch einfachste Lösung gleichzeitig die datenschutzfreundlichere.
Und was ist mit Google Maps?
Bei Google Maps ist die Situation schwieriger.
Eine klassische Einbindung kann bereits beim Laden Verbindungen zu Google herstellen. Zusätzlich können weitere Ressourcen geladen werden, darunter Google Fonts.
Wer Google Maps einsetzen möchte, muss deshalb nicht nur auf Cookies schauen. Je nach konkreter Einbindung können mehrere datenschutzrechtliche Fragen zusammenkommen.
Eine Möglichkeit ist, die Karte zunächst gar nicht von Google zu laden. Stattdessen kann auf der Website zunächst nur ein Platzhalter angezeigt werden.
Erst wenn der Besucher sich bewusst dafür entscheidet, die Karte zu laden, wird die Verbindung zu Google hergestellt.
Das ist technisch deutlich besser, als Google Maps bereits beim ersten Seitenaufruf automatisch zu laden. Es ist allerdings wichtig, die konkrete Umsetzung und die erforderliche Rechtsgrundlage im Einzelfall zu betrachten.
Ein Cookie-Banner löst nicht automatisch jedes Problem
Hier wird es häufig etwas kompliziert.
Ein Consent-Management-System kann Einwilligungen verwalten und bestimmte Dienste blockieren. Es bedeutet aber nicht automatisch, dass jede externe Ressource zuverlässig erkannt und blockiert wird.
Gerade externe Dateien wie Schriftarten können technisch auf unterschiedliche Weise eingebunden werden. Deshalb sollte man nicht davon ausgehen, dass ein Cookie-Tool automatisch jede datenschutzrelevante Verbindung findet.
Außerdem ist ein Cookie nicht die Voraussetzung dafür, dass eine Datenverarbeitung datenschutzrechtlich relevant ist.
Das ist einer der Gründe, warum wir bei Websites lieber zuerst die technische Einbindung betrachten und erst danach überlegen, welches Consent-System überhaupt notwendig ist.
Muss denn jetzt alles lokal liegen?
Nein.
Drittanbieter sind nicht grundsätzlich verboten.
Die entscheidende Frage ist vielmehr:
Was wird von wem geladen, wann passiert das und welche Daten werden dabei übertragen?
Bei einer kleinen Unternehmenswebsite kann man allerdings erstaunlich viel davon vermeiden.
Schriften können lokal eingebunden werden. JavaScript-Bibliotheken können häufig ebenfalls lokal gespeichert werden. Bilder müssen nicht zwingend von einem fremden CDN kommen. Und eine Karte kann gegebenenfalls durch eine datenschutzfreundlichere Alternative ersetzt werden.
Dr. DSGVO empfiehlt bei unnötigen Drittanbieter-Abrufen genau diesen Ansatz: Ressourcen, die problemlos selbst bereitgestellt werden können, sollten möglichst nicht unnötig von fremden Servern geladen werden.
Ein einfacher Test für jede Website
Bei einer neuen Website lohnt sich deshalb eine einfache Frage:
Welche Verbindungen baut mein Browser eigentlich auf, wenn ich die Seite öffne?
Dafür muss man nicht einmal besonders tief in den Quellcode einsteigen. Die Entwicklertools des Browsers können im Bereich „Netzwerk“ zeigen, welche Dateien geladen werden und von welchen Domains sie stammen.
Findet man dort beispielsweise:
googleapis.comgstatic.comyoutube.comgoogle-analytics.com- externe CDN-Domains
- Tracking- oder Marketingdienste
sollte man sich anschauen, warum diese Verbindung überhaupt benötigt wird.
Manchmal gibt es eine einfache lokale Alternative. Manchmal ist der Dienst tatsächlich sinnvoll und muss entsprechend datenschutzrechtlich berücksichtigt werden.
Weniger Drittanbieter bedeutet oft auch weniger Komplexität
Das ist letztlich der wichtigste Punkt.
Eine Website muss nicht möglichst viele externe Dienste verwenden, nur weil sie technisch verfügbar sind.
Wenn eine Schrift lokal ausgeliefert werden kann, braucht man dafür keinen externen Dienst.
Wenn eine Karte nicht unbedingt interaktiv sein muss, reicht vielleicht eine statische Anfahrtsskizze oder ein Link zum Kartendienst.
Wenn eine JavaScript-Bibliothek nur für eine kleine Funktion benötigt wird, kann man möglicherweise ganz darauf verzichten.
Weniger externe Abhängigkeiten bedeuten dabei nicht nur weniger Datenschutzfragen. Die Website hat häufig auch weniger Requests, weniger Abhängigkeiten und weniger Dinge, die beim Laden schiefgehen können.
Eine gute Website sollte deshalb nicht nur fragen: „Kann ich diesen Dienst einbauen?“ – sondern auch: „Muss ich ihn überhaupt einbauen?“