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

2023 年第 1 季季度報告，摘要說明收到的 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、FLEDGE 和 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 API 在測試開始前未完成，測試是否仍適用於 CMA 的評估 Privacy Sandbox API 的開發進度正在快速推進。這些功能已在 Origin Trial 中開放測試，並將於今年夏天全面開放給 100% 的流量使用。

此外，我們已明確說明某些功能 (例如 FLEDGE 事件層級報表、使用 iframe 顯示 FLEDGE) 的時間表，這些功能不會在 2026 年前受到影響。

我們鼓勵生態系統測試 API，並根據測試人員在第三方 Cookie 淘汰後預期會依賴的項目，向 CMA 提供意見回饋。這有助於他們評估第三方 Cookie 淘汰後可能帶來的影響。
使用者控制項 向生態系統提供關於 Privacy Sandbox API 使用者控制項影響的明確指引 我們無法就生態系統可使用的使用者控制項提供法律建議。同時，Chrome 也正在實驗向極少數使用者顯示更新版 Privacy Sandbox 功能 (「強化廣告隱私權」) 的使用者控制項，這是我們持續改善 Privacy Sandbox 技術的一部分。更新內容包括更清楚、更實用的用語和版面配置。一旦 Chrome 評估這些精進項目，並決定是否要擴大範圍，就能與生態系統分享更多資訊。
資料外洩 在瀏覽器遭到入侵的情況下，第一方資料外洩至 Google 和其他方的風險 我們的 FLEDGE 說明文件清楚說明，廣告技術供應商只會將資料分享給同一個廣告技術供應商 (透過其 worklet 或可信任的伺服器)，或是由該廣告技術供應商明確分享 (例如買家向賣方顯示要顯示的廣告網址)。唯一例外狀況是，k 匿名檢查必須由全球集中式伺服器執行，而我們會持續投入大量資源於此領域。如要進一步瞭解我們對隱私權的看法，請參閱K 匿名性說明文件。

此外，我們也樂意進一步說明 k-anonymity 伺服器設計中採用的廣告技術保護機制如何運作。
其他討論區 要求 W3C 提供額外論壇，讓非技術生態系統參與者分享意見 Privacy Sandbox 意見回饋表單適合用於一般和具體意見、技術和非技術意見。
「改善網路廣告業務群組」是透過每週電話會議和 GitHub 存放區進行討論的論壇。
Privacy Sandbox 的「意見回饋」頁面說明瞭其他提供意見回饋和參與討論的機制。Chrome 也持續舉辦公開諮詢時間等活動，方便使用者提問並分享內容。此外，Chrome 在過去一個季度也舉辦或參加了十多場業界活動。
時間軸說明 澄清 2023 年第 3 季正式發布的確切日期 根據 PrivacySandbox.com 發布的時間表，我們預計在 Chrome 115 版發布時開始推出一般版。
reCAPTCHA Sandbox API 對 reCAPTCHA 垃圾訊息偵測用途的影響 我們會定期向 reCAPTCHA 取得意見回饋，確保 Privacy Sandbox 提案不會對網路安全或詐欺行為造成重大影響。他們正在擬定因應第三方 Cookie 淘汰後的計畫，並調整相關事宜，因此最適合回答這個問題。
Chrome 擴充功能 隱私權保護技術 (例如反隱密追蹤) 是否適用於 Chrome 擴充功能？ 我們尚未宣布 ACT 是否適用於 Chrome 擴充功能。不過，如果某項技術會秘密收集使用者資訊，就違反了我們的隱私權原則。

顯示相關內容和廣告

主題

意見回饋主題 摘要 Chrome 回應
TAG 設計審查 TAG 發布了 Topics 的早期設計審查。 我們仍致力於開發 Topics，並在最新消息頁面和本期內容中分享相關進展。我們回覆 TAG 審查結果，並在這裡分享更高層級的願景。Topics API 仍會是廣告生態系統在 2023 年應測試的 API 集合之一。我們希望聽到的測試意見和獲得的導入經驗，能為未來在這個領域推動跨瀏覽器標準的努力做出寶貴貢獻。我們期待持續與生態系統互動，瞭解如何在 Topics API 成為跨瀏覽器相容性的標準後，協助開發人員順利轉換。
主題處理方式 支援 Chrome 開發 Topics API 的開放式做法 我們感謝您提供意見，也期待能繼續與業界團隊合作，開發可為整體生態系統提供價值的 Topics API。
(2022 年第 3 季也有人回報)
主題分類不夠細緻		 廣泛主題分類不包含更精細的主題，包括特定地區的主題。 第 1 季更新：

我們會持續改善分類系統，並在第 2 季宣布 Topics API 的分類系統更新。為了建立這項新分類法，我們與生態系統中的各家公司密切合作。
我們正積極收集意見，瞭解哪些分類法對生態系統最有幫助。評估是否要擴大主題數量或納入更細緻的主題時，請考量以下幾點：1) 可能的隱私權影響 (主題越多，指紋辨識風險就越高)，以及 2) 能否擷取先前觀察到的主題 (例如，主題越多，廣告技術可能就越少在過去看到所選主題)。
(也於 2022 年第 4 季回報)
對第一方信號的影響		 主題信號可能非常有價值，因此會降低其他第一方興趣信號的價值。 我們認為按照興趣顯示廣告是網路上的重要用途，而 Topics 就是為了支援這種用途而設計。我們瞭解，部分大型發布商擔心「主題」會對其第一方資料策略造成負面影響。我們期待進行生態系統測試，以便深入瞭解「Topics」對發布商的影響。
非廣告相關的 Topics 用途 將主題用於顯示興趣廣告以外的用途 Topics 旨在解決按照興趣顯示廣告的用途，我們認為這是免費開放式網際網路的重要用途。我們目前正在尋求其他使用情境的意見回饋，並進行評估。
預設的選擇加入狀態 地區法規對主題同意聲明預設值的影響 我們無法對法律意見發表評論。
(2022 年第 3 季也曾回報)
分類錯誤的網站		 指定主題時，某個網站的主題被錯誤分類 第 1 季更新：
我們將在第 2 季宣布 Topics API 的更新分類器，並期待與生態系統合作。
為了回應目前的意見回饋，我們會結合人工編排的覆寫清單 (包含最熱門網站) 和裝置端機器學習模型，對網站進行分類。Chrome 會持續評估網站提供主題分類的選項。任何實用性改善措施都必須權衡隱私權和濫用風險。舉例來說，其中一些風險包括：網站使用自訂標籤，將不同的 (可能含有敏感內容) 意思編碼為主題；網站為了營利而誤導主題；網站攻擊主題，以削弱主題對其他人的實用性 (例如以無意義的垃圾內容攻擊使用者的主題)。一般使用者可以透過 chrome://topics-internals 或這個 Colab 取得工具，檢查這些元件。我們會透過測試改善分類方式，並歡迎提供意見回饋，指出可能分類錯誤的網站。
主題分類器 要求在「No Topics」傳回給呼叫端時，傳回額外資訊，說明原因，以利偵錯 我們瞭解並感謝開發人員在將 Topics API 整合至系統時，能夠使用偵錯工具。不過，如果我們公開額外資訊 (例如未傳回任何主題的原因)，可能會不小心分享資訊，讓各方得以揭露額外詳細資料 (例如使用者是否處於無痕模式、已停用 API 等等)，進而侵害使用者隱私。我們目前不打算提供其他偵錯工具，但歡迎您提供寶貴意見，讓我們瞭解哪些工具最有價值。
擷取私人資訊 要求 Topics API 採用私人資訊擷取功能 我們先前曾研究使用 PIR，並在這裡分享取捨之處。
出價串流 在出價串流中，主題是否會與賣方定義目標對象有所區隔？ Topics API 是 Chrome 開發的 Privacy Sandbox 提案，與 IAB Tech Lab 的「Seller-Defined Audiences」提案不同。我們希望這兩者在出價串流中能清楚呈現。瞭解主題如何在 OpenRTB 出價要求中顯示。

Protected Audience API (舊稱 FLEDGE)

意見回饋主題 摘要 Chrome 回應
FLEDGE 功能適用情況 針對 FLEDGE 功能 (例如 Fenced Frame 強制執行、K-Anonymity 等) 的測試和導入時間表進行說明。 我們已分享狀態，說明各種 FLEDGE 功能的範圍，以及何時會支援這些功能。我們會持續開發 FLEDGE，歡迎您針對這項公告提供更多意見。
產品轉譯限制 要求放寬 FLEDGE 圍欄框架的「由多個部分組成的廣告」限制 如同我們在2 月宣布，至少到 2026 年為止，使用者仍可選擇是否使用 Fenced Frames，而 urn-iframes 會支援 iframe 行為。歡迎進一步討論這個主題。
可擴充性問題 隨著使用量擴大，FLEDGE 效能也隨之提升 我們正在積極追蹤意見回饋並瞭解更多背景資訊，以便提出可行的解決方案。第一步是將意見回饋分為兩類，我們做了以下分類：
  1. 透過賣方平台驅動的篩選功能，針對 a) 賣方平台和 b) 需求端平台，改善每秒查詢次數 (QPS) 的負載。
  2. 興趣群組 DailyUpdate 邏輯，可改善 DSP 的 QPS 負載。
(也於 2022 年第 3 季回報)
出價邏輯的可見度		 擔心 DSP 出價邏輯會在 JavaScript 中公開 第 1 季更新：

我們分享了一項提案，可限制敵對方以探索性 (強制瀏覽) 方式從伺服器要求資料，歡迎生態系統參與者分享對這項提案的意見回饋或支持。
測試困難 讓較小的 DSP 能夠正確測試 FLEDGE，並降低廣告客戶只想透過大型 DSP 進行測試的風險 我們致力於與較小的 DSP 合作，並在 FLEDGE 全面推出後，強烈鼓勵 DSP 和各種規模的廣告客戶擴大測試範圍。我們很想知道如何協助他們與生態系統中的其他人一起測試 FLEDGE，也歡迎您提供想法和業界努力，以激勵廣告客戶與較小的 DSP 進行測試。
動態再行銷 在淘汰第三方 Cookie 後，是否仍可使用 FLEDGE 進行動態再行銷？ 我們正在考慮如何回覆這個問題，歡迎生態系統參與者分享他們打算如何使用動態再行銷功能的其他洞察資料。
詐欺/濫用 生態系統如何降低風險，並阻止惡意人士或買方將自己定位為理想的目標對象？ 我們期待與生態系統參與者進一步合作，共同打擊詐欺和濫用行為，也歡迎您提供更多意見。
使用者偏好設定 儲存使用者偏好設定並用於廣告選擇的程序 針對特定廣告，相關廣告技術是最佳的控管方，可提供哪些廣告素材會顯示或如何選取廣告素材的控制項。
定量測試提案 為了讓定量測試公平進行，您是否應該針對不使用第三方 Cookie 的流量，或只使用 FLEDGE 的 SSP 進行測試？如何避免混淆來自第三方 Cookie 的信號？ 我們感謝這項意見回饋，並與 CMA 合作設計實驗，以便提供可靠的圖表，說明第三方 Cookie 淘汰和 Privacy Sandbox 提案對生態系統的影響。歡迎直接向 CMA 提供更多意見，針對 CMA 提出的定量測試提案提出意見。
更清楚的說明文件 要求提供更清楚的競價設定說明 我們希望在未來幾週內發布一篇部落格文章，進一步介紹 FLEDGE 競價報表。
平行處理 出價和競價 (B&A) 服務是否支援並行化？ 使用出價 / 競價伺服器的廣告技術可啟動多個伺服器，並以並行方式提供結果。
因應濫用行為 使用私密狀態權杖的 FLEDGE k-匿名性伺服器，是否足以確保使用者隱私權？ 導入 k-anonymity 的動機並非著重於微型客層指定，而是在 FLEDGE 允許事件層級報表的過渡期中，提供一些備用機制。我們已分享更多想法，並歡迎提供更多意見回饋。
ES 模組衝突 要求將 generateBid 從全域函式中移除，因為它與 ES 模組發生衝突 我們正在討論這項要求，也歡迎您提供更多意見。
元件競價 要求發布商能進一步掌控競價設計 出價和競價方案，以支援元件競價，與裝置上的 Chrome 相同。
B&A 時間軸 針對有意測試 B&A 伺服器的廣告技術人員，明確說明時間表 我們剛更新了 B&A 說明，並更新時間表章節，在與 CMA 保持一致後，為 Chrome B&A 測試的不同階段提供明確的時間表定義。
逾時控制配置 改善目前可供 FLEDGE 使用的逾時控制方案 這是個有趣的提案。我們會將這項功能加入待研究的提案佇列，並回報相關進展。
廣告素材出價串流 能夠根據廣告素材查看及篩選得標出價 這是個有趣的提案。我們會將這項功能加入待研究的提案佇列，並回報相關進展。
reportWin 提案：針對 reportWin 函式中勝出的興趣群組擁有者，提供其他勝出的興趣群組擁有者最高得分出價的額外資訊 這是個有趣的提案。我們會考慮在匯總報表中加入其他信號，也歡迎在這裡提供更多意見回饋。
事件類型 與 FLEDGE 整合時，在評估 API 中標準化事件類型 這是個有趣的提案。我們會將這項功能加入待研究的提案佇列，並回報相關進展。這項計畫會影響 FLEDGE 以外的其他 Privacy Sandbox API，因此需要與我們在這個領域的其他努力進行協調。歡迎在此提供更多意見回饋。
事件層級報表的長期解決方案 即使在第三方 Cookie 淘汰後，仍想保留 highestScoringOtherBid 等特定資料 如同我們在2 月的部落格文章中所述，事件層級競價得標報表將支援至「至少 2026 年」。我們目前沒有其他詳細資訊可提供，但歡迎您提供更多意見，說明為何在淘汰第三方 Cookie 後，仍需保留特定資料。
興趣群組限制 來源可以將單一瀏覽器加入的興趣群組數量有何限制？ Chrome 允許每位擁有者最多建立 1,000 個興趣群組，最多有 1,000 位興趣群組擁有者。這些值是用來做為防護措施，在正常運作時不應觸及。
事件層級信號 支援提案，為 generateBid 和 reportWin 提供事件層級信號，可用於機器學習訓練 我們已在此處說明瀏覽器設計信號和廣告技術定義信號的決定，並歡迎您提供更多意見回饋。
出價指令碼 在出價指令碼的網址中加入使用者 ID。 這不可能，因為 FLEDGE 有額外規定，興趣群組擁有者、出價指令碼網址和算繪廣告素材的元組必須是 k 匿名，廣告才能顯示。
K-anon 違規處置 是否對 (componentAd, size) 組合強制執行 k-anonymity？ 是的，請參閱 turtledove/issues/312。
出價和競價服務相關規定 B&A 服務如何支援參與者與裝置端 FLEDGE 和其他 B&A 服務整合？ 我們仍在完成設計，歡迎在這裡提供更多意見回饋。
瀏覽後歸因 是否支援瀏覽後歸因？ 目前我們沒有任何標準的可視度定義，而是依靠廣告素材本身來標記觀看事件。請參閱 turtledove/issues/452。
類似指定目標 Privacy Sandbox 是否支援「相似目標對象指定」？ 我們正在討論這裡的使用情境，歡迎提供更多意見。
即時監控 API 即時 FLEDGE 監控方法提案 我們正在討論這項提案，並歡迎您在此提供更多意見。
FLEDGE 報表 reportWin 和 reportResult 應以隨機順序產生，以免報表過多或不足。 reportResult() 必須先由賣方執行，再由買方執行 reportWin()，這樣才能將 reportResult() 中的賣方信號納入 reportWin()。詳情請參閱說明文件。
自訂鍵/值 (K/V) 伺服器 日後是否會支援自訂 K/V 伺服器？ 我們正在討論這個問題，歡迎提供任何其他意見。
頂層競價 是否必須是廣告伺服器才能執行頂層競價機制？ FLEDGE API 並未指定哪一方必須呼叫該 API，FLEDGE 的設計中也沒有這方面的要求。任何人都可以執行 FLEDGE 競價 (包括多賣方競價)。如 2022 年第 4 季報告所述，FLEDGE 允許每位發布商選擇競價結構，包括選擇頂層和元件賣家。
API 範圍 FLEDGE 是否會使用第一方資料？ 我們將在 2023 年第 2 季發布內容，說明第一方資料確實可與 FLEDGE 搭配使用，用於 1) 做為邏輯來判斷興趣群組成員資格，以及 2) 做為使用者出價信號，用於後續出價邏輯產生作業。
跨網域興趣群組 建立跨網域興趣群組的可能性 將瀏覽器加入興趣群組時，可使用任何可用資訊來提供給該目標對象。第三方 Cookie 逐步淘汰後，跨網站資料可用性將受到限制，無法用於建立興趣群組。
用戶端出價邏輯 將現有的伺服器端出價邏輯移植至用戶端 我們想進一步瞭解號碼轉移程序中哪些領域有挑戰或缺陷，並歡迎您提供任何額外的意見回饋或洞察。
K/V 伺服器值 K/V 伺服器值是否必須是字串類型？ 值必須是字串，但可以將物件儲存在 JSON 或通訊協定緩衝區中，並將其序列化為字串。
廣告主封鎖清單 哪些信號適合提供給買方，用於廣告主封鎖清單？ 適當的位置是 auctionSignals 或 perBuyerSignals。
出價單位 支援不同的出價單位，例如 CPI 和 CPM 我們想進一步瞭解，在現行設計下為何需要這項功能，也歡迎提供其他意見回饋。
競價邏輯 是瀏覽器還是廣告伺服器決定競價勝出者？ 所有獲勝者選拔作業都會在沙箱中執行，且所有決策都由賣家的程式碼做出。瀏覽器只提供封閉的私人環境，讓買方和賣方程式碼在其中執行。
Permissions-Policy 來源試用結束後，目前的 FLEDGE 權限政策是否會繼續強制執行？ 在 Origin Trial 中，這兩項功能目前的預設許可清單是暫時性的，將會變更。我們想瞭解廣告技術人員需要多久的時間來準備變更，才能開始強制執行。
信號大小限制 信任出價信號要求會在具有相同 trustedBiddingSignalsUrl 的多個興趣群組中合併；2 MB 的大小限制是限制條件。 裝置端呼叫端存在限制，以免裝置上的資源過多。B&A 伺服器的呼叫端會採用較寬鬆的限制。
回報信號 新增額外信號「script-errors」，以便擷取每個興趣群組擁有者和每個 computeBid 或 reportWin / reportResult 的用戶端錯誤數。 我們正在考慮這項提案的隱私權疑慮，歡迎生態系統參與者分享更多相關洞察，說明為何需要這項功能。
K-Anon 視窗大小 將 K-Anon 時間範圍從目前的 7 天上限提高。 我們正在考慮這項功能，目前也期待收到生態系統的額外意見回饋。
裝置成效 如果使用者屬於大量興趣群組，FLEDGE 會如何處理裝置效能？ FLEDGE 在 SSP 和 DSP 中提供多種逾時、優先順序和限制選項，讓廣告技術人員在裝置效能可能會導致裝置加入大量興趣群組而限制參與競價時，能精細控管相關情況。
B&A 服務測試 要求生態系統玩家在測試階段使用自己的伺服器，以便取得更多可用於偵錯的記錄 B&A 可讓使用者透過核准的雲端服務供應商啟動及調整伺服器。為了維護使用者隱私，我們會強制執行受信任的執行環境 (TEE)。我們即將發布有關 B&A TEE 偵錯的說明，並正在開發相關功能。我們正在尋求更多意見回饋。
法規要求 FLEDGE 是否會與不同國家/地區的雲端服務供應商合作，以便遵守當地法規要求？ 我們隨時歡迎其他雲端服務供應商提出建議，但目前我們至少計畫在第三方 Cookie 淘汰後，支援 GCP 和 AWS。詳情請參閱這篇說明文章。

評估數位廣告成效

歸因報表 (和其他 API)

意見回饋主題 摘要 Chrome 回應
噪音影響資料分析 如何針對雜訊的影響進行資料分析的指引 我們已提供其他文件，說明雜訊和設計決策，以及如何利用這些決策來改變雜訊對廣告技術資料的影響。

您也可以參閱更詳細的指南。
空值回報 明確說明如何實作空值報表 我們目前正在擬定實作空值報表的提案，並會盡快提供更多詳細資訊。導入空報表後，我們就能在不犧牲隱私權的情況下，減少報表延遲。
吵雜程度 根據歸因時間長度調整噪音等級 我們樂見這項提案，並正在考慮將其納入規格。歡迎在這裡提供更多意見。
觸發資料大小 為什麼觸發事件資料大小上限為 3 位元？ 大小限制為 3 位元和 8 個不同值，以確保使用者跨網站/情境資訊的數量受到限制。歡迎生態系統參與者提供意見回饋，針對目前事件層級報表的參數化是否合理提出看法。
事件層級報表觸發條件 允許在簡化鍵中設定優先順序 我們正在尋找解決方案，歡迎提供更多意見。
偵錯支援 第三方 Cookie 淘汰後的偵錯功能說明 我們希望在淘汰第三方 Cookie 後提供偵錯功能，並正在考慮相關選項。我們希望能收到更多意見回饋和想法。
點閱後轉換替代方案 請提供更多關於點閱後轉換替代方案的指引 我們鼓勵生態系統使用 Attribution Reporting API 做為適用的轉換評估用途，建立可靠的私人評估系統。其他替代方案也存在，廣告技術供應商需要根據自身的隱私權和實用性需求，決定適當的解決方案。
帳單用途 明確說明 Attribution Reporting 將支援哪些以轉換為準的結帳用途 我們正著手公開發布，以便釐清 Attribution Reporting API 的結帳範圍。最初，Attribution Reporting API 的範圍並未直接支援單次動作出價結帳；但它支援單次點擊和千次曝光出價結帳，這是大多數廣告技術使用的結帳結構。
如果有更多生態系統意見回饋，我們日後可能會支援這項功能。
用途支援 成效評估 API 的用途說明文件 我們正在努力釐清所有 Privacy Sandbox 報表途徑的說明文件。
點擊品質 要求新增信號，以區分廣告的蓄意和非蓄意點擊 我們正在討論這項要求，歡迎提供更多意見。
成效評估解決方案 支援多個 DSP 中的成效評估解決方案 評估服務供應商可以使用 Attribution Reporting API，在多個 DSP 之間進行去重。此外，我們建議在 attributionsrc 中支援網址清單，方便需求端平台支援評估供應商 Attribution Reporting API 要求。歡迎針對上述提案提供其他意見。
事件層級報表 要求在報告直接傳送前，先提供幾天的時間 廣告技術人員已可使用目前可用的資訊來計算這項要求。我們尚未收到任何其他生態系統對這項要求的意見回饋，但歡迎提供意見。
source_registration_time 在事件層級歸因報表中新增 source_registration_time。 我們正在考慮這項要求，歡迎提供更多意見回饋，說明生態系統玩家是否認為這項功能實用。
無痕模式 使用者在無痕模式下是否可使用評估解決方案？ 否，使用者在無痕模式下無法使用成效評估解決方案。無痕模式預設會關閉第三方 Cookie。
資料無塵室 Measurement API 是否與資料無塵室相容？ 一般來說，資料無塵室是一種環境，可將來自不同來源的個別 ID 資料上傳至資料庫，並根據合併的基礎資料執行分析。Privacy Sandbox API 的兩個評估架構分別是事件層級報表和摘要報表。事件層級報表確實包含廣告技術提供的事件 ID，可用於資料淨室，但相關的轉換資訊會受到限制且雜訊較多。加密的可匯總報表無法直接用於清潔的聊天室，但匯總服務提供的摘要結果可做為您執行分析的輸入內容，或用作輔助資訊。

匯總服務

意見回饋主題 摘要 Chrome 回應
(2022 年第 4 季也已回報)
回報延遲		 報表的預估延遲時間為何？ 2023 年第 1 季更新：

根據合作夥伴的意見回饋，我們提出了減少延遲 和減輕延遲影響的建議。

在 WICG 通話期間，廣告技術人員都已支持這兩項提案。
禁止重複規則 如果已處理具有相同共用 ID 的匯總報表，您如何處理「延遲匯總報表」？ 我們已分享一項提案，針對匯總報告的共用資訊和匯總服務的共用 ID 定義，新增額外的報表延遲時間，以部分解決延遲損失對匯總 API 的影響。歡迎您針對這項提案提供任何意見。
資料處理 要求使用隱私預算，在尊重差異化隱私的情況下，支援多次傳送資料 我們正在討論是否可以使用更靈活的方式使用隱私權預算，以便支援這項用途，也歡迎您提供更多意見回饋。
(也於 2022 年第 2 季回報) 查詢人體工學 啟用查詢鍵值的匯總功能。 2023 年第 1 季更新：

我們仍在評估這項功能要求，但目前沒有任何可分享的提案。
來源試用功能限制 釐清匯總服務的範圍，例如目前未在來源測試中套用的「不重複規則」。 我們正在更新說明文件，以便說明來源試用版和 GA 版的差異。

私密匯總 API

意見回饋主題 摘要 Chrome 回應
私密匯總貢獻預算 L1 貢獻預算過於嚴格。 每個 Private Aggregation API 呼叫都稱為貢獻。為保護使用者隱私，我們限制了可從個人收集的貢獻內容數量。
當您將所有匯總鍵的所有可匯總值加總時，加總值必須低於貢獻預算。

根據目前的設計，我們會針對特定報表來源在過去約 24 小時內 (以滾動式視窗計算) 的貢獻設定限制。也就是意見回饋中提到的 L1 貢獻預算。我們建議開發人員根據預期的音量來調整提供的值 (也就是不要只使用 1 的值)。因此，建議您針對較常見的事件使用較小的值，以免用盡預算。

我們目前正在尋求 Private Aggregation API 的貢獻預算的數值限制和範圍的意見回饋。我們正在考慮將範圍從個別來源移至個別網站，並將現有上限移至十分鐘的時間範圍，並提供更大的每日上限。

限制隱密追蹤

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

意見回饋主題 摘要 Chrome 回應
採用通用分析 (分析) 在英國的 10,000 個熱門網站中，只有 1% 使用程式輔助廣告的網站會傳送 HTTP 用戶端提示。未遷移的 DSP 可能會影響防詐功能。 在對相同資料集執行分析後，我們發現如果您使用 HTML <meta> 標記和 JavaScript API 來計算使用 UA-CH 的網站數量，使用 UA-CH 的網站數量會遠高於您在意見回饋中提供的 1% 數字。基於這項資訊和其他事實 (包括生態系統的意見回饋)，我們有信心按照已發布的時間表，逐步推出第 6 階段的使用者代理程式減少計畫，同時持續向 CMA 提供相關資訊。請注意，網站有將近兩年的時間來準備轉換，如果網站認為自己尚未準備好，仍可使用淘汰試用版。
其他板型規格的提示 要求 UA-CH 提供其他板型規格，例如電視、VR 我們樂見這項提案，並正在評估是否將其納入設計。歡迎提供其他意見回饋。
自動化測試 在 UAR 第 6 階段發布前，要求解決無頭 Chrome 中的 UA-CH 錯誤 問題中的錯誤已修正。
iOS 上的 UA-CH 支援 某個網站需要精細的通用 Analytics 資訊來放送廣告，但該網站指出 iOS 版 Chrome 不支援這類用途。 針對非 Safari iOS 瀏覽器 (包括 iOS 版 Chrome)，WebKit 專案必須先新增對 UA-CH 的支援，才能啟用這項功能 (因為它們會控制網路堆疊)。

IP 保護 (原稱 Gnatcatcher)

意見回饋主題 摘要 Chrome 回應
(第 4 季度也曾提及) 地理位置用途 IP 保護功能可能會導致合法的地理位置用途無法在日後運作，例如根據地理位置提供個人化內容。 我們的回覆與 2022 年第 4 季相同：

「我們正與利害關係人合作，確保 Chrome 持續支援 IP 位址的正當用途。我們正在尋求有關 IP 地理位置精細程度的生態系統意見回饋。
監管法規遵循 如果某個區域的人口低於 100 萬，IP 保護的現有門檻 (100 萬) 就會阻止網站使用 IP 位址來遵守法規。 我們正與利益相關者合作，確保 Chrome 持續支援 IP 位址的正當用途。我們希望能獲得生態系統對智慧財產保護法規遵循相關事宜的意見回饋。
因應濫用行為 當事人可以將未遮蓋的 IP 位址分享給其他人，藉此規避 IP 保護功能。 我們瞭解目前的 IP 保護提案在技術上可能無法防止各方與他人分享未遮蓋的 IP 位址，我們正在研究如何減輕這類濫用風險。

我們會持續改良提案，歡迎提供更多意見回饋和討論。具體來說，我們想瞭解各方認為需要與其他人分享未遮蔽 IP 位址的任何用途。
網路封鎖 使用者可以透過 IP 保護 Proxy 規避網路封鎖。 執行封鎖作業的實體必須為此情況停用 IP 保護功能。我們已回覆問題，也歡迎您提供更多意見。
受 IP 保護提案影響的 IP 位址封鎖清單 許多廣告技術公司會使用 IP 位址的基本封鎖清單 (例如 TAG 資料中心 IP 位址清單)，避免對極有可能涉及詐欺 (或至少無法營利) 的廣告空間出價。如果廣告技術也是追蹤器，且可能受 IP 保護提案規範，該公司可能會失去在購買廣告空間前，對廣告執行基本檢查的功能。 我們鼓勵您針對智慧財產權保護提案的潛在問題和解決方案，提供更多意見回饋和討論。其中一個選項是將類似的清單套用至 IP 保護功能，這樣我們就不會為來自先前標記 IP 位址的用戶端建立 Proxy。

強化跨網站隱私界線

第一方集合

意見回饋主題 摘要 Chrome 回應
(也於第 4 季回報) 網域限制 要求擴充相關網域數量 我們的回應與 2022 年第 4 季相同：

「我們在 WICG 通話中已說明，Chrome 致力於提供可用的解決方案，同時也考量使用者的隱私權。因此，我們樂見社群針對可能受到網域限制的特定用途提供意見回饋，以便團隊能考量如何處理這些用途，同時繼續保護使用者隱私。」
替代 FPS 提交 提案：FPS 全球名單的其他提交方式 目前，我們正準備在 Chrome 中推出第一方集合 (FPS)，並已設定集中式 GitHub 存放區來接受集合提交內容。我們希望 FPS 能填補現有網站平台解決方案的缺口，為第三方 Cookie 淘汰做準備，因此希望能從他們身上瞭解網站作者如何運用 FPS。隨著套裝組合清單逐漸增加，生態系統也將適應第三方 Cookie 淘汰後的世界，我們也能將這項程序完善，以便考慮其他去中心化方案，例如我們提出的方案。我們預計在現行程序中設定生命週期，以便隨著時間推移改進收件程序。提交程序成熟後，我們可以重新考慮這個想法。
存放區管理 實施 FPS 提交存放區的社群審核機制，以防濫用。惡意人士很容易利用臨時帳號來源提出集合要求，導致程序不堪負荷，而大量要求可能會影響真實集合提案的作業。 我們會依據技術驗證檢查，盡可能讓檢查結果保持客觀。我們認為這是提交程序最具擴充性的做法。為了達成這個目標，我們也會盡力確保這個程序能抵禦垃圾內容 / 匿名帳戶提交的內容。
相關聯的子集 FPS 是否能透過關聯子集支援第三方供應商/SaaS 流程用途？ 第三方供應商 / SaaS 流程並非目前 First-Party Sets 範圍內的用途。歡迎您針對這些用途提供更多意見回饋，說明如何使用跨網站 Cookie。
FPS + CHIPS 整合 要求整合 FPS 和 CHIPS，以便支援 A/B 測試等用途 我們正在討論這個用途，也考慮在 WICG 通話中進一步討論這個問題，歡迎在此提供額外意見。
GDPR 根據 GDPR 概念建立新的 FPS 子集的提案 我們已在內部討論這項提案，並將其與收到的其他意見回饋以及我們的隱私權目標進行比較。我們已提供答案，說明為何我們目前不會採用這項提案。
記憶體 納入 FPS 清單時，瀏覽器記憶體大小的預期變化 瀏覽器先前曾經有過類似的清單儲存方式，且對記憶體的影響降到最低，例如 Disconnect 追蹤保護清單。雖然 First-party Sets 清單會複製到每個 Chrome 用戶端的本機，但我們會持續監控檔案大小，並確保能最佳化記憶體占用空間。

Fenced Frames API

意見回饋主題 摘要 Chrome 回應
圍欄頁框限制 清楚說明 Fenced Frames 的限制 我們在 3 月更新了關於圍欄框架的說明文件，提供有關其功能的資訊，歡迎您提供任何額外意見回饋。
展開存取資訊 要求擴大鄰近影格周圍資訊的存取權 我們希望進一步瞭解為何這是生態系統的要求，也歡迎提供其他意見回饋。
圍欄頁框和 iframe 關於 Fenced Frames 和 iframe 之間功能相容性的問題 所有可用的 Privacy Sandbox API 和報表都會以相同方式提供給 iframe 和 FencedFrames。
重新調整圍欄頁框大小 限制影格大小變更會影響特定用途。 我們很想進一步瞭解受限制影響的使用情境類型，也歡迎您提供更多意見回饋。

Shared Storage API

意見回饋主題 摘要 Chrome 回應
第三方工作區 第三方是否可以寫入以來源分區的 Shared Storage？或呼叫其他用於第三方評估的 worklet？ 執行程式碼的瀏覽內容來源會決定資料寫入哪個共用儲存空間。當第三方程式碼加入頁面時，第三方程式碼可做為 iframe 嵌入，並使用其自身的瀏覽內容，讓第三方程式碼寫入自身的來源。第三方程式碼也可以做為指令碼嵌入，而非 iframe，這樣不會切換瀏覽內容，而且第三方可以寫入嵌入者的共用儲存空間。請注意，只有共用儲存空間的擁有者才能讀取該共用儲存空間。
簡化資料 對於 Chrome 生態系統以外的互動，無法進行去重作業。 共用儲存空間旨在提供 Chrome 瀏覽器在 Chrome 內的獨特觸及範圍輸出。我們希望與廣告技術合作，瞭解如何將這些輸出內容用於更廣泛的觸及範圍模型。我們瞭解輸出內容本身可能只占互動量的一小部分，因此有意與廣告技術合作，探索可疊加的其他建模方法。
轉換回溯期 要求提供轉換回溯期，以便查看轉換隨時間變化的情形 您可以使用共用儲存空間，在用戶端處理各種轉換路徑，藉此實作這項功能，這樣一來，您就能透過安全的未分割瀏覽器儲存空間，享有更彈性的進階分析功能。
商品到期日 要求將到期日延長至 90 天 資料保留政策已於 2022 年 11 月更新，並指出每個鍵會在上次寫入後的三十天後清除。歡迎提供更多意見回饋，協助我們瞭解新政策是否適用於這個生態系統。
廣告素材輪播 廣告素材輪播用途不會反映競價後的實際動作。 我們希望更多買方廣告技術公司提供意見，讓我們瞭解廣告素材輪替說明文件是否正確。

CHIPs

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

FedCM

意見回饋主題 摘要 Chrome 回應
身分斷言端點 明確允許對身分斷言端點提出任意要求。 我們一直與 Mozilla 合作，針對這個提取要求進行合作，以限制網站在未經使用者同意的情況下，私下發出跨來源憑證要求，並繼續審查及處理其他意見回饋。
預先填入身分 FedCM 可否用於預先填入登入表單，並使用 FedCM 清單中的身分提供者？ 這個用途的疑慮在於，如果網站未與使用者互動，卻能查詢使用者最近使用的 IDP，可能會導致資訊外洩。我們正在討論這個問題，歡迎提供更多意見。
內容相關帳戶選取 在帳戶選取 UI 中新增情境信號的提案 我們正在考慮這項提案，並歡迎進一步討論。

打擊垃圾內容和詐欺

Private State Token API (和其他 API)

意見回饋主題 摘要 Chrome 回應
能力收集問卷調查 我們在第 1 季初完成收集問卷調查結果，瞭解各種防詐用途需要哪些功能，並將結果公開分享 (分鐘、 結果) 我們預計在開發新的提案和原型時，納入這項意見回饋，以便針對防詐功能打造專屬的隱私權保護 API。我們會優先開發有充分需求，且可建立在現有技術之上，同時兼顧使用者隱私權的功能。舉例來說，裝置和啟動完整性獲得高分，而且許多平台都有現有的 API，可安全地分享裝置完整性評估，因此在社群群組中進行探索是個不錯的選擇。
出貨意圖的 PST 意見回饋 我們使用較舊版本的 Privacy Pass，因此在意圖發布階段收到了疑慮。我們也收到意見回饋，指出規格在某些部分不夠明確，應加以改善，以利瀏覽器相容性。 我們打算在將應用程式送交 GA 前，實作許多建議的規格變更，以及一些 API 變更。這項意見回饋是在第 1 季結束時收到，因此我們會追蹤 GitHub 問題，並提供具體詳細資料和發布計畫更新 (這份意見回饋報告發布時，我們仍在進行這項作業)。

針對 API 的重大變更，我們會考慮進行調整，但我們認為，最好的做法是繼續推出一般版，並取得更多開發人員的實際意見回饋。我們希望繼續討論這個議題，並追求瀏覽器標準化。如果新標準出現，我們會考慮採用並制定計畫，謹慎過渡至新標準。