2025 年第 2 季季報，彙整了我們收到的 Privacy Sandbox 提案生態系統意見回饋，以及 Chrome 的回應。
Google 依據第 12、17(c)(ii) 和 32(a) 段的規定，準備這份季度報告，以履行對英國競爭及市場管理局(簡稱「CMA」) 的承諾。這份報告涵蓋 Google 在 Privacy Sandbox 提案方面的進展、更新的時間預期、Google 如何考量第三方觀察結果的實質說明，以及 Google 與 CMA 互動的摘要，包括 CMA 的意見回饋和 Google 處理意見回饋的方式。
Google 一直在定期狀態會議中向 CMA 匯報 Privacy Sandbox 提案的進展，這些會議是依據承諾第 17(b) 段的規定安排。此外，這個團隊也維護開發人員說明文件，提供核心私密廣告功能和 Cookie 變更的總覽，以及 API 實作和狀態資訊。重要更新會發布在開發人員網誌，並透過個別開發人員郵寄清單分享相關更新。
考量第三方觀察結果
縮寫字詞彙表
- ARA
- Attribution Reporting API
- CHIPS
- 具有獨立分區狀態的 Cookie
- DSP
- 需求端平台
- FedCM
- Federated Credential Management
- IAB
- 美國互動廣告協會
- IDP
- 身分識別提供者
- 網際網路工程任務組 (IETF)
- 網際網路工程任務組
- IP
- 網際網路通訊協定地址
- openRTB
- 即時出價
- 延長賽
- Origin Trial
- PA API
- Protected Audience API (舊稱 FLEDGE)
- PatCG
- 私人廣告技術社群群組
- RP
- 信賴方
- RWS
- 相關網站集合 (舊稱「第一方集合」)
- SSP
- 供應端平台
- UA
- 使用者代理程式字串
- UA-CH
- User-Agent Client Hints
- W3C
- 全球資訊網協會
- WIPB
- 蓄意視而不見
一般意見回饋，不涉及特定 API/技術
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| Privacy Sandbox 的未來 | 由於我們已宣布不會推出第三方 Cookie 的使用者選擇機制，因此在有第三方 Cookie 的情況下，部分 API 會比其他 API 更有用，而其他 API 則需要經過演進才能發揮效用。除了 Privacy Sandbox API，Chrome 還有其他潛在的投資領域。 | 感謝您提供意見。我們將持續與利害關係人合作，評估 Privacy Sandbox API 在未來可扮演的角色，並根據 Google 於 2025 年 4 月發布的公告，探索未來可投資的新領域。公告指出，我們將維持目前的做法，讓使用者選擇是否允許 Chrome 使用第三方 Cookie。 |
| Privacy Sandbox | 部分生態系統參與者對這項公告感到失望，因為這代表我們不會繼續導入第三方 Cookie 的使用者選擇機制，但他們對已完成的工作感到自豪，也感謝 Privacy Sandbox 帶來的技術挑戰，並強調與 Chrome 合作關係的價值，以及市場測試補助金的實用性。 | 感謝您提供意見回饋。我們同意 Chrome 可以也應該與開發人員合作，共同開發技術，在改善線上隱私權的同時，維持含廣告的網際網路環境。 |
| 瀏覽器資料共用 | 瀏覽器中介資料共用技術極具吸引力，有助於解決市場效率不彰和信任問題。瀏覽器具有值，可做為協作的第三方執行環境。 | 感謝您提供意見。我們同意 Chrome 可以也應該協助開發人員建立技術，增進協作開發人員和使用者之間的信任感。 |
| Chrome 流量 | Chrome 無 Cookie 流量的比例，以及無痕模式流量的比例為何？ | 正如英國競爭及市場管理局 (CMA) 在「有意發布承諾的通知」中所述，無痕模式只會影響一小部分的瀏覽活動。在英國和歐洲經濟區，Chrome 無痕模式的代表性為：在搭載 Android 作業系統的裝置上，無痕模式的導覽次數不到 10%；在搭載 Windows 作業系統的裝置上，無痕模式的導覽次數不到 10%。這些指標僅指英國和歐洲經濟區內，以 Chromium 為基礎的 Chrome 瀏覽器導覽。 我們不會分享封鎖第三方 Cookie 的瀏覽器資料。 開發人員可使用 Storage Access Headers 決定 Cookie 的分割時間，並視情況採取可用的因應措施。 |
| Chrome 測試標籤 | Chrome 於 2024 年啟用 1% 的無 Cookie 流量進行測試，這項計畫的後續發展為何？ | 我們目前沒有計畫分享，但我們打算在可用的時候公開分享。 |
| Chrome 測試 | 目前的測試標籤設定是否包含適用於以下情境的處理方式：第三方 Cookie 和 Privacy Sandbox API 皆可用，且 Privacy Sandbox API 已啟用？ | 目前的測試標籤設定包含 3PC 和 Privacy Sandbox API 的處理方式，也就是模式 A。 |
| Privacy Sandbox | 部分廣告主認為 Privacy Sandbox API 相當複雜，且由於先前的準備工作，他們對此感到冷漠，並質疑如何量化早期採用者的優勢，同時尋求有關再行銷、開發新客和評估效果的教育資源。 | 感謝您提供意見回饋，我們瞭解您對技術複雜度和準備練習的感受。 就瞭解目前 Privacy Sandbox 技術的成效而言，我們的測試結果顯示，生態系統參與是瞭解 Privacy Sandbox 解決方案成效的關鍵因素。低用量測試無法重現市場動態，也無法模擬大規模使用技術的誘因。 |
註冊與認證
本季未收到任何意見回饋。
顯示相關內容和廣告
主題
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 改良版 Topics API 的效能和實用性 | 買方利害關係人的意見回饋指出，Topics API 是有價值的信號，且廣告主廣告活動的千次曝光出價 (CPM) 資料，與第三方 Cookie 目標對象的資料相比毫不遜色。部分發布商認為 Topics API 的信號品質優於標準開放式網路信號。根據這項對 Topics API 實用性的意見回饋，利害關係人要求進行強化，例如提高分類法擬真度、一致性，以及擴大發布商控制項，以推動更廣泛的採用。 | Google 於 2025 年 4 月宣布，目前在 Chrome 中提供第三方 Cookie 選擇權的做法將維持不變，因此我們正在評估 Privacy Sandbox API 未來的角色，並將這些意見回饋納入考量。 |
| 對不同類型的利害關係人來說是否實用 |
由於主題分類器目前只會使用網頁主機名稱定義相應主題，因此內容多元的大型網站會提供一般主題，小型網站則會提供廣告價值較高的利基主題。 | 我們的回應與前幾季類似： 與第三方 Cookie 相同，不同網站提供的資訊價值也有所差異。利基興趣網站的價值貢獻不一致：並非所有利基興趣網站都有商業價值高的內容，因此貢獻的價值較少。這些網站將受益於 Topics API。我們已考慮過以網頁層級而非網站層級進行分類的可能性，但這類分類會造成許多重大的隱私權和安全性問題。 |
| 主題分類不夠精細 | 對於在單一網域中提供多元內容的發布商，Topics API 的精細程度不足，可能限制了 API 在廣告指定目標方面的實用性。 | Google 於 2025 年 4 月宣布，目前在 Chrome 中提供使用者第三方 Cookie 選擇權的做法將維持不變，因此我們正在評估 Privacy Sandbox API 未來的角色，並將這些意見回饋納入考量。 |
| 分類器改良 | 允許發布商授予 Chrome 權限，根據網頁內容 (例如標題、內文) 分類主題。 | 我們正在考慮這項要求，歡迎在這裡提供其他意見。 |
| 政策 | 請說明使用 Topics API 時，如何搭配第三方 Cookie 資訊。 | Topics API 和 3PC 都能順利運作，因為 Topics API 提供的功能是 3PC 的子集。 |
| 觀察瀏覽主題標頭 | 要求釐清 Observe-Browse-Topics 標頭的實作方式，特別是持續傳回標頭是否會導致問題。 | 持續傳回 Observe-Browse-Topics: ?1
標頭不會造成任何技術問題。瀏覽器會有效處理這項信號，只會記錄網頁造訪符合主題計算資格，不會造成重複或錯誤。雖然並非每個網頁都必須傳送，但建議您在所有頂層文件中，將其做為標準標頭傳送，這是簡單又有效的方法。 |
| 分類類別 | 要求使用新主題更新最新主題分類。 | 我們正在考慮這項要求，歡迎生態系統在這裡提供其他意見。 |
| 空值 | 要求提供指引，說明如何提升 Topics API 的效能，以及瞭解空值回應的原因，例如篩選或敏感度。 | 為求清楚，Topics API 傳回 null 或空白回應是預期的隱私權功能，並非錯誤。null 回應可能的原因：• 隱私權規則：5% 的隨機 null
機率，或因為您的指令碼未「觀察」使用者在與該主題相關網站上的行為。• 使用者狀態：瀏覽記錄不足、使用無痕模式，或使用者已在 Chrome 的廣告隱私權設定中停用這項功能。 • 技術錯誤：發布商網站必須傳送 Observe-Browse-Topics: ?1 標頭，且任何呼叫 iframe 都需要 allow="Browse-topics"
權限。如要進行調查，請使用 chrome://topics-internals偵錯
頁面，查看瀏覽器計算出的主題和原因。隱私權功能會導致刊登率無法達到 100%，但您可以採取下列措施來提升成效： • 與發布商合作：確保合作夥伴在網站上正確傳送 Observe-Browse-Topics: ?1 標頭。• 驗證程式碼：如果您使用 iframe，請確認已設定 allow="Browse-topics" 政策。 |
Protected Audience API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 成本和複雜度阻礙 PA API 採用率 | 採用者會降低 Protected Audience API (PA API) 整合的優先順序或回溯，理由是營運成本、廣告主需求不足，以及交易所的廣告空間量偏低。 部分意見回饋提到 PA API 的潛在優勢，例如可提供永久性目標對象，以及因比對率高而能觸及更多使用者。 |
Google 於 2025 年 4 月宣布，目前在 Chrome 中提供使用者第三方 Cookie 選擇權的做法將維持不變，因此我們正在評估 Privacy Sandbox API 未來的角色，並將這些意見回饋納入考量。 |
| 跨平台功能 | 應利用跨平台的 PA API 支援跨平台功能，以解鎖更強大的再指定目標和目標對象指定功能。Google 應允許在原生環境或 WebView 中放送廣告時，存取 Chrome 中註冊的興趣群組 (IG)，並在 Chrome 競價中提供 Android 註冊的興趣群組。 | Google 於 2025 年 4 月宣布，目前在 Chrome 中提供使用者第三方 Cookie 選擇權的做法將維持不變，因此我們正在評估 Privacy Sandbox API 未來的角色，並將這些意見回饋納入考量。 |
| directFromSellerSignals | 限制情境式競價中可用的資訊量，競價參與者一律會透過 Google 的廣告伺服器進行放送。發布商必須先呼叫所有 Ad Exchange 合作夥伴，
然後呼叫 Google Ad Manager (GAM) 執行情境競價，
最後允許 GAM 叫用 IG 競價。如果無法即時得知脈絡競價的結果，任何競爭對手都無法公平地協調頂層決策。 PA API 中的 directFromSellerSignals 功能可能缺乏競價資訊的透明度，進而妨礙存取必要資料。Google 應移除 directFromSellerSignals，或更新該信號，確保無法用來隱藏廣告伺服器的競價結算價格。舉例來說，情境價格可透過 Chrome 傳遞，方法是使用透明、不可變動的簽署欄位，所有競價參與者 (和發布商) 都能存取及驗證。 |
我們的回覆與前幾季相同： Chrome 回覆： 除非賣家從自己的 iframe 呼叫 runAdAuction()，否則傳遞至 runAdAuction() 的資訊不會來自賣家。在多位賣家的競價中，所有賣家都無法建立呼叫 runAdAuction() 的影格。directFromSellerSignals 會從賣家來源載入的子資源套件載入內容，解決這個問題。這可確保從賣方競價設定傳遞至競價的資訊真實性與完整性不會遭到竄改。如果發布商想使用 PA API 瞭解技術供應商傳遞至 PA 競價的任何資訊，可以向這些技術供應商要求提供這項功能。 Google Ad Manager 回應： 多年來，我們一直非常重視競價公平性，包括承諾不會在其他買方參與競價前，向對方透露發布商任何無保證廣告來源的價格，包括無保證委刊項價格。我們隨後也在對法國競爭主管機關的承諾中重申這項原則。 對於 Protected Audience 競價，我們打算運用 directFromSellerSignals 履行承諾，且在多個賣方競價結束前，不會向任何其他競價參與者透露任何競價參與者的出價。如這篇更新所述，我們不會與自家元件競價分享脈絡競價的價格。 |
| 報表 | 要求新增分析/報表實體，以啟用集中式報表功能。 | 我們正在這裡討論這項要求，歡迎提供更多意見。 |
| 買方報表 ID 的 k-anonymity | 可根據「buyerReportingId」的 k 匿名性捨棄出價，方便您收錄目標對象，並履行與第三方資料供應商的報表義務。 | Google 於 2025 年 4 月宣布，目前在 Chrome 中提供使用者第三方 Cookie 選擇權的做法將維持不變，因此我們正在評估 Privacy Sandbox API 未來的角色，並將這些意見回饋納入考量。 |
| 改善 generateBid 指令碼的偵錯功能 | 要求機制，以便在 generateBid 指令碼中快速找出程序失敗的特定階段或「中斷點」。 | 我們瞭解您希望將即時評估做為裝置端競價的斷點設定機制。Google 於 2025 年 4 月宣布，目前在 Chrome 中提供第三方 Cookie 選擇權的做法將維持不變，因此我們會將這些意見納入考量，評估 Privacy Sandbox API 未來的角色。 |
| 監控 runAdAuction 狀態的事件監聽器 | 建議在 PA API 的 navigator.runAdAuction 函式中新增事件監聽器支援功能，以改善廣告競價生命週期的監控作業。 | 我們正在評估這項要求，也歡迎生態系統在此提供其他意見。 |
| API 使用方法 | 請說明在沒有第三方 Cookie 的情況下，PA API 和 Attribution Reporting API (ARA) 如何支援網路廣告用途，特別是針對已停用第三方 Cookie 但未停用 Privacy Sandbox API 的使用者，以及涉及 Cookie 同步失敗和 WebView 的情境。 | Google 於 2025 年 4 月宣布，目前在 Chrome 中提供使用者第三方 Cookie 選擇權的做法將維持不變，因此我們正在評估 Privacy Sandbox API 未來的角色，並將這些意見回饋納入考量。 |
| 延遲時間 | 如果 PA API 延遲時間過長，發布商可能會選擇停用 PA API，進而阻礙採用。 | 過去幾季，我們對裝置端延遲進行了多項改善。視需要持續建構及擴展出價和競價 (B&A) 服務。我們更新了延遲最佳做法指南，加入更多關於如何善用這些功能的資訊。我們也正在探索如何開發新的延遲改善功能，部分功能可參閱這裡。 |
| B&A 中的記錄行為 (測試與正式版) | 釐清 B&A 服務在測試和正式版模式下的記錄行為差異。具體來說，就是雲端記錄的可用性，以及生產模式對記錄的影響。 | 首先，請務必區分正式版與非正式版建構作業，以及個別的 TEST_MODE 參數，後者只會啟用硬式編碼的測試加密金鑰。以下說明著重於建構類型。 在非正式版中，B&A 伺服器提供可設定的記錄詳細程度。這些詳細記錄會寫入標準 stdout/stderr 串流。在 Google Cloud 中，您可以透過原生記錄介面存取這些記錄；在 Amazon Web Services 中，則可在附加的控制台記錄中找到這些記錄。 如果是正式版建構作業，記錄行為會受到更多限制。詳細程度層級是固定的，無法變更。雖然系統仍會將部分與隱私權無關的記錄 (例如伺服器啟動訊息和大多數當機錯誤) 列印至 stdout/stderr，但您無法透過這個管道取得特定要求記錄。只有包含同意偵錯權杖的要求，才會產生每個要求的記錄，且這些記錄只會透過 OpenTelemetry 匯出。請謹慎使用同意聲明偵錯功能，因為大量流量可能會導致伺服器效能降低，並導致健康檢查失敗。 所有指標都會透過 OpenTelemetry 匯出。系統一律會直接匯出非隱私權敏感指標，不會加入任何「雜訊」。反之，從以生產模式執行的伺服器匯出隱私權敏感指標時，一律會「加入雜訊」。具體遙測設定會決定是否要匯出這些隱私權敏感指標，以及匯出時是否要加入雜訊。 |
| 在品牌安全受信任的出價信號中加入完整網頁路徑 | 要求更新 PA API，在 fetch 請求中加入頂層網頁的完整網址路徑，以及主機名稱，以取得 trustedBiddingSignals。 主要用途是啟用更精細的品牌安全控制選項。廣告主通常需要禁止廣告顯示在網域的特定部分 (例如 news-site.com/politics)，但一般來說，他們對該網域沒有意見。由於這些封鎖清單可能包含數百萬個項目，因此必須在伺服器端進行評估。目前的規格只會傳送主機名稱，因此 trustedBiddingSignals 伺服器無法執行這項必要的路徑層級評估，進而限制品牌安全功能。 |
我們目前正在這裡討論這個問題，
先前已進行過多次討論，可參閱這裡，
歡迎提供其他意見。 不過，我們想澄清的是，只有在 trustedBiddingSignals 擷取作業要前往在受信任的執行環境 (TEE) 內執行的伺服器時，我們才會考慮加入這項資訊。 |
受保護的競價 (出價和競價服務)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 測試可用性 | 有關在 Chrome 和 B&A 環境中測試鍵/值 (KV) v2 的資訊。 | KV v2 同時適用於 B&A 和 Chrome。如需其他指引，請參閱這個頁面。 |
| KV 伺服器實作 | 請說明 KV 伺服器的用途，特別是將廣告素材的算繪網址對應至要求資料、SSP 和 DSP 是否需要協調定義算繪網址中的參數，以及是否有文件說明 KV 模式中所需的協調作業和資料儲存。 | KV 服務會使用 renderURL 做為鍵。如果是新網址，系統會儲存。如果存在，系統會傳回其值，供 scoreAd 使用。傳回格式取決於設定：「自備伺服器」(BYOS) 允許任何值，而「受信任的 KV 服務」則需要使用者定義函式。 雖然不一定需要與 DSP 協調，但如果想使用巨集替換等功能 (例如 ${AD_WIDTH})，可動態自訂及驗證廣告。 建議先使用一個 DSP 進行簡單測試，判斷必要的協調層級。我們也正在更新 KV 文件，完成後會公開分享。 |
| B&A 的 BYOS | 為什麼 B&A 沒有提供類似 KV 的 BYOS 模式？ | B&A 需要 TEE，因此無法使用 BYOS 模型，因為 B&A 會處理高度機密的資料組合，需要強制執行隱私權機制，詳情請參閱下文。 DSP： B&A 會處理發布商環境 (如果賣家透過 auctionSignals / perBuyerSignals 明確傳送，則可能為完整網址)，並結合詳細的使用者 IG 資料。TEE 可安全地處理這項組合，並防止使用者重新識別身分，因此至關重要。在 KV BYOS 中，無法傳送完整網址。 對於供應端平台： 光是知道競價中參與的 IG 組合 (以及其需求端平台擁有者)，就能產生識別簽章。這時就要使用干擾解決方案，但必須使用 TEE。 因此，安全處理這些合併的敏感信號，以及強制執行隱私權機制，都需要 TEE 的受控認證環境。 |
評估數位廣告
Attribution Reporting (和其他 API)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 噪音政策 | 對部分市場參與者而言，導入 ARA 很有價值，Google 應繼續提供事件層級的報表。如果 ARA 和第三方 Cookie 皆可使用，Google 應考慮放寬噪音政策。成效廣告主越來越常使用 ARA 彈性事件的現行「value」欄位實作方式，而較寬鬆的雜訊政策有助於減少延遲和不準確的報表。 | 這項機制是 ARA 設計的基礎部分，目的是防止追蹤個別使用者，藉此保護使用者隱私。Google 於 2025 年 4 月宣布，Chrome 將維持目前的做法，讓使用者選擇是否允許第三方 Cookie。有鑑於此，我們會持續評估 Privacy Sandbox API 未來的角色，以及任何潛在的未來強化功能，同時考量因干擾而導致的報表問題。 |
| 發展藍圖和長期支援 | 要求提供 ARA 產品發展藍圖，並確認長期投資和支援，因為 Google 已宣布不會為第三方 Cookie 導入使用者選擇機制。 | Privacy Sandbox 團隊正與生態系統互動，瞭解 Privacy Sandbox API 未來的角色，並評估未來的投資。 |
| 跨環境評估 (應用程式到網站) | 要求採用 ARA 解決方案，以利跨環境評估，提供更簡潔可靠的資料流程，並提升連結不同平台使用者互動的能力。 | ARA 已支援在同一部裝置上進行應用程式到網站的轉換。如要進一步瞭解跨應用程式和網站評估解決方案，請參閱這篇文章 和這篇文章。 |
| 跨瀏覽器歸因 | 如果能以統一的跨瀏覽器方式進行 ARA，將可大幅提升評估公開網路上投資報酬率的能力，並在法規可能異動前，提供穩定的替代方案。Chrome 應與 Safari 團隊合作，共同開發這類解決方案。 | 我們已在 W3C 的 PATCG 和 PATWG 群組中，與其他瀏覽器供應商共同探索可互通的 API。請注意，這項工作尚處於初步階段，相關人員歡迎在此查看進度。 |
| 跨裝置/離線評估 | 無法在 ARA 中支援跨裝置轉換評估，是相當大的限制。評估線上到離線的轉換也十分重要，瀏覽器可與評估供應商合作，共同完成這項工作。 | Google 於 2025 年 4 月宣布，目前在 Chrome 中提供使用者第三方 Cookie 選擇權的做法將維持不變，因此我們正在評估 Privacy Sandbox API 未來的角色，並將這些意見回饋納入考量。 |
| 多接觸點歸因分析 | 要求允許廣告主使用 Privacy Sandbox 資料做為公正的「基本資料」，藉此驗證及校正現有的歸因模式。為此，您可以將 ARA 瀏覽器提供的資料做為可靠的校正信號，建立事實基準。 | Google 於 2025 年 4 月宣布，目前在 Chrome 中提供使用者第三方 Cookie 選擇權的做法將維持不變，因此我們正在評估 Privacy Sandbox API 未來的角色，並將這些意見回饋納入考量。 |
| 未取得同意聲明/已選擇不接受追蹤的流量評估 | 保護隱私權的解決方案 (例如 Interoperable Private Attribution) 可評估未取得同意聲明的流量。這樣一來，即使使用者選擇不接受追蹤，您也能納入相關資料，更全面地瞭解廣告活動成效，解決同意聲明規定造成的重大評估缺口。 | Google 於 2025 年 4 月宣布，目前在 Chrome 中提供使用者第三方 Cookie 選擇權的做法將維持不變，因此我們正在評估 Privacy Sandbox API 未來的角色，並將這些意見回饋納入考量。 |
| 伺服器對伺服器歸因 | 要求允許廣告技術採用更靈活的方式整合 ARA，以支援難以完全在用戶端管理的使用情境，同時維護使用者隱私權。 | Google 於 2025 年 4 月宣布，目前在 Chrome 中提供使用者第三方 Cookie 選擇權的做法將維持不變，因此我們正在評估 Privacy Sandbox API 未來的角色，並將這些意見回饋納入考量。 |
| 多網域註冊 | 想進一步瞭解使用 ARA 註冊多個網域時的限制和注意事項，特別是關於匯總服務和跨來源歸因。 | 使用 ARA 搭配多個網域時，主要限制如下： • 歸因範圍僅限單一來源。您無法將某個網域的點擊與另一個網域的轉換配對。來源和觸發事件的歸因作業都會受到沙箱限制，只能在相同來源中進行。 • 匯總服務不支援多來源批次處理。不同來源的報表必須分批處理。我們正在研究日後支援這項功能的方法。 簡而言之，雖然一個實體可以註冊多個網域，但目前所有 ARA 函式 (例如歸因和匯總) 都必須以來源為單位處理。 |
匯總服務
本季未收到任何意見回饋。
Private Aggregation API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 限制和噪音程度 | 對 Private Aggregation API 匯總鍵大小和匯總值限制的疑慮。 | 我們選擇的匯總鍵和值大小，可提供高精細度，同時限制網路和儲存空間成本。此外，我們建議您在指派鍵時使用雜湊，盡量提高彈性。 雖然還有其他因素可保護使用者資料，但加入干擾因子是 Private Aggregation API 隱私權保護機制的重要一環。 我們會考量這些意見，並持續評估合適的參數選項，同時考量 Privacy Sandbox API 在未來扮演的角色，因為 Google 已於 2025 年 4 月宣布，目前在 Chrome 中提供使用者第三方 Cookie 選擇權的做法將維持不變。 |
| 隱私權與實用性 | Privacy Sandbox 的方法可能會優先考量隱私權而非實用性，進而阻礙採用。建議在取得使用者同意聲明後，允許更精細的資料共用，以改善評估和廣告個人化功能。 | 我們選擇的匯總鍵和值大小，可提供高精細度，同時限制網路和儲存空間成本。此外，我們建議您在指派鍵時使用雜湊，盡量提高彈性。 Google 於 2025 年 4 月宣布，Chrome 將維持目前做法，讓使用者選擇是否允許第三方 Cookie。我們正在評估 Privacy Sandbox API 在這方面扮演的角色，並會將這些意見回饋納入考量。 |
限制隱密追蹤
縮減使用者代理程式/使用者代理程式用戶端提示
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 垃圾內容偵測 | 如果網站使用垃圾內容偵測系統，且第一個要求依賴用戶端提示，追蹤或偵測系統可能無法識別或正確分類要求。 | 如果用途需要存取第一個要求中的 User-Agent Client Hints (UA-CH)，請使用重要 Client Hints。 |
| API 意見回饋 | 建議您將 Sec-CH-USA-Wow64 設為已淘汰，因為這項資訊已不適用於現代網路。 | 我們正在考慮這項要求，也歡迎您在這裡提供其他意見。我們也收到意見回饋，指出將 wow64 擴展到 Windows 以外的平台會很有用。 |
IP 保護 (原稱 Gnatcatcher)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 控制項 | 要求網站在無痕模式以外選擇性使用 IP 保護切換鈕。 | 感謝你提供意見，歡迎按這裡針對這個問題提供更多想法。 |
| 不當行為 | 如果機率性揭露權杖 (PRT) 導致值為 NULL，警方要求揭露平台不當行為的 IP 位址時，是否就無法識別行為人？ | 如果網域專門用於偵測詐欺和濫用行為，則可能不會納入遮蓋網域清單 (MDL)，因此不會受到 IP 保護功能影響。因此，這些網域不需要 PRT。 如果網域包含在 MDL 中，目前只能透過 PRT 瞭解代理要求的原始 IP 位址。由於 PRT 專為支援匯總分析而設計，而非用於識別個人，因此在大多數情況下，PRT 不會包含 IP 位址。不過，由於 IP 保護功能僅適用於第三方情境，因此我們預期這項異動對上述情況的影響有限。也就是說，發布商仍會收到第一方互動的未經 Proxy 處理 IP 位址，例如使用者造訪線上平台的網站。 |
| 反詐欺 | Google IP 保護防詐欺措施的具體內容為何？包括限制存取 Proxy 和核發驗證權杖的詳細資訊，以及 PRT 的具體用途。 | 我們確認 IP 保護功能中的頻率限制和驗證權杖，是為了防止機器人過度存取 Proxy 而進行廣告詐欺，詳情請參閱防範詐欺和垃圾內容策略。如要進一步瞭解 PRT 的用途，請參閱這份 PRT 說明文件。 |
| 無痕模式 | IP 保護功能是否仍預計在第 3 季推出無痕模式版本？ | 目前 IP 保護功能在無痕模式中推出的時間表 (第 3 季) 沒有變動。 |
跳轉追蹤因應措施
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| API 意見回饋 | 套用彈跳追蹤防範措施 (BTM) 時，Chrome 應封鎖 Cookie/儲存空間存取權，而非進行分割，因為 Safari 的「分割」方法會導致非預期的行為和混淆。 | 我們很歡迎這項建議。目前 BTM 不會進行 Cookie/儲存空間分割，而是在寬限期過後刪除。如果日後 BTM 的設計涉及對 Cookie 採取立即行動，我們打算優先封鎖 Cookie，而非進行分割。 |
強化跨網站隱私界線
相關網站集合 (舊稱「第一方集合」)
本季未收到任何意見回饋。
Fenced Frames API
本季未收到任何意見回饋。
Shared Storage API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| API 功能要求 | 要求在共用儲存空間中附加廣告瀏覽和點擊次數。 | Google 於 2025 年 4 月宣布，目前在 Chrome 中提供使用者第三方 Cookie 選擇權的做法將維持不變，因此我們正在評估 Privacy Sandbox API 未來的角色，並將這些意見回饋納入考量。 |
CHIPS
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| API 問題 | 要求說明 Chrome 的第三方 Cookie 控制選項如何與 CHIPS 互動，特別是停用第三方 Cookie 時，非分割 Cookie 是否會轉換為分割 Cookie，以及分割 Cookie 是否會保持啟用狀態。 | 如果停用第三方 Cookie，系統就不會在第三方環境中儲存、擷取或傳送未分割的 Cookie。不過，分割區 Cookie 仍會在第三方環境中儲存、擷取及傳送，因為停用第三方 Cookie 的瀏覽器設定不會影響分割區 Cookie 的功能。 |
| 隱私權疑慮 | 擔心具有永久 ID 的嵌入式第三方 (例如單一登入) 即使使用分割區 Cookie，仍可能讓嵌入式和嵌入式第三方取得全域數位 ID。 | 嵌入式第三方可能會有持續性 ID，但如果這個 ID 儲存在已分區的 Cookie 中，就只能在嵌入式第三方設定 Cookie 的網站上存取。跨網站加入這個 ID 需要登入動作，即使不使用分割 Cookie，登入動作也允許以驗證權杖的形式交換 ID。 |
FedCM
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| API 使用方法 | 如果使用者有多個帳戶，且沒有特定錯誤，則無聲中介服務會失敗。 | 這是刻意設計的功能，因為無聲中介服務適用於只有一個可用帳戶的特定情況。建議改用「選用」中介服務，如果無法進行無聲中介服務，FedCM 會改為向使用者顯示帳戶選擇器。 |
| API 使用方法 | navigator.credentials.get 會傳回一般錯誤，因此無法擷取特定拒絕原因，例如使用者關閉或冷卻期。 |
開發人員無法區分使用者關閉 FedCM 對話方塊、發生網路錯誤，以及 FedCM 處於「冷卻期」(因為使用者先前關閉了對話方塊)，這也是一項設計功能，旨在保護使用者隱私。這項功能可能會讓網站推斷使用者在不同身分識別提供者 (IdP) 的登入狀態。 |
| 登入 | 我們發現，登入多個帳戶時，帳戶選取行為不一致。 | 目前尚不清楚在多個已登入帳戶的情況下，間歇性無法選取特定帳戶，是 FedCM 的間歇性錯誤，還是測試系統的問題。我們正在與回報者合作解決這個問題，並要求提供更多詳細資料，以便深入瞭解問題。 |
| API 使用方法 | 如果使用者在透過 FedCM 授權時關閉對話方塊，系統不會透過可擷取的錯誤回報使用者處於冷卻狀態。 | 是的，這會產生一般錯誤代碼，以維護使用者隱私。 |
| API 使用方法 | 為什麼 FedCM 在成功「自動重新驗證」後，會進入 10 分鐘的靜止期？ | 由於自動重新驗證是在使用者未發起動作的情況下進行，如果使用者想返回網站，但要使用其他帳戶登入，就必須等待一段時間，讓 FedCM 不會自動重新驗證。「靜止期」可讓使用者有機會手動登入其他帳戶。如要進一步瞭解這段「靜止期」，請參閱這篇網誌文章。 |
| 輕量型 FedCM | 輕量型 FedCM 提案會導致 IdP 必須支援兩種不相容的實作方式 (FedCM 與輕量型 FedCM)，因此會增加複雜度。 | 輕量型 FedCM 與傳統 FedCM 相容。身分識別提供者可以選擇要使用哪種實作方法，不必同時支援兩種方法。 輕量型 FedCM 是 FedCM 的推送機制。如果 IdP 選擇使用這項功能，就能在使用者登入時將帳戶資訊推送至瀏覽器，這樣一來，當依賴方 (RP) 叫用 FedCM 時，系統會從瀏覽器擷取帳戶，而不是從 IdP 的帳戶端點擷取。 |
| 輕量型 FedCM | 擔心輕量型 FedCM 提案會將使用者姓名、電子郵件地址和個人資料相片等個人資料洩漏給 RP。 | 收到這項意見回饋後，我們已更新輕量型 FedCM 提案，從方法回應中移除名稱、電子郵件地址和個人資料圖片。 |
| 輕量型 FedCM | 在 Lightweight FedCM 提案中，管理多個已登入帳戶似乎過於僵化。提案目前不支援個別工作階段生命週期，或每個帳戶的細微登入狀態。 | 目前，憑證物件中的 IdP 會決定到期時間。我們已將帳戶到期日列為開放式問題，並會在日後的開發作業中考量這項意見回饋。 |
| 輕量型 FedCM | 「已登入」和「可供選取」之間的區別不明確，可能會影響 Lightweight FedCM 提案的使用者體驗。 | 我們目前不支援在 FedCM 使用者介面 (UI) 中，區分帳戶是否已登入。系統不應列出已登出的帳戶。 如果帳戶已登出但仍列在清單中，且使用者選取未主動登入的帳戶，則可使用 Continuation API 讓使用者重新登入。 |
| API 使用方法 | given_name 欄位在 getUserInfo 中與在 FedCM UI 中的用法不一致。 |
我們已在這裡與 Mozilla 進一步討論這個問題，以便就 given_name 在 getUserInfo 中的處理方式達成共識。 |
| API 使用方法 | 並非所有 IdentityProviderAccount 中 UI 使用的欄位都會提供給 getUserInfo，尤其是 tel 和 username，這表示需要同步處理。 |
與 Mozilla 和其他 FedID 社群群組成員的討論持續進行中，目前正在解決要將 IdentityProviderAccount 的哪些欄位傳送至 getUserInfo. 的問題。 |
| 企業版 FedCM | 要求為企業 IdP 用途提供 FedCM 支援。 | 主要問題是需要可信的機制，讓 IdP 向瀏覽器發出信號，指出管理員已預先同意允許使用者存取特定 RP，且網路追蹤器無法模仿和/或濫用。我們在 4 月 22 日的 FedID CG 會議中討論了這個問題 (請參閱會議記錄)，並提出瀏覽器擴充功能和企業政策 (適用於受管理裝置) 的組合，做為可能的解決方案。歡迎按這裡提供有關這個問題的意見。 |
防範垃圾內容和詐欺行為
Private State Token API (和其他 API)
本季未收到任何意見回饋。