2025 年第 1 季季度報告，摘要說明收到的 Privacy Sandbox 提案生態系統意見回饋，以及 Chrome 的回應。
Google 根據第 12 段、第 17(c)(ii) 段和第 32(a) 段的承諾，向英國競爭及市場管理局(CMA) 提交這份季度報告。這份報告涵蓋 Google 在 Privacy Sandbox 提案方面的進度、更新的時間預期、Google 如何考量第三方觀察到的現象的實質說明，以及 Google 與 CMA 之間互動的摘要，包括 CMA 的意見回饋和 Google 處理意見回饋的方式。
Google 會根據承諾書第 17 段(b) 規定，在定期舉行的狀態會議中，向 CMA 更新 Privacy Sandbox 提案的進度。此外，團隊會維護開發人員說明文件，提供核心私人廣告功能和Cookie 變更的概略說明，以及 API 導入方式和狀態資訊。我們會在開發人員網誌上分享重要更新，並將指定的更新內容分享至個別開發人員郵寄清單。
專有名詞詞彙表
- ARA
- Attribution Reporting API
- CHIPS
- 具有獨立分區狀態的 Cookie
- DSP
- 需求端平台
- FedCM
- Federated Credential Management
- IAB
- 互動廣告協會
- IDP
- Identity Provider
- 網際網路工程任務組 (IETF)
- 網際網路工程任務組
- IP
- 網際網路通訊協定地址
- openRTB
- 即時出價
- 延長賽
- Origin 試用版
- PA API
- Protected Audience API (舊稱 FLEDGE)
- PatCG
- Private Advertising Technology Community Group
- RP
- 依賴方
- RWS
- 相關網站集合 (舊稱第一方集合)
- SSP
- 供應端平台
- UA
- 使用者代理程式字串
- UA-CH
- 使用者代理程式用戶端提示
- W3C
- 全球資訊網協會
- WIPB
- 故意隱藏 IP
一般意見回饋，沒有特定 API/技術
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 使用者選擇 | 目前尚不清楚 Google 更新的提升使用者選擇權做法會是什麼樣子、如何向使用者呈現，以及預期的選擇加入/選擇不加入率。您必須提供更多資訊，才能區分這項問題與第三方 Cookie 淘汰。 | 2025 年 4 月，Google 發布了一篇部落格文章，說明Chrome 的 Privacy Sandbox 和追蹤保護功能後續處理方式，宣布 Google 已決定維持目前在 Chrome 中提供使用者第三方 Cookie 的方式，並不會推出新的第三方 Cookie 獨立提示。 我們會在有進一步消息時通知大家。 |
| 數位指紋採集 | Google 並未向發布商或行銷人員提供任何資訊，說明如何使用 Google 廣告系統以外的替代方案，而無須使用較危險的消費者身分做為常見比對鍵 (例如指紋比對)。 | 我們特別挑選了幾個非 Google 廣告系統，這些系統為發布商和行銷人提供的解決方案，部分是採用 Privacy Sandbox API 建構而成。這包括跨市場和管道的非 Google 廣告系統。如需進一步瞭解相關資訊和個案研究，請前往 privacysandbox.com 的「商家資源」專區，按這裡。 |
| Privacy Sandbox | Privacy Sandbox API 會將網際網路資料元素替換成 Google 的完成品。由於 Google 的替代方案是 API，因此您可以存取 Google 擁有及控管的產品，且該產品須遵守 Google 自行決定的條款及細則。這並非替代品，因為其他人可使用這些元件製作自己的成品。 | 我們在與監管機構和生態系統內的多方利益相關者進行廣泛合作後，開發並導入了 Privacy Sandbox API。與其他平台技術一樣，Privacy Sandbox API 必須考量到這些 API 將用於其他成品中的元件，我們歡迎生態系統開發其他技術，與 Privacy Sandbox API 搭配使用。 |
| 使用者選擇 | 要求提供資訊，說明 Google 在 Chrome 上針對 3PC 更新的方法是否符合特定監管規定，這可能會影響利益相關者同意聲明管理平台的使用體驗。 | 2025 年 4 月，Google 發布了一篇部落格文章，說明Chrome 的 Privacy Sandbox 和追蹤保護功能後續處理方式，宣布 Google 已決定維持目前在 Chrome 中提供使用者第三方 Cookie 的方式，並不會推出新的第三方 Cookie 獨立提示。 我們會在有進一步消息時通知大家。 |
| Privacy Sandbox 時程表與採用情況 | 廣告技術公司已暫停 Privacy Sandbox API 測試，並正在尋找更有力的理由，以便針對產品和行銷活動重新投資這些技術。他們的再投資決策受到多項因素的影響，包括需要更清楚瞭解使用者選擇時間表，以及對 Protected Audience API (PA API) 延遲時間和 B&A 路線圖的疑慮。此外，我們也對即將進行的 CMA 承諾審查感到疑慮，特別是 Google 在無須依賴第三方 ID 的 Privacy Sandbox 技術中扮演的主要推手角色，以及這項計畫的整體未來方向，以便制定投資策略。 | 2025 年 4 月，Google 發布了一篇部落格文章，說明Chrome 的 Privacy Sandbox 和追蹤保護功能後續處理方式，宣布 Google 已決定維持目前在 Chrome 中提供使用者第三方 Cookie 的方式，並不會推出新的第三方 Cookie 專屬提示。如有進一步的更新資訊，我們會立即提供。 Chrome PA API 競價的速度比去年快了 35%。此外，我們發現並行競價的使用率大幅增加，這類競價的勝出機率也因此提高。 如要查看目前的 B&A 藍圖，請按這裡。 |
| Privacy Sandbox 時程表 | Privacy Sandbox 時間表頁面有哪些更新？ | 我們最近在 Privacy Sandbox 時程表頁面中新增了 Topics API 的總覽。 |
| Privacy Sandbox | 是否有任何研究報告可說明隱私權與實用性之間的關係，協助我們瞭解 Privacy Sandbox 對收益的影響？ | 如要查看相關市場研究案例，請按這裡。如要查看 Privacy Sandbox API 測試結果，請按這裡。 |
| 採用 Privacy Sandbox | 早期採用者回報，由於大型公司採用率偏低，導致 Privacy Sandbox API 的初步測試受到影響。不過，我們很感謝 Privacy Sandbox 團隊採取合作方式，並迅速回應意見。 | 我們感謝早期採用者的寶貴意見。我們致力於與早期採用者合作，並將持續與生態系統互動，並在評估 Privacy Sandbox 技術在支援生態系統方面的作用時，收集相關意見回饋。 |
| Chrome 測試 | 擔心在移除測試標籤後，無法有效進行 Privacy Sandbox 測試，因為在 Chrome 中停用第三方 Cookie (模式 B) 與使用者在 Chrome 設定中自行停用第三方 Cookie 之間，流量品質有顯著差異。 | 我們的回應與前幾季類似： Privacy Sandbox 團隊瞭解企業希望繼續使用Cookie 淘汰標籤。延長標籤可用性的程序與延長來源試用期類似。我們曾多次延長標籤的支援期限。我們預計會進一步擴大 Cookie 淘汰標籤的支援範圍，並在 blink-dev 上分享最新消息。 |
註冊與認證
本季未收到任何意見回饋。
顯示相關內容和廣告
主題
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 選擇採用/不採用 | Google 確認 Google 搜尋不會將網站選擇不採用 Topics API 的決定做為排名信號，這是否會限制 Google 使用網站選擇採用 Topics API 的決定做為排名信號？ | 我們的回應與先前幾季類似： Privacy Sandbox 團隊並未與搜尋團隊協調，也未要求對方使用網頁排名，作為網站採用 Topics API 的誘因。Google 搜尋不會將網站決定是否支援 (或不支援) Topics API 做為排名信號。 |
| 使用情形觀測 | 要求供應端平台或一般廣告技術提供觀察機制，以便查看他們實作的 Topics API 是否在網站上使用。 | 我們正在評估這項功能的支援情形，如果這項功能是優先考量，歡迎生態系統提供更多意見回饋。 |
| 隱私權 | 有關同意聲明和重新識別潛力的疑問。 | 我們目前正在這裡討論這個問題，也歡迎您提供更多意見。 |
Protected Audience API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| PA API 和 GAM/AdX | Google 不會將任何 GAM/AdX 需求傳送給想採用競爭對手發布商廣告伺服器的發布商。Google 應讓競爭對手的發布商能夠選擇其他頂層 PA API 競價賣家，以便控制最終競價。GAM 可使用 PA API 提供的資訊，但競爭對手的 SSP 則無法使用。因此，發布商無法比較 GAM 中 PA API 來源的廣告需求成效，例如 AdX 或已整合至 PA API 的 SSP。 | Chrome 回覆： PA API 標準具備彈性，可讓不同參與者執行頂層競價。這個選項取決於發布商的廣告伺服器 (不論是 GAM 或其他) 和生態系統中其他參與公司的具體實作和功能。 PA API 以隱私權為重點的設計，可為所有參與者提供一致的精細報表。由 PA API 競價回報的特定資料，會受到所有參與者 (包括任何 SSP) 適用的相同 API 定義隱私權保護規則和限制。 發布商可使用 PA API 提供的匯總報表，評估成效並保護隱私。這可讓您評估透過 PA API 取得的需求整體貢獻度，並與其他需求管道進行比較，符合 API 的隱私權設計原則。 Google Ad Manager 提供的回覆： 發布商無須使用 GAM 的廣告伺服器功能，即可存取 AdX 需求。此外，無論是單一賣家或多重賣家設計，PA API 都不會區分誰啟動競價。 |
| 頂級賣家 | 最高層級賣家 (TLS) 可存取其他元件賣家無法存取的資訊，因此有人擔心資訊存取權不平等。雖然任何實體都可以是 TLS，但發布商必須使用 GAM 做為發布商廣告伺服器，才能存取 AdX 需求。這會促使發布商使用 GAM 做為廣告伺服器，為 Google 創造競爭優勢。 | Chrome 回覆： PA API 的設計並未規定哪個實體可充當 TLS。TLS 角色需要協調競價，並根據 API 結構存取相關競價資訊。 Google Ad Manager 回覆： 我們多年來一直非常重視競價公平性，包括承諾不會在其他買家出價競價前，與他們分享任何發布商無保證廣告來源 (包括無保證委刊項價格) 的價格，後來我們在向法國競爭管理局做出的承諾中也重申了這一點。 針對 PA API 競價，我們會信守承諾，在多賣家競價結束前，不會將任何競價參與者的出價提供給其他競價參與者。在此說明，我們不會將內容相關廣告競價的價格提供給任何元件競價 (包括我們自己的競價)，如這篇更新文章所述。此外，我們不會在自家競價中使用元件競價設定的相關資訊，包括買方提供給 SSP 的信號。 此外，如上所述，GAM 不會要求發布商使用廣告伺服器功能，即可存取 AdX 需求。 最後，如Google 2024 年第 2 / 3 季報告中所述，Google 的買方平台 (Google Ads (舊稱 AdWords) 和 DV360) 會透過 PA API 從非 Google 廣告交易平台購買曝光。 |
| PA API 和 GAM/AdX | 由於選項的標籤未清楚說明用途，因此發布商難以瞭解為何要對 100% 的廣告空間啟用 PA API。對於 SSP 而言，由於存取廣告空間的主要方式通常是透過多層次競價，而 GAM 會擔任 TLS，因此，如果不受 GAM 影響，就無法透過 PA API 進行測試或營利。 | Chrome 回應： PA API 標準定義了技術角色 (例如 TLS 和元件賣家) 和競價程序，讓平台可以靈活地執行這些角色。 實作方 (發布商、SSP、TLS 供應商) 會管理營運活動 (例如設定、協調和協議)，以利使用 PA API 架構參與。 Google Ad Manager 提供的回覆： 如說明中心所述，Ad Manager 提供發布商控制項，可在可使用 API 的發布商廣告空間 100% 中，啟用非 Google 元件賣家 (例如其他 SSP) 的測試功能 (覆寫 GAM 可能套用的任何取樣或節流)。 如果發布商啟用這項控制項，只要非 Google 元件賣家提供競價設定，且發布商已取得必要的使用者同意，GAM 就會嘗試執行包含提供元件競價的頂層競價。GAM 會向發布商明確指出這項控制項可能會影響成效，以便發布商做出明智的決定。 |
| 伺服器端與裝置端 | 伺服器端解決方案 (例如出價和競價) 可能可解決流量塑造問題，同時保障隱私。伺服器端解決方案是唯一可行的解決之道，Google 應放棄裝置端解決方案。 | Privacy Sandbox 旨在支援伺服器端 (B&A 服務) 和裝置端競價解決方案，提供多種選項，滿足不同的廣告技術需求和用途。 |
| 競價安全性 | 對 PA API 出價的攻擊行為，基本上會導致裝置端出價和競價失去資格，而利益相關者認為這個問題尚未解決，因此持續要求提供技術保證，確保 PA API 出價不會遭到竄改，並提供詳盡的偵錯模式，以便即時偵測事件並有效進行偵錯。 | 確保 PA API 競價機制完整性 (包括減輕潛在攻擊) 是 Privacy Sandbox 的主要重點。API 的設計納入了完整性措施，歡迎您進一步討論特定疑慮的技術問題。 在 2024 年 5 月的 W3C 反詐欺社群群組會議中，我們提出並討論了一份 PA API 潛在攻擊的詳細清單，以及我們採取的因應措施。歡迎您進一步討論並提供意見，說明您對「廣告客戶 API 出價遭到攻擊」的疑慮。 |
| 無 Cookie 流量 | 是否有辦法只在無 Cookie 流量中啟用 PA API，以便進行測試或用於其他用途？ | 廣告技術可以判斷是否存在 3PC。如要進一步瞭解這項功能，請參閱這篇文章。 |
| 席位 ID | 就座位 ID提案而言，座位 ID 資訊對於大多數出價要求都至關重要，因此我們擔心將座位 ID 與廣告素材註冊綁在一起。此外，這項功能是否只適用於「主要廣告」，還是也適用於元件廣告？ | BuyerAndSellerReportingId 提案解決了主要廣告的廣告素材註冊過程中缺少買方帳戶 ID 的問題。這個 ID 旨在將買方的座位 ID 傳達給賣方。我們正在評估是否支援元件廣告。 |
| 監控和回報 | 即時監控 (RTM) 功能要求：(1) 針對取消的競價傳送 RTM 報表，以及 (2) 新的瀏覽器填入值區塊，以便清楚瞭解發生了哪種取消。 | RTM 似乎不適合用於調查參與率。RTM 是低延遲監控 API，設計用來偵測突然發生的重大暫時性停機問題。相反地，參與度不需要低延遲回報，也不是重大的臨時性暫時性中斷。買方與合作的賣方最能有效解決參與率問題，而非透過瀏覽器調查。 此外，由於取消競價的情況非常常見，如果瀏覽器會針對每個取消競價產生 RTM 報表，可能會淹沒實際停機的 RTM 報表。 |
| 說明文件 說明 |
回報 PA API 說明文件中的文件差異，說明 nonce 應為 UUID 字串，但實際上傳回的是承諾。 | 如需進一步說明，請參閱這篇文章。 |
| Frozen 背景資訊 |
使用凍結式內容時，有哪些選項可解決與 (1) 捆綁、(2) 外部程式庫和 (3) 不支援的資料類型相關的問題和挑戰？ | 我們已在這裡回答這個問題。 |
| 規格 | Private Aggregation API 新增了一般 contributeToHistogramOnEvent 作業。因此，PA API 中的定義變成了超載作業，而 Web IDL 作業「不得在介面、部分介面 [...] 之間超載」，因此該定義現在無效。 | 這個問題指出，在合併 PA API 和 Private Aggregation 的類似變更時，兩者之間出現了暫時不一致的情況。我們已合併提取要求來解決這個問題。 |
| 興趣群組 | 請提供指引，說明如何在廣告活動停止時，以省資源的方式結束興趣群組 (IG) 的出價參與。 | 以下是我們提供的建議： 我們認為，使用即時出價信號通知 generateBid() 停止出價，是延遲時間最短、最不永久，且資源釋放量最少的機制。第二個選項會在即時出價信號回應中為該 IG 設定負優先順序，因為這會停止 generateBid() 的叫用。第三個選項是從 IG 中移除廣告，這樣會使用更少的資源。沒有廣告的 IG 不會叫用 generateBid()。第四個選項 (使用更少資源) 是從 IG 中移除 biddingLogicURL。此時，您仍可更新/重新加入 IG 帳戶，以便重新啟用帳戶。其他選項則是關於離開 IG，可透過 leaveAdInterestGroup() 或 clearOriginJoinedAdInterestGroups() 離開，也可以等待 IG 到期。如上所述，不同選項的延遲影響和資源消耗量也不同。廣告技術人員可以選擇最適合其特定用途的選項。 |
| 目標對象 | 要求提供機制，以便在建立的目標對象上執行邏輯運算 (例如，能夠指定 IG A 與 IG B 的交集) | 有了 PA API，您現在就能針對同一網站的目標對象執行邏輯運算。基於隱私權考量，我們目前不支援跨不同網站的目標對象邏輯運算，詳情請參閱我們的隱私權模型。我們會持續進行相關研究，並在過程中分享任何最新消息。 |
| 功能建議 | 提案：移除額外出價的限制，不再要求事先知道傳輸層安全標準 (TLS)。 | 我們目前正在這裡討論這項提案，也歡迎您提供更多意見。 |
| 更新 Chrome 上的 3PC 方法 | 所有 Chrome 穩定版使用者是否都能繼續使用 PA API 等 Privacy Sandbox API，還是只有拒絕 3PC 的使用者才能使用這些 API (或部分 API)？ | 我們不希望使用者拒絕第三方 Cookie 的決定，會影響 Chrome 穩定版中 Privacy Sandbox API 的可用性。 |
| 強化訊號 | 是否有計劃新增功能，指出 TLS 是否打算執行 PA API 競價？ | 我們正在評估是否支援這項功能。我們會在時程可供使用時提供更多詳細資訊，也歡迎您針對這項要求提供更多意見回饋。 |
| 交易 ID | 擔心Deal ID提案中的 KV 伺服器規定可能會是耗時且費用高昂的伺服器端程序。 | 透過交易 ID 提案，SSP 可以在 PA 競價期間從鍵/值伺服器查詢所選交易 ID 的中繼資料，因此不必將所有交易相關中繼資料預先載入裝置。我們會根據 SSP 的要求開發這項提案，歡迎您在這裡提供更多生態系統意見回饋。 我們瞭解設定鍵/值伺服器需要花費心力，但整體而言，我們認為這對廣告技術公司來說仍是淨益。歡迎您繼續提供意見和建議，協助我們簡化這項程序。 |
| 跨 IG 展示頻率上限 | 透過 PA API 要求跨 IG 展示頻率上限。 | 跨 IG 展示頻率上限具有隱私權方面的挑戰，我們目前尚未找到解決方法。 如果這項功能是優先考量，歡迎生態系統提供更多意見回饋。 |
| 交易 ID 和席位 ID 報表 | 要求能夠在匯總報表中取得交易或座位 ID。 | 我們正在開發的報表 ID 功能 可用於回報交易和座位 ID。 selectedBuyerAndSellerReportingId 會提供給 reportResult()，因此最簡單的回報方式就是透過事件層級回報 (也就是將交易 ID 編碼至傳送至 sendReportTo() 的網址)。如果要使用匯總報表，也可以這麼做。 目前有 10% 的 Chrome 穩定版管道流量會使用報表 ID 功能。我們正在評估是否要將推出範圍擴大到 100%。 |
| 興趣群組 | 在 IG 選取和評估作業中使用相同的優先順序，並在所有評估模式中使用該優先順序。 | 我們目前正在這裡討論這個問題，也歡迎你提供更多意見。 |
| 興趣群組 | 建議使用目標對象啟用和委派功能，以便提高 Privacy Sandbox API 的採用率。 | 我們已知多位相關人士提出這項要求，目前正在研究解決方案。 歡迎生態系統提供更多意見回饋。 |
| 興趣群組 | 建立 PA API IG 時遇到的挑戰，特別是代表多個買家或發布商購買時的委派和擁有權。 | 我們收到多方利益相關者提出的要求，希望我們支援更進階的 IG 委派作業，而賣方平台在這項程序中可提供額外價值。 我們正在進行研究，找出最適合讓不同參與者參與目標對象擴展程序的解決方案。歡迎生態系統提供更多意見回饋。 |
| 用戶端效能 | 請提供指引，說明如何簡化 trustedBiddingSignals 的用戶端快取作業，以便改善基礎架構成本和延遲時間。 | 我們目前正在這裡討論這個問題，也歡迎你提供更多意見。 |
Protected Auction (B&A Services)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| K/V 服務 | 瀏覽器向賣方 KV 伺服器傳送要求時，如何進行批次處理？對於賣家而言，瀏覽器的請求會是 GET 還是 POST 要求？此外，我們也需要進一步說明 k-anonymity 的相關規定。 | 針對 v1，Chrome 會向賣家的 KV 服務傳送 GET 要求，藉此透過要求的查詢參數中的信號擷取 trustedScoringSignalsURL。參數包括 hostname、renderUrls、adComponentRenderUrls 和 experimentGroupId。我們目前正在實驗某些擴充功能，以便傳送額外資訊供廣告素材掃描使用，但尚未推出。將 maxTrustedScoringSignalsURLLength 設為 0 時，Chrome 可能會將所有信號批次處理至單一要求 (可能會超過伺服器的網址長度限制)，但無法保證一定會這樣做。目前 Chrome 會選擇將準備好在 10 毫秒內傳送的請求納入同一批次，但我們目前正在研究如何最佳化這項功能。使用 trustedScoringSignals 時，請記得 Chrome 會遵循快取標頭。 Stale-While-Revalidate「Cache-Control」標頭等標頭可讓 Chrome 使用快取副本 (並更新下次競價的快取)，進而減少平均延遲時間，有效從關鍵路徑中移除信號擷取作業。最後，關於 k-anonymity，說明的特定部分似乎已過時。我們原本要求信任信號網址必須符合 k-anonymity 規定，但後來取消了這項規定。我們會從說明中移除這句話。 |
| B&A 服務 | 升級至最新版 B&A 需要很長的時間。縮短建構時間或使用預先建構的映像檔會更有幫助。 | 廣告技術可以自行建構二進位檔，並使用提供的雜湊值進行驗證。我們會考慮調查是否有可能提供預先建構的構件，或改善建構時間。 |
| API 功能要求 | 要求為出價和競價服務 (B&A) 建構指令碼、容器映像檔和叫用工具提供 macOS 相容性，以利於本機開發和測試。 | 我們目前支援 amd64，這已足以部署至支援的雲端平台 (GCP 和 AWS)。我們日後可能會研究支援其他架構。 |
| AWS | 是否必須建立 IAM 角色才能進行正式版建構？ | 是的，您必須具備 IAM 角色，才能取得適當的權限，並與協調員進行通訊。這些金鑰可用於解密裝置上產生的 ProtectedAudienceInput 密文，如這裡所述。此外，這些角色必須透過相同的協調器，通過實際建構的伺服器/TEE 認證。如要進一步瞭解這項功能，請參閱自助指南。 |
| B&A 標記 | 請將可用的 B&A 標記定義列入說明文件，因為目前這些定義位於 Terraform 程式碼、cc 檔案和 proto 檔案中，但廣告技術人員可透過這些標記的說明文件，瞭解如何自訂部署作業。 | 我們正在研究是否能記錄 Terraform 標記說明，歡迎在這裡提供更多意見回饋。 |
| AWS 出價服務 |
請提供 AWS 出價服務的相關指引，以及預設記錄行為和設定。 | 如要在 TEE 中偵錯出價服務 (例如出價服務)，建議您使用廣告技術同意偵錯。這樣一來，您就能啟用詳細記錄功能，並直接從用戶端擷取特定測試要求的要求/回應資料，以利進行除錯。 |
| TEE K/V 說明文件 |
請說明 開發人員網站所述的 TKV 執行時間。 | 我們會事先提供充分的通知，要求您使用 TEE。在此之前，您可以繼續使用自家的伺服器來傳送即時鍵/值信號。 |
| B&A 測試與分析 | B&A 分析和測試仍需耗費大量成本，且似乎無法用於正式版。 | 我們需要更多資訊，才能進一步調查成本分析和評估正式版完備性的因素。 |
| 可信任的伺服器最佳化 | 建議將元件賣家專屬的參數合併為一個 inputsPerSeller 參數，並使用 JSON 字串做為其值。 | 我們正在討論這項提案，歡迎您在這裡提供更多意見。 |
| 安全性 | 使用 B&A 可如何降低 TKV 的安全性風險？ | 您可以防止外部呼叫 TKV。目前 GCP 已全面支援這項功能，並可進行設定。 對於 AWS，由於先前啟用此功能的 AWS App Mesh 已淘汰，因此需要開發額外的支援功能。歡迎在這個頁面提供更多意見。 |
| B&A 服務 | 請說明說明/說明文字，說明 HTTP 串流對廣告與放送最佳化有何價值。 | Privacy Sandbox 支援串流功能，可在轉移 B&A 資料時改善延遲時間，方便廣告技術人員選擇使用。在混合模式下，這是選用的效能最佳化功能。 |
| 出價前 | 要求更新開放原始碼 Prebid 程式庫的貢獻內容，為生態系統啟用 PA API B&A 功能。 | 在 2025 年 3 月，Chrome 在穩定版中推出了 Prebid 優先最佳化功能，如 B&A 公開路線圖所述 (請參閱 2025 年 3 月)。 |
| 流量型態 | 要求提供機制，記錄 B&A 收到的內容訊號，以便進一步瞭解 IG 何時會啟用，並改善 IG 在內容回應中「出價意圖」的邏輯。這可讓您更有效地使用網路資源，避免產生「無用流量」(又稱為流量塑形)。 | 我們目前正在討論 這項提案，歡迎提供更多意見。 |
| 說明文件 說明 |
需要釐清在 B&A 測試整合設定中發現的「無法存取 Service/Vsock proxy」錯誤。 | 這是因為記憶體有最低需求。AWS 設定說明已更新，以反映這項需求。 |
評估數位廣告成效
歸因報表 (和其他 API)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 即時資料 | 缺乏即時資料會影響整個產業。即時資料延遲對廣告主來說是嚴重問題，買方會轉移至採用 Google Analytics 的平台，因為只有在這些平台上，他們才能取得觸及目標對象的證明。 | Attribution Reporting API (ARA) 的即時資料延遲功能是為了保護隱私權而實作的機制，可減少廣告技術人員使用事件層級報表追蹤跨網站使用者的可能性。不過，ARA 可讓您彈性調整歸因報表的傳送方式，例如讓事件層級報表的回溯期間最短為 1 小時，或是讓匯總報表可選擇立即傳送給廣告技術人員，不必延遲。 |
| API 用量 | 請確認跨網站應用程式歸因流程的正確設定，尤其是在同時執行網站對網站和網站對應用程式歸因時。 | 並行執行網頁到網頁和網頁到應用程式廣告活動時，廣告技術應只選擇一個平台來登錄每個來源或觸發事件，以免重複計算。我們強烈建議您盡可能使用作業系統 (OS)，因為只要網頁來源和觸發條件已正確委派，OS 就能同時執行網頁到網頁和網頁到應用程式歸因。這表示您必須針對來源使用 Attribution-Reporting-Register-OS-Source 標頭，針對觸發事件使用 Attribution-Reporting-Register-OS-Trigger 標頭回應。 Attribution-Reporting-Support 標頭可用於判斷是否有 Chrome 和/或 Android 層級支援。如果要求中沒有 Attribution-Reporting-Support 標頭，Attribution-Reporting-Info 標頭就很實用。在這種情況下，瀏覽器會根據使用者裝置上支援的平台可用性，決定是否註冊平台。 |
| API 規格 | 請說明 Attribution Reporting API 設定的 Attribution-Reporting-Support HTTP 要求標頭，以及標頭是否會在所有平台上同時包含 web 和 os 鍵。 | 瀏覽器會在 Attribution-Reporting-Support 標頭中加入「GREASE」參數，以確保伺服器使用符合規範的有結構標頭剖析器。對於這個標頭，您應該只解析結構化字典的鍵。這些值和參數目前未使用。如需範例，請參閱這篇文章。 |
| 以 3PC 為依據的報表 | 請提供如何排解廣告活動中 ARA 和 3PC 評估結果不一致的問題。 | ARA 支援兩種偵錯報表，可用於排解差異問題和進行偵錯。歸因成功偵錯報表可用於輕鬆比較 ARA 結果與其他評估技術的結果，而詳細偵錯報表可用於取得更多資訊，並排解歸因註冊中的潛在問題。 |
| API 使用方法 | 在測試 ARA 時，我們發現了以下問題：報表資料不夠詳細，導致資料雜訊過多，無法有效改善廣告活動；門檻過高，導致小型廣告客戶無法使用；以及關鍵績效指標不一致，導致難以比較廣告活動。 | ARA 提供多個參數，廣告技術人員可根據特定評估用途自訂，以便靈活運用。事件層級報表支援彈性事件層級報表，廣告技術人員可以自訂報表回溯期、可收到的報表數量，以及要評估的觸發事件資料，進而改變雜訊對資料的影響，並實現不同的用途。同樣地，廣告技術人員可以透過多種方式自訂匯總報表的設定，例如追蹤的維度數量、批次處理頻率，以及使用貢獻預算來改變雜訊的影響，並實現不同的用途。 |
| API 規格 | 關於 ARA 對 3PC 的依附性問題，特別是關於是否仍處於需要這些 3PC 的測試階段。 | ARA 的啟用與 3PC 無關，但必須啟用 3PC，才能讓 ARA 轉換偵錯報表將 ARA 結果與 Cookie 為基礎的歸因結果進行比較。 |
| API 使用方法 | 使用 ARA 在舊版 Android (11、12 和 13) 上註冊應用程式到網路歸因來源的相關問題。 | ARA 目前支援 Android S 以上版本 (12 以上)。 |
| API 使用方法 | 要求提供 ARA 選擇加入比率和發行詳細資料。 | 我們的回覆與先前幾季相同： 「我們沒有打算與生態系統分享這項資訊。歡迎開發人員呼叫已部署程式碼的 API，以便估算 Privacy Sandbox API 的可用性」 |
| API 適用性 | 啟用 ARA 時，是否已啟用或停用 3PC？ | 在使用者的瀏覽器中啟用 ARA 不會對使用者的 Cookie 設定造成任何影響。您可以啟用 ARA，並讓使用者啟用或停用 Cookie。 |
| 報表 | 我們可以在「Attribution-reporting-support」標頭中接收預先定義的值清單嗎？ | 如 指南所述，這個值是結構化標頭字典，目前定義的語意只有 OS 和 web 鍵是否存在。系統會忽略標頭的所有其他部分。換句話說，剖析作業必須使用結構化標頭剖析器，而非簡單的字串比對。 |
匯總服務
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 功能建議 | 匯總服務功能要求： 伺服器對伺服器整合、跨裝置評估、簡易多觸點歸因和貢獻報表、全通路歸因，以及支援進階機器學習最佳化迴圈 (例如私人模型訓練)。 |
我們正在評估這些要求，並會在可提供更多資訊時提供詳細資訊。 歡迎生態系統提供更多意見，說明這些要求是否屬於優先處理項目。 |
| 功能建議 | 要求在 Terraform 環境中將 EBS delete_on_termination 參數設為 True，以便在更新匯總服務集時減輕重設疑慮。 | 我們正在評估這項要求，並會在可提供更多詳細資料時通知您。 歡迎生態系統提供更多意見回饋，說明這項要求是否為優先事項。請在此提供意見。 |
| 說明文件 說明 |
請提供指引，說明哪些項目可以變更 (例如監控門檻)，以及哪些項目應保持不變。 | 我們正在評估是否要針對匯總服務的現有自訂選項，發布其他說明文件和指南。 |
| 部署作業 | 請說明在 bazel 指令中，新部署作業為何失敗。 | 部署作業可能會因環境中使用的 Bazel 版本而失敗。 說明文件會調整，涵蓋 Terraform 失敗的偵錯作業，並指出所需的 bazel 版本。 |
Private Aggregation API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| API 使用方法 | 針對一些實作挑戰尋求指引，例如可能因已回報的共用儲存空間限制而導致資料遺失、高基數導致需要複雜的匯總服務許可清單 (建議使用萬用字元)，以及匯總服務的「不重複」規則導致測試速度變慢。 | 就 Shared Storage 限制而言，20 個貢獻限制 (詳情請參閱這裡) 是指每次執行，而非每月。此外，API 呼叫端可以覆寫這項限制。這項限制旨在協助管理匯總服務中處理報表的成本，並非限制報表公用程式。 關於萬用字詞查詢，我們正在評估這項要求，並會在可提供更多詳細資訊時分享。 針對「不重複」規則，為了進行測試，我們暫時支援偵錯模式，以便略過這項規則。詳情請參閱這篇文章 。 |
| 篩選 ID 和值區 | 在兩次不同的匯總執行作業中，是否可以向匯總服務要求同一個區塊，但使用兩個不同的篩選 ID？也就是說，篩選 ID 是否可以做為網域的輔助區隔？ | 是的，這項功能受到支援。執行匯總作業時，系統只會處理篩選 ID 與工作參數清單相符的貢獻內容，其餘內容則可在個別執行作業中處理。 |
| 多接觸點歸因分析 | 針對多觸點歸因 (MTA) 導入作業，請提供以下說明： 1) 如果匯總值不超過 2^16，是否有貢獻次數上限？ 2) 在特定情境下，可儲存的不重複匯總鍵 (值區) 數量是否有上限？ 3) 如果每個使用者代理程式 (瀏覽器) 都有專屬的匯總鍵 (在 MTA 中可能會發生)，匯總服務會如何處理摘要報表？ |
1) 我們已設定預設的貢獻限制，但 API 呼叫端可以選擇覆寫這些限制，詳情請參閱這篇文章。限制的目的在於協助 API 呼叫端管理匯總服務中處理報表的成本。 2) 沒有這類限制，但廣告技術人員應考量匯總鍵的精細程度，以改善信號雜訊比，詳情請參閱這篇文章。 3) 請參閱這份指南，特別是上述 2) 項所述的訊雜比指南。 |
限制隱密追蹤
使用者代理程式縮減/使用者代理程式用戶端提示
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 功能建議 | 要求將 Sec-CH-UA-Robot 新增至 User-Agent 用戶端提示 (UA-CH)，這樣伺服器就能識別自動化流量，以便進行內容調整、安全性和分析。 | 這是其他標準群組正在討論的重要用途 (詳情請見這裡 )，建議有興趣的各方提供意見回饋。不過，我們認為 UA-CH 可能不是適當的解決方案，因為自動化流量很容易操控 HTTP 要求標頭。 |
IP 保護 (原稱 Gnatcatcher)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| IP 位址隱私權 | 將 IP 位址提供給 Google 使用，與 Google 聲明的隱私權目標相違。雖然 Google 表示會透過 IP 保護功能將資料匿名化，但使用者必須登入 Chrome 才能使用 IP 保護功能，因此 Google 還是會瞭解使用者的身分。 | 登入的原因是為了防範詐欺和濫用行為，主要目的是限制存取 Proxy 的頻率。 此外，為了在驗證要求的情況下保護使用者隱私，我們的權杖設計採用盲簽名，也就是說，登入時核發的權杖與代理期間使用的權杖不同，因此核發的權杖無法日後連結至使用者的 Google 身分。也就是說，即使為了防範詐欺而要求驗證，Google 還是無法得知使用者在無痕模式下瀏覽的流量。 |
| IP 位址隱私權 | 使用 IP 是錯誤的做法。與 Cookie 不同，使用者無法透過瀏覽器刪除這類資訊，也無法像 Cookie 一樣控制資訊的透明度。如果 Cookie 消失，業界將改用 IP 做為替代方案，將自保視為優先，而非隱私權。 | Chrome 是一種平台，旨在為使用者提供可改善網路瀏覽體驗的功能。對於選擇在無痕式瀏覽模式下瀏覽的 Chrome 使用者，這項功能可限制第三方內容中的 IP 位址資訊，提供更強大的跨網站追蹤防護。 |
| 遮蓋的網域清單 | Masked Domain List (MDL) 的選取條件為何？ | Chrome 開發了判斷標準，可識別哪些網域應加入 MDL，並在第三方情境中接收經過遮罩的 IP 位址。Google 與 Disconnect.me 合作，後者是網路隱私權領域的知名領導者，也與其他網路瀏覽器合作。Chrome 會利用 Disconnect.me 找出符合 Chrome 規定條件的網域。此外，Chrome 也開發了一種方法，可找出廣泛使用的 JavaScript 函式，這些函式可從穩定且高熵的網路 API 提供一致的輸出內容，因此可用於建構高熵機率 ID。當這些函式在第三方情境中載入網站時，系統就會偵測到這些函式，並列出提供具有這些特徵的腳本的網域，這些網域會成為 MDL 的一部分，因此會經過 Proxy 處理。偵測管道會尋找這些 API 濫用模式，並考量所有網域，包括 Google 自有網域。 |
| 詐欺防範 | 針對機率揭露權杖 (PRT) 的意見回饋：建議的 24 小時揭露延遲時間和揭露率會妨礙即時詐欺偵測。要求更短的延遲時間 (1 小時延遲) 和更高的費率 (至少兩位數)。我們還建議您根據風險信號 (VPN、自動化瀏覽器) 啟用差異化費率，並允許指定特定符記的揭露。 | 我們與大多數開發人員的對談中，他們都會每小時向客戶提供報表，並在一天中多次更新 IP 封鎖清單。延遲時間越短，更新頻率就越高，且在小於 1 小時的情況下，系統會在每小時統計資料中重新啟用 IVT 評估，但也可能增加使用者重新識別的可能性。我們會根據生態系統研究和利害關係人的意見回饋，探索縮短延遲時間和變更顯示率的可能性，也歡迎您前往這個頁面提供更多意見。 |
| 遮蓋的網域清單 | 關於網域未有廣告用途，但仍納入 MDL 的問題。擔心這麼做可能會啟用「IP 橋接」功能，根據 IP 位址建立設定檔。 | 我們瞭解，針對以名單為依據的做法導入申訴程序的重要性。透過申訴，公司可以聲明自己的網域不符合 MDL 的納入條件，因此應予以移除，藉此讓該網域繼續在無痕模式下，透過第三方內容接收使用者的原始 IP 位址。 我們現在已啟動申訴程序，讓網域擁有者有充足的時間提出申訴，並在 Chrome 穩定版推出 IP 保護功能的無痕模式前收到決定。 如要進一步瞭解申訴程序，請參閱本文。 |
| 遮蓋的網域清單 | 發布商正在調查合作夥伴加入 MDL 後的影響。他們對 IP 保護說明中的地理 IP 條款感到放心。 | Chrome 瞭解支援地理位置相關用途的重要性。Proxy 會指派代表使用者概略位置 (包括國家/地區) 的 IP 位址。如需更多資訊，請參閱「IP 位址地理位置說明」。 |
| 遮蓋的網域清單 | 關於 MDL 的問題：國家/地區層級指定功能是否仍可用。 | Chrome 瞭解支援地理位置相關用途的重要性。Proxy 會指派代表使用者概略位置 (包括國家/地區) 的 IP 位址。如需更多資訊，請參閱「IP 位址地理位置說明」。 |
| 詐欺偵測 | 擔心 IP Protection 對詐欺偵測系統的影響。使用者會看到 Proxy IP 或標頭嗎？在特定用途下，SSP 和 DSP 是否會看到相同的代理 IP 位址？不一致的資訊可能會影響詐欺偵測和 OpenRTB。 | 如果使用者在啟用 IP 保護功能的無痕模式下瀏覽網頁，並向 MDL 上的網域提出要求，系統會根據定義的 Geofeed 提供 Proxy IP 位址。機構可以要求將 PRT 做為 Proxy 流量的額外標頭傳遞，在延遲一段時間後，系統會揭露少量原始 IP 位址。我們懷疑許多賣方平台會將伺服器端出價要求中的代理 IP 位址傳遞給需求合作夥伴，但獲勝的 DSP 不保證會在曝光時看到相同的代理 IP 位址。 |
| 詐欺偵測 | 有關 IP 地理位置檔案更新頻率、回報詐欺行為和 PRT 詳細資料的更新時間，以及廣告技術應如何偵測詐欺活動的問題。 | 已上線的 PRT 說明，以及代理伺服器 IP 位址和對應地理區域的清單。建議您定期檢查這份檔案，瞭解是否有更新和變更，因為 IP 位址會隨著時間輪替。我們會在臨近推出日期時，公布用來回報濫用行為的公開電子郵件地址。 |
| 地理位置 | 要求公開用於代理伺服器的 IP 位址清單。 | 您可以在這裡下載 IP 保護功能的 IP 位址對應大概位置檔案。請注意，這份檔案會定期更新。 |
| API 使用方法 | 斷言指出 IP 保護功能似乎預設為開啟，且使用者無法選擇停用。 | 使用者可在 Android 和電腦平台的 Chrome 無痕模式中使用 IP 保護功能。使用者可以停用 IP 保護功能。企業管理版 Chrome 可啟用 IP 保護功能，但預設為關閉。 |
| API 使用方法 | 有關實驗旗標可用性的查詢，可在 Chrome Canary 和 Beta 版中啟用及測試 IP 保護功能。 | 目前我們沒有實驗標記可用於測試完整的 IP 保護功能。我們正在進行的功能實驗只會代理流量傳送至 Google 網域。 |
| IP 位址隱私權 | 當瀏覽器進入無痕模式時，3PC 提示設定會如何運作？ | 在無痕模式下，系統預設會封鎖 3PC。 |
| 無痕模式 | 想確認在使用者未登入 Chrome 時，IP 保護功能是否會在無痕模式下運作。 | 如果使用者在啟動無痕模式前未登入 Chrome，IP 保護功能就不會啟用。這是為了防止欺詐和濫用行為，也就是限制存取速度。IP 保護功能會使用用戶端驗證機制，限制惡意行為人利用 Proxy 對 MDL 上的服務進行攻擊。因此，只有在使用者開啟新無痕式視窗前，使用登入 Chrome 瀏覽器時所使用的 Google 帳戶進行驗證的使用者，才能使用 IP 保護功能。 |
| 無痕模式 | 要求在推出前評估 IP 保護功能的影響，包括： (1) 建議使用瀏覽器狀態旗標或匯總 API 回報，以量化無痕模式的使用情形； (2) 在啟用功能前，先傳送 IP 保護標頭一段時間；以及 (3) 將功能提供給少量已知流量，以便推估。 |
我們瞭解生態系統希望能夠瞭解並評估 IP Protection 的規模和影響。不過，Chrome 會盡力保護使用者在無痕模式下瀏覽的隱私權。Chrome 不會公開偵測使用者是否在無痕模式下瀏覽網頁的方法，並已採取措施限制可能洩漏使用者瀏覽模式的其他信號。 我們正在考慮如何進行這項測試，而不影響使用者在無痕模式下瀏覽網頁的隱私權，也歡迎生態系統提供更多意見回饋。 |
跳轉追蹤因應措施
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 法規遵循 | Google 不願授權使用符合資料保護法規的 Bounce Tracking Mitigations (BTM) 技術，這沒有任何法律依據，也讓 Privacy Sandbox 申訴程序變得毫無意義。 | 如先前的意見回饋報告所述，符合規定的狀態與 BTM 的應用無關，Google 不會就導入 BTM 的符合規定性做出任何決定。與其他 Chrome 隱私權防護機制一樣，BTM 的目標是讓使用者進一步控管資料是否分享，以及分享方式。 CMA 第 2/3 季報告中提到的第三方管理申訴程序，是指 Google 決定個別公司是否納入或排除名單的相關領域。 |
| 法規遵循 | 討論瀏覽器如何在 GDPR 的背景下，確保符合法律同意聲明的行為，並強調瀏覽器可能會抑制使用者明確同意的行為 (例如重新導向或 Cookie 設定)，進而造成法律同意聲明和瀏覽器隱私權設定之間的衝突。 | 瀏覽器無法得知使用者與網站之間的關係。此外，在目前的 BTM 行為中，使用者可以透過明確同意追蹤跳出率的替代做法，從特定網站提供資訊。 如要進一步瞭解法規遵循，請參閱隱私權相關法規遵循常見問題。 |
| 雙重用途網站 | 想請你說明，在 BTM 下，從 WebView 或應用程式到網頁 (Chrome) 的轉換是否會視為「雙重用途網站」？ | 瀏覽器無法得知彈出連鎖反應是否是透過 WebView 或應用程式轉換開始。 因此，BTM 不會對這些流程提供任何特殊處理。而是將流程解讀為從「about:blank」開始的跨網站跳出，並繼續執行標準行為。 |
強化跨網站隱私界線
相關網站集合 (舊稱第一方集合)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| API 使用方法 | 擔心 RWS 與 IP 保護功能可能遭到濫用。向 RWS 集合中的機構公開 IP 位址，可能會促使機構加入多個 RWS 集合，以便存取可攜式 IP 位址資料，追蹤無痕模式使用者。 | 系統會透過自動驗證機制，針對相關網站、服務網站和整個集合設定相關規定，以減少嘗試加入多個集合的誘因。 如果要透過 IP 位址彙整跨集合的使用者活動，就必須在集合中加入 MDL 網域，因此集合擁有者和網域擁有者必須協調。同樣的風險也適用於與 MDL 網域協調的單一網站 (即不涉及 RWS)。 我們已在這裡詳細回答這個問題。 |
Fenced Frames API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 原生廣告 | 意見回饋指出，目前設計的 Fenced Frames 與原生廣告業務模式不相容，因為原生廣告需要靈活調整廣告內容，以配合周遭內容。 | 我們會持續評估生態系統需求和目前的 Fenced Frames 服務。無論如何，如先前所述，最快須在 2026 年才會要求使用 Fenced Frames。 |
Shared Storage API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| API 錯誤 | 回報指出，當 Shared Storage API 的預算機制導致 selectURL 作業無法執行時，Chrome 會記錄錯誤，即使這是預期的行為也一樣。要求 Chrome 將記錄層級從錯誤降級為警告或資訊，因為呼叫端無法採取行動處理錯誤。 | 這項異動已實施，並納入 Chrome M134 中，自 2025 年 3 月 4 日起提供。 |
CHIPS
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| API 說明文件 | 需要釐清分割 Cookie 與 SameSite=Lax/Strict Cookie 提供的安全防護措施有何不同。建議在說明文件中明確指出，分割 Cookie 無法提供與 SameSite=Lax/Strict Cookie 相同的 XSS 和 CSRF 攻擊防護層級。 | 我們會更新說明和規格，清楚說明分割 Cookie 的語意和保護措施。 |
FedCM
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| UI 與安全性 | 意見回饋指出 FedCM UI 過於類似 Google 先前的單鍵登入功能，且由於缺乏被動呈現追蹤功能，因此很難量化 FedCM 成效，建議針對 PKCE 提供更明確的說明文件語言。 | 我們正積極與利害關係人互動，處理他們的意見回饋。我們持續討論的議題包括如何為 IdP 提供更優質的指標，讓他們追蹤 FedCM 成效，以及可能的強化功能，以便針對訂閱用途處理 FedCM 的新用途。 |
| API 使用方法 | 當使用者重新整理網頁並呼叫 navigator.credentials.get 來登入時，系統會顯示彈出式視窗，要求使用者點選繼續，這會造成延遲，影響使用者體驗。依賴方 (RP) 可以將 navigator.credentials.get 傳回的權杖快取，以改善使用者體驗嗎？ | RP 可以使用自己的 Cookie 儲存權杖。接著，在叫用 navigator.credentials.get 之前，RP 可以檢查自己的 Cookie，判斷使用者是否已登入。我們已在這篇文章中進一步說明這項問題。 |
| 多個 ID 提供者選項 | 瀏覽器如何在 FedCM 中顯示多個 ID 提供者的登入選項？ | 開發人員說明文件提供多個 IdP 的顯示方式相關資訊。利害關係人可以在 chrome://flags 中啟用 fedcm-multi-idp 標記，試用這項功能。 |
| 瀏覽器和 IdP | Chrome 等瀏覽器是否可以充當 IdP？瀏覽器可以使用儲存的帳戶和設定檔資料，做為可信任的驗證來源。 | 由於瀏覽器可以修改 (例如透過擴充功能)，因此如果瀏覽器直接聲稱已通過電子郵件驗證，除非經過額外的伺服器驗證，否則我們無法信任。因此，我們不建議使用純粹以用戶端為基礎的解決方案。 我們已在這篇文章中進一步討論這個問題。 |
| API 規格 | 討論 IdentityCredential.disconnect() 演算法的參數是否應為必要或選用項目。 | 不過現在我們已順利解決這項問題。詳情請參閱這裡。 |
| API 安全性 | 如果 RP 有 XSS 漏洞，則在 FedCM 登入程序中發生符記外洩的疑慮。攻擊者可在惡意程式碼中執行 navigator.credentials.get，藉此取得權杖。 | FedCM 不會造成新的 XSS 風險，這些風險是網頁應用程式和現有驗證通訊協定固有的風險。為降低這些風險，RP 應驗證 ID 權杖中的 aud 要求，並只接受在自身來源發行的斷言。如這篇文章所述，目前已有廣泛認可的最佳做法，可確保這類權杖交換機制，並可搭配 FedCM 使用。 此外，Storage Access API 可搭配 FedCM 使用，且在先前有 FedCM 呼叫時，系統會自動授予 Storage Access API 呼叫。這應該會啟用 GitHub 問題中討論的內嵌重新導向流程。 |
| API 規格 | FedCM 設定端點回應中，client_metadata_endpoint 是必填欄位。空白物件是有效的回應，而 Chromium 會默默忽略 404 回應，這表示端點在實際上會視為選用項目。 | 我們同意可以變更規格，以反映這項異動，並將 client_metadata_endpoint 設為選用欄位。 |
| API 使用方法 | 由於瀏覽器控制的使用者介面無法透過 DOM 存取，因此無法測試 FedCM 實作項目。 | 我們支援瀏覽器自動化 API，可用於回歸測試，以解決這些問題。這些 API 的說明文件請見這裡。 |
| API 規格 | 規格第 3.2 節未記錄 login_url 參數，但該參數是設定端點回應的必要部分。 | 我們已提交說明文件更新，在第 3.2 節中加入 login_url 參數。 |
| API 規格 | 關於 FedCM 中潛在追蹤向量的疑慮。IdP 可以將 ID 插入做為路徑參數，插入至設定端點回應中指定的端點 (accounts_endpoint、client_metadata_endpoint)，並使用這些 ID 將帳戶和用戶端中繼資料要求關聯起來。 | 雖然我們沒有證據顯示 IdP 會將 ID 插入這些端點，但我們正積極考慮採取緩解措施來解決這個問題。 |
打擊垃圾內容和詐欺
Private State Token API (和其他 API)
本季未收到任何意見回饋。