Drittanbieter

Was ist ein Drittanbieter?

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

Im Almanac werden Inhalte von Dritten als Inhalte definiert, die auf einem gemeinsam genutzten und öffentlichen Ursprung gehostet werden und von vielen verschiedenen von Websites und wird nicht von einzelnen Websiteinhabern beeinflusst. Dabei kann es sich um Bilder oder andere Medien wie Videos, Schriftarten oder Skripte handeln. Bilder und Skripts machen mehr aus als alles andere zusammen. Inhalte von Drittanbietern sind für die Entwicklung einer Website nicht erforderlich, aber es könnte genauso gut sein: werden Sie höchstwahrscheinlich etwas verwenden, das von einem öffentlichen Server geladen wird, z. B. Web-Schriftarten, eingebettete iFrames von Videos, Anzeigen oder JavaScript-Bibliotheken Vielleicht verwenden Sie Webschriftarten, die von Google Fonts stammen, oder das Messen von Analysen mit Google Analytics, Du hast möglicherweise "Gefällt mir"-Schaltflächen oder "Anmelden mit"-Schaltflächen aus sozialen Netzwerken hinzugefügt. Sie betten möglicherweise Karten oder Videos ein oder wickeln Einkäufe über Drittanbieterdienste ab. verfolgen Sie möglicherweise Fehler und Logging für Ihre eigenen Entwicklungsteams über Monitoring-Tools von Drittanbietern.

Aus Datenschutzgründen ist es hilfreich, eine etwas andere und weniger weit gefasste Definition zu verwenden: „Ressource von Drittanbietern“ und in bestimmte Drittanbieter-Skripts, werden aus gemeinsam genutztem öffentlichen Ursprung bereitgestellt und wie illustriert häufig verwendet, sind aber auch selbst verfasst. die nicht vom Websiteinhaber stammen. Die Urheberschaft Dritter ist das Entscheidende, wie Sie Ihre des Nutzers Privatsphäre von anderen. So können Sie überlegen, welche Risiken bestehen, und dann entscheiden, wie oder ob Sie eine Drittanbieter-Ressourcen basierend auf diesen Risiken. Wie bereits erwähnt, helfen Ihnen diese Dinge, den Kontext zu verstehen um zu verstehen, welche Kompromisse Sie eingehen müssen und was sie bedeuten.

Bei der Thematisierung von „Ressourcen von Drittanbietern“ die Unterscheidung zwischen Erstanbieter- und geht es um den Kontext, in dem etwas verwendet wird. Ein Script, das von einer anderen Website geladen wird, gehört zu einem Drittanbieter und die HTTP-Anfrage, die das Skript lädt, kann Cookies enthalten. Diese Cookies sind jedoch keine wirklichen "Drittanbieter-Cookies". Cookies und ob es sich um Drittanbieter-Cookies handelt, oder „Erstanbieter“ hängt davon ab, ob das Skript auf einem oder eine Seite auf der Website des Skripteigentümers.

Warum nutzen wir Ressourcen von Drittanbietern?

Mit Drittanbietern können Sie ganz einfach Funktionen zu Ihrer Website hinzufügen. Das können Funktionen sein, die den Nutzern angezeigt werden, oder unsichtbare Entwicklerfunktionen wie Fehlertracking reduzieren, aber den Entwicklungsaufwand reduzieren und die Skripts selbst beibehalten werden. von jemand anderem: dem Entwicklungsteam des Dienstes, den Sie anbieten. Dies alles funktioniert aufgrund der Zusammensetzbarkeit des Webs: Teile zu einem Ganzen zusammensetzen, das größer ist als die Summe.

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

Drittanbieter bieten eine endlose Sammlung von Bildern, Videos, Schriftarten, Tools, Bibliotheken, Widgets, Trackern, Anzeigen und alles andere ein, was Sie in unsere Webseiten einbetten können. Dies ermöglicht selbst die technisch nicht versierten, die in der Lage sind, Inhalte im Web zu erstellen und zu veröffentlichen. Ohne Drittanbieter wäre das Web ein langweiliges, textbasiertes und akademisches Medium sein und nicht die umfassende, immersive, komplexe Plattform, die so wichtig für das Leben ist. von vielen von uns.

Was können Ressourcen von Drittanbietern tun?

Auf Informationen zugreifen

Wenn Sie auf Ihrer Website eine Ressource eines Drittanbieters verwenden, werden einige Informationen an diese Drittanbieter-Website weitergegeben. Wenn Sie beispielsweise ein Bild von einer anderen Website einfügen, wird bei der HTTP-Anfrage des Browsers des Nutzers ein Verweis-URL-Link weitergeleitet. mit der URL Ihrer Seite sowie der IP-Adresse des Nutzers.

Websiteübergreifendes Tracking

Wir bleiben bei diesem Beispiel: Wenn das Bild von der Drittanbieter-Website geladen wird, kann es ein Cookie enthalten, das dann an den Drittanbieter zurückgesendet werden, wenn der Nutzer das nächste Bild anfordert. Das bedeutet, dass der Drittanbieter erkennen kann, verwendet wird, und kann ein Cookie zurücksenden, möglicherweise mit einer eindeutigen ID für diesen Nutzer. Das bedeutet, dass wenn der Nutzer das nächste Mal Ihre Website besucht oder eine andere Website mit einer Ressource dieses Drittanbieters, wird diese eindeutige Das ID-Cookie wird noch einmal gesendet. So kann der Drittanbieter ein Protokoll der von diesem Nutzer besuchten Seiten erstellen: Ihre Website, weitere Websites, die dieselben Ressourcen Dritter im gesamten Web nutzen.

Hier handelt es sich um websiteübergreifendes Tracking: Drittanbieter können damit auf vielen Websites ein Protokoll der Nutzeraktivitäten erfassen, sofern diese Nutzer nutzen alle eine Ressource vom selben Drittanbieter. Das kann eine Schriftart, ein Bild oder ein Stylesheet sein – alles statische Ressourcen. Es kann sich auch um eine dynamische Ressource wie ein Skript, eine Schaltfläche für soziale Medien oder eine Anzeige handeln. Mit dem enthaltenen Skript können noch mehr Informationen, da sie dynamisch sind: Sie können den Browser und die Umgebung des Nutzers überprüfen und diese Daten an den Ursprungsserver zurückgeben. Ein Skript kann dies bis zu einem gewissen Grad tun, ebenso wie dynamische Ressourcen, die nicht als Skript dargestellt werden, z. B. soziale Medien oder eine Anzeige oder eine Schaltfläche zum Teilen. In den Details eines Cookie-Banners auf beliebten Websites finden Sie eine Liste der Organisationen, die ein Tracking-Cookie für Ihre Nutzer hinzufügen, um ein Bild ihrer Aktivitäten zu sammeln und ein Profil dieses Nutzers zu erstellen. Es Hunderte davon sein können. Wenn ein Drittanbieter einen Dienst kostenlos anbietet, ist eine Möglichkeit für ihn wirtschaftlich sinnvoll, weil sie diese Daten sammeln und monetarisieren.

Das Target Privacy Threat Model ist ein nützlicher Leitfaden zu den Arten von Datenschutzproblemen, vor denen ein Browser seine Nutzer schützen sollte. Dieses Dokument wird zum Zeitpunkt der Erstellung dieses Dokuments noch diskutiert, es enthält jedoch einige übergeordnete Klassifizierungen bestehende Bedrohungen zu schützen. Die Risiken von Drittanbieterressourcen sind primär die „unerwünschte websiteübergreifende Erkennung“, bei der ein denselben Nutzer über mehrere Websites hinweg identifizieren kann, und die "Offenlegung vertraulicher Informationen", bei der eine Website Daten Informationen, die Nutzende als vertraulich betrachten.

Dies ist ein wichtiger Unterschied: Eine unerwünschte websiteübergreifende Erkennung ist schlecht, auch wenn der Drittanbieter keine zusätzlichen sensiblen Daten erfasst. Informationen daraus, da sie Nutzern die Kontrolle über ihre Identität entziehen. Zugriff auf die Verweis-URL und IP-Adresse eines Nutzers erhalten und Cookies selbst schon eine unerwünschte Offenlegung sind. Die Nutzung von Drittanbieter-Ressourcen ist mit einer Planungskomponente für den Einsatz von um sie datenschutzfreundlich zu gestalten. Ein Teil dieser Arbeit liegt in Ihren Aufgaben als Website-Entwickler, andere erledigt der Browser in seiner Rolle als User-Agent, d. h. der Kundenservicemitarbeiter, der im Auftrag des Nutzers arbeitet, um die Offenlegung vertraulicher Daten zu vermeiden, und unerwünschte websiteübergreifende Erkennung. Im Folgenden werden die Abhilfemaßnahmen und Ansätze für Browser genauer erläutert. und Website-Entwicklungsebene.

Serverseitiger Drittanbietercode

Unsere frühere Definition eines Drittanbieters hat den eher clientseitigen Ansatz des HTTP-Almanac absichtlich geändert (wie angemessen für ihren Bericht!), um die Urheberschaft von Dritten einzubeziehen, denn aus Datenschutzsicht die nicht Sie sind.

Dies gilt auch für Drittanbieter, die Dienste anbieten, die Sie auf dem Server nutzen, sowie auch auf dem Client. Aus Datenschutz ist es ebenfalls wichtig, die Bibliothek von Drittanbietern zu kennen, z. B. von NPM, Composer oder NuGet. Geben Ihre Abhängigkeiten Daten außerhalb Ihrer Grenzen weiter? Wenn Sie Daten an einen Logging-Dienst oder eine remote gehostete Datenbank übergeben, wenn Bibliotheken auch „phone home“ enthalten verstoßen, können diese gegen die Richtlinien der Nutzer verstoßen, Datenschutz und müssen überprüft werden. In der Regel müssen Sie einem serverbasierten Drittanbieter die Nutzerdaten bereitstellen. Das bedeutet, haben Sie mehr Kontrolle über die Daten, auf die es Zugriff hat. Im Gegensatz dazu kann ein clientbasierter Drittanbieter, also ein Skript oder eine HTTP-Ressource, auf Ihrer Website eingebunden sind und vom Browser des Nutzers abgerufen werden. der Erhebung durch Sie vermitteln. In diesem Modul geht es größtenteils um die Identifizierung dieser clientseitigen Drittanbieter. Sie haben sich dafür entschieden, Ihre Nutzer einzubeziehen und ihnen zugänglich zu machen, genau deshalb, weil Sie weniger Vermittlung haben. Aber es lohnt sich sollten Sie überlegen, Ihren serverseitigen Code zu sichern, damit Sie ausgehende Kommunikation verstehen und jede Art von Protokollieren oder unerwartet kommen. Wie genau das geht, können wir an dieser Stelle nicht im Detail besprechen (und hängen von Ihrer Serverkonfiguration ab). ist dies ein weiterer Aspekt Ihrer Sicherheits- und Datenschutzstrategie.

Warum muss man bei Drittanbietern vorsichtig sein?

Skripte und Funktionen von Drittanbietern sind sehr wichtig. Unser Ziel als Webentwickler sollte sein, solche Dinge zu integrieren, sie sich nicht abwenden! Aber es gibt potenzielle Probleme. Inhalte von Drittanbietern können zu Leistungsproblemen führen und da Sie einen externen Dienst innerhalb Ihrer Vertrauensgrenze einbinden. Aber Drittanbieter können auch zu Datenschutzproblemen führen.

Wenn wir über Online-Ressourcen von Drittanbietern sprechen, ist es hilfreich, an Sicherheitsprobleme zu denken (unter anderem) in denen Dritte Daten von Ihrem Unternehmen stehlen können, und um dies mit Datenschutzproblemen zu vergleichen, die unter anderem in denen Dritte, die Sie eingeschlossen haben, die Dateien Ihrer Nutzer Daten, ohne dass Sie (oder die Personen) einwilligen.

Ein Beispiel für ein Sicherheitsproblem sind „Web-Skimmer“, Kreditkartendaten stehlen – eine Ressource von Drittanbietern, die enthalten ist auf einer Seite, auf der ein Nutzer Kreditkartendetails eingibt, können diese Daten möglicherweise stehlen und an folgende Adresse senden: den böswilligen Dritten. Diejenigen, die diese Skimmer-Skripte erstellen, sind sehr kreativ und suchen nach Möglichkeiten, sie zu verbergen. Eine Zusammenfassung beschreibt, wie Skimmer-Skripts in Inhalten von Drittanbietern verborgen sind, z. B. auf Bildern, die für Website-Logos, Favicons und soziale Medien verwendet werden, beliebte Bibliotheken wie jQuery, Modernizr und Google Tag Manager, Website-Widgets wie Livechat-Fenster und CSS-Dateien.

Datenschutzprobleme sind etwas anders. Diese Drittanbieter sind Teil Ihres Angebots. um die Anforderungen Ihrer Nutzenden Vertrauen in Sie haben, müssen Sie sich darauf verlassen können, dass Ihre Nutzer ihnen vertrauen können. Wenn ein von Ihnen verwendeter Drittanbieter Daten Ihre Nutzer missbrauchen, das Löschen oder Auffinden erschweren, eine Datenpanne erleiden oder gegen die Erwartungen wahrnehmen, wird dies für die Nutzer wahrscheinlich als ein Vertrauensverlust in Ihren Dienst empfunden werden, nicht nur in den eines Drittanbieters. Es geht um Ihren Ruf und Ihre Beziehung in der Leitung. Deshalb ist es wichtig, sich zu fragen: Vertrauen Sie die Sie auf Ihrer Website einsetzen?

Beispiele für Drittanbieter

Wir sprechen über „Drittanbieter“ Es gibt jedoch unterschiedliche Arten, die Zugriff auf unterschiedliche Datenmengen haben. Wenn du beispielsweise deinem HTML-Code ein <img>-Element hinzufügst, das von einem anderen Server geladen wurde, erhält dieser Server andere Informationen. über Ihre Nutzer als das Hinzufügen eines <iframe>-Vorgangs oder eines <script>-Elements. Hierbei handelt es sich nicht um eine umfassende Liste, sondern lediglich um Beispiele, ist hilfreich, um die Unterschiede zwischen den verschiedenen Arten von Drittanbieter-Elementen zu verstehen, die auf Ihrer Website eingesetzt 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 Dazu gehören <img>, <audio>, <video>, von CSS geladene Webschriftarten und WebGL-Texturen. Diese werden alle über eine HTTP-Anfrage geladen. umfassen diese HTTP-Anfragen alle Cookies, die zuvor von der anderen Website gesetzt wurden, die IP-Adresse des anfragenden Nutzers, und die URL der aktuellen Seite als Verweis-URL. Bisher waren diese Daten bei allen Anfragen von Drittanbietern standardmäßig enthalten, obwohl Es werden Bemühungen unternommen, die von verschiedenen Browsern an Dritte weitergegebenen Daten zu reduzieren oder zu isolieren. Weitere Informationen hierzu finden Sie im Abschnitt Schutzmaßnahmen für Drittanbieter-Browser“ weitergehen.

Einen websiteübergreifenden iFrame einbetten

Ein vollständiges Dokument, das über <iframe> in deine Seiten eingebettet ist, kann neben dem Trifecta zusätzlichen Zugriff auf Browser-APIs anfordern von Cookies, IP-Adresse und Referrer-URL. Welche APIs genau für <iframe>d zur Verfügung stehen und wie der Zugriff angefordert wird, ist browserspezifisch und wird derzeit geändert: siehe „Richtlinie für Berechtigungen“ . Dokumente.

Websiteübergreifendes JavaScript ausführen

Wenn du ein <script>-Element einfügst, wird websiteübergreifendes JavaScript im Kontext der obersten Ebene deiner Seite geladen und ausgeführt. Das bedeutet, dass der das ausgeführte Skript vollen Zugriff auf alle Aktionen hat, die mit Ihren eigenen eigenen Skripts ausgeführt werden. Diese Daten werden weiterhin über Browserberechtigungen verwaltet, Daher ist die Zustimmung des Nutzers erforderlich, um beispielsweise den Standort des Nutzers anzufordern. Aber alle Informationen, die auf der Seite oder da JavaScript-Variablen von einem solchen Skript gelesen werden können. Dies gilt nicht nur für Cookies, die an den Drittanbieter übergeben werden, als Teil der Anfrage, aber auch Cookies, die nur für Ihre Website bestimmt sind. Ebenso kann ein Drittanbieter-Skript in Ihr -Seite kann dieselben HTTP-Anfragen stellen wie dein eigener Code. Das bedeutet, dass sie fetch()-Anfragen an deine Back-End-APIs senden kann, 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 nicht von Ihren eigenen zu unterscheiden sind. Code in ihrer Macht zu haben; Code, den Sie aus einem GitHub-Repository oder der Bibliothek Ihrer Programmiersprache (npm, PyPI, Composer usw.) einbinden Daten lesen kann wie Ihr anderer Code.

Informationen zu Drittanbietern

Dazu müssen Sie Ihre Drittanbieterliste kennen und wissen, welche Datenschutz-, Datenerhebungs- und Meinungen und Richtlinien im Hinblick auf die Nutzerfreundlichkeit. Dieses Verständnis wird dann zu einem Teil Ihrer Vor- und Nachteile: Wie nützlich und wichtig ist der Service, abwägen danach, wie aufdringlich, umständlich oder beunruhigend deren Anforderungen auf die Nutzer sind. Drittanbieter Content bietet einen Mehrwert, da Sie sich als Websiteinhaber die Arbeit abnehmen und sich auf Ihre Kernkompetenzen konzentrieren können. Für eine bessere Nutzererfahrung ist es also sinnvoll, diesen Kompromiss einzugehen und auf einen gewissen Nutzerkomfort und Datenschutz zu verzichten. Dabei ist es wichtig, die Nutzererfahrung nicht mit der Entwicklererfahrung zu verwechseln: „Für unser Entwicklungsteam ist es einfacher, Service“ ist keine überzeugende Geschichte für Nutzende.

Zu diesem Verständnis kommt der Prozess der Prüfung.

Drittanbieter überprüfen

Zu den Handlungen eines Drittanbieters gehört der Audit-Prozess. Das ist sowohl technisch als auch technisch möglich. für einen einzelnen Dritten und für Ihre gesamte Sammlung.

Nichttechnischen Audit durchführen

Der erste Schritt ist nicht technisch: Lesen Sie sich die Datenschutzerklärungen Ihrer Lieferanten durch. Wenn Sie Ressourcen von Drittanbietern einbeziehen, die Datenschutzerklärung lesen. Sie werden lang und voller rechtlicher Texte sein und in einigen Dokumenten werden möglicherweise einige der Ansätze verwendet. ausdrücklich vor in früheren Modulen gewarnt, z. B. vor zu allgemeinen Aussagen und ohne Hinweise wie oder wann erhobene Daten entfernt werden. Aus der Perspektive der Nutzenden müssen alle Daten, die auf Ihrer Website, einschließlich von Dritten, erfasst werden, unterliegen diesen Datenschutzbestimmungen. Auch wenn Sie Alles korrekt, wenn Sie Ihre Ziele transparent darstellen und die Erwartungen Ihrer Nutzer übertreffen Erwartungen an den Datenschutz und können Nutzer Sie auch für alles, was Ihre ausgewählten Drittanbieter tun, verantwortlich machen. Wenn in der Datei deren Datenschutzerklärungen enthalten. Dies sollten Sie in Ihren eigenen Richtlinien nicht angeben, da dies die vertrauenswürdig ist, ob es einen alternativen Anbieter gibt.

Dies kann hilfreich im Zusammenhang mit der weiter unten besprochenen technischen Prüfung sein, da sie als Grundlage für eine eine andere. Sie sollten die Ressourcen von Drittanbietern kennen, die Sie aus geschäftlichen Gründen einbinden, z. B. Werbenetzwerke. oder eingebetteten Inhalten), da eine Geschäftsbeziehung besteht. Dies ist ein guter Ausgangspunkt, um ein nicht-technisches Prüfung. Bei der technischen Prüfung ist es wahrscheinlich, dass Dritte identifiziert werden, insbesondere solche, die sich auf technische und eher als aus geschäftlichen Gründen (externe Komponenten, Analysen, Dienstprogrammbibliotheken), und diese Liste kann mit der Liste der geschäftsorientierte Drittanbieter. Das Ziel besteht darin, dass Sie als Websiteinhaber das Gefühl haben, zu verstehen, was die dritte die Sie in Ihre Website aufnehmen, und Sie als Unternehmen in der Lage sind, Ihren Rechtsbeistand mit dieser Liste von Dritten, um sicherzustellen, dass Sie alle erforderlichen 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. also keine Abhängigkeit laden, in einem Test-Harnisch und auf diese Weise prüfen. Stellen Sie sicher, dass Sie sehen, wie Ihre Abhängigkeiten als Teil Ihrer tatsächlichen Website verhalten. und nicht im Test- oder Entwicklungsmodus im öffentlichen Internet bereitgestellt werden. Es ist sehr aufschlussreich, die eigene Website als neuer Nutzer. Öffnen Sie einen Browser in einem neuen Profil, damit Sie nicht angemeldet sind und keine Vereinbarung gespeichert haben. Versuchen Sie dann, Ihre Website aufzurufen.

Registrieren Sie sich auf Ihrer eigenen Website für ein neues Konto, wenn Sie Nutzerkonten zur Verfügung stellen. Ihr Designteam wird diese neue nutzende Person orchestrieren. aus UX-Perspektive zu verstehen. Es kann jedoch anschaulich sein, den Ansatz auch aus datenschutzrechtlicher Sicht zu betrachten. Klicken Sie nicht einfach auf „Akzeptieren“ in den Nutzungsbedingungen, der Cookie-Warnung oder der Datenschutzerklärung; sich die Aufgabe stellen, Ihren eigenen Dienst zu verwenden ohne dabei personenbezogene Daten preiszugeben oder Tracking-Cookies zu verwenden, und prüfen Sie, ob das möglich ist und wie schwierig es ist. Es kann auch hilfreich sein, in den Entwicklertools des Browsers zu sehen, auf welche Websites zugegriffen wird und welche Daten an für diese Websites. Die Entwicklertools stellen eine Liste mit separaten HTTP-Anfragen bereit (normalerweise in einem Abschnitt namens "Netzwerk"). Hier sehen Sie, Hier werden Anfragen nach Typ gruppiert (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, aus der hervorgeht, wie viele verschiedene Orte kontaktiert werden. und es kann zu Anfragen von Dritten kommen, werden nur Drittanbieter angezeigt. (Es kann auch hilfreich sein, Content-Security-Policy zu verwenden, der Berichterstellung, um eine kontinuierliche Prüfung durchzuführen, für die Sie weiterlesen.)

Simon Hearnes Tool "Request Map Generator" bietet ebenfalls einen hilfreichen Überblick Unteranforderungen einer öffentlich verfügbaren Seite

An diesem Punkt können Sie auch die unternehmensbezogenen Dritten einbeziehen, die im Rahmen der nichttechnischen Prüfung identifiziert wurden. (d. h. die Liste der Unternehmen, mit denen Sie eine finanzielle Beziehung haben, wenn Sie deren Ressourcen nutzen). Das Ziel hier ist, um die Liste der Dritten, die Sie Ihrer Meinung nach verwenden (aus Finanz- und Rechtsunterlagen), mit der Liste abzugleichen, die Sie tatsächlich verwenden. (unter Berücksichtigung der HTTP-Anfragen von Drittanbietern, die Ihre Website sendet). Sie sollten in der Lage sein, für jedes welche technischen ausgehenden Anfragen gestellt werden. Wenn Sie bei der technischen Prüfung für einen Dritten keine Anfragen identifizieren können Geschäftsbeziehung identifiziert wurden, ist es wichtig, den Grund für Ihre Tests zu ermitteln und diese zu berücksichtigen: Ressource nur in einem bestimmten Land, auf einem bestimmten Gerätetyp oder für angemeldete Nutzer geladen wird. Dadurch wird das Bild Liste der zu prüfenden Websitebereiche und stellen Sie sicher, dass alle ausgehenden Zugriffe angezeigt werden. (Eventuell wird auch ein Drittanbieter Ressource, für die Sie bezahlen und die Sie nicht verwenden, was immer die Finanzabteilung aufmuntert.)

Wenn Sie die Liste der Anfragen an Dritte eingegrenzt haben, die Sie beim Audit berücksichtigen möchten, klicken Sie auf ein werden alle Details angezeigt, insbesondere die Daten, die an diese Anfrage übergeben wurden. Es ist auch sehr wichtig, Die Anfrage eines Drittanbieters, die Ihr Code initiiert, führt anschließend darüber hinaus dazu, dass viele weitere Anfragen von Drittanbietern initiiert werden. Diese zusätzlichen Drittanbieter werden ebenfalls "importiert", in Ihre eigene Datenschutzerklärung ein. Diese Aufgabe ist mühsam, aber wertvoll. oft in vorhandene Analysen eingebunden werden, sollte Ihr Front-End-Entwicklungsteam bereits Anfragen für (etwa mithilfe vorhandener Tools wie WebPageTest oder Lighthouse) und das Einbinden eines Datenschutzprüfungen in diesen Prozess integrieren.

<ph type="x-smartling-placeholder">
</ph> Die web.dev-Anfragezuordnung.
Eine (dramatisch vereinfachte) Anfragekarte für web.dev, auf der Websites von Drittanbietern zu sehen sind, die weitere Drittanbieter-Websites anfordern usw.

Do

Öffnen Sie einen Browser mit einem neuen Nutzerprofil, damit Sie nicht angemeldet sind und keine gespeicherte Vereinbarung haben. und öffne dann den Browser Entwicklungstools Netzwerkbereich mit allen ausgehenden Anfragen. Fügen Sie eine neue Spalte hinzu, in der die Domain der einzelnen Anfragen angezeigt wird, und prüfen Sie die „Drittanbieteranfragen“ um nur Drittanbieter anzuzeigen, falls vorhanden. Dann:

  • Rufen Sie Ihre Website auf.
  • Registrieren Sie sich für ein neues Konto, wenn Sie Nutzerkonten zur Verfügung stellen.
  • Versuchen Sie, Ihr erstelltes Konto zu löschen.
  • Führen Sie ein oder zwei normale Aktionen auf der Website aus. Die genauen Aktionen hängen davon ab, was Ihre Website tut. Sie sollten jedoch Aktionen auswählen, die die meisten Nutzer häufig ausführen.
  • Führen Sie ein oder zwei Aktionen aus, von denen Sie wissen, dass sie insbesondere Abhängigkeiten von Drittanbietern beinhalten. Dazu gehört das Teilen von Inhalten soziale Medien, das Starten eines Bezahlvorgangs oder das Einbetten von Inhalten von einer anderen Website.

Bei jeder dieser Aufgaben notieren Sie die Ressourcen, die von nicht Ihnen gehörenden Domains angefordert wurden. Sehen Sie sich dazu das Steuerfeld „Netzwerk“ an. wie beschrieben. Dies sind einige Ihrer Drittanbieter. Hierzu können Sie am besten mit den Netzwerktools des Browsers das Netzwerk erfassen Anfrageprotokolle in einer HAR-Datei.

HAR-Dateien und Erfassung

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 ab:

Chrome

Öffnen Sie die Entwicklertools des Browsers (Menü > Weitere Tools > Entwicklertools), gehen Sie zum Bereich „Network“ (Netzwerk), laden oder aktualisieren Sie die Seite und wählen Sie das Speichersymbol mit dem Abwärtspfeil oben rechts neben dem Dropdown-Menü Keine Drosselung aus.

Im Netzwerkbereich der Chrome-Entwicklertools ist das Symbol „HAR-Datei herunterladen“ markiert.
Firefox

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

Im Netzwerkbereich der Firefox-Entwicklertools ist die Option „Alle als Har speichern“ markiert.
Safari

Öffnen Sie die Entwicklertools des Browsers (Menü > Entwickeln > Web Inspector anzeigen). Wenn Sie das Menü „Entwickler“ nicht haben, aktivieren Sie es über Menü > Safari > Einstellungen > Erweitert > Menü „Entwickler“ in der Menüleiste anzeigen, gehen Sie zum Bereich „Netzwerk“, laden Sie die Seite oder aktualisieren Sie sie. und wählen Sie oben rechts Export (Exportieren) aus (rechts neben Preserve Log (Eventuell müssen Sie das Fenster vergrößern).

Im Bereich „Netzwerk“ in Safari ist die Option „HAR-Export“ markiert.

Für weitere Details können Sie im Abschnitt „Anfrage“ auch festhalten, was an Dritte weitergegeben wird. Diese Daten werden oft die verschleiert und nicht nützlich interpretierbar sind.

Best Practices für die Integration von Drittanbietern

Sie können eigene Richtlinien für Drittanbieter auf Ihrer Website festlegen: Ändern Sie den Anzeigenanbieter je nach Nutzung wie störend oder aufdringlich das Einwilligungs-Pop-up für Cookies ist, oder ob Sie Social-Media-Schaltflächen Tracking-Links in Ihren E-Mails oder utm_campaign-Links zur Verfolgung in Google Analytics in Ihren Tweets. Ein Aspekt, der berücksichtigt werden sollte, ist die Entwicklung einer Website der Datenschutz- und Sicherheitsstatus Ihres Analysedienstes. Einige Analysedienste werden explizit ausgetauscht wenn Sie Ihre Daten schützen. Häufig gibt es auch Möglichkeiten, ein Drittanbieter-Skript zu verwenden, das zusätzlichen Datenschutz bietet: sind Sie nicht das erste Team, das die ihre Daten zu schützen und sie vor der Datenerhebung durch Drittanbieter zu schützen. bereits Lösungen sein können. Außerdem reagieren viele Drittanbieter jetzt stärker auf Probleme bei der Datenerhebung als bisher. Außerdem können Sie oft Funktionen oder Parameter hinzufügen, die den Nutzerschutz erhöhen. Hier einige Beispiele:

Wenn Sie eine Schaltfläche zum Teilen in sozialen Medien hinzufügen

Sie könnten HTML-Schaltflächen direkt einbetten. Auf der Website https://sharingbuttons.io/ finden Sie einige gut gestaltete Beispiele. Oder Sie fügen einfache HTML-Links hinzu. Der Nachteil ist, dass Sie den Anteil am Anteil verlieren. Statistiken und Ihre Fähigkeit zur Klassifizierung Ihrer Kunden in Ihren Facebook-Analysen. Dies ist ein Beispiel für einen Kompromiss zwischen der Nutzung eines Drittanbieters und dem Erhalt weniger Analysedaten.

Im Allgemeinen ist es bei der Einbettung eines interaktiven Widgets irgendeiner Art von Drittanbieter häufig möglich, stattdessen ein mit dem Drittanbieter verknüpft sind. Das bedeutet zwar, dass Ihre Website nicht inline angezeigt wird, aber dies wirkt sich auf die Freigabe aus. Daten an den Drittanbieter von Ihnen an Ihren Nutzer, der entscheiden kann, ob er mit dem Drittanbieter interagieren möchte oder nicht.

Sie könnten beispielsweise Links für Twitter und Facebook hinzufügen, um Ihren Dienst auf beispiel.beispiel.de 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 Sie bei Facebook eine URL zum Teilen und bei Twitter eine URL sowie Text angeben können.

Beim Einbetten eines Videos

Achte beim Einbetten von Videos von Videohosting-Websites auf datenschutzfreundliche Optionen im Einbettungscode. Für YouTube können Sie beispielsweise youtube.com in der Einbettungs-URL durch www.youtube-nocookie.com ersetzen, um Tracking-Cookies zu vermeiden. die auf der eingebetteten Seite platziert werden. Außerdem können Sie das Kästchen „Erweiterten Datenschutzmodus aktivieren“ beim Generieren der Link von YouTube selbst teilen/einbetten. Dies ist ein gutes Beispiel für die Verwendung eines stärkeren Nutzerschutzmodus des Drittanbieters. Weitere Informationen dazu findest du unter https://support.google.com/youtube/answer/171780. und andere Einbettungsoptionen speziell für YouTube)

Andere Videowebsites haben in dieser Hinsicht weniger Möglichkeiten: TikTok hat zum Beispiel keine Möglichkeit, Videos einzubetten, ohne Tracking zu aktivieren. als dieser Artikel verfasst wurde. Es ist zwar möglich, die Videos selbst zu hosten (dies ist eine Alternative), aber es kann auch eine viel mehr Arbeit, vor allem die Unterstützung vieler Geräte.

Wie bei den zuvor besprochenen interaktiven Widgets ist es häufig möglich, ein eingebettetes Video durch einen Link zur entsprechenden Website zu ersetzen. Diese Funktion ist weniger interaktiv, da das Video nicht inline abgespielt wird. Der Nutzer kann jedoch entscheiden, ob er es gemeinsam ansehen möchte. Dabei kann es sich um als Beispiel für das „Fassadenmuster“, den Namen für das dynamische Ersetzen interaktiver Inhalte durch etwas, das eine nutzende Person erfordert. um sie auszulösen. Ein eingebettetes TikTok-Video kann durch einen einfachen Link zur TikTok-Videoseite ersetzt werden, allerdings mit etwas mehr. ein Thumbnail für das Video abrufen und anzeigen und daraus einen Link machen. Auch wenn der ausgewählte Videoanbieter bieten eine einfache Möglichkeit zum Einbetten von Videos ohne Tracking. Viele Videohosts unterstützen oEmbed, eine API, die bei gegebener einen Link zu einem Video oder eingebetteten Inhalten enthält, werden programmatische Details wie ein Thumbnail und ein Titel angezeigt. TikTok unterstützt oEmbed (weitere Informationen unter https://developers.tiktok.com/doc/embed-videos). Das bedeutet, dass kannst du (manuell oder programmatisch) einen Link zu einem TikTok-Video https://www.tiktok.com/@scout2015/video/6718335390845095173 in JSON-Metadaten zu diesem Video umwandeln. https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173 und ruft daher eine Miniaturansicht ab anzuzeigen. WordPress verwendet diese häufig, um oEmbed anzufordern.“ Informationen zu eingebetteten Inhalten. Sie können diese Option programmatisch verwenden. um eine „Fassade“ anzuzeigen das interaktiv aussieht und nach dem Klick ein interaktives Video einbettet oder verlinkt.

Beim Einbetten von Analyseskripts

Analytics ist so konzipiert, dass Daten zu Ihren Nutzern erfasst werden, damit sie analysiert werden können. Dazu ist es gedacht. Analysesysteme sind im Wesentlichen Dienste zur Erfassung und Anzeige von Daten über Zugriffe und Nutzer. Dies erfolgt der Einfachheit halber auf einem Drittanbieterserver, z. B. Google Analytics. der Implementierung. Es gibt auch selbst gehostete Analysesysteme wie https://matomo.org/. Dies ist jedoch aufwendiger als die Verwendung eines Drittanbieterlösung dafür. Wenn Sie ein solches System auf Ihrer eigenen Infrastruktur ausführen, können Sie die Datenerfassung reduzieren, da es Ihr eigenes Ökosystem nicht verlässt. Daten dagegen verwalten, entfernen und Richtlinien dafür festlegen ist Ihre Verantwortung. Das websiteübergreifende Tracking besteht meist dann, wenn es heimlich heimlich oder als Nebeneffekt der Nutzung eines Dienstes, der überhaupt keine Datenerfassung enthalten muss. Analysesoftware ist offenkundig Daten sammeln, um Websiteinhaber über ihre Nutzer zu informieren.

In der Vergangenheit gab es einen Ansatz, alle verfügbaren Daten über alles zu sammeln, wie ein riesiges Fischernetz, und und diese später auf interessante Muster hin analysieren. Diese Einstellung hat zu einem großen Teil das Gefühl von Unbehagen und Unruhe geweckt. zur Datenerhebung, die in Teil 1 dieses Kurses behandelt wurde. Viele Websites finden zunächst heraus, welche Fragen sie stellen und dann spezifische und begrenzte Daten sammeln, um diese Fragen zu beantworten.

Wenn auf Ihrer Website und auf anderen Websites ein Drittanbieterdienst verwendet wird, Sie aber den JavaScript-Code dieser Drittanbieter in Ihre Website einbinden, und für jeden Nutzer Cookies gesetzt werden, ist es wichtig zu bedenken, dass dieser Nutzer möglicherweise eine unerwünschte websiteübergreifende Erkennung durchführt. also das websiteübergreifende Tracking der Nutzer. Einige werden vielleicht, andere nicht, aber der Datenschutzgrundsatz besteht darin, dass wir davon ausgehen, dass ein solcher Drittanbieter-Dienst tatsächlich websiteübergreifendes Tracking durchführt, es sei denn, Sie haben einen guten Grund, darüber nachzudenken oder etwas anderes zu wissen. Dies ist an sich kein Grund, solche Dienste zu vermeiden, aber es ist etwas, das Sie bei Ihrer Einschätzung der Kompromisse berücksichtigen sollten. ihrer Verwendung.

Früher bestand der Kompromiss bei der Analyse nur darin, zu entscheiden, ob sie verwendet werden sollte oder nicht: Erfassung aller Daten und Beeinträchtigung des Datenschutzes im Gegenzug für Erkenntnisse und Planung nutzen oder ganz auf Erkenntnisse verzichten. Dies ist jedoch nicht mehr der Fall und häufig gibt es auch zwischen diesen beiden Extremen zu finden. Erkundigen Sie sich bei Ihrem Analyseanbieter nach den Konfigurationsoptionen, die Sie einschränken können die gesammelten Daten zu sammeln und die Menge und Dauer ihrer Speicherung zu reduzieren. Da Ihnen die Aufzeichnungen aus der technischen Prüfung vorliegen, wie zuvor beschrieben, können Sie die relevanten Abschnitte des Audits erneut ausführen, um zu bestätigen, dass das Ändern dieser Konfigurationen die Menge der erfassten Daten tatsächlich reduzieren. Wenn Sie diese Umstellung auf einer bestehenden Website vornehmen, ein quantifizierbares Maß, das für Ihre Nutzenden beschrieben werden kann. Beispielsweise gibt es in Google Analytics eine Reihe von Opt-in-Modulen (standardmäßig deaktiviert). Datenschutzfunktionen, von denen viele hilfreich sein können, um lokale Datenschutzgesetze einzuhalten. Einige Optionen, die bei der Einrichtung von Google In Analytics kann die Aufbewahrungsdauer für erhobene Daten unter „Verwaltung“ > „Tracking-Informationen“ > „Datenaufbewahrung“ niedriger als die Standardeinstellung von 26 Monaten sein. und einige technische Lösungen wie die teilweise IP-Anonymisierung ermöglichen. Weitere Informationen finden Sie unter https://support.google.com/analytics/answer/9019185.

Verwendung von Drittanbietern datenschutzfreundlich

Bisher haben wir besprochen, wie Sie Ihre Nutzer während der Entwicklungsphase Ihrer Anwendung vor Dritten schützen können, während was diese Anwendung tun soll. Die Entscheidung, einen bestimmten Drittanbieter nicht zu verwenden, Auch die Analyse der Nutzung fällt in diese Kategorie: Es geht darum, Entscheidungen über den Stand des Datenschutzes zu treffen. Diese Entscheidungen sind an sich nicht sehr detailliert; die Entscheidung, einen bestimmten Drittanbieter in Anspruch zu nehmen, oder dies abzulehnen. Es ist viel wahrscheinlicher, dass Sie etwas dazwischen wollen: ein bestimmtes Angebot eines Drittanbieters benötigen oder nutzen möchten, aber Tendenzen, die gegen den Datenschutz verstoßen (ob absichtlich oder versehentlich), abzuschwächen. Dies ist die Aufgabe, Nutzer in der „Build-Zeit“ zu schützen: die Einführung von Absicherungen, um Schäden zu reduzieren, mit denen Sie nicht gerechnet hatten. All dies sind neue HTTP-Header, die Sie beim Ausliefern Seiten und weist den User-Agent darauf hin oder befehlen ihn, bestimmte Haltungen in Bezug auf Datenschutz oder Sicherheit einzunehmen.

Richtlinie für Verweis-URLs

Do

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

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

Oder serverseitig, z. B. in Express:

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

Legen Sie gegebenenfalls für bestimmte Elemente oder Anfragen eine lockere Richtlinie fest.

Warum dies zum Schutz der Privatsphäre der Nutzer dient

Standardmäßig leitet jede HTTP-Anfrage des Browsers einen Referer-Header weiter, der die URL der Seite enthält, von der die Anfrage initiiert wird. z. B. über einen Link, ein eingebettetes Bild oder ein Skript. Das kann ein Datenschutzproblem sein, da URLs private Informationen enthalten können und diese URLs Dritten zugänglich gemacht wird, diese privaten Informationen an diese weitergibt. Web.dev listet einige Beispiele auf an URLs mit privaten Daten. Wenn bekannt ist, dass ein Nutzer von https://social.example.com/user/me@example.com auf Ihre Website gelangt ist, erfahren Sie, wer dieser Nutzer ist. Das ist definitiv ein Leck. Aber selbst eine URL, die selbst keine privaten Informationen preisgibt, legt offen, dass dieser bestimmte Nutzer (den Sie vielleicht kennen, wenn sie angemeldet sind) kommen von einer anderen Website hierher und dies zeigt, dass dieser Nutzer diese andere Website besucht hat. Das allein ist die Schaffung eines Informationen, die Sie vielleicht nicht über den Browserverlauf der Nutzer wissen sollten.

Durch Angabe eines Referrer-Policy-Headers (mit korrekter Schreibweise!) kannst du dies so ändern, dass einige oder keine der Verweis-URLs weitergegeben werden. MDN listet alle Details auf, aber die meisten Browser haben standardmäßig der angenommene Wert strict-origin-when-cross-origin, d. h. die Referrer-URL wird jetzt an die Parteien als Ursprung verwendet (https://web.dev statt https://web.dev/learn/privacy). Dies ist ein nützlicher Datenschutz ohne Sie müssen irgendetwas tun. Sie können dies jedoch noch weiter verkürzen, indem Sie Referrer-Policy: same-origin angeben, um zu vermeiden, dass Verweis-URL-Informationen an Dritte (oder Referrer-Policy: no-referrer, um die Weitergabe an Dritte zu vermeiden, auch an Ihre eigene Herkunft). (Dies ist ein schönes Beispiel für ein ausgewogenes Verhältnis zwischen Datenschutz und Nutzen. Der neue Standard ist viel datenschutzfreundlicher als zuvor, aber er stellt trotzdem übergeordnete Informationen an Dritte Ihrer Wahl bereit, z. B. Ihren Analyseanbieter.

Es ist auch hilfreich, diesen Header explizit anzugeben, da Sie dann genau wissen, um welche Richtlinie es sich handelt, und sich nicht auf die Standardeinstellungen des Browsers verlassen. Wenn du keine Header festlegen kannst, kannst du mithilfe eines Meta-Elements im <head> eine Verweisrichtlinie für eine ganze HTML-Seite festlegen: <meta name="referrer" content="same-origin">; Wenn Sie Bedenken bezüglich bestimmter Drittanbieter haben, können Sie auch eine referrerpolicy Attribut für einzelne Elemente wie <script>, <a> oder <iframe>: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

Content-Security-Policy

Der Header Content-Security-Policy, oft als „CSP“ bezeichnet, gibt vor, von wo externe Ressourcen geladen werden können. Es wird hauptsächlich zu Sicherheitszwecken verwendet, um Cross-Site-Scripting-Angriffe und Script-Injection zu verhindern. Neben Ihren regelmäßigen Audits kann es auch einschränken, an welche Drittanbieter Daten weitergeben können.

Die Nutzererfahrung ist möglicherweise nicht optimal. wenn eines Ihrer Drittanbieter-Skripts beginnt, eine Abhängigkeit aus einem Ursprung nicht in Ihrer Liste enthalten, wird diese Anfrage blockiert, das Skript schlägt fehl und Ihre Anwendung schlägt fehl. (oder zumindest auf die Fallback-Version mit Fehlern reduziert wird). Das ist nützlich, wenn die CSP aus Sicherheitsgründen verwendet wird, Dies ist der normale Zweck: Schutz vor Cross-Site-Scripting-Problemen (und verwenden Sie dazu eine strikte CSP). Sobald Sie alle von Ihrer Seite verwendeten Inline-Skripts kennen, können Sie eine Liste davon erstellen, einen Hashwert berechnen oder einen zufälligen Wert hinzufügen. („Nonce“) und fügen Sie die Liste der Hashes dann Ihrer Content Security Policy hinzu. Dadurch wird verhindert, dass Scripts nicht auf der Liste steht. Dies muss in den Produktionsprozess der Website integriert werden: Skripte auf Ihren Seiten müssen um die Nonce aufzunehmen oder einen Hash als Teil des Builds berechnen zu lassen. Ausführliche Informationen finden Sie im Artikel zu strict-csp.

Glücklicherweise unterstützen Browser einen zugehörigen Header, nämlich Content-Security-Policy-Report-Only. Wenn dieser Header angegeben wird, werden Anfragen die gegen die angegebene Richtlinie verstoßen, werden nicht blockiert, aber es wird ein JSON-Bericht an die 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/, Lädt der Browser ein Skript von einem anderen Ort als 3p.example.com, ist diese Anfrage erfolgreich, aber ein Bericht an die bereitgestellten report-uri gesendet. Normalerweise wird diese Methode verwendet, um mit einer Richtlinie zu experimentieren, bevor sie implementiert wird. Es ist jedoch nützlich, sollten Sie dies als Möglichkeit nutzen, eine „laufende Prüfung“ durchzuführen. Neben Ihrer zuvor beschriebenen regulären Prüfung haben Sie Sie können die CSP-Berichterstellung aktivieren, um zu sehen, ob unerwartete Domains angezeigt werden. Dies könnte bedeuten, dass Ihre Drittanbieterressourcen geladen werden und die Sie berücksichtigen und bewerten müssen. (Es kann aber auch sein, dass die Website Scripting-Exploits Ihre Sicherheitsgrenze überschritten haben, was natürlich ebenfalls wichtig ist!)

Content-Security-Policy ist eine komplexe und umständliche API. Das ist bekannt und wir arbeiten daran, die „nächste Generation“ der CSP die zwar die gleichen Ziele erreichen, aber nicht ganz so kompliziert in der Anwendung sind. (oder um Hilfe beim Design zu erhalten)? Dann besuchen Sie https://github.com/WICG/csp-next, um weitere Informationen zu erhalten.

Do

Fügen Sie den bereitgestellten Seiten diesen HTTP-Header hinzu: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control. Speichern Sie JSON-Daten, die an diese URL gesendet werden. Überprüfen Sie die gespeicherten Daten, um eine Sammlung der Drittanbieterdomains zu erhalten, die Ihre Website anfordert, wenn sie von anderen aufgerufen wird. 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

Warum

Dies ist Teil Ihrer fortlaufenden technischen Prüfung. Bei der ersten technischen Prüfung, die Sie durchgeführt haben, Eine Liste von Drittanbietern, an die Ihre Website Nutzerdaten weitergibt oder an diese weitergibt. Dieser Header bewirkt, dass Seitenanfragen Informationen darüber, welche Dritten jetzt kontaktiert werden, und Sie können Änderungen im Laufe der Zeit verfolgen. So werden Sie nicht nur über Änderungen informiert, die von Ihren bestehenden Drittanbietern vorgenommen wurden. Dabei werden aber auch neu hinzugefügte Drittanbieter aufgeführt, die nicht in die technische Prüfung aufgenommen wurden. Es ist wichtig, die Kopfzeile zu aktualisieren, damit keine Berichte über erwartete Domains mehr erstellt werden. Sie müssen aber auch die manuelle Anleitung wiederholen. gelegentliche technische Audits (da beim Content-Security-Policy-Ansatz nicht angegeben ist, welche Daten übergeben werden, dass ein Antrag gestellt wurde.)

Der Parameter muss nicht jedes Mal oder jeder Seite hinzugefügt werden. So viele Seitenantworten erhalten in der Kopfzeile, damit Sie repräsentative Stichprobe von Berichten erhalten, deren Menge nicht zu groß ist.

Berechtigungsrichtlinie

Der Permissions-Policy-Header, der unter dem Namen Feature-Policy eingeführt wurde, ähnelt vom Konzept her dem Content-Security-Policy-Header, schränkt aber den Zugriff auf leistungsstarke Browserfunktionen ein. Beispielsweise kann die Nutzung von Gerätehardware wie Beschleunigungsmesser, oder USB-Geräten sowie Funktionen einschränken, die nicht Hardware betreffen, z. B. die Berechtigung für den Vollbildmodus oder die Verwendung des synchronen XMLHTTPRequest-Modus. Diese Einschränkungen können auf eine Seite der obersten Ebene angewendet werden, um zu verhindern, dass geladene Skripts diese Funktionen verwenden. Seiten mit Subframes, die über einen iFrame geladen werden. Bei dieser Einschränkung der API-Nutzung geht es nicht wirklich um Fingerabdruck des Browsers. Es geht darum, zu verhindern, dass Dritte aufdringliche Dinge tun (wie die Verwendung von leistungsstarken APIs, die Verwendung von Pop-up-Fenstern Berechtigungsfenstern usw.). Dies wird im Target Privacy Threat Model als Intrusion (Intrusion) definiert.

Ein Permissions-Policy-Header wird als Liste von Paaren (feature, erlaubte Ursprünge) angegeben. Somit gilt:

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

In diesem Beispiel können diese Seite („self“) und <iframe>s aus der Quelle example.com die navigator.geolocation APIs verwenden. aus JavaScript, Er ermöglicht dieser Seite und allen Subframes die Nutzung der Vollbild-API und verbietet jede Seite, einschließlich dieser Seite, ob sie eine Kamera zum Lesen von Videoinformationen verwendet. Weitere Informationen und eine Liste möglicher Beispiele findest du hier.

Die Liste der Funktionen, die vom Header „Permissions-Policy“ verarbeitet werden, ist umfangreich und befindet sich möglicherweise noch in der Entwicklung. Die Liste ist derzeit unter https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md verwaltet.

Do

Browser, die Permissions-Policy unterstützen, verbieten standardmäßig keine leistungsfähigen Funktionen in Subframes. Sie müssen sie 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. Es wird jedoch standardmäßig keine Berechtigungsrichtlinie auf die Hauptseite angewendet. die von der Hauptseite geladen werden, sind nicht daran gehindert, diese Funktionen zu verwenden. Daher ist es sinnvoll, eine einschränkende Permissions-Policy standardmäßig auf alle Seiten ein und fügen dann nach und nach Funktionen hinzu, die für Ihre Seiten erforderlich sind.

Beispiele für leistungsstarke Funktionen, die von Permissions-Policy betroffen sind, sind die Anforderung des Standorts des Nutzers, der Zugriff auf Sensoren (einschließlich Beschleunigungsmesser, Gyroskop und Magnetometer), die Berechtigung zum Aktivieren des Vollbildmodus und Anfordern des Zugriffs auf die Kamera und das Mikrofon des Nutzers. Die (sich ändernde) vollständige Liste der Funktionen ist oben verlinkt.

Um alle Funktionen standardmäßig zu blockieren und dann selektiv wieder zuzulassen, müssen alle Funktionen in der Kopfzeile aufgelistet werden. was ziemlich unelegant wirken kann. Ein Permissions-Policy-Header ist dennoch ein guter Ausgangspunkt. permissionspolicy.com/ verfügt über einen klickbaren Generator zum Erstellen einer Kopfzeile. Wird er zum Erstellen einer Kopfzeile verwendet, mit der alle Funktionen deaktiviert werden, führt dies zu folgendem Ergebnis:

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 in Webbrowsern

Zusätzlich zur „Build-Dauer“ und „Designzeit“ Es gibt auch Datenschutzmaßnahmen, die während der Laufzeit erfolgen, d. h. -Funktionen, die in Browsern selbst zum Schutz der Nutzer implementiert sind. Dies sind keine Funktionen, die du als Website direkt steuern oder nutzen kannst Entwickler: Es sind Produktfunktionen, aber es handelt sich um Funktionen, die Sie kennen sollten, da Ihre Websites von diesen Produktentscheidungen betroffen sein können. in Browsern. Ein Beispiel dafür, wie sich diese Browserschutzmaßnahmen auf Ihre Website auswirken können, wenn Sie clientseitiges JavaScript verwenden, bevor eine Drittanbieterabhängigkeit geladen wird, bevor Sie mit der Seiteneinrichtung fortfahren, und diese Drittanbieterabhängigkeit überhaupt nicht geladen wird, müssen Sie Ihre Seiteneinrichtung wird möglicherweise nie abgeschlossen, sodass dem Nutzer eine nur halb geladene Seite angezeigt wird.

Sie beinhalten Intelligent Tracking Prevention in Safari. (und der zugrunde liegenden WebKit-Engine) sowie dem erweiterten Schutz vor Tracking in Firefox (und seiner Suchmaschine, Gecko). All das erschwert es Dritten, detaillierte Profile Ihrer Nutzer zu erstellen.

Die Herangehensweise an Datenschutzfunktionen von Browsern ändert sich häufig. Deshalb ist es wichtig, auf dem neuesten Stand zu bleiben. die folgende Liste von Schutzmaßnahmen zum Zeitpunkt der Abfassung des Textes korrekt sind. Browser können auch andere Schutzmaßnahmen implementieren: Diese Listen sind nicht vollständig. Weitere Informationen finden Sie im Modul zu Best Practices. Hier finden Sie Möglichkeiten, wie Sie mit den Änderungen Schritt halten können. Testen Sie außerdem auch künftige Browserversionen auf Änderungen, die sich auf Ihre Projekte auswirken könnten. Beachten Sie, dass im Inkognitomodus bzw. im Modus für privates Surfen manchmal andere Einstellungen implementiert werden als die Standardeinstellungen des Browsers. Drittanbieter-Cookies werden möglicherweise blockiert. zum Beispiel standardmäßig in solchen Modi). Daher entsprechen Tests im Inkognitomodus möglicherweise nicht immer der typischen Browsernutzung der meisten Nutzer. nicht im privaten Modus. Beachten Sie außerdem, dass das Blockieren von Cookies in verschiedenen Situationen bedeuten kann, dass andere Speicherlösungen wie window.localStorage, und nicht nur Cookies blockiert werden.

Chrome

  • Drittanbieter-Cookies sollen in Zukunft blockiert werden. Zum Zeitpunkt der Erstellung dieses Artikels sind sie nicht standardmäßig blockiert. Diese Option kann jedoch vom Nutzer aktiviert werden: https://support.google.com/chrome/answer/95647 werden die Details erläutert.
  • Die Datenschutzfunktionen von Chrome, insbesondere die Funktionen in Chrome, die mit Google und Diensten von Drittanbietern kommunizieren, sind unter privacysandbox.com/ beschrieben.

Edge

  • Drittanbieter-Cookies werden nicht standardmäßig blockiert. Dies kann jedoch vom Nutzer aktiviert werden.
  • Funktionsblöcke Tracking Prevention von Edge Tracker von nicht besuchten Websites und bekannter schädlicher Tracker werden standardmäßig blockiert.

Firefox

Klicken Sie in der Adressleiste auf das Schildsymbol oder rufen Sie about:protections in Firefox (auf einem Computer) auf, um Informationen zu den blockierten Elementen zu erhalten und Probleme zu beheben.

Safari

  • Drittanbieter-Cookies werden standardmäßig blockiert.
  • Im Rahmen der Funktion Intelligent Tracking Prevention Safari reduziert die an andere Seiten übergebene Referrer-URL zu einer Website der obersten Ebene und nicht zu einer bestimmten Seite: (https://something.example.com, statt https://something.example.com/this/specific/page).
  • Browserdaten localStorage-Daten werden nach sieben Tagen gelöscht.

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

Aktiviere den Debug-Modus „Intelligent Tracking Prevention Debug Mode“, um Informationen zu möglichen Blockierungen zu erhalten und Probleme zu beheben. im Safari- Entwicklermenü (auf dem Computer). Weitere Informationen finden Sie unter https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/.

API-Vorschläge

Wozu brauchen wir neue APIs?

Neue datenschutzfreundliche Funktionen und Richtlinien in Browserprodukten tragen zwar dazu bei, die Privatsphäre der Nutzer zu wahren, bringen aber auch Herausforderungen mit sich. Viele Webtechnologien sind für websiteübergreifendes Tracking geeignet, obwohl sie für andere Zwecke entwickelt wurden und verwendet werden. Beispiel: Viele Systeme zur Identitätsföderation, die wir täglich nutzen, nutzen Drittanbieter-Cookies. Zahlreiche Werbelösungen, die Publisher auf Umsätzen beruhen, basieren auf Drittanbieter-Cookies. Viele Lösungen zur Betrugserkennung basieren auf Fingerprinting. Was? passiert es in diesen Anwendungsfällen, wenn Drittanbieter-Cookies und Fingerprinting eingestellt werden?

Es wäre schwierig und fehleranfällig für Browser, Anwendungsfälle zu unterscheiden und zuverlässig zu unterscheiden, wenn sie gegen den Datenschutz verstoßen. von anderen. Aus diesem Grund haben die meisten gängigen Browser Drittanbieter-Cookies und Fingerprinting blockiert oder möchten dies zum Schutz der Nutzer tun. Datenschutz.

Ein neuer Ansatz ist erforderlich: Da Drittanbieter-Cookies abgeschafft werden und die Verwendung von Fingerprinting reduziert wird, benötigen Entwickler maßgeschneiderte APIs. die weiterhin den Anwendungsfällen entsprechen, aber datenschutzfreundlich entwickelt wurden. Das Ziel ist es, APIs, die nicht für das websiteübergreifende Tracking verwendet werden können Im Gegensatz zu den im vorherigen Abschnitt beschriebenen Browserfunktionen Browser-übergreifende APIs zu entwickeln.

Beispiele für API-Vorschläge

Die folgende Liste ist nicht vollständig – sie gibt nur einen kleinen Vorgeschmack auf das, was gerade diskutiert wird.

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

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

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

Darüber hinaus gibt es einen weiteren API-Vorschlag, bei dem es darum geht, bisher Browserspezifisches verdecktes Tracking einzudämmen. Ein Beispiel ist Privacy Budget. In diesen verschiedenen Anwendungsfälle sind die von Chrome vorgeschlagenen APIs unter dem Oberbegriff Privacy Sandbox zu finden.

Global-Privacy-Control ist ein Header, mit dem einer Website mitgeteilt wird, dass Nutzer möchte, dass erhobene personenbezogene Daten nicht an andere Websites weitergegeben werden. Es wurde ein ähnliches Programm wie „Do Not Track“ entwickelt, das eingestellt wurde.

Status der API-Vorschläge

Die meisten dieser API-Vorschläge wurden noch nicht oder nur hinter Flags oder in eingeschränkten Umgebungen für Tests bereitgestellt.

Diese öffentliche Ausarbeitungsphase ist wichtig: Browseranbieter und Entwickler sammeln Diskussionen und Erfahrungen darüber, ob diese APIs und ob sie tatsächlich das tun, wofür sie vorgesehen sind. Entwickler, Browseranbieter und andere Akteure im Ökosystem nutzen diese Phase um das Design der API zu iterieren.

Der beste Ort, um über neue APIs auf dem Laufenden zu bleiben, ist die Liste der Vorschläge der Privacy Group auf GitHub.

Müssen Sie diese APIs verwenden?

Wenn Ihr Produkt direkt auf Drittanbieter-Cookies oder -Techniken wie Fingerprinting basiert, sollten Sie sich mit diesen neuen APIs beschäftigen, mit ihnen experimentieren und Ihre eigenen Erfahrungen in die Diskussionen und das API-Design einbringen. In allen anderen Fällen müssen Sie zum Zeitpunkt der Erstellung des Textes nicht unbedingt alle Details zu diesen neuen APIs kennen. Es ist jedoch gut, über zukünftige Entwicklungen im Klaren zu sein.