2022 年第 1 季的季度報告匯總了我們在 Privacy Sandbox 提案和 Chrome 回覆中收到生態系統的意見回饋。
為履行對競爭及市場管理局的承諾，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 已廣泛告知使用者，並且會張貼確認常見問題的常見問題，該功能會在全球推出。此外，Chrome 會持續定期與 CMA 諮詢作業相關的公開時間表。
顯示相關內容和廣告
| API / 技術 | 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 主題 | 粗略主題的實用性 | 許多疑慮都表示，粗略的主題分類對按照興趣顯示的廣告可能不夠實用。 | 需透過測試瞭解 API 的實用性。Chrome 會根據測試結果調整分類。 |
| 主題 | 分類 | 業界利害關係人希望勇於發聲，進而影響分類。 | Chrome 仍會開啟這類分類的輸入內容。Chrome 非常關心有關修改分類的管理模型，並討論其他產業機構可如何更積極地發展及維護分類。 |
| 主題 | 不同類型網站的實用性 | 許多疑慮都引發了網站實用性方面的疑慮，因為網站的流量多寡或內容專業程度而異。 | 需透過測試瞭解 API 的實用性。Chrome 會根據測試結果調整分類和其他參數。根據分類或參數的演進，不需要回溯不相容的變更。此外，Chrome 預期在第三方 Cookie 淘汰後，相關意見將繼續影響 Topics API 的演進。 |
| 主題 | 網站分類方法 | 要求網站能夠決定或影響主題分類。 | Chrome 正在探索這項要求，但他們反映 (來自網路瀏覽器社群和需求端平台) 認為，網站能以保護隱私權的方式「欺騙系統」來鎖定使用者，或降低廣告關聯性。Chrome 正在收集意見回饋，並評估可能的變更。 |
| 主題 | 雜訊信號 | 5% 的時間傳送隨機主題給他人，可能會產生過多雜訊 / 誤判。 | 雜訊是保護使用者隱私的重要方法，需要測試主題的雜訊程度和實用性。 |
| 主題 | 由網站控管的第三方權限 | 要求網站能夠選擇哪些廣告技術可從其網站呼叫 Topics API。 | 已透過「瀏覽主題」權限政策要求這項要求的功能，如說明內容中所述。 |
| 主題 | Topics API 對網頁效能的影響 | 受到 Topics API 影響，導致第一次廣告出現時間延遲的問題 | Chrome 正在討論可能支援 HTTP 要求標頭中的 Topics，藉此改善效能。我們正在進行測試，看看是否需要進行這類變更。 |
| 主題 | 隱私權 / 政策 | 詢問來電者篩選回應的目的，看看是否有第三方會與任何通話對象分享他們的主題 | Chrome 根據生態系統中許多人的意見回饋，選擇這項設計，限制只針對原本無法存取這類資訊的使用者進行存取。當然，獲得 Topics 的發布商和第三方可自行決定要與自家網站上第三方分享哪些資訊。如果使用者要進行這類分享作業，Chrome 強烈建議他們清楚說明這類分享情形，並為使用者提供控制選項。 |
| 主題 | 說明文件 | 您感興趣的說明文件涵蓋 Chrome 使用的分類器模型和分類，就像您針對 FLoC 一樣，例如分類器和分類的變動頻率。 | Chrome 已經提供用於來源試用的分類，而將網站分類為 Topics 的分類器模型則是在 Chrome 的程式碼集內提供，做為開放原始碼的一部分。在「來源試用」過程中，Chrome 有權在收到意見回饋及收集學習成效等資訊時變更版本。 |
| FLEDGE | 展示頻率上限 | 希望能控制廣告活動或廣告群組內每位使用者的展示頻率。 | FLEDGE 將支援裝置端競價的展示頻率上限。FLEDGE 還有待解決的問題，同樣支援內容相關/品牌宣傳廣告活動。共用儲存空間、另一個開發 API 和網站專屬上限也適用於其他展示頻率上限。 |
| FLEDGE | FLEDGE 對效能的影響 | 許多疑慮對 FLEDGE 競價中需要大量計算的出價工具可能產生的影響 | Chrome 正在與開發人員積極討論，瞭解可能對網站效能造成的影響。在測試期間，Chrome 歡迎進一步瞭解相關資訊。 |
| FLEDGE | 使用其他功能測試 FLEDGE | 使用其他功能 (k-anonymity 伺服器、鍵/值伺服器等) 進行測試的時機和方式。 | Chrome 刻意分階段為初步來源試用推出各項功能，目的是讓測試變得更輕鬆。Chrome 瞭解，提供其他功能清楚的時間表十分重要，並會盡可能闡明。 |
| FLEDGE | 測試協調作業 | 如何協調多項廣告技術的測試作業。 | Chrome 正在研究提供額外支援，協助協調實驗，以便針對相同使用者進行不同的廣告技術實驗。這也是 Chrome 合作夥伴推廣計畫的一大重點；業界貿易機構也表示有興趣扮演某個角色。 |
| FLEDGE | 興趣群組限制 | 使用者能加入或可參與競價的興趣群組數量是否有限制？ | 在測試期間，Chrome 會根據意見回饋和經過評估的延遲時間影響，修正網頁效能或使用者體驗方面的限制。我們還會繼續討論其他方法，讓買家和賣家調整資源用量。 |
| FLEDGE | 跨 API 功能 | FLEDGE 的歸因報表如何運作？ | 詳細資訊仍待定，Chrome 預計會在第 2 季更新相關資訊。在來源試用期間，Chrome 會繼續提供事件層級報表，以便瞭解競價結果 (勝出和損失)。 |
評估數位廣告
| API / 技術 | 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| Attribution Reporting (和其他 API) | 測試流量 | 如果有足夠的流量可供測試，該怎麼辦 | Chrome 將在流量極低的情況下開始來源試用，確保使用者控制項沒有任何嚴重錯誤或問題。早期測試人員扮演著重要角色，必須從技術角度確認 API 運作正常，這有助於加快增加流量的速度。確信 API 可以正常運作後，Chrome 會增加來源試用，以便支援公用程式測試。 |
| 歸因報表 | 用於註冊活動的人體工學 | 與支援的活動註冊形式相關的問題。 | Chrome 已在 GitHub 上發布回應，闡明目前支援的註冊形式。Chrome 目前正在收集生態系統對目前設計的意見回饋，以瞭解所提供的變更是否足以解決這些疑慮或需要進一步更新。 |
| 歸因報表 | 產生雜訊 | 想進一步瞭解匯總報表產生雜訊的方式。 | Chrome 已在 GitHub 發布回應，進一步說明雜訊的系統產生方式。Chrome 計劃提供程式庫來模擬噪音，並在 OT 期間使用多種參數進行測試。此外，Chrome 也計劃為匯總報表模式提供額外的開發人員說明文件和指南。 |
| 歸因報表 | 小型網站的資料準確度較低 | 請留意小型網站或廣告活動所接收的資料準確度會較低。 | Chrome 瞭解，以雜訊為基礎的隱私保護措施對於較小的資料片段的影響較大。不過，匯總較長時間範圍的做法或許能解決這個問題，也無法確定根據極小的資料片段 (例如一或兩筆購買) 得出的結論是否對廣告客戶有意義。在來源試用期間，Chrome 鼓勵測試人員多方嘗試各種隱私權和雜訊參數，以便針對這個問題提供更具體的意見回饋。 |
| 歸因報表 | 轉換延遲對公用程式的影響 | 因為轉換延遲會幹擾廣告活動設定和驗證，或是廣告活動最佳化。 | Chrome 收到了一些衝突的意見回饋，指出轉換報表延遲的影響。不過，為保護使用者隱私，Attribution Reporting API 會在回報時產生隨機延遲，因此 Chrome 預期在測試期間，特定用途或問題會更清楚明瞭，並可可以透過額外的偵錯支援或開發人員指南來解決。 |
| 歸因報表 | 歸屬期較長 | 申請延長 30 天的歸屬期 | Chrome 已發布回應，希望進一步瞭解歸屬期長度，同時兼顧資料最小化原則和實用性。 |
| 歸因報表 | 非可視曝光 | 關於瀏覽後轉換報表是否會計入非可視曝光的問題。 | Chrome 已在 GitHub 發布回應，讓您更清楚瞭解可視曝光次數。 |
限制隱密追蹤
| API / 技術 | 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 使用者代理程式縮減 | 效能 | 對透過關鍵 CH 取得提示 (在第一次載入網頁時) 取得提示會有什麼疑慮。 | Chrome 正在研究如何提升效能。 |
| 使用者代理程式縮減 / 使用者代理程式用戶端提示 | 反詐欺 / 反濫用疑慮 | 在針對特定類型的攻擊 (包括阻斷服務) 進行偵錯時，請提供越多資訊越好。如果在通用 Analytics (分析) 字串中遺失部分資訊，可能會造成問題。 | Chrome 正在討論如何維護隱私，並提供足以進行偵錯的充足資訊。 |
| 使用者代理程式縮減 | 深入瞭解 OT 設定 | 有多位來源試用參與者建議改善說明文件，並附上如何註冊來源試用的範例。 | 「通用 Analytics (分析) 來源試用優惠」即將結束，但 Chrome 想改善淘汰試用操作說明，包括讓示範範例更顯眼。 |
| 使用者代理程式縮減 | 對特定提示的值有疑慮 | 詢問 Sec-CH-UA-Model 是否與 User-Agent 字串中的 <deviceModel> 相同。 | Sec-CH-UA-Model 與使用者代理程式字串中的 <deviceModel> 相同。Chrome 會在日後的說明文件中，嘗試更明確的說明。 |
| 使用者代理程式縮減 | 擔心申請淘汰試用 | 關於如何在「淘汰試用」中註冊大量網域的問題 | 在設計淘汰試用計畫時，Chrome 已考量集中式方法，但 Chrome 認為現有的來源試用功能是最佳選擇，因為這項功能可為開發人員提供所有控制權 (因為他們可以選擇傳送標頭)。 |
| 使用者代理程式用戶端提示 | 有關 UA-CH 規定性質的疑慮 | 與 rfc7231 定義的使用者代理程式相比，UA-CH 會過於嚴謹。 | 從最終跨瀏覽器互通性和使用者隱私保護功能的觀點來看，Chrome 將 UA-CH 標頭的規範性質視為重要改進，從最終跨瀏覽器互通性和使用者隱私保護的觀點來看 (這是為了防止隨意新增高熵 ID)。
不過，如果其他人也分享這個問題並想提供意見，則問題仍未解決。 |
| 使用者代理程式用戶端提示 | 關於 API 用於封鎖某些瀏覽器的疑慮 | 確認網站使用 API 搜尋「Google Chrome」或「Microsoft Edge」，並封鎖所有其他瀏覽器。 | 品牌清單的概念是專為處理這個情況而設計：除了自家品牌外，瀏覽器也可以傳送「Google Chrome」。 |
| 使用者代理程式用戶端提示 | 要求提供方法列舉所有支援的提示 | 想透過程式輔助方式瞭解瀏覽器的所有支援提示。 | Chrome 正在評估功能要求。 |
| 使用者代理程式縮減 / 使用者代理程式用戶端提示 | 反詐欺 / 反濫用疑慮 | HTTP1 首次載入時無法使用用戶端提示 | Client Hints Reliability API (accept_CH) 僅支援 HTTP2 和 HTTP3。針對仍透過 HTTP1 提供服務的伺服器，只能使用 Critical-CH。 |
| 使用者代理程式縮減 | Chrome for Android 對 Chrome 的影響 | 針對這對 Android 版 Chrome 有何影響。 | 通用 Analytics (分析) 縮減和 UA-CH 將會在 Android 版和電腦版 Chrome 中提供。針對 Android 版 Chrome，系統只會在目前預定適用於 Chrome 110 版的「第 6 階段」進行變更， |
| Gnatcatcher (WIPB) | 不統一的用途和方法 | 清楚瞭解非合規用途和非符合規定的方法。 | Chrome 會更新說明，提供更多詳細資訊。 |
| Gnatcatcher + 使用者代理程式縮減 | 減少反詐欺信號 | 「同時」減少 IP 存取，「同時」減少 UA 存取作業，反而受到反詐欺的影響。 | 只要預期有利於 IP 盲人反詐欺政策的規範 (允許使用 IP 進行反詐欺用途)，即可解決 IP Proxy 處理的防禦問題。 |
| 導覽追蹤 | 對日後的故障問題有疑慮 | 廣告客戶擔心潛在的服務中斷問題，識別資訊提供者也表示對 Chrome 的計畫感興趣。 | Chrome 不會立即做出破壞性變更，且仍在探索各種用途。 |
| SameSite Cookie | 與其他瀏覽器的互通性 | Chrome 修正 crbug.com/1221316 的計畫相關問題，因為這個區域 Chrome 的實作方式與其他瀏覽器的不同。 | Chrome 發現指標有錯誤，也因此帶來新的指標。Chrome 會收集相關資料，進一步瞭解修正錯誤的影響。 |
| 儲存空間分區 | 對於分區訊息管道有疑慮 | 詢問訊息管道 (例如SharedWorker 和 BroadcastChannel)。 | Chrome 正在評估意見回饋，但 Chrome 認為將訊息管道與儲存空間分開，才能有效防止隱密追蹤。 |
強化跨網站隱私界線
| API / 技術 | 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 第一方集合 | 常見的隱私權政策規定 | 我們無法為所有產品和管轄區採用相同的隱私權政策。 | Chrome 仍在製定政策規定，因此將牢記這項意見回饋。 |
| 第一方集合 | 獨立執法實體 (IEE) 可能會收到大量的 FPS 有效性挑戰。 | 判斷 FPS 有效性的可預見挑戰摘要：文字或隱私權政策與所有集合成員不相符；詳細說明如何界定使用者關注的成員資格、頻寬和時間挑戰，以及公司結構的專業專業知識。 | Chrome 仍在製定政策規定，因此將牢記這項意見回饋。 |
| 第一方集合 | 維護瀏覽器 FPS 清單的程序 | 關懷西方國家/地區的網站進入障礙、因更新頻率不同所導致的各瀏覽器 FPS 清單版本不一致的問題，以及小型/新版瀏覽器使用清單的問題。 | Chrome 仍將制定政策規定、接受程序和清單使用權限，意見也會謹記在心。
此外，Chrome 也會從網路平台使用的其他靜態清單 (例如公開尾碼清單) 中學習 |
| 第一方集合 | 動態個別網站斷言設計 | 動態設計 (與靜態清單不同) 可能較容易遭誤判為共同擁有權，以及網頁載入延遲/失敗。 | Chrome 目前正在採用靜態清單做法，日後若能重新評估已簽署斷言做法，我們會將這份意見回饋納入考量。 |
| 第一方集合 | 第一方集合的可能用途 (如果可以建立可靠且對等的 FPS 清單) | 單一登入及可自訂的資料提示，為使用者提供更全面的資訊公開報告。 | Chrome 將根據這項意見回饋，考慮後續的第一方集合 |
| 方塊 | 瀏覽器相容性 | 想瞭解其他瀏覽器如何處理分區 Cookie 屬性 | Chrome 會繼續在 W3C 等公開標準群組內運作，找出適用於各種瀏覽器的設計和實作方式。 |
| 方塊 | 設計規定 | 我們無法在名稱前加上 __Host-名稱前置字串 | Chrome 已移除「來源試用」的命名規定，且會在測試期結束時考慮是否要讓這項功能永久使用。 |
| 方塊 | 將 CHIPS 用於廣告用途 | 詢問是否能針對廣告用途使用 CHIPS。 | CHIPS 可讓第三方建立已分區至頂層網站 (或其第一方集合) 的用戶端 Cookie。如果用途需要分區狀態，而非跨網站狀態，則可針對該用途使用 CHIPS。 |
| 方塊 | 整合 CHIPS 與 FPS | 擔心使用 CHIPS 進行測試可能無法與其他 Privacy Sandbox 提案 (例如第一方集合) 同時執行 | Chrome 正在主動探索如何促進測試環境，以促進這類測試。Chrome 也發布了適用於 FPS 和 CHIPS 本機測試的操作說明，目前也可用於測試。 |
| FedCM | 表達能力 | 注意：由於瀏覽器會轉譯部分聯合身分識別流程的一部分，因此很難掌握 IdP 要向使用者顯示的所有細微差異 | Chrome 肯定需要權衡的取捨，因此將繼續與大環境合作，盡可能涵蓋更多地方，並盡可能呈現生動細節。Chrome 正在開發某些功能，包括自訂品牌宣傳元素 (例如標誌、顏色) 和自訂字串 (例如「存取這篇文章」，而非「登入方式」)。 |
| FedCM | 瀏覽器參與 | 確認瀏覽器在身分聯盟流程中較複雜，因此可以更明確地瞭解使用者登入的網站 (和哪個 IDP)。 | Chrome 瞭解瀏覽器現在是一個更活躍的角色，但瀏覽器需要這樣的額外參與，讓瀏覽器能夠區分及防止跨網站追蹤，同時仍支援聯盟功能。 |
| FedCM | 適用性和互通性 | 確認其他瀏覽器不會採用或導入 FedCM。 | 除此之外，Chrome 也已與其他瀏覽器供應商合作，在 FedID Community Group 中找到聯盟方面的常用解決方案。 |
| FedCM | 各種 API 挑戰 | 瞭解 FedCM 仍處於早期 / 不盡理想的狀態，因此需要較長時間才能提供生態系統需要的所有功能。 | Chrome 會在生態系統測試中進一步探索這一點。 |
| FedCM | 企業政策和使用者控制項 | 確認是否有可讓企業控管聯合身分識別部署作業的控制選項 (例如企業政策和/或使用者設定)。許多聯合身分的內部部署部署項目難以重新部署 / 變更，因此在面對需要 IDP 重新部署的新瀏覽器 API 上，有許多阻礙。 | Chrome 正在探索企業管理員和使用者適用的控制功能，認為可以化解這些疑慮。如果企業希望將特定用途納入考量，歡迎向 Chrome 提供意見回饋。 |
打擊垃圾內容和詐欺
| API / 技術 | 意見回饋主題 (按 API 的 Prevalence 排名) |
問題與疑慮摘要 | Chrome 回應 |
| Trust Token API | 兌換限制 | 每個頁面大約有 2 個限制，尤其是嵌入同一個網頁，或是機構內有第二個核發機構網域的情況。其中較有可能會自行達到門檻，卻不考慮其他市場的參與者。 | 如要提高採用率，Chrome 可以稍微擴大每頁兌換上限，但必須降低這個上限才能造成過多熵。此外，快取兌換記錄或許能減少核發機構在短時間內為單一使用者兌換多個權杖的需求。 |
| Trust Token API | 延遲時間 | 一般來說，他們必須在 10 毫秒內回應出價要求，因此在第一次載入網頁時兌換符記，就不太可能會將代碼納入出價前的無效流量決策中 | Chrome 會嘗試透過測試瞭解延遲對出價前使用情境的影響。 |
| Trust Token API | OpenRTB 採用率 | 在預先出價的應用實例中，您必須將已兌換的權杖資訊傳遞至賣方平台和需求端平台，以便用於廣告決策 | Chrome 樂於與 IAB 合作，確保任何實用的反詐欺/反濫用信號都能透過 OpenRTB 傳播，雖然他們擁有新增預設欄位的標準。 |
| Trust Token API | 隱私權 | 關於任何形式的跨網站資料傳播方式長期可行性的問題，但熵不足 (約為 2.5 位元) | Chrome 提供完善的使用者保護措施，防止不重複使用者識別身分，而 Chrome 認為有益於這個生態系統接受生態系統。Chrome 與重要利害關係人密切合作，確保長期可行性。 |
| 平台認證信號 | 評估新提案/提案的搜尋熱度 | 對各種可行 (與不可行) 信號的強力支援，例如傳達平台可提供的裝置完整性信號 | Chrome 計劃將這個想法轉交給 W3C 的反詐欺社群群組，以便提供新的意見回饋。 |
| 用於防範詐欺的受信任伺服器 | 評估新提案/提案的搜尋熱度 | 這項概念感興趣，但可能需要進一步研究適用用途 | 視興趣程度而定，Chrome 可能會對這個概念進行進一步的構思，並在日後提供生態系統意見回饋時參考。 |