歡迎參閱 10 月版的「Privacy Sandbox 進度報告」，瞭解 Chrome 逐步淘汰第三方 Cookie 的里程碑，以及我們致力打造更私密的網路環境。我們每個月都會分享 Privacy Sandbox 時間表的最新資訊，以及整個專案的相關消息。
活動
我們將自 11 月 3 日起舉辦 Chrome 開發人員大會。您可以在主題演講中取得 Privacy Sandbox 的最新資訊，並有機會在 AMA 中向領導團隊提問，也可以在辦公時間向工程團隊提出更詳細的問題。立即註冊，期待與您相會！
這個月也舉辦了 W3C 年度大會 (通常稱為 TPAC)，W3C 的各個團隊都會齊聚一堂，討論網路上的各種主題。您可以查看分組會議的時間和影片，以及下方列出的特定會議，其中包含 Privacy Sandbox 主題。
在會議季持續進行期間，IETF (網際網路工程任務組) 將舉辦定期的 112 線上技術全體會議。與 TPAC 類似，我們也安排了許多個別的會議，討論 Privacy Sandbox 主題，例如 PRIV (Privacy Respecting Incorporation of Values)、PEARG (Privacy Enhancements and Assessments Research Group) 和 MASQUE (Multiplexed Application Substrate over QUIC Encryption) 工作小組。這些是關於協定設計的深入技術討論，如果您具備相關專業知識，且有意參與這些討論，請考慮加入。
強化跨網站隱私界線
第三方 Cookie 是啟用跨網站追蹤的重要機制。逐步淘汰這些功能是重要的里程碑，但我們也需要解決其他形式的跨網站儲存或通訊問題。
Federated Credentials Management API
Federated Credentials Management (FedCM) 提案是 WebID 的新名稱，更能表達其意義。聯合身分識別是網際網路的重要服務，但由於這項服務明確是用於與其他網站分享身分識別的部分，因此實作細節與跨網站追蹤重疊。
聯合憑證管理提案會探討各種選項，從現有解決方案的簡單遷移路徑，到更私密的方法，以最少的資訊連線至服務。
這項提案仍處於初期階段，您可以前往 W3C 聯邦身分群組瞭解相關討論。這個團隊也在 TPAC 舉辦分組 工作坊，探討提案的概略說明。另外，Chrome 89 的旗標後方也提供API 的早期原型版本，但這只是實驗性質，隨著討論進展，這個版本也會有所變動。
Cookie
隨著 Cookie 相關提案的進度，您應檢查自己的 SameSite=None 或跨網站 Cookie，並規劃在網站上採取的行動。
CHIPS
如果您設定的 Cookie 是在跨網站情境中傳送，但處於 1:1 關係 (例如 iframe 嵌入或 API 呼叫)，則應遵循 CHIPS 提案，或使用具有獨立分割狀態的 Cookie。這樣一來，您就能將 Cookie 標示為「已劃分」，並將 Cookie 放入各個頂層網站的獨立 Cookie Jar 中。
CHIPS 的開發工作正在進行中，雖然這項功能已在 chrome://flags/#partitioned-cookies 和 --partitioned-cookies CLI 標記後方推出，但尚未處於可完全測試的狀態。實作作業完成後，我們會提供最新的測試和偵錯詳細資料。
第一方集合
如果您為跨網站情境設定 Cookie，但只跨越您擁有的網站，例如在 .com 上代管服務，而該服務由 .co.uk 使用，則應遵循第一方集合。這項提案定義了一種宣告方式，可讓您宣告要形成哪些網站組合，然後將 Cookie 標示為「SameParty」，以便只傳送該組合內的內容。
第一方集合可供本機開發人員測試，位於 chrome://flags/#use-first-party-set 和 chrome://flags/#sameparty-cookies-considered-first-party 標記後方，可讓您指定自己的相關網站集合，並在這些網站上進行 Cookie 行為實驗。
儲存空間分區
網頁平台包含其他形式的儲存空間，可能會啟用跨網站追蹤功能。在 TPAC 的「瀏覽器儲存空間分割狀態」專題討論會中，我們將概略說明 Chrome 的進度，並討論其他瀏覽器供應商的相關資訊。
開發人員目前不需要採取行動，但如果您使用 SharedWorker、Web Storage、IndexedDB、CacheStorage、FileSystem API、BroadcastChannel、Web Locks API、Storage Buckets 或其他形式的儲存或通訊 API，且需要在多個網站上存取資料，則應追蹤這個主題，以便瞭解日後的更新。
避免採用隱蔽的追蹤技巧
由於我們減少了明確跨網站追蹤的選項，因此也需要處理網路平台中會洩漏可用於指紋辨識或隱密追蹤使用者的身分資訊的部分。
使用者代理程式字串縮減和使用者代理程式用戶端提示
我們已擴大來源試驗，測試 Chrome 的簡化 User-Agent 格式，將第三方嵌入內容納入。如果您主要為其他服務提供跨網站內容，可以在註冊來源測試時啟用第三方選項，以便在要求存取資源時收到縮減格式。
您可以追蹤縮減 Chrome 使用者代理程式的完整時間表，並參考更多示例和推出階段的詳細資料。如果您需要使用目前 User-Agent 格式的平台版本、裝置或完整版本資訊，也必須改用 User-Agent Client Hints (UA-CH)。
我們會繼續將現有的用戶端提示名稱標準化，在缺少 Sec-CH- 標頭前置字串的地方加上該字串。我們希望在取得核准後，擴大 UA-CH 的 GREASE 字元範圍。
顯示相關內容和廣告
隨著我們逐步淘汰第三方 Cookie，我們需要推出 API，以便允許依賴第三方 Cookie 的用途，但不允許跨網站追蹤。
FLoC
FLoC 是一種提案，可讓您按照興趣顯示廣告，而不需要個別跨網站追蹤。我們先評估 FLoC 早期原生試驗的意見回饋，再進一步進行生態系統測試。我們會持續處理 FLoC 的後續步驟和決策，您很快就會在 Chromium 程式碼庫中看到一些關於主題概念的探索性程式碼 (先前參照)。由於 Chrome 的所有開發作業都是公開進行，因此這項工作會公開顯示，但開發人員無法立即採取任何行動 (這也不適用於使用者)。我們希望繼續在新的 PATCG (Private Advertising Technology Community Group) 中分享這些討論和更新。
評估數位廣告
為了搭配不含跨網站追蹤功能的廣告放送，我們需要使用隱私權保護機制來評估這些廣告的成效。
Attribution Reporting API
Attribution Reporting API 可讓您評估某個網站上的事件 (例如點按或瀏覽廣告)，進而導致另一個網站上的轉換，而無需啟用跨網站追蹤。
我們希望繼續測試 Attribution Reporting API，並計劃延長來源試用期至 Chrome 97。目前的來源測試權杖已於 10 月 12 日到期，因此您必須申請更新的權杖，才能繼續進行測試。
打擊網路垃圾內容和詐欺行為
當我們減少可用於跨網站追蹤的途徑時，另一個挑戰是，這些相同的指紋採集技術通常用於防範垃圾內容和詐欺。我們也需要隱私權保護的替代方案。
Trust Tokens
Trust Token API 是一種提案，可讓一個網站分享有關訪客的聲明，例如「我認為他們是人類」，並讓其他網站驗證該聲明，而無須識別個別使用者。
信任權杖是整體策略的一部分，可用來解決網路上的垃圾內容和詐欺問題。在 TPAC 的「網站防詐」專題中，來自整個生態系統的代表討論了目前的部分挑戰和方法。
意見回饋
我們會持續發布這些每月更新內容，並持續推動 Privacy Sandbox 計畫，希望確保開發人員能取得所需資訊和支援。如果您認為我們有需要改進之處，請透過 @ChromiumDev Twitter 告訴我們。我們會根據你的意見持續改善格式。
我們也新增了 Privacy Sandbox 常見問題，並會根據您提交至 開發人員支援存放區的問題持續擴充內容。如果您對任何提案的測試或實作方式有任何疑問，歡迎與我們聯絡。