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

意見回饋報告 - 2023 年第 3 季

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 的 1:1 相關人員會議記錄、個別工程師收到的電子郵件、API 郵寄清單和公開意見回饋表單接著，Google 會和參與這些各種外聯活動的團隊協調，判斷各主題相對於各 API 的相對情況。

我們根據已發布的常見問題、對利害關係人提出問題的實際回應，制定了 Chrome 回應回應的說明，並針對這項公開報告練習制定專屬定位。回顧目前的開發和測試重點，以及有關 Topics、Protected Audience 和 Attribution Reporting API 的問題和意見回饋。

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

縮寫詞

方塊: 具有獨立分區狀態的 Cookie
DSP: 需求端平台
FedCM: Federated Credential Management
FPS: 第一方集合
IAB: 互動廣告協會
印尼盾: 識別資訊提供者
網際網路工程任務組 (IETF): 網際網路工程任務組
IP: 網際網路通訊協定位址
openRTB: 即時出價
加時: 來源試用
PatCG: 私人廣告科技社群
RP: 宗教派對
賣方平台: 供應端平台
TEE: 受信任的執行環境
UA: 使用者代理程式字串
UA-CH: 使用者代理程式用戶端提示
W3C: 全球資訊網協會
建構中: 有益 IP 盲點

一般意見回饋，不使用特定 API 或技術

意見回饋主題	摘要	Chrome 回應
生態系統完備性	賣方平台提出了一個疑慮，那就是發布商未準備就緒，且未執行必要的部署工作。	Privacy Sandbox 設有專門的推廣計畫，專門協助發布商瞭解相關知識，包括透過專屬網路研討會，以及與發布者和賣方平台召開會談，推動部署工作。
第三方 Cookie 停用	由於產業技術停止服務，導致第三方 Cookie 淘汰 (3PCD) 的疑慮在 2023 年第 4 季增長。	Privacy Sandbox 的時程表與 CMA 討論，將序列排入 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 或公開出價賣方平台公開的底價。	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 上建構技術。用戶端 API 需要與用戶端整合，就和 Cookie 一樣。許多 API (例如 Cookie) 都有 HTTP 標頭介面。我們已經看過一種廣告產業架構：預先出價，並且與 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 會連結至資訊公開和同意聲明架構第 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 回應
效能	效能疑慮會影響 Topics 在歐洲經濟區的採用率影響。	我們建議相關人員與相關資料保護主管機關聯絡，討論這項問題。他們最適合用來解決這類疑慮，並影響隱私權加強技術的應用是否受到法律動機，還是被視為追蹤而需要採用相同的同意聲明方式。後者可能會導致 Privacy Sandbox 中的這類 API 不常使用。
註冊	下游出價方是否需要註冊 Topics API，才能使用上游賣方平台提供的 Topics 信號？	除了初始 Topics API 呼叫端以外，主題的下游接收器不必註冊，但許多主題可能會註冊使用其他 API。Privacy Sandbox 註冊者清單會以程式輔助方式提供，做為這項計畫公開計畫的一環，讓 Topics API 感興趣的呼叫端檢查自己傳送主題的接收者是否已註冊 (如有需要)。
主題篩選	要求對他在頁面上擷取的主題套用另一個呼叫端的篩選條件，以便只分享買家可擷取的內容。	我們正在考慮這個要求，並歡迎生態系統提供其他意見回饋。
網站排除	排除網站，避免網站對使用者的主題納入內容。	根據預設，系統不會呼叫主題。請注意，選取主題時，系統不會將任何頁面內容納入考量，也會收錄所有主題，確保內容不敏感。網站也可以透過下列權限政策標頭，禁止網站納入主題計算：`Permissions-Policy: browsing-topics=()`
主題觀察	允許發布商授予 Chrome 根據網頁內容 (例如標頭或內文) 將主題分類的權限。	我們之前考慮提供根據網頁內容將網站分類的功能，並且根據隱私權和安全性疑慮決定不繼續。本提案可能會緩解其中一些疑慮，但不清楚的範圍。由於即將進行 CMA 實驗，我們預計在 3PCD 之前不會發生這項變更。歡迎點選這裡，提供其他意見。
主題觀察	為發布商提供更精細的權限政策。	為發布商提供更精細的權限政策，可讓發布商網站對整個生態系統的 Topics API 公用程式造成負面影響，而不會對網站本身使用 Topics API 的效用造成負面影響。如要進一步瞭解相關主題，請參閱「更新權限政策以支援個別的擷取與觀察 GitHub 問題」一節。
醫療與健康主題	為什麼 Topics 分類不涵蓋醫療或健康類別的主題？	醫療和健康類別屬於敏感主題，因此不在 Topics 分類中。
擷取主題	可讓 DSP 更快取得 Topics，而不必使用標頭擷取。	與建立跨來源 iframe 並發出 `document.browsingTopics()` 呼叫相比，標頭方法的成效更佳，成本也更低。(呼叫必須使用跨來源 iframe，因為頂層內容來觀察主題必須與存取主題的背景資訊相符)。詳情請參閱這裡。
擷取主題	支援透過跨來源指令碼標記要求透過標頭傳送 Topics 的要求。	就安全性層面而言，這不可能。每份文件及其執行環境都會與文件的單一來源建立關聯。凡是在相同環境中載入及執行的第三方子資源，都會視為文件來源所擁有。這是為了避免因未同意而從一個來源的資料外洩到另一個來源。另一種做法是在 `<script>` 標記上提供 `browsingTopics` 屬性。這些資訊應從安全性的角度清除，不會增加額外的延遲時間。我們很樂意向感興趣的單位提供意見回饋。
知名度	讓大眾更容易瞭解 Topics API 和 API 的預計使用方式。	我們已與提供這項意見回饋的利害關係人聯絡，這項問題已在 GitHub 中解決。未來我們將繼續協助生態系統對 API 的理解，並期待收到相關人員的看法。與此同時，我們建議相關人員想進一步瞭解 Topics API，並參閱 Chrome 開發人員指南中的說明文件。
通知	在網站觀察到使用者主題時提醒使用者的通知。	我們已解決 GitHub 上的這項意見回饋。使用者可以前往 Chrome 說明中心進一步瞭解 Topics 控制項。
機器學習	如何運用機器學習來推斷使用者 Topics？	我們正在討論這個問題，也歡迎提供意見。
不同各類型相關人員的實用性	由於瀏覽器計算 Topics 的方式影響，小型廣告技術公司可能無法觀察 Topics。	只有在過去三週內，觀察到使用者造訪相關主題頁面的廣告技術，才會收到主題。如果廣告技術在過去三週沒有針對該使用者在網站上呼叫該主題呼叫 API，傳回的值就會空白。這項功能意味著，如果廣告技術有大量網站擁有者使用服務，因此較有機會觀察特定使用者網站造訪情形，收到的主題可能會比其他廣告技術更多。這項功能對於 API 的隱私保護至關重要，因為這會限制使用者只能看到相同基礎資訊 (目前透過第三方 Cookie) 的使用者。
XHR 要求	`XMLHttpRequest` (XHR) 要求中的 Topics 將於何時淘汰？	Chrome 已於 2023 年 8 月宣布，在從來源試用轉換為正式發布版時，Chrome 已開始淘汰 XHR 相關支援。隨著 Topics 的逐步發展，只有啟用 OT 功能的使用者，且在個別 OT 實驗群組合併時完全淘汰了 XHR 支援功能。如果您搭配 XHR 使用 Topics，網站不會中斷。系統不會將主題新增到您的 XHR 要求標頭。建議您為要求改用 `fetch`、使用 iframe 屬性，或使用 JavaScript API 擷取主題。所有新式瀏覽器都支援擷取功能，但 Internet Explorer 或 Opera Minii 不支援擷取功能。
分類和分類器更新程序	進一步瞭解 Topics 分類和分類器發布頻率，以及公司如何為這類更新做好準備。	第 2 季的回應仍維持不變：如最近的網誌文章所述，我們預期分類的發展會隨著時間而有所進展，且對於分類管理，最終將轉型為代表業界各方利害關係人的外部人員。我們也在 topics-announce 群組中分享了增加曝光量計畫。
濫用行為	可能透過重新導向鏈結遭受攻擊。	我們正在考慮這個問題，也歡迎您提供其他意見回饋。
發布商廣告空間類型	Protected Audience 和 Topics 測試支援哪些類型的發布商廣告空間？	Protected Audience 和 Topics 本身都沒有限制，對於可用廣告空間類型則設有限制。
適應期	建議不要讓新分類達到 100% 的適應時間。	我們已按照生態系統提出的意見回饋要求，並在 PATCG 會議期間討論相關意見，並宣布新分類推出的計畫。

Protected Audience API (舊稱「FLEDGE」)

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

評估數位廣告

Attribution Reporting (和其他 API)

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

匯總服務

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

Private Aggregation 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 位址進行存取權控管的網路服務。	我們瞭解反詐欺用途的重要性，以及這些用途可能受到的影響。我們正在徵求生態系統意見回饋，瞭解該如何有效支援通常仰賴 IP 位址的反詐欺用途。
2-Hop Proxy 之間的通訊	如何確認 Proxy 之間沒有資訊。	我們正在設計 Proxy 互動。我們的目標是盡可能避免透過業務、程序和技術等方式分享這類資訊。
非 Google 驗證	支援非 Google 驗證。	我們預計日後會發布更多帳戶驗證相關詳細資料，不過還有一些初步注意事項。
追蹤記錄分類	IP 保護如何判定追蹤器及其變化版本的組成？	我們瞭解這個問題的重要性，並正積極努力找出哪些第三方流量符合資格，哪些第三方流量則符合資格。歡迎對這個主題提出寶貴意見。
數據分析	IP 防護可能會影響數據分析服務的準確度。	我們想要進一步瞭解「IP 保護」的影響，也歡迎各位提供來自這個生態系統的其他意見回饋和範例。
Proxy	如果使用者正在使用 Proxy 或已手動定義 Proxy，則 IP 遮罩會如何運作？	我們正試圖瞭解 IP 保護功能對其他 Proxy 可能造成的影響。我們目前沒有任何計畫可以分享。歡迎您針對這個主題提供意見。
進階方案	「IP 保護」屬於付費功能嗎？	Chrome 使用者可在核心瀏覽器體驗中使用 IP 保護功能。但非付費功能。
Proxy 伺服器	使用者工作階段期間是否會使用相同的 Proxy 伺服器？	HTTP/S 連線會使用一對 Proxy，並會向來源顯示一個遮蓋的 IP 位址。除此之外，不同 HTTP/S 連線不需要使用相同的伺服器，因此沒有硬性限制。
平台支援	哪個平台將支援 IP 防護？	「IP 保護」最初適用於 Android 版和電腦版 Chrome。我們會持續評估如何擴大防護範圍至其他平台。
選擇退出	使用者將停用 IP 保護嗎？	我們計劃讓使用者自行選擇是否要使用 IP 保護。
去識別化	IP 防護設定將哪些類型的要求去識別化？	傳送至合格第三方網域的 HTTP/S 和 DNS 要求，會透過隱私權 Proxy 進行去識別化處理。我們會在後續的章節中提供更多詳細資訊，說明我們如何決定要加入哪些網域。其餘流量 (例如其餘 DNS 要求或其他 HTTP/S 流量) 則不受影響。
資料掌握	在 IP 保護的第一個躍點期間，可能會存取網路位址。	在雙躍點 Proxy 模型中，第一個躍點 (由 Google 控管) 只會看到來源用戶端 IP 和連線至第二個躍點的要求，而第二個躍點 (由外部 CDN 控制) 則只會在第一個躍點 (Proxy IP + 通訊埠) 和目的地 IP 上看見元組。對於來源傳回的回應，第二個躍點可以轉送回應至與要求相關聯的第一個躍點 Proxy+通訊埠，且無需瞭解原始用戶端 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，因此這些 Cookie 不會造成可觀察的影響。
正當的編輯內容	相關網站集存放區如何防止非擁有者修改集合？	根據提交指南，任何人都可以在 GitHub 上提交 PR 來編輯 `first_party_sets.JSON` 檔案。不過，如果 PR 獲得核准 (通過技術驗證等)，Google 每週都會手動將 PR 批次合併到標準 FPS 清單一次 (東部標準時間星期二下午 12 點)。如有不肖人士企圖修改不屬於自己的集合，就不應該發生問題，因為他們無法修改 `.well-known` 檔案，導致驗證失敗。
網域駭客	網域駭客可能會向未經授權的方公開相關網域資料。	如這個 Protected Audience GitHub 問題所述，您無法採取這種做法。

Fenced Frames API

意見回饋主題	摘要	Chrome 回應
內容違規	允許使用者檢舉可疑的廣告。	有 Fenced Frames 而無法發送可疑廣告回報。使用者仍可與廣告互動，並照常向廣告技術檢舉可疑廣告。
與周遭網站的互動	允許與周圍或頂層網站互動。	我們想瞭解這項要求有必要的原因，也歡迎生態系統提供意見。
原生廣告	適用於原生廣告的 Fenced Frame 支援。	我們正在考慮支援這種做法，並討論可能的解決方法和解決方案。

Shared Storage API

意見回饋主題	摘要	Chrome 回應
跨網域	允許跨網域通訊，以便儲存本機儲存空間。	此使用案例目前與 Shared Storage 的隱私權保護輸出閘不符，但在我們針對非分區儲存空間提案改進提案時，歡迎提供其他背景資訊。
Blob 網址	要求支援共用儲存空間中的 Blob 網址。	Chrome M116 新增了對 Blob 網址的支援。

方塊