Kurzanleitung zur Implementierung von freigegebenem Speicher und privater Aggregation

Dieses Dokument ist eine Kurzanleitung für die Verwendung von Shared Storage und Private Aggregation. Sie benötigen Kenntnisse beider APIs, da im Shared Storage die Werte gespeichert und mit der Private Aggregation API aggregierbare Berichte erstellt werden.

Zielgruppe:Anbieter von Anzeigentechnologien und Analysen

Shared Storage API

Um websiteübergreifendes Tracking zu verhindern, partitionieren Browser alle Arten von Speicher, einschließlich des lokalen Speichers und von Cookies. Es gibt jedoch Anwendungsfälle, in denen nicht partitionierter Speicher erforderlich ist. Die Shared Storage API bietet unbegrenzten Schreibzugriff auf verschiedene Websites der obersten Ebene mit datenschutzfreundlichem Lesezugriff.

Shared Storage ist auf den Kontextursprung (den Aufrufer von sharedStorage) beschränkt.

Shared Storage hat ein Kapazitätslimit pro Herkunft. Jeder Eintrag ist auf eine maximale Anzahl von Zeichen beschränkt. Wenn das Limit erreicht ist, werden keine weiteren Eingaben gespeichert. Die Beschränkungen für die Datenspeicherung sind im Shared Storage-Explainer beschrieben.

Shared Storage aufrufen

Ad-Tech-Unternehmen können mit JavaScript oder einem Antwort-Header in Shared Storage schreiben. Das Lesen aus Shared Storage erfolgt nur in einer isolierten JavaScript-Umgebung, einem sogenannten Worklet.

• JavaScript verwenden: Ad-Tech-Unternehmen können bestimmte Shared Storage-Funktionen wie das Festlegen, Anhängen und Löschen von Werten außerhalb eines JavaScript-Worklets ausführen. Funktionen wie das Lesen von Shared Storage und das Ausführen von Private Aggregation müssen jedoch über ein JavaScript-Worklet ausgeführt werden. Methoden, die außerhalb eines JavaScript-Worklets verwendet werden können, finden Sie unter Proposed API Surface - Outside the worklet.

  Methoden, die während eines Vorgangs im Worklet verwendet werden, finden Sie unter Proposed API Surface - In the worklet.

• Antwortheader verwenden

  Ähnlich wie bei JavaScript können nur bestimmte Funktionen wie das Festlegen, Anhängen und Löschen von Werten im Shared Storage über Antwortheader ausgeführt werden. Wenn Sie Shared Storage in einem Antwortheader verwenden möchten, muss Shared-Storage-Writable: ?1 im Anfrageheader enthalten sein.

  Führen Sie den folgenden Code aus, um eine Anfrage vom Client aus zu starten. Das hängt von der gewählten Methode ab:

  • fetch() verwenden

    fetch("https://a.example/path/for/updates", {sharedStorageWritable: true});
    

  • iframe- oder img-Tag verwenden

    <iframe src="https://a.example/path/for/updates" sharedstoragewritable></iframe>
    

  • IDL-Attribut mit einem iframe- oder img-Tag verwenden

    let iframe = document.getElementById("my-iframe");
    iframe.sharedStorageWritable = true;
    iframe.src = "https://a.example/path/for/updates";
    

Weitere Informationen finden Sie unter Shared Storage: Response Headers (Gemeinsam genutzter Speicher: Antwortheader).

In Shared Storage schreiben

Wenn Sie in Shared Storage schreiben möchten, rufen Sie sharedStorage.set() innerhalb oder außerhalb eines JavaScript-Worklets auf. Wenn der Aufruf von außerhalb des Worklets erfolgt, werden die Daten in den Ursprung des Browsing-Kontexts geschrieben, aus dem der Aufruf stammt. Wenn der Aufruf aus dem Worklet erfolgt, werden die Daten in den Ursprung des Browsing-Kontexts geschrieben, der das Worklet geladen hat. Die gesetzten Schlüssel haben ein Ablaufdatum von 30 Tagen ab der letzten Aktualisierung.

Das Feld ignoreIfPresent ist optional. Wenn vorhanden und auf true gesetzt, wird der Schlüssel nicht aktualisiert, wenn er bereits vorhanden ist. Die Gültigkeit des Schlüssels wird auf 30 Tage ab dem set()-Aufruf verlängert, auch wenn der Schlüssel nicht aktualisiert wird.

Wenn im selben Seitenaufbau mit demselben Schlüssel mehrmals auf den freigegebenen Speicher zugegriffen wird, wird der Wert für den Schlüssel überschrieben. Es empfiehlt sich, sharedStorage.append() zu verwenden, wenn der Schlüssel den vorherigen Wert beibehalten soll.

• JavaScript verwenden

  Außerhalb des Worklets:

  window.sharedStorage.set('myKey', 'myValue1', { ignoreIfPresent: true });
  // Shared Storage: {'myKey': 'myValue1'}
  window.sharedStorage.set('myKey', 'myValue2', { ignoreIfPresent: true });
  // Shared Storage: {'myKey': 'myValue1'}
  window.sharedStorage.set('myKey', 'myValue2', { ignoreIfPresent: false });
  // Shared Storage: {'myKey': 'myValue2'}
  

  Im Worklet gilt Ähnliches:

  sharedStorage.set('myKey', 'myValue1', { ignoreIfPresent: true });
  

• Antwortheader verwenden

  Sie können auch mithilfe von Antwortheadern in den freigegebenen Speicher schreiben. Verwenden Sie dazu Shared-Storage-Write im Antwortheader zusammen mit den folgenden Befehlen:

  Shared-Storage-Write : set;key="myKey";value="myValue";ignore_if_present
  

  Shared-Storage-Write : set;key="myKey";value="myValue";ignore_if_present=?0
  

  Mehrere Elemente können durch Kommas getrennt werden und set, append, delete und clear kombinieren.

  Shared-Storage-Write :
  set;key="hello";value="world";ignore_if_present, set;key="good";value="bye"
  

Wert anhängen

Mit der Methode „append“ können Sie einem vorhandenen Schlüssel einen Wert hinzufügen. Wenn der Schlüssel nicht vorhanden ist, wird er durch den Aufruf von append() erstellt und der Wert wird festgelegt. Dies kann mit JavaScript oder einem Antwortheader erreicht werden.

• JavaScript verwenden

  Verwenden Sie sharedStorage.append() innerhalb oder außerhalb des Worklets, um Werte vorhandener Schlüssel zu aktualisieren.

  window.sharedStorage.append('myKey', 'myValue1');
  // Shared Storage: {'myKey': 'myValue1'}
  window.sharedStorage.append('myKey', 'myValue2');
  // Shared Storage: {'myKey': 'myValue1myValue2'}
  window.sharedStorage.append('anotherKey', 'hello');
  // Shared Storage: {'myKey': 'myValue1myValue2', 'anotherKey': 'hello'}
  

  So hängen Sie Daten im Worklet an:

  sharedStorage.append('myKey', 'myValue1');
  

• Antwortheader verwenden

  Ähnlich wie beim Festlegen eines Werts im Shared Storage können Sie das Schlüssel/Wert-Paar mit dem Shared-Storage-Write im Antwortheader übergeben.

  Shared-Storage-Write : append;key="myKey";value="myValue2"
  

Werte im Batch aktualisieren

Sie können sharedStorage.batchUpdate() innerhalb oder außerhalb eines JavaScript-Worklets aufrufen und ein geordnetes Array von Methoden übergeben, die die ausgewählten Vorgänge angeben. Jeder Methodenkonstruktor akzeptiert dieselben Parameter wie die entsprechende einzelne Methode für „set“, „append“, „delete“ und „clear“.

Sie können batchUpdate() über JavaScript aufrufen oder einen Antwortheader verwenden:

• JavaScript verwenden

  Folgende JavaScript-Methoden können mit batchUpdate() verwendet werden:

  • SharedStorageSetMethod(): Schreibt ein Schlüssel/Wert-Paar in den gemeinsam genutzten Speicher.
  • SharedStorageAppendMethod(): Fügt einem vorhandenen Schlüssel im Shared Storage einen Wert hinzu oder schreibt ein Schlüssel/Wert-Paar, wenn der Schlüssel noch nicht vorhanden ist.
  • SharedStorageDeleteMethod(): Löscht ein Schlüssel/Wert-Paar aus dem gemeinsam genutzten Speicher.
  • SharedStorageClearMethod(): Löscht alle Schlüssel im Shared Storage.

  sharedStorage.batchUpdate([
  new SharedStorageSetMethod('keyOne', 'valueOne'),
  new SharedStorageAppendMethod('keyTwo', 'valueTwo'),
  new SharedStorageDeleteMethod('keyThree'),
  new SharedStorageClearMethod()
  ]);
  

• Antwortheader verwenden

  Shared-Storage-Write : set;key=keyOne;value=valueOne, append;key=keyTwo;value=valueTwo,delete;key=keyThree,clear
  

Wenn Sie Antwortheader verwenden, wird batchUpdate() für alle Methoden im Header ausgeführt.

Aus dem freigegebenen Speicher lesen

Sie können nur aus Shared Storage lesen, wenn Sie sich in einem Worklet befinden.

await sharedStorage.get('mykey');

Der Ursprung des Browsing-Kontexts, aus dem das Worklet-Modul geladen wurde, bestimmt, wessen Shared Storage gelesen wird.

Aus Shared Storage löschen

Sie können Löschvorgänge aus dem Shared Storage mit JavaScript entweder innerhalb oder außerhalb des Worklets oder mit Antwort-Headern mit delete() ausführen. Wenn Sie alle Schlüssel gleichzeitig löschen möchten, verwenden Sie clear().

• JavaScript verwenden

  So löschen Sie Daten aus Shared Storage außerhalb des Worklets:

  window.sharedStorage.delete('myKey');
  

  So löschen Sie Daten aus Shared Storage aus dem Worklet heraus:

  sharedStorage.delete('myKey');
  

  So löschen Sie alle Schlüssel gleichzeitig außerhalb des Worklets:

  window.sharedStorage.clear();
  

  So löschen Sie alle Schlüssel gleichzeitig aus dem Worklet:

  sharedStorage.clear();
  

• Antwortheader verwenden

  Wenn Sie Werte mithilfe von Antwortheadern löschen möchten, können Sie auch Shared-Storage-Write im Antwortheader verwenden, um den zu löschenden Schlüssel zu übergeben.

  delete;key="myKey"
  

  So löschen Sie alle Schlüssel mithilfe von Antwortheadern:

  clear;
  

Protected Audience-Interessengruppen aus Shared Storage lesen

Sie können die Interessengruppen von Protected Audience aus einem Shared Storage-Worklet lesen. Die Methode interestGroups() gibt ein Array von StorageInterestGroup-Objekten zurück, einschließlich der Attribute AuctionInterestGroup und GenerateBidInterestGroup.

Im folgenden Beispiel wird gezeigt, wie Sie die Interessengruppen des Browserkontexts lesen und einige mögliche Vorgänge ausführen können, die für die abgerufenen Interessengruppen ausgeführt werden können. Zwei mögliche Vorgänge sind das Ermitteln der Anzahl der Interessengruppen und das Ermitteln der Interessengruppe mit der höchsten Anzahl von Geboten.

async function analyzeInterestGroups() {
  const interestGroups = await interestGroups();
  numIGs = interestGroups.length;
  maxBidCountIG = interestGroups.reduce((max, cur) => { return cur.bidCount > max.bidCount ? cur : max; }, interestGroups[0]);
  console.log("The IG that bid the most has name " + maxBidCountIG.name);
}

Der Ursprung des Browsing-Kontexts, aus dem das Worklet-Modul geladen wurde, bestimmt den Ursprung der Interessengruppen, die standardmäßig gelesen werden. Weitere Informationen zum Standardursprung des Worklets und dazu, wie Sie ihn ändern können, finden Sie im Abschnitt „Shared Storage und Private Aggregation ausführen“ im Shared Storage API-Walkthrough.

Optionen

Alle Shared Storage-Modifikatormethoden unterstützen ein optionales Optionenobjekt als letztes Argument.

withLock

Die Option withLock ist optional. Wenn diese Option angegeben ist, wird die Methode angewiesen, vor dem Fortfahren mit der Web Locks API eine Sperre für die definierte Ressource zu erwerben. Beim Anfordern des Schlosses wird ein Schlossname übergeben. Der Name steht für eine Ressource, deren Nutzung über mehrere Tabs, Worker oder Code innerhalb des Ursprungs koordiniert wird.

Die Option withLock kann mit den folgenden Methoden zum Ändern des freigegebenen Speichers verwendet werden:

• set
• append
• Löschen
• löschen
• Batch-Update

Sie können die Sperre mit JavaScript oder einem Antwortheader festlegen:

• JavaScript verwenden

  sharedStorage.set('myKey', 'myValue', { withLock: 'myResource' });
  

• Antwortheader verwenden

  Shared-Storage-Write : set;key="myKey";value="myValue",options;with_lock="myResource"
  

Shared Storage-Sperren werden nach dem Datenursprung partitioniert. Die Sperren sind unabhängig von allen Sperren, die mit der LockManager-Methode request() abgerufen werden, unabhängig davon, ob sie sich in einem window- oder worker-Kontext befinden. Sie haben jedoch denselben Umfang wie Sperren, die mit request() im Kontext von SharedStorageWorklet abgerufen werden.

Die request()-Methode bietet zwar verschiedene Konfigurationsoptionen, für Sperren, die im gemeinsamen Speicher erworben wurden, gelten jedoch immer die folgenden Standardeinstellungen:

• mode: "exclusive": Es können keine anderen Sperren mit demselben Namen gleichzeitig gehalten werden.
• steal: false: Vorhandene Sperren mit demselben Namen werden nicht freigegeben, um anderen Anfragen Rechnung zu tragen.
• ifAvailable: false: Die Anfragen warten unbegrenzt, bis die Sperre verfügbar ist.

Verwendung von withLock

Sperren sind in Szenarien nützlich, in denen möglicherweise mehrere Worklets gleichzeitig ausgeführt werden (z.B. mehrere Worklets auf einer Seite oder mehrere Worklets auf verschiedenen Tabs), die jeweils auf dieselben Daten zugreifen. In diesem Fall ist es ratsam, den relevanten Worklet-Code mit einer Sperre zu umschließen, damit jeweils nur ein Worklet Berichte verarbeitet.

Sperren sind auch dann nützlich, wenn in einem Worklet mehrere Schlüssel gleichzeitig gelesen werden müssen und ihr Status synchronisiert werden soll. In diesem Fall sollten die get-Aufrufe mit einer Sperre umschlossen werden. Außerdem muss dieselbe Sperre beim Schreiben in diese Schlüssel abgerufen werden.

Reihenfolge der Sperren

Aufgrund der Funktionsweise von Web Locks werden Modifikatormethoden möglicherweise nicht in der von Ihnen definierten Reihenfolge ausgeführt. Wenn für den ersten Vorgang eine Sperre erforderlich ist und er sich verzögert, kann der zweite Vorgang beginnen, bevor der erste abgeschlossen ist.

Beispiel:

// This line might pause until the lock is available.
sharedStorage.set('keyOne', 'valueOne', { withLock: 'resource-lock' });

// This line will run right away, even if the first one is still waiting.
sharedStorage.set('keyOne', 'valueTwo');

Beispiel für das Ändern mehrerer Schlüssel

Die Option withLock mit batchUpdate() sorgt für den gegenseitigen Ausschluss mit anderen gleichzeitigen Vorgängen, die dieselbe Sperre erhalten. Sie können die Option withLock für batchUpdate() nur auf den gesamten Batch anwenden. Wenn Sie withLock auf ein einzelnes Methodenobjekt im Batch anwenden, wird eine Ausnahme ausgelöst.

In diesem Beispiel wird eine Sperre verwendet, um sicherzustellen, dass die Lese- und Löschvorgänge im Worklet gleichzeitig erfolgen und Störungen von außerhalb des Worklets verhindert werden.

Im folgenden modify-multiple-keys.js-Beispiel werden mit modify-lock neue Werte für keyOne und keyTwo festgelegt. Anschließend wird der modify-multiple-keys-Vorgang aus dem Worklet ausgeführt:

// modify-multiple-keys.js
sharedStorage.batchUpdate([
    new SharedStorageSetMethod('keyOne', calculateValueFor('keyOne')),
    new SharedStorageSetMethod('keyTwo', calculateValueFor('keyTwo'))
], { withLock: 'modify-lock' });

const modifyWorklet = await sharedStorage.createWorklet('modify-multiple-keys-worklet.js');
await modifyWorklet.run('modify-multiple-keys');

Innerhalb von modify-multiple-keys-worklet.js können Sie dann mit navigator.locks.request() das Sperren anfordern, um die Schlüssel nach Bedarf zu lesen und zu ändern.

// modify-multiple-keys-worklet.js
class ModifyMultipleKeysOperation {
  async run(data) {
    await navigator.locks.request('modify-lock', async (lock) => {
      const value1 = await sharedStorage.get('keyOne');
      const value2 = await sharedStorage.get('keyTwo');

      // Do something with `value1` and `value2` here.

      await sharedStorage.delete('keyOne');
      await sharedStorage.delete('keyTwo');
    });
  }
}
register('modify-multiple-keys', ModifyMultipleKeysOperation);

Kontextwechsel

Shared Storage-Daten werden in den Ursprung (z. B. https://example.adtech.com) des Browsing-Kontexts geschrieben, aus dem der Aufruf stammt.

Wenn Sie den Drittanbietercode mit einem <script>-Tag laden, wird der Code im Browsing-Kontext des Einbettungselements ausgeführt. Wenn also im Drittanbietercode sharedStorage.set() aufgerufen wird, werden die Daten in den Shared Storage des Einbettungsprogramms geschrieben. Wenn Sie den Drittanbietercode in einem iFrame laden, erhält der Code einen neuen Browserkontext und sein Ursprung ist der Ursprung des iFrames. Daher werden die Daten durch den sharedStorage.set()-Aufruf aus dem iFrame im Shared Storage des iFrame-Ursprungs gespeichert.

Kontext von selbst erhobenen Daten

Wenn auf einer eigenen Seite JavaScript-Drittanbietercode eingebettet ist, der sharedStorage.set() oder sharedStorage.delete() aufruft, wird das Schlüssel/Wert-Paar im eigenen Kontext gespeichert.

Drittanbieterkontext

Das Schlüssel/Wert-Paar kann im Ad-Tech- oder Drittanbieterkontext gespeichert werden, indem ein iFrame erstellt und set() oder delete() im JavaScript-Code innerhalb des iFrames aufgerufen wird.

Private Aggregation API

Mit der Private Aggregation API können Sie aggregierbare Daten messen, die in Shared Storage gespeichert sind.

Wenn Sie einen Bericht erstellen möchten, rufen Sie contributeToHistogram() in einem Worklet mit einem Bucket und einem Wert auf. Der Bucket wird durch eine vorzeichenlose 128-Bit-Ganzzahl dargestellt, die als BigInt an die Funktion übergeben werden muss. Der Wert ist eine positive Ganzzahl.

Aus Datenschutzgründen wird die Nutzlast des Berichts, die den Bucket und den Wert enthält, bei der Übertragung verschlüsselt. Sie kann nur mit dem Aggregationsdienst entschlüsselt und zusammengefasst werden.

Der Browser schränkt auch die Beiträge ein, die eine Website zu einer Ausgabefrage leisten kann. Das Beitragsbudget begrenzt die Gesamtzahl aller Berichte einer einzelnen Website für einen bestimmten Browser in einem bestimmten Zeitfenster über alle Buckets hinweg. Wenn das aktuelle Budget überschritten wird, wird kein Bericht erstellt.

privateAggregation.contributeToHistogram({
  bucket: BigInt(myBucket),
  value: parseInt(myBucketValue)
});

Shared Storage und Private Aggregation ausführen

Wenn Sie den freigegebenen Speicher mit createWorklet() verwenden, ist der Ursprung der Datenpartition standardmäßig der Ursprung des aufrufenden Browsing-Kontexts und nicht der Ursprung des Worklet-Scripts selbst.

Wenn Sie das Standardverhalten ändern möchten, legen Sie die Eigenschaft dataOrigin beim Aufrufen von createWorklet fest.

• dataOrigin: "context-origin": (Standard) Daten werden im freigegebenen Speicher des Ursprungs des aufrufenden Browserkontexts gespeichert.
• dataOrigin: "script-origin": Daten werden im freigegebenen Speicher des Ursprungs des Worklet-Scripts gespeichert. Zum Aktivieren dieses Modus ist eine Einwilligung erforderlich.
• dataOrigin: "https://custom-data-origin.example": Daten werden im freigegebenen Speicher eines benutzerdefinierten Datenursprungs gespeichert. Für die Aktivierung dieses Modus ist eine Einwilligung erforderlich. Außerdem ist die Einwilligung des Inhabers der benutzerdefinierten Datenquelle erforderlich, wie unter Benutzerdefinierte Datenquelle beschrieben.

sharedStorage.createWorklet(scriptUrl, {dataOrigin: "script-origin"});

Wenn Sie "script-origin" oder einen benutzerdefinierten Ursprung verwenden, muss der Skriptendpunkt mit dem Header Shared-Storage-Cross-Origin-Worklet-Allowed antworten, um die Funktion zu aktivieren. Für ursprungsübergreifende Anfragen muss auch CORS aktiviert sein.

Shared-Storage-Cross-Origin-Worklet-Allowed : ?1
Access-Control-Allow-Origin: *

Sie können auch ursprungsübergreifende Skripts mit einem Drittanbieter-iFrame ausführen. In diesem Fall erfolgen Shared Storage-Aktionen im Browserkontext des Drittanbieters.

Cross-Origin-iFrame verwenden

Zum Aufrufen des Shared Storage-Worklets ist ein iFrame erforderlich.

Laden Sie das Worklet-Modul im Iframe der Anzeige, indem Sie addModule() aufrufen. Rufen Sie sharedStorage.run() im JavaScript des Anzeigen-iFrames auf, um die Methode auszuführen, die in der Worklet-Datei sharedStorageWorklet.js registriert ist.

const sharedStorageWorklet = await window.sharedStorage.createWorklet(
  'https://any-origin.example/modules/sharedStorageWorklet.js'
);
await sharedStorageWorklet.run('shared-storage-report', {
  data: { campaignId: '1234' },
});

Im Worklet-Script müssen Sie eine Klasse mit einer asynchronen run-Methode erstellen und register, damit sie im Iframe der Anzeige ausgeführt wird. Innen sharedStorageWorklet.js:

class SharedStorageReportOperation {
  async run(data) {
    // Other code goes here.
    bucket = getBucket(...);
    value = getValue(...);
    privateAggregation.contributeToHistogram({
      bucket,
      value
    });
  }
}
register('shared-storage-report', SharedStorageReportOperation);

Ursprungsübergreifende Anfrage verwenden

Mit Shared Storage und Private Aggregation können ursprungsübergreifende Worklets ohne ursprungsübergreifende iFrames erstellt werden.

Auf der eigenen Seite kann auch ein createWorklet()-Aufruf an den JavaScript-Endpunkt für ursprungsübergreifende Anfragen erfolgen. Beim Erstellen des Worklets müssen Sie den Ursprung der Datenpartition des Worklets auf den Ursprung des Skripts festlegen.

async function crossOriginCall() {
  const privateAggregationWorklet = await sharedStorage.createWorklet(
    'https://cross-origin.example/js/worklet.js',
    { dataOrigin: 'script-origin' }
  );
  await privateAggregationWorklet.run('pa-worklet');
}
crossOriginCall();

Der JavaScript-Endpunkt für Cross-Origin-Anfragen muss mit den Headern Shared-Storage-Cross-Origin-Worklet-Allowed antworten und angeben, dass CORS für die Anfrage aktiviert ist.

Shared-Storage-Cross-Origin-Worklet-Allowed : ?1

Worklets, die mit createWorklet() erstellt wurden, haben selectURL und run(). addModule() ist dafür nicht verfügbar.

class CrossOriginWorklet {
  async run(data){
    // Other code goes here.
    bucket = getBucket(...);
    value = getValue(...);
    privateAggregation.contributeToHistogram({
      bucket,
      value
    });
  }
}

Benutzerdefinierte Datenquelle

Wenn dataOrigin auf einen gültigen Ursprung festgelegt ist, muss der Inhaber von dataOrigin der Verarbeitung von Shared Storage für diesen dataOrigin zustimmen, indem er eine JSON-Datei mit dem Ursprung des Worklet-Skripts unter dem Pfad /.well-known/shared-storage/trusted-origins hostet. Die Datei sollte ein Array von Objekten mit den Schlüsseln scriptOrigin und contextOrigin sein. Die Werte für diese Schlüssel können entweder ein String oder ein Array von Strings sein.

Erstellen Sie die trusted-origins-Datei mit den folgenden Informationen:

• Kontext des Anrufers
• Ursprung und URL des Worklet-Skripts
• Datenquelle und ‑inhaber

Die folgende Tabelle zeigt, wie Sie die trusted-origins-Datei auf Grundlage dieser Informationen erstellen können:

[{
  "scriptOrigin": "https://cdn-ad.example",
  "contextOrigin": "https://publisher.example"
}]
      

[{
  "scriptOrigin": "https://cdn-ad.example",
  "contextOrigin": "*"
}]
      

[{
  "scriptOrigin": "https://cdn-ad.example",
  "contextOrigin": [
      "https://publisher-a.example",
      "https://publisher-b.example"
  ]
}]
      

[{
  "scriptOrigin": [
    "https://cdn-a-ad.example",
    "https://cdn-b-ad.example"
  ],
  "contextOrigin": "https://publisher.example"
}]
      

Der folgende JSON-Code kann beispielsweise unter https://custom-data-origin.example/.well-known/shared-storage/trusted-origins gehostet werden und alle zulässigen Prozessoren von Shared Storage-Daten für den Ursprung https://custom-data-origin.example kombinieren.

[
  {
    "scriptOrigin": "https://script-origin.a.example",
    "contextOrigin": "https://context-origin.a.example"
  },
  {
    "scriptOrigin": "https://script-origin.b.example",
    "contextOrigin": [
      "https://context-origin.a.example",
      "https://context-origin.b.example"
    ]
}]

Nächste Schritte

Auf den folgenden Seiten werden wichtige Aspekte der Shared Storage API und der Private Aggregation API erläutert.

• Einführung in Shared Storage (Developer Chrome)
• Anwendungsfälle für Shared Storage (Developer Chrome)
• Einführung in Private Aggregation (Developer Chrome)
• Shared Storage Explainer (GitHub)
• Private Aggregation Explainer (GitHub)
• Demo zu Shared Storage und Private Aggregation

Sobald Sie sich mit den APIs vertraut gemacht haben, können Sie mit dem Erfassen der Berichte beginnen. Diese werden als POST-Anfrage an die folgenden Endpunkte als JSON im Anfragetext gesendet.

• Debug-Berichte – context-origin/.well-known/private-aggregation/debug/report-shared-storage
• Berichte – context-origin/.well-known/private-aggregation/report-shared-storage

Sobald Berichte erfasst wurden, können Sie sie mit dem Tool für lokale Tests testen oder die Trusted Execution Environment for Aggregation Service einrichten, um die aggregierten Berichte zu erhalten.

Feedback geben

Sie können Ihr Feedback zu den APIs und der Dokumentation auf GitHub teilen.

• Shared Storage
• Private Aggregation