在 Chrome 淘汰第三方 Cookie 後，第一方集合 (FPS) 的設計目的是支援使用者的網頁瀏覽體驗。在FPS 孵化期間，這項提案在開放式網路論壇中大幅演進，首先是 W3C 的隱私權社群群組，現在則是網路孵化器社群群組。
在本篇文章中，我們將回顧演進過程、強調主要變更，並說明為何我們認為這些變更可改善網站隱私權，同時繼續支援生態系統。
背景
網站通常會在第三方內容中存取 Cookie，為使用者提供流暢且個人化的體驗。除了隱私權保護廣告 API (Topics、Protected Audience API 和 Attribution) 之外，Chrome 團隊也想瞭解第三方 Cookie 的使用範圍，除了廣告個人化或評估用途之外，也能為使用者提供更優質的瀏覽體驗。
我們發現，機構可能會依賴第三方 Cookie，因為其網站架構設計為使用多個網域。舉例來說，某機構可能有一個網域用於健行部落格，另一個網域用於露營商店，並希望支援這些網站的使用者歷程。機構也可能會為網路服務維護多個國家/地區代碼網域，並共用基礎架構。針對這類情況，我們著手打造符合這些機構需求的解決方案，同時維護使用者對網路隱私權的期望。
我們的起點
由於瀏覽器目前使用網站層級邊界來解讀「第一方」與「第三方」，以便考量機構可能管理的網域範圍，因此建議將這項技術邊界替換為更精細的定義。
2021 年，Chrome 最初為第一方集合提出 SameParty Cookie 屬性，讓網站可以定義來自「同一個群體」網站的 Cookie。我們使用User-Agent 政策定義「同一方」的構成條件。這項政策定義試圖建立在現有「第三方」架構 (例如 W3C DNT 規格) 之上，並納入相關隱私權論述的建議 (例如 2012 年聯邦貿易委員會的報告，標題為「Protecting Consumer Privacy in an Era of Rapid Change」)。
當時，我們認為這種做法可為不同類型的機構 (跨產業) 提供足夠的彈性，同時也能達成我們的根本目標，也就是盡量減少透過第三方 cookie 進行的廣泛追蹤。
對初步提案的意見回饋
經過與網際網路生態系統中利害關係人的多次對談，我們發現這項初始設計有其限制。
透過 SameParty 屬性存取 Cookie 的被動隱私權問題
其他瀏覽器供應商偏好採用主動式方法存取第三方 Cookie，這類方法需要明確的 API 叫用，而不是建立邊界，以便維持主動式 Cookie 存取權。要求 Cookie 存取權的活動可讓瀏覽器掌握及控制相關資訊，進而降低透過第三方 Cookie 進行隱密追蹤的風險。此外，這項可見度也能讓瀏覽器為使用者提供允許或封鎖這類 Cookie 存取權的選項。
為了尋求跨瀏覽器的網頁互通性，並提升隱私權益，我們決定朝這個方向前進。
實施建議政策的挑戰
原始政策提出了三項要求，以便將網域納入單一組合：共同擁有權、「共同隱私權政策」和「共同群組身分」。
從更廣泛的生態系統來看，我們發現收到的政策相關意見回饋可歸納為四大主題。
共同擁有權過於嚴格
針對「共同擁有」規定，我們收到意見回饋，指出如果 FPS 的定義僅著重於企業擁有權，大型企業將比小型企業更能跨多個網域和面向使用者的服務，匯集更多資料。由於我們的目標是為整個生態系統建構 Privacy Sandbox，因此我們非常重視這項意見回饋，並將優先考量更具包容性的解決方案。
單一政策限制了用途的擴充功能
雖然制定全方位政策來管理邊界，目的是為了讓需要位於機構 FPS 中的不同類型網域具備彈性，但我們發現某些重要用途無法符合這項政策設計。舉例來說，服務網域 (例如代管使用者產生的內容) 可能需要存取第三方內容中的 Cookie，以便驗證或識別使用者。這類網域很少有使用者可存取的首頁，因此無法符合與同一個 FPS 中其他網域的「共同群組身分」或「共同隱私權政策」規定。
使用者對群組身分的認知和理解可能有所不同
我們最初提出的護欄是為了定義「通用群組身分」，以便將單一組內的網域範圍縮小到可輕鬆與通用群組身分建立關聯的網域。不過，我們無法定義技術手段來評估共同群組身分是否「容易被使用者發現」。這可能會導致濫用行為，並引發執行問題。
我們也收到 意見回饋，指出「共同擁有」的定義可能因使用者而異，因此很難制定適用於所有網站的規範。
主觀的政策很難大規模執行
由於某些規定 (例如「一般群組身分」) 具有主觀性，且需要涵蓋其他例外狀況或邊緣情況 (「一般隱私權政策」)，因此我們收到許多要求提供更詳細指南的請求。
為確保政策能公平且一致地套用，Chrome 必須為網站作者提供更明確的規範。我們認為，若試圖制定更嚴格的規範，可能會對生態系統造成不利影響。
雖然我們最初建議由獨立執法機構負責調查和執行政策遵循情形，但在目前的生態系統中，要找到具備適當專業知識，能以公正態度執行這些責任的獨立執法機構，並不容易。我們努力轉向可透過技術強制執行的政策，確保能以一致且客觀的方式實施。
演進
我們已根據客戶意見重新設計 FPS，我們回歸我們試圖解決的具體問題，並決定以更直接的方式，針對我們要解決的特定用途來構思提案。
解決主要用途
Chrome 開發了三個不同用途的「子集」，以滿足網路上的重點用途。子集方法相較於舊方法，更能確保隱私性、更具體且更容易一致執行。
- 「ccTLD」(國家/地區代碼頂層網域)：機構可能會維護使用不同 ccTLD 的網站，以提供在地化體驗，而這些網站可能仍需要存取共用服務和基礎架構。
- 「服務」網域：網站可能會使用個別網域來確保安全性或提升效能，這些網站可能需要存取使用者的身分，才能執行其功能。
- 「相關」網域：機構可能會為不同的相關品牌或產品維護多個網站。他們可能會需要跨網站 Cookie 存取權，以便進行跨相關網站的使用者歷程分析，進一步瞭解機構的使用者族群如何與其網站互動，或是記住使用者在相關網站上登入的狀態，而該網站使用相同的登入基礎架構。
針對這些用途，我們有不同的政策規定、對應的技術驗證檢查，以及特定瀏覽器處理行為 (詳情請參閱提交指南)。這些變更捨棄了「一體適用」的設計，並採用以用例為導向的區隔式架構，以解決原始提案中的限制。
透過要求第三方 Cookie 存取權，提供互通性
Chrome 很樂意促進與其他瀏覽器的互通性，以維持網站平台的健康。由於 Safari、Firefox 和 Edge 等其他瀏覽器目前使用 Storage Access API (SAA) 來促進有效的 Cookie 要求，因此我們選擇在 Chrome 中運用 SAA，不僅有助於回應收到的主要意見回饋，也能支援網路互通性。
為讓開發人員享有更多彈性，並解決 SAA 的已知限制，我們也提出了 requestStorageAccessForOrigin API。
可同時使用 Storage Access API 和 FPS
實作 Storage Access API (SAA) 時，瀏覽器可以選擇直接向使用者要求權限，其他瀏覽器則可以選擇允許有限數量的要求，不顯示權限提示。
Chrome 認為，FPS 可在 SAA 之上提供透明層，限制使用者摩擦，並避免在重要且受限的用途中出現提示疲勞。如果瀏覽器選擇提示使用者授予權限，FPS 也會讓瀏覽器彈性地向使用者提供有關集合成員的額外背景資訊。
有了 FPS，開發人員就能找出自己的受影響網站，並提供重要用途。這可讓開發人員/代理商預測網站對使用者的運作方式，並透過 FPS 或第三方 Cookie 替代方案，採取措施來限制對使用者體驗的影響。此外，FPS 可讓開發人員預測平台行為，而非使用推論法，因為推論法可能會隨著時間變化，或導致不同使用者出現不同的行為。
最後，如果開發人員在 Chrome 中導入 SAA 以搭配 FPS 運作，就能在其他瀏覽器 (即使不支援 FPS) 上利用 SAA 提升網站效能。
後續討論
我們認為，最新的提案在考量使用者和開發人員需求的情況下，在取捨之間取得了平衡。我們感謝網路生態系統利益相關者提供意見回饋，協助我們改善 FPS 提案。
我們瞭解網路生態系統的利益相關者仍在熟悉更新後的提案。歡迎與我們互動，讓我們能持續改善設計，讓開發人員更容易使用，並持續改善網際網路上的隱私權。Google 也將持續與英國競爭及市場管理局 (CMA) 合作，確保遵守承諾。
如要吸引觀眾，請參考下列資源：
- WICG 中的育成
- FPS 測試操作說明
- 第一方集合：整合指南
- FPS 提交指南
使用生態系統
很高興看到 Salesforce 和 CafeMedia 等公司積極提供關鍵意見，並開發第一方集合。這些研究人員對技術的進步貢獻良多。其他幾位使用者也分享了對第一方集合和 Chrome 與網路生態系統合作的看法：
「Chrome 正在開發第一方集合，以便支援許多使用情境，例如保留使用者歷程。這也證明 Google 團隊正在努力瞭解網站擁有者的需求。」- Mercado Libre
「我們 VWO 很感謝 Google 致力提升隱私權標準，同時確保處理真實的使用情境。很高興這個團隊與開發人員生態系統合作，並根據網站利益相關者的意見回饋，持續改善第一方集合方案的實作方式。我們很高興能參與這項提案的測試過程，也期待這項提案能納入瀏覽器。」- VWO 工程總監 Nitish Mittal