Homepage: Einbindung externer Inhalte nur mit Einwilligung?

Grund der Anfrage ist eine Fragestellung im Softwareforum von ZETA, einem Desktop-CMS. Vielfach werden auf einer Homepage externe Inhalte via IFrame oder RSS eingebunden. Aufgrund des Artikels unter https://dr-dsgvo.de/iframes-haftung-bei-einbindung-externer-inhalte/ stellt sich die Frage, ob das im CMS bereits integrierte Cookie-Consent dahingehend erweitert werden sollte, dass sämtliche externen Inhalte unterbunden werden bis zu einer Einwilligung des Besuchers.
Das vorhandene Cookie-Consent blockiert bisher Inhalte von bekannten Diensten wie Youtube, Facebook, GA & Co.
IFrames und RSS-Feeds, die nicht versuchen, Cookies zu setzen, werden nicht blockiert. Hierbei geht es beispielsweise um die Einbindung von Warnungen des DWD, Hochwasserpegel, Meldungen aus BIWAPP, aber auch beispielsweise Scripts von Reiseveranstaltern.
Urheberrechtlich ist bereits klargestellt, dass die externen Anbieter entweder im Rahmen einer Lizenz oder via Vertrag der Einbindung auf der Webseite zugestimmt haben.

Datenschutzrechtlich geht es um folgendes Problem:

Der Seitenbetreiber erklärt in seiner Datenschutzinformation, dass Inhalte externer Anbieter in der Homepage eingebunden sind. Die Übermittlung von pb. Daten (IP-Adresse) an den externen Anbieter ist notwendig, da nur hierüber die externen Inhalte dargestellt werden können. Nach dem oben verlinkten Artikel wäre aber bereits dafür eine Einwilligung erforderlich. Dies würde dazu führen, dass bei einer Seite einer freiwilligen Feuerwehr Warnmeldungen aus BIWAPP nicht angezeigt werden, bis der Besucher zustimmt. Gleiches träfe auch zu auf die Webseite einer Gemeinde, die den aktuellen Hochwasserspiegel via IFrame eingebunden hat, oder einen Reiseanbieter, der Inhalte eines Buchungsportals verwendet.
Frage: Kann die Übermittlung der IP-Adresse als “notwendig” betrachtet werden oder muss hier tatsächlich eine Einwilligung erfolgen?

Zur Verarbeitung pb Daten gibt es neben der Einwilligung auch das berechtigte Interesse als Rechtsgrundlage. Das Abstellen auf berecht. Interesse erfordert eine Interessenabwägung. Beim Einbinden von Katastrophenwarnmeldungen auf einer Webseite der FFW, wird die Interessenabwägung regelmäßig sicher zugunsten des Verantwortlichen ausfallen können. In diese Betrachtung muss man aber einbeziehen, wo die Inhalte herkommen. Denn hierbei kann eine Einwilligung notwendig werden, Stichwort “Drittlandtransfer”.

Außerdem empfehle ich, auch wenn man selbst keinen Einfluss auf die Inhalte des I-Frames hat, zu prüfen ob die Webseite, die im I-Frame geladen werden soll, selbst datenschutzkonform arbeitet. Natürlich wird dies nur bis zu einem gewissen Grad sinnvoll sein. Aber man sollte schon prüfen können, ob die I-Frame-Seite selbst Tools wie Google Analytics & Co. verwendet und dabei entsprechende Consent-Banner und eine ausreichende Datenschutzerklärung verwendet.

Da bin ich nicht sicher, denn auch die Seiten mit den Warnmeldungen können direkt aufgerufen werden und das heißt, es fehlt die Notwendigkeit dafür, die externen Inhalte als eigene Inhalte einzubinden. Der Link zum Drittanbieter genügt vollkommen (das mildere Mittel). Es fehlt eine rechtliche Anforderung, dass die Inhalte unmittelbar anzuzeigen sind. Das würde bei der Interessenabwägung mE zugunsten des Betroffenen sprechen. Etwas anderes wäre es vielleicht, wenn die externen Inhalte nur über das eigene Angebot erreicht werden können, weil zB ein Login des Anbieters notwendig ist.

Man muss hier unterscheiden: Eine Übermittlung der Besucherdaten vom Verantwortlichen an den Drittanbieter findet nicht statt. Die Übermittlung der Daten erfolgt durch den Besucher selbst. Aber es kann eine gemeinsame Verantwortlichkeit durch die Nutzung externer Inhalte bestehen. Zur Einbindung externer Inhalte, die eine Datenübermittlung in Drittstatten beinhalten, äußerten sich in jüngster Vergangenheit mehrere Gerichte in der Hinsicht, dass eine Einwilligung vor der Übermittlung notwendig ist (zB LG München Az. 3 O 17493/20; VG Wiesbaden Az. 6 L 738/21.WI). Aus Sicht der DSGVO steht also die Frage der gemeinsamen Verantwortlichkeit im Raum. Denn im Gegensatz zum Link, der unmissverständlich auf eine weitere Seite führt, wird das Angebot des Drittanbieters als eigener Inhalt dargestellt und somit über Zweck und Mittel des Drittanbieters im Rahmen des eigenen Angebotes verfügt. Das ist der Unterschied zum Link, der eindeutig auf ein fremdes Angebot verweist.

Das TTDSG fordert in §19 Abs.3:

Die Weitervermittlung zu einem anderen Anbieter von Telemedien ist dem Nutzer anzuzeigen.

Das wurde unverändert von §13 Abs.5 TMG übernommen und hat seinen Ursprung in §4 Abs.3 TDDSG (Teledienstedatenschutzgesetz). In der Gesetzesbegründung des TDDSG aus dem Jahr 1997 (BT-Drs 13/7385) heißt es dazu:

Zweck des Absatzes 3 ist es, dem Nutzer Transparenz über die Weiterschaltung zu einem weiteren Diensteanbieter zu ermöglichen. Ohne eine derartige Vorschrift können weder das Auskunftsrecht des Nutzers noch eine datenschutzrechtliche Kontrolle wirksam wahrgenommen werden.

Das Beispiel des LDA Bayern zur Einbindung von Drittdiensten oder -inhalten ist missverständlich formuliert[1]. Durch das Einbinden von Drittinhalten ohne Verlinkung wird ein Onlineangebot natürlich nicht verlassen und es findet auch keine technische Weiterleitung statt (zB statt <img src="www.irgend.wo/images/…> die lokale Kopie <img src=images/…>). Dazu passt allerdings nicht der Hinweis, die Einbindung von Drittinhalten sei häufig mit der Übermittlung von personenbezogenen Daten an Drittanbieter verbunden. Wird das Onlineangebot nicht verlassen, werden auch keine Daten an Dritte übermittelt. Hier wurden offenbar zweierlei Formen der Einbindung vermischt, nämlich eine lokale Kopie des Drittinhaltes (= Nichtverlassen des Onlineangebots) und das Laden externer Drittinhalte mittels Aufruf der Quelle (= Verlassen des Onlineangebots).
Durch die Einbindung externer Inhalte per iframe erfolgt die Weiterleitung bereits mit dem Aufruf der Webseite. Sie findet also vor der geforderten Anzeige einer Weitervermittlung statt. Technisch passiert beim direkten Besuch des Drittanbieters via Link und bei der Einbindung via iframe dasselbe: Aufbau TCP-Verbindung und Datenübermittlung zum Drittanbieter (IP, Browserdaten etc.). Ein technischer Unterschied besteht im Umfang der Inhalte: Laden sämtlicher Inhalte beim Besuch des Drittanbieters vs. partielles Laden beim Einbinden einzelner Inhalte des Drittanbieters. Ein datenschutzrechtlicher Unterschied kann ebenfalls im Umfang der Datenverarbeitung bestehen: Beim Laden der kompletten Seite kann eine Weiterverarbeitung stattfinden (Scripte, Cookies), was bei partiellen Inhalten vielleicht nicht passiert.

Mit der Einbettung von externen Inhalten in iframes findet die Weiterleitung oder -vermittlung idR ohne Wissen des Besuchers statt (gleiches bei Bildern, Fonts, Scripten uä). Meist verrät erst der Blick in den Quelltext das tatsächliche Geschehen. Damit sind wir bei dem in der Gesetzesbegründung angesprochenen Problem: Die Nutzung ist für den Besucher intransparent; die Verarbeitung von pb Daten ist unbekannt; es fehlt die Möglichkeit der datenschutzrechtlichen Kontrolle. Und während ein Besucher bei einem Link über die Weiterleitung frei entscheiden kann, bleibt ihm diese Entscheidung bei iframes versagt.

Aus Sicht der IT-Sicherheit sind iframes, die externe Inhalte laden, grundsätzlich nicht zu empfehlen[2], da auch der Anbieter keine Kontrolle über die Drittinhalte hat.

Die Methode, auf externen Inhalt hinzuweisen und einen Button “Externe Inhalte anzeigen” einzubinden, wahlweise den Link zum Drittanbieter anzuzeigen, ist wohl das empfehlenswerte Vorgehen. Das ermöglichte dem Besucher eine freie Entscheidung und mit der Nutzung des Buttons würde dem Anzeigen des externen Inhaltes ebenso zugestimmt wie beim Klicken auf einen Link.

[1] Rn21, Erläuterungen zum neuen Telekommunikation-Telemedien-Datenschutz-Gesetz (TTDSG), Orientierungshilfe
https://www.datenschutz-bayern.de/datenschutzreform2018/OH_TTDSG_Telemedien.pdf
[2] https://owasp.org/www-community/attacks/Cross_Frame_Scripting

Orientierungshilfe der Aufsichtsbehörden für Anbieter:innen von Telemedien ab dem 1. Dezember 2021 (OH Telemedien 2021)
https://datenschutzkonferenz-online.de/media/oh/20211220_oh_telemedien.pdf

1 „Gefällt mir“

Es gibt auch die Möglichkeit, zunächst Platzhalter anzuzeigen, dort die Hinweise unterzubringen und erst nach “Klick” nachzuladen. Als User gefällt mir das besser und in einem Cookiebanner würde ich die Info nicht erwarten.

Zur formalen Frage:

Ich tue mir schwer, hier ein berechtigtes Interesse des Betreibers zu erkennen - welches soll das sein?

Die Erforderlichkeit für iFrames kann man einfach nicht behaupten: Links tun es genauso, es wird nur weniger “hübsch & bequem”.

Eine Abwägung kann man hier wohl vertreten (sie mtob).

Für die Anwendung von Art 6 1 f) DS-GVO braucht man alle 3 Punkte, https://www.datenschutz-wiki.de/DSGVO:Art_6

Danke für das zahlreiche Feedback. Durch die Kommentare wird deutlich, dass es erhebliche Bedenken gegen das “berechtigte Interesse” gibt.

@mtob Sofern die externe Seite Cookies verwendet, wird dies bereits jetzt über das Widget Cookie-Consent erkannt und bis zur Einwilligung das Script blockiert. Der Besucher kann dann selektiv auswählen, welche externen Medien er angezeigt bekommen möchte.

@anzolino Ja, ein Link wäre dann das mildere Mittel. Hier kommen wir letztlich aber auch zu dem Problem, dass dann zwischen internen und externen Links unterschieden werden müsste, damit tatsächlich die “Fremdheit des Angebotes” erkennbar wird. Wir wären dann wieder beim Weiterleitungsfenster “Sie werden in 10 Sekunden auf eine externe Seite weitergeleitet. Bitte drücken Sie OK, wenn Sie direkt zur exterenen Seite wollen oder ABBRUCH, wenn Sie zur vorherigen Seite zurückkehren möchten”.

@haderner Der Button “Externe Inhalte anzeigen” ist bereits über das in der Software integrierte Cookie-Tool vorhanden. Dieses ist im Gegensatz zu Drittanwendungen Bestandteil der eigenen Webseite. Externe Inhalte, in deren Code Cookies enthalten sind, werden hierdurch geblockt. In der gegenwärtigen Diskussion im Entwicklerforum geht es halt um die Frage, dieses Tool generell auf IFrames und RSS-Feeds auszuweiten.

Zum “berechtigten Interesse”: Ein Autohaus bietet auf seiner Homepage Fahrzeuge an, die in der Datenbank des Händlers bei mobile.de eingepflegt sind. Wenn er statt dessen auf der eigenen Homepage nur einen Link zu den Fahrzeugen setzt, müsste er nach jedem Verkauf die eigene Homepage bearbeiten und den Link entfernen, da dieser ansonsten ins Leere läuft. Außerdem möchte er ja gezielt seine Fahrzeuge anbieten und den potentiellen Kunden eben nicht auf den großen Marktplatz locken, auf dem auch der Nachbarhändler zwei Straßen weiter vertreten ist.
Ähnlich sieht es bei einem Reisebüro aus, welches verschiedene Reiseveranstalter im Angebot hat. Bei einem Enwilligungsbedürfnis kommt man dann auf die Seite und sieht nur noch “blockierte Scripte”. Da wird sich kaum ein Besucher die Mühe machen, auf den Button “externe Inhalte anzeigen” zu drücken, sondern im Browserverlauf direkt wieder eine Seite zurück zur Suchmaschine zu gehen und ein anderes Reisebüro aufzurufen.

Ich würde jetzt im Entwicklerforum dazu tendieren, externe Inhalte generell zu blocken mit der Option, dass für den Webdesigner ein Schalter für “berechtigtes Interesse” vorhanden ist. Damit könnte der Webdesigner, der ja nur den Auftrag des Seiteninhabers ausführt, auf Wunsch des Kunden die externen Inhalte weiterhin anzeigen. Wie viele Kunden dann allerdings auf eine andere Software springen, die weniger datenschutzaffin ist, bliebe abzuwarten.
Da die Software weltweit genutzt werden kann, wäre eine generelle Blockade für Kunden außerhalb der EU nicht vermittelbar. Die Software in zwei Varianten zu entwickeln (DSGVO / Drittland) würde die Entwicklungskosten in die Höhe treiben.

Das genügt dem Anspruch für externe Inhalte aus Drittstaaten nicht, da bei diesen kein berechtigtes Interesse geltend gemacht werden kann. Hier ist eine Einwilligung notwendig. Und da auch europäische Anbieter ihre Webseiten bei einem US-Unternehmen hosten können, benötigt es aus Sicht der Entwickler zwei Varianten: direkte Einbindung ohne Einschränkung und Einbindung mit einem vorgeschaltetem “Externen Inhalt anzeigen”, der bei deaktiviertem Javascript und/oder iframe den Link anzeigt, und damit in jedem Fall eine zustimmende Aktion des Besuchers erfordert.

Von datenschutzaffin kann man hier nicht mehr sprechen. Denn die Anzeige der Weitervermittlung wird gesetzlich gefordert und die Gerichte haben bereits gegen eine Übermittlung ohne Einwilligung entschieden. Das Thema wird künftig vermutlich mehr Aufmerksamkeit erfahren. Ein CMS, das dann den Anspruch von Privacy by Design erfüllt, kann nur punkten.

1 „Gefällt mir“

Naja, im Cookie-Tool wird man das eigentlich nicht erwarten …

Bin kein Web-Mensch, aber mir schwebt etwas vor wie bei https://stadt.muenchen.de/infos/corona-fallzahlen-muenchen

Soweit ich es verstehe, wird bei “Grafik anzeigen” lediglich die Seite neu geschrieben, aber diesmal mit (allen) Frames anstatt dem opt-in an der Stelle (die Info zur Einwilligung auf der Seite dazu ist natürlich für die Füße …).

Ein Entwickler bzw. ein CMS sollte sowas hinbekommen, ohne 2 Varianten zu pflegen.

Als Update: Im Ergebnis der Diskussion hier wird in der aktuellen Version der Software folgende Standardlösung umgesetzt:
IFrames mit externen Inhalten werden blockiert und erst nach Klick durch den User freigeschalten. Sofern die Seite mit Google-Webfonts erstellt wurde, erfolgt die Darstellung zunächst mit Rückfallfonts, der Besucher erhält den Hinweis, dass Schriftarten blockiert wurden und kann diese ebenfalls per Klick nachladen.

Kann man dem Kunden anbieten, die Webfonts lokal einzubinden? Wenn er sie lokal nutzen will, werden sie per Mausklick heruntergeladen und in einem Fontverzeichnis abgelegt. Die Software prüft das Vorhandensein lokaler Schriften und erstellt das entsprechende Font-CSS oder ergänzt das vorhandene CSS. Das würde Rückfallfonts samt Darstellungsfehler vermeiden und den Klick samt Laden externer Fonts überflüssig machen.

@anzolino : Die Webfonts können auch selbst gehostet werden. Im Handbuch gibt es dazu eine Schritt-für-Schritt-Anleitung.