Storage Access API

ブラウザ、ユーザー設定、ストレージ パーティショニングによるサードパーティ Cookie のブロックは、認証などのユーザー ジャーニーで埋め込みコンテキストの Cookie やその他のストレージに依存するサイトやサービスにとって課題となっています。Storage Access API（SAA）を使用すると、これらのユースケースを継続して機能させながら、サイト間トラッキングを可能な限り制限できます。

実装ステータス

Storage Access API はすべての主要なブラウザで利用できますが、ブラウザ間で実装に若干の違いがあります。これらの違いについては、この投稿の関連するセクションで説明しています。

API を標準化する前に、残りのブロックの問題をすべて解決する作業が継続されています。

Storage Access API とは何ですか？

Storage Access API は、ブラウザ設定によってアクセスが拒否される場合に、iframes からストレージのアクセス権限をリクエストできるようにする JavaScript API です。クロスサイト リソースの読み込みに依存するユースケースを含む埋め込みは、必要に応じて API を使用してユーザーにアクセス権限をリクエストできます。

ストレージ リクエストが許可されると、iframe はパーティション化されていない Cookie とストレージにアクセスできるようになります。これらは、ユーザーがトップレベル サイトとしてアクセスした場合にも利用できます。

Storage Access API を使用すると、エンドユーザーへの負担を最小限に抑えながら、特定のパーティション化されていない Cookie とストレージへのアクセスを提供できます。同時に、ユーザー トラッキングによく使用される一般的なパーティション化されていない Cookie とストレージへのアクセスは防止されます。

ユースケース

一部のサードパーティ埋め込みでは、ユーザー エクスペリエンスを向上させるために、パーティショニングされていない Cookie またはストレージへのアクセスが必要です。サードパーティ Cookie が制限され、ストレージ パーティショニングが有効になっている場合、このアクセスは利用できません。

次のようなユースケースがあります。

• ログイン セッションの詳細を必要とするコメント ウィジェットが埋め込まれている。
• ログイン セッションの詳細を必要とするソーシャル メディアの「いいね」ボタン。
• ログイン セッションの詳細が必要な埋め込みドキュメント。
• 動画埋め込みに提供されるプレミアム エクスペリエンス（ログイン ユーザーに広告を表示しない、ユーザーのクローズド キャプションの設定を把握する、特定の動画タイプを制限するなど）。
• 組み込み型決済システム。

これらのユースケースの多くでは、ログイン アクセスを埋め込み iframe に保持しています。

他の API ではなく Storage Access API を使用する場合

Storage Access API は、パーティション化されていない Cookie とストレージを使用する際の代替手段の 1 つです。そのため、他の API と比較してこの API をいつ使用すべきかを理解することが重要です。これは、次の両方が当てはまるユースケースを対象としています。

• ユーザーが埋め込みコンテンツを操作する（つまり、パッシブ iframe や非表示の iframe ではない）。
• ユーザーがトップレベルのコンテキストで埋め込みのオリジンにアクセスした（つまり、そのオリジンが別のサイトに埋め込まれていない）。

さまざまなユースケースに対応する代替 API があります。

• Cookies Having Independent Partitioned State（CHIPS）を使用すると、デベロッパーは、トップレベル サイト別のストレージに「パーティション化して」保存される Cookie にオプトインできます。たとえば、サードパーティのウェブチャット ウィジェットは、セッション情報を保存するために Cookie の設定に依存している場合があります。セッション情報はサイトごとに保存されるため、ウィジェットによって設定された Cookie は、ウィジェットが埋め込まれている他のウェブサイトでアクセスする必要がありません。Storage Access API は、埋め込まれたサードパーティ ウィジェットが異なるオリジン間で同じ情報を共有することに依存している場合（ログイン セッションの詳細や設定など）に便利です。
• ストレージ パーティショニングは、クロスサイトの iframe が既存の JavaScript ストレージ メカニズムを使用しながら、基盤となるストレージをサイトごとに分割する方法です。これにより、あるウェブサイトの埋め込みストレージが、他のウェブサイトの同じ埋め込みからアクセスされるのを防ぐことができます。
• 関連ウェブサイト セット（RWS）は、組織がサイト間の関係を宣言して、ブラウザが制限されているパーティション化されていない Cookie とストレージの特定の目的でのアクセスを許可できるようにする方法です。サイトは引き続き Storage Access API を使用してアクセスをリクエストする必要がありますが、セット内のサイトについては、ユーザーにメッセージを表示せずにアクセスを許可できます。
• Federated Credential Management（FedCM）は、ID 連携サービスへのプライバシーを保護したアプローチです。Storage Access API は、ログイン後のパーティション分割されていない Cookie とストレージへのアクセスを処理します。ユースケースによっては、FedCM は Storage Access API の代替ソリューションとなり、ログインに特化したブラウザ プロンプトを備えているため、より望ましい場合があります。ただし、FedCM を採用するには、通常、HTTP エンドポイントのサポートなど、コードにさらなる変更を加える必要があります。
• 不正行為防止、広告関連、測定の API も存在しますが、Storage Access API はこれらの懸念に対処することを目的としていません。

Storage Access API を使用する

Storage Access API には、次の 2 つの Promise ベースのメソッドがあります。

• Document.hasStorageAccess()（Chrome 125 以降では Document.hasUnpartitionedCookieAccess() という新しい名前でも利用可能）
• Document.requestStorageAccess()

また、Permissions API とも統合されています。これにより、サードパーティ コンテキストでストレージ アクセス権限のステータスを確認できます。これは、document.requestStorageAccess() の呼び出しが自動的に許可されるかどうかを示します。

• navigator.permissions.query({name: "storage-access"});

hasStorageAccess() メソッドを使用する

サイトが最初に読み込まれるときに、hasStorageAccess() メソッドを使用して、サードパーティ Cookie へのアクセスがすでに許可されているかどうかを確認できます。

// Set a hasAccess boolean variable which defaults to false.
let hasAccess = false;

async function handleCookieAccessInit() {
  if (!document.hasStorageAccess) {
    // Storage Access API is not supported so best we can do is
    // hope it's an older browser that doesn't block 3P cookies.
    hasAccess = true;
  } else {
    // Check whether access has been granted using the Storage Access API.
    hasAccess = await document.hasStorageAccess();
    if (!hasAccess) {
      // Handle the lack of access (covered later)
    }
  }
  if (hasAccess) {
    // Use the cookies.
  }
}
handleCookieAccessInit();

Storage Access API は、requestStorageAccess(), を呼び出した後にのみ iframe ドキュメントにストレージ アクセスを許可するため、hasStorageAccess() は最初は false を返すことがあります（たとえば、ユーザーがデフォルトでサードパーティ Cookie をブロックしている場合など）。（ただし、ユーザーがサードパーティ Cookie をデフォルトでブロックしている場合でも、サイト固有のユーザー設定で特定のサイトの Cookie へのアクセスを許可することもできます）。この API を使用したストレージ アクセスは、iframe 内の同一オリジン ナビゲーション全体で保持されます。これは、HTML ドキュメントの初回リクエストで Cookie が必要となるページでアクセスを許可した後にリロードできるようにするためです。

requestStorageAccess()

iframe にアクセス権がない場合は、requestStorageAccess() メソッドを使用してアクセス権をリクエストする必要があります。

if (!hasAccess) {
  try {
    await document.requestStorageAccess();
  } catch (err) {
    // Access was not granted and it may be gated behind an interaction
    return;
  }
}

初回のリクエストでは、ユーザーがブラウザのプロンプトでこのアクセスを承認する必要がある場合があります。その後、Promise は解決されます。await が使用されている場合は、例外が発生して拒否されます。

不正使用を防止するため、このブラウザ プロンプトはユーザーの操作後にのみ表示されます。そのため、requestStorageAccess() は iframe の読み込み直後ではなく、ユーザーがアクティブにしたイベント ハンドラから最初に呼び出す必要があります。

async function doClick() {

  // Only do this extra check if access hasn't already been given
  // based on the hasAccess variable.
  if (!hasAccess) {
    try {
      await document.requestStorageAccess();
      hasAccess = true; // Can assume this was true if requestStorageAccess() did not reject.
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

  if (hasAccess) {
    // Use the cookies
  }
}

document.querySelector('#my-button').addEventListener('click', doClick);

権限のプロンプト

ユーザーがボタンを初めてクリックすると、ほとんどの場合、ブラウザのプロンプトが自動的に表示されます（通常はアドレスバーに表示されます）。次のスクリーンショットは Chrome のプロンプトの例ですが、他のブラウザにも同様の UI があります。

特定の状況では、ブラウザによってプロンプトがスキップされ、権限が自動的に付与されることがあります。

• プロンプトを承認してから 30 日以内にページと iframe が使用された場合。
• 埋め込まれた iframe が関連ウェブサイト セットの一部である場合。
• FedCM がストレージ アクセスの信頼シグナルとして使用されている場合。
• Firefox では、既知のウェブサイト（トップレベルでやり取りしたことがあるウェブサイト）の場合、最初の 5 回の試行ではプロンプトもスキップされます。

また、状況によっては、プロンプトが表示されずにメソッドが自動的に拒否されることもあります。

• ユーザーが、iframe の所有サイトにトップレベル ドキュメントとして（iframe 内ではなく）以前にアクセスして操作したことがない場合。つまり、Storage Access API は、ユーザーがファーストパーティのコンテキストで以前にアクセスした埋め込みサイトでのみ有用です。
• ユーザー操作イベントの外部で requestStorageAccess() メソッドが呼び出され、操作後のプロンプトの事前承認がない場合。

初回使用時にはユーザーにプロンプトが表示されますが、その後は Chrome と Firefox でプロンプトが表示されることなく、ユーザーの操作を必要とせずに requestStorageAccess() を解決できます。Safari では常にユーザー操作が必要になります。

Cookie とストレージへのアクセスは、プロンプトやユーザー操作なしで許可される場合があるため、この機能をサポートするブラウザ（Chrome と Firefox）では、ページ読み込み時に requestStorageAccess() を呼び出すことで、ユーザー操作の前にパーティション化されていない Cookie またはストレージへのアクセスを取得できることがよくあります。これにより、ユーザーが iframe を操作する前でも、パーティショニングされていない Cookie やストレージにすぐにアクセスして、より充実したエクスペリエンスを提供できるようになります。状況によっては、ユーザー操作を待つよりもユーザー エクスペリエンスが向上する可能性があります。

SAA のトラスト シグナルとしての FedCM

FedCM（Federated Credential Management）は、サードパーティの Cookie やナビゲーション リダイレクトに依存しない、ID 連携サービス（「～でログイン」など）へのプライバシーを保護したアプローチです。

FedCM を使用してサードパーティの ID プロバイダ（IdP）のコンテンツが埋め込まれた利用者（RP）にユーザーがログインすると、埋め込まれた IdP コンテンツは、独自の最上位のパーティショニングされていない Cookie へのストレージ アクセスを自動的に取得できます。FedCM で自動ストレージ アクセスを有効にするには、次の条件を満たす必要があります。

• FedCM 認証（ユーザーのログイン状態）が有効になっている必要があります。
• RP は、たとえば identity-credentials-get 権限を設定することでオプトインしています。

<iframe src="https://idp.example" allow="identity-credentials-get"></iframe>

たとえば、idp.example iframe が rp.example に埋め込まれています。ユーザーが FedCM でログインすると、idp.example iframe は独自のトップレベル Cookie のストレージ アクセスをリクエストできます。

rp.example は、FedCM 呼び出しを行い、ID プロバイダ idp.example を使用してユーザーをログインさせます。

// The user will be asked to grant FedCM permission.
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/fedcm.json',
      clientId: '123',
    }],
  },
});

ユーザーがログインした後、RP が Permissions Policy で明示的に許可している限り、IdP は idp.example iframe 内から requestStorageAccess() を呼び出すことができます。埋め込みには、ユーザーの有効化や別の権限プロンプトを必要とせずに、独自のトップレベル Cookie へのストレージ アクセス権が自動的に付与されます。

// Make this call within the embedded IdP iframe:

// No user gesture is needed, and the storage access will be auto-granted.
await document.requestStorageAccess();

// This returns `true`.
const hasAccess = await document.hasStorageAccess();

この権限は、ユーザーが FedCM でログインしている間のみ自動的に付与されます。認証が無効になると、ストレージ アクセスの付与に標準の SAA 要件が適用されます。

Cookie 以外のストレージ用の Storage Access API

パーティショニングされていないローカル ストレージへのアクセスをリクエストするには、requestStorageAccess 呼び出しに types パラメータを渡します。たとえば、パーティショニングされていないローカル ストレージへのアクセスをリクエストするには、requestStorageAccess({localStorage: true}) を呼び出すことができます。

サードパーティ Cookie が有効になっている場合、このメソッドはユーザーのアクティベーションや権限プロンプトを必要とせずにアクセスを許可します。ユーザーがサードパーティの Cookie を無効にしている場合、ストレージへのアクセスを許可する前にユーザーに確認する必要があります。

まず、ブラウザがすでにストレージへのアクセス権を持っているかどうかを確認します。

async function hasCookieAccess(){
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported, so we assume it's an older browser that doesn't partition storage.
    throw new Error("requestStorageAccess is not supported")
  }

  // Check if access has already been granted or if the user has 3-party cookies enabled
  return document.hasStorageAccess();
}

サードパーティ Cookie が有効になっている場合は、ストレージ アクセスをリクエストします。

// Request storage access and return the storage handle
async function requestStorageHandle(){
// You can request for multiple types of non-cookie storage
// at once, or request for all of them with all:true
return document.requestStorageAccess({all:true});
}

サードパーティ Cookie がブロックされている場合（シークレット モードなど）、クエリ権限を確認して、ユーザー プロンプトが必要かどうかを判断します。navigator.permissions.query({name: 'storage-access'}) 権限の状態は次のいずれかの値になります。

• granted。ユーザーはすでにアクセス権を付与しています。requestStorageAccess を呼び出して、追加のユーザー プロンプトを必要とせずにパーティション分割されていないストレージ アクセスを取得します。
• prompt。ユーザーがまだアクセス権を付与していない。クリック リスナーを設定し、ユーザーの操作後に requestStorageAccess を再度呼び出します。
• error。この権限はサポートされていません。Storage Access API がサポートされている場合、この権限もサポートされている可能性があります。

// Returns `granted`, or `prompt`; or throws an error if storage-access
// permission is not supported
async function getStorageAccessPermission(){
  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
    return navigator.permissions.query({name: 'storage-access'});
}

Cookie 以外のパーティション分割ストレージを処理する完全なフローは、次のように実装できます。

async function getStorageHandle() {
    // Check if the user has 3-party cookie access
    if (await hasCookieAccess()) {
    // If the user has access, requestStorageAccess() will resolve automatically
        return requestStorageHandle();
    }

    // If the browser blocks third party cookies, check if the user has
    // accepted the prompt and granted access. If they have,
    // requestStorageAccess() will resolve automatically
    const permission = await getStorageAccessPermission();
    if (permission == 'granted') { // User has seen prompt and granted access
        return requestStorageHandle();
    }

    // Wait for user activation to prompt the user again
    // (or put your silent failure logic here instead)
    return new Promise((resolve, reject) => {
        document.querySelector('#myButton').addEventListener(e => {
            requestStorageHandle().then(resolve, reject);
        })
    })
}

// Use your storage
getStorageHandle().then(handle=>{
    handle.indexedDB.open(...);
}).catch(() => {
    // If the promise is rejected, you can use regular partitioned storage
    indexedDB.open(...);
})

ストレージ アクセス ヘッダーを使用した後続の読み込み

ストレージ アクセス ヘッダーは、iframe 以外のリソースを含む埋め込みコンテンツの読み込みを有効にするための、推奨されるパフォーマンスの高い方法です。この機能は Chrome 133 以降で利用できます。Storage Access Headers を使用すると、ブラウザは現在のコンテキストでユーザーがサードパーティのオリジンに storage-access 権限をすでに付与しているかどうかを認識し、その後のアクセスでパーティショニングされていない Cookie にアクセスできるリソースを読み込むことができます。

ストレージ アクセス ヘッダーのフロー

Storage Access ヘッダーを使用すると、後続のページ訪問で次のフローがトリガーされます。

1. ユーザーが以前に calendar.example リソースを埋め込んでいる website.example にアクセスし、document.requestStorageAccess() 呼び出しで storage-access を付与している。
2. ユーザーが calendar.example リソースが埋め込まれた website.example に再度アクセスします。このリクエストは、以前と同様に、まだ Cookie にアクセスできません。ただし、ユーザーは以前に storage-access 権限を付与しており、フェッチには Sec-Fetch-Storage-Access: inactive ヘッダーが含まれています。これは、パーティション分割されていない Cookie へのアクセスは可能だが、有効になっていないことを示しています。
3. calendar.example サーバーは、Activate-Storage-Access: retry; allowed-origin='<origin>' ヘッダー（この場合、<origin> は https://website.example になります）で応答し、リソースの取得には storage-access 権限を持つパーティション分割されていない Cookie の使用が必要であることを示します。
4. ブラウザはリクエストを再試行します。今回は、パーティショニングされていない Cookie を含めます（このフェッチと後続のフェッチに対して storage-access 権限を有効にします）。
5. calendar.example サーバーは、パーソナライズされた iframe コンテンツを返します。レスポンスには Activate-Storage-Access: load ヘッダーが含まれています。これは、ブラウザが storage-access 権限を有効にしてコンテンツを読み込む（つまり、document.requestStorageAccess() が呼び出されたかのように、パーティショニングされていない Cookie アクセスで読み込む）ことを示します。
6. ユーザー エージェントは、storage-access 権限を使用して、パーティショニングされていない Cookie アクセスで iframe コンテンツを読み込みます。この手順を完了すると、ウィジェットが想定どおりに動作するようになります。

ストレージ アクセス ヘッダーを使用する

次の表に、Storage Access ヘッダーを示します。

たとえば、Storage Access Headers を使用して、サードパーティから画像画像を読み込むことができます。

  // On the client side
  <img src="https://server.example/image">

この場合、server.example はサーバーサイドで次のロジックを実装する必要があります。

  app.get('/image', (req, res) => {
  const storageAccessHeader = req.headers['sec-fetch-storage-access'];

  if (storageAccessHeader === 'inactive') {
    // The user needs to grant permission, trigger a prompt

    // Check if the requesting origin is allowed
    // to send credentialed requests to this server.
    // Assuming the `validate_origin(origin)` method is previously defined:
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(req.headers.origin +
        ' is not allowed to send credentialed requests to this server.');
      return;
    }
    // 'retry' header value indicates that the content load request should be re-sent after the user has granted permissions
    res.set('Activate-Storage-Access', `retry; allowed-origin='${req.headers.origin}'`);
    res.status(401).send('This resource requires storage access. Please grant permission.');
  } else if (storageAccessHeader === 'active') {
    // User has granted permission, proceed with access
    res.set('Activate-Storage-Access', 'load');
    // Include the actual iframe content here
    res.send('This is the content that requires cookie access.');
  } else {
    // Handle other cases (e.g., 'Sec-Fetch-Storage-Access': 'none')
  }
});

Storage Access API のデモでは、Storage Access Headers を使用してサードパーティのコンテンツ（iframe 以外の画像を含む）を埋め込んでいます。

storage-access 権限クエリを使用する

ユーザーの操作なしでアクセス権を付与できるかどうかを確認するには、storage-access 権限のステータスを確認し、インタラクションが必要な場合に呼び出して失敗するのではなく、ユーザー アクションが必要ない場合にのみ requestStoreAccess() 呼び出しを早期に行うことができます。

また、ログインボタンなどの別のコンテンツを表示することで、プロンプトの必要性を事前に処理することもできます。

次のコードは、前の例に storage-access 権限チェックを追加したものです。

// Set a hasAccess boolean variable which defaults to false except for
// browsers which don't support the API - where we assume
// such browsers also don't block third-party cookies.
let hasAccess = false;

async function hasCookieAccess() {
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported so best we can do is
    // hope it's an older browser that doesn't block 3P cookies.
    return true;
  }

  // Check if access has already been granted
  if (await document.hasStorageAccess()) {
    return true;
  }

  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
  // (e.g. Safari and earlier versions of Firefox).
  let permission;
  try {
    permission = await navigator.permissions.query(
      {name: 'storage-access'}
    );
  } catch (error) {
    // storage-access permission not supported. Assume no cookie access.
    return false;
  }

    if (permission) {
    if (permission.state === 'granted') {
      // Permission has previously been granted so can just call
      // requestStorageAccess() without a user interaction and
      // it will resolve automatically.
      try {
        await document.requestStorageAccess();
        return true;
      } catch (error) {
        // This shouldn't really fail if access is granted, but return false
        // if it does.
        return false;
      }
    } else if (permission.state === 'prompt') {
      // Need to call requestStorageAccess() after a user interaction
      // (potentially with a prompt). Can't do anything further here,
      // so handle this in the click handler.
      return false;
          } else if (permission.state === 'denied') {
            // Not used: see https://github.com/privacycg/storage-access/issues/149
      return false;
          }
    }

  // By default return false, though should really be caught by earlier tests.
  return false;
}

async function handleCookieAccessInit() {
  hasAccess = await hasCookieAccess();

  if (hasAccess) {
    // Use the cookies.
  }
}

handleCookieAccessInit();

サンドボックス化された iframe

サンドボックス化された iframe で Storage Access API を使用する場合は、次のサンドボックス権限が必要です。

• Storage Access API へのアクセスを許可するには、allow-storage-access-by-user-activation が必要です。
• allow-scripts は、JavaScript を使用して API を呼び出すことを許可するために必要です。
• allow-same-origin は、同一オリジンの Cookie やその他のストレージへのアクセスを許可するために必要です。

次に例を示します。

<iframe sandbox="allow-storage-access-by-user-activation
                 allow-scripts
                 allow-same-origin"
        src="..."></iframe>

Cookie の要件

Chrome の Storage Access API でアクセスするには、クロスサイト Cookie を次の 2 つの属性で設定する必要があります。

• SameSite=None - Cookie をクロスサイトとしてマークするために必要
• Secure - HTTPS サイトによって設定された Cookie のみにアクセスできるようにします。

Firefox と Safari では、Cookie はデフォルトで SameSite=None に設定されており、SAA を Secure Cookie に制限しないため、これらの属性は必要ありません。SameSite 属性を明示的に指定し、常に Secure Cookie を使用することをおすすめします。

トップレベル ページのアクセス

Storage Access API は、埋め込み iframe 内でサードパーティ Cookie へのアクセスを有効にすることを目的としています。

トップレベル ページでサードパーティ Cookie へのアクセスが必要になるユースケースもあります。たとえば、Cookie によって制限されている画像やスクリプトなどです。サイト所有者は、iframe ではなくトップレベル ドキュメントに直接含めることを希望する場合があります。このユースケースに対応するため、Chrome は Storage Access API の拡張機能を提案しています。この拡張機能では requestStorageAccessFor() メソッドが追加されます。

requestStorageAccessFor() メソッド

requestStorageAccessFor() メソッドは requestStorageAccess() と同様に機能しますが、最上位のリソースに対して機能します。これは、関連ウェブサイト セット内のサイトでのみ使用でき、サードパーティ Cookie への一般的なアクセスを許可しないようにします。

requestStorageAccessFor() の使用方法について詳しくは、関連ウェブサイト セット: デベロッパー ガイドをご覧ください。

top-level-storage-access 権限のクエリ

storage-access 権限と同様に、requestStorageAccessFor() へのアクセスを許可できるかどうかを確認する top-level-storage-access 権限があります。

RWS で使用する場合、Storage Access API はどのように異なりますか？

関連ウェブサイト セットを Storage Access API と組み合わせて使用すると、次の表に示すように、特定の追加機能を利用できます。

デモ: Cookie の設定とアクセス

次のデモは、デモの最初の画面でユーザーが設定した Cookie に、デモの 2 番目のサイトの埋め込みフレームからアクセスできることを示しています。

storage-access-api-demo.glitch.me

このデモでは、サードパーティ Cookie が無効になっているブラウザが必要です。

• chrome://flags/#test-third-party-cookie-phaseout フラグが設定され、ブラウザが再起動された Chrome 118 以降。
• Firefox
• Safari

デモ: ローカル ストレージの設定

次のデモは、Storage Access API を使用して、サードパーティの iframe からパーティショニングされていないブロードキャスト チャネルにアクセスする方法を示しています。

https://saa-beyond-cookies.glitch.me/

このデモには、test-third-party-cookie-phaseout フラグが有効になっている Chrome 125 以降が必要です。

リソース

• サードパーティ Cookie へのアクセスを提供する仕様を読むか、問題をフォローして報告します。
• パーティション分割されていないストレージ アクセスを提供する仕様を読むか、問題をフォローして報告します。
• API ドキュメントとガイド。
• 関連ウェブサイト セットで Storage Access API を使用する方法に関する Chrome のドキュメント