Drittanbieter

Was ist ein Drittanbieter?

Es kommt eher selten vor, dass eine Website völlig eigenständig ist. Der HTTP Web Almanac zeigt, dass die meisten Websites – etwa 95 % – Inhalte von Drittanbietern enthalten.

Der Almanac definiert Drittanbieterinhalte als Inhalte, die von einem gemeinsamen und öffentlichen Ursprung gehostet werden, der von einer Vielzahl von Websites weit verbreitet und nicht von einem einzelnen Websiteinhaber beeinflusst wird. Dabei kann es sich um Bilder oder andere Medien wie Videos, Schriftarten oder Skripts handeln. Bilder und Skripts decken mehr als alles andere zusammen. Inhalte von Drittanbietern sind für die Entwicklung einer Website nicht unbedingt notwendig, können es aber auch sein. Sie werden mit hoher Wahrscheinlichkeit etwas verwenden, das von einem öffentlichen, gemeinsam genutzten Server geladen wird. Dabei kann es sich um Webschriftarten, eingebettete iFrames von Videos, Anzeigen oder JavaScript-Bibliotheken handeln. Sie können beispielsweise Webschriftarten verwenden, die von Google Fonts bereitgestellt werden, oder Analysen mit Google Analytics analysieren. Möglicherweise haben Sie „Mag ich“-Schaltflächen oder „Anmelden mit“-Schaltflächen aus sozialen Netzwerken hinzugefügt. Sie können Karten oder Videos einbetten oder Shopping-Käufe über Drittanbieterdienste abwickeln. Möglicherweise verfolgen Sie Fehler und protokollieren Protokollierung für Ihre eigenen Entwicklungsteams mithilfe von Überwachungstools von Drittanbietern.

Aus Datenschutzgründen ist es sinnvoll, eine etwas andere und weniger breit gefasste Definition in Betracht zu ziehen: Eine Ressource eines Drittanbieters und insbesondere ein Skript eines Drittanbieters wird von einem gemeinsamen und öffentlichen Ursprung bereitgestellt und wie illustriert häufig verwendet, aber auch von einem anderen Autor als dem Inhaber der Website verfasst. Der Aspekt der Drittanbieter-Urheberschaft ist entscheidend, wenn es darum geht, wie Sie die Privatsphäre Ihrer Nutzer vor Dritten schützen können. Dies führt Sie dazu, dass Sie überlegen, welche Risiken bestehen, und dann entscheiden, wie oder ob Sie basierend auf diesen Risiken eine Drittanbieter-Ressource verwenden. Wie bereits erwähnt, helfen Ihnen diese Punkte dabei, den Kontext zu verstehen und somit zu verstehen, welche Kompromisse Sie eingehen müssen und was sie bedeuten.

Das ist nicht ganz das, was bei der Erläuterung von „Ressourcen von Drittanbietern“ im Allgemeinen gemeint ist: Der Unterschied zwischen eigenen und Drittanbietern bezieht sich tatsächlich auf den Kontext, in dem etwas verwendet wird. Ein Skript, das von einer anderen Website geladen wird, ist eine Drittanbieterressource. Die HTTP-Anfrage, über die das Skript geladen wird, kann Cookies enthalten. Diese sind jedoch keine sogenannten Drittanbieter-Cookies, sondern nur Cookies. Es hängt davon ab, ob das Skript auf einer Seite Ihrer Website oder auf einer Seite der Website des Skriptinhabers geladen wird.

Warum verwenden wir Ressourcen von Drittanbietern?

Drittanbieter sind eine gute Möglichkeit, um Ihrer Website Funktionen hinzuzufügen. Dabei kann es sich um Funktionen handeln, die Nutzern zugänglich gemacht werden, oder unsichtbare Entwicklerfunktionen wie die Fehlerverfolgung, die jedoch Ihre Entwicklungslast reduzieren. Die Skripts selbst werden jedoch von jemand anderem verwaltet: dem Entwicklungsteam des von Ihnen eingebundenen Dienstes. Das alles funktioniert aufgrund der Zusammensetzbarkeit des Webs: Teile zusammenfügen können, um ein Ganzes zu bilden, das größer ist als seine Summe.

Der Web Almanac des HTTP-Archivs bietet eine gute Beschreibung:

Drittanbieter stellen eine unendliche Sammlung von Bildern, Videos, Schriftarten, Tools, Bibliotheken, Widgets, Trackern, Anzeigen und allem anderen bereit, das Sie in unsere Webseiten einbetten können. So können auch Nutzer mit wenig technischem Hintergrund Inhalte erstellen und im Web veröffentlichen. Ohne Drittanbieter wäre das Web wahrscheinlich ein langweiliges, textbasiertes, akademisches Medium anstelle der umfangreichen, immersiven und komplexen Plattform, die für viele von uns heutzutage so wichtig ist.

Was können Ressourcen von Drittanbietern tun?

Zugriff auf bestimmte Informationen

Wenn Sie auf Ihrer Website die Ressource eines Drittanbieters verwenden, werden einige Informationen an diesen Drittanbieter weitergegeben. Wenn du beispielsweise ein Bild von einer anderen Website einfügst, übergibt die HTTP-Anfrage des Browsers des Nutzers einen Verweis-Header mit der URL deiner Seite und der IP-Adresse des Nutzers.

Websiteübergreifendes Tracking

Bleiben wir bei demselben Beispiel: Wenn das Bild von der Website des Drittanbieters geladen wird, kann es ein Cookie enthalten. Dieses Cookie wird an den Drittanbieter zurückgesendet, wenn der Nutzer das Bild das nächste Mal anfordert. Das bedeutet, dass der Drittanbieter weiß, dass sein Dienst auf Ihrer Website verwendet wird, und ein Cookie zurücksenden kann, möglicherweise mit einer eindeutigen ID für diesen Nutzer. Das bedeutet, dass das eindeutige ID-Cookie noch einmal gesendet wird, wenn der Nutzer das nächste Mal Ihre Website oder eine andere Website besucht, die eine Ressource dieses Drittanbieters enthält. Dadurch kann der Drittanbieter ein Protokoll anlegen, wo der Nutzer die Website besucht: deine Website, andere Websites, die dieselbe Drittanbieterressource verwenden, im gesamten Web.

Dies ist websiteübergreifendes Tracking: Drittanbieter können ein Protokoll der Aktivitäten eines Nutzers auf vielen Websites erfassen, sofern diese Websites alle eine Ressource desselben Drittanbieters verwenden. Das kann eine Schriftart, ein Bild oder ein Stylesheet sein – allesamt statische Ressourcen. Es kann sich auch um eine dynamische Ressource handeln: ein Skript, eine Schaltfläche für soziale Medien, eine Anzeige. Das enthaltene Skript kann noch mehr Informationen erfassen, da es dynamisch ist: Es kann den Browser und die Umgebung des Nutzers überprüfen und die Daten an den Urheber zurückgeben. In gewissem Umfang ist dies mit jedem Skript möglich, ebenso bei dynamischen Ressourcen, die nicht als Skript angezeigt werden, z. B. einer Einbettung in sozialen Medien, einer Anzeige oder einer Schaltfläche zum Teilen. Wenn Sie sich die Details eines Cookie-Banners auf beliebten Websites ansehen, sehen Sie eine Liste der Organisationen, die Ihren Nutzern ein Tracking-Cookie hinzufügen können, um sich ein Bild ihrer Aktivitäten zu machen und ein Profil dieses Nutzers zu erstellen. Es kann Hunderte von ihnen geben. Wenn ein Drittanbieter einen Dienst kostenlos anbietet, kann dies für ihn wirtschaftlich rentabel sein, weil er diese Daten erfasst und dann monetarisiert.

Ein nützlicher Leitfaden zu den Arten von Datenschutzproblemen, vor denen ein Browser seine Nutzer schützen sollte, ist das Target Privacy Threat Model. Dieses Dokument wird zum Zeitpunkt der Erstellung dieses Dokuments noch diskutiert, enthält jedoch einige allgemeine Klassifizierungen der Arten von Datenschutzbedrohungen, die es gibt. Die Risiken durch Drittanbieterressourcen bestehen in erster Linie aus der "unerwünschten websiteübergreifenden Erkennung", bei der eine Website denselben Nutzer über mehrere Websites hinweg identifizieren kann, und in der "Offenlegung vertraulicher Informationen", bei der eine Website Informationen erfassen kann, die ein Nutzer als sensibel einstuft.

Dies ist eine wichtige Unterscheidung: Unerwünschte websiteübergreifende Erkennung ist auch dann schlecht, wenn der Drittanbieter keine zusätzlichen vertraulichen Informationen daraus sammelt, da der Nutzer die Kontrolle über seine Identität verliert. Der Zugriff auf die Referrer-URL, die IP-Adresse und die Cookies eines Nutzers ist bereits eine unerwünschte Offenlegung. Die Verwendung von Ressourcen von Drittanbietern erfordert eine Planungskomponente für deren datenschutzfreundliche Nutzung. Einige dieser Aufgaben sind für Sie als Website-Entwickler zu tun, während andere vom Browser in seiner Rolle als User-Agent erledigt werden. Das heißt, der Agent arbeitet im Auftrag des Nutzers, um die Offenlegung vertraulicher Informationen und unerwünschte websiteübergreifende Erkennung zu vermeiden. Im Folgenden werden wir uns genauer auf Maßnahmen und Ansätze auf Browser- und Websiteentwicklungsebene eingehend eingehen.

Serverseitiger Drittanbietercode

In unserer früheren Definition eines Dritten wurde der eher clientseitige Ansatz von HTTP Almanac (wie für den Bericht angemessen) so geändert, dass die Urheberschaft durch Dritte einbezogen wird, da aus Datenschutzperspektive jeder Dritte ist, der etwas über Ihre Nutzer weiß, und nicht Sie.

Dies gilt auch für Drittanbieter, die Dienste anbieten, die Sie auf dem Server nutzen, sowie auf dem Client. Aus Datenschutzgründen ist es auch wichtig, die Bibliothek eines Drittanbieters, z. B. von NPM, Composer oder NuGet, zu verstehen. Übergeben Ihre Abhängigkeiten Daten außerhalb Ihrer Grenzen? Wenn Sie Daten an einen Logging-Dienst oder eine extern gehostete Datenbank übergeben und Bibliotheken für ihre Autoren auch „Phone home“ enthalten, können diese den Datenschutz Ihrer Nutzer verletzen und müssen geprüft werden. In der Regel müssen Sie die Nutzerdaten an einen serverbasierten Drittanbieter aushändigen. Das bedeutet, dass Sie mehr Kontrolle über die Daten haben, denen er ausgesetzt ist. Im Gegensatz dazu kann ein clientseitiger Drittanbieter – ein auf Ihrer Website enthaltenes und vom Browser des Nutzers abgerufenes Skript oder eine HTTP-Ressource – einige Daten direkt vom Nutzer erfassen, ohne dass dieser Erfassungsprozess von Ihnen vermittelt wird. In diesem Modul geht es größtenteils darum, wie Sie die clientseitigen Drittanbieter identifizieren, die Sie für Ihre Nutzer einbeziehen und mit denen Sie Kontakt aufnehmen möchten, genau weil Sie weniger Vermittlung haben. Es lohnt sich jedoch, Ihren serverseitigen Code so zu sichern, dass Sie die ausgehende Kommunikation davon verstehen und unerwartete Ereignisse protokollieren oder blockieren können. Wie genau dies genau funktioniert, liegen an dieser Stelle nicht in unserem Verantwortungsbereich (und hängt stark von Ihrer Servereinrichtung ab). Dies ist jedoch ein weiterer Teil Ihrer Sicherheits- und Datenschutzstrategie.

Warum muss man bei Drittanbietern vorsichtig sein?

Skripts und Funktionen von Drittanbietern sind sehr wichtig und unser Ziel als Webentwickler sollte es sein, solche Dinge zu integrieren, anstatt sie abzuwenden. Aber es gibt auch potenzielle Probleme. Inhalte von Drittanbietern können zu Leistungsproblemen und Sicherheitsproblemen führen, da Sie einen externen Dienst innerhalb Ihrer Vertrauensgrenze einbinden. Aber auch Inhalte von Dritten können zu Datenschutzproblemen führen.

Wenn wir über Ressourcen von Drittanbietern im Internet sprechen, ist es unter anderem hilfreich, sich bei Sicherheitsproblemen vorzustellen, bei denen ein Drittanbieter Daten Ihres Unternehmens stehlen kann, und diese mit Datenschutzproblemen zu vergleichen, bei denen unter anderem ein von Ihnen eingeschlossener Drittanbieter die Daten Ihrer Nutzer stiehlt oder Zugriff auf die Daten Ihrer Nutzer erlangt, ohne dass Sie (oder sie) zustimmen.

Ein Beispiel für ein Sicherheitsproblem ist, dass "Web-Skimmer" Kreditkartendaten stehlen. Eine Drittanbieterressource, die auf einer Seite enthalten ist, in die ein Nutzer Kreditkartendaten eingibt, können diese Kreditkartendaten möglicherweise stehlen und an den böswilligen Dritten senden. Diejenigen, die diese Skimmer-Skripte erstellen, sind sehr kreativ und versuchen, sie zu verstecken. Eine Zusammenfassung beschreibt, wie Skiimmer-Skripts in Inhalten von Drittanbietern verborgen wurden, z. B. in Bildern, die für Websitelogos, Favicons und soziale Netzwerke verwendet werden, beliebte Bibliotheken wie jQuery, Modernizr und Google Tag Manager, Website-Widgets wie Live-Chat-Fenster und CSS-Dateien.

Datenschutzprobleme sind ein wenig anders. Diese Drittanbieter sind Teil Ihres Angebots. Um das Vertrauen Ihrer Nutzer in Sie aufrechtzuerhalten, müssen Sie darauf vertrauen können, dass Ihre Nutzer Ihnen vertrauen können. Wenn ein von Ihnen verwendeter Drittanbieter Daten über Ihre Nutzer erfasst und sie dann missbraucht, das Löschen oder Auffinden erschwert, eine Datenpanne auftritt oder die Erwartungen Ihrer Nutzer verletzt werden, werden Ihre Nutzer dies wahrscheinlich als ein Zusammenbruch des Vertrauens in Ihren Dienst und nicht nur in Bezug auf den Drittanbieter empfinden. Es geht um deinen Ruf und deine Beziehung. Daher sollten Sie sich die folgende Frage stellen: Vertrauen Sie den Drittanbietern, die Sie auf Ihrer Website nutzen?

Was sind Beispiele für Drittanbieter?

Wir sprechen im Allgemeinen über Drittanbieter, aber es gibt tatsächlich verschiedene Arten und diese haben Zugriff auf unterschiedliche Mengen an Nutzerdaten. Wenn Sie dem HTML-Code beispielsweise ein <img>-Element hinzufügen, das von einem anderen Server geladen wird, erhält dieser Server andere Informationen über Ihre Nutzer als das Hinzufügen eines <iframe>- oder <script>-Elements. Dies sind Beispiele und keine umfassende Liste. Es ist aber hilfreich, die Unterschiede zwischen den verschiedenen Arten von Drittanbieterelementen zu verstehen, die auf deiner Website verwendet werden können.

Websiteübergreifende Ressource anfordern

Eine websiteübergreifende Ressource ist alles auf deiner Website, das von einer anderen Website geladen wird und kein <iframe> oder <script> ist. Beispiele hierfür sind <img>, <audio>, <video>, von CSS geladene Webschriftarten und WebGL-Texturen. Sie werden alle über eine HTTP-Anfrage geladen. Wie oben beschrieben, enthalten diese HTTP-Anfragen alle zuvor von der anderen Website gesetzten Cookies, die IP-Adresse des anfragenden Nutzers und die URL der aktuellen Seite als Referrer-URL. Alle Anfragen von Drittanbietern enthielten diese Daten standardmäßig standardmäßig. Es gibt jedoch Maßnahmen, um die von verschiedenen Browsern an Dritte übermittelten Daten zu reduzieren oder zu isolieren, wie im Abschnitt „Informationen zum Browserschutz von Drittanbietern“ weiter unten beschrieben.

Websiteübergreifenden iFrame einbetten

Ein vollständiges Dokument, das über eine <iframe> in deine Seiten eingebettet wird, kann neben der Reihe von Cookies, IP-Adresse und Referrer-URL zusätzlichen Zugriff auf Browser-APIs anfordern. Welche APIs genau für <iframe>d Seiten verfügbar sind und wie sie den Zugriff anfordern, ist browserspezifisch und wird derzeit geändert. Informationen zu aktuellen Maßnahmen zur Einschränkung oder Überwachung des API-Zugriffs in eingebetteten Dokumenten finden Sie unten in der „Berechtigungsrichtlinie“.

Ausführen von websiteübergreifendem JavaScript

Wenn Sie ein <script>-Element einfügen, wird websiteübergreifender JavaScript-Code im Kontext der obersten Ebene Ihrer Seite geladen und ausgeführt. Das bedeutet, dass das ausgeführte Skript uneingeschränkten Zugriff auf alle Ihre eigenen Skripts hat. Diese Daten werden weiterhin durch Browserberechtigungen verwaltet, sodass zum Beispiel die Abfrage des Nutzerstandorts weiterhin die Nutzereinwilligung erfordert. Allerdings können alle Informationen, die auf der Seite vorhanden sind oder als JavaScript-Variablen verfügbar sind, von einem solchen Skript gelesen werden. Dies umfasst nicht nur Cookies, die im Rahmen der Anfrage an den Drittanbieter übergeben werden, sondern auch Cookies, die nur für Ihre Website bestimmt sind. Entsprechend kann ein Drittanbieterskript, das auf Ihre Seite geladen wird, dieselben HTTP-Anfragen stellen wie Ihr eigener Code. Es könnte also fetch()-Anfragen an Ihre Back-End-APIs senden, um Daten abzurufen.

Bibliotheken von Drittanbietern in Abhängigkeiten einbinden

Wie bereits erwähnt, enthält Ihr serverseitiger Code wahrscheinlich auch Abhängigkeiten von Drittanbietern, die sich in ihrer Macht nicht von Ihrem eigenen Code unterscheiden. Code, den Sie aus einem GitHub-Repository oder der Bibliothek Ihrer Programmiersprache (npm, PyPI, Composer usw.) einbinden, kann dieselben Daten lesen wie Ihr anderer Code.

Informationen zu Drittanbietern

Dazu müssen Sie Ihre Liste der Drittanbieter und deren Haltungen und Richtlinien in Bezug auf Datenschutz, Datenerhebung und Nutzererfahrung kennen. Dieses Verständnis wird dann Teil Ihrer Reihe von Kompromissen: wie nützlich und wichtig der Dienst ist und wie aufdringlich, umständlich oder beunruhigend deren Anforderungen für Ihre Nutzer sind. Inhalte von Drittanbietern bieten einen Mehrwert, da sie Ihnen als Websiteinhaber viel Arbeit abnehmen und Ihnen die Möglichkeit geben, sich auf Ihre Kernkompetenzen zu konzentrieren. Diese Abwägung ist also sinnvoll, wenn Sie für eine bessere Nutzererfahrung Abstriche bei Komfort und Datenschutz machen müssen. Es ist jedoch wichtig, die Nutzererfahrung nicht mit der Entwicklererfahrung zu verwechseln: „Für unser Entwicklungsteam ist es einfacher, den Dienst zu erstellen“. Das ist für Nutzer keine überzeugende Story.

Wie Sie dieses Verständnis erlangen, ist der Audit-Prozess.

Drittanbieter prüfen

Mit dem Audit-Prozess können Sie nachvollziehen, was Dritte tun. Sie können dies sowohl technisch als auch nicht-technisch sowie für einen einzelnen Drittanbieter und für Ihre gesamte Sammlung tun.

Nicht-technische Prüfung durchführen

Der erste Schritt ist nicht technisch: Lesen Sie die Datenschutzerklärungen Ihrer Lieferanten. Wenn Sie Ressourcen von Drittanbietern verwenden, prüfen Sie die Datenschutzrichtlinien. Sie werden lang und voller rechtlicher Texte sein und in einigen Dokumenten werden möglicherweise einige der Ansätze verwendet, gegen die in früheren Modulen gewarnt wurde, z. B. zu allgemeine Aussagen und ohne Angabe, wie oder wann erfasste Daten entfernt werden. Aus Nutzersicht unterliegen alle Daten, die auf Ihrer Website (auch von Drittanbietern) erhoben werden, den vorliegenden Datenschutzerklärungen. Selbst wenn Sie alles richtig machen, können Nutzer, wenn Sie in Bezug auf Ihre Ziele transparent sind und die Erwartungen der Nutzer in Bezug auf Datenschutz und Sensibilität übertreffen, Sie möglicherweise auch für alles verantwortlich machen, was Ihre ausgewählten Drittanbieter tun. Wenn die Datenschutzerklärung etwas enthält, das Sie nicht in Ihren eigenen Richtlinien angeben möchten, weil dies das Vertrauen der Nutzer verringern würde, sollten Sie überlegen, ob es einen alternativen Anbieter gibt.

Dies kann nützlich zusammen mit dem weiter unten besprochenen technischen Audit sein und sich gegenseitig informieren. Sie sollten die Ressourcen von Drittanbietern kennen, die Sie aus geschäftlichen Gründen einbinden (z. B. Werbenetzwerke oder eingebettete Inhalte), da eine Geschäftsbeziehung besteht. Dies ist ein guter Ausgangspunkt für eine nichttechnische Prüfung. Außerdem werden bei der technischen Prüfung wahrscheinlich Dritte identifiziert, insbesondere solche, die eher aus technischen als auch aus geschäftlichen Gründen genannt werden (externe Komponenten, Analysen, Dienstprogrammbibliotheken). Diese Liste kann mit der Liste geschäftsorientierter Drittanbieter zusammengeführt werden. Ziel ist es, dass Sie als Websiteinhaber wissen, was die Drittanbieter tun, die Sie Ihrer Website hinzufügen, und dass Sie als Unternehmen Ihrem Rechtsberater eine Liste dieser Drittanbieter zur Verfügung stellen können, um sicherzustellen, dass Sie alle Verpflichtungen erfüllen.

Technische Prüfung durchführen

Bei einem technischen Audit ist es wichtig, die Ressourcen vor Ort als Teil der Website zu verwenden. Das heißt, eine Abhängigkeit nicht in einen Test-Harnisch zu laden und auf diese Weise zu überprüfen. Achten Sie darauf, dass Sie sehen, wie sich Ihre Abhängigkeiten als Teil Ihrer tatsächlichen Website verhalten, die im öffentlichen Internet bereitgestellt wird und nicht im Test- oder Entwicklungsmodus. Es ist sehr aufschlussreich, die eigene Website als neue Nutzende zu betrachten. Öffnen Sie einen Browser in einem neuen, sauberen Profil, damit Sie nicht angemeldet sind und keine Vereinbarung gespeichert haben, und versuchen Sie, Ihre Website aufzurufen.

Melden Sie sich auf Ihrer eigenen Website für ein neues Konto an, wenn Sie Nutzerkonten angeben. Ihr Designteam wird diesen neuen Prozess der Nutzergewinnung aus UX-Perspektive orchestrieren, aber es kann illustrierend sein, ihn aus Datenschutzperspektive zu betrachten. Klicken Sie nicht einfach in den Nutzungsbedingungen, in der Cookie-Warnung oder in der Datenschutzerklärung auf "Akzeptieren". Entscheiden Sie sich selbst, Ihren eigenen Dienst zu nutzen, ohne dabei personenbezogene Daten offenzulegen oder Tracking-Cookies zu verwenden, und prüfen Sie, ob Sie dies tun können und wie schwierig es ist, dies zu tun. Es kann auch hilfreich sein, in den Entwicklertools des Browsers nachzusehen, auf welche Websites zugegriffen wird und welche Daten an diese Websites übergeben werden. Die Entwicklertools stellen eine Liste separater HTTP-Anfragen bereit, die sich normalerweise im Bereich „Netzwerk“ befinden. Hier sehen Sie Anfragen, die nach Typ gruppiert sind (HTML, CSS, Bilder, Schriftarten, JavaScript, von JavaScript initiierte Anfragen). Es ist auch möglich, eine neue Spalte hinzuzufügen, in der die Domain der einzelnen Anfragen angezeigt wird. So lässt sich nachvollziehen, wie viele verschiedene Orte kontaktiert werden. Unter Umständen gibt es auch ein Kästchen für „Drittanbieter-Anfragen“, mit dem nur Drittanbieter angezeigt werden. (Es kann auch nützlich sein, die Content-Security-Policy-Berichterstellung zu verwenden, um ein kontinuierliches Audit durchzuführen, für das weiter unten beschrieben wird.)

Das Tool Request Map Generator von Simon Hearne kann ebenfalls eine hilfreiche Übersicht über alle Unteranfragen bieten, die von einer öffentlich verfügbaren Seite gestellt werden.

An dieser Stelle können Sie auch die geschäftsorientierten Drittanbieter einbeziehen, die im Rahmen des nichttechnischen Audits identifiziert wurden (d. h. die Liste der Unternehmen, mit denen Sie eine finanzielle Beziehung haben, um ihre Ressourcen zu nutzen). Ziel ist es, die Liste der Drittanbieter, die du deiner Meinung nach verwendest (aus Finanz- und Rechtsunterlagen), mit der Liste abzugleichen, die du tatsächlich verwendest (an dem du prüfst, welche HTTP-Anfragen von Drittanbietern von deiner Website gestellt werden). Sie sollten für jeden geschäftlichen Drittanbieter erkennen können, welche technischen ausgehenden Anfragen gestellt werden. Wenn Sie bei der technischen Prüfung für einen Drittanbieter, der anhand einer Geschäftsbeziehung identifiziert wurde, keine Anfragen finden können, ist es wichtig, den Grund dafür herauszufinden und sich bei Ihren Tests anleiten zu lassen. Vielleicht wird die Ressource des Drittanbieters nur in einem bestimmten Land, auf einem bestimmten Gerätetyp oder für angemeldete Nutzer geladen. Dadurch wird die Liste der zu prüfenden Websitebereiche erweitert und es wird sichergestellt, dass Sie alle ausgehenden Zugriffe sehen. Vielleicht wird auch eine Ressource eines Drittanbieters identifiziert, für die Sie bezahlen und die Sie nicht verwenden, was die Finanzabteilung immer aufheitert.

Nachdem Sie die Liste der Anfragen an Dritte, die an dem Audit teilnehmen möchten, eingegrenzt haben, können Sie auf eine einzelne Anfrage klicken, um alle Details zu sehen und insbesondere zu erfahren, welche Daten an diese Anfrage übergeben wurden. Es kommt auch häufig vor, dass eine von Ihrem Code initiierte Anfrage eines Drittanbieters viele andere Anfragen von Drittanbietern initiiert. Diese zusätzlichen Drittanbieter werden ebenfalls in Ihre Datenschutzbestimmungen "importiert". Diese Aufgabe ist mühsam, aber wertvoll und kann oft in vorhandene Analysen eingefügt werden. Ihr Front-End-Entwicklungsteam sollte bereits Anfragen aus Leistungsgründen prüfen (vielleicht mithilfe vorhandener Tools wie WebPageTest oder Lighthouse). Die Einbindung einer Daten- und Datenschutzprüfung in diesen Prozess kann dies vereinfachen.

Die web.dev-Anfragezuordnung
Eine (dramatisch vereinfachte) Anfragezuordnung für web.dev mit Websites von Drittanbietern, die Websites von Drittanbietern anfordern usw.

Das sollten Sie tun:

Öffnen Sie einen Browser mit einem sauberen neuen Nutzerprofil, damit Sie nicht angemeldet sind und keine gespeicherte Vereinbarung haben. Öffnen Sie dann den Netzwerkbereich der Browser-Entwicklertools, um alle ausgehenden Anfragen zu sehen. Fügen Sie eine neue Spalte hinzu, um die Domain jeder Anfrage anzuzeigen, und klicken Sie das Kästchen „Drittanbieter-Anfragen“ an, damit nur Drittanbieter angezeigt werden, sofern vorhanden. Dann:

  • Rufen Sie Ihre Website auf.
  • Registrieren Sie sich für ein neues Konto, wenn Sie Nutzerkonten angeben.
  • Versuchen Sie, Ihr erstelltes Konto zu löschen.
  • Führen Sie ein oder zwei normale Aktionen auf der Website aus. Die genaue Vorgehensweise hängt davon ab, was Ihre Website tut. Wählen Sie jedoch die Aktionen aus, die die meisten Nutzer ausführen.
  • Führen Sie eine oder zwei Aktionen aus, von denen Sie wissen, dass sie insbesondere Abhängigkeiten von Drittanbietern beinhalten. Dazu gehören das Teilen von Inhalten in sozialen Medien, das Starten eines Bezahlvorgangs oder das Einbetten von Inhalten von einer anderen Website.

Notieren Sie sich bei jeder dieser Aufgaben die Ressourcen, die von fremden Domains angefordert werden. Sehen Sie sich dazu wie beschrieben das Steuerfeld „Netzwerk“ an. Dies sind einige Ihrer Drittanbieter. Eine gute Möglichkeit ist, die Netzwerkanfragelogs mit den Netzwerktools des Browsers in einer HAR-Datei zu erfassen.

HAR-Dateien und Datenerfassung

Eine HAR-Datei ist ein standardisiertes JSON-Format aller Netzwerkanfragen, die von einer Seite gestellt werden. So rufen Sie eine HAR-Datei für eine bestimmte Seite auf:

Chrome

Öffnen Sie die Entwicklertools des Browsers (Menü > Weitere Tools > Entwicklertools), gehen Sie zum Steuerfeld „Netzwerk“, laden (oder aktualisieren) Sie die Seite und wählen Sie den Abwärtspfeil oben rechts neben dem Drop-down-Menü „Keine Drosselung“ aus.

Im Bereich „Netzwerk“ der Chrome-Entwicklertools ist das HAR-Symbol für den Download markiert.
Firefox

Öffnen Sie die Entwicklertools des Browsers (Menü > Weitere Tools > Web-Entwicklertools), rufen Sie das Steuerfeld „Netzwerk“ auf, laden (oder aktualisieren) Sie die Seite und wählen Sie das Zahnradsymbol rechts oben neben dem Drop-down-Menü für die Drosselung aus. Wählen Sie im Menü die Option Alle als HAR speichern** aus.

Im Bereich „Netzwerk“ der Firefox-Entwicklertools ist die Option „Alle speichern unter“ markiert.
Safari

Öffnen Sie die Entwicklertools des Browsers (Menü > Entwickeln > Web Inspector anzeigen. Falls das Menü „Entwickler“ nicht verfügbar ist, aktivieren Sie es in der Menüleiste unter Menü > Safari > Einstellungen > Erweitert > Menü „Entwickeln“. Wechseln Sie dann zum Steuerfeld „Netzwerk“, laden bzw. aktualisieren Sie die Seite und wählen Sie rechts oben neben „Log beibehalten“ die Option Exportieren aus.

Im Bereich „Network“ (Netzwerk) von Safari Web Inspector ist die Option „HAR-Export“ markiert.

Für weitere Details können Sie im Abschnitt „Anfrage“ auch aufzeichnen, was an Dritte weitergegeben wird. Diese Daten sind jedoch oft verschleiert und nicht sinnvoll interpretierbar.

Best Practices für die Integration von Drittanbietern

Sie können eigene Richtlinien für Drittanbieter festlegen, die auf Ihrer Website verwendet werden: Ändern Sie je nach Praktiken, welchen Anzeigenanbieter Sie verwenden, wie lästig oder störend das Pop-up zur Einholung von Cookies ist oder ob Sie Schaltflächen für soziale Medien auf Ihrer Website verwenden oder Links in Ihren E-Mails oder utm_campaign-Links erfassen möchten, die in Google Analytics in Ihren Tweets erfasst werden sollen. Ein Aspekt, den Sie bei der Entwicklung einer Website berücksichtigen sollten, ist der Datenschutz- und Sicherheitsstatus Ihres Analysedienstes. Bei einigen Analysediensten handelt es explizit um Datenschutz. Häufig gibt es auch Möglichkeiten, ein Drittanbieterskript zu verwenden, das zusätzlichen Datenschutz bietet: Sie sind nicht das erste Team, das den Datenschutz für Nutzer verbessern und sie vor der Datenerhebung durch Drittanbieter schützen möchte, und vielleicht gibt es bereits Lösungen. Außerdem reagieren viele Drittanbieter heute empfindlicher auf Probleme bei der Datenerhebung als in der Vergangenheit. Außerdem gibt es oft Funktionen oder Parameter, die Sie hinzufügen können, um den Schutz der Nutzer zu verbessern. Hier einige Beispiele:

Beim Hinzufügen einer Schaltfläche zum Teilen in sozialen Medien

Wir empfehlen, HTML-Schaltflächen direkt einzubetten. Auf der Website https://sharingbuttons.io/ finden Sie einige gut gestaltete Beispiele. Sie können auch einfache HTML-Links hinzufügen. Der Nachteil ist, dass Sie die Statistik „Anzahl der geteilten Inhalte“ verlieren und Ihre Kunden in Ihren Facebook-Analysen klassifizieren können. Dies ist ein Beispiel für einen Kompromiss zwischen der Nutzung eines Drittanbieters und dem Erhalt von weniger Analysedaten.

Allgemein gilt: Wenn Sie ein interaktives Widget irgendeiner Art von einem Drittanbieter einbetten, ist es oft möglich, stattdessen einen Link zu diesem Drittanbieter bereitzustellen. Das bedeutet, dass auf Ihrer Website keine Inline-Funktionalität verfügbar ist. Die Entscheidung über die Weitergabe von Daten an den Drittanbieter wird jedoch von Ihnen auf den Nutzer übertragen, der nach eigenem Ermessen interagieren kann oder nicht.

Sie könnten zum Beispiel Links für Twitter und Facebook hinzufügen, um Ihren Dienst wie folgt unter mysite.example.com zu teilen:

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

Beachten Sie, dass Facebook die Angabe einer URL zum Teilen erlaubt und Twitter die Angabe einer URL und eines Textes.

Beim Einbetten eines Videos

Wenn du Videos von Websites, auf denen Videos gehostet werden, einbettest, solltest du im Einbettungscode nach datenschutzfreundlichen Optionen suchen. Ersetzen Sie für YouTube beispielsweise youtube.com in der Einbettungs-URL durch www.youtube-nocookie.com, um zu verhindern, dass Tracking-Cookies auf der eingebetteten Seite platziert werden. Du kannst auch das Kontrollkästchen "Erweiterten Datenschutzmodus aktivieren" aktivieren, wenn du den Link zum Teilen/Einbetten direkt auf YouTube erstellst. Dies ist ein gutes Beispiel für die Verwendung eines nutzerschutzfreundlicheren Modus eines Drittanbieters. Weitere Informationen hierzu und weitere Einbettungsoptionen speziell für YouTube findest du unter https://support.google.com/youtube/answer/171780.

Bei anderen Videowebsites gibt es in dieser Hinsicht weniger Optionen: TikTok hat zum Zeitpunkt der Veröffentlichung dieses Artikels zum Beispiel keine Möglichkeit, Videos ohne Tracking einzubetten. Es ist zwar möglich, die Videos selbst zu hosten (hierbei handelt es sich um eine Alternative), aber es kann viel mehr Arbeit sein, vor allem, wenn viele Geräte unterstützt werden.

Wie bei den zuvor beschriebenen interaktiven Widgets ist es häufig möglich, ein eingebettetes Video durch einen Link zur entsprechenden Website zu ersetzen. Dies ist weniger interaktiv, da das Video nicht inline abgespielt wird. Es bleibt jedoch die Entscheidung, ob der Nutzer es sich gemeinsam ansehen möchte. Dies kann als Beispiel für das „Fassadenmuster“ verwendet werden, der Name zum dynamischen Ersetzen interaktiver Inhalte durch etwas, das eine Nutzeraktion zum Auslösen erfordert. Ein eingebettetes TikTok-Video kann durch einen einfachen Link zur TikTok-Videoseite ersetzt werden. Mit etwas mehr Aufwand ist es jedoch möglich, eine Miniaturansicht für das Video abzurufen und anzuzeigen und zu einem Link zu machen. Auch wenn der ausgewählte Videoanbieter keine einfache Methode zum Einbetten von Videos ohne Tracking unterstützt, unterstützen viele Videohosts oEmbed. Dies ist eine API, die bei einem Link zu einem Video oder eingebetteten Inhalten programmatische Details wie eine Miniaturansicht und einen Titel zurückgibt. TikTok unterstützt oEmbed (weitere Informationen finden Sie unter https://developers.tiktok.com/doc/embed-videos). Das bedeutet, dass Sie einen Link zu einem TikTok-Video https://www.tiktok.com/@scout2015/video/6718335390845095173 mit https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173 in JSON-Metadaten zu diesem Video umwandeln und somit eine Miniaturansicht abrufen können (manuell oder programmatisch). WordPress verwendet dies häufig, um beispielsweise oEmbed-Informationen für eingebettete Inhalte anzufordern. Hiermit kannst du programmatisch eine „Fassade“ anzeigen, die interaktiv aussieht und die dazu wechselt, ein interaktives Video einzubetten oder zu verlinken, wenn der Nutzer darauf klickt.

Beim Einbetten von Analyseskripts

Mit Analytics sollen Daten zu Ihren Nutzern erfasst werden, damit sie analysiert werden können: Zu diesem Zweck ist es gedacht. Analysesysteme sind im Wesentlichen Dienste zum Erfassen und Anzeigen von Daten zu Zugriffen und Nutzern. Das erfolgt zur Vereinfachung der Implementierung auf einem Drittanbieterserver wie Google Analytics. Es gibt auch selbstgehostete Analysesysteme wie https://matomo.org/. Das ist allerdings aufwendiger, als hierfür eine Drittanbieterlösung zu verwenden. Wenn Sie ein solches System auf Ihrer eigenen Infrastruktur ausführen, können Sie jedoch die Datenerhebung reduzieren, da es Ihr eigenes System nicht verlässt. Andererseits liegt es in Ihrer Verantwortung, diese Daten zu verwalten, zu entfernen und Richtlinien dafür festzulegen. Ein großer Teil der Bedenken in Bezug auf websiteübergreifendes Tracking besteht darin, dass dies heimlich und heimlich geschieht oder als Nebeneffekt bei der Verwendung eines Dienstes, der keine Datenerfassung enthalten muss. Die Analysesoftware erhebt ausschließlich Daten, um Websiteinhaber über ihre Nutzer zu informieren.

In der Vergangenheit wurden alle verfügbaren Daten zu allen möglichen Themen gesammelt, z. B. zu einem riesigen Fischernetz, und diese später auf interessante Muster analysiert. Diese Denkweise hat zu einem großen Teil das Unbehagen und Unbehagen bezüglich der Datenerfassung hervorgerufen, auf die in Teil 1 dieses Kurses eingegangen wurde. Viele Websites überlegen zuerst, welche Fragen gestellt werden, und sammeln dann spezifische und begrenzte Daten, um diese Fragen zu beantworten.

Wenn ein Drittanbieterdienst von Ihrer Website und von anderen Websites verwendet wird, Sie dessen JavaScript-Code auf Ihrer Website einfügen und Cookies für jeden Nutzer setzen, sollten Sie bedenken, dass dieser Drittanbieter möglicherweise eine unerwünschte websiteübergreifende Erkennung durchführt, d. h. Ihre Nutzer websiteübergreifend erfasst. Einige können, andere nicht, aber die datenschutzkonforme Haltung besteht darin, davon auszugehen, dass ein solcher Drittanbieterdienst tatsächlich websiteübergreifendes Tracking durchführt, es sei denn, Sie haben einen guten Grund, etwas anderes zu denken oder zu wissen. Dies ist kein Grund, solche Dienste zu vermeiden, aber es ist etwas, das Sie bei der Beurteilung der Nachteile der Nutzung berücksichtigen sollten.

Früher galt bei Analysen der Kompromiss, ob sie genutzt werden sollen oder nicht: alle Daten zu erheben und im Austausch für Erkenntnisse und Planung alle Daten zu kompromittieren oder die Erkenntnisse ganz aufzugeben. Dies ist jedoch nicht mehr der Fall und es gibt oft bereits einen Mittelweg zwischen diesen beiden Extremen. Erkundigen Sie sich beim Analyseanbieter nach Konfigurationsoptionen, mit denen Sie die erfassten Daten begrenzen und die Speicherdauer und -dauer reduzieren können. Da Ihnen die Aufzeichnungen aus der zuvor beschriebenen technischen Prüfung vorliegen, können Sie die entsprechenden Abschnitte des Audits noch einmal ausführen, um zu bestätigen, dass durch eine Änderung dieser Konfigurationen die erfasste Datenmenge tatsächlich reduziert wird. Wenn du diese Umstellung auf einer bestehenden Website durchführst, erhältst du damit ein quantifizierbares Maß, das du für deine Nutzer aufschreiben kannst. In Google Analytics gibt es beispielsweise eine Reihe von Datenschutzfunktionen, die aktiviert werden müssen (und die daher standardmäßig deaktiviert sind), von denen viele zur Einhaltung lokaler Datenschutzgesetze hilfreich sein können. Bei der Einrichtung von Google Analytics sollten Sie z. B. die Aufbewahrungsdauer für erhobene Daten unter „Verwaltung“ > „Tracking-Informationen“ > „Datenaufbewahrung“ auf einen kürzeren Zeitraum als den Standardwert von 26 Monaten festlegen und technische Lösungen wie die teilweise Anonymisierung von IP-Adressen aktivieren. Weitere Informationen finden Sie unter https://support.google.com/analytics/answer/9019185.

Drittanbieter auf datenschutzfreundliche Weise verwenden

Bisher haben wir besprochen, wie Sie Ihre Nutzer in der Entwicklungsphase Ihrer Anwendung vor Dritten schützen können, während Sie planen, was diese Anwendung leisten soll. Die Entscheidung, einen bestimmten Drittanbieter überhaupt nicht zu verwenden, ist Teil dieser Planung. Auch die Prüfung Ihrer Verwendung fällt in diese Kategorie: Es geht darum, Entscheidungen über Ihren Standpunkt zum Datenschutz zu treffen. Diese Entscheidungen sind jedoch an sich nicht sehr detailliert. Die Entscheidung, ob Sie einen bestimmten Drittanbieter nutzen oder nicht, ist keine differenzierte Entscheidung. Es ist viel wahrscheinlicher, dass Sie etwas dazwischen wollen: ein bestimmtes Drittanbieterangebot benötigen oder planen, aber alle Tendenzen, die gegen den Datenschutz verstoßen, abzuschwächen (ob absichtlich oder versehentlich). Dies ist die Aufgabe des Schutzes der Nutzer zum „Build-Zeitpunkt“: Durch das Hinzufügen von Absicherungen, um unerwünschte Schäden zu reduzieren, mit denen Sie nicht gerechnet haben. All dies sind neue HTTP-Header, die Sie beim Bereitstellen von Seiten bereitstellen können. Sie weisen den User-Agent darauf hin oder fordern den User-Agent auf, bestimmte Datenschutz- oder Sicherheitsmaßnahmen einzunehmen.

Verweis-URL-Richtlinie

Das sollten Sie tun:

Legen Sie die Richtlinie strict-origin-when-cross-origin oder noreferrer fest, um zu verhindern, dass andere Websites einen Verweis-Header empfangen, wenn Sie auf sie verlinken oder sie von einer Seite als Unterressourcen geladen werden:

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

Oder serverseitig, zum Beispiel in Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Legen Sie bei Bedarf eine weniger strikte Richtlinie für bestimmte Elemente oder Anfragen fest.

Warum wird dadurch die Privatsphäre der Nutzer geschützt?

Standardmäßig übergibt jede HTTP-Anfrage, die vom Browser gestellt wird, einen Referer-Header, der die URL der Seite enthält, die die Anfrage initiiert. Dabei kann es sich um einen Link, ein eingebettetes Bild oder ein Skript handeln. Dies kann ein Datenschutzproblem sein, da URLs private Informationen enthalten können und URLs, die für Dritte verfügbar sind, diese privaten Informationen an sie weitergeben. Auf Web.dev sind einige Beispiele für URLs aufgeführt, die private Daten enthalten. Wenn ein Nutzer über https://social.example.com/user/me@example.com auf Ihre Website gelangt ist, erfahren Sie, wer dieser Nutzer ist. Dies ist definitiv eine Datenlecks. Aber selbst eine URL, die selbst keine privaten Informationen enthält, legt offen, dass dieser bestimmte Nutzer (den Sie möglicherweise kennen, falls er angemeldet ist) von einer anderen Website hierher gekommen ist. Dies zeigt daher, dass dieser Nutzer diese andere Website besucht hat. Dies ist bereits die Offenlegung von Informationen, die Sie vielleicht nicht über den Browserverlauf Ihrer Nutzer wissen sollten.

Durch Angabe eines Referrer-Policy-Headers (mit korrekter Rechtschreibung!) können Sie dies ändern, sodass nur ein Teil der Verweis-URL oder keine davon weitergegeben wird. Die MDN enthält alle Details, aber die meisten Browser haben jetzt standardmäßig den angenommenen Wert strict-origin-when-cross-origin. Das bedeutet, dass die Verweis-URL jetzt nur als Ursprung an Dritte weitergegeben wird (https://web.dev statt https://web.dev/learn/privacy). Dies ist ein nützlicher Datenschutz, ohne dass Sie etwas tun müssen. Sie können dies jedoch noch weiter einschränken, indem Sie Referrer-Policy: same-origin angeben, um zu verhindern, dass Verweisinformationen an Dritte weitergegeben werden. Oder Sie verwenden Referrer-Policy: no-referrer, um zu vermeiden, dass sie an Dritte weitergegeben werden, auch nicht an Ihren eigenen Ursprung. (Dies ist ein schönes Beispiel für das Gleichgewicht zwischen Datenschutz und Dienstprogramm. Die neue Standardeinstellung ist viel datenschutzfreundlicher als zuvor, liefert aber dennoch Dritten Ihrer Wahl, etwa Ihrem Analyseanbieter, hochwertige Informationen.)

Es ist auch nützlich, diesen Header explizit anzugeben, da Sie dann genau wissen, was die Richtlinie ist, und Sie sich nicht auf die Standardeinstellungen des Browsers verlassen. Wenn du keine Header festlegen kannst, besteht die Möglichkeit, eine Verweisrichtlinie für eine ganze HTML-Seite mithilfe eines Meta-Elements in <head> festzulegen: <meta name="referrer" content="same-origin">. Wenn du Bedenken bezüglich bestimmter Drittanbieter hast, kannst du auch ein referrerpolicy-Attribut für einzelne Elemente wie <script>, <a> oder <iframe> festlegen: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

Content Security Policy

Der Content-Security-Policy-Header, oft als „CSP“ bezeichnet, bestimmt, von wo externe Ressourcen geladen werden können. Sie wird hauptsächlich für Sicherheitszwecke verwendet, um Cross-Site-Scripting-Angriffe und Skripteinschleusungen zu verhindern. Wenn sie aber zusätzlich zu Ihren regelmäßigen Audits eingesetzt wird, kann es auch einschränken, wohin die von Ihnen ausgewählten Drittanbieter Daten weitergeben können.

Dies ist möglicherweise eine nicht so gute Nutzererfahrung. Wenn eines Ihrer Drittanbieterskripts beginnt, eine Abhängigkeit von einem Ursprung zu laden, der nicht in Ihrer Liste enthalten ist, wird diese Anfrage blockiert, das Skript schlägt fehl und Ihre Anwendung kann fehlschlagen oder zumindest auf die Fallback-Version für JavaScript-Fehler reduziert werden. Dies ist nützlich, wenn die CSP aus Sicherheitsgründen implementiert wird. Dies ist der normale Zweck: Schutz vor Cross-Site-Scripting-Problemen (und verwenden Sie dafür eine strikte CSP). Sobald Sie alle Inline-Skripts kennen, die auf Ihrer Seite verwendet werden, können Sie eine Liste dieser Skripts erstellen, für jedes Skript einen Hashwert berechnen oder einen Zufallswert (auch „Nonce“ genannt) hinzufügen und die Liste der Hashes dann Ihrer Content Security Policy hinzufügen. Dadurch wird verhindert, dass Skripts geladen werden, die sich nicht in der Liste befinden. Dies muss in den Produktionsprozess der Website integriert werden: Skripts auf Ihren Seiten müssen die Nonce enthalten oder einen Hashwert im Rahmen des Builds berechnen lassen. Weitere Informationen finden Sie im Artikel auf strict-csp.

Glücklicherweise unterstützen Browser den verwandten Header Content-Security-Policy-Report-Only. Wenn dieser Header angegeben ist, werden Anfragen, die gegen die bereitgestellte Richtlinie verstoßen, nicht blockiert. Es wird jedoch ein JSON-Bericht an eine angegebene URL gesendet. Ein solcher Header könnte so aussehen: Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/. Wenn der Browser ein Skript von einer anderen Stelle als 3p.example.com lädt, ist die Anfrage erfolgreich. Es wird jedoch ein Bericht an die bereitgestellte report-uri gesendet. Normalerweise wird dies verwendet, um vor der Implementierung mit einer Richtlinie zu experimentieren. Es bietet sich jedoch an, dies als Möglichkeit zur Durchführung eines "laufenden Audits" zu nutzen. Neben der zuvor beschriebenen regelmäßigen Prüfung können Sie CSP-Berichte aktivieren, um zu sehen, ob unerwartete Domains angezeigt werden. Dies kann bedeuten, dass Ihre Drittanbieterressourcen eigene Ressourcen von Drittanbietern laden, die Sie berücksichtigen und bewerten müssen. Es kann natürlich auch ein Zeichen dafür sein, dass einige websiteübergreifende Scripting-Exploits Ihre Sicherheitsgrenze überschritten haben. Das ist auch wichtig zu wissen.

Content-Security-Policy ist eine komplexe und umständliche API. Dies ist bekannt und wir arbeiten an der "nächsten Generation" der CSP, die dieselben Ziele erreichen wird, aber nicht ganz so kompliziert in der Anwendung sein wird.Das ist noch nicht ganz so weit, aber wenn Sie sehen möchten, in welche Richtung sich dies entwickeln wird (oder sich an der Entwicklung beteiligen möchten), finden Sie weitere Informationen unter https://github.com/WICG/csp-next.

Das sollten Sie tun:

Füge diesen HTTP-Header den bereitgestellten Seiten hinzu: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control. Wenn JSON unter dieser URL gepostet wird, speichern Sie ihn. Sehen Sie sich die gespeicherten Daten an, um die Domains von Drittanbietern zu erfassen, die von Ihrer Website angefordert werden, wenn sie von anderen aufgerufen werden. Aktualisieren Sie den Content-Security-Policy-Report-Only-Header, um die erwarteten Domains aufzulisten und zu sehen, wann sich diese Liste ändert:

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

Gute Gründe

Dies ist Teil Ihrer fortlaufenden technischen Prüfung. Bei der ersten von Ihnen durchgeführten technischen Prüfung erhalten Sie eine Liste der Drittanbieter, an die Ihre Website Nutzerdaten weitergibt oder weitergibt. Dieser Header führt dann dazu, dass die Seitenanfragen angeben, welche Drittanbieter jetzt kontaktiert werden. Außerdem können Sie im Laufe der Zeit Änderungen nachverfolgen. So werden Sie nicht nur über Änderungen informiert, die von bestehenden Drittanbietern vorgenommen wurden, sondern auch neu hinzugefügte Dritte, die beim technischen Audit nicht berücksichtigt wurden. Es ist wichtig, den Header zu aktualisieren, um keine Berichte über erwartete Domains mehr zu erstellen. Es ist aber auch wichtig, die manuelle technische Prüfung gelegentlich zu wiederholen. Bei Content-Security-Policy wird nämlich nicht angegeben, welche Daten übergeben wurden, sondern nur, dass eine Anfrage gestellt wurde.

Beachten Sie, dass sie nicht den Seiten hinzugefügt werden muss, die jedes Mal oder auf jeder Seite bereitgestellt werden. Optimieren Sie die Anzahl der Seitenantworten, die den Header erhalten, damit Sie eine repräsentative Stichprobe von Berichten erhalten, die nicht zu umfangreich sind.

Berechtigungsrichtlinie

Der Header Permissions-Policy, der unter dem Namen Feature-Policy eingeführt wurde, ähnelt vom Konzept Content-Security-Policy, schränkt jedoch den Zugriff auf leistungsstarke Browserfunktionen ein. Es ist beispielsweise möglich, die Nutzung von Gerätehardware wie Beschleunigungsmesser, Kamera oder USB-Geräten oder Nicht-Hardwarefunktionen wie die Berechtigung zum Wechseln in den Vollbildmodus oder zur Verwendung der synchronen XMLHTTPRequest einzuschränken. Diese Einschränkungen können auf eine Seite auf oberster Ebene oder auf Seiten mit Subframes angewendet werden, die über einen iFrame geladen werden. So soll verhindert werden, dass geladene Skripts versuchen, diese Funktionen zu verwenden. Bei dieser Einschränkung der API-Nutzung geht es nicht wirklich um den Fingerprinting im Browser. Es geht vielmehr darum, zu verhindern, dass Dritte aufdringliche Aktionen ausführen, z. B. leistungsstarke APIs verwenden oder Berechtigungsfenster öffnen. Dies wird vom Target Privacy Threat Model als "Intrusion" definiert.

Ein Permissions-Policy-Header wird als Liste von Paaren aus (Feature, erlaubten Ursprüngen) angegeben. Daher gilt:

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

In diesem Beispiel können diese Seite („self“) und <iframe>s aus dem Ursprung example.com die navigator.geolocation APIs aus JavaScript verwenden. Es erlaubt dieser Seite und allen Subframes die Nutzung der Fullscreen API und verhindert, dass jede Seite, auch diese Seite, eine Kamera zum Lesen von Videoinformationen verwendet. Hier finden Sie viele weitere Details und eine Liste möglicher Beispiele.

Die Liste der Funktionen, die vom Header „Permissions-Policy“ verarbeitet wird, ist umfangreich und kann sich ändern. Aktuell wird die Liste unter https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md verwaltet.

Das sollten Sie tun:

Browser, die Permissions-Policy unterstützen, verbieten standardmäßig leistungsstarke Funktionen in Subframes. Sie müssen aktiv werden, um sie zu aktivieren. Dieser Ansatz ist standardmäßig privat. Wenn Sie feststellen, dass Subframes auf Ihrer Website diese Berechtigungen benötigen, können Sie sie selektiv hinzufügen. Auf die Hauptseite wird jedoch standardmäßig keine Berechtigungsrichtlinie angewendet. Daher werden auch Skripts von Drittanbietern, die von der Hauptseite geladen werden, nicht daran gehindert, diese Funktionen zu verwenden. Aus diesem Grund ist es sinnvoll, standardmäßig eine restriktive Permissions-Policy auf alle Seiten anzuwenden und dann nach und nach Funktionen hinzuzufügen, die für deine Seiten erforderlich sind.

Beispiele für leistungsstarke Funktionen, die von Permissions-Policy betroffen sind, sind die Anforderung des Nutzerstandorts, der Zugriff auf Sensoren (einschließlich Beschleunigungsmesser, Gyroskop und Magnetometer), die Berechtigung zur Aktivierung des Vollbildmodus und das Anfordern des Zugriffs auf die Kamera und das Mikrofon des Nutzers. Oben finden Sie einen Link zur vollständigen (ändernden) Liste der Funktionen.

Wenn alle Features standardmäßig blockiert und dann selektiv wieder zugelassen werden sollen, müssen sie alle im Header aufgelistet werden. Das kann ziemlich unschick wirken. Trotzdem ist ein solcher Permissions-Policy-Header ein guter Ausgangspunkt. Unter permissionspolicy.com/ gibt es einen bequemen anklickbaren Generator zum Erstellen eines solchen Headers:

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

Integrierte Datenschutzfunktionen von Webbrowsern

Zusätzlich zu den Schutzmaßnahmen zur Erstellungszeit und zur Entwicklungszeit gibt es auch Datenschutzfunktionen, die zur Laufzeit angewendet werden. Das sind Datenschutzfunktionen, die in Browsern selbst zum Schutz der Nutzer implementiert werden. Dies sind keine Funktionen, die Sie direkt steuern oder als Website-Entwickler nutzen können – es handelt sich um Produktfunktionen. Es handelt sich jedoch um Funktionen, die Sie kennen sollten, da Ihre Websites von diesen Produktentscheidungen in Browsern betroffen sein können. Ein Beispiel dafür, wie sich diese Browserschutzmaßnahmen auf Ihre Website auswirken können: Wenn Sie clientseitiges JavaScript verwenden, das auf das Laden einer Drittanbieterabhängigkeit wartet, bevor Sie mit der Seiteneinrichtung fortfahren, und diese Abhängigkeit von Drittanbietern überhaupt nicht geladen wird, kann die Einrichtung Ihrer Seite unter Umständen nicht abgeschlossen werden und der Nutzer sieht eine halb geladene Seite.

Dazu gehören Intelligent Tracking Prevention in Safari (und die zugrunde liegende WebKit-Engine) und der erweiterte Tracking-Schutz in Firefox (und seine Engine, Gecko). All das erschwert es Drittanbietern, detaillierte Profile Ihrer Nutzer zu erstellen.

Die Ansätze für Datenschutzfunktionen von Browsern ändern sich häufig und es ist wichtig, auf dem neuesten Stand zu bleiben. Die folgende Liste der Schutzmaßnahmen ist zum Zeitpunkt der Erstellung dieses Dokuments korrekt. Browser können auch andere Schutzmaßnahmen implementieren. Diese Listen sind nicht vollständig. Im Modul zu den Best Practices finden Sie Informationen dazu, wie Sie mit den Änderungen Schritt halten können. Testen Sie mit zukünftigen Browserversionen auf Änderungen, die sich auf Ihre Projekte auswirken könnten. Für den Inkognito-Modus und den Modus für privates Surfen gelten manchmal andere Einstellungen als die Standardeinstellungen des Browsers. In diesen Modi können beispielsweise Drittanbieter-Cookies standardmäßig blockiert werden. Daher entsprechen Tests im Inkognitomodus möglicherweise nicht immer dem normalen Surferlebnis der meisten Nutzer, wenn sie nicht den privaten Modus verwenden. Bedenken Sie außerdem, dass das Blockieren von Cookies in verschiedenen Situationen dazu führen kann, dass nicht nur Cookies, sondern auch andere Speicherlösungen wie window.localStorage blockiert werden.

Chrome

  • Drittanbieter-Cookies werden künftig blockiert. Zum jetzigen Zeitpunkt sind sie nicht standardmäßig blockiert (kann aber von einem Nutzer aktiviert werden): Unter https://support.google.com/chrome/answer/95647 finden Sie weitere Informationen.
  • Die Datenschutzfunktionen von Chrome, insbesondere die Funktionen in Chrome, die mit Google und Diensten von Drittanbietern kommunizieren, werden unter privacysandbox.com/ beschrieben.

Edge

  • Drittanbieter-Cookies werden nicht standardmäßig blockiert, können aber von einem Nutzer aktiviert werden.
  • Die Edge-Funktion Tracking Prevention blockiert Tracker von nicht besuchten Websites und bekannte schädliche Tracker werden standardmäßig blockiert.

Firefox

Um einen Einblick in die möglichen Blockierungen zu erhalten und Probleme zu beheben, klicke auf das Schildsymbol in der Adressleiste oder rufe about:protections in Firefox auf (auf dem Computer).

Safari

  • Drittanbieter-Cookies werden standardmäßig blockiert.
  • Im Rahmen der Funktion Intelligent Tracking Prevention wird in Safari die an andere Seiten weitergegebene Verweis-URL auf eine Website der obersten Ebene und nicht auf eine bestimmte Seite reduziert: https://something.example.com statt https://something.example.com/this/specific/page.
  • localStorage-Daten des Browsers werden nach sieben Tagen gelöscht.

Unter https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ sind diese Funktionen zusammengefasst.

Aktivieren Sie auf dem Computer im Entwicklermenü von Safari die Option „Intelligent Tracking Prevention Debug Mode“, um Informationen zu möglichen blockierten Elementen zu erhalten und Probleme zu beheben. Weitere Informationen finden Sie unter https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/.

API-Angebote

Wozu brauchen wir neue APIs?

Neue datenschutzfreundliche Funktionen und Richtlinien in Browserprodukten tragen zwar dazu bei, den Datenschutz für Nutzer zu wahren, bringen aber auch Herausforderungen mit sich. Viele Webtechnologien können für websiteübergreifendes Tracking verwendet werden, obwohl sie für andere Zwecke entwickelt wurden und auch für andere Zwecke verwendet werden. Beispielsweise sind viele Identitätsföderationssysteme, die wir täglich verwenden, auf Drittanbieter-Cookies angewiesen. Drittanbieter-Cookies basieren auf zahlreichen Werbelösungen, auf die sich Publisher heute im Hinblick auf den Umsatz verlassen. Viele Lösungen zur Betrugserkennung basieren auf Fingerprinting. Was passiert mit diesen Anwendungsfällen, wenn Drittanbieter-Cookies und Fingerprinting eingestellt werden?

Für Browser wäre es schwierig und fehleranfällig, Anwendungsfälle zu unterscheiden und datenschutzkonforme Anwendungen zuverlässig von anderen zu unterscheiden. Aus diesem Grund haben die meisten Browser Drittanbieter-Cookies und Fingerprinting blockiert oder beabsichtigen, dies zu tun, um die Privatsphäre der Nutzer zu schützen.

Es ist ein neuer Ansatz erforderlich: Da Drittanbieter-Cookies eingestellt und das Fingerprinting gemindert wird, benötigen Entwickler maßgeschneiderte APIs, die den Anwendungsfällen gerecht werden (die nicht eingestellt wurden), aber datenschutzfreundlich sind. Ziel ist es, APIs zu entwerfen und zu erstellen, die nicht für websiteübergreifendes Tracking verwendet werden können. Im Gegensatz zu den im vorherigen Abschnitt beschriebenen Browserfunktionen sollen diese Technologien zu browserübergreifenden APIs werden.

Beispiele für API-Vorschläge

Die folgende Liste ist nicht vollständig – sie gibt nur einen kleinen Überblick über das, was gerade besprochen wird.

Beispiele für API-Vorschläge zum Ersetzen von Technologien, die auf Drittanbieter-Cookies basieren:

Beispiele für API-Vorschläge zum Ersetzen von Technologien, die auf passivem Tracking basieren:

Beispiele für weitere Vorschläge, auf denen andere APIs künftig ohne Drittanbieter-Cookies aufbauen können:

Darüber hinaus gibt es eine weitere Art von API-Vorschlag, die bislang browserspezifische Eindämmungen in Verbindung mit verdecktem Tracking bietet. Ein Beispiel hierfür ist Privacy Budget. Für diese verschiedenen Anwendungsfälle sind die ursprünglich von Chrome vorgeschlagenen APIs unter dem Oberbegriff der Privacy Sandbox verfügbar.

Global-Privacy-Control ist ein Header, mit dem einer Website mitgeteilt wird, dass der Nutzer möchte, dass erhobene personenbezogene Daten nicht an andere Websites weitergegeben werden. Die Absicht ist ähnlich wie „Do Not Track“, die eingestellt wurde.

Status der API-Angebote

Die meisten dieser API-Angebote wurden noch nicht oder nur hinter Flags oder in eingeschränkten Umgebungen zum Testen bereitgestellt.

Diese öffentliche Inkubationsphase ist wichtig: Browseranbieter und Entwickler sammeln Diskussionen und Erfahrungen darüber, ob diese APIs nützlich sind und ob sie tatsächlich das tun, wofür sie entwickelt wurden. Entwickler, Browseranbieter und andere Akteure des Ökosystems nutzen diese Phase, um das Design der API zu iterieren.

In der Privacy Group auf GitHub finden Sie Vorschläge für neue APIs.

Müssen Sie diese APIs verwenden?

Wenn Ihr Produkt direkt auf Drittanbieter-Cookies oder -Techniken wie Fingerprinting basiert, sollten Sie sich an diesen neuen APIs beteiligen, mit ihnen experimentieren und Ihre eigenen Erfahrungen in die Diskussionen und das API-Design einbringen. In allen anderen Fällen müssen Sie nicht unbedingt alle Details zu diesen neuen APIs zum Zeitpunkt der Erstellung dieses Dokuments kennen, aber es ist gut zu wissen, was als Nächstes kommt.