Aktualisierungen bei Shared Storage und ausgewählten URLs: plattformübergreifende Worklets und gespeicherte Abfragen

Tara Agyemang

In Chrome 130 wurden Änderungen an der Shared Storage API vorgenommen, um die Verwendung von Worklet-Scripts mit unterschiedlichen Ursprüngen mit createWorklet() und addModule() zu ermöglichen. Außerdem führen wir in Chrome 132 Updates für die Select URL API mit Shared Storage ein, die die Unterstützung gespeicherter Abfragen umfasst.

Mit der Shared Storage API können registrierte Websites beliebige Schlüssel/Wert-Daten in den Shared Storage schreiben. Das Lesen der Daten ist jedoch auf bestimmte Ausgabe-APIs beschränkt.

Cross-Origin-Worklets mit der Shared Storage API in Chrome 130

Wir haben in Chrome 130 Änderungen an der Shared Storage API vorgenommen, um Ihnen mehr Flexibilität bei der Arbeit mit plattformübergreifenden Worklet-Scripts zu bieten.

Änderungen

Wir haben die Same-Origin-Einschränkung für addModule() aufgehoben. Sie können jetzt Worklet-Scripts von jeder Quelle laden. Mit plattformübergreifenden Worklet-Scripts können wichtige Anwendungsfälle wie das Hosten von Worklet-Scripts in CDNs realisiert werden. Wenn das Worklet-Script eine andere Quelle als der aufrufende Browserkontext hat, wird die Quelle des aufrufenden Kontexts als Ursprung der Datenpartition für den Zugriff auf den freigegebenen Speicher verwendet.

Um dem neuen Verhalten von addModule() zu entsprechen und mögliche Verwirrung zu vermeiden, wurde dem createWorklet()-Aufruf die Property dataOrigin hinzugefügt. So können Daten in einer freigegebenen Speicherdatenpartition gelesen und geschrieben werden, die sich vom aufrufenden Browserkontext unterscheidet. So haben Sie eine genauere Kontrolle darüber, auf den gemeinsamen Speicher welcher Quelle jedes Worklet zugreift, auch wenn Sie plattformübergreifende Worklet-Scripts verwenden.

Wie hat sich das verändert?

Ab Chrome 125 können mit einem plattformübergreifenden Script eines Drittanbieters auf einer Seite plattformübergreifende Worklets erstellt werden, ohne dass plattformübergreifende iframes erforderlich sind. Dazu wird createWorklet(url) aufgerufen. Bisher wurde bei createWorklet(url) unabhängig vom Aufrufkontext die URL der Scriptdatei (url) als Ursprung der Datenpartition verwendet.

In Chrome 130 wird für createWorklet() der Aufrufkontext als Standardursprung der Datenpartition verwendet, um dem neuen Verhalten von addModule() zu entsprechen. Damit Sie weiterhin die Script-URL-Quelle als Datenpartitionsquelle verwenden können, wird die neue Property dataOrigin eingeführt, mit der Sie den Ursprung der Datenpartition explizit festlegen können.

Für die neue Property dataOrigin ist "script-origin" zulässig. Damit wird der Ursprung der Datenpartition als Ursprung des Scripts festgelegt. Mit "context-origin" wird der Ursprung der Datenpartition als Ursprung des aufgerufenen Browser-Kontexts festgelegt. In einer zukünftigen Version planen wir auch die Unterstützung benutzerdefinierter Datenpartitionsquellen, bei denen ein Worklet-Script auf freigegebene Speicherdaten aus einer beliebigen Quelle zugreifen kann.

Beim Laden eines plattformübergreifenden Scripts, bei dem der Datenursprung auf "script-origin" festgelegt ist, enthält die vom Browser gesendete Anfrage für das Script einen "Sec-Shared-Storage-Data-Origin: <origin>"-Header. Dazu muss das Script auch den Antwortheader "Shared-Storage-Cross-Origin-Worklet-Allowed: ?1" für die Einwilligung enthalten.

Verwendung

Wenn Sie createWorklet() bereits mit dem Script-Ursprung als Ursprung der Datenpartition des Worklets verwenden, können Sie dataOrigin so festlegen:

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

Da mit createWorklet() eine datenübergreifende Partition und mehrere Worklets erstellt werden können, empfehlen wir Ihnen, createWorklet() anstelle von addModule() zu verwenden.

Wir haben die Entwicklerleitfäden entsprechend aktualisiert und um weitere Informationen ergänzt.

Gespeicherte Abfragen mit der Select URL API in Chrome 132

Wir führen in Chrome 132 Updates für die Select URL API mit Shared Storage ein, die die Unterstützung gespeicherter Abfragen umfassen.

Was ändert sich?

Die Select URL API hat derzeit zwei Budgets pro Seitenladevorgang, die die Anzahl der API-Aufrufe bei jedem Seitenladevorgang begrenzen. Wir führen die Möglichkeit ein, Abfragen pro Seite zu speichern und wiederzuverwenden. Wenn Sie eine gespeicherte Abfrage verwenden, werden die Budgets pro Seitenladevorgang beim ersten Ausführen der gespeicherten Abfrage berechnet, nicht aber bei nachfolgenden Ausführungen der gespeicherten Abfrage während desselben Seitenladevorgangs.

Gespeicherte Abfragen implementieren

Ab der Version 132 von Chrome können Sie den Parameter savedQuery in den Optionen für selectURL() mit dem Namen der Abfrage verwenden:

await sharedStorage.selectURL('experiment', urls, {
  savedQuery: 'control_or_experiment',
  keepAlive: true
});

Verwenden Sie für jeden Aufruf von selectURL() denselben savedQuery-Namen, damit Folgeabfragen demselben Budget in Rechnung gestellt werden.

Wir haben die Dokumentation entsprechend aktualisiert und zusätzliche Informationen zum Budget für selectURL() hinzugefügt.

互动和分享反馈

请注意，Shared Storage API 提案正在积极讨论和开发中，因此可能会发生变化。

我们非常期待听到您对 Shared Storage API 的看法。

• 提案：查看详细提案。
• 讨论：加入持续讨论，提出问题并分享您的见解。

掌握最新动态

• 邮寄名单：订阅我们的邮寄名单，及时了解与 Shared Storage API 相关的最新动态和公告。

需要帮助？

• 开发者支持：在 Privacy Sandbox 开发者支持代码库中与其他开发者联系，并获取问题解答。