Die Website als Flickenteppich
PSP Case Study zur DSGVO: Praxisfall 13

DSGVO: Praktischer Fall

Die Huber AG hat einen Online-Auftritt. Jeder Browser eines Internet-Nutzers, der die Website der Huber AG aufruft, wird durch den Code der Website zunächst dazu veranlasst, einen Zeichensatz (Font) – Teil der „corporate identity“ der Huber AG – von Google-Servern nachzuladen. Weiter wird der Browser dazu veranlasst, bestimmte Java-Funktionsbibliotheken von Drittservern nachzuladen. Diese „Drittdatenquellen“, welche der Browser abfragen muss, um die Website der Huber AG überhaupt darstellen zu können, erhalten vom Browser verschiedene Informationen, insbesondere die IP-Adresse des Rechners, auf dem der Browser läuft. Die Dritten haben ihr Einverständnis gegeben, dass ihre Seiten als „Drittdatenquellen“ fungieren können, betreiben aber umfangreiches Tracking (Aufbau von Nutzerprofilen) mithilfe der Browser-Daten. Die Huber AG macht sich dazu keine Gedanken.

Niemand muss im Zeitalter des Internets das Rad immer wieder neu erfinden; was verfügbar ist und als gut angesehen wird, das wird als Informationsquelle genutzt. Das betrifft etwa Bilddaten, Zeichensätze, Funktionsbibliotheken mit Code-Fragmenten, Kartendaten, Multimediainhalte, Tracking-Technologien, iFrames und sonstige Daten, die ein Website-Betreiber gerne vorgefertigt einbindet, um Ressourcen zu sparen. Der Benutzer selbst bemerkt gar nicht, dass sein Browser im Hintergrund die Seite mithilfe dieser Ressourcen „zusammenbaut“. Da muss es noch gar nicht um urheberrechtliche Fragen, die Gefahr von Schadsoftware, die Zulässigkeit von Werbe-Tracking oder aktiven Elemente von sozialen Medien (Stichwort „Like“-Button) gehen. Zunächst einmal muss die Seite als solche „funktionieren“.

Es ist offensichtlich, dass die „Drittdatenquelle“ keine Pflichthinweise an den Betroffenen (Website-Besucher) erteilt, dass und welche personenbezogenen Daten sie zu welchen Zwecken verarbeitet. Der Website-Besucher soll ja den Einsatz der „Drittdatenquelle“ gar nicht merken; entsprechend wird auch die Zieladresse in der Adresszeile des Browsers nicht angezeigt. In den wenigsten Fällen wird in der Datenschutzerklärung auf den Einsatz von Drittdatenquellen hingewiesen – am ehesten noch auf Google-Maps-Kartenausschnitten. Im oben beschriebenen Fall der Google-Fonts und Funktionsbibliotheken gilt es darüber hinaus zu beachten, dass zu dem Zeitpunkt, zu dem die Datenschutzerklärung für den Betroffenen erstmals überhaupt angezeigt werden kann, die Datenerhebung durch die „Drittdatenquelle“ bereits abgeschlossen ist.

Man kann sich in diesen Fällen mit der Antwort des Bayerischen Landesamts für Datenschutzaufsicht in dessen FAQ-Sektion auf die Frage „Dürfen externe Schriftarten z. B. Google Fonts auf der Website eingebunden werden?“ helfen: „Ja. Wichtig ist, dass in der Datenschutzerklärung auf der Website darüber informiert wird.“ Auf die entsprechende Frage zur Einbindung von Google Maps lautet die Antwort: „Ja. Wichtig ist, dass in der Datenschutzerklärung auf der Website darüber informiert wird. Außerdem sollten die Inhalte von Google Maps erst dann geladen werden, wenn der Nutzer aktiv den Kartendienst in Anspruch nimmt, z. B. durch einen extra Klick.“ Das ist pragmatisch, kurz und gut. Es wäre aber noch schöner, wenn sich dieses – für den gesunden Menschenverstand möglicherweise sehr überzeugende – Ergebnis auch aus der DSGVO ableiten ließe. Aber dann ergeben sich leider eine Menge Probleme, die die bayerische Datenschutzaufsicht nicht aufwirft und dementsprechend auch nicht lösen muss. Der Haken ist natürlich, dass die Datenschutzaufsichtsbehörden den Gesetzestext nicht verändern können. Und ob die Antwort des Europäischen Gerichtshofes, wenn er mit dieser Fallgestaltung konfrontiert würde, ebenso simpel ausfallen würde, darf bezweifelt werden.

Der Unterschied zu Fall 12 liegt darin, dass hier keine Daten von der Huber AG an die „Drittdatenquelle“ (bzw. den dahinterstehenden Anbieter) direkt übermittelt werden. Vielmehr weist der Code der Webseite der Huber AG den Browser des Webseiten-Besuchers an, mit einem Dritten Kontakt aufzunehmen, der dann gegebenenfalls (neben der IP-Adresse) verschiedene personenbezogene Daten (Browser-Fingerprint etc.) erhebt und dabei gegen Datenschutzrecht verstößt. Diese Konstellation geht über einen (externen) Link, den der Besucher selbst (aktiv) anklickt, hinaus, und erinnert an die Technik der „frames“ (eingebettete Seitenteile aus Drittquellen). Der Jurist denkt dabei an die Konstruktion der „mittelbaren Täterschaft“ unter Einsatz eines „Werkzeugs“, in diesem Fall des ahnungslosen Webseiten-Besuchers, der nur eine Webseite aufrufen wollte und der (bzw. dessen Browser) sodann unwissentlich Informationen an Dritte preisgibt. Datenschutzrechtlich wäre jedoch eher die Frage zu stellen, ob die Huber AG und die „Drittdatenquelle“ – ähnlich wie in den Facebook-Fanpage- und Like-Button-Fällen des EuGH – gemeinsam für Datenschutzverstöße der „Drittdatenquelle“ verantwortlich sind. Im Unterschied zu den EuGH-Fällen profitiert die Huber AG aber nicht an den durch die „Drittdatenquelle“ erhobenen personenbezogenen Daten der Webseiten-Besucher, sondern an den (ihrerseits nicht personenbezogenen) Daten, die von der „Drittdatenquelle“ an den Webseiten-Besucher ausgeliefert werden – also an den zugeladenen Ressourcen. Möglicherweise sind aber die „vermittelten“ personenbezogenen Daten der Webseiten-Besucher die „Währung“, mit der sich die „Drittdatenquelle“ bezahlen lässt, um überhaupt Webseiten-Ressourcen zum Hinzuladen anzubieten.

Auf dieser Basis stellen sich datenschutzrechtlich eine Reihe von Fragen. Ein Hinweis in der Datenschutzerklärung auf die Ressource ist gut und schön, aber müsste der Hinweis nicht erscheinen, bevor auf die Ressource zugegriffen wird? Und auf welcher datenschutzrechtlichen Legitimationsgrundlage erhebt die „Drittdatenquelle“ die Daten vom Webseiten-Besucher? Oft sitzt die „Drittdatenquelle“ in einem Drittland und es muss eine gesonderte Grundlage für die Drittlandsübermittlung vorliegen – muss nun der Webseiten-Betreiber eine Einwilligung „für den Dritten“ einholen, weil schon Daten in das Drittland übermittelt werden müssten, bevor die „Drittdatenquelle“ überhaupt selbst eine Einwilligung einholen könnte?

Wenn man solche Ressourcen wie Zeichensatz und Kartenmaterial in der Mitte des Spektrum verortet, dann wäre am einen Ende des Spektrums ein gewöhnlicher Link und am anderen Ende der Facebook-Like-Button zu verorten. Bei letzterem handelt es sich um ein Stück Code von Facebook, das vom Webseiten-Betreiber integriert wird und welches schon beim Aufruf der Webseite „allerhand“ Daten an Facebook überträgt, mit denen Facebook dann „allerhand“ macht bzw. machen kann. Dies gilt sowohl für den Fall, dass der Webseiten-Besucher selbst Mitglied des sozialen Netzwerks ist, als auch für den Fall, dass der Webseiten-Besucher mit dem sozialen Netzwerk bislang nie etwas zu tun hatte. Die zugrundeliegende Mechanik wurde im Like-Button-Urteil des Europäischen Gerichtshofs vom Juli 2019 („Fashion ID“-Entscheidung) abstrakt so skizziert, dass es ein Webseiten-Betreiber (dort „Fashion ID“) einem Dienstebetreiber (dort Facebook) ermöglicht, personenbezogene Daten von den Nutzern der Webseite zu erlangen. Der einfachste Fall des „Zuführens“ von personenbezogenen Daten an einen Dritten (verbunden mit der Möglichkeit, auf dieser Basis weitere Daten „abzusaugen“) ist die Übermittlung von dessen IP-Adresse. Dies ist aber auch bei jedem normalem Link (oder Frame) der Fall, auf den der Webseiten-Besucher klickt und der zum Laden einer anderen Webseite führt (was vielleicht nicht einmal richtig deutlich für den Nutzer ist, wenn der „Sie verlassen jetzt diese Internet-Seite“-Hinweis fehlt). Natürlich wird der Webseiten-Besucher nach dem Anklicken des Links im Regelfall wissen, dass er sich nun auf einer „anderen Seite“ befindet, aber möglicherweise ist ihm das in dem Moment, in dem er den Link anklickt, noch nicht bewusst. Ist der Unterschied zwischen einem (vielleicht nicht als solchem erkennbaren) externen Link, einer (für den Webseiten-Besucher unsichtbaren) externen Ressource und einem (unsichtbaren) „Plug-in“ so groß, dass nur ein Plug-in zu einer gemeinsamen Verantwortlichkeit führt, während eine externe Ressource nur „aufklärungspflichtig“ ist und ein Link zu einer anderen Webseite unbeachtlich ist?

Dies beschwört eine alte Diskussion über die – umstrittene – Prüfpflicht des „Linksetzers“ herauf, die hier dazu führen würde, dass der „Linksetzer“ (d. h. der Webseiten-Betreiber) die Datenschutzkonformität der verlinkten Webseite (ständig) prüfen muss, weil er es dessen Betreiber schließlich auch „ermöglicht, personenbezogene Daten zu erlangen“. Datenschutzrechtlich würde dies noch dazu bedeuten, dass der „Linksetzer“ vollumfänglich und im Vorhinein über die datenschutzrechtlichen Verhältnisse der Zielseite aufklären müsste, denn die Einwilligung des Betroffenen, dass die Zielseite nach dem Klick auf den Link automatisch Daten (zumindest die IP-Adresse) des Betroffenen erhebt, muss – wenn eine solche Einwilligung notwendig ist – wohlinformiert sein. In den FAQ zu Cookies und Tracking des Landesdatenschutzbeauftragten von Baden-Württemberg findet sich der vielsagende, natürlich nicht mit Blick auf Hyperlinks geschriebene Satz:

„Eine ausdrückliche, informierte, freiwillige, aktive und vorherige Einwilligung der Nutzer ist insbesondere erforderlich, wenn Dritten die Möglichkeit gegeben wird, Nutzungsverhalten zu analysieren [...]. Einwilligungs-Banner müssen eingesetzt werden, wenn tatsächlich eine Einwilligung des Nutzers nötig ist, also insbesondere [...] Dritten die Möglichkeit eröffnet wird, Daten zu erheben.“

Wen das Argument der datenschutzrechtlichen „Gefährlichkeit“ von Links nicht überzeugt, der mag sich vor Augen halten, dass Links häufig zusätzliche Informationen über die Verarbeitungssituation „verraten“, die dann mit der – obligatorisch an den Server des „Link-Ziels“ übergebenen – IP-Adresse des Benutzers verknüpft werden. So kann etwa ein Link (vereinfacht gesagt) den Bestandteil „source=twitter“ als Teil der aufgerufenen URL beinhalten, der dem Betreiber des Ziel-Servers die (personenbezogene) Information verschafft, dass der (durch seine IP-Adresse identifizierbare) Benutzer sich entweder auf der Twitter-Plattform aufgehalten hat (und dort den Link angeklickt hat) – diese Information erhofft sich natürlich der Betreiber des Ziel-Servers – oder ihm der Link (zumindest) von einem Twitter-Nutzer weitergeleitet wurde.

Man sieht, dass, wenn man hier einen „rigorosen Kurs fährt“, bei vielen Webseiten erheblich (nachgedacht und) nachgebessert werden muss, eventuell mithilfe von Informationen, die der Webseiten-Betreiber gar nicht hat und sich auf gar nicht beschaffen kann: Er kann nicht ohne Weiteres (s. aber Fall 12 zu möglichen „due diligence“-Pflichten in der Datenkette) herausfinden, was der Dritte mit den Daten machen wird, und kann deshalb weder ordnungsgemäße Pflichtinformationen noch später eine vollständige Auskunft erteilen. Dazu muss man gar nicht erst den „Extremfall“ des Facebook-Like-Buttons zugrunde legen.

Diese News könnten Sie auch interessieren
Alle News
Mehr laden
Diese Vorträge & Veröffentlichungen könnten Sie interessieren
Alle Vorträge & Veröffentlichungen
Mehr laden