2022 年第 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、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 回應 |
| (第 2 季也會提供這份報表)
不同各類型利害關係人的實用性 |
以下問題是，Privacy Sandbox 技術對大型開發人員較有利，而小眾 (小型) 網站帶來的貢獻內容高於一般 (大型) 網站。 | 第 3 季更新：
Google 致力於設計及導入 Privacy Sandbox 提案，不會因自己偏好 Google 自身業務而扭曲競爭情形，同時將對數位廣告及發布商和廣告客戶競爭情形的影響納入考量，無論規模大小為何。我們會持續與 CMA 密切合作，確保我們所做的努力符合這些承諾。 隨著 Privacy Sandbox 的進展，我們要評估一項重要問題，就是新技術對不同類型相關人員的成效。意見回饋十分重要，尤其是具體的意見回饋，可協助我們進一步改善技術設計。 我們與 CMA 合作制定量化測試做法，並支持 CMA 發布實驗設計的附註，為市場參與者提供更多資訊，讓對方有機會評論建議的做法。 |
| (第 2 季也會提供這份報表)
說明文件要求 |
要求取得更多資源，並詳細說明如何管理測試、分析和實作的方式 | 第 3 季更新：
感謝開發人員目前認為我們提供的實用資源，並會繼續在未來幾週和幾個月累積更多資源，讓開發人員持續瞭解新技術對他們有何助益。 我們也舉辦了公開的開發人員諮詢時間會議，分享最佳做法和示範內容，並邀請產品和工程主管進行問答活動，方便大家進行現場討論/問答活動。 |
| 支援跨瀏覽器 | 採用 Privacy Sandbox API 的其他瀏覽器供應商。 | 有些瀏覽器供應商 (例如 Apple、Mozilla 和 Microsoft) 會積極參與公開論壇，討論隱私權原則和瀏覽器相關做法。受到近期的 W3C 年度 TPAC 會議，以及正在進行的 W3C PATCG 論壇等論壇成員協作，鼓舞我們，大家都對這些論壇的收斂力很有幫助。 |
| 平台差異 | 請盡可能確保網頁和 Android 的功能集一致，以減少轉換所需的資源。 | 我們正致力於為 Chrome 和 Android 提供一致的做法，避免造成業界混淆，或造成混亂。造成這些差異的原因，大都是因為網頁和行動應用程式平台在技術方面上的差異，開發人員原本就已納入考量。 |
| 可用來測試 Privacy Sandbox API 的資源 | 難以分配 因應當前經濟逆境，提供測試資源來測試 Privacy Sandbox API。 |
Google 會持續改善提供給測試人員的說明文件和支援服務，以簡化相關作業程序，並協助測試人員採用 API。包括：API 專屬的郵寄清單、開放諮詢時間，以及 developers.chrome.com 上的持續更新。 |
| Sandbox API 選擇不採用信號 | 請求提供「使用者已停用沙箱 API」信號，供廣告技術和網站使用。 | 我們發現，以往許多網站都會藉由按下使用者變更設定來回應使用者選擇 (例如「關閉第三方 Cookie」)，有時也會禁止網站存取，有時甚至會禁止網站存取 (除非使用者採取這類動作)。此外，系統也可能會將選擇不採用信號做為數位指紋採集的另一個信號。目前，Google 不打算提供選擇停用信號。 |
| (第 2 季也會提供這份報表)
更清晰的時程 |
更明確、更詳細的發布時間表 | 第 3 季更新：
如下方「回應意見回饋」一節的說明，Google 在 7 月更新了 Privacy Sandbox 的時間表，讓市場有更多時間進行初步測試並提供意見，並在 Privacy Sandbox API 全面推出前，釋出更多時間進行測試。 |
| (第 2 季也會提供這份報表)
第三方 Cookie 淘汰時間表 |
請求進一步避免第三方 Cookie 遭到淘汰 | 第 3 季更新：
7 月時，Chrome 宣布更新第三方 Cookie 的淘汰時程，反映了我們在技術複雜性及對生態系統的重要性下，秉持負責任的態度積極行動。在此之前，我們會先參考監管機構和業界的意見回饋，並繼續與所有相關人員密切合作。 |
| 第一方 Cookie | Google 是否也提議對第一方 Cookie 設有限制？如果答案是肯定的，如果對長期穩定性有所疑慮，可能會受到進一步無法預測的瀏覽器變更風險，因而浪費在工程上費心。 | 我們尚未考慮到任何第一方 Cookie 限制。Privacy Sandbox 致力淘汰第三方 Cookie。 |
顯示相關內容與廣告
主題
| 意見回饋主題 | 摘要 | Chrome 回應 |
| (第 2 季也會提供這份報表)
不同各類型利害關係人的實用性 |
許多疑慮都引發了網站實用性方面的疑慮，因為網站的流量多寡或內容專業程度而異。 | 第 3 季更新：
需透過測試瞭解 API 的實用性。根據「承諾使用合約」第 17.c.ii 段的規定，Google 會將這類測試的結果提供給 CMA。Chrome 會根據測試結果調整分類和其他參數。根據分類或參數的演進，不需要回溯不相容的變更。此外，Chrome 預期在第三方 Cookie 淘汰後，也會繼續收到相關意見回饋，持續影響 Topics API 的演進。 |
| 隱私權/政策 | 要求移除每個呼叫端的主題篩選要求。 | 根據隱私權 KOF、隱私權擁護者、安全性專家、數位版權團體和生態系統中其他人的意見回饋，Chrome 選擇這個設計，只將資訊存取權提供給其他需要這類存取權的人員。原因包括但不限於：限制跨端資料外洩事件、確保資訊公開及可解釋性、採用簡單易懂的方法、說明和限制數位指紋採集的風險。接受 Topics 的發布商和第三方可自行決定要與自家網站上第三方分享哪些資訊。如果第三方要分享這些資訊，Chrome 強烈建議他們向使用者說明這類分享內容，並提供控制選項。 |
| 網站分類有誤 | 網站分類錯誤，可能導致廣告指定目標不正確。 | 系統會結合人工收錄的覆寫清單來分類網站，其中包含最受歡迎的網站和裝置端機器學習模型。Chrome 會持續評估網站是否要納入 Topics 分類，所有公用程式的改善都必須權衡隱私權和濫用風險。舉例來說，以下列舉幾項風險：
大眾可以透過 chrome://topics-internals 或這個 colab 提供的工具檢查這些元件。透過測試，我們期望能隨著時間改善分類功能，我們也歡迎你針對可能分類錯誤的網站提供意見回饋。 |
| 存取權需求 | 目前網頁上的 DOM 實體以指令碼或 iframe 的形式設定 Topics 規定，可能會導致玩家在廣告生態系統中遇到不想要的行為。 | 我們已合併 GitHub 說明的異動。我們希望支援 HTTP 標頭中的 Topics。 |
| 主題分類的精細程度不足 | 目前的主題分類範圍太廣，並未包含更精細的主題，例如區域主題。 | 我們會持續改善分類，我們期望能隨著生態系統測試與輸入內容，不斷調整分類方式。
我們正積極向我們反應對大環境最實用的分類方式。在評估是否要擴大主題數量或納入更精細的主題時，需要考量以下幾點：1) 潛在的隱私權影響 (例如，更多主題可能會導致數位指紋採集風險) 和 2) 擷取先前觀察到的主題 (例如主題越多，廣告技術過去查看所選主題的機率也就較低)。進一步擴大第 2 項，Google 希望能根據現有的篩選規定，盡可能讓來電者擷取先前觀察到的主題，同時兼顧實用性和隱私權。 |
| 主題限制 | 每個網站列出三個主題的資訊不足，導致廣告客戶無法放送廣告。 | 生態系統的意見回饋將影響 API 的發展，特別是來源試用的測試結果。請注意，Topics 應補充其他信號 (例如比對內容)，協助找出適當的訪客廣告。因此除了主題以外，您還可獲得更多資訊。 |
| (第 2 季也會提供這份報表)
使用者控制項和安全性 |
有些主題可能屬於敏感族群的 Proxy，而使用者需要更多控制項才能避免負面結果。 | 第 3 季更新：
「主題」是進一步提升使用者控制權與資訊透明度的重要推手。使用者可以選擇不採用主題、查看已指派的主題、移除主題，以及瞭解哪些公司在特定網頁上與他們的主題互動。此外，使用者也可以刪除瀏覽記錄，藉此清除相關主題。這些控制項目前是在裝置層級的 Chrome 瀏覽器上導入。對於更進階的使用者控制項 (例如開發人員的建議)，我們依然可以繼續討論，但同時也必須確保新增的內容經過妥善調整，以解決使用者抱持的疑慮，不會因此進行基本變更。 |
| 對搜尋引擎最佳化 (SEO) 的影響 | 如果發布商為了反映 Topics 而調整網站的主機名稱，可能會對 SEO 產生負面影響。 | 我們會謹慎處理網站是否只為了 Topics 變更主機名稱。網站確實能夠以這種方式影響獲派的主題。但這麼做對發布商的好處還不甚明確。此外，如果網站試圖「操弄」分類模型，這會損害 Topics 對整個生態系統的價值。主題指派作業也不再固定，我們預期這個分類方式會隨著測試和輸入內容不斷演進。針對這項測試，我們鼓勵意見回饋，包括所有可能誤判的網站示例。 |
| 詐欺與濫用 | 讓買方驗證他們看到的主題確實是由瀏覽器產生。 | 很高興看到建議支援一項機制，協助廣告技術買方驗證賣方在程式輔助廣告競價中傳遞的主題。我們鼓勵所有生態系統都能在這裡積極參與討論。雖然我們目前先將重心放在其他優先順序更高的其他項目，但我們深知，這對設計而言可能有必要未來。 |
| 詐欺與濫用 | 允許對 Topics 資料的合法使用者公開評論，就像發布第一方貼文和評論會遵守第一方集合一樣。 | 我們十分重視這項建議，並同意公開可靠度是有助於達成 Privacy Sandbox 目標的重要工具。Topics API 呼叫本身是公開的，因為任何人都可以造訪網站並觀察網域對 JavaScript API 的呼叫。這樣一來，個別使用者和機構組織就能查看相關活動，評估哪些網站使用 Topics 和使用方式。我們認為這種做法比評估 Topics API 本身功能中「合法」部分的網站「符合規定」。 |
| 對第一方信號的影響 | 主題信號可能極具價值，因此會降低其他第一方興趣信號的價值。 | 我們認為按照興趣顯示廣告是網頁重要的使用情境，而 Topics 也能支援這種使用情境。如前所述，其他生態系統利害關係人曾表示 Topics 實用性不高，無法提供價值。總體而言，改善分類並不容易，我們相信這個分類法能隨著大環境的測試和輸入內容持續調整。 |
FLEDGE
| 意見回饋主題 | 摘要 | Chrome 回應 |
| FLEDGE 競價 | 賣方平台如何格式化資料給 Google Ads，以便在 FLEDGE 競價中出價。 | 我們鼓勵所有參與測試的公司發布相關測試計畫文件，並視情況協同合作。
我們與 CMA 合作制定量化測試做法，並支持 CMA 發布實驗設計的附註，為預計參與試用的市場參與者提供更多資訊，並提供對建議做法的見解。 如果賣方有意針對使用 Ad Manager 做為廣告伺服器的發布商測試 FLEDGE，Ad Manager 團隊已在這裡發布說明文件。 如需其他技術詳細資料，請參閱這篇文章。 |
| 巢狀 Fenced Frame 中的 FLEDGE | 圍欄頁框可進行較嚴格的測試，同時限制在未定義的未來環境中執行更多限制。這樣的未知時程對大環境帶來挑戰。 | 公司目前可以使用 Fenced Frames 測試 FLEDGE。如要提供更簡單的新手上路選項，公司可以選擇先導入 FLEDGE。導入 FLEDGE 後，他們就能使用 FLEDGE 設計測試 Fenced Frame。 |
| 資料處理政策 | 興趣群組 / FLEDGE 的資料處理政策是什麼？ | 在 FLEDGE 設計中，興趣群組中儲存的所有資料或使用者對於興趣群組的資料都會保留在裝置中。這些資料都不會傳送至 Google 伺服器。
Chrome 針對 FLEDGE 制定的某些隱私權保護措施確實涉及與 Google 執行的 k-anonymity 伺服器互動。這種互動在經過精心設計，可避免分享使用者的相關資訊，並在受信任的執行環境 (TEE) 中執行，以確保廣告生態系統中的資訊一致。 \ Google 承諾在設計及導入 Privacy Sandbox 提案時，不會考量 Google 本身的業務，也不會因此扭曲競爭情形，並將影響數位廣告、發布商和廣告主的競爭影響納入考量。我們會繼續與 CMA 密切合作，確保我們所做的工作符合這些承諾。 |
| 年齡政策 | Chrome 如何確保 FLEDGE 建立的目標對象符合年齡限制？ | 發布商和廣告客戶最適合用來評估自己使用 FLEDGE 建立的目標對像是否符合適用法律。為進一步保護使用者，只要使用者帳戶設定年齡未滿 18 歲，即使在測試期間登入 Chrome，他們也無法啟用 Privacy Sandbox API。(如果是未登入帳戶的使用者，Chrome 不會收集設定檔信號，以便瀏覽器推測使用者年齡)。 |
| FLEDGE 金鑰/價值服務 | 進一步說明 FLEDGE 鍵/值服務允許的項目，例如金鑰數量和更新頻率。 | 使用 FLEDGE 的公司可以擁有多少金鑰，可用於 RAM。詳情請參閱這裡的說明。
我們正在設法更快速地修改資料，並針對任何需求提供歡迎建議。 |
| 測試 | 難以搭配 Google Ads 測試 FLEDGE | 請參閱 Google Ads 新手上路說明文件，瞭解如何參與及測試來源試用。 |
| 出價和競價服務 API | Google 對出價和競價服務 API 採取的方向為何？進行裝置競價時，優先順序會高於或低於 Chrome 瀏覽器 FLEDGE？ | 我們會持續努力採用目前的 FLEDGE 裝置端出價設計。我們提議出價和競價服務，針對某些裝置運算能力或網路速度可能受限的用途，找出合適的解決方案。 |
| 匯總報表 | 要求支援根據可產生出價的所有信號的匯總報表。 | 我們預計不久後就會公開分享更多資訊。 |
| 內容相關廣告 | 使用 FLEDGE 放送內容相關廣告。 | 我們已經考慮採用這個選項，並基於這份討論中說明的理由，目前不建議在內容相關廣告中使用 FLEDGE。 |
| 實際測試 | 說明如何隔離 FLEDGE 與第三方 Cookie，以便進行實際測試。 | 我們正在研究提供測試人口的方法。 我們與 CMA 合作制定量化測試做法，並支持 CMA 發布實驗設計的附註，為市場參與者提供更多資訊，讓對方有機會評論建議的做法。 |
| 測試 FLEDGE 和 Attribution Reporting API | 使用 FLEDGE 導入 Attribution Reporting API 的最佳做法為何？最好同時區隔 FLEDGE 和歸因分析，還是同時進行測試？ | 我們最終會支援測試 FLEDGE 和 Attribution Reporting API 做為整合式解決方案，但我們建議開發人員先獨立測試 Attribution Reporting API，然後在整合完成後使用 FLEDGE。 |
| 出價顯示設定 | 要求模糊處理出價價格。 | 您可以在「generateBid()」或「scoreAd()」中設定中斷點，以便存取開發人員工具中的出價值。針對 FLEDGE 的這份意見回饋，Chrome 團隊已考量過這種攻擊範圍較小的攻擊向量。不過，Chrome 的安全性和隱私權模型會將使用者視為信任，以他們能對自己裝置上的資訊執行任何操作，因此也無法依要求隱藏出價資料。 |
| 說明文件要求 | 在即時生態系統中測試的說明文件和範例。 | 感謝開發人員目前認為我們提供的實用資源，並會繼續在未來幾週和幾個月累積更多資源，讓開發人員持續瞭解新技術對他們有何助益。
我們也為開發人員舉辦了公開諮詢時間，由產品及工程主管分享最佳做法和示範內容，並邀請產品和工程主管進行現場討論/問答活動。 |
| Private Aggregation API | 需要進一步瞭解 Private Aggregation API 嗎？ | 有關公開說明，以及我們目前可分享的最新資訊。我們在開發這個 API 並定義用途後，將會提供更多說明文件。 |
| 資料延遲 | FLEDGE 鍵/值伺服器資料擷取作業會即時進行嗎？ | 如開放式 GitHub 問題所述，少量的過時程度會以分鐘為單位，在伺服器可傳回更新的資料前，不應等待數小時。此外，我們也希望徵求開發人員的意見回饋。 |
| 出價和競價服務 | 如果使用出價和競價 (B&A) 服務，系統會向使用者顯示出價價格嗎？ | 在 B&A 伺服器端的做法，系統不會向使用者顯示個別出價，因為這個出價要求是由賣方平台競價服務直接向 DSP 競價服務發出，因此瀏覽器無法再使用。
但是，瀏覽器仍會顯示勝出的出價價格 (詳情請參閱上方說明，並要求模糊處理出價價格)。 |
| 出價和競價服務 | 如何對出價和競價服務進行負載平衡？ | 我們目前並無任何關於負載平衡的指引，但從效能和隱私權的角度來看，這一點也相當重要。我們日後會提供更多詳細資訊。 |
| FLEDGE 限制 | 要求將 joinAdInterestGroup 時間長度上限從 30 天提高為 90 天。 | 我們認為 30 天的資料保留期限與其他 Privacy Sandbox 廣告 API 一致，例如歸因報表的 30 天上限，以及 Topics 的 3 週回顧。此時間範圍可滿足廣告技術和使用者對隱私權保障的需求。 不過，歡迎你進一步提供意見，我們會持續討論這裡的問題。 |
| FLEDGE 的共用儲存空間 | 可以在 FLEDGE 中使用 Shared Storage API 嗎？ | 我們預計日後在 FLEDGE 中支援 Shared Storage API，並預計在即將推出的來源試用中支援這項功能。 |
| 依點擊次數控制展示頻率 | 可以在 FLEDGE 中按點擊 (無法勝出) 設定展示頻率上限嗎？ | FLEDGE 確實指出 Fenced Frame 可以呼叫 navigator.LeaveAdInterestGroup() (不含參數)，以退出導致廣告顯示的興趣群組；此呼叫可在第一次收到點擊時完成，以防止日後出價，做為展示頻率上限的形式。目前，這項解決方案無法在多次點擊後無法設定上限。 |
| 巢狀 Fenced Frame 中的 FLEDGE。 | 如果點擊發生在巢狀 Fenced Frame，則無法透過 Fenced Frame 廣告報表回報。 | 我們已發布修正此問題的提案，請前往這個頁面。 |
| 判定結果 | 需要指引，瞭解如何在 FLEDGE 競價中收集出價方的延遲資料。 | 我們會盡快發布成效評估文件。 |
| 報表 | FLEDGE 報表的處理方式為何？ | 勝出、競價結果和事件等 FLEDGE 報表可透過 FLEDGE API (例如 reportResult()) 取得點擊。在廣告轉換報表中，Attribution Reporting API 的整合與 FLEDGE 無關，但我們正在與生態系統討論可行的做法。 Private Aggregation API 也可用來回報隔離的執行環境中的競價結果。請參閱這裡的說明。 |
| 興趣群組規模 | 廣告技術是否可透過任何方式檢查興趣群組的大小 (即群組中的使用者人數)？ | 興趣群組成員是由瀏覽器或使用者的裝置儲存，不會與瀏覽器廠商或其他人分享。
但是，興趣群組擁有者可以理論追蹤所有對 navigator.joininterestgroup(...) 的每個呼叫。追蹤此呼叫並不保證 IG 的確切大小 (因為使用者隨時都可以離開群組)，但可以向擁有者提供上限和概略大小的概略值。 |
| 效能 | 出價 JS/WebAssembly 程式碼是否會在每次競價時編譯？ | 每次競價期間，出價的 JS/WebAssembly 程式碼會編譯一次。 |
| 效能 | BidDurationMsec 的範圍為何？ | BidDurationMsec 包括編譯指令碼時間。不包括下載時間、 wasm 編譯時間、網路時間、從鍵/值伺服器擷取時間，或是 JS 編譯前項目的時間。 |
| 自訂 | 可以更新 adComponent 以便為使用者自訂嗎？ | 當呼叫 getInterestGroup 或 Chrome 呼叫 DailyUpdateURL 時，呼叫端更新興趣群組時，您就可以更新 adComponent。如此一來，呼叫端就可以分別根據目前網站上使用者的瞭解，或根據 k 匿名資訊，更新 adComponent。您可以在這裡找到產品層級 Turtledove 的原始提案，當中包含 RTB House 對建議用途核心指標的影響分析。 |
| 興趣群組 | 興趣群組擁有者可以有條件地移除特定使用者嗎？ | 興趣群組成員資格只會儲存在使用者的瀏覽器中，只能透過使用者的瀏覽器移除 (例如清除網站資料)。
不過，如果使用者返回到興趣群組擁有者所控制的網頁，興趣群組擁有者可以呼叫 navigator.LeaveAdInterestGroup() (以及其中包含某些條件邏輯)。 |
| 效能 | 如何評估 generateBid 的成效？ | 使用 bidDurationMsec 即可評估編譯和執行時間。你可以使用 chrome://net-export 評估下載時間。在較新版本的 Chrome 中，編譯和執行時間會顯示在「開發人員工具」分頁中。 |
| 興趣群組更新頻率 | 瀏覽器更新興趣群組的頻率為何？ | 針對過去 24 小時內未更新的興趣群組，Chrome 會在呼叫 navigator.updateAdInterestGroups() 或有機會參與競價時，嘗試更新興趣群組。詳情請參閱這裡的說明。 |
| 匯總服務供應商 | 匯總服務何時會支援其他雲端服務供應商？ | 我們目前未於特定時間有任何更新資訊，但會再分享一次。目前只有 AWS 符合匯總服務的安全性需求。 |
| FLEDGE 測試時間軸 | 在 BYOS 中測試 FLEDGE 的時間要多久？我有足夠時間從 BYOS 模型切換至 TEE 型模型嗎？ | 為了確保生態系統有足夠的時間進行測試，我們預計在第三方 Cookie 淘汰一段時間後，才會要求使用 TEE。在這段過渡期間，我們會重大通知開發人員，以便開始測試與採用。我們目前沒有任何其他更新，但會盡快發布更多消息。請到這裡查看最新資訊。 |
| 資料大小上限 | 出價函式中的 wasm 資料大小限制是多少。 | 如這裡所述，興趣群組更新不會產生超過 50 KB 的興趣群組，但由於尚未定義搜尋資料大小上限，因此歡迎針對這個主題提供意見。 |
| 競價信號 | 競價信號是否會有標準化的資料結構？ | 我們尚未制定這項功能，但歡迎提供意見回饋。 |
| 查詢廣告技術伺服器 | 可以從 K/V 伺服器即時查詢廣告技術伺服器資料嗎？ | 否。K/V 伺服器會在信任模型中執行，該模型會強制執行「無網路、磁碟存取、計時器或記錄」選項，避免使用者資料外洩。詳情請參閱信任模型說明。 |
| 更新 adComponents 的頻率 | 目前無法由使用者的瀏覽記錄更新 adComponents 欄位 (目前只能在 IG 設定中) | Privacy Sandbox 的目標是在不使用跨網站追蹤功能的情況下，滿足網路生態系統的需求，也就是防止使用者存取瀏覽記錄。建議你改用 Topics 等替代方案。 |
| 競價結果 | 廣告技術能否知道競價勝出率？ | 系統會分別在賣方和得標買方提供的競價程式碼中呼叫 reportResult() 和 reportWin() 函式，以回報競價結果，讓每個買方都有機會執行競價結果的記錄和報表作業。 |
| (第 2 季也會提供這份報表)
支援指定排除興趣群組 |
支援排除興趣群組的 API：只有在使用者不屬於某個興趣群組時，才會顯示廣告。 | 第 3 季更新：
我們分享了新的 提案 ，希望能徵求意見回饋。 |
評估數位廣告
Attribution Reporting (和其他 API)
| 意見回饋主題 | 摘要 | Chrome 回應 |
| OT 規定 | 僅在期間 / 用於 OT 時移除 Permission-Policy 限制。 | 請參閱我們公告的權限測試期間的 Permissions-Policy 異動項目。這項變更解決了潛在利害關係人疑慮，可讓需求端平台在較多的跨來源 iframe 中測試 API。最初需求端平台必須與發布商/賣方平台協調，確認已設定適當的權限政策，以便在跨來源 iframe 上測試 API，但透過這項變更，需求端平台將能預設呼叫 API，而賣方平台/發布商則可視需要在來源試用期間停用該 API。 |
| 雜訊 | 透過意見回饋指出雜訊等級過高，會影響報表的實用性。 | 我們歡迎您針對雜訊提供寶貴意見，我們會根據這項意見決定特定雜訊的相關參數。我們也希望發布更多資源、工具和其他文件，協助測試人員進行這項作業。 |
| 跨網域轉換 | 如何追蹤跨網域轉換，例如設定 2 個以上的目的地？ | 我們目前正針對這個問題討論及徵求意見回饋。 |
| 偵錯需求 | 要要求開發人員在部署 / 測試摘要報表時，查看剩餘的隱私預算嗎？ | 如要追蹤這項功能要求，請按 這裡。 |
| API 使用政策 | 提供意見，根據數位指紋採集等方面的限制，提供特定 API 的使用建議政策 | 這是個很有趣的想法，我們很樂意與其他瀏覽器供應商和廣大的網路生態系統展開進一步合作。 |
| 轉換報表中的過期設定 | 申請支援報表篩選器 / 到期日不超過 24 小時。 | 每小時到期是隱私權考量的一大因素，可讓廣告技術瞭解使用者確切造訪廣告客戶網站的時間。每日層級的到期時間可讓廣告技術篩除無效曝光，不必判斷使用者造訪網站的時段。 |
| 來源試用權杖到期日 | 要求延長現有 OT 權杖的有效性，以降低營運負擔。 | 我們瞭解權杖必須更新，並持續設法讓開發人員更輕鬆地進行修正，同時也會另行通知。 |
| 區域支援 | 匯總服務目前不支援所有區域。 | 這是 Beta 版目前的限制。我們預計隨著測試進度在更多地區推出這項服務，不過尚未提供明確的時間表。 |
| 事件層級報表延遲 | 就某些用途而言，事件層級報表中的 2 到 30 天延遲時間可能過長。 | 我們在這裡分享了一項提案，可讓廣告技術控制事件層級報表透過到期日傳送的時機。預設值為 30 天，但可以設定較短的時間。 |
| (第 2 季也會提供這份報表)
多接觸點歸因分析 |
允許多接觸點歸因分析，例如跨裝置或跨應用程式。 | 第 3 季更新：
目前，多接觸點歸因分析的方法需要確定，將不同網站上的使用者曝光 (並依身分) 結合在一起。因此，這項功能在現有表單中與 Privacy Sandbox 的目標不符。 Privacy Sandbox 的目標是在沒有跨網站追蹤的情況下，支援重要的廣告用途。 |
| FLEDGE 與歸因報表整合時程 | FLEDGE 和 Attribution Reporting API 的整合時程為何？ | 目前還沒有任何最新消息，但等確定確切的時間表之後，我們會再公開提供更多資訊。 |
| 多種觸發條件類型 | 要求提高觸發事件登錄作業的彈性。 | 我們提議針對匯總 API 使用簡化系統，讓廣告技術人員能更靈活地控制事件層級和可匯總報表。 |
| 判定結果 | 要求接收評估資料，以便瞭解廣告空間成效是否良好。 | 感謝您提供意見回饋，並希望進一步瞭解這項要求的適用情形。 |
| 轉換到期日 | 要求支援使用觸發條件代碼的轉換期限，而非只支援來源代碼。 | 感謝您的意見回饋，並希望您進一步釐清這項要求的適用情形。 |
| 批次報表 | 要求在批次報表中納入其他評估資料。 | 非常感謝您提供意見，我們會繼續思考對匯總服務的影響。我們想瞭解廣告技術對批次處理報表的想法、預期頻率，以及有關批次策略在一整年內如何變化的意見回饋。 |
| Epsilon | 何時會判定ε 的價值？ | 我們正積極與生態系統測試者合作，共同闡明 ε 價值，以及如何在 Google Analytics (分析) 中導入此價值。這項數值會對外公開，我們還會展開討論，共同促成決策價值。如果你有任何意見回饋，請在這個 GH 問題中張貼。 |
限制轉換追蹤
使用者代理程式縮減
| 意見回饋主題 | 摘要 | Chrome 回應 |
| 部署依附元件 | 解決結構化使用者代理程式 (SUA) 部署依附元件。 | 我們已經推出「第 4 階段」，對 101 以上版本的所有 Chrome 使用者來說，可降低版本。請按這裡查看更新。 |
| 測試 | 要求延長 Meta 的使用者代理程式縮減來源試用期限。 | 為配合規模較大的網站，我們延長了來源試用並取得權限來移除流量限制。寬鬆的流量限制適用於任何網站，無論規模大小都適用。 |
使用者代理程式用戶端提示
| 意見回饋主題 | 摘要 | Chrome 回應 |
| (第 2 季也會提供這份報表)
反詐欺 / 反濫用疑慮 |
透過通用 Analytics (分析)-CH 可能無法使用部分功能：點擊追蹤程式和詐欺點擊。 | 第 3 季更新：
我們收到許多公司提出的正面意見回饋，指出他們並未對反詐欺管道造成任何負面影響 (請按這裡和這裡查看結果)。 我們的團隊正在與反詐欺和評估相關人士持續調查這些潛在問題。 |
| 權限政策 | 權限政策是否快取？ | 未快取 Permission-Policy，如這個 GitHub 問題所說明。 |
Gnatcatcher (編輯中)
| 意見回饋主題 | 摘要 | Chrome 回應 |
| 地理位置用途 | Gnatcatcher 可能會妨礙合法的地理位置用途，例如根據地理位置進行內容個人化。 | 我們正在與利害關係人合作，確保 Chrome 持續支援 IP 位址的正當使用情境。 |
強化跨網站隱私界線
第一方集合
| 意見回饋主題 | 摘要 | Chrome 回應 |
| 政策 | 請留意 FPS 和 CMA 在「適用的資料保護法規」中所述的承諾使用條款，其受 GDPR 並未限制某組站內的網站數量，而 FPS 規定的限制為 3 個。 | Google 致力於設計及導入 Privacy Sandbox 提案，確保自己不會偏好 Google 自家業務，導致競爭品質失真，以及考量在數位廣告、發布商和廣告客戶之間的競爭影響，以及隱私權結果對隱私權結果是否符合《適用資料保護法規》中規定的資料保護原則的影響。在此提出的問題未揭露任何與 GDPR 不相容的問題。我們會繼續與 CMA 密切合作，確保我們所做的努力符合這些承諾。詳情請參閱下方的「回應意見回饋的變更」一節。 |
| 說明文件 | 要求提供其他範例及更新現有說明內容。 | 說明中的示例正在審核中，並視需要釐清或移除。 |
| 偏好設定共用 | 對各方共同主導的提案。 | 歡迎提供意見回饋，並積極參與 這裡討論的理由。 |
| 違規處置 | 透明的違規處置程序可能會遭到惡意行為人濫用。 | 我們很重視意見回饋，也積極與 GitHub 上的相關人員交流 (考量這個問題中提到的要點，並希望納入這個問題中提出的建議)，以評估此風險並找出潛在的因應措施。 |
| 共同擁有權 | 機器可讀取的常見擁有權聲明提案 | 歡迎對提案提供意見。 |
| 子網域擁有權 | 如果不同的子網域分別使用不同的資料控管者、不同的隱私權政策或由不同實體營運，是否應納入同一個第一方集合？ | 我們計劃根據意見回饋，移除常見的 eTLD 使用案例。 |
| 緩解濫用行為 | 要求進一步瞭解濫用緩解措施。 | 我們正在考慮這項流程的管理方針，且將於未來幾個月內分享更多細節。 |
| 潛在的攻擊向量 | 舉例來說，如果網頁含有容易找到的網頁，系統可能會透過欺騙性相關聯的網頁，將流量帶往其他以欺騙方式呈現的獨立網頁。 | 我們會積極收集大眾意見，並設法解決這個問題。 |
| 設定驗證 | 透過同意的通用政策驗證組合。 | 網路標準社群及廣大生態系統的各位成員指出，我們無法採取這個做法。 |
| 網域限制 | 要求擴大相關網域的數量。 | 我們目前正積極討論 FPS 的網域限制，也希望社群針對其使用案例所需的相關網域數量提供更多意見回饋。 |
| 部分服務互動 | 對服務和相關聯的子集合互動有疑慮。 | 感謝你提供寶貴意見，並會設法在日後的規格中更明確地說明這一點。 |
| (第 2 季也會提供這份報表)
加強隱私防護 |
如果相同組合中擁有過多網站，則可能導致使用第三方 Cookie 的結果類似。 | 第 3 季更新：
最新的提案建議「關聯」子子集 (不含 ccTLD 和服務網域) 最多三個網域。Chrome 正積極與生態系統互動，以判定此限制是否適當。 |
| (第 2 季也會提供這份報表)
常見的隱私權政策規定 |
我們無法為所有產品和管轄區採用相同的隱私權政策。 | 第 3 季更新：
但以往的隱私權政策不再是同一集合中的規定。 |
Fenced Frames API
| 意見回饋主題 | 摘要 | Chrome 回應 |
| 為什麼要新增元素，而不是 iframe 中的屬性？ | 與提案「Frenced Frame」(而非現有的 iframe 提案) 有關的問題。 | 歡迎提出寶貴意見，也歡迎與我們分享 這裡所討論內容的當前狀態。 |
| 圍欄框架中交集觀察器 | 關於 Fenced Frame 中資訊可視度的問題。 | 我們目前正在進行討論，也在本文件和 GitHub 上的註解期內提供這項功能。我們歡迎合作夥伴提供應用實例，進一步瞭解如何提供支援。 |
| 支援影片和原生廣告空間 | Fenced Frame 是否支援影片和原生廣告空間？ | 就影片播放功能而言，Fenced Frame 與 iframe 並無不同，因此任何公開文件中並未明確指出。如果發現影片廣告有任何問題，歡迎提供意見，協助我們展開進一步調查。 |
| Web Bundle | 日後使用 Fenced Frame x FLEDGE 時，網頁組合的廣告放送 / 顯示功能是否會成為必備條件？ | 長期的目標，是支援網路組合，以在圍欄頁框中顯示廣告素材。不過，目前的 FLEDGE 實作不支援這項功能，必須轉譯從 RenderUrl 擷取的 HTML 資源。 |
| 素材資源尺寸 | 請求 Render_url 支援版位高度和寬度的巨集，以便我們以適當大小的廣告素材 | 我們會積極討論這裡。 |
Shared Storage API
| 意見回饋主題 | 摘要 | Chrome 回應 |
| FLEDGE 整合 | 共用儲存空間和 FLEDGE 的整合方式為何？ | 儘管目前我們尚未實行相關措施，但還是希望能夠瞭解這個做法，看看能否保護隱私權。我們建議有興趣的人士前往共用儲存空間 GitHub 存放區或 FLEDGE GitHub 存放區，針對這個提案可提供的潛在用途。。 |
| 資料保留 | 清除共用儲存空間可以降低實用性。是否有延長保留期限或刪除個別鍵/值的功能？ | 我們一直致力於在兼顧使用者隱私和實用性之間取得平衡。歡迎針對調整事宜提供意見，並鼓勵合作夥伴在測試共用儲存空間時提供更多意見回饋和詳細資料。 |
| 負面信號 | Mozilla 針對「共用儲存空間」提案發出的負面信號。 | 謝謝 Mozilla 仔細審查我們的提案。我們計劃在不久的將來回應他們的意見。 |
方塊
| 意見回饋主題 | 摘要 | Chrome 回應 |
| 分區要求 | 針對第一方 Cookie 的「分區」屬性新增明確行為規定。 | 我們已在 PrivacyCG 通話上討論過相關內容，並在 GitHub 問題 中再次提供附註。我們會持續與瀏覽器、開發人員和隱私權社群攜手合作，配合使用者行為並指定這個行為。 |
| 經過驗證的嵌入 | CHIPS 可能會影響目前的 SSO 登入流程，因為不同分區會影響已驗證的嵌入項目。 | 我們明白經驗證的嵌入項目用途，目前正努力探索解決方案。 |
| Cookie 分區限制 | 擔心目前的 10 個 Cookie 限制可能不足以用於特定用途。 | 我們將取消 Cookie 數量上限，直到 12KB 的記憶體限制為止。這樣做可讓我們化解對於 Cookie 限制的疑慮，同時確保效能和瀏覽器記憶體用量不會受到負面影響。 |
| 來源試用時間軸 | 延長 OT 必須遵守主機名稱限制規定。 | 根據大環境的意見回饋，我們已延後來源試用期限。 |
| Chrome 的測試限制 | 由於 Chrome 目前限制，可能無法在 Firefox 中測試 CHIPS。 | Firefox 的實作方式大致上相同，Chrome 的 Cookie 上限較低，而 CHIPS 是選擇採用的機制，但 Firefox 預設為分區。 |
| (第 2 季也會提供這份報表)
經過驗證的嵌入 |
登入狀態是否會保留 CHIPS ？ | 第 3 季更新：
目前系統不會保留登入狀態，但這並非 CHIPS 的預期用途。我們明白經驗證的嵌入項目用途，目前正努力探索解決方案。 |
FedCM
| 意見回饋主題 | 摘要 | Chrome 回應 |
| (第 2 季也會提供這份報表)
潛在的攻擊向量 |
透過連結裝飾和時間攻擊來防範攻擊向量。 | 第 3 季更新：
我們已與 Mozilla 合作，共同瞭解如何解決時間攻擊的問題，詳情請參閱這篇文章。我們正在設計這項架構變更的原型，並預計在接下來幾季中執行實驗。 |
| 識別資訊提供者 | 帳戶選擇工具：單一識別資訊提供者。要求允許多個識別資訊提供者。 | 我們與瀏覽器廠商和 FedID CG 合作，說明如何允許多個識別資訊提供者，並提出了幾個值得嘗試的公式。提案說明請參閱這裡，我們預計在接下來幾季開發原型並進行實驗。 |
| 聯盟的已知問題 | 要求列舉在第三方 Cookie 淘汰後聯盟可能發生問題的情況。 | FedID CG 有一個工作項目，列出聯盟在這裡和這裡的聯盟中斷方式。同時也在這裡建立決策矩陣，用於將故障對應到 Web Platform API。 |
| 否定參數 | Nounce 參數會影響登入流程嗎？ | 這就算是跨網站追蹤，我們仍在收集相關資料並分析如何處理這類情況。 |
| 使用者同意 | 為每個來源連結不同的依賴方 (RP) 和使用者同意聲明。 | 這項規格無法控制相同網域內來源共用 Cookie 的方式。規格允許來自 IDP 來源的 idToken 來源，但由 RP 決定使用者的登入狀態是否應儲存在鎖定於該單一來源的 Cookie 中，還是與來源網域相同的 Cookie 共用。 |
| IDP 帳戶 可攜性 |
如果使用者選擇在兩個 IdP 之間轉移 IDP，請使用者選擇遷移 IdP。 | 使用者似乎必須直接在所選新 IDP 的註冊頁面中進行，而不是透過 FedCM API。 |
| 帳戶刪除 | 透過 IdP 撤銷帳戶的 IDP 撤銷權限。 | 這項功能要求仍開放開放使用，也正在調查中。 |
| UI 聲明 | 宣稱瀏覽器特定介面的部分。 | 如要解決這個問題，請參閱提取要求相關說明。 |
| IDP 參照連結網址檢查 | IDP 會檢查 RP 的參照網址。 | 在規格中新增了必要的 IDP 參照網址檢查。請參閱提取要求一節。 |
| 登入流程 | 依 RP 偏好設定自訂登入流程。 | 我們歡迎您的想法，也積極討論。 |
打擊垃圾內容和詐欺
Trust Tokens API
| 意見回饋主題 | 摘要 | Chrome 回應 |
| 詐欺與濫用 | 是否有相關工具可以確保機器人未誘騙核發者提供權杖？機器人未接管核發給真實使用者的權杖，並防止機器人核發惡意權杖嗎？ | 雖然機器人或許可以從核發者取得權杖，但我們建議核發機構設定權杖的頻率，以及核發權杖和發布權杖的完善方法，以防惡意人士試圖規避這類機制。如果核發者在核發權杖中缺乏完善邏輯，則生態系統的信任度可能會降低，因為網站是取決於更強大的核發機構。 |
| 詐欺與濫用 | 信任的權杖兌換者能否指定他們只能接受特定實體提供的信任權杖？ | 可以。說明的「信任權杖兌換」一節說明瞭這項功能的運作方式。 |
| 詐欺與濫用 | 信任權杖核發機構可以定義兌換者名單，並禁止他人兌換權杖嗎？ | 目前還不行，但我們的團隊正在調查這個用途。 |
| 時間軸 | Trust Token API 何時開放正式發布？ | 待確認時程內，我們就會公開提供更多資訊。 |
| (第 2 季也會提供這份報表)
維護負擔 |
不清楚通訊協定版本的支援時間長度。 | 第 3 季更新：
我們正努力為 API 新增支援多個並行版本的支援功能，好讓在不同版本之間流暢地轉換，不過支援 / 淘汰的時程仍在開發階段。 |