2024 年第 2 季和第 3 季的季度報告，摘要說明收到的 Privacy Sandbox 提案大環境意見回饋，以及 Chrome 的回應。
為履行對 CMA 的承諾，Google 同意針對其 Privacy Sandbox 提案，公開提供利害關係人參與流程的季度報告 (請參閱「承諾」第 12 和第 17(c)(ii) 段)。Google 於 2024 年 7 月 22 日宣布，Chrome 不會淘汰第三方 Cookie (3PC)，並提議推出新的做法，讓使用者選擇更多功能。因此，在 CMA 同意下，Google 並未向 CMA 提交 2024 年第 2 季的公開報告，以便 Google 和 CMA 有足夠的時間考量 Google 公告的影響。
這些 Privacy Sandbox 意見回饋摘要報表是透過匯總 Chrome 從各種來源 (如意見回饋總覽所列) 收到的意見回饋而產生，包括但不限於 GitHub 問題、privacysandbox.com 提供的意見回饋表單、與業界利益相關者開會，以及網路標準論壇。Chrome 歡迎來自生態系統的意見回饋，並積極探索如何將學習成果整合至設計決策。
意見回饋主題會依據每個 API 的普遍程度進行排名。我們會將 Chrome 團隊針對特定主題收到的意見回饋數量加總，並依數量由多到少排序。我們透過審查公開會議 (W3C、PatCG、IETF)、直接意見回饋、GitHub 和透過 Google 內部團隊和公開表單提出的常見問題，查看常見的意見回饋主題。
具體來說，我們審查了網站標準機構會議的會議記錄，並考量直接意見回饋、Google 的個別利益相關者會議記錄、個別工程師收到的電子郵件、API 的電子郵件發送清單，以及公開意見回饋表單。接著，Google 會協調參與這些各種外展活動的團隊，以便判斷與各個 API 相關的主題的相對盛行率。
我們根據已發布的常見問題、對利益相關者提出的問題的實際回應，以及為了這項公開報告活動而特別決定的立場，說明 Chrome 對意見回饋的回應。反映目前的開發和測試重點，並收到關於 Topics、Protected Audience 和 Attribution Reporting API 的問題和意見回饋。
目前報表統計期結束後收到的意見回饋，可能尚未視為 Chrome 的回應。
專有名詞詞彙表
- ARA
- Attribution Reporting API
- CHIPS
- 具有獨立分區狀態的 Cookie
- DSP
- 需求端平台
- FedCM
- Federated Credential Management
- FPS
- 第一方集合
- IAB
- 互動廣告局
- IDP
- Identity Provider
- 網際網路工程任務組 (IETF)
- 網際網路工程任務組
- IP
- 網際網路通訊協定位址
- openRTB
- 即時出價
- 延長賽
- Origin Trial
- PAT API
- Protected Audience API (舊稱 FLEDGE)
- PatCG
- Private Advertising Technology Community Group
- RP
- 依賴方
- RWS
- 相關網站集合 (原稱第一方集合)
- SSP
- 供應端平台
- TEE
- 受信任的執行環境
- UA
- 使用者代理程式字串
- UA-CH
- 使用者代理程式用戶端提示
- W3C
- 全球資訊網協會
- WIPB
- 故意隱藏 IP
一般意見回饋，沒有特定 API/技術
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 淘汰第三方 Cookie (3PCD) | Google 對 3PCD 的計劃為何？長期下來對數位廣告產業有什麼影響？ | 我們建議採用更新的做法，提升使用者選擇體驗。如這篇文章所述，我們並未淘汰 3PC，而是會在 Chrome 中推出全新體驗，讓使用者在瀏覽網頁時做出明智的選擇，並隨時調整選擇。我們正在與監管機構討論這項新做法，並會在推出前與業界展開合作。 |
| 使用者選擇 | 使用者的選擇公告影響了廣告產業採用 Privacy Sandbox 解決方案的意願。有很多人針對使用者選擇公告發表的意見，包括監控功能等功能的要求。 | 隨著更新方法提升使用者選擇權，開發人員仍須提供可強化隱私權的替代方案，以取代跨網站 ID。雖然我們尚未能提供新體驗的詳細資訊，但我們預期 Chrome 中的無 Cookie 流量將大幅增加。也就是說，Privacy Sandbox API 對企業仍至關重要。我們將持續投資 Privacy Sandbox 技術，進一步加強隱私保護與實用性。 |
| 使用者選擇 UI | 關於選擇不採用/同意功能的時程表、要考慮的使用者選項類型，以及 UI 對自動測試環境的影響。 | 我們目前沒有任何進度更新資訊可提供。我們決定不推行 3PCD 平台後，希望盡快通知 YouTube 生態系統的相關事宜。我們會在有最新消息時，立即分享使用者選擇的時間表。 |
| Chrome 測試 | 要求 Chrome 協助測試標籤持續提供，以便評估 3PCD 在 2024 年第 2 季後的市場採用率和經濟效益。 | 我們瞭解測試人員會繼續使用已加上標籤的瀏覽器群組進行測試與協調，即使 2024 年上半年採用 Chrome 輔助的測試已結束。我們正在評估標籤的後續處理方式，並參考使用者選擇公告。在此同時，Chrome 團隊已發布意圖延長支援標記瀏覽器群組，這項支援將持續到 2025 年 1 月，並在 Chrome 里程碑 132 中實施。 |
| Android 版 Privacy Sandbox | Android 版 Privacy Sandbox 和 Chrome 版 Privacy Sandbox 之間絕對連結，在沒有 Android 版本的情況下，我們無法正確評估 Privacy Sandbox。典型的客戶歷程包含跨裝置和多觸點層面，對 Chrome 和 Android 版 Privacy Sandbox 都至關重要。 | 請注意，Android 版 Privacy Sandbox 不屬於 Google 對 CMA 的承諾範圍。 如果意見回饋與 Android 時間軸和推出時程相關，我們會持續提升 Android 裝置的服務品質，目前我們不會再提供其他最新資訊。Google 將視為可改善隱私的獨立工作流程。 如先前所述，Android 版 Privacy Sandbox API 的使用率也會影響 API 的供應情形，而這並非 Google 所能控制。 |
| 模式 B：流量受限 | 透過模式 B 取得的廣告競價流量低於預期。 | 有許多原因可能導致 Protected Audience API (PA API) 的競價量低於預期，例如： - 我們已知已完成整合 PA API 的公司只有橫幅廣告格式。 - 賣方平台不一定會啟動競價。 - 瀏覽器可能沒有興趣群組 (IG)。 - 沒有任何出價。 不過，我們並未發現有人嘗試測試 PA API 卻沒有收到任何流量。 |
| 停機狀況可見度 | 瞭解影響 Privacy Sandbox API 的異常中斷和問題。 | 針對在瀏覽器外提供服務的 Privacy Sandbox API，我們設有 公開狀態頁面。 Chrome 團隊會將平台的可靠性，以及網路上主要網站和服務使用的所有重要 API (包括 Privacy Sandbox 技術) 列為最高優先事項。目前只有一次服務中斷。這與測試時 1% 的暫時性設定有關。我們很快就會停止使用這次服務中斷事件中涉及的實驗性設定，因此只要在 Chrome 中以正常方式啟用 API，就不會再發生這個問題。 |
| Cookie 圖形研究 | 在 Privacy Sandbox 架構中，Chrome 對 這篇論文中所述 CookieGraph 方法有何看法？ | 這份報告提出了一些有趣的觀點，探討由使用者造訪網域以外的網域設定的第一方 (1P) Cookie 的偵測和普遍性。正如這份報告所指出，這些 Cookie 對於收集使用者與網站互動方式的數據分析和資訊非常有用。開發人員可根據這類資料為使用者提供更優質的瀏覽體驗， 這份論文的主要論點有缺陷，因為它將第一方 Cookie 視為跨網站追蹤向量。不過，這項結論只適用於論文中所述的極端假設：
請注意，這些是可在未使用第一方 Cookie 的情況下 (例如透過伺服器端資料分享) 進行重新識別的向量，因此需要與我們目前的努力分開處理，因為我們目前的努力著重於以狀態為準的追蹤機制，例如第三方 Cookie。 最後我們想強調，這份白皮書將數據分析和廣告 Cookie 設為追蹤 Cookie 和強制使用 Cookie 的必要 Cookie，但這不一定是非追蹤 Cookie。事實上，第一方分析或劃分至網站的廠商服務 (例如商店定位小工具、即時通訊小工具或負載平衡器 Cookie) 通常只會限於一個網域，反之，為了防詐，某些絕對必要的 Cookie 可能會進行跨網站追蹤。 |
| 使用者體驗變更 | Chrome 第 112 版的使用者體驗經過調整，如果將第一方 Cookie 控制項放在 Chrome 設定的「裝置端網站資料」部分，使用者可能更難封鎖所有 Cookie。 | 這項異動是為了將 3PC (或未分割的儲存空間) 的控制項與所有其他類型的網站資料分開，並提升其優先順序。3PC 控制項會顯示在「隱私權和安全性」面板下方；而第一方 Cookie 和所有其他類型的網站資料 (通常是網站重要功能所依賴的資料) 的控制項則會在「裝置端網站資料」下方顯示。我們將持續監控這個主題的相關意見，但相信目前的區隔功能可在重要的隱私權控制項可偵測性和正常運作的瀏覽體驗之間取得良好平衡。 |
| 帳單與付款 | 由於測試人員將更多心力投入 Privacy Sandbox API 的其他部分測試，因此無法全面測試結帳和付款功能。 | 開發人員和公司可以自行選擇測試的時間和內容。自 2023 年 9 月起，這些 API 已開放測試。 |
| 測試 | 並非所有需求端平台從供應方平台收到的實驗流量都會標示。部分 DSP 提交的資料指出，實驗組和控制組的未標示實驗曝光次數比例可能不同。 | Chrome 無法控制公司是否會在出價請求中轉寄標籤。我們提供從瀏覽器取得標籤的方法，如果合作夥伴無法直接讀取這些標籤，則由生態系統將標籤傳遞給合作夥伴。 |
| Android WebView 上的 3PCD | 請提供指南，說明如何在 Android WebView 中啟用「Test Third Party Cookie Phaseout」標記，以便測試淘汰作業。 | 根據預設，Android WebView 會封鎖第三方電腦。 |
| 差異化隱私可降低模型訓練風險 | 為什麼要在模型訓練中使用差異化隱私？ | 在模型訓練過程中，差異化隱私搭配受信任的執行環境 (TEE) 是必要做法，有助於防止資料外洩，以及保護機密資訊免受威脅的影響。這麼做可確保模型權重不會洩漏個別使用者資料。 |
註冊與認證
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 註冊 | 要求進一步說明認證註冊在註冊來源與廣告技術來源 (含有 www 子網域) 之間的運作方式。 | 廣告技術只需要在 https://example.com 上完成新手上路程序。當他們將認證放入 https://example.com/.well-known/privacy-sandbox-attestations.json 時，https://www.example.com 就會受到保護，因為它是子網域。 |
| API 規格 | 建議在存放區中新增認證檔案的 JSON 結構定義。 | 我們正在評估這項建議，歡迎在這個頁面提供更多意見。 |
顯示相關內容和廣告
主題
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 主題加權 | 在「主題」中，最重要的是瞭解特定信號的稀有程度。目前的設計應進行調整，以便在每個觀察主題旁邊新增權重值。權重是指與使用該主題的所有瀏覽器相比，瀏覽器指定主題的相對權重。 | 我們想進一步瞭解信號的稀有性為何是最重要的信號。歡迎生態系統提供更多意見，讓我們瞭解這個用途的實用性，詳情請參閱這個頁面。 |
| 主題可靠性 | Google 需要提供更強的保證，確保「主題」功能隨時間推移的可靠性。 | 我們會持續根據生態系統意見回饋調整 API，並在變更前公開討論。我們提議修改後的管理架構，提供額外的保障。 |
| 分類器 | 發布商的網站經常被錯誤分類，或是指派的「主題」過於概略，無法發揮任何實質作用。 | 如這篇文章所述，我們會結合人工編輯的覆寫清單 (包含最熱門的網站) 和裝置端機器學習模型，為網站進行分類。Chrome 會持續評估網站提供主題分類的選項，任何實用性改善措施都必須權衡隱私權和濫用風險。 舉例來說，其中一些風險包括： - 網站使用自訂標籤，將不同的 (可能敏感的) 意思編碼為主題；以及 - 網站攻擊主題，以降低主題對其他人的實用性 (例如，以無意義的垃圾內容攻擊使用者的主題)。 所有人都能透過 chrome://topics-internals 或這個 Colab 提供的工具檢查這些元件。測試過程中，我們預期分類會隨著時間的進步，也歡迎您針對可能分類錯誤的網站提供意見。 |
| API 問題 | 擔心 Topics API 會為營利不當內容的 SSP 提供持續性和反競爭的優勢。 | 與 3PC 一樣，只要實體已註冊並通過認證，瀏覽器就不會理會要將 Topics 傳回給誰。 |
| (也在前幾季回報) 適用於 不同 利害關係人 |
由於主題分類器目前只會使用網頁主機名稱來定義對應的主題，因此含有多元內容的大型網站會提供一般主題，而小型網站則會提供較有廣告價值的專屬主題。 | 回覆內容與前幾季類似： 和第三方 Cookie 一樣，不同網站提供的資訊有其價值並不相同。興趣專屬網站的價值貢獻不一致：並非所有興趣專屬網站都有商業價值的內容，因此價值貢獻較低。以下是可從 Topics API 中獲益的網站。我們曾考慮以網頁層級而非網站層級進行分類，但這類分類會帶來許多隱私和安全疑慮。 |
| 分類器 | 較小的網站經常會被指派不正確的分類，或根本沒有分類，因此無法參與價值交換。 | 由於網站可能一直有誤導之虞，凡是可能誤遭分類的網站，都不會因此而受到其他損害，因為該網站的內容比對資訊永遠都會在該網站參與競價，因此就算分類錯誤，網站也能提供與正確的主題相當的資訊。主題一般用於從外部網站 (而非自家網站) 收集可能實用的廣告資訊。 |
| 分類版本 | 我們該如何存取分類版本，以確保回溯相容性？ | 分類版本是透過啟用主題的擷取要求傳送的一部分要求標頭。 舉例來說，如果標頭為「(1 2);v=chrome.1:2:5, ();p=P000000000」，則版本為 chrome.1:1:2。其中 chrome.1 是設定版本，2 是分類版本，5 是模型版本。 這項資訊已在規格說明文件中說明，並新增至說明文件。 |
| 主題資料 | 要求說明如何更新主題資料。 | 未指定分類更新。這可讓瀏覽器供應商在實作時更具彈性。 話雖如此，以下是 Chrome 從 V1 到 V2 的類別更新的推論法： - 為 V1 和 V2 的主題維護單一類別樹狀結構。 - 相同的主題 ID 代表相同的意思。 - 樹狀圖只會擴大，新增新主題或連結，不會縮小。 - 不過，某些主題或連結可能會在版本中處於「停用」狀態，讓人誤以為已刪除或重新排序。 範例： - 「Pickup Trucks」現在有「Trucks, Vans & SUVs」做為中間父項。 - 「Foreign Language Study」現在設有「Education」做為第二個父項，而原始父項「Reference」則會變為非活動狀態。 「已停用」主題的影響：系統不會使用這些主題進行新分類。不過，在強制執行使用者封鎖功能時，系統仍會考量這些主題：如果使用者在 V1 中封鎖某個主題，則該主題的子主題仍會在 V2 中遭到封鎖 (即使子主題在 V2 中顯示為其他父主題的子主題)。 |
| 分類器 | 想瞭解錯誤分類的可能原因，以及可用的修正選項。 | 首先，我們想指出，Chrome 判斷網站主題的結果僅用於輸入至 Topics 演算法，以便判斷使用者的興趣喜好，用於廣告用途。並非用於其他更廣泛的分類目的。 我們想瞭解分類模型的整體準確度，並盡可能提高精確度/喚回度，但請將全域層級而非個別網站分類層級加以調整。這是因為分類錯誤發生時，並不會對分類錯誤的網站造成影響，而會降低 Topics 信號的品質，因此從其他網站上挑選廣告。選擇歸類錯誤的網站廣告時，該網站早已知道真正的主題，可用來輸入廣告查詢。 歡迎在這裡提供更多意見回饋。 |
| API 測試 | Topics 和 Privacy Sandbox API 通常都能透過 Chromium 進行測試嗎？ | Chromium 無法與 Chromium 一併提供 Topics API，而是 Chrome 隨附的 API。 |
| 主題來電者 | 要求廣告技術利用 TEE 服務提升主題的附加價值，以符合隱私權規範的方式支援進階分析的成本。 | 我們已在這裡回覆類似意見。我們考慮了反向頻率，最終在模擬反向頻率後，發現根據買方和賣方提供的價值，反向頻率與主題價值並無太大關聯。 歡迎在這裡提供更多意見回饋。 |
| API 規格 | 瀏覽器興趣相似群組設定會封鎖 Topics API 嗎？ | 我們已在這裡回覆這項意見回饋。 Topics API 是屬於 FLoC 的革新，因此遵循 FLoC 的權限政策。如說明文件所述：「注意：FLoC 的舊版 Permissions-Policy: interest-cohort=() 也會禁止主題計算。」 |
| 主題排名 | 取得「前 5 個主題」時，我們會根據每個符合資格的呼叫端計算網站造訪頻率，還是一律根據瀏覽器的整個造訪記錄計算？此外，是否會為每個呼叫端進一步對主題進行排名？ | 這項數據是根據部分瀏覽記錄的頻率計算而得。只有在網頁至少有一個主題呼叫端的情況下，瀏覽記錄項目 (網頁) 才符合參與資格。如要進一步瞭解主題記錄儲存空間，請參閱這篇文章。 如這篇文章所述，Topics API 的排名會根據頻率和二元優先順序等級而定 (詳情請參閱這篇文章和這篇文章)。不過，這項指標不受通話者的頻率影響。請注意，這並不表示所有呼叫端都能在下一個 Epoch 時間取得所有前 5 大主題。如說明所述，「如要接收特定主題，呼叫端必須在過去 3 週內，針對與該主題相關聯的網站觀察使用者造訪情形。」瀏覽器確實需要追蹤哪個呼叫端觀察到哪些前 5 大主題 (對應於規格中的前 5 大主題與呼叫端網域)。 歡迎您前往這個頁面，針對這個問題提供更多意見。 |
Protected Audience API (舊稱 FLEDGE)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| (也列於先前幾季) 費用 |
在公用雲端執行 TEE 的費用是否比在自家廣告技術資料中心執行更高？ | 我們目前的 TEE 安全性模型受益於公有雲導入做法的優勢 (詳情請參閱公有雲 TEE 規定說明)。舉例來說，目前的硬體式 TEE 無法防範所有實體攻擊。我們現有支援的公有雲供應商 AWS 和 GCP，設計和實施緩解措施，防範員工等實體存取風險。 雖然部分廣告技術公司已提及，相較於地端部署的廣告技術資料中心，採用雲端服務的費用較高，其他廣告技術則是在公有雲上運作，例如成本或其他優勢。 我們會持續評估擴大 TEE 支援的選項，包括公有雲以外的選項。為此，我們正在研究內部部署的資料中心，並與生態系統合作，探索提供這類支援的潛在解決方案。在目前的研究階段，我們無法保證這項做法能為生態系統帶來可行的解決方案。 |
| PA API 和 Google Ad Manager (GAM) | GAM 無法達成公平的市場結果。GAM 無法及時放送廣告、回報使用 PA API 放送的廣告數量，且無法提供可設定的廣告放送方法，例如為特定版位關閉 PA API。 | Google Ad Manager 回覆： GAM 一直致力於透過 PA API 放送廣告時，改善延遲情況，讓 PA API 需求帶來的額外發布商收益，高於因 PA API 競價延遲而產生的費用。根據初步測試，發布商不必使用第三方 Cookie，就能透過 PA API 獲得流量淨收益。換句話說，由 PA API 額外需求獲得的收益，高於因延遲而產生的費用。如要進一步瞭解我們的做法，請參閱常見問題。 此外，GAM 也會針對透過 PA API 放送的廣告提供報表。這包括 GAM 做為元件賣家時放送的廣告，以及 GAM 做為頂層賣家時透過其他元件賣家放送的廣告。如要進一步瞭解檢舉功能，請前往說明中心。 最後，GAM 允許發布商透過 UI 內控制項，在其流量中啟用或停用 PA API 的使用 (詳情請參閱說明中心)。我們會考慮發布商可能希望進一步控管的意見回饋，並根據標準功能優先順序程序，優先處理任何功能要求。 |
| PA API 和 GAM/AdX | 據我們觀察，Google 似乎已決定，只要 GAM 未做出最終銷售決策，就不會購買任何 PA API 曝光，就像 AdWords 只購買自家廣告空間一樣。這似乎只是濫用市場立場的行為，因為 GAM/AdX 可以提交元件競價設定給其他頂層賣方，就像任何其他廣告交易平台一樣。 | Google Ads 平台管理員回應： 這不是 Google 的立場。Google 的買方平台 (Google Ads 和 DV360) 會從非 Google 廣告交易平台購買曝光。這項規定適用於 PA API 曝光次數和非 PA API 曝光次數。 |
| 市場回應 | Mozilla 的疑慮： Google 的 Protected Audience 功能更偏向保護廣告客戶 (和 Google)，而非使用者。 | 我們感謝 Mozilla 的評估，並會持續在公開標準論壇中與 Mozilla 互動，瞭解他們的意見回饋。這項評估的一大重點是，PA API 目前的實作方式尚未強制執行所有預定的保護措施。我們透過 PA API 的市場行銷策略，希望在鼓勵採用與盡快實施隱私權保護措施之間取得平衡。為此，我們陸續制定了持續實施隱私權限制的藍圖，希望未來能更有效地整合 API，並給予我們時間來收集更多意見回饋，以利日後用於相關保護措施 (例如圍欄頁框中的 VAST 功能)。 此外，我們也歡迎 Mozilla 近期的內容，當中說明其隱私權和數位廣告策略的內容：「免費開放的網際網路不應犧牲隱私權」和「透過產品和基礎架構改善線上廣告」。 |
| (也在前幾季記錄) 競價結果 |
要求單一競價返回多個轉譯網址及其對應分數，以便原生廣告輕鬆去重，避免使用者體驗和延遲問題。 | 我們的回應與前幾季類似： 我們考慮在單一 PA API 競價中分享多個顯示網址及其各自的分數，但有鑑於隱私權考量，我們並未採行這些措施。 我們深知您是否希望避免在一個網頁上，向使用者多次顯示同一則廣告，並正在評估這項要求。歡迎生態系統提供更多意見回饋，讓我們瞭解 PA API 需要哪些額外支援，以便最佳化原生廣告用途。 |
| 成效 | 關於延遲時間影響 PA API 的疑慮。 | 我們瞭解延遲時間的問題，因此開發了許多 PA API 功能，讓 SSP 可以設定 DSP 延遲時間限制，並改善延遲時間。我們最近更新了 延遲最佳做法指南，其中包含更多資訊，說明如何充分利用這些功能。我們也會持續開發新的延遲時間改善措施，如 這篇文章所述。 |
| 頂層賣家 | Google 應讓發布商選擇其他頂層 PA API 競價賣方。 | 無論是單一賣家或多重賣家設計，PA API 都不會影響誰發起競價。個別公司可自行決定是否支援 PA API 競價，以及支援的方式。 |
| (也在前幾季記錄) 排除指定目標 |
針對廣告主不想向特定目標對象放送廣告的用途，提出解決方案。 | 我們透過額外 (內容) 出價支援 IG 排除指定目標，解決廣告客戶不想向特定目標對象放送廣告的需求。 詳情請參閱這篇說明文件和這個 GitHub 問題。 我們也正在研究解決方案，以便在 PA API 出價時支援 IG 排除指定目標，歡迎您前往這裡提供更多意見回饋。 |
| (也列於先前幾季的報表中) 原生廣告 |
要求為原生廣告提供 Fenced Frame 支援。 | 我們正在考慮支援這個用途，並在 這個頁面討論可能的因應措施和解決方案。 |
| WebView | 請說明在 Chrome 中加入的 IG 無法在 WebView 上執行的競價情況。 | 在隱私權基礎架構充足的情況下，我們希望能夠支援這些使用情境。我們目前沒有其他公告，但歡迎您 在這裡提供更多意見回饋。 |
| 排除 IG | 要求更新網址處理程序，透過新興的標頭功能支援負面 IG。 | 我們正在評估這項要求，也歡迎您在這裡提供更多意見。 |
| 多元性篩選 | 請教如何在 PA API 中透過多個賣方和多個競價執行原生廣告時，實作多元篩選功能。 | 我們正在 這裡討論這項要求，也歡迎您提供更多意見。 |
| (也在前幾季記錄) 封鎖篩選器 |
要求取得指引，說明透過多重賣方在付費 API 中執行原生廣告時，如何強制執行「發布商封鎖」(篩選器) 規則。 | 我們已在 這裡提供指南，也歡迎您提供更多意見。 |
| 限制 | 要求在網域層級 (而非子網域層級) 限制。 | 子網域或來源層級的限制會遵循網際網路的基本安全性模型，這是我們的預設設計。 我們已在這裡和這裡詳細討論這項功能。 |
| 信任出價 | 在信任的出價信號要求中，要求使用者代理程式和相關用戶端提示。 | 我們會追蹤這項功能的要求，歡迎 按這裡提供其他意見回饋。 |
| (也在前幾季回報) 多個 IG |
在同一出價中使用多個 IG。 | 目前 PA API 不支援這項功能，因為這會導致基礎隱私權模型發生變更。 歡迎 按這裡進一步討論。 |
| (也已在前幾季回報) 成效 |
將更多邏輯移至用戶端可能會影響網頁效能和使用者體驗，進而影響網站的 SEO 分數。 | 我們會討論此問題，也歡迎你提供其他意見回饋。 |
| 競價情況多變 | PA API 會減少競價機制相關資訊 (例如參與競價的對象、各個競價項目的得標者等)，因此發布商難以追蹤，也難以得知是否保留了交易。 | 我們在這篇文章中提出了追蹤交易的解決方案。我們打算修改部分現有欄位，並在 IG 物件內建立一些新欄位來儲存 DealID 和 SeatID，並在產生出價時從 generateBid 和 scoreAd 中套用，或是透過事件層級報表套用。這應該能充分支援交易的用途。 歡迎您提供意見，告訴我們廣告技術人員認為對競價動態至關重要，以及能讓發布商保有這種可追溯性的其他中繼資料。我們鼓勵廣告技術人員提供具體範例，說明他們所指的中繼資料，以及中繼資料需要從哪一方流向哪一方。 |
| GAM | 關於必須使用 GAM 做為發布商廣告伺服器，才能存取 AdX 需求的疑慮。 | Google Ad Manager 提供的回應： GAM 並未要求發布商使用其廣告伺服器功能，才能存取廣告交易平台功能。 |
| (也曾在前幾季回報) 元件競價 |
GAM 將查看 PA API 元件競價得標者，引發他們對資訊取得不平等的疑慮。 | 我們的回應與先前幾季相同： Google Ad Manager 提供的回應： 「我們多年來一直非常重視競價公平性，包括承諾不會在其他買方出價競價前，將任何發布商的無保證廣告來源 (包括無保證委刊項價格) 的價格提供給對方。我們後來在向法國競爭局承諾時，也再次重申這項承諾。 針對 PA API 競價，在多重賣方競價結束競價前，我們會履行承諾，不向其他競價參與者透露出價。在此說明，我們不會將內容相關競價的價格提供給任何競價元件，包括我們自己的競價元件，如這篇更新文章所述。 此外，我們不會將元件競價設定 (包括買方提供給 SSP 的信號) 用於自家競價。事實上，我們很歡迎變更 PA API，讓元件賣方用頂層賣方混淆的方式指定元件競價設定。」 |
| GAM | 如果 GAM 未參與 IG 或 PA API 元件競價的建立，是否會針對頂層競價的執行/報表要求收益分潤？ | Google Ad Manager 提供的回覆： 發布商選擇使用 GAM 做為廣告伺服器時，GAM 會執行頂層競價，並針對其廣告伺服器功能收取廣告放送費 (與 PA API 競價以外適用的廣告放送費相同)。 不過，如果得標廣告來自非 GAM 元件賣家 (也就是說，GAM 並未參與 IG 或 PA API 元件競價的建立)，GAM 就不會處理帳單，也不會收取百分比媒體費。 |
| 點擊 | 點擊事件的註冊作業是否也受到差異化隱私權的規範？ | 目前這項功能並未受到「k-anon」限制，因為「點擊次數」只會以 generateBid() 函式中的 browserSignal 形式提供，不會在事件層級報表中以新屬性形式提供。 |
| 成效 | 由於對內容相關出價要求無條件回應，導致輸出費用偏高。 | 基於隱私權考量，我們無法直接提供哪些 DSP 有 IG 的資訊。不過，我們正在研究其他解決方案，希望能同時提供洞察資料和保護隱私權。 |
| 原生廣告和串流外廣告 | 要求取得 Chrome 對原生和串流外廣告相關觀點的最新消息。 | Chrome 的實際位置取決於相關用途。 就影片而言，Chrome 的立場是鼓勵生態系統使用我們的 API，匯集可行的內嵌影片解決方案。目前我們所知的唯一具體提案是 GAM 的提案。 針對原生廣告，我們正在積極收集意見回饋，並計劃盡快與廣告技術人員合作，提供更多探索步驟。 |
| 即時監控 (RTM) | 已標記的流量不會傳送 RTM 報表。 | 我們已注意到這個差距，並正在設法提供解決方案。 如有最新消息，我們會按這裡發布。 |
| 目標對象額外資訊支援 | 請更新 PA API 中目標對象擴充資料/賣家策劃的目標對象支援情形。 | 我們正在努力為這個用途提供解決方案。我們正在收集生態系統的意見回饋，瞭解我們應建構及支援哪些內容。 我們會在第一時間提供最新資訊，歡迎按這裡查看其他意見回饋。 |
| 偵錯 | Chrome 的開發人員工具中沒有面板可監控 PA API 的詳細效能。舉例來說，IG 數量或買家數量可能會影響整體成效。 | 雖然這項特定意見回饋與 Chrome 開發人員工具 UI 中的監控功能相關，不過我們在 10 月 7 日推出了廣告技術設定自訂事件的功能，可用於監控及傳送快訊。如需更多詳細資訊，請參閱這篇文章。我們希望這次更新能解決這項意見回饋的大部分問題。 歡迎您在 GitHub 的相關討論區 這裡，針對這項功能提供任何意見回饋，無論是與支援的資料點相關，還是開發人員體驗。 |
| 信號 | 擔心 DSP 是否能確保 perBuyerSignals 會傳送至 SSP，不受內容相關競價結果影響。 | 系統假設內容相關競價只從一個 DSP 贏得一個得標出價，也就是僅計算一次出價，嘗試贏得後續的私下競價 API 競價。對於 PA API 流程，SSP 會決定邀請所有需求端平台，看看他們是否有需求 (以裝置端 IG 的形式) 要提交。失去內容相關競價的 DSP 很可能會「重新獲邀」參與 PA API 競價。在這個「重新邀請」程序中，如果需求端平台決定接受，就會將廣告驗證工具希望確保需求端平台考量的任何信號 (如果有) 轉寄給賣方平台。 換句話說，無論內容輔助廣告競價發生什麼事，需求端平台一律都能向供應方平台提交 perBuyerSignal。 |
| 信號 | 要求將 prevClicks 新增至傳遞至 generatedBid() 的 browserSignals 物件。 |
我們提出的提案可支援點擊率信號，因此可以解決這項要求。我們在最近的網誌文章和相關說明文章中宣布這項功能。 歡迎在這個頁面提供對這項提案的其他意見。 |
| (也曾在先前的季度中回報) 模擬信號 |
要求將模擬信號位元從 12 位元提高至 30 位元。 | 我們已透過這裡提交回復通知來回應這份意見回饋。我們正積極與業界互動，瞭解他們對這項提案的看法，並評估這項提案對業界的益處，以及對 Chrome 使用者和其他利害關係人的影響。 |
| 說明文件 | 請教如何使用鍵/值 (K/V) 伺服器和 TEE。 | 如要瞭解如何在 K/V 情境中使用 TEE，請參閱這篇文章，瞭解 K/V 服務信任模式設計的詳細資訊。 |
| 排除 IG 的生命週期 | 要求將 IG 排除條件有效期限延長至 365 天。 | 負面 IG 可用於避免顯示廣告，但惡意人士仍可利用這類廣告揭露使用者資訊，導致重新識別風險 (例如，惡意人士可透過重複設定高出價的負面 IG，瞭解使用者是否曾造訪特定網站)。 如果將存留時間設為 365 天，惡意行為人就會有更多關於排除 IG 的資料，而這些資料帶來極為嚴重的隱私權風險。 為保護使用者隱私，我們無法支援這項要求。 |
| API 規格 | 可以插入哪些值做為 PerBuyerSignals 的一部分？賣家可以自行決定嗎？ | 賣方可透過 perBuyerSignals 向買方提供他們想在競價中提供的任何資訊。 生態系統會決定要插入哪些內容，但我們歡迎您在這裡進一步討論。 |
| 廣告大小巨集替換 | 無法替換廣告大小巨集的替換指南。 | 我們會盡快公開更多詳細資訊。 |
| 出價賣方平台巨集替換：假冒頂層網址 | Chrome 可以透過哪些機制讓驗證服務供應商驗證 Privacy Sandbox 架構中的頂層網址？ 是否有其他資料點或信號可用於 Fenced Frame，以確保賣方平台提供的頂層網址正確無誤？ |
如有其他歡迎意見，歡迎點選這裡討論。 |
| 功能建議 | 要求針對 updateURL 擷取作業和即時報表回傳提供低熵的 UACH。 | 這些要求仍在這裡參與討論。歡迎按這裡和這個頁面提出其他意見回饋。 |
| 功能建議 | 要求在特定用戶端觸發時，透過 forDebuggingOnly.reportAdAuctionWin() 和 forDebuggingOnly.reportAdAuctionLoss() 傳送經過降樣處理的「for DebuggingOnly」事件層級報表時，啟用信任的伺服器同意的偵錯設計。 |
這是我們目前正在追蹤的有效要求，有可用的更新時，我們會提供給生態系統。歡迎前往這個頁面提供更多意見。 |
| API 使用方法 | 尋求有關如何計算不重複使用者觸及數和曝光觸及數的指引。 | 我們正在討論一項提案，說明如何從共用儲存空間工作區讀取 IG，以便您傳送私人匯總報表。 想進一步瞭解詳情，請參閱這裡的內容。歡迎查看提案意見回饋，瞭解這項提案的實用度，以及對整個生態系統的實用性。 |
| API 使用方法 | 發布商應測試的項目、哪些 API 重要、應啟用哪些 API，以及未來的發展方向不夠明確。 | 我們持續努力為發布商及其角色提供更完善的支援。 |
| API 使用方法 | 是否可以為廣告競價工作區事件新增事件監聽器？ | 這在一般事件中是不可能的，但 Chrome 開發人員工具通訊協定事件可部分解決這個用途。 請注意，一般事件可能會影響隔離/隱私權屬性，但詳情請參閱這篇文章。 |
| K-匿名性 | 尋求廣告算繪規定的說明 (例如，如果系統允許顯示廣告，至少有 50 位使用者會看到廣告)。 | 開發人員說明文件概述了我們對未來開發作業的期望。特別說明初始 k-anonymity 門檻為 k=10 人。 blink-dev 電子報會提供 Chrome 即時運作情況的最新消息。 如k 匿名性電子郵件討論串所述，我們目前正在實驗，針對約 1% 的 Chrome 穩定流量強制執行 k 匿名性規定，但不會對明確標示的「模式 A」和「模式 B」切片強制執行。 |
| 混亂 | 是否可以暫時移除或減少 TEE K/V 的斷層，或減少必須呼叫所有 N 資料分割，或是達到平衡隱私保護與實用性 (即K/V 效能/成本)？ | 這類要求只會處理在可控管 chaffing 的非正式環境執行個體中。正式環境執行個體仍需要進行遮蔽。我們會在收到非正式環境使用者的意見回饋後，評估情況。 |
| 混亂 | 要求新增旗標，以停用偵錯/非實際工作環境 K/V 二進位檔的終止功能。 | 這個標記會隨 1.0.0 版本提供。 |
| API 錯誤 | 即使在設定中啟用該 API，API 在升級至 Chrome 126 後已停止運作。 | 我們發現這項問題與「enable-fenced-frames」Chrome 旗標有關，使用者為了開發目的而啟用這項旗標。將此旗標重設為預設值即可解決問題。 |
| 報表 | 要求讓買家可以選擇啟用即時回報 API，而非依賣家而定。 | 我們已將這項要求視為這個頁面。 RTM 解決方案最近發布，我們特別歡迎您針對已導入這項功能的廣告技術提供意見。 |
| 報表 | 要求第三方回報，因為雖然 DSP 和 SSP 會收到 Chrome 的曝光通知，但中介層技術供應商根據預設不會收到。 | 我們也會討論這項要求，歡迎按這裡提供意見。 |
受保護的競價服務
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| TEEs | Google 要求使用技術標準手動完成新手上路程序，這項規定嚴重限制了雲端供應商的選擇。我們可以遵循適用的技術標準，而無須前往 Google 所提及的雲端服務供應商局。其他供應商最晚在 2025 年 (最早) 才推出這項功能，這點我們無法接受，因為這會引發網路效應，鼓勵使用者使用 Google 的解決方案。 | 匯總服務是唯一需要在 TEE 服務中執行的服務，可用於處理某些廣告技術用途。匯總服務同時支援 Amazon Web Services (AWS) 和 Google Cloud Platform (GCP)。根據廣告技術人員的意見回饋，我們認為現階段這類支援服務足以派上用場。 其他雲端服務供應商：Google 已發布詳細的公有雲端服務供應商 TEE 相關條件。這些規範旨在確保 TEE 解決方案符合 Privacy Sandbox 的隱私權和安全性目標。 具體來說，Privacy Sandbox TEE 伺服器會處理未加密的跨網站使用者資料 (例如匯總服務的發布商和廣告主網站資料)。這些 API 必須安全，才能符合使用者隱私權目標。同樣地，安全環境也是必要條件，可確保 API 持續保護公司的機密商業資訊 (例如，防止其他 PA API 競價參與者存取買家的專屬商業資料)。 據我們所知，目前沒有任何 TEE 技術可完全保護使用者資料，避免遭到潛在的對立運算單元攻擊。因此，我們會加入多項要求，驗證雲端服務供應商的可信度。 我們不確定「雲端服務供應商辦公室」指的是什麼，而且這並非規定的一部分。歡迎您針對這些規定提供寶貴意見。我們也持續評估新供應商的支援服務，包括根據說明文件中定義的程序提交的要求。目前我們只收到要求支援 Azure 的要求，我們正在評估中。 |
| 民宿 | 由於設計持續演進，因此很難評估 B&A 服務的技術複雜度和可行性。 | 為解決這些疑慮，我們已在 GitHub 上提供詳細說明，解釋 B&A 的設計、發布可用性的時間表，以及支援 PA API 的功能路線圖。我們會協助廣告技術人員部署 B&A，並在 GitHub 上收集生態系統的意見回饋。 |
| B&A | 想瞭解如何計算使用 TEE 進行 B&A 的成本，以便開始使用或從裝置端遷移至使用 TEE。 | 我們最近發布了 K/V 伺服器執行個體大小設定指南，其中包含可更準確評估成本的工具。 |
| K/V 伺服器 | 廣告驗證工具要求能夠使用完整網頁網址，向 K/V 伺服器執行廣告驗證。 | 我們目前正在評估是否有可能為廣告驗證目的，將完整網頁網址提供給在 TEE 中執行的 K/V 伺服器。K/V BYOS 中不會提供完整網頁網址。 |
| 競價安全性 | 尋求競價安全防護功能，確保不肖人士無法存取敏感資料或冒用他人身分 - 哪些功能可保護競價免於重播攻擊，以及如何實作安全防護措施？ | B&A 現有的安全性模型可以保護競價的完整性。B&A 在 TEE 中執行，可保護廣告技術信號和程式碼不受惡意行為人的機密性。 在 B&A 架構中，經過加密的 B&A 要求酬載 (要求密文) 會從用戶端經由不受信任的廣告伺服器流向 SellerFrontEnd 服務 (SFE，由 SSP 在 TEE 中執行)。要求密文包含以時間戳記為基礎的產生 ID。SFE 會檢查要求的時間戳記，並拒絕任何不在伺服器時間 +/- n 秒內的重播要求。此外，B&A 可針對伺服器對伺服器通訊傳回經填充的固定大小回應酬載。當惡意人士嘗試重新播放相同的要求承載來進一步瞭解其內容時，這些解決方案有助於透過系統緩解重播攻擊。 B&A 團隊正在撰寫說明文件，並更新安全性模型。 |
| 透過 的信號 K/V 伺服器 |
要求將透過 K/V 服務傳送的 perBuyerSignals 納入 Chrome 信任的出價信號要求。 | 我們正在評估是否能夠提供 PerBuyerSignals 資訊，並將這些資訊轉移至在 TEE 中執行的 K/V 伺服器，包括完整的網頁網址。 |
| K/V 伺服器 | 要求在 K/V 和 B&A 中，針對隱私權限制採取更分階段的時間表。 | 我們瞭解您希望採用 TKV 的做法更有階段性，並感謝您針對 K/V 和 B&A 提出具體要求。 不過，經過審慎評估後，我們決定目前不放寬這些 API 中的隱私權保護措施。我們認為，瓶頸等措施是保護使用者隱私，並維護 Privacy Sandbox 的信任度。 |
| K/V 伺服器 | 想瞭解如何透過相容的設定擴充 K/V 儲存空間。 | 如需相關協助，請參閱近期發布的 K/V 伺服器執行個體規模指南。這項工具會為每一個參數組合提供 QPS (詳情請參閱說明中的「RPS」)。 |
| K/V 伺服器 | 在 K/V 伺服器要求中新增賣方資訊。 | 我們正在討論這個問題，也歡迎您在這個頁面提供更多意見。 |
| K/V + B&A 服務 | 要求釐清 K/V 和 B&A 的發布時程或發展藍圖。 | 針對 K/V 和 B&A，我們有以下階段和時間表： 如果 K/V 伺服器與裝置端 PA API 競價 (而非 B&A)，公開時間表可在這裡查看。請參閱「藍圖」一節，瞭解 K/V 如何定義「正式發布版」的規定。 如要瞭解 B&A 的公開時程，請參閱這個頁面和這份藍圖中的藍圖。我們將「規模測試」定義為「完整穩定的實際工作環境規模測試」，如要瞭解這個階段的具體功能組合，請參閱這篇文章。 B&A 也包含 Alpha 和 Beta 階段，因此擴大測試會納入先前階段的超級集合功能。 針對 K/V 和 B&A，請告訴我們這些階段定義是否有助於釐清何時可使用哪些內容。如果仍然沒有缺口，請與我們聯絡。我們很樂意提供更詳細的資訊，協助您規劃行程。 |
評估數位廣告成效
歸因報表 (和其他 API)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 市場回應 | 要求競爭對手的歸因系統只能在嚴格限制的範圍內使用事件層級報表和摘要/匯總報表，這項規定對競爭對手來說是一種不合理的限制。即使已採取安全防護措施確保符合資料保護規定 (例如去識別化)，這項功能仍會禁止在事件層級進行即時裝置專屬再行銷和歸因。 | 上述設計是以 API 的隱私權目標為根據，例如保護從某網站傳遞至其他網站的跨網站資訊。舉例來說，ARA 支援透過事件報表進行事件層級歸因。事件報表會延遲至少一小時，以免使用者在廣告客戶網站上的身分難以透過時間側通道攻擊與事件層級報表建立關聯，詳情請參閱這篇文章。 除此之外，除了 ARA 以外，還有其他方法可以進行歸因，例如直接向某些使用者提供識別資訊。 如果 Privacy Sandbox API 目前的隱私權範圍無法滿足某些用途，歡迎針對這些使用情境提供意見。 |
| 多種表面 | 請確認 ARA 和 Shared Storage API 是否支援多層面用途，並提供相關證明。 | 目前 ARA 和共用儲存空間不支援多重途徑 (跨裝置) 歸因。支援在同一裝置上 (透過 ARA) 跨應用程式和網站歸因。 |
| (也列於前幾季報表) 跨裝置 |
ARA 是否支援跨裝置轉換？ | 我們的回應與先前幾季類似： 跨裝置功能除了 3PC 之外，還會帶來新的隱私權挑戰，而且由於使用者可能會使用各種裝置和平台，因此也會帶來技術分發方面的挑戰。我們正在研究可能的解決方案，但重點放在 ARA 目前支援的重要用途，但目前尚未提供跨裝置支援的時間表。 |
| 資源調度 | 擔心目前是否已設定 Attribution Report API (ARA)，且能否可靠地推出並擴大規模，以服務所有 Chrome 使用者。 | ARA 目前開放所有 Chrome 使用者使用，且可正常運作。此外，由於測試 ARA 的廣告技術公司數量持續增加，我們會持續測試及監控其可靠性和可擴充性。 歡迎您在這裡提供更多生態系統相關意見回饋。 |
| (也列於先前幾季) 去重 |
擔心 ARA 提出的裝置歸因機制限制，導致發布商無法有效執行摘要報表的歸因後邏輯，包括針對同一個廣告點擊重複計算多個相同類型的轉換。 | 我們的回應與先前幾季相同： 在 3PC 中，廣告技術人員也面臨跨裝置和評估管道的去重複問題，這是目前已知的挑戰。有了 ARA，廣告技術人員就能決定何時註冊特定轉換，並新增特定中繼資料，指出他們使用哪些評估管道追蹤轉換 (即匯總鍵的一部分)，以便與其他評估管道進行比較。 歡迎您在這裡提供更多生態系統相關意見回饋。 |
| 轉換追蹤 | 要求使用來自多個網域的轉換。 | 我們正在討論這項要求，也歡迎您提供其他生態系統意見回饋。 |
| 報表 | 瀏覽器會等待至少兩天，最多 30 天才會傳送轉換，這可能會造成疑慮，因為大多數的利害關係人廣告客戶都是成效廣告客戶，他們需要近乎即時的轉換資料。 | 事件層級報表的預設設定包含下列預設報表回溯期：2 天、7 天和 30 天。 彈性事件層級報表可讓廣告技術人員變更報表回溯期的數量和長度，不再受限於預設值。報表時間範圍可變更為最短 1 小時，這可能有助於成效廣告客戶的用途。 歡迎按這裡，針對生態系統提供其他意見。 |
| 線上到離線歸因 | 在 ARA 中，是否有任何導入線上到離線廣告的選項，或是有其他建議可用來評估離線到線上歸因？ | 目前沒有計畫在 ARA 中支援線上到離線的評估用途。這類支援需要考量重大的隱私權與安全性難題。 歡迎您針對這項支援功能的用途提供更多生態系統意見回饋，請前往這個頁面。 |
| 偵錯報表 | 如何在 Chrome (來源/觸發條件) 註冊 Chrome (來源/觸發條件) 的應用程式至網頁歸因程序中，儲存及擷取廣告 ID？ | 為啟用偵錯報表，廣告技術必須向我們證明他們已能跨應用程式和網站加入使用者，以確保偵錯報表不會揭露任何新資訊。廣告技術可以提供每位使用者專屬的彙整鍵，證明彙整作業。這個彙整鍵可以是 AdID，也可以是第一方合併鍵。如果廣告技術使用 AdID，Chrome 原生不支援透過瀏覽器存取 AdID，而且 API 會預期各項廣告技術在網站登錄期間使用自己的方法傳送 AdID。 |
| 值區精細程度 | 是否可以為每位廣告主使用不同的分桶策略？ | 建議您嘗試不同的捐款預算調整方法，找出最適合您用途的方法。ARA 的設計初衷是為了提供靈活性和可自訂性，以滿足各種廣告技術用途的需求。因此，建議您針對每位廣告主或每個產業嘗試不同的分類策略。如果廣告客戶想追蹤的評估值和評估值數量不同，採用不同的分組策略就很有幫助。 |
| 說明文件 | 索取額外的文件，瞭解如何實作 ARA 的應用程式<>網頁。 | 我們已在這裡發布應用程式 <>ARA 網頁版的說明文件。 |
| 成效 | 與維持連線要求數量相比，ARA 相關要求的數量可能會對發布商伺服器造成沉重負載，批次處理單一要求的來源事件有助於降低伺服器的負載。允許擷取 JSON 編碼物件的陣列 | 您可以使用 JavaScript 邏輯搭配 API，在一定程度上根據特定邏輯批次處理來源事件。我們目前正在評估這項要求，歡迎透過這個頁面提出其他寶貴意見。 |
| 功能建議 | 由於不支援伺服器對伺服器整合，因此建議採用替代方案。 | 我們目前不打算在 ARA 中實作伺服器對伺服器整合功能。如要支援伺服器對伺服器整合，我們需要進一步考量許多隱私權問題。 歡迎生態系統提供意見，讓我們瞭解伺服器對伺服器支援功能的其他用途。請點選這裡提供意見。 |
| 說明文件 | 請提供「快速入門」指南，說明 ARA 的關鍵部分/如何開始使用並執行幾個簡單的用途。 | 如需 ARA 快速入門指南，請參閱這篇文章。 我們今年會進一步改善這份說明文件，歡迎您在這裡提供更多意見，讓我們瞭解哪些特定用途或情境需要額外說明文件。 |
| API 使用方法 | 針對許多小值，要求提供有關放大貢獻值的建議。 | 建議您嘗試不同的捐款預算調整方法，找出最適合您用途的方法。在許多小值的情況下，建議您嘗試使用不同的 epsilon 值，找出可接受 epsilon 雜訊的轉折點，以便用於您的用途。 如需進一步瞭解詳情，請參閱我們關於ARA 摘要報表最佳化 的研究論文。 |
| 彈性事件層級 | 彈性事件層級 (多個觸發條件規格) 何時會實施？ | 目前，彈性事件層級支援自訂下列登錄設定：每個來源可產生的報表數量、報表回溯期間的數量和長度，以及觸發事件資料的基數。 我們目前正在收集有關彈性活動層級其他強化功能的額外生態系統意見回饋，但目前沒有任何實施計畫。 歡迎針對使用情境提供更多意見回饋，讓我們瞭解您可能從這裡列出的彈性事件層級強化功能中受益。 |
| 值區處理 | 要求考慮對值區的匯總貢獻上限，以及日後的擴充性和回溯相容性。 | 我們正在討論這項要求，歡迎您在這裡提供更多意見。 |
| Epsilon | ARA 變更為正式發布後，ε值範圍會發生什麼情況？ | ARA 已於 2023 年第 3 季正式發布 Chrome。目前沒有修改 Epsilon 值期的計畫。我們提出的治理架構修訂方案，可在任何修訂內容上提供額外保證。 |
| 報表 | 觸發事件報表不含來源屬性。 | 如規格中所述，trigger-unknown-error 的額外欄位無須在報告內文中顯示。我們發現，在報告內文中說明欄位的表格可能有誤導之虞，因為來源相關欄位不一定會顯示，取決於錯誤的根本原因。 舉例來說，在來源比對邏輯發生前，可能會發生內部錯誤，這表示沒有可用來源資料可用於填入偵錯報表。 說明文件現已更新，清楚說明這項資訊。 |
| API 使用方法 | 使用兩個評估目標 (計數和價值) 時，是否表示要將貢獻預算和 epsilon 一併分割？ | 如果您使用兩個評估目標，建議您將貢獻預算分攤給這兩個目標。 |
| 報表 | ARA 是否支援多觸點歸因或輔助報表 (又稱為貢獻報表)？ | ARA 目前不支援多接觸點歸因分析或輔助報表。我們目前沒有實施這項功能的計畫。 歡迎您在這個頁面提供更多意見，說明使用情境和優先順序。 |
| API 錯誤 | 對於 ARA，說明文件指出 XOR 是用於結合來源和觸發事件的匯總鍵片段，但實際上使用的是 OR。這會導致實作時產生混淆和潛在錯誤。 | 說明文件已更新，反映出這是錯誤。 |
匯總服務
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 匯總工作 | 要求允許在匯總工作中使用多個前置字串。 | 我們正在調查這項意見回饋，並已在這裡發布提案。歡迎前往這個頁面提供意見。 |
| 功能建議 | 要求變更 Terraform 指令碼，以便在未設定 service_account_token_creator_list (或為空白) 時，略過修改帳戶 IAM 政策的程序。 | 我們正在調查這個問題，也歡迎您提供其他生態系統意見回饋。 |
| API 使用方法 | 有關 Terraform 計畫持續顯示變更的必要說明。 | AgS 2.8 版本已修正這個問題。 |
| API 使用方法 | 尋找透過彈性貢獻篩選功能，針對個別廣告主設定匯總頻率設定的建議。 | 目前可使用 ARA 依廣告主批次處理廣告。當廣告技術人員想要進一步依頻率區隔報表的貢獻資料時，可使用彈性貢獻篩選功能處理更進階的情況。 廣告技術請參閱這篇文章，進一步瞭解如何批次處理資料，以及如何搭配 ARA 使用篩選 ID。請按這裡。我們也正在製作更多篩選 ID 的說明文件。 |
| 功能建議 | 要求支援匯總服務 (AgS) 中的「log_sum_exp」。 | 我們已與此利害關係人聯絡，以瞭解這項用途的詳細資訊。我們會在取得更多資訊後提供最新消息。 |
| 功能建議 | 要求在 AgS 發生問題，以及已部署的 AgS 可能發生問題時，能夠查看更多記錄/洞察資料/其他指標。 | 我們已在說明文件中發布更新內容，加入更多錯誤、緩解措施和說明，請按這裡。 歡迎針對未記錄或無法取得的錯誤/指標/記錄等，提供更多意見回饋，並指出 這裡有哪些詳細資料會有所幫助。 |
| API 測試 | 測試期間結束後，epsilon 的最終值為何？ | 目前沒有修改 Epsilon 值期的計畫。我們鼓勵測試人員嘗試不同的參數，並提供意見回饋。 |
| 報表 | 系統會產生報表，但仍會在傳回碼中收到 PRIVACY_BUDGET_AUTHORIZATION_ERROR。 | 我們已提供指引，說明如何指定正確的報表來源和可匯總的報表，以免發生這項錯誤。 歡迎您針對這個問題提供更多意見回饋，尤其是如果有重複發生的錯誤。 |
| 金鑰探索 | 索引鍵探索提案的計畫為何？ | 我們目前還沒有主要探索提案的推出時間表，但我們希望你能針對這個提案，請按這裡提供寶貴意見。 |
| 自訂 | 尋找可用於匯總服務的自訂選項。 | TEE 內無法自訂匯總服務，但 TEE 外的部分元件可以自訂。這是因為我們需要在 TEE 中維持隱私權和安全性標準。 我們正在更新說明文件，協助廣告技術人員瞭解架構，以及哪些元件可自訂。我們無法支援特定自訂功能，因此建議廣告技術盡可能使用標準設定。 |
| Spot 與隨選執行個體 | 系統是否已使用 Spot 執行個體與隨選執行個體來測試？除了潛在的暫時性無法使用之外，使用 Spot 執行個體還有任何具體缺點嗎？ | 我們並未優先測試點播式執行個體，因為我們建議廣告技術人員使用隨選執行個體。使用點數機時，工作可能會在預算用盡時中斷。如果預算已用盡，且工作在廣告技術人員收到摘要報表前中斷，廣告技術人員就無法重試工作，而必須申請預算復原。我們只建議在發生重大故障時使用預算復原功能，以保護隱私。 我們建議廣告技術設定自動調度資源功能，藉此將費用降至最低。選取 0 做為自動調度資源的值，表示在收到工作要求前，系統不會執行任何執行個體 (請注意，這可能會增加延遲時間，因為系統會在收到要求時啟動執行個體)。 |
| 已知錯誤和解決方案 | 針對顯示「服務錯誤」的匯總服務工作所需說明 | 這個問題已在這裡解決。 我們也更新了部分錯誤訊息，讓內容更具描述性。舉例來說，我們開始在 AWS 上拋出更明確的權限/授權錯誤，而非先前以內部錯誤呈現。 我們已在這裡更新錯誤代碼和因應步驟的說明文件，也歡迎您針對未記錄或提供的錯誤提供額外意見回饋，並瞭解哪些詳細資料可能有幫助。 這裡 |
私密匯總 API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 主要設計 | 要求私密匯總鍵設計指南 | 雖然我們沒有私人匯總功能的專屬指南，但匯總服務負載測試架構和進階金鑰管理指南都可以做為參考資源。 |
| 捐款預算 | 貢獻預算的計算和限制層級為何？ | 在 10 分鐘滾動式時間區間中，貢獻預算為 2^16，在 24 小時滾動式時間區間中則為 2^20。 |
限制隱密追蹤
使用者代理程式縮減/使用者代理程式用戶端提示
本季未收到任何意見回饋。
IP 保護 (原稱 Gnatcatcher)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 僅適用於搭載 Android | 計劃推出 Android 的 IP 保護服務嗎？ | 我們正在研究如何將反隱匿追蹤功能 (包括 IP 保護功能) 導入 Android，但目前尚未有正式的計畫可供分享。 |
| API 使用方法 | 想知道 IP 保護功能是否有或將有防詐例外狀況？ | 我們致力於在防止根據使用者的 IP 位址在網路上追蹤使用者，同時盡量降低正常伺服器作業中斷的情況，包括使用 IP 位址進行反濫用。雖然我們目前無法提供更多詳細資訊，但預計不久後就會提供，也期待繼續討論。 |
| 惡意行為人識別 | 擔心傳統安全防護措施無法有效防範惡意 IP 位址。 | IP Protection 不會代理第一方要求，因此我們認為大多數入侵偵測系統不會受到影響。我們預計日後會提供更多詳細資訊，說明如何針對無痕模式使用者解決防詐和網站中斷問題。 |
| IP 位址遮蓋 | 如果新聞發布者網站 (1P) 和廣告網站使用同一個網域 (3P)，是否會遮蓋兩者的 IP 位址？如果不是，如何區分這兩者？ | IP 保護目前提供以清單為基礎的方法，可識別哪些第三方流量通過 Proxy。不過，即使來源位於該清單中，如果在第一方內容中存取，也不會進行 Proxy。我們正在敲定相關細節，包括哪些特定第三方網域會優先處理，以及如何明確定義 IP 保護的第一方和第三方內容。 |
| IP 位址遮蓋 | 擔心 IP 保護措施，以及這類措施對防詐系統的影響。 | 第一方網站不會受到 IP 保護方案的影響，因此論壇等網站應可存取 IP 位址來解決爭議。我們預計日後會提供更多詳細資訊，以解決廣告詐欺問題。 |
| IP 位址遮蓋 | 受影響網域的 IP 是否遮蓋到標頭？ | 系統會根據使用者目前所在位置的 Proxy 前 IP 位址，將使用者指派至地理區域。詳情請參閱這裡。 |
跳轉追蹤因應措施
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| API 規格 | 需要說明 Chrome 在分頁關閉時，如何處理延長的導覽行為。 | 我們已在這裡解決這個問題，並按照規定更新規格。 |
| 導覽追蹤 | 討論追蹤緩解方法，包括使用有限數量的連結，以減少跨網站要求中的熵。 | 我們會繼續與其他瀏覽器供應商討論這個議題，也歡迎生態系統提供更多意見回饋和具體建議。 |
隱私預算
如 GitHub 說明和開發人員網站所述，Privacy Sandbox 提案不再積極
採用隱私預算。
強化跨網站隱私界線
相關網站集合 (舊稱第一方集合)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| (也已在先前季度回報) 相關網站集合 (RWS) 網域限制 | 要求提高 RWS 中關聯網域的上限 | 我們的回覆內容與前幾季類似： 目前我們不打算提高這個數值限制，這項限制是根據使用者隱私權考量、W3C 生態系統利益相關者提供的意見回饋，以及其他瀏覽器的類似實作方式 而制定。詳情請參閱我們的網誌文章 (1、2)。 建議您檢查需要跨網站 Cookie 存取權的使用情形超過數字限制的使用情形，並考慮依據我們的指引，瞭解身分用途、驗證嵌入和廣告用途。如果使用者工作階段與登入動作相連結，建議您使用 Federated Credential Management (FedCM) API，確保各項功能正常運作。 歡迎您針對其他可能需要的用途提供寶貴意見，歡迎按這裡提供意見。 |
| 跨網站 Cookie 處理 | 由子網域設定的跨網站 Cookie 不會在主網域的後續要求中傳送。即使有適當的 CORS 和憑證設定，這個問題仍持續發生。 | 我們在這裡提供指引，說明如何正確使用 requestStorageAccessFor API，並說明需要指定完整來源 (即包含子網域)，才能在後續擷取要求中傳送跨網站 Cookie。 |
| 使用者選擇 | 在使用者選擇功能推出後，請提供有關 RWS 使用 requestStorageAccessFor 的更多資訊，特別是目前允許存取 3PC 的隱含或明確使用者手勢，在新系統中如何運作。 | 我們預期在任何使用者選擇模式下，RWS 的行為 (即無論使用者是否選擇保留或限制第三方 Cookie) 都會與 Chrome 中允許第三方 Cookie 的現有/發布行為一致，而非啟用 RWS 時會封鎖第三方 Cookie (也就是「允許相關網站查看你在群組中的活動」設定)。 建議您先呼叫 hasStorageAccess，檢查嵌入項目是否已具備未區隔的跨網站 Cookie 存取權，再呼叫 requestStorageAccess。如果使用者選擇允許 3PC，hasStorageAccess 方法會傳回 true。如果允許 3PC，requestStorageAccessFor 目前不需要使用者手勢。 我們已開啟一個新的 GitHub 問題，討論並明確指出此情況應有的正確行為，也歡迎生態系統提供更多意見回饋。 |
| API 使用方法 | 不清楚將 RWS 用於「商業」用途的明確規定，妨礙採用。利害關係人表示有意將刊登內容分組，以便放送指定廣告。 | 回應式網頁設計的用途是支援網站的核心功能和核心使用者歷程。我們建議您在指定廣告相關用途中使用專用廣告 API。 |
| API 使用方法 | 回報 requestStorageAccess 的問題，指出該問題會設定 localStorage 資料，但不會設定 Cookie。 | 這個問題是因為 SameSite 屬性有錯字。請確認拼字正確，並明確將其設為 3PC 的 None。 |
| API 規格 | 檢查儲存庫中的 JSON 結構定義是否有差異，例如「contact」欄位放錯位置，以及改善建議，包括使用「oneOf」關鍵字來確保一致性。 | 我們正在調查這項意見回饋，並會在近期內改善結構定義。 歡迎在這裡提供更多意見回饋。 |
| 第三方 (第三方) 對 RWS 的存取權 | 在取得使用者同意後，允許媒體機構指出哪些第三方網域也能存取 RWS API 資料。 | 允許第三方將未分割的資料與 RWS 網站資料合併，會破壞 Privacy Sandbox 的跨網站追蹤保護機制。 不過，我們正在考慮讓第三方能夠將資料保留在 RWS 中，並在 這裡尋求這類解決方案的設計相關意見回饋。 |
Fenced Frame API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| API 問題 | 擔心沒有網路存取權的 Fenced Frames 會破壞廣告客戶的品牌安全和詐欺防護機制。 | 我們會在實施 Fenced Frames 的計畫中追蹤這個問題。我們會盡快開始尋找能與 Fenced Frames 違規處置相容的解決方案。只要提案有足夠的內容，我們就會立即發布。 |
| API 問題 | Fenced Frames API 是否仍預計於 2026 年推出？ | 如公開公告所述，Fenced Frames 的使用期限最早為 2026 年。 |
| API 錯誤 | reportEvent() 成功從跨來源子框架傳送點擊資料時，setReportEventDataForAutomaticBeacons() 不會覆寫頂層框架的資料。 |
我們正在討論這個問題，也歡迎您在這個頁面提供更多意見。 |
Shared Storage API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 應用程式廣告 | Android 版 Privacy Sandbox 中沒有對等的 Shared Storage API。 | 我們正在根據用途需求和平台限制，評估 Android 上的解決方案。我們目前不打算分享任何計畫，但很歡迎各位對這個問題提供其他意見。 |
| API 使用方法 | 對於是否需要額外的 JavaScript 工作區，以便實作 Shared Storage API 感到困惑。 |
我們正在調查這項意見回饋，並考慮更新說明文件，說明為 Share Storage API 使用額外工作區塊指令碼的需求。 |
| 不穩定 | Shared Storage API 可能會因隱私權批評而大幅變動，或遭到捨棄，因此在建構時並不可靠。 | 我們不打算大幅變更或調降「共用儲存空間」的基礎架構。我們已宣布的主要變更是選取網址輸出閘道，其中需要使用圍欄框架，且事件層級報表將淘汰。不過，這些異動至少要到 2026 年才會生效。 |
CHIPS
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 分區 Cookie | 與 Firefox 不同，Chrome 不會根據影格祖系區分分割鍵，因此會導致不一致性。 | Chrome 採用了「祖系鏈結位元」，以解決安全疑慮，以及與 Firefox 的行為不一致。 詳情請參閱這篇文章。 |
| 分區 Cookie | 嵌入的 iframe 具有不同的儲存空間存取層級，會共用並覆寫相同的分區 Cookie，導致驗證狀態不一致。 | 針對這項特定的設定，我們建議在叫用 Storage Access API 時使用未分區的 Cookie。 我們已在這篇文章中進一步討論這項功能。 |
| 分區 Cookie | 停用 3PC 時，系統會清除分割的 Cookie 罐嗎？有沒有方法可以測試這種行為？ | 我們目前沒有任何計畫可分享。不過，開發人員可以透過 Chrome 開發人員工具應用程式> Cookie 面板，手動刪除分割的 Cookie，以便測試這項功能。 |
FedCM
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 識別資訊提供者 (IdP) 註冊範圍與機構選擇器 |
關於將 IdP 註冊從目前的相同來源政策擴展至相同網站政策的問題。這項變更可讓身分管理功能更廣泛且更具彈性，例如讓大學的歡迎頁面註冊多個以子網域為基礎的身分提供者，而無需進行個別來源註冊。 針對改善偵錯功能、處理已核准的客戶以便進行靜默中介服務、說明 Cookie 行為、允許自訂彈出式視窗文字，以及解決逾時問題的意見回饋。 |
我們已收到這項意見回饋，並正在考慮如何將機構選擇器納入 FedCM。 歡迎根據 這個頁面提供的其他寶貴意見，持續改善這項做法。 |
| IdP Cookie | 討論在裝置繫結工作階段憑證 (DBSC) 提案中導入短期工作階段 Cookie 的影響。關於 FedCM 的使用者體驗，人們擔心 FedCM 過期時，必須讓使用者能夠察覺回應，才能更新過期的 IdP Cookie。 | 建議的 DBSC 應允許在無使用者互動情況下更新 Cookie，確保持續的使用者體驗。 我們已在這裡進一步討論這個問題。 |
| API 規格 | 當「providers」陣列的大小不等於 1 時，在 FedCM API 規格中使用「NetworkError」是否適當？ | 我們同意「TypeError」更適合用於這種情況，因為它反映的是程式碼錯誤，而非網路問題。我們會考慮這項變更，並在日後的更新中探索是否有可能移除這項限制，以便支援多個 ID 提供者。 歡迎在這裡提供更多意見回饋。 |
打擊垃圾內容和詐欺行為
Private State Token API (和其他 API)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 淘汰試用方案和模式 B | 對淘汰測試、模式 B 測試、Private State Tokens (PST) 可能停用的疑慮，以及新 API 是否更適合防詐用情境的疑慮。 | 淘汰前測試和模式 B 測試則維持不變。我們會透過開發人員網誌發布任何更新。我們沒有停用 PST 的計畫，目前正在 GitHub 討論持續開發功能和更新。 我們尚未公布任何新的 API，但歡迎您提供意見，說明 PST 可如何更有效解決反詐欺用途。 |
| API 意見回饋 | 申請撤銷權杖的功能，以因應反詐欺用途。 | 雖然發出者可以透過變更所使用的金鑰來撤銷所有權杖，但 API 無法撤銷個別權杖，因為這需要發出者將權杖核發和兌換連結在一起，這會破壞 PST 隱私權模式，因為這會在兩個事件之間進行追蹤。 |