意見回饋報告 - 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 的 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 效能 我們會積極追蹤創作者的意見回饋並進一步瞭解背景資訊,進而提供可行的解決方案。第一步是將意見回饋分為兩個類別:
  1. 由賣方平台驅動的篩選機制,將 a) 本身和 b) DSP 的每秒查詢 (QPS) 負載最佳化。
  2. 興趣群組 DailyUpdate 邏輯,最佳化 DSP 上的 QPS 負載。
(另於 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 位興趣群組擁有者。這些資訊旨在做為防護機制,而非在一般作業中發揮作用。
事件層級信號 支援具備 generateBidreportWin 的事件層級信號,可用於進行機器學習訓練 我們已分享我們對瀏覽器設計的信號和廣告技術定義信號的決定,同時也歡迎提供其他意見回饋。
出價指令碼 在出價指令碼的網址中加入使用者 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 報表 reportWinreportResult 應隨機進行順序,以免過度回報或遭到低估。 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 或通訊協定緩衝區中,並將其序列化為字串。
廣告主封鎖清單 哪些信號適合為廣告客戶封鎖清單提供買方? 適當位置位於 auctionSignalsperBuyerSignals 中。
出價單位 支援不同的出價單元,例如單次安裝出價和千次曝光出價 我們希望進一步瞭解為什麼目前的設計需要這麼做,也希望收到其他意見回饋
競價邏輯 瀏覽器或廣告伺服器會決定競價的勝出者嗎? 所有勝出組合都會在沙箱中執行,且所有決定都是由賣方的程式碼所決定。瀏覽器只提供一個密封的私密環境,供買方和賣方程式碼執行。
權限 -政策 來源試用結束後,目前的 FLEDGE 權限政策是否會繼續強制執行? 在來源試用中,這兩項功能目前的預設許可清單是暫時性的,之後將變更。Google 想知道廣告技術人員需要花多少時間做好準備,才能落實這項異動。
信號大小限制 系統會將受信任的出價信號要求,與 trustedBiddingSignalsUrl 相同的多個興趣群組相輔相成。2MB 的大小限制是一種限制。 裝置端的呼叫端設有此限制,以免裝置的資源過大。B&A 伺服器的呼叫者將擁有更嚴格的限制
報表信號 新增其他信號「指令碼錯誤」,以擷取每個興趣群組擁有者和每個 computeBidreportWin / 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 的較大變更,我們十分樂意考量這些異動,但我們認為最好的方式是繼續執行正式發布,並取得更多開發人員的實際意見。我們希望繼續討論並推動瀏覽器標準化。如果日後出現新標準,我們會考慮採用並制定計畫,謹慎地轉換標準。