Chrome 如何改進第一方集合提案

第一方集合圖表。

在 Chrome 淘汰第三方 Cookie 後，第一方集合 (FPS) 的設計目的是支援使用者的網頁瀏覽體驗。在FPS 孵育計畫期間，這項提案在開放式網路論壇中大幅演進，首先是 W3C 的隱私權社群群組，現在則是網路孵育器社群群組。

在本篇文章中，我們將回顧演進過程、強調主要變更，並討論為何我們認為這些變更可改善網站隱私權，同時繼續支援生態系統。

背景

網站通常會在第三方情境中存取 Cookie，為使用者提供流暢且個人化的體驗。除了隱私權保護廣告 API (Topics、Protected Audience API 和 Attribution) 之外，Chrome 團隊也想瞭解使用第三方 Cookie 的情況範圍，除了廣告個人化或評估用途之外，也能為使用者提供更優質的瀏覽體驗。

我們發現，機構可能會依賴第三方 Cookie，因為其網站架構設計為使用多個網域。舉例來說，某機構可能有一個網域用於健行部落格，另一個網域用於露營商店，並希望支援這些網站的使用者歷程。機構也可能會為網路服務維護多個國家/地區代碼網域，並共用基礎架構。針對這類情況，我們著手建立符合這些機構需求的解決方案，同時維護使用者對網路隱私權的期望。

我們的起點

由於瀏覽器目前使用網站層級邊界來解讀「第一方」與「第三方」，以便考量機構可能管理的網域範圍，因此建議將這項技術邊界替換為更精細的定義。

含有內嵌 iframe 的網站圖表。

2021 年，Chrome 最初為第一方集合提出 SameParty Cookie 屬性，讓網站可以定義來自「同一個群體」網站的 Cookie。我們使用使用者代理程式政策定義「同一方」的構成條件。這項政策定義嘗試以現有「第三方」架構 (例如 W3C DNT 規格) 為基礎，並納入相關隱私權論述的建議 (例如 2012 年聯邦貿易委員會的報告「Protecting Consumer Privacy in an Era of Rapid Change」)。

當時，我們認為這種做法可為各行各業的不同類型機構提供足夠的彈性，同時也能達成我們的根本目標，也就是盡量減少透過第三方 cookie 進行的廣泛追蹤。

對初步提案的意見回饋

在與網際網路生態系統中的利害關係人進行多次對談後，我們發現這項初始設計存在一些限制。

其他瀏覽器供應商偏好採用主動式方法存取第三方 Cookie，這類方法需要明確的 API 叫用，而不是建立邊界，以便維持主動式 Cookie 存取權。積極要求 Cookie 存取權可讓瀏覽器掌握及控制 Cookie，進而降低透過第三方 Cookie 進行隱密追蹤的風險。此外，這項可見度也能讓瀏覽器為使用者提供允許或封鎖這類 Cookie 存取權的選項。

為了尋求跨瀏覽器的網頁互通性，並提升隱私權益，我們決定朝這個方向前進。

實施建議政策的挑戰

原始政策提出了三項網域須符合的條件，才能歸入同一組：共同擁有者、「共同隱私權政策」和「共同群組身分」。

在更廣泛的生態系統中，我們發現收到的政策相關意見可歸納為四大主題。

共同擁有權過於嚴格

針對「共同擁有」規定，我們收到意見回饋，指出如果 FPS 的定義僅著重於企業擁有權，大型企業將比小型企業更有機會跨多個網域和面向使用者的服務，匯集更多資料。由於我們的目標是為整個生態系統打造 Privacy Sandbox，因此我們非常重視這項意見回饋，並將優先考量更具包容性的解決方案。

單一政策限制了用途的可擴充性

雖然制定全方位政策來管理邊界，目的是為了讓需要位於機構 FPS 中的不同類型網域具備彈性，但我們發現某些重要用途無法符合這項政策設計。舉例來說，服務網域 (例如代管使用者產生的內容) 可能需要存取第三方內容中的 Cookie，以便驗證或識別使用者。這類網域很少有使用者可存取的首頁，因此無法符合「共同群組身分」或「共同隱私權政策」的要求，而這些要求是指在同一個 FPS 中與其他網域共用。

使用者對群組身分的認知和理解可能有所不同

我們最初提出的護欄定義了「共同群組身分」，試圖將單一組內的網域範圍縮小到那些容易與共同群組身分相關聯的網域。不過，我們無法定義技術手段來評估共同群組身分是否「容易被使用者發現」。這可能導致濫用行為，並引發執行問題。

我們也收到 意見回饋，指出「共同擁有」的定義可能因使用者而異，因此很難制定適用於所有網站的規範。

主觀的政策很難大規模執行

由於某些規定 (例如「一般群組身分」) 具有主觀性，且需要涵蓋其他例外狀況或邊緣情況 (「一般隱私權政策」)，因此我們收到許多要求提供更詳細指南的請求。

為確保政策能公平且一致地套用，Chrome 必須為網站作者提供更明確的規範。我們認為，若試圖制定更嚴格的規範，可能會對生態系統造成不利影響。

雖然我們最初建議由獨立執法機構負責調查和執行政策遵循情形，但在目前的生態系統中，要找到具備適當專業知識，能以公正態度執行這些責任的獨立執法機構，並不容易。我們努力轉向可透過技術強制執行的政策，確保能以一致且客觀的方式實施。

演進

我們已根據意見回饋重新設計 FPS。我們回歸到要解決的具體問題，並決定以更直接的方式，針對我們要解決的特定用途來構思提案。

解決主要用途

Chrome 開發了三個不同用途的「子集」，以滿足網路上的重點用途。子集方法相較於舊方法，更具隱密性、更具體，也更容易一貫執行。

第一方集合子集的圖表。
  • 「ccTLD」(國家/地區代碼頂層網域)：機構可能會維護使用不同 ccTLD 的網站，以提供當地體驗，而這些網站可能仍需要存取共用服務和基礎架構。
  • 「服務」網域：網站可能會使用個別網域來確保安全性或提升效能，這些網站可能需要存取使用者的身分，才能執行其功能。
  • 「相關」網域：機構可能會為不同的相關品牌或產品維護多個網站。他們可能會需要跨網站 Cookie 存取權，以便進行橫跨相關網站的使用者歷程分析，進一步瞭解機構的使用者族群如何與其網站互動，或是記住使用者在相關網站上登入的狀態，而該網站使用相同的登入基礎架構。

針對這些用途，我們有不同的政策規定、對應的技術驗證檢查，以及特定的瀏覽器處理行為 (詳情請參閱提交指南)。這些變更捨棄了「一體適用」的設計，並採用以用例為導向的區隔式架構，以解決原始提案中的限制。

Chrome 希望能促進與其他瀏覽器的互通性，以維持網站平台的健康。由於 Safari、Firefox 和 Edge 等其他瀏覽器目前使用 Storage Access API (SAA) 來促進有效的 Cookie 要求，因此我們選擇在 Chrome 中運用 SAA，不僅有助於回應收到的主要意見回饋，也能支援網路互通性。

為了讓開發人員享有更多彈性，並解決 SAA 的已知限制，我們也提出了 requestStorageAccessForOrigin API。

可同時使用 Storage Access API 和 FPS

導入儲存空間存取 API (SAA) 時，瀏覽器可以選擇直接向使用者要求權限，其他瀏覽器則可以選擇允許有限數量的要求，不顯示權限提示。

Chrome 認為，FPS 可在 SAA 之上提供透明層，限制使用者摩擦，並避免在重要且受限的用途中出現提示疲勞。如果瀏覽器選擇提示使用者授予權限，FPS 也會讓瀏覽器彈性地向使用者提供有關集合成員資格的額外背景資訊。

透過 FPS，開發人員可以找出自己的受影響網站，並提供重要用途。這樣一來，代理商就能預測網站對使用者的運作方式，並利用 FPS 或第三方 Cookie 替代方案，採取措施來限制對使用者體驗的影響。此外，FPS 可為開發人員提供平台可預測性，而非採用可能會隨時間變更的啟發式搜尋，或導致不同使用者產生不同行為。

最後，如果開發人員在 Chrome 中導入 SAA 以搭配 FPS 運作，就能在其他瀏覽器上利用 SAA 提升網站效能，即使這些瀏覽器不支援 FPS 也一樣。

後續討論

我們認為，最新的提案在考量使用者和開發人員需求的情況下，在權衡取捨的難題中取得了平衡。我們感謝網路生態系統利益相關者提供意見回饋，協助我們改善 FPS 提案。

我們瞭解網路生態系統的利益相關者仍在熟悉更新後的提案。歡迎與我們互動，讓我們能持續改善設計，讓開發人員更容易使用，並持續改善網頁上的隱私權。Google 也將持續與英國競爭及市場管理局 (CMA) 合作，確保遵守承諾。

如要吸引觀眾，請參考下列資源：

使用生態系統

很高興看到 Salesforce 和 CafeMedia 等公司積極提供關鍵意見，並開發第一方集合。這些研究人員對技術的進步貢獻良多。其他幾位使用者也分享了對第一方集合和 Chrome 與網路生態系統合作的看法：

「Chrome 正在開發第一方集合，以便配合許多使用情境，例如保留使用者歷程。這也證明 Google 團隊正在努力瞭解網站擁有者的需求。」- Mercado Libre

「我們 VWO 很感謝 Google 致力提升隱私權標準，同時確保處理真實的使用情境。很高興這個團隊與開發人員生態系統合作，並根據網站利益相關者的意見回饋，持續改善第一方集合方案的實作方式。我們很高興能參與這項提案的測試過程，也期待這項提案能納入瀏覽器。」- VWO 工程總監 Nitish Mittal