Details zur Privacy Sandbox

Die Privacy Sandbox umfasst mehrere Vorschläge für Anwendungsfälle von Drittanbietern ohne Drittanbieter-Cookies oder andere Tracking-Mechanismen.

Dutton

Zusammenfassung

  • In diesem Beitrag werden APIs und Konzepte aus den Privacy Sandbox-Vorschlägen beschrieben.
  • Die Autoren bitten um Feedback aus der Community, insbesondere aus der Werbebranche (Publisher, Werbetreibende und AdTech-Unternehmen), um fehlende Anwendungsfälle vorzuschlagen und Informationen darüber zu geben, wie Sie Ihre geschäftlichen Anwendungsfälle unterstützen können.
  • Sie können die Vorschläge kommentieren, indem Sie Probleme in den unten verlinkten Repositories melden.
  • Am Ende dieses Artikels finden Sie ein Glossar zu den Angeboten.

Der aktuelle Stand des Datenschutzes im Web

Websites nutzen Dienste anderer Unternehmen für Analysen, Videos und viele andere nützliche Dinge. Die Zusammensetzbarkeit ist eine der Superkräften des Webs. Anzeigen werden über Drittanbieter-JavaScript und -iFrames in Webseiten eingebunden. Anzeigenaufrufe, Klicks und Conversions werden mithilfe von Drittanbieter-Cookies und -Scripts erfasst.

Wenn Sie jedoch eine Website besuchen, wissen Sie möglicherweise nicht über die beteiligten Dritten und deren Verwendung mit Ihren Daten. Selbst Publisher und Webentwickler verstehen möglicherweise nicht die gesamte Lieferkette von Drittanbietern.

Für die Anzeigenauswahl, die Conversion-Analyse und andere Anwendungsfälle ist es derzeit erforderlich, eine stabile websiteübergreifende Nutzeridentität aufzubauen. In der Vergangenheit wurde dies mithilfe von Drittanbieter-Cookies umgesetzt. Seitdem wird jedoch der Zugriff auf diese Cookies in Browsern eingeschränkt. Außerdem werden vermehrt andere Mechanismen für das websiteübergreifende Nutzer-Tracking verwendet, etwa verdeckte Browserspeicher, Geräte-Fingerprinting und Anfragen nach personenbezogenen Daten wie E-Mail-Adressen.

Das ist ein Dilemma für das Web. Wie können legitime Anwendungsfälle von Drittanbietern unterstützt werden, ohne dass Nutzer websiteübergreifend erfasst werden können?

Wie können Websites insbesondere Inhalte finanzieren, indem sie Dritten die Möglichkeit geben, Werbung einzublenden und die Anzeigenleistung zu messen, aber nicht zulassen, dass Profile für einzelne Nutzer erstellt werden? Wie können Werbetreibende und Websiteinhaber die Authentizität von Nutzern bewerten, ohne dunkle Muster wie Geräte-Fingerprinting verwenden zu müssen?

Die aktuelle Arbeitsweise kann für das gesamte Web und nicht nur für die Nutzer problematisch sein. Für Publisher und Werbetreibende kann das Tracking der Identität und die Verwendung verschiedener nicht standardmäßiger Drittanbieterlösungen die technischen Altlasten, die Codekomplexität und das Datenrisiko erhöhen. Nutzer, Entwickler, Publisher und Werbetreibende sollten darauf vertrauen können, dass die Datenschutzentscheidungen der Nutzer im Web geschützt werden.

Werbung ist ein zentrales Geschäftsmodell für das Internet im Web, aber Werbung muss für alle funktionieren. Damit kommen wir zum Ziel der Privacy Sandbox, eine florierende Webumgebung zu schaffen, die Nutzer respektiert und die Privatsphäre standardmäßig respektiert.

Einführung der Privacy Sandbox

Mit der Privacy Sandbox werden mehrere datenschutzfreundliche APIs eingeführt, um Geschäftsmodelle zu unterstützen, mit denen das offene Web finanziert wird, wenn Tracking-Mechanismen wie Drittanbieter-Cookies fehlen.

Für die Privacy Sandbox APIs müssen Webbrowser eine neue Rolle übernehmen. Anstatt mit eingeschränkten Tools und Schutzmechanismen zu arbeiten, ermöglichen die APIs dem Browser des Nutzers, im Namen des Nutzers – lokal auf seinem Gerät – zu handeln, um die personenbezogenen Daten des Nutzers beim Surfen im Web zu schützen. Die APIs ermöglichen Anwendungsfälle wie Anzeigenauswahl und Conversion-Analyse, ohne dass einzelne private und personenbezogene Daten offengelegt werden. Aus technischer Sicht ist eine sandbox eine geschützte Umgebung. Ein Grundprinzip der Privacy Sandbox ist, dass personenbezogene Daten von Nutzern geschützt und nicht so weitergegeben werden müssen, dass sie über Websites hinweg identifiziert werden können.

Dies ist ein Richtungswechsel für Browser. Die Zukunftsvision der Privacy Sandbox sieht vor, dass Browser spezielle Tools für bestimmte Anwendungsfälle bereitstellen und gleichzeitig den Datenschutz wahren. Ein potenzielles Datenschutzmodell für das Web legt die Grundprinzipien der APIs fest:

  • Damit lässt sich der Bereich von Webaktivitäten bestimmen, in dem der Browser des Nutzers zulassen kann, dass eine Person von Websites als eine einzige Identität behandelt wird.
  • Um herauszufinden, wie sich Informationen über Identitätsgrenzen hinweg bewegen können, ohne diese Trennung zu gefährden.

Die Privacy Sandbox-Vorschläge

Die Privacy Sandbox-Initiative benötigt Ihre Unterstützung, um Drittanbieter-Cookies erfolgreich zu entfernen. Die Erklärungen des Vorschlags benötigen Feedback von Entwicklern, Publishern, Werbetreibenden und Anzeigentechnologie-Unternehmen, um fehlende Anwendungsfälle vorzuschlagen und Informationen darüber bereitzustellen, wie ihre Ziele datenschutzkonform erreicht werden können.

Sie können die Erläuterung des Angebots kommentieren, indem Sie Probleme mit jedem Repository melden:

  • Datenschutzmodell für das Web
    Legen Sie den Bereich von Webaktivitäten fest, in dem Websites eines Nutzers mithilfe des Browsers einer Person als eine einzige Identität behandeln lassen. Identifizieren Sie die Möglichkeiten, wie sich Informationen über Identitätsgrenzen hinweg bewegen können, ohne diese Trennung zu gefährden.
  • Datenschutzbudget
    Begrenzt die Gesamtzahl der potenziell identifizierbaren Daten, auf die Websites zugreifen können. APIs aktualisieren, um die Menge an potenziell identifizierbaren Daten zu reduzieren Den Zugang zu potenziell identifizierbaren Daten messbar machen
  • Gnatcatcher
    Sie können die Identifizierung einzelner Nutzer anhand ihrer IP-Adresse einschränken.
  • Trust Token API
    Ermöglichen Sie eine Quelle, bei der einem Nutzer kryptografische Tokens ausgestellt werden, die vom Browser des Nutzers gespeichert werden, damit sie in anderen Kontexten zur Bewertung der Authentizität des Nutzers verwendet werden können.
  • First-Party-Sets
    Sie können zulassen, dass verbundene Domainnamen, die derselben Entität gehören, als zu derselben Erstanbieter gehören.
  • Zusammengefasste Berichte
    Bieten Sie datenschutzfreundliche Mechanismen für eine Vielzahl von Anwendungsfällen, z. B. Messung von View-through-Conversions, Anzeigenwirkung auf die Markenbekanntheit, Anzeigenwirkung auf die Markenbekanntheit und Reichweite.
  • Attributionsberichte
    Mit Berichten auf Ereignisebene und zusammengefassten Berichten erhalten Sie datenschutzfreundliche Analysen von Klicks und Aufrufen.
  • Topics API
    Interessenbezogene Werbung aktivieren, ohne die von Nutzern besuchten Websites erfassen zu müssen Das Design der API basiert auf dem Feedback der Community aus früheren FLoC-Tests und ersetzt den FLoC-Vorschlag.
  • FLEDGE
    Diese Lösung für Remarketing-Anwendungsfälle ist so konzipiert, dass sie nicht von Drittanbietern verwendet werden kann, um das Browserverhalten von Nutzern websiteübergreifend zu verfolgen.

Sie können sich sofort in die Erklärungen zu API-Vorschlägen eintauchen. In den kommenden Monaten werden wir Beiträge zu jedem einzelnen Vorschlag veröffentlichen.

Außerdem werden wir unsere Playlist mit fünfminütigen Videos mit einfachen Erklärungen zu den einzelnen APIs ergänzen.

Anwendungsfälle und Ziele

Conversions erfassen

Ziel: Werbetreibenden ermöglichen, die Anzeigenleistung zu messen.

Mit der Attribution Reporting API können zwei Ereignisse gemessen werden, die miteinander verknüpft sind: 1. Ein Ereignis auf der Website eines Publishers, z. B. wenn ein Nutzer eine Anzeige ansieht oder klickt. 1. Eine nachfolgende Conversion auf der Website eines Werbetreibenden.

Diese API unterstützt die Messung von Klicks und View-through.

Weitere Funktionen dieser API sind Berichte für geräteübergreifende Attribution und Berichte zur App-zu-Web-Attribution.

Die API bietet außerdem zwei Arten von Attributionsberichten:

  • In Berichten auf Ereignisebene werden bestimmte Anzeigenklicks oder ‐aufrufe (auf Anzeigenseite) mit Daten auf der Conversion-Seite verknüpft. Um die Privatsphäre der Nutzer zu schützen, indem die Zusammenführung der Nutzeridentität über Websites hinweg verhindert wird, sind nur sehr begrenzte Daten auf Conversion-Seite verfügbar. Außerdem werden die Daten „verrauscht“, d. h. in einem kleinen Prozentsatz von Fällen werden zufällige Daten gesendet. Aus Datenschutzgründen werden Berichte nicht sofort gesendet.

  • Zusammengefasste Berichte sind nicht an ein bestimmtes Ereignis auf Anzeigenseite gebunden. Diese Berichte enthalten detailliertere Conversion-Daten als Berichte auf Ereignisebene. Eine Kombination aus Datenschutztechniken wie Kryptografie, Vertrauensverteilung und Differential Privacy trägt dazu bei, das Risiko der Zusammenführung von Identitäten über Websites hinweg zu verringern.

Beide Berichtstypen können gleichzeitig verwendet werden und ergänzen sich.

In der Einführung in Attribution Reporting finden Sie weitere Informationen zum Status dieser Funktionen und dazu, wie Sie die API ausprobieren können.

Anzeigen auswählen

Ziel: Werbetreibenden ermöglichen, für Nutzer relevante Anzeigen zu schalten

Relevante Anzeigen sind für Nutzer attraktiver und für Publisher profitabler, also für Nutzer, die werbeunterstützte Websites betreiben. Tools zur Anzeigenauswahl von Drittanbietern machen Werbeflächen für Werbetreibende (die Personen, die Werbeflächen auf Websites kaufen) wertvoller. Dies wiederum steigert den Umsatz für werbeunterstützte Websites und ermöglicht die Erstellung und Veröffentlichung von Inhalten.

Es gibt viele Möglichkeiten, Anzeigen für den Nutzer relevant zu machen. Hier einige Beispiele:

  • Selbst erhobene Daten: Es werden Anzeigen ausgeliefert, die für Themen relevant sind, die ein Nutzer einer Website mitgeteilt hat, für die er sich interessiert, oder für Inhalte, die er sich zuvor auf der aktuellen Website angesehen hat.
  • Kontext: Wählen Sie basierend auf dem Websitecontent aus, wo Anzeigen ausgeliefert werden sollen. Beispiel: „Diese Anzeige neben Artikeln über Stricken platzieren“
  • Remarketing: Ihre Anzeigen werden auf Nutzer ausgerichtet, die Ihre Website bereits besucht haben, während sie sich nicht auf Ihrer Website befinden. Beispiel: „Zeigen Sie diese Anzeige mit Schnäppchenjägern Nutzern, die Ihr Geschäft besucht und Strickartikel im Einkaufswagen gelassen haben, während sie Bastel-Websites besuchen.“
  • Interessenbezogene Werbung: Anzeigen werden basierend auf dem Browserverlauf des Nutzers ausgewählt. Beispiel: „Diese Anzeige Nutzern zeigen, deren Suchverhalten darauf schließen lässt, dass sie am Stricken interessiert sind.“

Selbst erhobene Daten und kontextbezogene Anzeigen können ausgewählt werden, ohne dass über die Aktivitäten des Nutzers auf einer Website Informationen vorliegen. Für diese Verfahren ist kein websiteübergreifendes Tracking erforderlich.

Beim Remarketing werden in der Regel Cookies oder eine andere Methode verwendet, um Nutzer websiteübergreifend zu erkennen. Dazu werden Nutzer Listen hinzugefügt und dann bestimmte Anzeigen für die Auslieferung ausgewählt.

Bei der interessenbezogenen Anzeigenauswahl werden derzeit Cookies verwendet, um das Nutzerverhalten auf möglichst vielen Websites zu verfolgen. Viele Nutzer machen sich Gedanken über die datenschutzbezogenen Folgen der Anzeigenauswahl. Im Rahmen der Privacy Sandbox werden zwei Alternativen für das Remarketing und für die interessenbezogene Auswahl vorgeschlagen:

  • FLEDGE: für Remarketing-Anwendungsfälle.
    Die API ist so konzipiert, dass sie nicht von Drittanbietern verwendet werden kann, um das Browserverhalten der Nutzer zu verfolgen: Im Browser des Nutzers, nicht im Browser des Werbetreibenden oder der Plattform für Anzeigentechnologie, werden vom Werbetreibenden definierte Interessengruppen gespeichert, mit denen der Browser des Nutzers verknüpft ist. Der Browser des Nutzers kombiniert Interessengruppendaten mit Daten zu Käufern/Verkäufern und der Geschäftslogik, um lokal auf dem Gerät des Nutzers eine Auktion durchzuführen, um eine Anzeige auszuwählen, anstatt Daten an Dritte weiterzugeben.

  • Topics API: für interessenbasierte Zielgruppen
    Interessenbezogene Werbung aktivieren, ohne die vom Nutzer besuchten Websites erfassen zu müssen Die API schlägt vor, dass mithilfe von maschinellem Lernen Themen aus Hostnamen abgeleitet werden, und eine JavaScript API, die grobe Themen zurückgibt, an denen ein Nutzer derzeit interessiert sein könnte. Grundlage sind die Hostnamen der kürzlich besuchten Websites.

Gegen Fingerprinting

Ziel: Die Menge an potenziell identifizierbaren Daten, die von APIs offengelegt werden, zu reduzieren und den Zugriff auf potenziell identifizierbare Daten zu ermöglichen, die von Nutzern gesteuert werden können und messbar sind.

In den Browsern werden Maßnahmen ergriffen, um Drittanbieter-Cookies abzuschaffen. Doch auch Verfahren zur Identifizierung und Nachverfolgung des Verhaltens einzelner Nutzer, auch Fingerprinting genannt, haben sich weiterentwickelt. Bei der Fingerabdruckerkennung werden Mechanismen verwendet, die den Nutzern nicht bekannt sind und die sie nicht steuern können.

  • Der Vorschlag zum Datenschutzbudget zielt darauf ab, das Potenzial für Fingerprinting einzuschränken. Dazu wird ermittelt, wie viele Fingerabdruckdaten von JavaScript APIs oder anderen Oberflächen (z. B. HTTP-Anfrageheadern) offengelegt werden. Außerdem wird ein Grenzwert für den Zugriff auf diese Daten festgelegt.

  • Fingerabdruckoberflächen wie der User-Agent-Header werden reduziert und die Daten, die über alternative Mechanismen wie Client-Hinweise zur Verfügung gestellt werden, unterliegen Limits für das Privacy Budget. Andere Oberflächen, wie die Geräteausrichtung und die Akkustand-APIs, werden aktualisiert, um die Informationen so gering wie möglich zu halten.

Sicherheit von IP-Adressen

Ziel: Kontrolle des Zugriffs auf IP-Adressen, um verdecktes Fingerprinting zu reduzieren und Websites zu ermöglichen, die Anzeige von IP-Adressen zu deaktivieren, um das Datenschutzbudget nicht aufzubrauchen.

Die IP-Adresse eines Nutzers ist die öffentliche "Adresse" seines Computers im Internet, die in den meisten Fällen dynamisch vom Netzwerk zugewiesen wird, über das sie mit dem Internet verbunden sind. Allerdings können selbst dynamische IP-Adressen über einen längeren Zeitraum hinweg stabil bleiben. Daher überrascht es nicht, dass IP-Adressen eine wichtige Quelle für Fingerabdruckdaten sind.

Mit dem Gnatcatcher-Vorschlag soll ein datenschutzfreundlicher Ansatz entwickelt werden, mit dem eine Aufbrauchung des Datenschutzbudgets vermieden wird. Gleichzeitig soll dafür gesorgt werden, dass Websites, die Zugriff auf IP-Adressen zu legitimen Zwecken wie Missbrauchsprävention erfordern, dies tun können, vorbehaltlich einer Zertifizierung und Prüfung.

Der Vorschlag besteht aus zwei Teilen: * Willful IP Blindness bietet Websites die Möglichkeit, Browser darüber zu informieren, dass sie keine IP-Adressen mit Nutzern verbinden. * Nah-Path-NAT ermöglicht es Nutzergruppen, ihren Traffic über denselben privaten Server zu senden, wodurch ihre IP-Adressen vor einem Websitehost verborgen werden.

So bekämpfen Sie Spam, Betrug und Denial-of-Service-Angriffe

Ziel: Die Authentizität von Nutzern ohne Fingerprinting überprüfen.

Der Schutz vor Betrug ist entscheidend, um Nutzer zu schützen und sicherzustellen, dass Werbetreibende und Websiteinhaber genaue Messungen der Anzeigenleistung erhalten. Werbetreibende und Websiteinhaber müssen in der Lage sein, zwischen schädlichen Bots und echten Nutzern zu unterscheiden. Wenn Werbetreibende nicht zuverlässig erkennen können, welche Anzeigenklicks von echten Menschen stammen, geben sie weniger aus und Website-Publisher erhalten weniger Umsatz. Viele Drittanbieterdienste nutzen derzeit Techniken wie das Fingerprinting, um Betrug zu bekämpfen.

Leider funktionieren die Methoden, mit denen legitime Nutzer identifiziert und Spammer, Betrüger und Bots blockiert werden, ähnlich wie Fingerabdrucktechniken, die der Privatsphäre schaden.

  • Die Trust Tokens API schlägt einen alternativen Ansatz vor. Dabei kann die für einen Nutzer in einem Kontext – z. B. auf einer Social-Media-Website – festgestellte Authentizität in einen anderen Kontext übertragen werden, z. B. in einer Anzeige auf einer Nachrichtenwebsite, ohne dass der Nutzer identifiziert oder die beiden Identitäten verknüpft werden müssen.

Domains können demselben Erstanbieter gehören

Ziel:Entitäten ermöglichen, zu deklarieren, dass verwandte Domainnamen demselben Erstanbieter gehören.

Viele Organisationen haben Websites über mehrere Domains hinweg. Dies kann zu einem Problem werden, wenn für das Tracking der Nutzeridentität auf Websites, die als „Drittanbieter“ gelten, aber tatsächlich zu derselben Organisation gehören, Einschränkungen gelten.

  • Mit Erstanbieter-Sets sollen die im Web verwendeten Erst- und Drittanbieter-Konzepte enger an das der realen Welt angeglichen werden. Hierzu können mehrere Domains angeben, dass sie demselben Erstanbieter gehören.

Weitere Informationen

Erläuterung der Privacy Sandbox-Vorschläge

Die Privacy Sandbox-Initiative benötigt Ihre Unterstützung. Die Erklärungen des API-Vorschlags benötigen Feedback, insbesondere um fehlende Anwendungsfälle und Möglichkeiten für mehr Privatsphäre zu erörtern, wie sie ihre Ziele erreichen können.

Ein potenzielles Datenschutzmodell für das Web legt die grundlegenden Prinzipien fest, die den APIs zugrunde liegen.

Die Privacy Sandbox

Diskussion und Teilnahme

Anwendungsfälle, Richtlinien und Anforderungen

Anhang: Glossar der in den Erläuterung des Angebots verwendeten Begriffe

Klickrate (Click-through-Rate, CTR)

Der Anteil der Nutzer, die auf eine Anzeige klicken und sie gesehen haben. (Siehe auch Impression.)

Klick-Conversion

Eine Conversion, die einer Anzeige zugeordnet wurde, auf die geklickt wurde.

Conversion

Der Abschluss einer Aktion auf der Website eines Werbetreibenden durch einen Nutzer, der zuvor mit einer Anzeige dieses Werbetreibenden interagiert hat. Beispiel: Kauf eines Produkts oder Anmeldung für einen Newsletter, nachdem auf eine Anzeige geklickt wurde, die mit der Website des Werbetreibenden verlinkt ist.

Differential Privacy

Teilen von Informationen über ein Dataset, um Verhaltensmuster aufzudecken, ohne private Informationen über Einzelpersonen oder deren Zugehörigkeit zu diesem Dataset preiszugeben.

Domain

Siehe Top-Level-Domain und eTLD.

eTLD, eTLD+1

Aktive Top-Level-Domains sind in der Liste der öffentlichen Suffixe definiert. Beispiel:

co.uk
appspot.com
glitch.me

Effektive TLDs sorgen dafür, dass foo.appspot.com sich von bar.appspot.com unterscheidet. Die effektive Top-Level-Domain (eTLD) ist in diesem Fall appspot.com und der gesamte Websitename (foo.appspot.com, bar.appspot.com) wird als eTLD+1 bezeichnet.

Siehe auch Top-Level-Domain.

Entropie

Ein Maß dafür, wie stark ein Datenelement die individuelle Identität offenbart.

Die Datenentropie wird in Bit gemessen. Je mehr die Daten Identitäten offenbaren, desto höher ist der Entropiewert.

Daten können kombiniert werden, um eine Person zu identifizieren, aber es kann schwierig sein herauszufinden, ob neue Daten zur Entropie beitragen. Wenn beispielsweise bekannt ist, dass eine Person aus Australien stammt, verringert sich die Entropie nicht, wenn Sie bereits wissen, dass die Person von der Känguruinsel stammt.

Fingerabdruck

Techniken zur Identifizierung und Verfolgung des Verhaltens einzelner Nutzende. Bei der Fingerabdruckerkennung werden Mechanismen verwendet, die den Nutzern nicht bekannt sind und die sie nicht steuern können. Websites wie Panopticlick und amiunique.org zeigen, wie Fingerabdruckdaten zu persönlichen Identifizierungszwecken kombiniert werden können.

Oberfläche für Fingerabdruck

Etwas, das verwendet werden kann (wahrscheinlich in Kombination mit anderen Oberflächen), um einen bestimmten Nutzer oder ein bestimmtes Gerät zu identifizieren. So bieten beispielsweise die JavaScript-Methode navigator.userAgent() und der HTTP-Anfrageheader User-Agent Zugriff auf eine Fingerprinting-Oberfläche, d. h. den User-Agent-String.

Eigene

Ressourcen von der Website, die Sie besuchen. Ein Beispiel: Die Seite, die du dir gerade ansiehst, befindet sich auf der Website web.dev und enthält Ressourcen von dieser Website. Siehe auch Drittanbieter.

Impression

Ansicht einer Anzeige (Siehe auch Klickrate.)

k-Anonymität

Ein Maß der Anonymität innerhalb eines Datensatzes. Falls Ihre k-Anonymität vorliegt, können Sie nicht von k-1-anderen Personen im Datensatz unterschieden werden. Mit anderen Worten: k Personen haben dieselben Informationen (einschließlich Sie).

Nonce

Beliebige Nummer, die nur einmal für die kryptografische Kommunikation verwendet wird.

Ursprung

Der Ursprung einer Anfrage, einschließlich des Servernamens, aber ohne Pfadinformationen. Beispiel: https://web.dev.

Passive Oberfläche

Einige Fingerprinting-Oberflächen wie User-Agent-Strings, IP-Adressen und Accept-Sprach-Header sind für jede Website verfügbar, unabhängig davon, ob die Website danach fragt oder nicht. Das bedeutet, dass passive Oberflächen das Datenschutzbudget einer Website problemlos nutzen können.

Im Rahmen der Privacy Sandbox-Initiative wird vorgeschlagen, passive Oberflächen durch aktive Möglichkeiten zum Abrufen bestimmter Informationen zu ersetzen. So werden beispielsweise Clienthinweise einmalig verwendet, um die Sprache des Nutzers zu ermitteln, anstatt einen „Accept-language“-Header für jede Antwort an jeden Server zu haben.

Publisher

Bei den Erläuterungs zum Privacy Sandbox-Vorschlag geht es hauptsächlich um Werbung. Die Arten von Publishern, die hier erwähnt werden, sind also diejenigen, die Werbung auf ihren Websites platzieren.

Reichweite

Die Gesamtzahl der Nutzer, die eine Anzeige sehen.

Remarketing

Indem Sie Nutzer ansprechen, die Ihre Website bereits besucht haben Ein Onlineshop könnte beispielsweise für Nutzer, die sich zuvor Spielzeug auf seiner Website angesehen haben, Anzeigen für den Verkauf von Spielzeug präsentieren.

Website

Siehe Top-Level-Domain und eTLD.

Plattform/Oberfläche

Weitere Informationen finden Sie unter Fingerabdruckoberfläche und Passive Oberfläche.

Drittanbieter

Ressourcen, die von einer Domain bereitgestellt werden, die nicht die von Ihnen besuchte Website ist Beispielsweise könnte die Website foo.com Analytics-Code von google-analytics.com (über JavaScript), Schriftarten aus use.typekit.net (über ein Link-Element) und ein Video von vimeo.com (in einem iFrame) verwenden. Siehe auch Eigene.

Top-Level-Domain (TLD)

Top-Level-Domains wie .com und .org sind in der Root Zone Database aufgeführt.

Beachten Sie, dass einige „Websites“ eigentlich nur Subdomains sind. Zum Beispiel sind Translate.google.com und maps.google.com nur Subdomains von google.com (eTLD + 1).

.well-known

Es kann nützlich sein, auf Richtlinien oder andere Informationen zu einem Host zuzugreifen, bevor Sie eine Anfrage stellen. Beispielsweise teilt robots.txt Web-Crawlern mit, welche Seiten besucht und welche ignoriert werden sollen. IETF RFC8615 beschreibt eine standardisierte Möglichkeit, websiteweite Metadaten an Standardspeicherorten im Unterverzeichnis „/.well-known/“ verfügbar zu machen. Eine Liste dieser Fälle finden Sie unter iana.org/assignments/well-known-uris/well-known-uris.xhtml.

Vielen Dank an alle, die uns beim Verfassen und Überprüfen dieses Beitrags geholfen haben.

Foto von Pierre Bamin bei Unsplash.