Chrome 115 藉由在第三方環境中分區的方式,變更儲存空間、Service Worker 和通訊 API。除了隔離相同來源政策之外,在第三方結構定義中使用的受影響的 API 也會隔離在頂層結構定義的網站。
如果網站已無時間導入第三方儲存空間分區支援功能,可以參與淘汰試用計畫,暫時解除分區 (依相同來源政策持續隔離,但依頂層網站移除隔離功能),並在內嵌的內容中還原儲存空間、服務工作人員和通訊 API 先前的行為。這個淘汰試用計畫已於 2024 年 9 月 3 日隨著 Chrome 127 版本到期。請注意,這與第三方 Cookie 的淘汰試用計畫不同,這只是儲存空間存取權。
為了因應第三方非 Cookie 儲存空間分區造成的某些用途,Chrome 目前提議開放第三方透過 Storage Access API (自 Chrome 117 起運送) 要求儲存/通訊服務 (Cookie 和非 Cookie)。這項 API 已開放第三方存取 Cookie。
自 Chrome 120 起,這項提案可透過來源試用進行實驗。開發人員應參與這項來源試用,評估提議的解決方案解決其用途,確保在淘汰試用期結束前做好準備。
來源試用詳細資料
自 Chrome 120 版起,Chrome 將支援來源試用 (StorageAccessAPIBeyondCookies),以啟用我們提議的 Storage Access API 擴充功能 (回溯相容),以便在第三方環境中存取未分區的儲存空間 (Cookie 和非 Cookie)。
機械
這個 API 的用途如下 (在內嵌 iframe 中執行的 JavaScript):
// Request a new storage handle via rSA (this should prompt the user)
const handle = await document.requestStorageAccess({all: true});
// Write some 1P context sessionStorage
handle.sessionStorage.setItem('userid', '1234');
// Write some 1P context localStorage
handle.localStorage.setItem('preference', 'A');
// Open or create an indexedDB that is shared with the 1P context
const messageDB = handle.indexedDB.open('messages');
// Use locks shared with the 1P context
await handle.locks.request('example', ...);
如果您只想獲得特定 API 存取權,而不想存取 all
,可以只傳遞所需的 API 處理名稱。舉例來說,您可以傳遞 {sessionStorage: true}
只取得工作階段儲存空間的存取權,傳送 {indexedDB: true, locks:true}
則可存取 IndexedDB 和 Web Lock。
除了呼叫這個額外的擴充功能外,存取非 Cookie 儲存空間,也符合透過 Storage Access API 存取 Cookie 的現行規定。舉例來說,在 Chrome 中,當來源屬於同一個相關網站集 (RWS,第一方集合的新名稱) 時,Chrome 不會顯示提示。如果來源不屬於相同的 RWS,則必須在 Chrome 中使用 Storage Access API 的提示要求。
時間長度
來源試用在 Chrome 120 版本為 Chrome 125 版本 (或 2024 年 8 月 6 日後)。
範圍
Chrome 120 僅支援 DOM 儲存空間 (工作階段和本機儲存空間)、索引資料庫和 Web Lock。
Chrome 121 新增了快取儲存空間、來源私人檔案系統、配額、Blob 儲存空間和廣播管道。
Chrome 第 123 版本增加了「共用工作人員」和控管 Cookie 納入作業。
如果在 Chrome 120 建立工作站之前就呼叫 requestStorageAccess
,「專屬工作站」會繼承未分區 Cookie 的存取權 (不需要使用 Storage Access API 處理常式)。
參加
- 評估您在第三方情境中如何使用 Cookie 和非 Cookie 儲存空間。您可以參考使用範例,瞭解這項提案是否滿足您的需求。
- 請啟動 Chrome 120 以上版本,並確認 test-third-party-cookie-phaseout 標記已啟用。
- 如果想在本機測試這項功能,而不先設定來源試用權杖,您可以在瀏覽器中啟用 #enable-experimental-web-platform-features。
- 在本機完成測試後,您可以註冊 StorageAccessAPIBeyondCookies 來源試用,取得網域的權杖。如需詳細操作說明,請參閱「開始使用來源試用」一文。Chrome 來源試用疑難排解指南提供一份完整檢查清單,協助您確保權杖設定正確無誤。
- 將來源試用權杖嵌入 iframe 中,並利用 HTTP 標頭、HTML 中繼標記或程式輔助方式,使用 Storage Access API 控制代碼。請注意,凡是要使用這個 API 的影格都必須嵌入權杖,將權杖嵌入父項影格,並不會在子頁框中啟用 API。
- 呼叫
document.requestStorageAccess(...)
即可在跨網站 iframe 中取得 Storage Access API 控制代碼。如要瞭解呼叫成功的需求條件,請參閱 Storage Access API 說明文件。 - 遷移 iframe 中相關的儲存空間,以便使用 Storage Access API 控制代碼 (如果有的話)。舉例來說,對
window.sessionStorage.setItem(...)
的呼叫會變成handle.sessionStorage.setItem(...)
。 - 開啟網站,確認儲存空間存取帳號是否正常運作。
- 如要停止參與來源試用,請移除您在步驟 3 中新增的權杖。
- 前往 Storage Access API 非 Cookie 儲存空間 GitHub 存放區提供意見或回報問題。
示範:使用 Storage Access API 存取未分區的本機儲存空間
以下示範示範如何使用 Storage Access API,從第三方 iframe 存取未分區廣播頻道:
https://saa-beyond-cookies.glitch.me/
如要使用這項示範,Chrome 121 以上版本必須啟用 test-third-party-cookie-phaseout 標記。