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