Chrome 130 では、Shared Storage API が変更され、createWorklet() と addModule() でクロスオリジン ワークレット スクリプトを使用できるようになりました。また、Chrome 132 では、保存したクエリのサポートにより、Shared Storage を使用した Select URL API が更新されます。
Chrome 130 の Shared Storage API によるクロスオリジン ワークレット
Chrome 130 では、クロスオリジン ワークレット スクリプトをより柔軟に操作できるように、Shared Storage API に変更を加えました。
変更内容
addModule() の同一オリジン制限が削除されたため、任意のオリジンからワークレット スクリプトを読み込むことができるようになりました。クロスオリジン ワークレット スクリプトを使用すると、CDN でワークレット スクリプトをホストするなどの重要なユースケースが可能になります。ワークレット スクリプトが呼び出し元のブラウジング コンテキストと異なるオリジンの場合、共有ストレージへのアクセスに使用するデータ パーティションのオリジンとして、呼び出し元のコンテキストのオリジンが使用されます。
新しい addModule() の動作に合わせて、混乱を避けるため、createWorklet() 呼び出しに dataOrigin プロパティが追加され、呼び出し元のブラウジング コンテキストとは異なる共有ストレージ データ パーティションへの読み取りと書き込みが可能になりました。これにより、クロスオリジン ワークレット スクリプトを使用している場合でも、各ワークレットがアクセスするオリジンの共有ストレージをよりきめ細かく制御できます。
変更内容
Chrome 125 以降、ページ上のサードパーティのクロスオリジン スクリプトは、createWorklet(url) を呼び出すことで、クロスオリジン iframe を使用せずにクロスオリジン ワークレットを作成できます。以前は、createWorklet(url) は呼び出しコンテキストに関係なく、スクリプト URL（url）オリジンをデータ パーティションのオリジンとして使用していました。
Chrome 130 では、新しい addModule() の動作に合わせて、createWorklet() でも呼び出しコンテキストをデフォルトのデータパーティションのオリジンとして使用します。スクリプトの URL オリジンをデータパーティションのオリジンとして引き続き使用できるように、新しいプロパティ dataOrigin が導入され、データパーティションのオリジンを明示的に設定できるようになりました。
新しい dataOrigin プロパティは、データ パーティションのオリジンをスクリプトのオリジンとして設定する "script-origin" と、データ パーティションのオリジンを呼び出し元のブラウジング コンテキストのオリジンとして設定する "context-origin" を受け入れます。今後のリリースでは、カスタム データ パーティションのオリジンもサポートする予定です。これにより、ワークレット スクリプトは、オプトインに基づいて任意のオリジンから共有ストレージ データにアクセスできるようになります。
データ送信元が "script-origin" に設定されたクロスオリジン スクリプトを読み込むと、ブラウザから送信されるスクリプトのリクエストに "Sec-Shared-Storage-Data-Origin: <origin>" ヘッダーが含まれます。これを有効にするには、スクリプトに "Shared-Storage-Cross-Origin-Worklet-Allowed: ?1" オプトイン レスポンス ヘッダーも含める必要があります。
使用方法
ワークレットのデータパーティションのオリジンとしてスクリプト オリジンで createWorklet() をすでに使用している場合は、次のように dataOrigin を設定できます。
sharedStorage.createWorklet(scriptUrl, {dataOrigin: "script-origin"});
createWorklet() ではクロスオリジン データ パーティションの作成と複数のワークレットの作成が可能であるため、addModule() の使用から createWorklet() への移行をおすすめします。
これらの変更を反映し、詳細なガイダンスを提供するため、デベロッパー向けのドキュメントを更新しました。
Chrome 132 の Select URL API による保存したクエリ
Chrome 132 では、保存したクエリのサポートにより、Shared Storage を使用した Select URL API が更新されます。
変更点
現在、Select URL API には、ページ読み込みごとに API に対して実行される呼び出し数を制限する2 つのページ読み込みごとの予算があります。クエリをページごとに保存して再利用できる機能が導入されます。保存したクエリを使用する場合、ページ読み込みごとの予算は、保存したクエリが初めて実行されたときに課金されますが、同じページ読み込み中に保存したクエリが次回以降実行された場合は課金されません。
保存したクエリを実装する方法
Chrome 132 リリース以降では、selectURL() のオプションで savedQuery パラメータとクエリ名を使用できます。
await sharedStorage.selectURL('experiment', urls, {
savedQuery: 'control_or_experiment',
keepAlive: true
});
selectURL() の呼び出しごとに同じ savedQuery 名を使用して、フォローアップ クエリが同じ予算で課金されるようにします。
これらの変更を反映し、selectURL() の予算編成について詳しく説明するため、ドキュメントを更新しました。
意見交換とフィードバックの提供
Shared Storage API の提案は現在議論と開発が進められているため、変更される可能性があります。
Shared Storage API について、ぜひご意見をお聞かせください。
- 提案書: 詳細な提案書を確認します。
- ディスカッション: 進行中のディスカッションに参加して、質問したり、分析情報を共有したりできます。
最新情報を入手する
- メーリング リスト: メーリング リストに登録すると、Shared Storage API に関する最新情報やお知らせを受け取ることができます。
ご不明な点がある場合
- デベロッパー サポート: プライバシー サンドボックス デベロッパー サポート リポジトリで他のデベロッパーと交流し、質問に答えてもらうことができます。