2022 年第 4 季季度報告，摘要說明收到的 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 回應 |
|---|---|---|
| (也列於第 3 季) 不同類型的利害關係人認為的實用性 |
擔心 Privacy Sandbox 技術偏袒大型開發人員，且小型網站的貢獻度高於一般 (大型) 網站 | 我們的回覆與第 3 題相同： 「Google 已向 CMA 承諾，在設計及實施 Privacy Sandbox 提案時，不會偏袒 Google 自家業務，導致競爭環境扭曲，並會考量數位廣告競爭環境、以及規模不論大小的發布商和廣告客戶所受的影響。我們會持續與 CMA 密切合作，確保我們的工作符合這些承諾。 隨著 Privacy Sandbox 測試進展，我們會評估新技術對不同類型的利害關係人帶來的效益，在這方面，意見回饋至關重要，特別是具體且可行的意見回饋，有助我們進一步改善技術設計。 「我們與 CMA 合作，開發了量化測試方法，並支持 CMA 發布實驗設計備忘錄，為市場參與者提供更多資訊，並提供機會讓他們對建議的做法發表意見。」 |
| (也於第 3 季回報) 說明文件要求 |
要求提供更多資源，詳細說明如何管理測試、分析和導入作業 | 第 4 季更新： 我們很高興開發人員認為目前的資料很實用，並會持續提供更多資料，協助開發人員瞭解新技術如何發揮效用。在過去一個季度，我們在 privacysandbox.com 新增了「新聞與更新」專區，並發布了詳細的評論，說明 Privacy Sandbox 如何協助提升廣告關聯性。 我們也舉辦了公開的開發人員諮詢時間，分享最佳做法和產品示範，並與產品和工程主管進行問答，讓開發人員可以即時討論/提問。 |
| Core Web Vitals | Privacy Sandbox API 延遲時間會如何影響 Core Web Vitals？ | 盡可能降低延遲時間是 Privacy Sandbox API 的主要設計目標。我們目前預期，API 延遲時間對網站的 Core Web Vitals 影響應會降到最低，因為大多數 API 都是在網站初始轉譯後才會呼叫。我們會持續監控並改善各個 API，進一步縮短延遲時間，也歡迎您持續測試並提供意見回饋。 「FLEDGE 競價成效」一節的 FLEDGE 專區中，會說明即時出價程序中的延遲問題 |
| 互通性 | 與其他潛在解決方案的互通性相關疑慮 | Privacy Sandbox 的目標是保護使用者免於遭受跨網站追蹤，同時滿足網路生態系統的需求。為達成這項目標，我們將淘汰可進行跨網站追蹤的舊版瀏覽器技術 (例如第三方 Cookie)，並提供專為支援特定用途而設計的新技術。 Privacy Sandbox 提案會限制從使用者裝置流出的資料，以提升隱私權。這些提案不會對網站在從瀏覽器收集資料後，分享或以其他方式處理資料的能力設下技術限制。因此，這些技術不會阻止公司簽訂「資料管理」協議或任何其他類似的合約關係。同樣地，這些政策也不會限制使用者透過其他方式同意分享資料。 為避免誤解，Google 承諾會以相同方式，將 Privacy Sandbox 技術套用至所有網站，包括 Google 產品和服務。Chrome 停止支援第三方 Cookie 後，Google 也將遵守承諾，不會使用其他個人資料 (例如使用者同步的 Chrome 瀏覽記錄) 追蹤使用者，以便指定目標或評估數位廣告成效。 |
顯示相關內容和廣告
主題
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 對 Google 搜尋排名的影響 | 詢問網站的 Topics API 支援功能是否會用來做為 Google 搜尋結果排名的潛在信號 | 部分網站可能會選擇不採用 Topics API。Privacy Sandbox 團隊並未與搜尋團隊協調或要求對方使用網頁排名，作為網站採用 Topics API 的誘因。Google 已向 CMA 確認，Google 搜尋不會將網站選擇不採用 Topics API 的決定做為排名信號。 |
| 主題分類器 | 除了主機名稱之外，請新增網址和網頁內容，以便判斷網頁的 Topic，進而提升對各方利益相關者的效用。 | 使用者的瀏覽記錄目前是根據網站的網域名稱進行分類。Chrome 會持續評估在主題分類中考量網頁層級中繼資料 (例如網頁網址和/或內容的所有或部分元件) 的選項。任何實用性改善措施都必須權衡隱私權和濫用風險。 舉例來說，針對中繼資料，其中一些風險包括： - 網站修改網頁層級中繼資料，以便將不同的 (可能屬於敏感) 意義編碼為主題； - 網站修改網頁層級中繼資料，藉此誤導主題以謀取經濟利益； - 網站以動態方式修改網頁層級中繼資料，用於跨網站追蹤 |
| (也於第 3 季回報) 對第一方信號的影響 |
主題信號可能非常有價值，因此會降低其他第一方興趣信號的價值。 | 我們的回覆與第 3 題相同： 「我們認為按照興趣顯示廣告是網路上的重要用途，Topics 就是為了支援這類用途而設計。如 [第 3 季報告]所述，其他生態系統利益相關者表示擔心，Topics 可能不夠實用，無法提供價值。無論如何，我們都會持續改善分類方式，並希望分類方式能隨著生態系統測試和意見回饋而有所調整。」 |
| 更新分類 | 分類清單如何更新？ | 我們正積極尋求意見回饋，瞭解分類法對生態系統最有用。初始 Topics API 提案中所包含的分類旨在啟用功能測試。Chrome 正在積極考慮多種更新分類法的做法。舉例來說，Chrome 可能會利用每個主題的商業價值概念，決定日後要納入哪些類別。 |
| 主題區域分類器成效 | 主題分類器在區域網域中的表現不佳 | 我們會持續改善分類器。根據收到的意見回饋，我們正在考慮擴充 Topics 覆寫清單，根據我們的分析，這麼做可提高全球涵蓋率並提升準確度。 簡單來說，Topics API 分類有兩個相關元件：(1) 包含前 1 萬個網站及其主題的覆寫清單，以及 (2) 可將主機名稱分類為主題的裝置端機器學習模型。擴充覆寫清單 (1) 後，我們就能改善分類器在分類效果不佳的區域的效能。 |
| 一週時間點 | 對於想要做出短期決策的使用者來說，一週的時間太長。 | 我們正積極研究適合的週期長度，也歡迎 提供更多意見回饋，讓我們瞭解哪種週期對生態系統最有利。 |
| 擷取 HTTP 標頭 | 擔心主題的 HTTP 標頭擷取資訊不足 | 我們正在處理標頭和 fetch() 的問題。相關資訊也已在這裡提供。我們也在說明中新增了 skipObservation 資訊。 |
| 主題功能只會協助廣告客戶，不會協助使用者 | Topics/Privacy Sandbox 似乎是一種以產業為重點的方法。使用者的好處不如產業的好處那麼明顯。 | 我們認為，Topics 支援按照興趣顯示廣告，可讓使用者享有免費且開放的網路環境，且與第三方 Cookie 相比，Topics 大幅提升隱私權。如果移除第三方 Cookie 而沒有可行的替代方案，可能會對發布商造成負面影響，並導致更糟糕的做法 ，這些做法不但不夠隱私、不透明，而且使用者無法實際重設或控制。許多公司正積極測試主題和 Sandbox API，我們也致力於提供工具，以提升隱私權並支援網路。 W3C 技術架構小組最近發布了 Topics API 的初步觀點，我們將公開回應。在這個階段，Google 收到生態系統提出的疑問，詢問這項審查對 Topics API 的開發和推出作業有何影響。因此，我們想重申，我們今年仍會在 Chrome 穩定版中推出這項功能。雖然 Google 感謝 W3C 技術架構小組的意見，但我們認為，與 CMA 和生態系統協商，繼續努力開發及測試主題，是至關重要的事。 |
| 資料外洩 | 擔心主題會在未經授權的情況下外洩給其他網站 | 由於 Topics API 的設計，單一發布商 (甚至是較小的發布商群組) 的資料不太可能以任何方式外洩。發布商網站也能完全控管 Topics API，並透過權限政策禁止存取此 API。 |
| 缺乏可用於測試的廣告主 | 發布商擔心目前無法向廣告主說明主題的價值。 | 我們預計在 2023 下半年開放所有廣告相關 API 供整合測試，並啟用生態系統分析，讓廣告主瞭解「主題」的價值。測試和發布結果的過程將由 CMA 監督，該機構會審查資料、分析和方法。我們鼓勵生態系統與 Google 和 CMA 分享意見回饋。 |
| Topics 和 FLEDGE | 請提供更多資訊，說明如何在 FLEDGE 的出價邏輯中使用 Topics | 您可以在 FLEDGE 的出價邏輯中使用主題。我們也正在製作整合指南，其中會提供更多實作詳細資訊。 |
| 主題呼叫端的自訂排名 | 允許呼叫端調整排名 | 為每項廣告技術自訂主題排名或值時，可能會出現廣告技術影響傳回主題的機制，因此會產生指紋辨識向量。 |
| 主題來電者優先順序清單 | 允許呼叫端提供 Topics API 會根據資格條件傳回的主題，並依優先順序列出清單。 | 我們目前正在進一步討論這個想法 ，歡迎提供更多意見。 |
FLEDGE
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| Google Ad Manager | 擔心 Google Ad Manager 是 FLEDGE 競價的最終決定者，且會偏袒 Google 發布商廣告代碼和 Google Ad Manager。 | FLEDGE 可讓每位發布商選擇競價結構，包括頂層和元件賣家。元件競價中的每位買家和賣家都知道頂層賣家是誰，並可選擇是否出價。 |
| 測試 FLEDGE 的參與者人數不足 | 要求鼓勵更多公司測試 FLEDGE，例如改善 API 功能，並減少使用指紋等侵犯隱私權的替代方案 | 我們與 CMA 和 ICO 密切合作，在其指導下分階段推動 Privacy Sandbox 計畫，而 FLEDGE 功能測試也已證明我們具備必要的穩定性和功能。Google 持續鼓勵生態系統測試 Sandbox API，最近發布了「提升廣告相關性」說明文件，說明 FLEDGE 和其他 API 如何在第三方 Cookie 淘汰後，協助廣告產業支援重要用途。 Privacy Sandbox 的其他部分已支援追蹤防範措施 (請參閱 UA-CH、IP 保護和跳出率追蹤防範措施)，並會持續改善。Google 的目標並非讓 FLEDGE 成為唯一可行的指定目標解決方案，而是持續致力於與業界和監管機構合作，在 Chrome 瀏覽器中推動最佳的隱私權保護廣告技術。 |
| 機器學習的用途 | 我們將在 FLEDGE 和歸因報表中提供更多指引，說明如何透過機器學習使用案例訓練競價出價演算法 | 我們瞭解有必要協助測試人員找到最實用的 Privacy Sandbox 技術應用方式。我們已開始發布指南，針對如何將 Privacy Sandbox API 的各個層面用於機器學習輸入內容提供具體說明。最新的文章「提升廣告相關性」討論了廣告產業如何運用這些信號進行機器學習，我們也計畫在日後持續發布這類指南。 |
| 查詢 FLEDGE 鍵/值 (K/V) 伺服器 | 為何 K/V 伺服器可公開查詢？ | K/V 伺服器的目標是向 FLEDGE 競價提供即時信號。因此，K/V 伺服器必須可從執行 FLEDGE 競價作業的使用者裝置存取，也就是說，該伺服器必須公開。只有已擁有金鑰的一方才能擷取儲存在 K/V 伺服器中的值。因此，如果廣告技術只將金鑰提供給興趣群組中的瀏覽器，且不使用可隨機猜測的金鑰，那麼只有需要值才能執行競價的瀏覽器才能擷取該值。 |
| 如何指定日期/時間？ | 支援出價邏輯函式中的日期物件。 | 方法有好幾種，買家可以要求賣家提供目前的日期和時間，而賣家也應該可以輕鬆向所有買家提供這項資訊。買方也可以在即時鍵/值回應中提供日期和時間。最後，買方可以提供日期和時間，做為個別買方信號中的內容回應的一部分，賣方可將這些資訊傳遞給買方的 generateBid 指令碼。 |
| 使用者偏好設定 | 使用者可以選擇在透過 FLEDGE 或其他替代方案放送廣告素材時，封鎖特定廣告客戶的廣告素材。 | 使用者可以選擇停用 Chrome 中的廣告 API。針對特定廣告，相關廣告技術供應商最適合提供控制項，以便控制要顯示哪些廣告素材，或如何選取廣告素材。 |
| 更清晰的時間表 | 請要求進一步瞭解 FLEDGE 中可用的隱私權保護措施，例如要求使用 Fenced Frames。 | 我們預計在第 1 季公布更詳細的時程。 |
| 回報疑問 | 要求進一步說明 FLEDGE 報表如何與其他 API (例如 Fenced Frame 和 Private Aggregation API) 搭配運作。 | 我們預計在未來幾週內，發布關於 Private Aggregation API、FLEDGE 和 Fenced Frames 之間互動的說明。 |
| 即時出價和 FLEDGE | 說明如何將 FLEDGE 與標準即時出價整合。 | 廣告技術供應商要能即時出價，必須能存取事件層級資料，並能輕鬆整合至 ARA。我們預計在第 1 季發送這兩項功能的最新資訊和說明。 |
| FLEDGE 競價成效 | 測試人員回報 FLEDGE 競價的延遲時間過長 | 我們感謝測試人員分享結果和用途，並提供一些改善 FLEDGE 效能的方法。 同時，我們也為瀏覽器新增了工具，讓開發人員更能診斷導致競價速度變慢的原因，並且已系統性地解決觀察到的延遲主要來源。最近的改善項目包括緩慢競價的逾時、快速出價方篩選技巧、重複使用 FLEDGE 工作項以避免支付啟動成本，以及讓內容相關廣告請求與 FLEDGE 啟動時間和網路擷取作業並行執行。我們預期 Chrome 開發人員和 FLEDGE 測試人員會持續討論 API 的實際使用經驗，因此延遲時間的最佳化調整工作也會持續進行。 |
| 興趣群組大小記憶體限制 | 要求將單一興趣群組的大小上限從 50 KB 提高。 | 我們正在積極考慮這項要求，並希望能收到有關限制值的意見回饋。 |
| 將 FLEDGE 放送的資料與第一方 Cookie 結合 | FLEDGE 是否支援與廣告主的第一方資料整合？ | FLEDGE 的設計目的是支援廣告主使用現有的第一方資料放送廣告。不過，FLEDGE 不支援廣告客戶瞭解使用者在廣告客戶網站以外的任何網站上的瀏覽行為。將非網站瀏覽行為附加至第一方資料，違反了 Privacy Sandbox 的目標。 我們預計在接下來的幾週內，分享整合指南，進一步說明 FLEDGE 如何支援第一方資料整合。 |
| K-匿名 (k-anonymity) 值 | 如何決定「K」值，以及是否會發布？ | 我們仍在確定「K」值，並會在計畫進展時提供更多資訊。我們想進一步瞭解未知的 k 值如何影響 FLEDGE 準備作業和機器學習模型訓練範圍，也歡迎您提供其他意見回饋。 |
| 支援多個 SSP | FLEDGE 如何支援多個 SSP？ | 如這份提案所述，FLEDGE 支援多個賣方競價。 |
| 出價邏輯的顯示方式 | 擔心 DSP 出價邏輯會在 JavaScript 中公開 | 在目前的設計中，其他人可以存取出價邏輯 JavaScript，但我們歡迎更多意見回饋，瞭解為何這會讓 DSP 感到擔心。 |
| prebid.js | 在 FLEDGE 中支援 prebid.js 的時間表為何？ | 只有 Prebid.js 7.14 以上版本支援 FLEDGE 模組。凡是有意參與測試的發布商，都必須加入 FLEDGE 模組，並升級 Prebid 例項。 |
| FLEDGE 中的使用者定義函式 | FLEDGE 如何支援使用者定義函式 (UDF)？這些函式可由使用者編程，用於擴充 API 的功能。 | 如需說明，請參閱這篇文章。這項功能仍在完善中，歡迎您提供更多意見回饋，協助我們改善使用情境。 |
| 放寬興趣群組資源的同源限制 | 要求放寬興趣群組資源的同源限制，以便使用特定廣告技術用途 | 在目前的 FLEDGE 實作中，biddingLogicUrl、biddingWasmHelperUrl、dailyUpdateUrl 和 trustedBiddingSignalsUrl 的來源必須與興趣群組擁有者相同。如這篇文章所述，這項限制旨在防止攻擊者利用特定漏洞。 |
| interestGroup 擁有權 | 要求限制廣告技術供應商是否可在不同網站上，針對相同的興趣群組使用 joinInterestGroup | 我們重視的是目標對象的使用方式，而非建立方式。我們正在討論可能的做法，也歡迎您提供更多意見。 |
| Key Value 伺服器金鑰到期 | 討論在對應的興趣群組到期後移除伺服器金鑰 | 我們正致力於處理金鑰到期問題，並希望能收到意見回饋。 |
評估數位廣告成效
歸因報表 (和其他 API)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 來源試用版流量 | 目前的試用版流量不足以進行實用性測試。 | 目前的 Origin Trial 旨在讓生態系統參與者進行功能測試，確保 API 能正常運作。我們瞭解，在各種 Privacy Sandbox API 的開發作業更成熟後，就需要更多流量才能執行公用程式測試。根據目前的測試時程，我們預計在 2023 年第 3 季正式發布 (即針對特定用途開發的技術正式發布，並開放 100% 的 Chrome 流量存取) 後，就會實現這項功能 (請參閱 privacysandbox.com 上的最新時程表)。我們歡迎您針對需要額外流量的用途測試提供其他意見回饋。 |
| 不同 Privacy Sandbox 評估 API 的功能重疊 | 透過 Privacy Sandbox 使用多種重疊的評估方法，可能會增加複雜度，例如 Attribution Reporting API 和 Private Aggregation API。 | 我們正在努力改善說明文件，以便說明 API 的不同用途。如果您認為我們有任何說明不足之處，歡迎提供額外意見回饋。舉例來說，Attribution Reporting API 專門用於支援轉換評估，而 Private Aggregation API 和 Shared Storage 則是通用 API，可支援更廣泛的跨網站評估用途。 |
| 重試失敗的報表要求 | 說明報表要求失敗時，系統會嘗試幾次。 | 我們已發布相關指南。總而言之，只有在瀏覽器執行/上線時，系統才會傳送報表。首次傳送失敗後，系統會在 5 分鐘後重試傳送報表。在第二次失敗後，系統會在 15 分鐘後重試報表。之後就不會傳送檢舉內容。 |
| 報表延遲 | 報表的預估延遲時間為何？ | 我們希望收集更多意見回饋，瞭解生態系統中哪些報表出現延遲情形，並同時收集相關資料，進一步評估這些延遲情形。 |
| 預先轉譯網頁 | ARA 歸因功能是否適用於預先載入的網頁？ | 歸因註冊作業會在預先算繪網頁上延後，直到啟用 (實際點擊或瀏覽發生) 為止。這表示我們會延遲 `attributionsrc` 要求的通知。 |
| 評估轉換升幅 | 如何在同一網域中使用 AB 測試評估轉換升幅 | 網站可以透過歸因報表，在同一個網域上進行 A/B 測試，評估轉換升幅。他們可以使用匯總 API 將 A/B 參數編碼為鍵，然後依據這些鍵值區塊，取得轉換值的摘要報表。 |
| (也列在第 3 季) 跨網域轉換 | 如何追蹤跨網域的轉換，例如有 2 個以上目的地 | 第 4 季更新： 我們已發布提案，移除到達網頁目的地限制，以便追蹤跨網域對話。這個提案已實施。 |
| (也於第 3 季回報) 轉換報表中的到期日設定 |
要求支援報表篩選器 / 到期時間小於 24 小時 | 第 4 季更新： 我們已分享這個提取要求 ，將到期日和報表時間範圍分開，以便在報表延遲和轉換到期日之間取得平衡。這項功能現已在 M110 推出。 |
| 詐欺與濫用 | 廣告主和行銷人員要求能根據廣告放送的發布商網站，切割及匯總資料，以便進一步瞭解潛在的廣告詐欺行為 | 我們正在積極討論這項意見回饋，歡迎提供更多意見。 |
| (第 3 季也曾提及) 事件層級報表延遲 | 事件層級報表的延遲時間為 2 到 30 天，對某些用途而言可能太長。 | 事件層級報表的預設報表期間為 2、7 和 30 天。您可以使用「expiry」參數修改這項設定。Ad-tech 可以設定到期日 (最短為 1 天)，以便在 2 天內取得潛在報表。我們將到期日的細緻度限制在 1 天，做為隱私權保護機制，因為更精細的報表可能會導致時間攻擊。此外，您也可以為事件層級和匯總報表設定獨立的「到期日」參數。請參閱這篇文章。此外，Google Ads 不會透過 Attribution Reporting API 取得其他廣告技術無法取得的任何特殊報表時間範圍。 |
| 相同報表來源規定 | 要求移除來源登錄來源必須與轉換登錄來源相同的要求 | 我們建議使用 HTTP 重新導向來委派註冊作業，以解決這個用途。歡迎您針對新指南提供其他意見。 |
| 轉換追蹤 | 需要區分轉換是否發生在廣告主設定的特定時段之前/之後 | Attribution Reporting API 可設定歸因來源的到期日和優先順序。透過這兩種方法，您就能將 X 天回溯期內發生的轉換與 X 天後發生的轉換分開歸因。 |
| 雜訊模擬 | 要求模擬每個值層的轉換量，瞭解轉換次數較少的廣告主受到的影響 | 我們會在日後推出的 Noise Lab 版本中，新增模擬這類情況的方法。歡迎提供更多意見。 |
| 行動裝置報表 | 在行動裝置上，Chrome 在背景執行時是否仍會傳送這份報表？ | 目前，即使在行動裝置上，Chrome 在背景執行時也不會傳送這份報表。當 API 與 Android Privacy Sandbox 整合時，這項規定可能會有所變動。請參閱這篇文章。請注意，Android Privacy Sandbox 並非 CMA 接受的承諾內容。 |
| 資料可用性 | 擔心 Google 會透過 Privacy Sandbox API 取得更多資料 | 首先，Google Ads 不會獲得 Attribution Reporting API 或其他 Privacy Sandbox API 的任何優先存取權。這個問題也已在「一般意見」部分的「互通性」中解決，其中包含 Google 的承諾詳細資訊。 其次，就大型和小型網站的差異而言，Google 認為以雜訊為基礎的隱私權保護措施對較小的資料切片影響較大。不過，我們還是可以採取一些緩解措施：例如，透過更長時間的累積資料來解決這個問題。不過，如果是根據非常少量的資料切片 (例如一或兩筆購買交易) 得出的結論，對廣告主來說是否有意義，目前仍不清楚。在原始測試期間，Google 鼓勵測試人員利用這項功能，嘗試各種隱私權和雜訊參數，以便針對這個問題提供更具體的意見回饋。 |
限制隱密追蹤
使用者代理程式縮減
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 在網路生態系統更成熟前，延後使用者代理程式縮減 | 我們沒有足夠的時間因應即將實施的 User-Agent 減少異動。 | 我們在完整報告的「利害關係人疑慮」一節中，針對這項意見回饋提出回應，該節的標題為「Google 與 CMA 的互動情形」。 |
| 在網路生態系統更成熟前，延後使用者代理程式縮減 | 要求在部署結構化使用者代理程式 (SUA) 前，延後使用者代理程式縮減功能的推出時程 | Google Ads 團隊在 2021 年 10 月向 OpenRTB 提出結構化使用者代理程式新增項目 (請參閱規格)，並在 2022 年 4 月發布的 2.6 版規格更新中納入這項項目。 我們有證據顯示，目前已部署並可使用 SUA，如 Scientia Mobile 網誌文章所示，該文章說明如何使用 UA-CH 和 WURFL API 建立 SUA。 |
###
User-Agent Client Hints
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 使用其他反隱匿追蹤技術測試通用 Analytics 代碼 | 指南：如何以整體方式測試所有 Privacy Sandbox API 和指紋技術 | 我們的測試計畫旨在反映開發部分防指紋措施的非同步時程，而非 Sandbox 提案的其他部分。這項措施解決了現實問題，即部分防指紋措施 (例如隱私權預算、IP 保護和跳出率追蹤緩解措施) 將在第三方 Cookie 淘汰後才會全面開發，並準備好推出一般版本。 雖然這些防指紋措施不會納入定量測試，但會根據停滯狀態期間的實際情況進行定性評估。 |
| (第 2 季也有報表) 成效 |
透過 Critical-CH 取得提示的延遲時間 (在首次載入網頁時) | 請參閱下方的專屬 UA-CH 專區 |
| 意見回饋不足 | 生態系統對 UA-CH 變更的意見回饋可能不足，導致生態系統缺乏相關認知。 | 我們會主動分享計畫，確保謹慎推出，盡可能減少干擾。 我們已在 2022 年 3 月 18 日向 W3C 反詐欺社群小組提交 User-Agent 減少計畫和 UA-CH API 相關計畫，並在 2022 年 1 月 20 日向網路支付工作群組和網路支付安全興趣群組提交。在簡報期間或之後，並未提出任何重大疑慮。 Google 已主動與超過 100 位網站管理員互動，收集意見回饋。此外，Google 也透過 Blink-Dev 管道，根據生態系統利益相關者的意見回饋，公開說明使用者代理程式減少功能的推出方式。 |
| 時間 | 對推出時程和業界準備情況的疑慮 | 請參閱下方的專屬 UA-CH 專區 |
| Chrome 平台狀態 | 要求更新 UA-CH 的 chromestatus 頁面 | chromestatus 項目已於 12 月 19 日更新為「Mixed signals」。 |
IP 保護 (原稱 Gnatcatcher)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 加入或退出 | IP 位址隱私權設定是啟用還是停用？ | 我們的目標是為所有使用者提供 IP 保護。為達成這個目標，我們目前正在評估 IP 保護功能的使用者選項。 |
| 第一方資料的 IP 位址用途 | 是否可以使用 IP 位址，將 IP 保護功能後的第一方網域使用者歷程拼接在一起？ | 如先前發布的內容所述，IP 保護功能一開始會著重於第三方內容中的追蹤，也就是說，第一方網域不會受到影響。 |
| 廣告技術用途 | 企業如何透過 IP 保護機制設定防詐措施？ | 我們瞭解 IP 位址在當今網路世界中，是反詐欺措施的重要信號。我們向 CMA 做出的承諾 (第 20 段) 中提到，如果我們未採取合理措施協助網站執行反垃圾內容和反詐欺措施，就不會實施 IP 保護功能。我們會優先瞭解 IP 保護功能對防詐欺用途和偵測功能的影響，以便進一步投資隱私權保護技術，協助企業維護網路安全。我們鼓勵您提供意見，並提供新提案的意見回饋，以便我們滿足安全和反詐欺公司的需求，即使信號會隨著時間而變更也不例外。 |
| 詐欺與濫用 | IP 保護功能是否包含阻斷服務 (DoS) 防護功能？ | 我們致力於在提升隱私權的同時確保網路安全，而防範阻斷服務攻擊是我們設計防濫用用途時的重要考量。我們希望透過 IP 保護功能的設計，以及新的反濫用解決方案，盡量減少 DoS 防護功能受到的影響。由於 IP 保護功能最初著重於第三方嵌入式服務，因此部分利益相關者表示，這項功能對第一方網站的 DoS 保護功能影響有限。不過，我們會持續向大眾徵詢意見，評估 DoS 使用情境的風險，特別是第三方嵌入式服務。 同時，我們也正在研究濫用行為意見回饋和封鎖用戶機制，讓網站或服務能夠封鎖垃圾內容使用者，而不必識別使用者。 |
| 內容篩選 | 搭配 IP 保護功能使用內容篩選功能 | 不同公司在篩選內容和自訂使用者體驗方面，有不同的需求。許多這類用途目前不依賴 IP 位址，因此不受 IP 保護功能影響。舉例來說，如果發布商想提供客製化內容並提高互動率，可以使用第一方 Cookie 或第三方分割 Cookie (CHIP)，瞭解使用者的興趣和先前與發布商的互動情形。舉例來說，如果廣告技術合作夥伴專注於向適當使用者放送適當廣告，則可納入 FLEDGE 和 Topics，以便放送與目前透過第三方 cookie 或其他跨網站追蹤技術放送的廣告類似的成效。 我們也正在研究如何在 IP 保護功能中加入新的隱私權保護機制，例如粗略地理位置，以便在現有機制不足以提供內容篩選功能時，進一步支援這項功能。歡迎針對可能受到 IP Protection 影響的內容篩選用途，提供更多意見回饋。 |
| (也列於第 3 季) 地理位置用途 |
IP 保護功能可能會導致合法的地理位置用途無法在日後運作，例如根據地理位置提供個人化內容。 | 第 4 季更新： 我們正與利害關係人合作，確保 Chrome 持續支援 IP 位址的合理用途。我們正在尋求生態系統對 IP 地理位置精細程度的意見回饋，請前往這個頁面提供意見。 |
隱私預算
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 更清楚的說明文件 | 提供更多範例，讓利益相關者瞭解導入隱私公開程度上限後，可能會受到哪些限制 | 隱私公開程度上限提案仍在積極討論中，目前尚未有任何瀏覽器導入這項功能。最早可供使用的日期代表可強制執行隱私公開程度上限的最早日期。我們會在 2024 年淘汰第三方 Cookie 後才實施這項政策。我們目前沒有其他文件可提供。 我們會在提案更明確後，提供更多詳細資訊。在此期間，歡迎利害關係人提供任何意見回饋，協助我們擬定提案。 |
強化跨網站隱私界線
第一方集合
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| (也於第 3 季回報) 網域限制 | 要求擴充相關網域數量 | 第 4 季更新： 我們已發布 FPS 供本機測試，包括在 GitHub 上模擬提交程序，以及用於本機測試 rSA 和 rSAFor 的標記。我們也為 FPS 開發人員舉辦了兩場公開會議，持續針對相關子集的用途相關問題提供解答。我們建議開發人員測試 FPS 功能，並針對相關子集的網域限制，提供 FPS 在其用途中的可用性影響。 我們在 WICG 通話中已說明，Chrome 致力於提供可用的解決方案，同時考量使用者的隱私權益。因此，我們希望社群能提供意見回饋，針對可能受到網域限制的特定用途提出建議，以便團隊能考量如何處理這些用途，同時繼續保護使用者隱私。 |
| 要求提供更多有關濫用行為緩解措施的詳細資訊 | 如果網域遭新增至未經同意的組合，會發生什麼事？ | 我們已於 2022 年 12 月 2 日發布第一方集合資料提交指南。 提交指南中說明，任何套件變更管理都會遵循 GitHub 的驗證程序，包括驗證擁有權，這應該可以降低這類風險。 |
| 因應濫用行為 | 擔心第一方集合組成可能遭到濫用 | 我們正在研究如何擴大子集類型的技術檢查，並積極尋求社群的額外意見回饋。 |
| Google Ads 用途 | 關於是否應使用第一方集合來支援廣告指定目標的問題 | 我們不支援第一方集合針對廣告指定目標的用途，建議您使用適用於這類用途的廣告 API。 |
| (第 3 季也已回報) 政策 | 擔心 FPS 與 CMA 在「適用的資料保護法規」方面的承諾不一致，因為 GDPR 並未對一組網站的數量設限，而 FPS 則設有 3 個上限 | 我們的回覆與第 3 題相同： 「Google 會持續向 CMA 承諾，以不會偏袒 Google 自家業務的方式設計及實施 Privacy Sandbox 提案，並考量對數位廣告、發布商和廣告主競爭的影響，以及對隱私權結果和適用資料保護法規中所載資料保護原則的遵循程度。您表達的疑慮並未揭露與 GDPR 不相容的任何問題。我們會持續與 CMA 密切合作，確保我們的工作符合這些承諾。」 |
| 替代提案 | GDPR 驗證集 | 除了生態系統針對採用「GDPR 驗證集」提案提供的意見回饋之外，Chrome 也對這個替代提案的以下限制感到疑慮：
自從提出這項替代方案後，Chrome 已更新第一方集合提案，並發布提交指南，說明如何建立新集合。 |
Fenced Frames API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 在 OT 期間的區隔畫面限制 | 在來源試用期間，Fenced Frames 目前有哪些限制？ | 我們正在撰寫有關限制和實施狀態的說明文件，並預計在 2023 年第 1 季發布。 |
| 單一圍欄框架中的多個廣告 | 要求在單一競價中，在一個圍欄廣告框中顯示多個廣告客戶 | 目前我們並未積極開發這項要求，但如果生態系統參與者認為這項功能很重要，歡迎提供額外意見回饋。 |
| Web Bundle | 針對含有圍欄框架的網頁套件，我們有哪些規範和支援計畫？ | 目前我們尚未掌握這項規定日後是否會實施。我們會事先宣布任何變更，並在淘汰第三方 Cookie 前實施。如要瞭解目前的狀態，請參閱這篇說明文章。 |
Shared Storage API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 廣告技術的共用儲存空間 | 對於廣告技術用途使用共用儲存空間的疑慮 | Shared Storage API 和 Private Aggregation API 可用於需要跨網站儲存評估的各種評估用途。請參閱這篇文章，瞭解相關範例。 我們預測 DSP 和成效評估解決方案供應商將成為廣告用途的主要整合服務供應商。 |
CHIPs
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| (也於第 3 季回報) 分區規定 | 針對第一方 Cookie 的「Partitioned」屬性新增明確的行為規定。 | 第 4 季更新： 在 GitHub 和 PrivacyCG 通話的討論後，我們一致認為，在第一方 Cookie 上設定的分割 Cookie 會使用分割鍵 (A,A)，其中「A」是頂層網站。我們會在說明和規格中記錄這項行為。 |
| Cookie 管理 | 是否有管理/控管第一方或第三方 Cookie 的工具？ | 您可以使用 Chrome 開發人員工具和 NetLog 測試啟用第三方 Cookie 封鎖功能的網站。兩種工具都會在 Cookie 因使用者設定而遭到封鎖時回報。歡迎提供意見，告訴我們希望看到哪些額外的稽核網站。 |
FedCM
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| IdP 需要知道 RP 才能允許工作階段 | 當使用者嘗試從兩個不同的 RP 登入 Feide IdP 時，會發生問題 | 我們正在討論可能的解決方法。 |
| 互通性 | 關於 FedCM 對使用者與他們透過 FedCM 登入的網站之間關係，以及網站間「互通性」的影響 | 當 Chrome 移除第三方 Cookie 後，FedCM 將繼續支援目前依賴第三方 Cookie 的聯合身分服務。我們預期 FedCM 只是這類服務可用的其中一種選項；身分驗證機構 (IdP) 和信賴方 (RP) 可以自由使用其他更符合需求的技術。 關於使用者-RP 關係和「互通性」的疑慮，似乎是因為誤解 FedCM 提案。FedCM 會讓 IdP 決定在使用者選擇登入 RP 網站後，要與 RP 分享哪些資訊，以及以何種形式分享。FedCM 並未要求 IdP「為使用者驗證的每個 [RP] 建立專屬的匿名 ID」。相反地，FedCM 會開放給每個 IdP，讓他們選擇是否要分享使用者的實際 ID、該 ID 的個別網站版本，或其他版本的這項資訊。 (FedCM 規格確實將跨網站相關性視為與 API 相關的隱私權風險，並討論將導向 (每個網站) ID 做為可能的緩解措施。不過，使用導向 ID 的決定權仍屬於 IdP，並非由瀏覽器強制執行。) FedCM 也已提供使用者選擇身分的選項。舉例來說，如果使用者在同一個 ID 提供者中擁有多個身分 (例如工作資料夾和個人資料夾)，FedCM 會提供一種方式，讓使用者選取要用來登入 RP 網站的身分。除此之外，每個 RP 都會自行決定在網站上支援哪些 IdP。這項決定的其中一個面向，是考量 ID 提供者所依賴的機制，無論是 FedCM 或其他技術。再次提醒您，瀏覽器不會為 RP 或 IdP 指定這些選項。 |
打擊垃圾內容和詐欺
Private State Token API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 處理機器人 | 如果發證者發現私密狀態權杖已核發給機器人，會發生什麼情況？ | 為避免向機器人核發的權杖在生態系統中停留太久，發證機構應定期輪替用於簽署權杖的金鑰，以便在舊權杖依據可能失效的核發邏輯核發後到期，讓網站以更新的核發邏輯兌換新權杖。 |
| 同網站表單提交 | 私密狀態符記是否可用於涉及整頁導覽 (即 Content-Type: application/x-www-form-urlencoded) 的同網站表單提交，而非來自 fetch/XMLHttpRequest API 的要求？ | 這項功能目前不支援第一版私密狀態權杖。如果有此用途的強烈需求，我們歡迎生態系統提供意見回饋。 |
| 伺服器端驗證 | 私密狀態權杖是否可在伺服器端驗證 | 代碼會向發出者兌換，接著發出者會建立兌換記錄，其中可能包含代碼本身或從代碼衍生出的某些已簽署值，伺服器可使用該兌換記錄驗證代碼的真實性，我們預期不同的發出者生態系統會針對如何解讀兌換記錄，制定不同的標準。 |