歡迎閱讀 Privacy Sandbox 中的 10 月進度版本，瞭解在 Chrome 中逐步淘汰第三方 Cookie 及致力打造更私密網路環境的各階段里程碑。我們每個月都會與您分享 Privacy Sandbox 時程的更新總覽，以及整個專案的最新消息。
活動
Chrome 開發人員高峰會將在 11 月 3 日舉辦。您將可以在主題演講中收到 Privacy Sandbox 的最新消息，並有機會向 AMA 的領導團隊提問，並在諮詢時間與工程團隊進一步詢問細節。歡迎立即報名，期待與您相見！
本月也舉辦了 W3C 年度大會 (通常稱為 TPAC)，在其中討論 W3C 中的所有不同團體，討論網路上各式各樣的主題。您可以在下方查看分組會議的分鐘數和影片，並查看包含 Privacy Sandbox 主題的特定講座。
後續會議賽季，IETF (網際網路工程任務小組) 將定期舉辦 112 年度線上技術人才。與 TPAC 類似，也有多個討論 Privacy Sandbox 主題的個別工作階段，例如 PRIV (隱私權保護評估價值)、PEARG (隱私權強化與評估研究群組) 以及 MASQUE (多重 xed Application Substrate over QUICEncryption) 工作小組。這些是關於通訊協定設計的技術性討論，如果您具備適當的專業知識，並有意參與這些討論，請考慮加入。
強化跨網站隱私權界線
第三方 Cookie 是實現跨網站追蹤的重要機制。可將其淘汰是重大的里程碑，但我們也得要解決其他的跨站位置儲存空間或通訊方式。
Federated Credentials Management API
Federated Credentials Management (FedCM) 提案是 WebID 更有意義的新名稱。聯合身分是網站的重要服務，但由於聯合身分在與其他網站共用身分資訊的明確有關，因此這類導入作業的詳細資料會與跨網站追蹤功能重疊。
聯合憑證管理提案探索了一系列選項，從現有解決方案的簡易遷移路徑，到以更私密的方式連線至服務，而且只提供最低限度的資訊。
本提案仍處於初期階段，您可以透過 W3C 的聯合身分社群群組追蹤討論內容。該團隊也在 TPAC 舉辦了分組 講座，其中探索了提案的總覽。Chrome 89 的標記後面還有一個早期的 API 原型版本，但僅供實驗之用，之後也會隨著討論進展而變更。
餅乾
當 Cookie 相關提案的進展時，您應稽核自己的 SameSite=None 或跨網站 Cookie，並規劃您必須在網站上採取的動作。
方塊
如果您要設定在跨網站結構定義中傳送的 Cookie，但以 1:1 關係 (例如 iframe 嵌入或 API 呼叫) 傳送，則應遵循 CHIPS 提案或具有獨立分區狀態的 Cookie。如此一來，您就能將 Cookie 標示為「分區」，並為每個頂層網站建立個別的 Cookie jar 檔案。
還在 CHIPS 上執行作業，雖然這項功能只能在 chrome://flags/#partitioned-cookies 和 --partitioned-cookies CLI 旗標的後端使用，因此尚未處於可完整測試的狀態。實作完成後，我們會提供更新的測試與偵錯詳細資料。
第一方集合
如果您為跨網站情境設定 Cookie，但只在您擁有的網站 (例如 .co.uk 使用的 .com 上) 代管服務，則應遵循第一方集合。 本提案定義了一種宣告方式，用來宣告您要組成組合的網站，然後將 Cookie 標示為「SameParty」，即可讓 Cookie 只針對該集合內的結構定義傳送。
您可以在 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 值區或其他形式的儲存空間或通訊 API，而這需要跨多個網站存取這些資料，那麼您應該追蹤這個主題，以利日後更新。
防範隱密追蹤
在減少明確跨網站追蹤的選項的同時，我們也必須解決網路平台中曝露識別資訊的區域，以免使用者數位指紋採集或隱密追蹤。
使用者代理程式字串縮減與 User-Agent Client 提示
我們已擴大來源試用範圍，測試 Chrome 的減少使用者代理程式格式，納入第三方嵌入。如果您主要為其他服務提供跨網站內容，可以在註冊來源試用時啟用第三方選項，以便在對資源的要求中取得縮減格式。
您可以追蹤減少 Chrome 使用者代理程式的完整時程，取得更多推出階段的範例與詳細資料。如果您使用平台版本、裝置，或是採用目前的 User-Agent 格式的完整建構版本資訊，您也必須遷移至 User-Agent Client Hints (UA-CH)。
我們將繼續為用戶端提示的現有名稱標準化，做法是新增缺少的 Sec-CH- 標頭前置字串。待核准，我們希望能擴大 UA-CH 的字元範圍。
顯示相關內容和廣告
在逐步淘汰第三方 Cookie 的同時，我們需要導入 API，允許需要仰賴這些 Cookie 的用途，但「不得」允許跨網站追蹤。
FLoC
FLoC 是一項提案，可讓您啟用按照興趣顯示的廣告，而不必進行個別的跨網站追蹤。我們一直在評估早期 FLoC 來源試用的意見回饋後，才能進行進一步的生態系統測試。在我們持續處理 FLoC 的後續步驟和決策時，您應該會看到與主題概念相關的探索程式碼 (先前經過參照)，很快就會出現在 Chromium 程式碼集中。Chrome 的所有開發作業都在公開階段進行，雖然這項作業都能顯示，但開發人員測試無法立即採取任何因應措施 (也不適用於使用者)。我們希望能繼續在新的 PATCG (私人廣告技術社群論壇) 中分享這些討論和更新內容。
評估數位廣告
除了不使用跨網站追蹤來顯示廣告之外，我們也需要隱私權保護機制，以便評估這些廣告的成效。
Attribution Reporting API
Attribution Reporting API 可讓您評估某網站上的事件 (例如點擊或觀看廣告)，並在不啟用跨網站追蹤功能的情況下，於其他網站完成轉換。
我們希望繼續測試 Attribution Reporting API，並打算將來源試用延長到 Chrome 97。目前的來源試用權杖已於 10 月 12 日到期，因此您需要套用更新過的權杖才能繼續測試。
打擊網路上的垃圾內容和詐欺活動
另一個挑戰是減少跨網站追蹤可用途徑的難題，在於這些數位指紋採集技術經常用於垃圾內容和詐欺防護。我們還需要可保護隱私權的替代方案。
信任權杖
Trust Token API 是一種提案，可讓某個網站針對訪客提出聲明 (例如「我認為這是人類」，並讓其他網站在不識別個人身分的情況下再次驗證該聲明)。
信任權杖是防範網路垃圾內容和詐欺行為的整體策略之一。在TPAC 網路反詐騙組織中，整個生態系統的代表提到了我們目前的一些挑戰和方法。
意見回饋：
我們會持續透過 Privacy Sandbox 發布這些每月更新和進度，因此請放心，開發人員可以取得所需的資訊與支援。如果您對本系列文章有任何需要改進的地方，歡迎透過 @ChromiumDev Twitter 告訴我們。我們會參考您輸入的內容繼續改善格式。
我們也新增了 Privacy Sandbox 常見問題。我們會根據您提交至開發人員支援存放區的問題，持續擴充相關資訊。如果您對任何提案的測試或實作有任何疑問，歡迎與我們聯絡。