為因應 2024 年起淘汰第三方 Cookie 的情形，許多 Privacy Sandbox API 會逐漸在 Chrome 穩定版中實現正式發布 (GA)。其中有些 API 有助於保留重要的跨網站 Cookie 用途 (例如 CHIPS)，以及目前稱為第一方集合 (FPS) 的 API。我們在這篇文章中介紹相關網站集 (RWS)，這是我們更反映其用途的新 FPS 名稱，同時針對主要用途和相關子集網域限制的更新提供複習。
保留關鍵使用者旅程
有了 RWS，當 Chrome 開始預設限制第三方 Cookie 存取權後，這項服務就能盡可能降低對特定使用者功能受到的干擾。我們的目標是讓使用者在最短幹擾的情況下瀏覽網頁，同時遵守 Privacy Sandbox 的隱私權目標。為了在兩者間取得平衡，RWS 會指定與網站功能相關的特定用途：
- ccTLD 用途在我們的公開追蹤器中回報的登入範例地址損壞問題。在生態系統中，這類情況通常是透過經驗法則式例外狀況解決 (請參閱參考資料 1)。
- 服務網域用途可協助開發人員將敏感功能 (例如驗證流程) 與使用者端網域區隔開來。生態系統中的這類情況可能會透過明確的例外狀況解決 (請參閱參考資料 2)。
- 相關網域用途針對重要使用者歷程可能需要第三方 Cookie 存取權的網域類型提供更靈活彈性 (請參閱參考資料 3)。雖然 ccTLD 和服務網域用途是針對網域特性進行嚴格技術檢查，盡可能減少濫用情形，但關聯網域會採用數值限制。詳情請參閱下一節。
關聯網域上限已提高至 5 個網域
Chrome 先前建議為關聯子集 (加上一個主網域) 建議最多三個網域的數字上限，以防廣泛追蹤濫用行為。網路標準參與者向我們反映，此限制對於不同類型的使用情境而言太低。
我們決定將相關網域數量上限提高為 5 個網域 (再加上一個主網域)，這是與其他主要瀏覽器上最相似的實作項目 (請參閱參考資料 4)。這項變更自 Chrome 117 版起生效。
由於 RWS 並非廣告解決方案，因此我們不會參考您對如何改善 RWS 來改善廣告用途的看法。針對廣告用途，開發人員應探索 Topics、Protected Audience 和 Attribution Reporting API 的使用方式，並據此提供意見回饋。
除了五個相關網域外，使用者還能選擇擴大使用情境
若無此限制，Chrome 目前正在改善使用者提示流程，並採用其他瀏覽器採用的 Storage Access API (SAA)，為使用者提供影響體驗。如果是需要超過五個相關網域的用途，建議開發人員評估非 RWS 環境可如何支援 SAA。我們將單獨遵循這項功能的 Blink 啟動程序，並自 Chrome 117 版起在 Chrome 電腦版中推出這項功能。
後續步驟
感謝大環境的各方意見回饋，協助我們打造 API。我們投入了 RWS 平台，協助開發人員能夠清楚掌控及控管網站，並確保他們能夠持續提供所建構網站的使用者體驗。隨著業務發展，我們很高興看到開發人員採用及採用回應式網頁設計。提交程序目前已上線。如需協助提交內容，建議從 RWS JSON 產生器工具著手。
遵循「意圖傳送執行緒」追蹤進度，並參閱這些資料中的實作指南。
參考資料
- 各瀏覽器之間普遍同意這類跨網站 Cookie 的用途，但他們採取了不同的啟用方法。Firefox (程式碼) 和 Safari (程式碼) 都導入了彈出式視窗經驗法則，藉此解決先前發現的損壞問題，例如 Nintendo 登入流程。
- 除此之外，還有多個例子，瀏覽器必須編寫硬式編碼的例外狀況，才能將對使用者的干擾降到最低。Firefox 會授予 Microsoft Teams 和 login.microsoftonline.us 之間重新導向流程的儲存空間存取權。
- 當使用者登入 instagram.com 時，Firefox 提供的「shim」會代表 facebook.com 呼叫 requestStorageAccessForOrigin。此外，在 Safari 的硬式編碼例外狀況中可看到多個網域的儲存空間存取提示，同樣提供網站分組範例。
- Firefox 會自動授予使用者先前瀏覽的第三方網站發出的前 5 個 requestStorageAccess 呼叫 (程式碼)。在 Chrome 中，除同一組的主網域外，在相關聯的前五個網域也會自動獲得透過 RWS 存取第三方 Cookie 的權限。