2024 年第 4 季季度報告，摘要說明收到的 Privacy Sandbox 提案生態系統意見回饋，以及 Chrome 的回應。
根據對 CMA 的承諾，Google 同意每季公開報告與 Privacy Sandbox 提案相關的利害關係人參與程序 (請參閱承諾書第 12 段和第 17(c)(ii) 段)。這些 Privacy Sandbox 意見回饋摘要報表是透過匯總 Chrome 從各種來源 (如意見回饋總覽所列) 收到的意見回饋而產生，包括但不限於 GitHub 問題、privacysandbox.com 提供的意見回饋表單、與業界利益相關者開會，以及網路標準論壇。Chrome 歡迎生態系統提供的意見回饋，並積極探索如何將所學到的知識融入設計決策。
意見回饋主題會依據每個 API 的普遍程度進行排名。我們會將 Chrome 團隊收到的意見回饋總數匯總，並依數量由多到少排序。我們檢視公開會議 (W3C、PatCG、IETF) 的討論主題、直接意見回饋、GitHub 和 Google 內部團隊和公開表單中常見的問題，找出常見的意見回饋主題。
具體來說，我們審查了網路標準機構會議的會議記錄，並考量直接意見回饋、Google 的個別利益相關者會議記錄、個別工程師收到的電子郵件、API 郵寄清單，以及公開意見回饋表單。接著，Google 就與參與這些宣傳活動的團隊進行協調，以便判斷與各個 API 相關的各個主題的相對普遍程度。
我們根據已發布的常見問題、對利益相關者提出的問題的實際回應，以及為了這項公開報告而特別決定的立場，說明 Chrome 對意見回饋的回應。我們特別收到了與 Topics、PA API 和 Attribution Reporting API 相關的問題和意見回饋，這些問題和意見回饋反映了我們目前的開發和測試重點。
我們最近收到的意見回饋可能尚未獲得 Chrome 的回應。
縮寫詞彙表
- ARA
- Attribution Reporting API
- CHIPS
- 具有獨立分區狀態的 Cookie
- DSP
- 需求端平台
- FedCM
- Federated Credential Management
- IAB
- 互動廣告協會
- IDP
- Identity Provider
- 網際網路工程任務組 (IETF)
- 網際網路工程任務組
- IP
- 網際網路通訊協定地址
- openRTB
- 即時出價
- 延長賽
- Origin Trial
- PA API
- Protected Audience API (舊稱 FLEDGE)
- PatCG
- Private Advertising Technology Community Group
- RP
- 依賴方
- RWS
- 相關網站集合 (原稱第一方集合)
- SSP
- 供應端平台
- UA
- 使用者代理程式字串
- UA-CH
- 使用者代理程式用戶端提示
- W3C
- 全球資訊網協會
- WIPB
- 故意隱藏 IP
一般意見回饋，沒有特定 API/技術
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 使用承諾 | 承諾第 G 節對於 Privacy Sandbox 的可行性至關重要。如果無法保證 Google 自家廣告業務將專門使用沙箱技術，就會提高日益降低的效用風險，以及 Google 出售這項技術的可能性。這類分割或減少效用，將對開放網站上以隱私為優先的目標對象造成生存威脅。 | 這些承諾並未保證 Google 自有的廣告業務會專門 使用 Privacy Sandbox 技術。Google 打算採用組合式方法來實現可尋址性，其中將納入 Privacy Sandbox 技術，第三方也能使用這項技術。我們瞭解，廣告生態系統中普遍採用組合式廣告。 我們認為，開發人員仍應具備隱私權保護工具和技術。我們會持續提供 Privacy Sandbox API，並持續投入心力，進一步提升隱私保護與實用性。 |
| 管理 | 所提治理模式並未納入正式諮詢或申訴程序中的問責機制。 | 答錯了。(i) 決策系統和相關出版品，以及 (ii) 申訴程序都設有特定機制，以確保負責。此外，監控受託人會詳細監督這些功能的運作情形。 |
| 管理 | 提供意見指出模型未包含建立和維護跨平台標準的條款。 | 沒有任何治理模式可以強制其他參與者 (在本例中為瀏覽器) 採用標準。因此，我們並未提出需要跨平台採用標準的模型。Google 將繼續參與標準論壇，在該論壇中提出提案和分享實施提案的經驗，這也是常見的活動。 |
| 管理 | 建議將諮詢期延長至至少 2 個月。所提治理模式無法讓生態系統有足夠的時間分析所提變更的影響。 | 三週的時間並非特定變更的完整意見回饋期，因為現有的意見回饋週期 (時間長得多) 會持續進行。諮詢程序則是在現有策略決策程序中，提供新的正式意見回饋時機。因此，第三方在功能開發期間，仍可透過各種論壇 (包括 GitHub、W3C 和 IAB Tech Lab 等廣告標準機構) 提供意見。以這種方式建構意見回饋週期，可讓生態系統有時間分析並分享對提案變更的看法，而不影響開發程序。 |
| 管理 | 要求提供有關未來治理計畫的詳細資訊。 | 在 CMA 2024 年第 2 季/第 3 季報告中，我們列出建議的治理模式摘要 (請參閱 3 至 5 頁這裡)。 |
| 例外狀況要求 | 為已同意的使用者，要求存取第三方 Cookie (3PC) 的例外狀況。 | 同意為了特定資料處理目的存取裝置和儲存裝置資料，並不表示使用者想在 Chrome 中覆寫 3PC 設定。允許網站層級覆寫使用者的 3PC 設定，可能會造成嚴重的濫用行為，而且 Chrome 無法審查所有可能導致例外狀況的網站行為。 |
| Privacy Sandbox | 要求提供 Privacy Sandbox API 選擇加入率。 | 我們目前沒有打算將這項資訊分享給生態系統。歡迎開發人員呼叫已部署程式碼的 API，以便估算 Privacy Sandbox API 的可用性。 |
| 來源試用 | 是否有延長來源試用期計畫？ | 來源試用計畫已延長至 2025 年 4 月 14 日。 |
| Privacy Sandbox | 請提供簡明扼要的非技術性說明，強調 Privacy Sandbox 的商業價值，並爭取高層主管的支持。 | 我們最近在 privacysandbox.com 這裡新增了「商家資源」專區，提供相關資訊。 |
| 模式 B | 瀏覽器處於「模式 B」時，目前的 Cookie Jar (1PC、3PC、本機儲存空間) 會保留還是會清除？ | 系統不會清除目前的 Cookie Jar。3PC 仍可在第一方內容中使用。 |
| 更新 Chrome 上的 3PC 方法 | 日後 Chrome 是否會完全移除 3PC？ | 我們建議採用更新的做法，提升使用者選擇權。如這篇文章所述，我們並未淘汰 3PC，而是會在 Chrome 中推出全新體驗，讓使用者在瀏覽網頁時做出明智的選擇，並隨時調整選擇。我們正在與監管機構討論這項新做法，並會在推出前與業界展開合作。 |
| Chrome 測試 | 要求繼續提供 Chrome 輔助測試標籤。 | Privacy Sandbox 團隊瞭解各家公司希望繼續使用Cookie 淘汰標籤。延長標籤可用性的程序與延長來源試用的程序類似。在這個程序中，實驗只能一次延長三個 Chrome 里程碑。舉例來說，Chrome 最新的 Intent to Extend Experiment (I2EE) 實驗針對 Cookie 淘汰標籤，已延伸至 Chrome M130 到 M132 版本。這項功能會在 2 月初的 M133 穩定版發布前，為標籤提供支援。其他擴充功能也會經過相同的程序，因此建議您訂閱 blink-dev 電子郵件群組，以便掌握最新消息。 |
註冊與認證
本季未收到任何意見回饋。
顯示相關內容和廣告
主題
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 規格 | Android (依應用程式名稱) 和 Chrome (依主機名稱) 之間是否共用分類器模型？ | 不，兩者是不同的模型，因為它們有不同的分類法。 |
| 主題分類的精細程度 | 主題過於籠統，無法與第一方資訊搭配使用。 | Topics 分類法旨在兼顧實用性和隱私權。雖然我們評估了可用來讓主題更具體化的機制，但基於安全和隱私權等考量，我們最終決定不採用。 廣告技術人員可以結合所有可用的工具，例如機器學習和來自隱私權保護 API 的隱私權保護信號，以及內容比對資料、廣告素材資料和第一方資料，以獲得最佳成效。如需進一步指引，請參閱這篇文章。 |
| API 使用方法 | Topics API 的涵蓋率偏低。 | 涵蓋率偏低的常見原因包括： - 使用者控制項/選擇不採用 - 發布商控制項/選擇不採用 - 網站資格 (以下網站未獲准與主題相符：不安全的網站、WebView、iOS 版 Chrome 和無痕模式) - 使用者限制 (未滿 18 歲或使用無痕模式的 Chrome 使用者無法觀察及指派主題) - 賣家觀察要求 (呼叫端必須先在與可用主題相關聯的網站上看到使用者) - 實作時間 (需要約 4 週的時間，才能讓呼叫端觀察到使用者) |
| API 使用方法 | 請提供有關 Topics API 用法的資訊，因為「Networking」分頁似乎顯示有呼叫傳送及擷取，但 chrome://topics-internals/ 並未顯示觀察器記錄。 | 使用 HTTP 標頭機制與 Topics API 互動時，主題會透過 Sec-Browsing-Topics 要求標頭傳送，但只有在伺服器以 Observe-Browsing-Topics: ?1 回應標頭回應時，才會觀察到這些主題。詳情請參閱這篇文章。 |
| 參與 Chromium | 在電腦上，Chrome 會與其他以 Chromium 為基礎的瀏覽器共用相同的觀察和排名背景嗎？ 在行動裝置上，Android Chrome 會與其他採用 Chromium / In-App Chromium 的 Android 瀏覽器共用相同的觀察和排名背景嗎？ |
Chrome 不會將主題資料分享給裝置上的其他瀏覽器。 |
| 規格 | Topics API 如何判斷使用者瀏覽的網頁是否視為「主題記錄項目」？ | 網頁瀏覽活動必須包含「observe」呼叫 (可來自任何呼叫端)，才能納入每週主題計算作業。如果沒有「observe」呼叫，系統就不會將該造訪納入主題記錄。 |
| 安全性 | Topics API 如何防止一個呼叫端取得其他呼叫端觀察的主題？ | 請參閱這篇文章，瞭解相關說明。 |
| 分類 | 在每個週期中，Topics API 的觀察資料如何使用樹狀結構分類法？ | 計算前 5 個主題時，系統只會考量分類器提供的原始主題，排名則會根據 (i) 網頁瀏覽頻率和 (ii) 優先順序分數 (請參閱規格) 決定。 計算各個前 5 大主題的觀察者時，會納入觀察到主題或其任何子主題的呼叫端。 |
| 規格 | 請提供有關回應中 5% 隨機雜訊的其他資訊。 | 每個週期都會有 5 個熱門主題。如果瀏覽記錄未提供 5 個主題，系統會隨機選擇主題，直到達到 5 個為止。我們稱之為「填充主題」。除非呼叫端在過去幾週內觀察到使用者造訪含有該主題的網站 (呼叫 API)，否則不會收到這些隨機填充的主題。 呼叫 API 時，系統會計算每位使用者、每個網站和每個時距的雜湊。如果該雜湊值小於傳回雜訊主題的機率，系統就會選取每個使用者、每個網站和每個週期的隨機主題來傳回。不過，只有在呼叫端觀察到該使用者/網站/時距的對應未雜訊主題時，系統才會傳回雜訊主題 (例如不會篩除) (請參閱說明)。這項篩選功能可確保系統在 5% 的時間內，無論觀察能力如何，都會傳回雜訊主題。 |
| 規格 | 跨週重複主題的運作方式為何？API 是否會在各週之間獨立挑選，然後合併？ | 系統會分別計算每週 (每個週期) 的主題。從每個訓練週期傳回的特定主題，取決於呼叫端所在的網站。 我們不會考慮主題是否會在特定呼叫端的各個時段重複 (因此應考慮選取其他主題)，但歡迎您在這裡提供更多意見回饋。 |
Protected Audience API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| A/B 測試 | 這裡所述的共用儲存空間解決方案會增加延遲時間，且失敗率偏高 (也就是說，有相當大比例的流量最後都沒有人口群 ID)。熵值偏低的 ID (例如3 位元) 就足以進行有效的 A/B 測試，且不會對隱私權造成重大影響。 | 我們認為共用儲存空間解決方案仍是可行的做法，但我們正在考慮這項要求，如果這項功能是優先考量，歡迎生態系統提供更多意見回饋。 |
| 報表 | 請在 reportWin() 中要求額外位元，特別是因為我們瞭解 PA API 中的新點擊和展示報表會使用 6 到 8 位元，有效減少其他 PA API 報表可用的位元。 |
基於隱私權考量，我們不再考慮將 modelingSignals 位元數增加到目前的 12 位元以上。 我們邀請生態系統提供意見回饋，針對私密模型訓練提案提出意見。該提案旨在在不受 Privacy Sandbox 位元限制的安全環境中，支援機器學習訓練需求。 |
| 興趣群組 | 請為興趣群組 (IG) 要求 90 天的生命週期，因為 30 天不夠長。 | 如同我們在網誌文章中所述，我們預計將 IG 的生命週期延長至 90 天，並在這裡提供相關說明。 我們目前正在進行實作，並會在可行時分享推出時程。 |
| 興趣群組 | 要求 IG 委派作業的動態更新。 | 我們已知多位利害關係人提出這項要求，目前正在研究解決方案。 我們會在 GitHub 上分享最新消息，並歡迎生態系統提供更多意見回饋。 |
| 裝置端 | 讓生態系統展現更多價值，繼續投資裝置端 PA API 解決方案。 | Privacy Sandbox 團隊持續開發以隱私權強化技術 (PET) 為基礎的 API (包括 PA API)，為開發人員提供更多瀏覽器隱私權保護選項。這些技術現在已廣泛運用於 Chrome 瀏覽器 (並非只有 1%，如部分開發人員所誤解)。無論使用者是否啟用 3PC，開發人員都可以選擇將以 PET 為基礎的解決方案整合至自家產品，就像許多公司選擇採用瀏覽器以外的其他以 PET 為基礎的解決方案一樣。許多開發人員已投資裝置端 PA API 解決方案，藉此擴展確定性第一方目標對象信號，進而改善各網站的觸及率。我們瞭解，只有在更多第三方 Cookie 停用後，部分開發人員才會選擇使用 Privacy Sandbox API 或其他以個人資料保護為重點的解決方案，而這些開發人員正在等待相關資訊，以便推測有多少瀏覽器會保留第三方 Cookie。我們瞭解這些開發人員會等到找到所需資訊後，再做出產品決策。 |
| 興趣群組 | 允許 SSP 在 IG 創作內容中扮演任何角色，以及與這些角色相關的角色。供應方平台認為這項功能是他們提供附加價值的重要一環，希望能協助發布商透過供應方平台銷售 IG。 | 我們收到多方利益相關者提出的要求，希望我們支援更進階的 IG 委派作業，而賣方平台在這項程序中可提供額外價值。 我們正在研究如何找到最佳解決方案，讓不同參與者參與目標對象擴展程序。我們會在 GitHub 上分享最新消息，並歡迎生態系統提供更多意見回饋。 |
| 報表 | forDebuggingOnly 和 Private Aggregation API 之間的「非零出價」報表數量有差異。 | 我們預期會出現差異，原因有二： 首先，Private Aggregation API 偵錯模式只有在裝置上允許 3PC 時才可使用，而 forDebuggingOnly API 則一律可用於未取樣的情況 (這項行為最終會變更，詳情請參閱這裡)。 其次，Private Aggregation API 有貢獻限制，而 forDebuggingOnly 則沒有。 不過，這項意見回饋顯示可能有其他因素導致不一致的情況，我們正在與第三方利益相關者合作，以解決這個問題。 |
| 點擊率 | 如更新的點擊率信號提案所述，系統會透過傳回新的 HTTP 回應標頭，為透過「attributionsrc」屬性啟動的符合資格的請求註冊觀看次數和點擊次數。這個回應標頭會包含來源清單，可用於指出哪些其他方可在匯總計數中納入這些觀看次數和點擊次數。這是否表示廣告技術可以任意設定來源？ | 點擊率說明中已說明，將瀏覽或點擊事件提供給匯總的瀏覽次數和點擊次數 (稱為「提供來源」) 的廣告技術，可能會在回應標頭中加入選用參數，以便指定「一或多個 IG 擁有者來源，可將這項事件納入計算的瀏覽次數和點擊次數，並在 Protected Audience 競價中提供給 generateBid() 呼叫」(稱為「符合資格的來源」)。不過，系統不會自動將這些觀看次數和點擊次數計入觀看次數和點擊次數。相反地，每個廣告技術必須在 IG 中指定一組「提供來源」，從中納入觀看和點擊事件，且只有這些提供來源的資料會計入廣告技術 generateBid() 呼叫的觀看和點擊次數。這項機制需要雙方簽署協議，並可防止惡意玩家影響其他廣告技術的觀看次數和點擊次數。這也表示，如果「提供」廣告技術任意設定「符合資格的來源」，不會影響這些符合資格的來源的觀看次數和點擊次數，除非這些符合資格的來源明確且刻意在 IG 中加入該提供來源。 |
| 私人模型訓練 | 在某些情況下，DP-SGD (差異化隱私 - 隨機梯度下降) 會破壞在反向傳播期間計算的梯度稀疏度，導致訓練程序速度大幅下降。是否有任何技術可用於解決這個問題，或是對這個問題有任何想法？ | 我們知道有某些技術可在 DP-SGD 中保留稀疏性 (例如這項技術)，並且正在研究如何在私人模型訓練基礎架構中支援這類技術。 我們會在情況有變時提供最新消息，也歡迎您在這裡提供更多意見回饋。 |
| 排除指定 | 請要求更新 IG 負面篩選功能的推出時間，詳情請參閱這篇文章。 | 如這篇文章所述，我們計劃在 PA API 出價中支援負向 IG。 我們會在可用時分享推出時間表，也歡迎您在這裡提供更多意見回饋。 |
| 出價 | 出價時是否可以合併多個 IG？ | 目前無法使用 PA API 執行這項操作。PA API 的設計理念是將 IG 與單一網站對使用者的相關資訊連結起來，這也是與生態系統廣泛討論的核心。這種做法可讓廣告技術人員建構各種解決方案，協助廣告客戶擴大自有目標對象的網路觸及範圍。 我們瞭解 Microsoft 的 Ads Selection API 提案確實提出了不同的設計，目標對象是根據各網站的資訊。 我們會持續密切關注他們的做法，但在考慮是否對 Chrome 做出類似變更前，希望能先與隱私權社群等生態系統成員進行更多討論。 |
| 原生廣告 | 擔心 PA API 是否能充分支援原生廣告的各種格式和算繪需求，以及 PA API 是否能提供廣告素材所需的靈活度和最佳化功能，以便有效放送原生廣告。 | 我們正積極研究如何進一步支援原生廣告，也歡迎生態系統提供更多意見回饋。 |
| 報表 | 請改善報表指令碼的穩健性，因為報表指令碼會與出價指令碼競爭資源，且在導覽離開正在進行的競價時，可能會遺失。 | 我們希望盡快在 GitHub 上發布回應，但我們認為這些疑慮不會對實際有效的報表造成太大影響。 |
| 巨集取代 | 競價設定傳遞的巨集替換項目無法與部分第三方設定搭配運作。 | 根本原因是並非所有標記為「模式 A/B」的流量都已啟用這項功能。我們最近決定在所有標示為 A/B 模式的流量中啟用這項功能 (以及其他類似情況的功能)。我們預計在 2025 年第 1 季實施這項異動。 歡迎在這裡提供更多意見回饋。 |
| 說明文件 | 請說明清楚，因為說明文件中似乎有差異，generateBid() 中 browserSignals 物件中的近期度值的測量單位。 |
我們已在這裡進一步回應此問題，並相應更新說明文件。正確答案是計算單位為毫秒。 |
| 報表 | 要求第三方報表；雖然 DSP 和 SSP 會收到 Chrome 的曝光通知，但中介層技術供應商則不會收到。 | 我們目前正在討論這項功能要求，歡迎提供更多意見回饋。 |
| 興趣群組 | 請提供指引，說明如何在使用平行 IG 競價工作流程時，動態排除興趣群組買家。 | 如需相關指南，請參閱這篇文章。 |
| 原生廣告 | 針對特定網頁載入作業的獨立 PA API 競價，可避免在同一網頁上篩除廣告。 | 我們正積極研究如何進一步支援原生廣告，包括稱為「原生」的推薦小工具，以及在一個單元中顯示多則廣告的做法。我們瞭解目前的設計可能無法篩除同一頁面的廣告，而其他保護措施 (例如 Fenced Frames) 也可能會進一步防止這種情況發生。 |
| 原生廣告 | 現有的 PA API 功能 (例如廣告素材掃描、報表等) 會依賴網址信號，因此可能需要調整，以便處理原生廣告素材中使用的 JSON 物件。 | 我們正積極研究進一步支援原生廣告的可能性，並評估改用 PA API 以利原生廣告顯示的可行性。 |
| 廣告驗證 | 由於 perBuyerSignals 的延遲和快取限制，PA API 中的第三方品牌安全性受到影響，這對動態內容來說是個問題。 | 我們瞭解 SSP 和 DSP 需要決定最佳快取 TTL，以平衡流量塑造目標和品牌安全性上限 TTL，確保快取資料仍與品牌安全性相關。我們正在調查這個問題，並會在調查進展時提供最新消息。 |
| 廣告驗證 | 如要進行出價後品牌安全評估，就必須由 SSP 進行 FullpageURL 巨集替換。 | 目前建議 SSP 提供 deprecatedReplaceInURN 信號。 |
| 廣告驗證 | 若 SSP 在後置出價驗證時使用的巨集格式缺乏標準化，可能會導致資料處理和分析出現不一致和錯誤。 | 賣方平台和廣告驗證工具應直接合作，明確定義巨集使用方式的規範和規格，推動賣方平台巨集格式的標準化，確保一致性，並避免資料處理和分析作業發生錯誤。這項活動非常適合由互動廣告協會科技實驗室 (IAB Tech Lab) 等廣告標準組織負責。 |
| 廣告驗證 | 廣告主和廣告驗證者需要一種機制，可連結相同發布商情境的出價前和出價後檢查，以便進行偵錯和疑難排解。 | 在出價後驗證方面，您可以選擇將事件層級報表納入競價和廣告活動信號。這可能會啟用與出價前決策記錄的彙整作業。我們正在研究實現這項功能的可能模式，並會在開發過程中提供最新消息。 |
| 廣告驗證 | 要求探索可信任的鍵值 (TKV) 伺服器解決方案 (DSP 和 Ad Verifier 擁有)，以便在出價前解決出價後的柵格框限制。 | 我們正在評估這項要求，並歡迎生態系統提供更多意見回饋，以便找出可支援出價前品牌安全性，並簡化各方協調要求的解決方案。 |
| 原生廣告 | 針對原生廣告，要求賣方進行出價後的算繪稽核。 | 我們正積極研究進一步支援原生廣告的做法，並考慮改用這類現有功能來協助原生廣告算繪。 |
Protected Auction (B&A Services)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 延遲時間 | 沒有充分緩解延遲問題。雖然 B&A 服務可能會從長遠角度緩解這個問題，但 Google 並未承諾在 Chrome 的 3PC 變更前，就會廣泛提供這項服務。 | 過去幾季，我們對裝置端延遲時間進行了多項改善。我們也會視需要建構及擴充 B&A 服務。我們最近更新了延遲最佳做法指南，其中包含更多資訊，說明如何充分利用這些功能。我們也持續開發新的延遲改善功能，部分功能可在這裡查看。 |
| (先前幾季也有提及) 競價安全性 |
要求進一步說明如何防止/減輕嘗試竄改裝置端競價的行為 (例如 Google 是否認為這是重大風險)。 | 我們的回覆與上季相同： 「PA API 廣告的報表機制會保留目前用於區分人流和機器人流的資訊。此外，PA API 可使用目前的網域技術，納入或排除特定網域。詳情請參閱我們對 IAB Tech Lab 的 Privacy Sandbox 報告回應。」 |
| 地端部署解決方案 | 擔心由於缺乏私有雲支援，加上支援路徑冗長且不透明，因此大型供應商可能不會採用 Privacy Sandbox 或 B&A。 | 我們致力於擴大 Privacy Sandbox 服務的基礎架構；我們最近宣布支援 Azure 雲端，並持續調查可能的解決方案，為私有雲端提供類似的隱私權和安全防護機制。 自 10 月以來，我們持續研究在內部信任執行環境 (TEE) 中，保護 Chrome 使用者隱私權的潛在方法，並已取得進展。我們目前正進行相關研究，希望能與生態系統利益相關者共同驗證不同的做法，並預計在第 1 季開始收集意見。生態系統的意見回饋和協作，有助於改善任何可能的解決方案。 |
| 測試 | 是否可以建立 TEE 來測試 PA API 報表解決方案 (即時報表和私人匯總)？ | 針對匯總服務測試，廣告技術人員可以使用測試資料和本機測試工具，產生功能測試摘要報表。請參閱本機測試程式碼研究室。 如要測試 TEE 中的匯總功能，廣告技術人員必須完成上述程式碼研究室必備條件中提及的註冊程序。 歡迎您 在這裡提供更多意見回饋。 |
| 交易 K/V 整合 | 要求能從 KV 中提取交易相關資訊，以便用於業務用途。 | 我們正在評估這項功能要求，並會在 GitHub 上提供最新消息。 |
| 不勝出 Deal Measure |
要求信號或瞭解 SSP 未勝出的原因。 | 我們正在評估這項要求，並會在 GitHub 上提供最新消息。 |
| 功能建議 | 要求 Privacy Sandbox 提供字典結構，協助將一組廣告與相應的交易 ID 集合配對。 | 我們正在評估這項要求，並評估其他方法，以便在儲存交易 ID 時縮減 IG 大小。我們會在 GitHub 上提供最新消息。 |
| 成效 | 解決方案：評估可能因出價指令碼大小而錯失的廣告競價商機。 | 我們正在評估這項要求，也歡迎您在這裡提供更多意見回饋。 |
| 規格 | 目前 B&A 只會讀取 prevWins 欄位，而非 spec 中取代 prevWins 的最新欄位 prevWinMs。 | B&A 確實不會將 prevWins 中的時間長度 (以毫秒為單位) 傳遞至 generatebid()。Chrome 會以秒為單位傳送時間長度，以確保酬載的額外負擔較少，這裡的修正方式是讓 B&A 將秒數轉換為毫秒。B&A 會在 browserSignals 中提供 prevWins 和 prevWinsMs，讓這項功能與裝置端競價相容。請注意，即使是裝置端的網站競價，prevWins 和 prevWinsMs 也對應相同的值，且 prevWinsMs = prevWins * 1000。 我們正在優先處理修正問題。 |
| 說明文件 | 說明文件並未清楚說明如何測試賣家前端 (SFE)，因此建議在完成部署後提供額外的測試指南，以及如何使用 Bazel 進行建構。 | 這個程式碼研究室已發布，可做為指南，讓更廣泛的生態系統更輕鬆地測試其 SFP。 |
| 部署作業 | 是否有提供 B&A 預先建構二進位檔的計畫？ | 我們正在考慮為 B&A 提供預先建構的二進位檔，但目前尚未有具體的時間表。在此之前，廣告技術人員可以自行建構二進位檔，並使用提供的雜湊值進行驗證。 |
| 部署作業 | 是否應支援所有協調類型 (伺服器、用戶端、混合)，或是應優先支援某種類型？ | 我們沒有任何具體建議，說明廣告技術應採用哪種模式。選擇取決於各種因素，但最終還是要以顧客的最佳利益為依歸。 |
| 測試 | 請說明 B&A 建構期間失敗的測試。 | 這可能是不穩定測試的結果。我們建議廣告技術人員使用 --no-tests 旗標搭配所有 build_and_test_all_in_docker 建構指令，以便略過測試執行作業。 |
| 記錄 | 想瞭解為何 GCP 的記錄探索器中的記錄會在測試模式下標記執行 SFE 的 VM 執行個體，但在正式版模式下，記錄不會標記 VM 執行個體。 | 很難一概而論，因為這取決於實際看到的內容，但一般來說： - non_prod 中的記錄可能是雲端服務供應商 (在本例中為 GCP) 重新導向的 stderr 記錄，而 GCP 則加入了標記。 - VM 產生的記錄通常會標示 VM 執行個體，而二進位檔產生的記錄則不會標示 GCP。 - TEE 中的 Open Telemetry 會匯出產品記錄，這些記錄具有不同的標記。 以下是 non_prod 和 prod 可用的詳細資訊。 |
| B&A | 停用 OTEL 記錄時，缺少機密資料會發生 403 錯誤。 | 這個問題已在 4.1 版更新中修正，說明文件也已相應修改。 |
| B&A | 缺少 GCP Terraform 設定的 outputs.tf 檔案會導致錯誤。 | 不過現在我們已順利解決這項問題。 |
| 測試 | 在測試模式下擷取私密金鑰時發生錯誤。 | 在這些情況下，請確認伺服器是以 TEST_MODE=true 的模式運作。 如需說明，請參閱這篇文章。 |
| 發展藍圖 | 是否有計劃讓 getInterestGroupAdAuctionData 接受多個賣家來源，並將賣家來源對應至 B&A 酬載密文？ | 是的，我們預計新增支援功能，讓 navigator.getInterestGroupAdAuctionData() 能夠接受多個賣家。 |
| KV 規格 | KV 網址 (trustedScoringSignalsURL) 是否可做為承諾傳送？ | 請參閱這篇文章的說明。 |
| B&A | 要求建立新的平台標頭，向 B&A 賣方指出用戶端 (瀏覽器) 需要哪些功能才能進行私下競價。 | 我們目前正在討論這項功能要求，歡迎提供更多意見回饋。 |
| 流量型態 | 提案：降低代管 B&A 伺服器的額外成本，尤其是 DSP。 | 我們目前正在這裡討論這項提案，也歡迎您提供更多意見。 |
| 自備二進位檔 |
建議更新說明，明確指出系統支援所有二進位檔。 | 我們已更新這項功能，請參閱這篇文章瞭解詳情。 |
| KV 呼叫 | generateBid() 會等待所有 Key-Value (KV) 儲存器呼叫完成，還是獨立執行？KV 批次處理作業對時間有何影響？ |
請參閱這篇文章的說明。 |
| 成效 | 請提供有關重複使用出價指令碼的其他說明文件，並建議在指令碼中設定快取控制標頭。 | 說明文件已新增至這個頁面。 |
| 成效 | 要求考慮並探索非同步載入資源 (例如出價指令碼) 的功能，以減少裝置端競價延遲時間。 | 我們目前正在討論這項功能要求，歡迎提供更多意見回饋。 |
| 同意聲明記錄 | 嘗試透過設定 CONSENTED_DEBUG_TOKEN 使用同意聲明記錄時，發生的錯誤需要釐清。 | 在這些情況下，請確認機密資料管理員中包含 CONSENTED_DEBUG_TOKEN，ENABLE_OTEL_BASED_LOGGING 設為 true，且 TELEMETRY_CONFIG 設為 mode: PROD。 請參閱這個說明文件，其中參照了這個來源。 |
| 記錄 | 是否可透過 B&A 取得 forDebuggingOnly 事件？ | 自 2024 年 4 月起，單一賣方競價已支援「forDebuggingOnly」的 B&A 廣告活動。我們預計很快就會為多賣家競價啟用這項功能。 |
| Worklet 記錄 | 要求讓工作單元記錄功能與 ChromeDriver 相容。 | 我們正在評估這項要求，也歡迎您在這裡提供更多意見回饋。 |
評估數位廣告
歸因報表 (和其他 API)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 偵錯報表 | 在 Chrome 上採用更新版 3PC 方法後，廣告技術人員如何取得 ARA 偵錯報表？ 如果使用者保留 3PC 並啟用 Privacy Sandbox API，廣告技術人員是否仍可存取 ARA 偵錯報表？ |
廣告技術人員將可針對同時啟用 3PC 和 ARA 的使用者，使用 Cookie 和無 Cookie 偵錯解決方案。關閉 Cookie 後，他們只能存取匯總偵錯解決方案。 如需偵錯解決方案的詳細資訊，請參閱這篇文章和這篇文章。 |
| 功能偵測 | 請提供有關如何在伺服器端為 ARA 進行功能偵測的指引。 | 目前，您可以根據使用者代理程式字串中的 Chrome 版本，判斷是否支援 ARA 功能。 歡迎您針對此議題提供更多生態系統意見回饋。 |
| 功能建議 | 要求在 ARA Aggregate shared_info 中使用的 source_registration_time 更精細，例如將其捨去至小時或分鐘 (而非一天)，並可設定為考量時區 (目前僅限世界標準時間)。 | 將 source_registration_time 欄位四捨五入至最近的一天，是一種隱私權機制，可降低廣告技術將特定使用者與特定來源登錄連結的能力。目前 source_registration_time 是根據世界標準時間計算，廣告技術可以調整廣告報表以反映這項變更。 歡迎您在這裡提供更多有關這項要求的生態系統意見回饋。 |
| 規格 | 要求釐清「trigger_data」和「priority」的規格，尤其是當這些屬性與陣列值搭配使用時。 | 這些欄位不接受陣列值。說明中的方括號並非表示陣列，而是表示文字不是示例值，而是帶有說明的預留位置。 如方括號內的文字所示： - trigger_data 是 int-64 - priority 是經過簽署的 int-64 這兩個欄位都不接受陣列值。您也可以考慮使用 標頭驗證工具，讓 ARA 嘗試不同的值，並在說明文件不清楚時執行錯誤。 |
| Accelerated Mobile Pages (AMP) 廣告支援 | ARA 是否支援 AMP 廣告？ | 我們提出的 AMP 支援方式提案已發布在這個頁面，歡迎提供更多意見。 |
| 規格 | 在 ARA 的多層嵌入式廣告中，哪個網址會視為「來源網站」？ | 頂層網站的網址。 |
| (也曾在先前的季度中回報) 功能要求 |
要求將 event_report_window 最小值從 3600 秒 (1 小時) 降低為 1800 秒 (30 分鐘)。 | 在決定最短的回報時間範圍時，您必須兼顧實用性和隱私權考量。 事件層級報表的報表期間最短為 1 小時，這對維護隱私權和減輕特定類型的歷史記錄重建攻擊至關重要。 歡迎您前往這個頁面，針對這項要求提供更多意見。 |
| 噪音 | 進一步瞭解 ARA 事件層級報表中的雜訊如何實作，確保資料的正確解讀和運用。 | 如需更多詳細資訊，請參閱這篇文章和這篇文章。 |
| 報表 | 根據預設，匯總報表的 shared_info 不再包含 source_registration_time。 | 這是因為 API 異動，詳情請參閱這篇文章。 |
| 報表 | filtering_id 未出現在 chrome://attribution-internals/ UI 的「Aggregatable Reports」分頁中。 |
按一下資料列後，目前會在「觸發登錄」分頁標籤的詳細資料中看到 filtering_id，可用於確認資料列的有效性。我們瞭解在「可匯總報表」分頁中顯示這項資訊的實用性，並已在這裡解決這個問題。 |
| 歸因來源 | 要求說明歸因來源的運作方式。 | 如需相關說明，請參閱這篇文章。 |
| 應用程式到網站歸因 | 針對實作作業要求指引，以便在來源為作業系統或網頁時，能確保來源的正確性。 | 如需指引，請參閱這篇文章。 |
匯總服務
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 功能建議 | 要求 AgS 的逾時期限可設定，以及/或針對長期執行作業提供更多工作狀態資訊。 | 我們正在考慮推出可監控長時間執行作業的功能。 歡迎您針對此議題提供更多生態系統意見回饋。 |
| Terraform | 即使未設定 service_account_token_creator_list，Terraform 仍會嘗試修改帳戶的 IAM 政策。 | 開發人員可以在本機 modules/adtech_setup/main.tf 檔案中新增額外權限。 |
| 文件要求 | 請提供說明文件或 Codelab，說明如何監控匯總服務的健康狀態。 | 如要瞭解可用於監控服務和工作健康狀況的現有警報，請參閱 coordinator-services-and-shared-libraries 存放區中的相關運算子 terraform 檔案 (alarms.tf 和 monitoring.tf)。 我們將發布其他說明文件和指南，說明如何監控匯總服務工作。 |
| 資源調度 | 如何監控資源調度問題？ | 我們發布了這份指南的更新版本，其中說明瞭匯集服務的更大規模。 目前沒有直接信號可指出機器無法支援工作規模而發生失敗。間接信號包括：失敗前記憶體消耗量達 90%、工作會重複失敗。歡迎您針對這類信號的需求提供更多生態系統意見回饋。 |
| 規格 | AgS 報表批次的一般執行時間為何？ | 請參閱這篇文章的指引。 |
私密匯總 API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 功能建議 | 要求允許以 2^16 的敏感度，將浮點值 (包括負值) 貢獻至 contributeToHistogramOnEvent | 我們目前正在這裡討論這項提案，也歡迎您提供更多意見。 |
限制隱密追蹤
使用者代理程式縮減/使用者代理程式用戶端提示
本季未收到任何意見回饋。
IP 保護 (原稱 Gnatcatcher)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 地理位置 | 要求提供 IP 保護地理位置檔案。 | 如要取得 IP 保護功能的 IP 與大概位置對應檔案，請按這裡。請注意，這份檔案會定期更新。 |
跳轉追蹤因應措施
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 許可清單 | 更新後的職位不再處理允許清單或類似機制，這些機制與 Google 的決策程序無關。 | Google 不打算針對彈出追蹤緩解措施 (BTM) 建立任何許可清單；保護措施會一律套用至所有網域。 |
| 法規遵循 | ICO 應具備隱私權相關法規遵循的授權。 | 符合性狀態與 BTM 的應用無關，Google 不會就導入 BTM 的符合性做出任何決定。 |
| 競爭程度 | 據信 Google 可以使用 BTM (或其他措施) 排擠 PET 競爭對手，然後自行決定是否允許對方重返市場。目前的申訴程序可能會暫時禁止 PET 競爭對手使用 BTM 或類似措施。 | 目前的 BTM 提案旨在將跳出率追蹤做為一種技巧。雖然 Google 希望避免破壞可能涉及類似技巧的特定用途，但我們並無計劃為 BTM 提供個別豁免權。因此，Google 不會因為行使裁量權而排除競爭對手。 |
強化跨網站隱私界線
相關網站集合 (舊稱第一方集合)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| (上個季度也有提及) 相關網站集合 (RWS) 網域限制 |
目前的五個關聯網域限制，無法滿足跨網站評估用途。 | 我們的回應與先前幾季類似： 目前，我們不打算提高數字限制。這項限制是根據使用者隱私權考量、W3C 生態系統利益相關者提供的意見回饋，以及其他瀏覽器的類似實作方式 而制定。如需更多資訊，請參閱我們的網誌文章 (1、2)。 建議您檢查需要跨網站 Cookie 存取權的用途，並考慮採用我們針對身分用途、已驗證的嵌入內容和廣告用途的相關指南。 歡迎在這裡提供更多意見回饋。 |
Fenced Frames API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 原生廣告 | 由於 iframe 和發布商網頁之間的通訊受到限制，因此繼承發布商的樣式會受到限制，因此在 Fenced Frame 中顯示原生廣告會遇到挑戰。 | 我們正積極研究如何進一步支援原生廣告，包括在實施 Fenced Frames 後提供支援。 歡迎您前往這裡提供更多意見。 |
Shared Storage API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| API 使用方法 | 在某些裝置上，即使其他 Privacy Sandbox API 可正常運作，Shared Storage API 仍無法使用。 | 這項行為預期會影響參與共用儲存空間區隔劃分實驗的一小部分使用者 (約 1%)。這項實驗設定可用於評估 API 在各種情境下的效能和採用率。 |
| API 使用方法 | 寫入 Shared Storage 的動作是在發布商來源還是出價腳本來源下執行？初步測試顯示，當發布商來源與指令碼來源不同時，系統不會寫入任何內容。 | 這個問題已解決，只有在可能發生 devtools 錯誤的情況下，才會繼續保留。如需更多詳細資訊，請參閱這篇文章。 共用儲存空間會在 generateBid 呼叫的出價情境中，寫入買方來源。即使發布商網頁位於其他網域，寫入作業也不會與發布商來源綁定。 |
| API 使用方法 | 為防止惡意行為人讀取 Shared Storage 報表，我們採取了哪些防護措施？ | 透過呼叫origin，可將 Shared Storage 劃分區塊，因此惡意人士或廣告技術無法讀取其他廣告技術的 Shared Storage 資料。私人匯總報表會透過 TLS 直接傳送至相同的來源，因此無法遭到攔截。 |
CHIPS
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 分區 Cookie | Chrome 和 Firefox 在處理不同本機端連接埠的 Cookie 時，處理方式並不一致，尤其是在使用 Partitioned 屬性時。 | Firefox 會將使用不同連接埠的 localhost 視為不同的分割鍵。雖然這項行為符合安全性原則，但卻違反規格和 Chrome 的做法。 我們預計在 HTML 規格討論中與其他瀏覽器討論這個問題，並在 CHIPS 分割鍵發生變更時通知生態系統。歡迎您前往這個頁面，針對這個問題提供更多意見。 |
| 分區 Cookie | Clear-Site-Data 草稿誤將清除範圍擴大到發出網站的分區，與這裡提到的先前討論內容相違背。 | 這是標準規格文件中的錯誤，我們會盡快修正。說明文件的這一節會說明正確的行為，並與儲存空間分割說明文件存放區中的其他瀏覽器行為一致。Chrome 的實作方式已正常運作。 |
FedCM
本季未收到任何意見回饋。
打擊垃圾內容和詐欺行為
Private State Token API (和其他 API)
本季未收到任何意見回饋。