本頁面由 Cloud Translation API 翻譯而成。

意見回饋報告 - 2023 年第 3 季
bookmark_border 透過集合功能整理內容你可以依據偏好儲存及分類內容。

2023 年第 3 季季度報告，摘要說明收到的 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、Protected Audience 和 Attribution Reporting API 相關的問題和意見回饋，這些問題和意見回饋反映了我們目前的開發和測試重點。

在目前報表期間結束後收到的意見回饋，可能尚未收到 Chrome 回應。

縮寫詞彙表

CHIPS: 具有獨立分區狀態的 Cookie
DSP: 需求端平台
FedCM: Federated Credential Management
每秒影格數: 第一方集合
IAB: 互動廣告協會
IDP: Identity Provider
網際網路工程任務組 (IETF): 網際網路工程任務組
IP: 網際網路通訊協定地址
openRTB: 即時出價
延長賽: Origin 試用版
PatCG: Private Advertising Technology Community Group
RP: 依賴方
SSP: 供應端平台
TEE: 受信任的執行環境
UA: 使用者代理程式字串
UA-CH: 使用者代理程式用戶端提示
W3C: 全球資訊網協會
WIPB: 故意隱藏 IP

一般意見回饋，沒有特定 API 或技術

意見回饋主題	摘要	Chrome 回應
生態系統完備性	賣方平台指出，發布商未準備就緒，也未執行必要的部署作業，這點令人擔心。	Privacy Sandbox 的宣傳活動特別著重於教育發布商，包括舉辦專屬網路研討會，以及與發布商和 SSP 舉行會議，以推動部署作業。
第三方 Cookie 停用	由於產業技術停擺，2023 年第 4 季將出現對第三方 Cookie 停用 (3PCD) 的疑慮。	我們已與 CMA 討論 Privacy Sandbox 的時程，並決定在 2024 下半年準備就緒。Privacy Sandbox 將發布更詳細的資訊，說明如何逐步提高 3PCD 的使用率。根據承諾，3PCD 必須等到 CMA 解決競爭疑慮後才能實施。
Google Ad Manager	Google Ad Manager 拒絕公開 API 途徑，導致測試難度提高。	Google Ad Manager 提供的回應：如Google Ad Manager 回覆所述，Google Ad Manager 的 Protected Audience API 整合計畫並未納入支援 Google 發布商廣告伺服器的計畫，因為這會導致無法控制頂層競價。
Google Ad Manager	Google Ad Manager 有一個底價，但只會向 AdX 或公開出價 SSP 公開。	根據 Google Ad Manager 的公開說明文件，內容相關競價的得標者會傳遞至頂層評分邏輯，而非任何元件競價 (包括 AdX 或公開競價)。此外，該文件說明瞭頂層評分邏輯：「Ad Manager 會比較各個元件競價的得標出價，包括 Ad Manager 自己的元件競價 (針對買方的興趣群組出價)，以及最佳比對內容廣告 (透過動態分配選取)，並會放送出價最高的廣告。」
Google Ad Manager	Google Ads 產品應遵守與第三方廣告產品相同的規則。	Google Ads 產品已適用與第三方相同的規則。
Chrome 協助測試	為不在 A 或 B 中的瀏覽器新增標籤。	我們目前不考慮這麼做，因為調查結果顯示，新增非實驗標籤可能會使無痕模式流量產生隱私權疑慮。
廣告代理商	代理商或公司在網站上沒有 JavaScript，可以使用 Privacy Sandbox API 嗎？	任何人都可以呼叫 Privacy Sandbox API。如果代理商或其他人想直接在 API 上建構技術，如同 Cookie，用戶端 API 也必須與用戶端整合。許多 API (例如 Cookie) 也具有 HTTP 標頭介面。我們已經看到 Prebid 這個廣告產業架構，使用 API 建構用戶端整合功能。其他機構也可以這麼做。
用戶端解決方案	工程師在 2012 年曾對這類解決方案的可擴充性表達疑慮，為什麼 Google 仍採用了 Privacy Sandbox 的用戶端解決方案？	自 2012 年以來，隱私強化技術 (PET) 這個研究領域已大幅進步，相關應用也已具備商業可行性。Privacy Sandbox 的核心是 PET 組合，這在十年前是不可能實現的。此外，個人運算能力也提升了，消費者對瀏覽器的期望和監管機關對隱私權的期望也隨之增加。
機器學習	Google 預計如何使用 Privacy Sandbox 進行機器學習？	目前廣告技術生態系統大多使用機器學習，我們認為這不會改變。Privacy Sandbox 不會禁止廣告技術公司或其他人繼續使用機器學習。Privacy Sandbox 也不要求整合 API 的公司使用機器學習。我們認為，無論是否採用機器學習，企業都應持續以滿足客戶需求的方式建構產品和服務。任何 Privacy Sandbox 整合業者建構的機器學習都會公開，因此不會對他們隱瞞。
資料驗證	公司如何驗證透過 Privacy Sandbox 收到的資料是否正確，以及 Google 是否願意透過媒體評級委員會 (MRC) 等實體進行審查？	Privacy Sandbox API 是建構在 Chrome 運作的開放原始碼平台中。在受信任執行環境中執行的 API 部分也是開放原始碼且可稽核。任何人都可以檢查程式碼，包括 MRC。
(也列於上季報告) 正式版支援	Chrome 支援 Privacy Sandbox 技術問題和影響生態系統的升級程序為何？	Google 提供多種管道，方便廣告技術人員回報技術問題，並能進行必要的升級作業，以解決這類問題。此外，Chrome 也希望進一步建構及擴大相關程序，以解決影響生態系統健康的技術問題和提報問題。Chrome 致力於為這項計畫提供資源。請參閱公開和私人論壇，提供意見回饋和提報。
Chrome 協助測試模式	進一步瞭解 Chrome 協助進行的測試模式的時間表和確切實作方式。	我們已發布有關測試模式的網誌文章，並正努力盡快提供更多資訊。我們歡迎您提供建議，告訴我們測試模式標籤應為何種大小。
與其他業界標準整合	Privacy Sandbox API 是否會連結至 TCF 第 2.* 版和同意模式？	我們沒有打算將 Privacy Sandbox API 直接整合至資訊公開和同意聲明架構第 2 版或同意聲明模式。不過，我們歡迎公司和產業貿易團體調整產品和架構，以便與 Privacy Sandbox API 搭配運作。舉例來說，如果採用資訊公開和同意聲明架構這類架構，每個參與者都必須根據收到的資訊公開和同意聲明架構信號和相關的資訊公開和同意聲明架構政策，自行決定遵循的做法。我們希望各家公司自行決定何時及如何使用 Privacy Sandbox 的各種建構元素。

註冊與認證

意見回饋主題	摘要	Chrome 回應
限制	註冊程序表示 Google 可以決定生態系統中哪些公司可以使用 Privacy Sandbox API。	註冊和認證程序基本上包含實體驗證 (例如實體有鄧白氏環球編碼、可提供隱私權政策連結等)，並將公開認證設為呼叫 API 的必要條件。系統會驗證能順利符合註冊規定的實體。對於沒有鄧白氏環球編碼的公司，我們提供與鄧白氏集團合作的免費快速程序，協助取得這組編碼。目的是透過上述措施強化 API 的隱私權保護，並為 Privacy Sandbox API 增添一層透明度，讓相關人士更瞭解哪些人使用哪些 API，以及他們做出哪些認證。我們歡迎業界針對這項問題提供更多意見回饋，我們已將這些意見納入考量，以塑造這項程序。
重新註冊的額外負荷	認證檔案每 12 個月到期，網站必須重新註冊。	我們已收到生態系統的意見回饋，並據此調整做法。也就是說，檔案不會再在 12 個月或任何設定的時間後過期。我們正在更新註冊開發人員指南，加入更多背景資訊。
認證檔案	如何使用認證檔案？	所有呼叫相關性和評估 API 的公司，都必須在執行期限前，將聲明檔案上傳至自家網站，並將檔案設為公開檢視 (只要您打算繼續呼叫 API)。網站每小時可能會收到來自 Privacy Sandbox 的一項要求，其他潛在實體也可能會提出查詢。這項作業會透過註冊系統本身的機制執行，以便查詢已註冊實體的伺服器，並確保認證檔案有效。認證資訊會納入資訊公開報告，供一般大眾查看。我們希望公司能依照其聲明的聲明認證行事，其他生態系統和相關監管機構也應如此。
註冊	註冊作業是按網站還是來源計算？	註冊作業是在網站層級進行。

顯示相關內容和廣告

主題

意見回饋主題	摘要	Chrome 回應
成效	在歐洲經濟區，主題功能的選擇加入率對成效的影響。	我們建議相關利害關係人與相關資料保護主管機關聯絡，討論這個問題。這些機構最適合處理這類疑慮，並影響是否要透過法律鼓勵應用程式採用隱私權強化技術，或是將其視為追蹤行為，要求採用相同的同意聲明做法。後者可能會導致 Privacy Sandbox 中的 API 無法經常使用。
註冊	下游出價方是否需要註冊 Topics API，才能使用上游銷售方平台的 Topics 信號？	除了初始 Topics API 呼叫端以外，主題的下游接收端不需要註冊，但許多可能會註冊以便使用其他 API。為提升透明度，我們會透過程式設計提供 Privacy Sandbox 註冊者的清單，讓 Topics API 的使用者 (如果有需要) 能夠檢查他們傳送主題的收件者是否已註冊。
主題篩選	要求將另一個呼叫端的篩選條件套用至該端在頁面上擷取的主題，以便只分享買方有權擷取的主題。	我們正在考慮這項要求，並歡迎生態系統提供其他意見回饋。
網站排除	排除網站，避免系統將其納入使用者的主題。	系統預設不會呼叫主題。請注意，系統在選取主題時不會考量任何網頁內容，且會篩選所有主題，確保不會出現敏感主題。網站也可以透過下列權限政策標頭，限制自己的網站不納入主題計算：`Permissions-Policy: browsing-topics=()`
主題觀察	允許發布商授權 Chrome 根據網頁內容 (例如標題或內文) 分類主題。	我們先前曾考慮提供功能，根據網頁內容將網站分類為不同主題，但基於隱私權和安全性考量，我們決定不繼續推出這項功能。這項提案或許能緩解部分疑慮，但無法確定程度。由於即將進行 CMA 實驗，我們預計這項變更會在 3PCD 後才會生效。歡迎在這裡提供更多意見。
主題觀察	為發布商提供更精細的權限政策。	為發布商提供更精細的權限政策，可讓發布商網站對整個生態系統的 Topics API 效用造成負面影響，而不會影響 Topics API 對網站本身的效用。如要進一步瞭解這個主題，請參閱「Update permissions policy to support separate permissions for retrieve and observe」GitHub 問題。
醫療和健康主題	為什麼主題分類不涵蓋「醫療」或「健康」類別的主題？	醫療和健康類別屬於敏感主題，因此會從「主題」分類中排除。
主題擷取	可讓 DSP 不必使用標頭擷取，以更快速的方式取得主題。	與建立跨來源 iframe 並從中進行 `document.browsingTopics()` 呼叫相比，標頭方法的效能更高，成本也更低。(由於用於觀察主題的頂層內容必須與存取主題的內容相符，因此必須使用跨來源 iframe 進行呼叫)。如要進一步瞭解這項功能，請參閱這篇文章。
主題擷取	要求支援透過跨來源指令碼標記要求的標頭傳遞主題。	從安全性角度來看，這不可能。每份文件及其執行環境都與單一來源相關聯，也就是文件本身。在相同環境中載入及執行的第三方子資源，會視為由文件來源擁有。這麼做是為了防止未經同意的資料從一個來源流出到另一個來源。另一種做法是在 `<script>` 標記上提供 `browsingTopics` 屬性。從安全性角度來看，這應該是乾淨的，且不會增加額外的延遲時間。我們歡迎有興趣的各方提供意見回饋。
知名度	提高大眾對 Topics API 和 API 使用方式的認知。	我們已與提供這項意見回饋的利害關係人接觸，並在 GitHub 上解決這個問題。日後，我們會持續協助生態系統瞭解 API，也期待聽取各方意見。在此同時，建議有意進一步瞭解 Topics API 的利害關係人，參閱 Chrome 開發人員指南中的說明文件。
通知	當網站觀察到使用者的主題時，系統會發出通知提醒使用者。	我們已在 GitHub 上回覆這項意見回饋。使用者可以前往 Chrome 說明中心進一步瞭解主題控制項。
機器學習	如何使用 ML 推斷使用者主題？	我們正在討論這個問題，也歡迎您提供更多意見回饋。
對不同類型的利害關係人有用	由於瀏覽器的計算方式，較小的廣告技術公司可能無法觀察 Topics。	只有在過去三週內觀察到使用者造訪與該主題相關的網頁時，廣告技術才會收到主題。如果廣告技術在過去三週內，未針對該使用者在與該主題相關的網站上呼叫 API，則傳回的值會為空白。這項功能表示，如果有更多網站擁有者使用廣告技術供應商的服務，因此有更多機會觀察特定使用者造訪網站，那麼廣告技術供應商可能會比其他廣告技術供應商收到更多主題。這項功能對於 API 的隱私權保護至關重要，因為它可將使用者資訊的使用範圍限制在已能觀察到相同基礎資訊的對象 (目前是透過第三方 Cookie)。
XHR 要求	`XMLHttpRequest` (XHR) 要求中的 Topics 何時會淘汰？	如 Chrome 在 2023 年 8 月宣布，Chrome 在從「來源試用」轉換為「一般可用」時，開始淘汰對 XHR 的支援。隨著主題功能的推出，我們只為啟用主題功能的使用者提供 XHR 支援，並在個別主題實驗群組合併時完全淘汰這項功能。如果您使用主題搭配 XHR，您的網站就不會中斷。只是不會將主題新增至 XHR 要求標頭。建議您為要求轉換為 `fetch`、使用 iframe 屬性，或使用 JavaScript API 擷取主題。所有新型瀏覽器都支援 Fetch，但 Internet Explorer 或 Opera Mini 除外。
分類和分類器更新程序	進一步瞭解主題分類和分類器的發布頻率，以及公司如何為這類更新做好準備。	我們的回應與第 2 季相同：如最近的網誌文章所述，我們預期分類法會隨著時間演進，並最終將分類法治理權移交給代表業界各方利益相關者的外部機構。我們也已在 topics-announce 群組中分享了這項計畫。
濫用行為	透過重新導向鏈結的潛在攻擊。	我們正在考慮這個問題，也歡迎您提供更多意見。
發布商廣告空間類型	Protected Audience 和 Topics 測試支援哪些類型的發布商廣告空間？	無論是 Protected Audience 還是 Topics，在可用廣告空間類型方面，都沒有任何限制。
增加曝光量時間	建議不要設定新分類的逐步導入時間，以便達到 100% 的導入率。	在收到生態系統的意見回饋要求和 PATCG 會議討論後，我們已宣布新分類法推出計畫。

Protected Audience API (舊稱 FLEDGE)

意見回饋主題	摘要	Chrome 回應
頂層競價	可使用 Google 的發布商廣告伺服器，而無須將頂層 Protected Audience API 競價的控制權交給 Google Ad Manager。	Google Ad Manager 提供的回應： Google Ad Manager 的 Protected Audience API 計畫不包含支援 Google 發布商廣告伺服器，因為無法控制頂層 Protected Audience 競價，原因如下：為了在發布商廣告放送市場中妥善服務客戶，Google 的發布商廣告伺服器需要保留最高層級 Protected Audience 競價的控制權。身為發布商廣告伺服器，我們的角色是為發布商提供預測資訊，讓他們能夠協商直接銷售的廣告活動，不必超額預訂，並以最佳方式調整及放送直接預訂。這項操作需要執行最終競價，比較所有符合資格的直接和間接需求。預測和配速是發布商期望廣告伺服器提供的核心功能。如果沒有準確的預測資料，發布商可能會過度銷售廣告空間，進而影響商譽。節奏也是關鍵因素，因為無法履行與廣告主的預訂合約，也可能會損害發布商與廣告主的直接關係，進而對發布商業務造成重大影響。因此，簡而言之，我們不會將發布商廣告伺服器執行頂層 Protected Audience 競價的活動視為與發布商廣告伺服器的其他活動有所不同。
`directFrom SellerSignals`	`directFrom SellerSignals` 可讓 Google Ad Manager 避免發布商看到其內容相關競價的價格。	Chrome 回應：除非賣家從自己的 iframe 呼叫 `runAdAuction()`，否則無法得知傳遞至 `runAdAuction()` 的資訊是否來自賣家。在多賣家競價中，所有賣家都無法建立呼叫 `runAdAuction()` 的框架。`directFromSellerSignals` 解決這個問題的方法，是從賣家的來源載入子資源組合，然後載入內容。這可確保從賣方競價設定傳遞至競價的資訊真實且完整，不會遭到操控。如果發布商想使用 Protected Audience API，瞭解技術供應商傳送至 Protected Audience 競價的任何資訊，可以向技術供應商要求這項功能。 Google Ad Manager 回覆：我們多年來一直非常重視競價公平性，包括承諾在其他買方參與競價前，不會將任何發布商無保證廣告來源的價格 (包括無保證委刊項價格) 與他們分享，這項承諾後來也透過向法國競爭局承諾再次確認。針對 Protected Audience 競價，我們會運用 `directFromSellerSignals` 信守承諾，並在多賣方競價中，在競價完成前，不與任何其他競價參與者分享任何競價參與者的出價。請注意，我們也不會將內容相關競價的價格與自家元件競價共用，如「進一步說明頂層競價機制」更新說明所述。
資訊外洩	瀏覽器可能會揭露機密的商業邏輯和合約詳細資料。	使用者可以查看瀏覽器中的所有內容。當瀏覽器內發生廣告競價時，使用者確實可以觀看競價過程，包括查看不同參與者選擇出價的金額。由於瀏覽器是使用者的代理程式，我們認為嘗試變更這項設定是不可能或不理想的做法。不過，只有使用瀏覽器的使用者才能查看這些作業。任何伺服器 (包括 Google 伺服器) 都無法觀察到使用 Protected Audience API 執行的裝置端競價。
`PerBuyerExperiment GroupId`	`PerBuyerExperiment GroupId` 的目前值範圍可讓買方將內容相關資料與受信任的伺服器要求建立關聯。	以這種方式使用 Protected Audience API 與 Privacy Sandbox 的強制認證不符，因為 API 使用者不會試圖規避 Privacy Sandbox 的保護機制。日後，我們會要求鍵/值伺服器在信任的執行環境 (TEE) 中執行，以提供技術防護，對抗這類攻擊。
相同來源政策	放寬相同來源政策，允許使用子網域。	我們正在考慮這項要求，並歡迎生態系統提供額外的意見回饋。
API 版本管理	針對 Protected Audience API 的變更，要求版本編號和版本資訊。	我們正在考慮這項要求，並歡迎生態系統提供額外的意見回饋。
多 SSP 競價	允許頂層競價信號使用元件信號 `auctionSignals` 執行 JSON 合併作業。	我們正在考慮這項要求，並歡迎生態系統提供額外的意見回饋。
出價限制	將進入出價的廣告元件數量上限從 20 提高至 40。	我們正在考慮這項要求，也歡迎生態系統提供其他意見回饋，說明為何這項功能實用。
(也已在前幾季的報告中提及) Protected Audience 競價成效	測試人員回報 Protected Audience 競價的延遲時間過長。	就延遲問題而言，Protected Audience API 通常會遵循現有的標準架構模式，建立控制項，讓賣方決定出價方可使用的時間和資源，以及建立工具，讓買方決定如何最佳運用可用的資源。這些控制項和工具目前已普遍推出，但只有在買方和賣方採用後，才能發揮完整效益。此外，Chrome 也持續改善各種基礎架構，以提升競價速度 (crrev.com/1190815、crrev.com/1199839、crrev.com/1201837、crrev.com/1198339、crrev.com/1197323)。我們歡迎您針對這項延遲改善計畫的兩個部分提供意見回饋：買方和賣方認為實用的全新工具，以及 Chrome 工程師應調查的觀察瓶頸。
買方篩選	新增對買方篩選功能的支援，以興趣群組為依據。	我們建議賣方平台和需求端平台可透過下列幾種方式，變更設計來處理這項問題：將部分工作移至 DSP 的 Key/Value 伺服器。 SSP 建立部分比對內容信號，並將這些信號提供給 DSP。 SSP 為需求端平台快取比對內容信號。
發布商興趣群組控制	支援發布商想委派使用發布商建立的興趣群組。	我們已與許多相關人士討論這項要求。我們認為，所有涉及「委派」發布商建立的興趣群組的這類用途，現在都能妥善處理。此外，我們應該要提供額外支援，讓某些用途日後能更順利進行。
(第 2 季也有提及) 受信任的執行環境	在非公開雲端環境中支援受信任的執行環境 (TEE)。	我們的回應與前幾季類似：雖然我們會持續探索除了公用雲端解決方案以外的支援選項，但目前沒有支援內部部署 TEE 的計畫。在這個階段，考量 Privacy Sandbox 安全性規定和內部部署作業所面臨的重大挑戰，我們認為持續擴大及改善雲端部署作業 (例如除了 AWS 外，也支援 Google Cloud) 對生態系統最為有利。不過，我們歡迎您提供更多意見回饋，說明為何在隱私權和安全性限制下，這項規定是必要且可行的。
受信任的執行環境	TEE 服務路徑中的元件 (例如負載平衡器) 可以觀察所有流量，並取得每個要求的 IP 位址資訊。	目前，在出價和競價以及裝置端 Protected Audience 競價的情況下，IP 位址會以中繼資料的形式，透過要求標頭傳送至不受信任的賣方廣告服務。詳情請參閱中繼資料轉送。長期來說，我們預計透過 IP Proxy 代理廣告技術和追蹤器流量，避免元件觀察到服務路徑中的所有流量。
存留時間 (TTL)	服務必須要求設定新金鑰之前的存留時間 (TTL) 是否會變得靈活 (或動態)？	TTL 通常是靜態的。目前，公開金鑰的存留時間為 8 天，且每 7 天會輪替一次；在匯總服務的情況下，私密金鑰的存留時間也相同。在出價和競價服務的情況下，系統會在非要求路徑中每隔 N 小時擷取私密金鑰和公開金鑰，並將這些金鑰快取至記憶體中，因此在金鑰輪替和伺服器擷取這些金鑰之間，最多只會延遲 N 小時。金鑰輪替和到期之間的 1 天緩衝區，是為了確保即使金鑰產生作業失敗，服務仍可繼續運作。我們正在考慮延長 TTL，以便在服務中斷時更有彈性。在金鑰外洩的情況下，我們會手動強制產生金鑰，並盡快讓金鑰失效。請注意，公開金鑰會在用戶端快取，目前為 24 小時，再次確保協調器發生異常時，服務仍可運作。
流量型態	支援出價和競價服務的流量塑造功能。	買方可以根據發布商的第一方資料或內容相關資料，指出 Protected Audience 競價的需求。賣家也可以在賣家的廣告伺服器或 Ad Exchange 伺服器中做出類似的判斷。模型可使用第一方資料和 Protected Audience 競價的任何匯總報表進行訓練。賣方可利用這項資訊，在沒有目標對象受保護競價需求時，避免向出價和競價伺服器傳送要求。我們認為這是有效塑造流量的方法。
元件競價	哪些頂層 auctionSignal 會與元件賣家共用？	元件競價中的買方只會收到元件賣家的信號。我們很快就會分享相關文件，說明標頭出價和 Protected Audience 競價的整體競價流程。
影片算繪	支援使用 Protected Audience 和 Fenced Frames 轉譯影片。	Protected Audience API 支援使用依賴 iframe 的機制顯示影片。不過，我們尚未設計出與 Fenced Frames 相容的解決方案，這也是我們決定將 Fenced Frames 的實施日期延後至 2026 年的原因之一。也就是說，如果合作夥伴現在決定強制採用 Fenced Frames，那麼該合作夥伴就會缺少影片支援功能。
展示頻率上限	(也已在前幾季的報表中列出) 廣告活動和廣告群組內的個別使用者展示頻率控制項。	我們的回應與先前的報告相同： Protected Audience 將支援裝置端競價和內容相關廣告活動和品牌宣傳廣告活動的展示頻率上限。共用儲存空間和網站專屬上限也可用於設定其他展示頻率上限。
廣告偏好設定	Protected Audience 是否提供可依廣告主網站選擇退出或封鎖的功能，或是可讓您退出所有同一位擁有者所建立的興趣群組的功能？	使用者可以透過多種方式封鎖對 Protected Audience API 和其他 Privacy Sandbox 功能的存取權。
出價和競價指令碼來源網址的相同來源政策	放寬要求，所有指定載入指令碼或 JSON 網址的欄位不必與擁有者同源。	我們目前正在審核這項要求，並歡迎生態系統提供其他意見回饋。
`forDebuggingOnly`	如果 `forDebuggingOnly .reportAdAuctionWin` 在 3PCD 後仍保留，可能會遭到濫用。	過去幾年來，我們一直收到生態系統的意見回饋，指出在淘汰第三方 Cookie 後，Protected Audience 的功能出現缺口。我們正在擬定計畫，在 3PCD 後支援這類功能，同時不犧牲 Privacy Sandbox 的目標。歡迎針對生態系統缺少的功能提供更多建議和意見回饋。
多個興趣群組	在同一個出價中使用多個興趣相似目標對象群組。	目前 Protected Audience API 不支援這項功能，因為這會導致底層隱私權模型發生變更。歡迎在此進一步討論。
裝置端競價	Android 版 Chrome 是否支援裝置端 Protected Audience 競價？	是的，Android 版 Chrome 將支援裝置端競價。
(2023 年第 2 季回報) 點擊相關資料	在瀏覽器信號中加入點擊相關資料。	我們會持續評估這項功能要求，並歡迎您提供其他意見，說明為何應優先實施這項功能。
受信任的執行環境供應商	不同雲端服務供應商提供的 Trusted Execution Environment 是否有重大差異？	我們不清楚兩者有何重大差異，但建議生態系統檢閱公開部署指南，瞭解哪種解決方案最符合需求。 Google Cloud。 AWS。
(上個季度已回報) 支援指定排除興趣群組	支援興趣群組排除條件的 API：僅在使用者不屬於某個興趣群組時顯示廣告。	我們正在研究如何實作這項功能，並討論要求。
內容違規	支援功能，讓使用者在 Fenced Frames 中，回報 Protected Audience API 放送的惡意廣告。	我們認為，現有的柵欄式廣告回報機制為希望使用者回報「惡意廣告」的廣告技術人員提供了不錯的選項。這樣一來，惡質廣告檢舉方式將與現行業界標準大致相同。如果仍有任何空白期，歡迎提出其他功能要求，包括在移除第三方 Cookie 後，但在 Fenced Frame 轉譯變得普遍之前。
Private Aggregation API 報表	我們如何計算使用者在該興趣群組中花費的時間？	在 Chrome M116 以上版本中，您應該可以使用 pull/639 定義的 recency。
K-匿名伺服器	進一步瞭解 K-Anonymity 伺服器。	我們已在這裡分享更多關於 K-Anonymity 伺服器的資訊，並歡迎您提供更多意見回饋。
動態廣告素材網址	支援不需預先宣告的廣告素材網址，同時仍尊重 k-anonymity。	我們正在討論這項功能要求，歡迎提供其他意見，說明為何應將這項功能列為優先。
K-anonymity 規定	是否會重新推出興趣群組更新的 k-anonymity 規定？	我們不預期會變更這篇 GitHub 貼文中所述的立場。如該篇文章所述，我們決定移除「Protected Audience」興趣群組更新的 k 匿名性要求，這不會對 API 的整體隱私權保護措施造成重大影響。我們預計在相關技術更成熟、部署及採用後，再考慮其他可能的更直接保護措施 (例如 IP 位址隱私權或可信任的更新伺服器)。
出價和競價服務 Beta 版測試	出價與競價服務 Beta 版何時開始測試？	如時間表和路線圖所述，第一階段的出價和競價服務測試將於 2023 年 11 月開始。
路障型廣告	要求支援廣告聯播網的廣告素材協調功能 (賣方平台和需求方平台位於同一家公司或資源)。	感謝您提供這個用途的意見回饋，我們想瞭解是否有更多廣告技術人員希望我們支援這個用途。歡迎提供更多意見回饋。
原生廣告	原生廣告的圍欄邊框支援。	我們正在考慮支援該用途，並討論可能的解決方法和解決方案。
K-anonymity	如何盡可能放送符合 k-anon 門檻的興趣群組廣告？	我們已提供一些相關實用建議。
POST 支援	支援透過 POST 要求傳送競價資料。	我們正在評估這項功能要求，並歡迎提交其他 GitHub 問題，說明為何應優先處理這項要求。
報表精細程度	使用由多個部分組成的廣告時，圍欄廣告報表的精細程度為何？	目前的設計不允許擷取產品 ID 或位置，因為這可能會危害使用者隱私。只能叫用 `reserved.top_navigation`，當使用者在廣告元件圍欄框架上執行某項操作 (例如點擊) 時，系統就會傳送這項事件，進而導致頂層導覽。
廣告競價	參與元件競價的賣方平台是否可以觸發另一個元件競價？	`componentSeller` 也不能包含 `componentAuctions`。多重賣方競價只有兩個層級： 1. 並行執行元件競價。 2. 頂層競價 (各 `componentAuction` 勝出的廣告競爭)。
出價和競價服務的適用情形	在 Chrome 輔助測試階段，是否可使用出價和競價功能？	在 Chrome 協助測試階段，系統不會提供出價和競價伺服器。
出價信號	允許瀏覽器要求及刪除出價信號。	我們正在討論這項要求，並歡迎提供更多意見回饋，說明為何應優先處理這項要求。
`generateBid()`	能夠透過 `updateURL` 更新興趣群組的 `userBiddingSignals`。	我們正在考慮這項提案，並歡迎您提供更多意見回饋和討論。
發布商廣告空間類型	哪些類型的發布商廣告空間支援 Protected Audience 和 TOPICS 測試？	無論是 Protected Audience 還是 Topics，在可用廣告空間類型方面，都沒有任何限制。
伺服器對伺服器整合	是否需要在 Protected Audience 中直接整合賣方平台和需求端平台？	如果 DSP 不需要在自有伺服器中處理內容信號，以便將經過處理的資訊傳遞至裝置端出價函式，就不需要在 SSP 和 DSP 之間直接整合。
B&A 中的 `bid_currency` 欄位	支援出價和競價服務中的 `bid_currency` 欄位。	B&A 尚未支援 `bid_currency`，但我們預計在 2024 年 1 月底前支援該功能。請參閱這裡的時間表。
`perBuyerSignals`	`perBuyerSignals` 是否有大小限制？	每位買家信號的數量沒有限制，但傳送過多資料可能會對瀏覽器的效能造成不利影響。
跨網站用途	我們可以跨多個網站使用 Protected Audience API 興趣群組嗎？	如turtledove/issues/282所述，Protected Audience 並非為這類用途而設計。
興趣群組 HTTP 要求	在 HTTP 標頭中加入興趣群組 Blob。	我們正在審核這項要求，也歡迎您提供更多意見回饋。
廣告品質控管	跨網站資訊相關的廣告品質控管功能遭到破壞。	我們正在考慮這項意見回饋，也歡迎提供更多意見回饋。
Chrome 開發人員工具	Chrome 開發人員工具的「網路」分頁應會顯示傳出 Protected Audience 網路要求。	我們正在努力在網路分頁中啟用這項功能，也歡迎提供更多意見，說明為何應優先實施這項功能。
受信任的執行環境	哪些指標會影響隱私權 (以及影響程度) 的詳細資料，何時會加入「受信任執行環境」監控說明？	我們正在更新說明，加入這項資訊。更新版說明將於 2023 年 11 月推出。
`directFrom SellerSignals`	為什麼 `directFrom SellerSignals` 沒有以網頁包裝格式封裝？	這裡說明瞭做出這項決定的原因。
曝光委派	是否有可行的方式，可在選取興趣群組的結果為另一個指定動作的情況下，進行曝光委派？	有兩個原因說明為何多個巢狀競價不符合我們的隱私權目標：首先，當競價勝出者在 Fenced Frame 中算繪時，Protected Audience 的隱私權目標包括產生的廣告素材算繪，而不會知道內容：周圍網頁的網址或第一方 Cookie 是違反隱私權的行為。在這種環境中，巢狀競價無法運作。第二，Protected Audience 模式指出，每場競價的勝出者應根據單一額外網站的資料。巢狀競價是一種複合方式，可讓系統根據多個網站設定檔選擇廣告。
靜態資料條件	進一步說明鍵/值服務信任模型中的靜態資料準則。	鍵值服務中的資料會載入至記憶體，並從記憶體提供，而不會執行任何貫穿式快取。
買方資料信號	從 DSP 收到的 `buyer_data` 信號是否有大小限制？	目前瀏覽器並未對從 DSP 收到的 `buyer_data` 信號設下限制。

評估數位廣告

歸因報表 (和其他 API)

意見回饋主題	摘要	Chrome 回應
跨裝置	規劃 Attribution Reporting API 的跨裝置支援功能。	跨裝置功能除了 3PC 之外，還會帶來新的隱私權挑戰，並且由於使用者可能會使用各種裝置和平台，因此也會帶來技術分發挑戰。我們正在探索潛在解決方案，但目前專注於歸因報表目前支援的重要用途，並無計劃在移除第三方 Cookie 前推出跨裝置支援功能。
(也列於前幾季) 觸發資料大小	為什麼觸發事件資料大小上限為 3 位元？	大小限制為 3 位元和 8 個不同值，以確保使用者跨網站和跨情境的資訊量受到限制。歡迎生態系統參與者提供意見，針對目前事件層級報表的參數化是否足夠。
轉換漏斗	回報轉換中使用的多個網域。	新增多個目的地後，即可實現此用途。歡迎提供其他意見回饋。
支援不同國家/地區的相同網域	歸因報表是否適用於網域相同但國家/地區頂層網域不同的網站？	我們已與提出問題的利害關係人討論並解決這個問題。如果廣告技術需要使用多個國家/地區頂層網域，就需要進行多項註冊，每個國家/地區頂層網域各一項。
Protected Audience 和歸因報表	廣告技術人員可以同時存取 Protected Audience 競價的瀏覽後轉換，以及歸因報表的點閱後轉換嗎？	是的，Privacy Sandbox 應支援 Protected Audience 中的 VTC 和 CTC。
可匯總報表延遲	進一步縮短可匯總報表的延遲時間。	我們最近收到了相關意見回饋，並在這裡分享想法。歡迎生態系統提供更多意見回饋。
可匯總報表延遲	透過引入伺服器中介服務來縮短延遲時間。	我們正在考慮這項提案，並歡迎您提供更多意見回饋。
事件層級報表延遲	縮短事件層級報表的延遲時間。	如彈性事件層級設定所述，完整彈性事件層級提案可將事件層級報表延遲時間縮短至 1 小時，但會產生雜訊。
每個來源的報表來源	每個來源報表網站的來源報表來源上限可避免廣告技術為單一發布商來源登錄不同報表來源的來源。	我們已與提出問題的利害關係人討論這項問題，並正在測試每個來源回報網站使用 1 個回報來源的潛在解決方案，然後再嘗試其他涉及重新導向的潛在解決方案。我們也歡迎您針對這項限制提供其他生態系統意見回饋。
問題回報	如何向 Chrome 回報 Attribution Reporting API 的錯誤或問題？	目前，我們建議廣告技術人員將可能遇到的任何 Attribution Reporting API 錯誤，當作問題回報至 GitHub。如果他們遇到與 Chrome 相關的問題，建議您建立 Chromium 錯誤。如要瞭解如何標示任何問題，以及標示的位置，請參閱「與我們互動並提供意見回饋」一文。
簡化資料	如何在不同管道和裝置上排除重複的轉換？	跨裝置和評估管道進行去重作業，是廣告技術人員目前面臨的 3PC 問題。有了歸因報表 API，廣告技術人員就能決定何時登錄特定轉換，並新增特定中繼資料，指出他們用來追蹤轉換的評估管道 (也就是匯總鍵的一部分)，以便與其他評估管道進行比較。我們歡迎您針對這項功能提供任何其他生態系統意見回饋。
去重複與優先順序	要求先排除重複項目再進行去重作業。	我們正在審核這項要求，並歡迎您提供更多意見回饋。
反詐欺	惡意使用者竄改事件層級資料的風險。	如「為什麼這項功能不支援事件層級報表？」所述，報表驗證功能無法用於事件層級報表。
轉換類型	如何在歸因報表中區分轉換和導覽？	我們有下列內建篩選選項：`source_type`。如需更多詳細資訊，請參閱這篇文章。

匯總服務

意見回饋主題	摘要	Chrome 回應
預算復原	部分廣告技術人員要求在報表發生失敗、錯誤或刪除的情況下，能夠重新處理報表。	團隊正在研究如何以保護隱私權的方式解決這個問題。
網站註冊	多位廣告技術人員已要求支援在同一個帳戶中處理多個來源，以便根據地理區域、廣告客戶等分割資料。由於用戶端 API 註冊現在是依網站而非來源為準，廣告技術也預期會出現這種行為。從來源到網站註冊的遷移作業，可透過與客戶註冊程序一致，簡化廣告技術新手上路流程。	我們很快就會推出匯集服務的來源註冊至網站註冊的遷移功能，歡迎生態系統提供意見回饋。
發布與淘汰計畫	匯總服務功能和發布的修補程式，其發布和淘汰時間表。這項計畫的目標是讓廣告技術人員瞭解我們的發布政策，以便為即將發布和淘汰的政策做好準備，並確保他們執行的是穩定且安全的服務版本。	我們最近發布了匯總服務的發布和淘汰計畫提案，歡迎提供更多意見回饋。
協調器	如果匯集服務的協調程式中斷，會發生什麼情況？	系統必須同時具備這兩種協調器，才能正常運作。用戶端程式庫會在短暫的服務中斷期間重試，如果兩個協調器其中一個無法使用，匯總工作就會失敗。如果隱私權預算尚未用盡，工作就能重新執行。如果服務失敗導致預算消耗，但沒有將摘要報表寫入廣告技術儲存空間，我們目前建議使用者使用「本機測試工具」，透過偵錯報表擷取結果。我們也正在開發功能，以便在失敗時復原預算，讓廣告技術人員重新執行工作。

私密匯總 API

意見回饋主題	摘要	Chrome 回應
Blob 網址	要求支援共用儲存空間中的 Blob 網址。	Chrome M116 已新增 Blob 網址支援功能。

限制隱密追蹤

使用者代理程式縮減和使用者代理程式用戶端提示

意見回饋主題	摘要	Chrome 回應
JavaScript API	User-Agent Client Hints JavaScript API 的供應情形。	我們沒有移除這項功能的計畫，因為這項功能是我們為合作夥伴提供的核心解決方案，可讓他們主動存取高熵資料，而非在已凍結及縮減的通用 Analytics 中預設提供的資料。
裝置和板型規格資訊	網站可瞭解造訪網站的裝置可支援的輸入、輸出和其他資訊。	我們已根據生態系統的意見回饋，新增這項要求的支援功能。

IP 保護 (原稱 Gnatcatcher)

意見回饋主題	摘要	Chrome 回應
符合資格的第三方流量	說明中提到的「符合資格的第三方流量」指的是什麼？	我們瞭解這個問題的重要性，並且正積極努力找出哪些第三方流量符合資格，哪些不符合資格。歡迎您針對這個主題提供意見。
網路流量稽核	支援企業為網路執行網路流量稽核作業。	只有嵌入第一方網站的第三方流量會受到影響，因此可限制需要篩選的流量數量。此外，我們也打算讓使用者選擇是否要使用 IP 保護功能，而企業控制的 Chrome 則會有企業政策來停用 IP 保護功能。最後，我們正在研究要為網路作業員提供哪些控制項 (如有)，以便停用 IP 保護功能。歡迎您針對這個主題提供意見。
存取權控管	IP 保護功能可能會影響使用 IP 位址做為存取控制機制的 Web 服務。	我們瞭解防詐欺用途的重要性，以及這些用途可能受到的影響。我們正在尋求生態系統的意見回饋，瞭解如何更好地支援通常仰賴 IP 位址的防詐行為用途。
2 跳 Proxy 之間的通訊	如何確保代理伺服器之間沒有任何資訊。	我們正在設計代理程式互動功能。我們的目標是盡可能減少透過業務、程序和技術手段分享這類資訊的機會。
非 Google 驗證	支援非 Google 驗證。	我們預計日後會發布更多帳戶驗證相關詳細資訊，但已分享一些初步考量。
追蹤器分類	IP 保護功能如何判斷追蹤器及其變體？	我們瞭解這個問題的重要性，並且正積極努力找出哪些第三方流量符合資格，哪些不符合資格。歡迎您針對這個主題提供意見。
數據分析	IP Protection 可能會影響數據分析服務的準確度。	我們正進一步瞭解 IP Protection 的影響，歡迎生態系統提供更多意見回饋和示例。
Proxy	如果使用者使用 Proxy 或已手動定義 Proxy，IP 遮罩在這種情況下會如何運作？	我們正試圖瞭解 IP 保護功能對其他 Proxy 的影響。我們目前沒有任何計畫可分享。歡迎您提供意見。
進階產品	IP 保護功能是否為付費功能？	IP 保護功能將成為 Chrome 使用者的核心瀏覽器體驗之一。這項功能不會收費。
Proxy 伺服器	使用者工作階段中是否會使用相同的 Proxy 伺服器？	HTTP/S 連線會使用一組 Proxy，並向來源顯示單一遮罩 IP 位址。除此之外，不同 HTTP/S 連線不必使用相同的伺服器，這方面沒有硬性限制。
平台支援	IP Protection 支援哪些平台？	IP 保護功能最初會在 Android 版和電腦版 Chrome 中推出。我們會持續評估如何將這項保護機制擴大至其他平台。
選擇不採用	使用者是否能停用 IP 保護功能？	我們預計讓使用者自行選擇是否要使用 IP 保護功能。
去識別化	IP 保護功能會將哪些類型的要求去識別化？	針對符合資格的第三方網域，系統會透過隱私權 Proxy 服務將 HTTP/S 和 DNS 要求匿名化。我們將於後續的說明中提供更多詳細資訊，說明我們如何決定納入哪些網域。其他流量 (例如其他 DNS 要求或其他 HTTP/S 流量) 不會受到影響。
資料掌握	IP 保護功能可能會在第一個中繼期間存取網路位址。	在兩跳 Proxy 模型中，第一跳 (由 Google 控制) 只會看到來源用戶端 IP 和連線至第二跳的要求，而第二跳 (由外部 CDN 控制) 只會看到第一跳的元組 (Proxy IP + 通訊埠) 和目的地 IP。針對來自來源的回應，第二個躍點可將回應轉送至與要求相關聯的第一個躍點 Proxy+Port，且不需要瞭解原始用戶端 IP 的任何資訊 (第一個躍點只會將回應傳回給用戶端，不會瞭解目的地 IP 的任何資訊)。這樣一來，第一個躍點只會學習用戶端 IP 和第二個躍點，而第二個躍點只會學習目的地 IP。
WebView	IP 保護功能日後是否會支援 Android WebView？	我們目前沒有任何計畫可分享，但我們的願景是盡可能提供這項保護措施。

跳轉追蹤因應措施

意見回饋主題	摘要	Chrome 回應
互動追蹤	系統如何追蹤使用者互動？	跳轉追蹤因應措施會追蹤兩種使用者互動：根據 html 規格定義的使用者啟動動作。這些動作基本上是點擊、按鍵、輕觸螢幕等。成功的 webauth 斷言。使用者輕觸安全金鑰或使用密碼金鑰進行驗證的情況這些互動會與發生互動的網頁中，頂層網站建立關聯。舉例來說，如果使用者在嵌入式 iframe 中點按，互動就會與頂層網站相關聯，而非嵌入式網站。互動會儲存在資料庫中，其中包含無架構 etld+1 和互動時間。互動可保護相關聯的網域，避免在 45 天內刪除彈出率追蹤緩解狀態。
已加入許可清單的豁免項目	網域是否可豁免？	我們正在考慮這項要求，也歡迎生態系統提供額外意見回饋。

隱私預算

本季未收到任何意見回饋。

強化跨網站隱私界線

意見回饋主題	摘要	Chrome 回應
集中式方法	對於用來管理相關網站集的中央存放區方法，我們有疑慮。	公開且容易存取的存放區是 RWS 設計的關鍵，因為它可提供提交內容的問責性。第三方 Cookie 功能最終是由使用 Storage Access API 或 rSAFor API 提供，RWS 會員則會自動授予存取權 (而非透過 Storage Access API 的提示)。我們認為，RWS 提交程序等做法是自動授予第三方 Cookie 存取權的適當要求。
重新命名 JSON 檔案	隨著 API 名稱的變更，是否需要變更代管的 JSON 檔案名稱？	是的，提交指南已變更，主要網域必須在 `/.well-known/related-website-set.json` 中提供 JSON 檔案。 RWS 清單中的現有組合不需要變更，但如果有針對現有組合提交的修改，就必須變更 JSON 檔案。
(也曾在前幾季回報) 網域限制	要求擴充相關網域數量	如 8 月 31 日的網誌文章所述，我們已根據生態系統的意見回饋，將相關網域數量上限提高至五個網域。我們決定將相關網域限制提高至五個網域 (加上一個主要網域)，這與其他主要瀏覽器提供的最佳可比實作方式最為相符。
第三方 Cookie	相關網站集合是否只能在停用第三方 Cookie 的情況下運作？	即使使用者未封鎖第三方 Cookie，相關網站組合也能正常運作，但不會有任何可觀察到的效果，因為相關 Cookie 可供使用，無須使用相關網站組合和 Storage Access API。
合法編輯	相關網站集合存放區如何防止非擁有者修改集合？	根據提交指南，任何人都可以在 GitHub 上提交 PR 來編輯 `first_party_sets.JSON` 檔案。不過，如果 PR 獲得核准 (通過技術驗證等)，Google 會每週一次 (星期二中午 12 點美國東部時間) 手動將 PR 批次合併至標準 FPS 清單。如果惡意使用者嘗試修改不屬於自己的集合，這應該不會造成問題，因為他們無法修改 `.well-known` 檔案，因此驗證作業會失敗。
網域劫持	網域劫持可能會將相關網域資料洩漏給未經授權的對象。	這項功能無法實現，詳情請參閱這個 Protected Audience GitHub 問題。

Fenced Frames API

意見回饋主題	摘要	Chrome 回應
內容違規	允許使用者檢舉可疑廣告。	防範可疑廣告的回報功能不會受到 Fenced Frames 的影響。使用者仍可與廣告互動，並以一般方式向廣告技術回報可疑廣告。
與周邊網站互動	允許與周圍或頂層網站互動。	我們希望瞭解為何需要這項要求，並歡迎生態系統提供更多意見回饋。
原生廣告	原生廣告的圍欄邊框支援。	我們正在考慮支援該用途，並討論可能的因應措施和解決方案。

Shared Storage API

意見回饋主題	摘要	Chrome 回應
跨網域	允許本機儲存空間跨網域通訊。	這個用途目前不符合共用儲存空間的隱私權保護輸出閘門，但我們歡迎提供額外背景資訊，協助我們為非分割儲存空間提出提案。
Blob 網址	要求支援共用儲存空間中的 Blob 網址。	Chrome M116 已新增 Blob 網址支援功能。

CHIPs