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 的 1:1 相關人員會議記錄、個別工程師收到的電子郵件、API 郵寄清單和公開意見回饋表單接著，Google 會和參與這些各種外聯活動的團隊協調，判斷各主題相對於各 API 的相對情況。
我們根據已發布的常見問題、對利害關係人提出問題的實際回應，制定了 Chrome 回應回應的說明，並針對這項公開報告練習制定專屬定位。回顧目前的開發和測試重點，以及有關 Topics、FLEDGE 和 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 回應 |
|---|---|---|
| 測試與試用 | 測試的關聯性，用於告知 CMA 評估作業，如果測試開始時未完成 Privacy Sandbox API 評估 | 正在開發 Privacy Sandbox API。這些 API 目前已可供測試的來源試用，且在今年夏天將開放給 100% 的流量使用。 此外，我們已針對在 2026 年之前不會受到影響的特定功能 (例如 FLEDGE 事件層級報表、使用 iframe 進行 FLEDGE 算繪) 清楚說明，並提供相關說明。 我們鼓勵生態系統測試 API，並根據測試人員在第三方 Cookie 淘汰後預期仰賴的事項，提供意見回饋給 CMA。這有助於他們評估第三方 Cookie 淘汰可能造成的影響。 |
| 使用者控制項 | 對於 Privacy Sandbox API 的使用者控制選項可能造成的影響，明確說明生態系統 | 我們無法針對使用者控制生態系統的可用內容，提供法律建議。同時，Chrome 正嘗試對極少數使用者顯示更新版 Privacy Sandbox (「加強型廣告隱私權」) 使用者控制項，藉此持續改善 Privacy Sandbox 技術。更新內容包括更清晰、更實用的語言和版面配置。Chrome 評估完這些修正內容，並決定是否將其擴大至更廣泛的人口後，便能夠與生態系統分享更多資訊。 |
| 資料外洩 | 如果瀏覽器遭到入侵，第一方資料就會導致 Google 和其他單位的資料外洩 | 我們的 FLEDGE 說明頁面清楚指出，廣告技術的資料僅會與同一廣告技術 (與其工作清單或信任的伺服器共用)，或由該廣告技術明確分享 (例如買家顯示想要顯示的廣告網址) 時。有一個例外是，k-anonymity 檢查必須由全域集中式伺服器完成，而我們持續投入大量資源。請參閱 K-anonymity 說明，瞭解我們如何考量隱私權。 此外，我們也很樂意針對 k-anonymity 伺服器設計中採用的廣告技術保護措施提供詳細資訊。 |
| 其他討論論壇 | 要求向 W3C 提供其他論壇，讓非技術生態系統玩家提供意見回饋 | Privacy Sandbox 意見回饋表單適用於一般評論、技術性和非技術性質。 改善網路廣告業務群組是一個論壇，您可以透過每週呼叫和 GitHub 存放區參與討論。 developer.chrome.com 的 Privacy Sandbox 意見回饋頁面說明其他提供意見回饋和參與討論的機制。此外，Chrome 也會持續保留公開諮詢時間等事件，方便使用者提問和分享內容。此外，Chrome 上一季還舉辦或參加過超過十場產業活動。 |
| 時間軸說明 | 說明預計在 2023 年第 3 季正式發布的確切日期 | 根據 PrivacySandbox.com 上發布的時程，預計從 Chrome 115 版開始推出。 |
| reCAPTCHA | Sandbox API 對 reCATPCHA 垃圾內容偵測用途的影響 | 我們會定期收到 reCAPTCHA 提供的意見回饋，確保 Privacy Sandbox 提案不會對網路安全性或詐欺行為造成顯著影響。他們目前正在製定自己的計畫，為第三方 Cookie 淘汰預做準備和調整，因此他們最適合回答這個問題。 |
| Chrome 擴充功能 | 反耦合追蹤 (ACT) 等 Privacy Sandbox 技術是否適用於 Chrome 擴充功能？ | 對於 ACT 是否適用於 Chrome 擴充功能，目前我們尚未發布任何公告。不過，如果技術會廣泛收集使用者資訊，這種情況就不符合我們的隱私權原則。 |
顯示相關內容和廣告
主題
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| TAG 設計審查 | TAG 發布 Topics 的早期設計審查。 | 我們持續致力於開發 Topics，並在最新更新頁面和這個問題中分享有關 Topics 的最新消息。我們會逐一回應 TAG 審核，並分享這份更高層級的願景。 Topics API 仍會是 Google Ads 生態系統在 2023 年應測試的 API 集合。我們希望聽到這些測試意見回饋及我們獲得的實作體驗，日後致力發展跨瀏覽器標準在這個領域發揮良好成效。我們期待繼續與生態系統互動，瞭解如何簡化 Topics API 的可行性，讓 Topics API 符合跨瀏覽器相容性的協議標準。 |
| Topics 方法 | Chrome 必須開發 Topics API，支援開放式方法 | 我們很重視這樣的情緒，期待能繼續與業界團體合作開發 Topics API，為整個生態系統帶來價值。 |
| (同樣在 2022 年第 3 季皆有報告) 主題分類的精細程度不足 |
廣泛主題分類不包含較精細的主題，包括特定區域。 | 第 1 季更新： 改善分類是我們持續努力的成果，我們會在第 2 季宣布 Topics API 的更新分類。為了建立這個新的分類，我們與生態系統中的公司密切合作。 我們正積極向大環境提供最實用的分類意見回饋。在評估是否要擴大主題數量或納入更精細的主題時，需要考量以下幾點：1) 潛在的隱私權影響 (更多主題可能會帶來數位指紋採集風險)，以及 2) 擷取先前觀察到的主題 (例如建立更多主題時，廣告技術過去可能較不常看到所選主題)。 |
| (另記錄於 2022 年第 4 季) 對第一方信號的影響 |
主題信號可能極具價值，因此會降低其他第一方興趣信號的價值。 | 我們認為按照興趣顯示廣告是網路的重要用途，而 Topics 也能支援這種使用情境。我們瞭解，有些大型發布者擔心 Topics 會對第一方資料策略造成負面影響。我們很期待進行生態系統測試，藉此深入分析 Topics 對發布商的影響。 |
| 與廣告無關的 Topics 使用案例 | 將 Topics 用於顯示按照興趣顯示的廣告以外的用途 | Topics 的用意是因應「按照興趣顯示」的廣告用途，而我們認為這是自由開放的網路環境的重要用途。我們目前正在評估其他用途的相關意見回饋，並正在評估當中。 |
| 預設採用狀態 | Topics 同意聲明預設值會依區域法規影響 | 我們無法對法律意見發表意見。 |
| (同樣在 2022 年第 3 季一併顯示) 分類錯誤的網站 |
指定網站主題分類錯誤的廣告指定目標 | 第 1 季更新： 我們在第 2 季宣布更新 Topics API 的分類器，並期待能與這個生態系統互動。 為回應目前的意見回饋，我們結合了人工收錄的覆寫清單來分類網站，其中含有最受歡迎的網站和裝置端機器學習模型。Chrome 會持續評估網站是否要納入 Topics 分類，所有公用程式的改善都必須權衡隱私權和濫用風險。舉例來說，網站可能會以「自主標籤」形式將不同 (可能敏感) 含意相關主題編碼；網站以牟利為目的而謊報主題；網站藉由攻擊主題為他人激增 (例如濫發無意義的雜訊，濫發垃圾內容)。 大眾可以透過 chrome://topics-internals 或這個 colab 取得工具，檢查這些元件。透過測試，我們期望能隨著時間改善分類功能，也歡迎你針對可能分類錯誤的網站提供意見回饋。 |
| 主題分類器 | 要求傳回其他資訊，顯示「沒有主題」傳回給呼叫端以進行偵錯的原因 | 我們瞭解偵錯工具正致力將 Topics API 整合至自家系統，因此對開發人員很有幫助。然而，公開其他資訊 (例如未傳回 Topics 的原因) 可能會無意間分享資訊，讓各方能進一步掌握其他詳細資料 (例如，使用者處於無痕模式，或已停用 API 等)，進而危害使用者隱私。我們暫時不打算提供其他偵錯工具，但還是歡迎您提供意見，說明哪些工具對您有價值。 |
| 擷取私人資訊 (PIR) | 要求 Topics API 採用私人資訊擷取功能 | 我們先前已使用 PIR 進行調查，並參閱此處的優缺點。 |
| 出價串流 | Topics 在出價串流中是否與賣方定義目標對像不同？ | Topics API 是 Chrome 開發的 Privacy Sandbox 提案，與 IAB Tech Lab 的「Seller-Defined Audiences」 提案不同。我們預期出價串流中會明確表示這兩者。瞭解 Topics 如何在 OpenRTB 出價要求中表示。 |
Protected Audience API (舊稱「FLEDGE」)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| FLEDGE 功能適用情況 | 針對 FLEDGE 功能的測試和實作時程說明，例如 Fenced Frame 強制執行、K-Anonymity 等。 | 我們已分享了一篇網誌文章介紹了各種限定範圍的 FLEDGE 功能及支援的時機。我們會持續開發 FLEDGE，歡迎針對公告提供其他意見回饋。 |
| 產品顯示限制 | 要求放寬 FLEDGE Fenced Frames 多方針限制的廣告 | 如同我們 2 月的公告，在至少 2026 年之前，你還是可以選擇是否要使用 Fenced Frame，且 urn-iframes 將支援 iframe 行為。我們希望您可以進一步討論這個主題。 |
| 擴充性問題 | 根據用量規模調整 FLEDGE 效能 | 我們會積極追蹤創作者的意見回饋並進一步瞭解背景資訊，進而提供可行的解決方案。第一步是將意見回饋分為兩個類別：
|
| (另於 2022 年第 3 季一併報告) 出價邏輯的瀏覽權限 |
瞭解 DSP 出價邏輯會在 JavaScript 中公開 | 第 1 季更新： 我們分享了一項提案，主要是限制有心人士以探索 (強制瀏覽) 的方式從伺服器要求資料。我們也歡迎生態系統玩家分享他們的意見回饋或支持提案。 |
| 測試問題 | 可讓較小的 DSP 正確測試 FLEDGE，並降低廣告客戶只想使用大型 DSP 進行測試的風險 | 我們致力於與較小的 DSP 合作，並強烈建議在 FLEDGE 移至正式發布階段後，進一步在 DSP 和各種大小的廣告客戶之間進行擴大測試。我們想瞭解該如何有效協助該公司與生態系統中的其他人員測試 FLEDGE，並歡迎提供想法和業界的想法，鼓勵廣告客戶透過較小的 DSP 進行測試。 |
| 動態再行銷 | 在第三方 Cookie 淘汰後，FLEDGE 仍可進行動態再行銷嗎？ | 我們正在考慮回答這個問題，也歡迎生態系統業者分享更多深入分析，說明他們打算如何使用動態再行銷。 |
| 詐欺/濫用 | 這個生態系統如何降低風險，並阻止惡意行為人或買家將自己定位為理想的目標對象？ | 我們期待能進一步與生態系統玩家交流互動，瞭解詐欺和濫用行為，也歡迎針對這方面提供意見回饋。 |
| 受使用者喜愛 | 儲存使用者偏好設定並用於廣告選擇的程序 | 針對特定廣告，相關的廣告技術是最適合用來控管顯示廣告素材或選取方式的一方。 |
| 量化測試提案 | 為確保量化測試保持公平，是否應在沒有第三方 Cookie 的流量，或透過僅使用 FLEDGE 的賣方平台執行測試？如何避免混合使用第三方 Cookie 的信號？ | 我們十分重視這項意見回饋，也正與 CMA 合作設計實驗，協助您全面瞭解第三方 Cookie 淘汰作業的影響，以及 Privacy Sandbox 提案對生態系統的影響。我們建議針對 CMA 的量化測試提案提供額外意見回饋，並直接與 CMA 分享。 |
| 說明文件內容更清楚 | 要求提供更清楚的競價設定說明文件 | 我們預計在未來幾週內發布一篇網誌文章，並提供有關 FLEDGE 競價報表的額外總覽。 |
| 平行處理 | 出價和競價 (B&A) 服務是否支援平行處理功能？ | 使用「出價 / 競價」伺服器的廣告技術可以啟動多個可以同時放送結果的伺服器。 |
| 緩解濫用行為 | 使用私人狀態權杖的 FLEDGE k-anonymity 伺服器是否足以保護使用者隱私？ | k-anonymity 的動機較不專注在微指定上，而是著重於在 FLEDGE 提供事件層級報表的過渡階段設定一些反向停止。我們已分享更多想法，也歡迎提供其他意見回饋。 |
| ES 模組衝突 | 要求將 generateBid 捨棄為全域函式，因為該函式與 ES 模組發生衝突 |
我們正在討論這項要求，也歡迎您提供意見。 |
| 組件競價 | 要求發布商進一步控管競價設計 | 支援元件競價的出價和競價計畫，與裝置端 Chrome 相同。 |
| 民宿時間表 | 針對有意測試 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 Services 如何支援與裝置端 FLEDGE 及其他 B&A 服務的參與者整合？ | 我們仍在確認設計階段，歡迎在這裡提供其他意見回饋。 |
| 瀏覽後轉換歸因 | 是否支援瀏覽後轉換歸因？ | 我們目前沒有任何類型的可視度標準定義，而是仰賴廣告素材本身標示觀看事件。請參閱 turtledove/issues/452。 |
| 類似指定目標 | Privacy Sandbox 是否支援「指定類似指定目標」？ | 我們正在討論用途，歡迎提供更多輸入內容。 |
| 即時監控 API | 即時 FLEDGE 監控方法的提案 | 我們正在討論提案內容，並在此歡迎你輸入其他資料。 |
| FLEDGE 報表 | reportWin 和 reportResult 應隨機進行順序，以免過度回報或遭到低估。 |
reportResult() 需要先由賣方執行，才能在 reportWin() 之前執行，這樣賣方信號才能加入 reportWin() 中。reportResult()詳情請參閱相關說明。 |
| 自訂鍵/值 (K/V) 伺服器 | 未來是否會支援自訂 K/V 伺服器？ | 我們正在在這裡討論問題，也歡迎您提供意見。 |
| 頂層競價 | 一定要讓廣告伺服器執行頂層競價機制嗎？ | FLEDGE API 不會指定必須呼叫該方的一方；FLEDGE 的設計中沒有任何規定。任何人都可以執行 FLEDGE 競價 (包括多重賣方競價)。如 2022 年第 4 季報告所述，FLEDGE 可讓每個發布商選擇競價結構，包括選擇頂層和元件賣方的選項。 |
| API 範圍 | FLEDGE 是否打算處理第一方資料？ | 我們將在 2023 年第 2 季發布內容，明確指出第一方資料確實可與 FLEDGE 搭配使用，以便：1) 以邏輯判斷興趣群組成員；以及 2) 以動態饋給做為後續產生出價邏輯的使用者出價信號。 |
| 跨網域興趣群組 | 建立跨網域興趣群組的可能性 | 將瀏覽器加入興趣群組時的任何資訊，都可用來告知目標對象。逐步停用第三方 Cookie 後，系統就無法提供跨網站資料來協助建立興趣群組。 |
| 用戶端出價邏輯 | 將現有的伺服器端出價邏輯移植到用戶端 | 我們期望進一步瞭解哪些方面較難或缺少攜碼轉移程序，也歡迎提供其他意見回饋或深入分析結果。 |
| K/V 伺服器值 | K/V 伺服器值是否為類型字串？ | 此值需要字串，但可以將物件儲存在 JSON 或通訊協定緩衝區中，並將其序列化為字串。 |
| 廣告主封鎖清單 | 哪些信號適合為廣告客戶封鎖清單提供買方？ | 適當位置位於 auctionSignals 或 perBuyerSignals 中。 |
| 出價單位 | 支援不同的出價單元，例如單次安裝出價和千次曝光出價 | 我們希望進一步瞭解為什麼目前的設計需要這麼做，也希望收到其他意見回饋。 |
| 競價邏輯 | 瀏覽器或廣告伺服器會決定競價的勝出者嗎？ | 所有勝出組合都會在沙箱中執行，且所有決定都是由賣方的程式碼所決定。瀏覽器只提供一個密封的私密環境，供買方和賣方程式碼執行。 |
| 權限 -政策 | 來源試用結束後，目前的 FLEDGE 權限政策是否會繼續強制執行？ | 在來源試用中，這兩項功能目前的預設許可清單是暫時性的，之後將變更。Google 想知道廣告技術人員需要花多少時間做好準備，才能落實這項異動。 |
| 信號大小限制 | 系統會將受信任的出價信號要求，與 trustedBiddingSignalsUrl 相同的多個興趣群組相輔相成。2MB 的大小限制是一種限制。 |
裝置端的呼叫端設有此限制，以免裝置的資源過大。B&A 伺服器的呼叫者將擁有更嚴格的限制。 |
| 報表信號 | 新增其他信號「指令碼錯誤」，以擷取每個興趣群組擁有者和每個 computeBid 或 reportWin / reportResult 的用戶端錯誤次數。 |
我們正在思考本提案的潛在隱私權疑慮，並歡迎生態系統玩家分享更多深入分析，說明為何需要這麼做。 |
| K-Anon 視窗大小 | 將 K-Anon 視窗大小提高目前的 7 天上限。 | 這屬於考慮性質，我們目前還在等候生態系統中的其他輸入內容。 |
| 裝置成效 | 如果使用者屬於大量興趣群組，FLEDGE 會如何處理裝置效能？ | FLEDGE 針對賣方平台和需求端平台提供多個逾時、優先順序和限制選項，讓廣告技術人員能精細控管裝置在大量興趣群組時參與競價的情況。 |
| 民宿服務測試 | 要求生態系統玩家在測試階段使用自己的伺服器，以便取得更多用於偵錯的記錄 | B&A 可讓使用者透過核准的雲端服務供應商啟動及調度伺服器。為維護使用者隱私，我們強制必須在受信任的執行環境 (TEE) 中執行執行作業。我們即將推出 B&A TEE 偵錯說明，目前正在開發支援這項功能的功能。我們正在針對這個主題尋求其他意見回饋。 |
| 法規要求 | FLEDGE 是否會與不同國家/地區的雲端服務供應商合作，以符合當地法規要求？ | 我們一直樂意推薦其他雲端服務供應商，但目前我們至少打算在強制執行第三方 Cookie 的淘汰時，支援 GCP 和 AWS。詳情請參閱這份指南。 |
評估數位廣告
Attribution Reporting (和其他 API)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 噪音影響資料分析 | 如何執行資料分析對雜訊的影響的指南 | 我們已分享有關雜訊和設計決策的其他說明文件，這些說明文件可用於變更雜訊對廣告技術資料造成的影響。 您也可以參閱更詳盡的指南。 |
| 空值報表 | 空值報表的導入作業清楚明確 | 我們目前正在研究如何導入空值報表，很快會再分享更多詳情。導入空值報表可讓我們在兼顧隱私的前提下，減少報表延遲。 |
| 噪音水平 | 根據歸屬期長度調整雜訊等級 | 我們歡迎這個提案，也有意將提案納入規格中。歡迎點選這個連結，提供其他意見。 |
| 觸發事件資料大小 | 為什麼觸發事件資料大小上限是 3 位元？ | 大小上限為 3 位元和 8 個不同的值，以確保使用者的相關跨網站/背景資訊有限。我們歡迎生態系統玩家提交意見回饋，說明目前的事件層級報表參數化作業是否合理。 |
| 事件層級報表觸發條件 | 允許在簡化鍵中設定優先順序 | 我們正在探索關於這個問題的解決方案，並歡迎您提供其他意見。 |
| 偵錯支援 | 第三方 Cookie 淘汰後產生的偵錯說明 | 在第三方 Cookie 淘汰後，我們希望能支援偵錯功能，並思考各種選項。我們希望提供其他意見回饋和想法。 |
| 點閱後轉換替代方法 | 取得更多點閱後轉換的替代指引 | 我們鼓勵生態系統使用 Attribution Reporting API，做為適用的轉換評估用途的長期不公開評估系統。還有其他替代做法，廣告技術供應商必須根據他們需要的隱私權和公用程式需求，決定合適的解決方案。 |
| 帳單用途 | Attribution Reporting 將支援以轉換為準帳單使用情境 | 我們正致力於公開發布相關資訊，清楚說明 Attribution Reporting API 的計費範圍。Attribution Reporting API 一開始並未以直接支援單次轉換出價計費的方式，而支援單次點擊出價和千次曝光出價的計費方式，後者是廣告技術人員使用的計費結構。 日後如有其他生態系統意見回饋，我們可能會支援這項功能。 |
| 用途支援 | Measurement API 的用途說明文件 | 我們正在努力釐清所有 Privacy Sandbox 報表介面的說明文件。 |
| 點擊品質 | 要求新增信號來區分廣告意圖和意外點擊 | 我們正在討論這項要求，並歡迎您提供意見。 |
| 成效評估解決方案 | 支援多個需求端平台的成效評估解決方案 | 評估服務供應商可使用 Attribution Reporting API 來簡化多個需求端平台之間的資料。此外，我們也建議支援 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 季最新消息： 我們仍會將這項功能要求列入考量，但目前沒有任何提案可以分享。 |
| 來源試用限制 | 說明匯總服務的範圍，例如目前未在來源試用中套用的「沒有重複規則」。 | 我們正在更新說明文件，以釐清在來源試用與 Google Analytics (分析) 中有哪些功能。 |
Private Aggregation API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 私人匯總貢獻預算 | L1 捐款預算限制過多。 | 每次呼叫 Private Aggregation API 都稱為貢獻。為保護使用者隱私，系統可向個別使用者收集貢獻內容數量有限。 當您將所有匯總鍵的所有可匯總值加總時，總和必須小於貢獻預算。 在目前的設計下，我們會限制特定報表來源在過去 24 小時內 (採滾動式期間) 的貢獻量。這是意見回饋中提及的 L1 貢獻預算。 我們建議開發人員根據預期數量調整他們貢獻的值 (即不要只使用 1 的值)。因此，為較常見的事件設定較小的值可能有助於避免用完預算。 我們目前希望針對 Private Aggregation API 對數字範圍和範圍的貢獻預算提出一些意見回饋。我們正在考慮將範圍從每個來源移至個別網站，並將現有的繫結移至每日上限較高的 10 分鐘時段。 |
限制轉換追蹤
使用者代理程式縮減/使用者代理程式用戶端提示
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| UA-R 採用 | 在英國前 10,000 名網站中，只有 1% 使用程式輔助廣告的網站傳送 HTTP 用戶端提示。尚未遷移的需求端平台可能會影響反詐欺功能。 | 針對相同資料集執行分析後，我們發現如果您透過 HTML <meta> 標記和 JavaScript API 計算 UA-CH 用量，則使用 UA-CH 的網站數量遠高於意見回饋中提供的 1% 數值。根據上述結果及其他資料 (包括生態系統意見回饋)，我們很有信心地進一步推動通用 Analytics (分析) 縮減的第 6 階段，以發布的時程為依據，同時讓 CMA 隨時掌握相關資訊。我們注意到網站有將近兩年的前置時間準備進行移轉，但也有網站還沒做好淘汰試用的準備，可能還是會提供淘汰試用。 |
| 其他板型規格的提示 | 要求 UA-CH 提供電視、VR 等額外的板型規格 | 我們歡迎這個提案，也有意將提案與設計整合。歡迎提出其他意見回饋。 |
| 自動化測試 | 要求在 UAR 第 6 階段出貨前，透過無頭 Chrome 解決 UA-CH 錯誤 | 相關錯誤已修正。 |
| iOS 上的 UA-CH 支援 | 如果網站需要精細的通用 Analytics (分析) 資訊用於廣告用途，請注意，不支援 iOS 版 Chrome。 | 針對非 Safari iOS 瀏覽器 (包括 iOS 上的 Chrome)，WebKit 專案必須新增 UA-CH 的支援，才能啟用 UA-CH (因為他們會控制網路堆疊)。 |
IP 保護 (原稱 Gnatcatcher)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| (同樣在第 4 季一併報告) 地理位置用途 | IP 保護可能會防止合法的地理位置用途日後順利運作，例如根據地理位置進行內容個人化。 | 我們的回應自 2022 年第 4 季起維持不變： 「我們正在與相關人員合作，確保 Chrome 能持續支援 IP 位址的正當使用情境。我們希望針對 IP 地理位置的精細程度，提供生態系統意見回饋。」 |
| 監管法規遵循 | 如果某個地區的人口少於 100 萬，目前 IP 防護的門檻為 100 萬，因此網站無法使用 IP 位址來規範法規遵循。 | 我們正在與利害關係人合作，確保 Chrome 持續支援 IP 位址的正當使用案例。因此，我們目前正請針對 IP 保護的法規遵循情形，向相關生態系統徵求意見回饋。 |
| 緩解濫用行為 | 雙方可以分享未遮蓋的 IP 位址，藉此規避 IP 保護。 | 我們留意到目前的 IP 保護提案在技術上可能並未防止各方與他人分享未遮蓋的 IP 位址。我們正在設法降低這項濫用風險。 在我們持續改進提案的過程中，我們鼓勵您提出更多意見並進一步討論。具體而言，我們希望瞭解各方認為需要與其他方分享未遮蓋的 IP 位址。 |
| 聯播網封鎖 | 雙方可以使用 IP 防護 Proxy 規避網路封鎖。 | 執行封鎖作業的實體必須為此情境停用「IP 保護」。我們已回應相關問題，也歡迎提供其他意見回饋。 |
| 受 IP 保護提案影響的 IP 位址封鎖清單 | 許多廣告技術公司會使用基本的 IP 位址封鎖清單 (例如 TAG 資料中心 IP 清單)，防止對極可能涉及詐欺 (或至少無法營利) 的廣告空間出價。如果廣告技術也是追蹤工具，且可能受到 IP 保護的提案影響，該公司可能無法在購買廣告空間前，對廣告執行基本檢查。 | 我們鼓勵您針對潛在問題和解決方案提供進一步意見，並討論 IP 防護提案。其中一種做法是將類似的清單套用至 IP 保護，這樣我們就不會使用先前標記 IP 位址的用戶端代理用戶端。 |
強化跨網站隱私界線
第一方集合
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| (第 4 季一併回報) 網域限制 | 要求增加相關網域數量 | 我們的回應和 2022 年第 4 季沒有任何異動： 「在 WICG 呼叫中，我們清楚說明瞭 Chrome 致力提供可行的解決方案，並將使用者的隱私權利益納入考量。透過這個做法，我們歡迎社群提供意見，說明可能會受到網域限制影響的特定用途，讓團隊可以考慮解決這些用途，同時繼續保護使用者隱私。」 |
| 提交替代每秒影格數 | 提議採取替代方式，提交每秒影格數適用的全球清單 | 我們目前正準備在 Chrome 中運送第一方集合 (FPS)，並已設定集中式 GitHub 存放區來接受集合提交內容。我們希望 FPS 能彌補現有網路平台解決方案的不足，進而為第三方 Cookie 淘汰做準備，所以我們期待能向網站作者說明 FPS 的使用方式。隨著組合清單不斷增加，且生態系統也因應第三方 Cookie 的後續發展，我們也可以改進相關流程，進而考慮採取其他去中心化配置，例如提出的建議。在目前的流程中，我們期望能確立生命週期，以便逐步改善攝入程序。待提交程序通過後，我們就能重新審視這個想法。 |
| 存放區管理 | 針對 FPS 提交存放區的社群審核措施，避免濫用。不肖人士可能會輕鬆處理使用工作倦怠的源頭來提出組合，而大量要求可能會影響原始組合提案的作業。 | 我們正透過技術驗證檢查來盡可能執行檢查。我們認為這是提交程序最可擴充的方法。為了實現這個目標，我們也會致力確保這項程序不受垃圾內容 / 燒錄物影響。 |
| 相關聯的子集 | FPS 是否能透過相關聯的子集，支援第三方廠商/軟體式服務 (SaaS) 流程用途？ | 第三方廠商 / 軟體式服務 (SaaS) 流程並非適用第一方集合的使用案例。我們也歡迎您提供其他意見回饋，協助我們瞭解跨網站 Cookie 如何因應這些用途。 |
| FPS + CHIPS 整合 | 要求進行 FPS + CHIPS 整合作業，以支援 A/B 測試等用途 | 我們正在討論這個使用案例，同時也考慮在 WICG 呼叫中進一步討論這個部分，也歡迎在這裡提供其他輸入內容。 |
| GDPR | 提議將 GDPR 概念用於新的 FPS 子集提案 | 我們內部討論了這項提案，並根據收到的其他意見回饋和隱私權目標來評估提案。我們提供了答案，解釋為何我們目前無法推薦這個提案。 |
| 記憶體容量 | 加入 FPS 清單時，瀏覽器記憶體大小的預期變化 | 一直以來，瀏覽器為了儲存這類清單而盡可能減少記憶體影響，例如「中斷連線追蹤保護清單」。雖然第一方集合清單會複製到每個 Chrome 用戶端，但我們會持續監控檔案大小，確保我們能最佳化記憶體用量。 |
Fenced Frames API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 圍欄頁框限制 | 圍欄框架設定的限制清楚呈現 | 我們在 3 月時更新了圍欄框架說明，提供有關其功能的資訊。我們也歡迎提供任何其他意見回饋。 |
| 展開存取權資訊 | 要求擴大鄰近影格相關資訊的存取權 | 我們想進一步瞭解這項生態系統規定的原因，也歡迎提供其他意見回饋。 |
| 圍欄頁框和 iframe | 關於 Fenced Frame 與 iframe 的功能對等性的相關問題 | 所有可用的 Privacy Sandbox API 和報表都將能以相同方式適用於 iframe 和 FencedFrames。 |
| 調整圍欄頁框大小 | 限制影格大小變更會影響特定用途。 | 我們希望進一步瞭解這類限制影響的用途類型，也歡迎您提供其他意見回饋。 |
Shared Storage API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 第三方 Worklet | 第三方可以依來源區分共用儲存空間嗎？或是要呼叫其他 Worklet 進行第三方評估？ | 執行程式碼的瀏覽環境來源會決定資料寫入所屬共用儲存空間。在網頁中加入第三方程式碼後，該第三方程式碼會以本身的瀏覽情境的形式嵌入 iframe 中，讓第三方程式碼得以寫入本身的來源。第三方程式碼也可以嵌入為指令碼而非 iframe，因為 iframe 不會切換瀏覽情境，且第三方可以寫入嵌入器的共用儲存空間。請注意，只有該共用儲存空間的擁有者才能從該共用儲存空間讀取資料。 |
| 簡化 | 不過，您無法為 Chrome 生態系統以外的互動刪除重複資料。 | 共用儲存空間旨在在 Chrome 中提供以 Chrome 為基礎的不重複觸及輸出內容。我們希望與廣告技術合作，瞭解如何將這些輸出內容做為整體觸及模型的一部分。我們瞭解輸出內容本身可能只佔一部分互動，且有意與廣告技術合作，探索可疊加的其他模擬方法。 |
| 轉換回溯期 | 申請設定轉換率的回溯期，以便瞭解轉換次數的長期變化 | 您可以利用共用儲存空間處理用戶端上的各種轉換路徑，藉此實作這個模式，這樣一來，就不用透過安全的非分區瀏覽器儲存空間進行進階分析，還能享有更多彈性。 |
| 商品過期期間 | 要求將到期日延長至 90 天 | 資料保留政策於 2022 年 11 月更新，指出每個金鑰會在上次寫入的三十天後清除。我們歡迎您提供其他意見回饋，瞭解新政策是否適用於大環境。 |
| 廣告素材輪播 | 廣告素材輪播用途不會反映競價後的實際動作。 | 我們想瞭解其他買方廣告技術公司，瞭解廣告素材輪播說明文件是否正確。 |
方塊
本季沒有任何意見回饋。
FedCM
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 身分宣告端點 | 明確允許對身分宣告端點發出任意要求。 | 我們正針對這項提取要求與 Mozilla 合作，藉此限制網站在不造成使用者乾擾的情況下，以靜音方式提出跨來源憑證要求。此外，我們也會繼續審查並處理其他意見回饋。 |
| 預先填入身分 | FedCM 是否可以使用 FedCM 清單中的識別資訊提供者預先填入登入表單？ | 這個使用案例的疑慮是，當使用者無法查詢使用者所用的網站時，可能會導致資訊外洩。我們正在進一步討論這個問題，也歡迎提供更多意見回饋。 |
| 選取內容比對帳戶 | 在帳戶選取使用者介面中加入比對內容信號的提案 | 我們正在考慮這項提案，並歡迎您進行其他討論。 |
打擊垃圾內容和詐欺
Private State Token API (和其他 API)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 能力收集問卷調查 | 我們在第 1 季上半年完成了問卷調查結果，收集到各種反詐欺用途所需的功能並公開分享 (分鐘、 結果) | 我們計劃在開發新提案和原型時，以針對專門的隱私保護 API 進行反詐欺功能開發新提案和原型。我們希望在有充足需求的開發上優先開發，同時提供現有技術，用於將這項功能導入網路功能，同時保障使用者隱私。舉例來說，裝置和啟動完整性受到較高的排名，許多平台的現有 API 可透過安全的方式共用裝置完整性的評估機制，因此非常適合在社群群組中追逐探索。 |
| PST 計畫傳送意見回饋的意願 | 為進行出貨，我們收到了一項問題，原因為使用舊版 Privacy Pass。我們也收到了某些部分的意見回饋，指出其中某些章節的規格不明確，因此需要改善，以便提高瀏覽器相容性。 | 我們計劃在提供產品至 Google Analytics (分析) 前，先實作其中許多建議的規格變更，以及一些 API 變更。我們在第 1 季末收到的意見回饋，因此會透過 GitHub 問題追蹤具體細節，以及推出計畫的更新內容 (發布後，這份意見回饋報告發布後)。 對於 API 的較大變更，我們十分樂意考量這些異動，但我們認為最好的方式是繼續執行正式發布，並取得更多開發人員的實際意見。我們希望繼續討論並推動瀏覽器標準化。如果日後出現新標準，我們會考慮採用並制定計畫，謹慎地轉換標準。 |