2022 年第 2 季的季度報告，彙整了各生態系統針對 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/技術
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 更清晰的時程 | 更清楚、更詳細的 Privacy Sandbox 技術發布時間表。 | 我們在 privacysandbox.com 上製定了目前的部署計畫，並每月更新。這些因素不僅會將開發時間納入考量，也會考量 Chrome 和網頁程式開發人員的開發時間，同時也考量到更需要時從廣闊生態系統收到的意見回饋，以便測試及採用新技術。每項技術都會經歷多個步驟，從測試到發布 (發布) 階段，每個步驟的時間都是根據我們在上一個步驟中學到的知識和發現的，而掌握每個步驟的時間。儘管目前我們未承諾發布版本，但一定會在 privacysandbox.com 更新公開時間表。 |
| 不同各類型利害關係人的實用性 | 以下問題是，Privacy Sandbox 技術對大型開發人員較有利，而小眾 (小型) 網站帶來的貢獻內容高於一般 (大型) 網站。 | 我們瞭解部分開發人員對 Privacy Sandbox 技術的影響有疑慮。Google 承諾不會設計或導入 Privacy Sandbox 提案時顧及 Google 自身業務以扭曲競爭情形，並將影響數位廣告競爭程度、對發布商和廣告客戶的影響，以及對隱私權結果和使用者體驗的影響納入考量。我們會持續與 CMA 密切合作，確保我們所做的努力符合這些承諾。
隨著 Privacy Sandbox 的進展，我們要評估一項重要問題，就是新技術對不同類型相關人員的成效。意見回饋至關重要，尤其是具體且可做為行動依據的意見回饋，有助於我們進一步改善技術設計。 |
| 第三方 Cookie 淘汰時間表 | 請求進一步避免第三方 Cookie 淘汰延誤 | 有些相關人員向我們反映，希望 Chrome 立即淘汰第三方 Cookie 而無需延遲。正如有人需要更多時間測試及採用 Privacy Sandbox 技術，考量到技術的複雜性，以及確保一切順利的生態系統的重要性，我們致力於以負責任的態度進行訴訟。業界和監管機構的意見回饋對這項程序來說至關重要。 |
| 第三方 Cookie 淘汰時間表 | 針對第三方 Cookie 淘汰時程的要求，並提供更多時間測試 API。 | 有些相關人員向我們反映，希望 Chrome 立即淘汰第三方 Cookie 而無需延遲。正如有人需要更多時間測試及採用 Privacy Sandbox 技術，考量到技術的複雜性，以及確保一切順利的生態系統的重要性，我們致力於以負責任的態度進行訴訟。業界和監管機構的意見回饋對這項程序來說至關重要。 |
| 說明文件要求 | 要求取得更多資源，並詳細說明如何管理測試、分析和實作的方式。 | 感謝開發人員目前認為實用資源，因此我們將在未來幾週和幾個月內，致力提供更多資源，包括開發人員諮詢時間及技術說明文件，以利開發人員持續瞭解新技術對這些技術有何助益。
我們也舉辦了公開的對外開發人員諮詢時間，與產品和工程主管分享最佳做法和示範，並邀請產品和工程主管進行現場討論/問答活動。 |
| 產業專業知識 | 與標準機構合作的 Chrome 團隊缺乏廣告生態系統的專業知識，才能妥善兼顧隱私權和實用性。 | 我們深知自己的責任重大，因此必須藉由特定意見回饋才能達成這項目標。此外，我們也會將隱私性和效益視為關鍵設計標準。負責網頁版 Privacy Sandbox 的團隊總共在數百年內投入廣告大環境的成果。 |
顯示相關內容與廣告
主題
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 不同各類型利害關係人的實用性 | 許多疑慮都表示，視流量等級或內容特有方式而定，網站的價值創造或分配十分重要。 | 需透過測試瞭解 API 的實用性。Chrome 會根據測試結果調整分類和其他參數。根據分類或參數的演進，不需要回溯不相容的變更。此外，Chrome 預期在第三方 Cookie 淘汰後，也會繼續收到相關意見回饋，持續影響 Topics API 的演進。 |
| 分類 | 業界利害關係人希望勇於發聲，進而影響分類。 | Chrome 仍會開啟這類分類的輸入內容。Chrome 非常關心有關修改分類的管理模型，並討論其他產業機構可如何更積極地發展及維護分類。 |
| 瀏覽記錄不足 | 建議針對使用者最近一週看過的主題，建議使用者因瀏覽記錄不足而無法在最近一週建立 5 個主題 | 在目前的設計中，這些元件是隨機選擇。我們會調查與過去主題的相關性，並評估是否有可能納入這些資訊，但關聯性可能會因為考量因素而需要考量到隱私權問題。 |
| 代表發布商呼叫 Topics | 第三方服務供應商可以與發布商共用 Topics 嗎？ | 是的，這是我們預期使用 Topics 的方式。 |
| 潛在的攻擊向量 | 找出吵雜的主題 | Chrome 根據生態系統中許多成員的意見回饋，選擇篩選主題並導入雜訊。我們制定這些決策時秉持隱私權原則，僅將資訊存取權限制於原本無法存取這類資訊的使用者，並分別對他們造成危害。我們瞭解這些決策有缺點，例如此處列出的攻擊向量。不過，我們評估的是隱私權優勢大於潛在風險。我們歡迎公開討論這項決定。 |
| 來源試用資格條件 | 如何偵測使用者是否符合來源試用資格？ | 即使使用者造訪的網頁已提供有效試用權杖，且瀏覽器包含在已啟用試用功能的群組中，使用者可能仍會因為瀏覽器設定或其他因素，而無法使用來源試用功能。
因此，請一律先透過功能偵測功能檢查是否可用的來源試用功能，然後再嘗試使用。 |
| 效能影響 | Topics 的負載與延遲問題 | 我們已徵求意見回饋，瞭解有哪些方法避免昂貴且緩慢的 X 來源 iframe，並讓提案分散 Topics API，以免取得主題不會變更瀏覽狀態。 |
| 分割 Topics API 功能 | 進一步控管 API 的三個不同面向 | 我們瞭解應用實例，並提議在 GitHub 中解決這個問題。我們目前正在等待生態系統針對這項功能建構提供的意見回饋。請按這裡查看持續進行的討論。 |
| 分類器時間軸和說明文件 | 開發人員已要求進一步瞭解分類器。 | 我們已在這裡提供了有關分類器的更多公開資訊。
以及這個頁面 請按這裡。 |
| 使用者控制項和安全性 | 有些主題可能屬於敏感族群的 Proxy，而使用者需要更多控制項才能避免負面結果。 | 「主題」是進一步提升使用者控制權與資訊透明度的重要推手。使用者可以選擇不採用主題、查看已指派的主題、移除主題，以及瞭解哪些公司在特定網頁上與他們的主題互動。此外，使用者也可以刪除瀏覽記錄，藉此影響自己的 Topics。我們歡迎繼續討論更進階的使用者控制項，例如開發人員的建議；不過，我們需要確保這項錯誤所述的疑慮確實能降低風險 (例如，僅移除「外語研究」主題，但從「瀏覽記錄」產生主題的網站無法完全保護使用者)。 |
| 在 Prebid.js 網站上使用主題 | Topics API 可用於採用 Prebid.js 的網站嗎？ | 答案是肯定的。如需相關詳情，請參閱這篇文章。 |
| 在推薦小工具中使用 Topics API | 是否可以在建議的小工具 (例如 Outbrain) 中使用 Topics API | 呼叫 API 後，系統不會限制擷取 Topics 的用途 (視個別開發人員的資料政策而定)。 |
| 隱私權 / 政策 | 詢問是否要依來電者篩選回覆的問題，說明是否有第三方會與進行通話的任何第三方分享他們的主題。 | Chrome 根據生態系統中許多人的意見回饋，選擇這項設計，限制只針對原本無法存取這類資訊的使用者進行存取。當然，獲得 Topics 的發布商和第三方可自行決定要與自家網站上第三方分享哪些資訊。如果使用者要進行這類分享作業，Chrome 強烈建議他們清楚說明這類分享情形，並為使用者提供控制選項。 |
| 雜訊信號 | 5% 的時間傳送隨機主題給他人，可能會產生過多雜訊 / 誤判。 | 噪音是保護使用者隱私的重要方法，且將透過測試來瞭解雜訊程度和主題實用性。 |
FLEDGE
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 測試協調作業 | 測試效能與收益影響 | 我們將在 WICG 公開會議中積極討論 FLEDGE 的效能，以及我們該如何在來源試用和正式發布階段協助進行生態系統測試。 |
| FLEDGE 的受信任伺服器 | 信任的伺服器何時可用於測試？ | 我們十分重視這個意見回饋，也正積極擬定更詳細的計畫，以便在 FLEDGE 中使用受信任的伺服器。 |
| 通訊協定標準化 | 在賣方平台和需求端平台之間傳遞資料時，是否使用通用的通訊協定 (例如興趣群組的通用標籤)？ | 歡迎需求端平台、賣方平台和更廣泛的廣告生態系統提供意見回饋。為了進行初步測試，我們建議您直接與測試合作夥伴聯絡，因為他們正在進行實驗不同的實驗。我們也鼓勵並計劃繼續與廣告交易機構合作，針對該組織的成員公司提供實用的標準化做法。 |
| 展示頻率上限 | 廣告活動和廣告群組中的每位使用者展示頻率控制項。 | FLEDGE 也支援裝置端競價和內容相關 / 品牌宣傳廣告活動的展示頻率上限。共用儲存空間和網站專屬上限也可用於設定其他展示頻率上限。 |
| FLEDGE 對效能的影響 | 在 FLEDGE 競價中計算密集型出價方 | Chrome 正在與開發人員討論可能對網站效能造成的影響。在測試期間，Chrome 歡迎進一步瞭解相關資訊。 |
| 使用其他功能測試 FLEDGE | Attribution Reporting API 和 FLEDGE 的事件層級報表會如何搭配使用？ | 這個部分在最近的 WICG/conversion-measurement-api 呼叫中已有討論，點選這裡的連結，即可前往查看詳細分鐘數。
會議摘要是，Fenced Frames Ad Reporting 目前採用的設計，可與 Fenced Frame 中產生的 ID 建立關聯，以及背景資訊。因此，Fenced Frame 中產生的事件層級報表會和伺服器上的相同內容資訊彙整 (使用 2 個伺服器端彙整，而不是 1)。 |
| 曝光次數 | 買方和賣方之間應或可使用哪種曝光計算方法 | FLEDGE API 已支援賣方和買方在競價期間採用的方法一致。我們已經收到針對替代執行方式的建議，但當中並沒有具體說明為何目前的設計無法在這個生態系統中運作。 |
| 顯示多個廣告 | 是否在特定的 Fenced Frame 中，可一次顯示多則廣告 | 這可用元件廣告 (請別和元件競價混淆)。因為所有廣告都必須屬於同一個興趣群組。 |
| 「賣方定義目標對象 (SDA)」規格和 FLEDGE | FLEDGE 是否能成為防止買方透過廣告請求建立 SDA 資料的機制？ | FLEDGE 旨在避免發布商知道 SDA 訪客位於哪個網站，進而避免資訊外洩。如果必須在 FLEDGE 內建的所有保護措施中支援透過 SDA 進行採購，可以選擇一種解決方案，讓賣方將 SDA 標籤傳遞到裝置端競價中，而買方廣告技術也能自行建立興趣群組，其出價邏輯為「我想購買目標對象 X」。 |
| 支援美元以外的貨幣 | 支援使用美元以外的貨幣測試 FLEDGE | 我們十分重視這次的呼叫，也努力在待處理功能要求中支援其他貨幣。希望這項功能很快就會推出。 |
| 支援指定排除興趣群組 | 支援 Instagram 排除指定目標的 API：只在使用者不屬於 Instagram 層級時顯示廣告。 | 目前正在討論 GitHub 問題，包括一些建議的支援選項。 |
| FLEDGE 中的多個賣方平台 | 在 FLEDGE 中導入多層競價的風險與 Google 合作 | 為了提供公平、公平的競爭環境，FLEDGE 新增了多個賣方平台的支援功能。Google 承諾不會設計、開發或導入 Privacy Sandbox 提案，但這些提案不會因自採廣告產品和服務而扭曲競爭情況。Google 非常重視這個問題，也非常樂意討論相關人員在技術方面可能提出的疑慮。如需相關資訊，Chrome 已經在這裡公開說明元件競價機制。 |
評估數位廣告
Attribution Reporting (和其他 API)
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 多接觸點歸因分析 | 要求支援多接觸點歸因分析的發布商 | 目前，多接觸點歸因分析的方法需要確定，將不同網站上的使用者曝光 (並依身分) 結合在一起。因此，這項功能在現有表單中與 Privacy Sandbox 的目標不符。 Privacy Sandbox 的目標是在沒有跨網站追蹤的情況下，支援重要的廣告用途。在某些情況下，即使沒有追蹤個別使用者，您還是可以概略指派抵免額 (例如使用加權，隨機優先順序)。 |
| 產生雜訊 | 與報表中的雜訊層級相關問題 | 我們的初始實驗可讓開發人員自行設定 ε 值，以便瞭解報表隨著雜訊等級變化的情況。截至目前，開發人員最多可以選擇 Yepsilon=64 的磅數值。這麼做是為了方便開發人員測試 API，並針對適當的 ε 值提供意見回饋。
此外，我們也針對這類意見回饋採取公開要求。 |
| 測試協調作業 | 本機測試工具可用於 OT 嗎？ | 是，在 OT 期間，你可以使用本機測試工具。只要第三方 Cookie 可供使用，本機測試工具即可與偵錯報表搭配使用。 |
| 查詢人體工學 | 啟用索引鍵匯總功能 | 我們同意這麼做可以提升 API 人體工學的效率，而且幾乎或完全沒有降低隱私成本。我們會提出廣泛共識，看看這些提案是否值得支持。 |
| 小型網站的資料準確度較低 | 網站或廣告活動規模越小，取得的資料精確度可能會降低。 | Chrome 瞭解，以雜訊為基礎的隱私保護措施對於較小的資料片段的影響較大。不過，匯總較長時間範圍的做法或許能解決這個問題，也無法確定根據極小的資料片段 (例如一或兩筆購買) 得出的結論是否對廣告客戶有意義。在來源試用期間，Chrome 鼓勵測試人員多方嘗試各種隱私權和雜訊參數，以便針對這個問題提供更具體的意見回饋。 |
限制轉換追蹤
使用者代理程式縮減
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 漫遊器防護 | UA-R 對機器人防護的影響 | 我們十分重視你的寶貴意見，且正在收集機器人防護方法的相關資訊，協助我們規劃未來的設計。 |
| 部署依附元件 | 解決結構化使用者代理程式 (SUA) 部署依附元件 | 我們已推出「第 4 階段」，也就是縮減 101 以上版本的 Chrome 使用者，也就是 100% 的子版本。請參閱這篇文章進行更新。 |
使用者代理程式用戶端提示
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 列舉所有支援的提示 | 想透過程式輔助方式瞭解瀏覽器的所有支援提示。 | 感謝你提供寶貴意見，我們正在評估這項功能要求。我們想瞭解這是否為常見用途。 |
| UA-CH 和使用者代理程式標頭的彈性 | 相較於 rfc7231 定義的彈性，UA-CH 會過度預先擬真。 | 從最終跨瀏覽器互通性和使用者隱私保護功能的觀點來看，Chrome 將 UA-CH 標頭的規範性質視為重要改進，從最終跨瀏覽器互通性和使用者隱私保護的觀點來看 (這是為了防止隨意新增高熵 ID)。
但請放心，如果其他人也分享這個疑慮並想提供意見，則問題會保持未解決。 |
| UA-CH：反詐欺 / 反濫用疑慮 | 透過通用 Analytics (分析)-CH 可能無法使用部分功能：點擊追蹤程式和詐欺點擊。 | 我們的團隊正在與反詐欺和評估相關人士共同調查這些潛在問題。 |
| 效能 | 對透過關鍵 CH 取得提示 (在第一次載入網頁時) 取得提示會有什麼疑慮。 | Chrome 正在研究如何提升效能。 |
Gnatcatcher (編輯中)
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 延遲問題 | 增加額外的躍點可能會影響延遲時間 | 我們正在考慮採用兩個躍點 Proxy，並探索如何在使用者隱私和延遲時間之間取得適當平衡。我們很樂意提供意見回饋，且會想透過 W3C 論壇進行後續討論。 |
| 詐欺和機器人防護機制 | 對詐欺和機器人防護機制的影響，包括發展程度較低的國家/地區 | 因此，我們一直在設法以有意義的方式 (例如透過 Proxy IP 位址處理) 加強使用者隱私，因此安全性是核心要求。兩個躍點 Proxy 與信譽良好的公司合作，提供可驗證的使用者隱私。為協助傳達使用者的信任，我們也持續提供新信號的構想。 |
| 遵守當地隱私權法律 | 國家/地區層級的地理區域資料報表，讓公司難以遵守更精細的當地制度 | 我們公開發布了我們的原則，其中包括可讓網站遵循當地法規的可行方法。 |
強化跨網站隱私界線
第一方集合
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 不同各類型利害關係人的實用性 | 每秒影格數對小型與大型發布者的影響 | Privacy Sandbox 的主要目標，是將目前的做法替換為不仰賴跨網站追蹤機制的解決方案，以加強使用者隱私。我們希望這些解決方案能針對各種類型的利害關係人和規模，盡可能提供更多實用內容。我們歡迎針對這些解決方案採取具體行動，提供具體可行的建議，期望能根據社群討論和測試不斷改進。 |
| 加強隱私防護 | 如果同一個組合中的網站過多，則和第三方 Cookie 的成效相差不遠 | 我們很重視這項意見回饋，也正在評估是否可行，以及是否可採用適當的限制，同時嘗試為使用者和開發人員提供適當處置或信號，以便他們瞭解上限為何。我們目前沒有具體的提案，但希望很快就能提供。 |
| FPS 的生態系統支援 | 收集有關持續開發隱私權 CG 每秒影格數的支援和疑慮 | 儘管我們偏好將第一方集合提案保留在 PrivacyCG 中，但我們也期待繼續在 WICG 中推動這項提案。我們也鼓勵許多支援持續討論第一方集合和用途，藉此鼓勵我們持續討論。Google 一向致力於尋找解決方案，以保障使用者隱私的方式持續推動網路成長並蓬勃發展。 |
| 瀏覽器互通性 | 由其他瀏覽器導入 | 我們瞭解瀏覽器互通性對開發人員的重要性，因此會繼續與其他瀏覽器合作，致力於實現 FPS 標準化的目標。 |
| 常見的隱私權政策規定 | 我們無法為所有產品和管轄區採用相同的隱私權政策。 | Chrome 仍在製定政策規定，因此將牢記這項意見回饋。 |
Fenced Frames API
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 說明文件要求 | 與沙箱 iframe 的差異 | 感謝您提供寶貴意見和建議。GitHub 上目前針對這個部分進行討論，我們希望能全面瞭解這項要求，然後加以全面評估。如要查看公開討論，請按這裡。 |
| 跨 API 功能 | 圍欄頁框中歸因報表的預設支援 | 我們徵求提案意見，以允許預設圍欄頁框的「不透明廣告模式」使用 Attribution Reporting API。我們建議開發人員參考這些價值來決定是否參與討論。 |
Shared Storage API
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 數據用量上限 | 每個分區可儲存的資料量是否有限制？ | 是，會受到限制。詳情請參閱 GitHub 問題。我們需要儲存空間配額。在目前的提案中，每個項目的大小上限為 4 KB，每個鍵和值的上限為 1024 字元 16_t 個字元，每個來源的項目數量上限為 10,000 個字元，而且在來源容量已滿時，可避免再提交其他項目。目前我們會積極針對這裡建議的具體限制情況提供意見回饋。 |
| 使用者資訊公開 | 提供公開的資料來源與資料使用方式 | 感謝你提供的寶貴意見，我們覺得這個做法值得一探。具體來說，我們會評估是否可行，確保必須以清楚透明的方式向使用者提供資訊。 |
方塊
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 採用阻抗 | CHIPS 是否應繫結主機名稱？(無網域規定)。 | 這項規定是為了降低採用 CHIPS 的阻礙，因此根據 OT 參與者的意見回饋，我們移除了 OTS 的規定。 我們會在隱私權社群群組中討論這項規定，做為規劃標準的一部分。 |
| CHIPS 的廣告用途 | CHIPS 可用於單一網站上的廣告用途嗎？ | 我們允許在一個網站內進行使用者追蹤。我們 更新了開發人員文章，以強調此用途。 |
| 經過驗證的嵌入 | 登入狀態是否會保留 CHIPS ？ | 目前系統不會保留登入狀態，但這並非 CHIPS 的預期用途。我們明白經驗證的嵌入項目用途，目前正努力探索解決方案。 |
| 測試協調作業 | 是否需要任何其他使用者動作才能測試分區？ | 只要 OT 權杖有效且出現在造訪的網頁標頭中，使用者不必採取任何其他操作，應該就能使用這項功能 |
| 瀏覽器相容性 | 想瞭解其他瀏覽器如何處理分區 Cookie 屬性。 | Chrome 會繼續在 W3C 等公開標準群組內運作，找出適用於各種瀏覽器的設計和實作方式。 |
FedCM
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 潛在的攻擊向量 | 透過連結裝飾和時間攻擊，讓潛在的攻擊向量 | 我們會積極收集大眾意見，並設法解決這個問題。 |
| 提供多個 IdP 的使用者體驗 | 一次只能顯示一個 IdP | 我們相信支援多種 IDP，並積極開發各種支援管道 |
| 表達能力 | 注意：由於瀏覽器會轉譯部分聯合身分識別流程的一部分，因此很難掌握 IdP 要向使用者顯示的所有細微差異。 | Chrome 正在探索品牌自訂元素 (例如標誌、顏色) 和自訂字串 (例如「存取這篇文章」，而非「登入方式」)。
Chrome 認可需要優缺點，並持續與生態系統合作，盡可能涵蓋更多情況，並盡可能生動地呈現內容。 |
| 適用性和互通性 | 確認其他瀏覽器不會採用或導入 FedCM。 | 除此之外，Chrome 也已與其他瀏覽器供應商合作，在 FedID Community Group 中找到聯盟方面的常用解決方案。 |
| 移除註冊流程中個人資料規定的建議 | (1) 提供使用者體驗告知使用者自己選擇的 IdP，但未說明將分享電子郵件、相片和名稱等資訊，較能保障隱私權
(2) 使用者體驗不完整，而且僅包含 IdP 提供的憑證附加資訊 |
對此我們具有共識，也正在探索如何以更友善、更能保障隱私權的方式實作相關意見。 |
| 使用者與 IdP 互動 | 超過風險門檻時，需要在使用者與 IdP 之間直接互動 | 我們正積極調查這項意見回饋。 |
網路狀態分區
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 效能 | 分區網路狀態可能會導致 CDN 資源耗用大量資源 | 我們仍在調查「網路狀態分區」的效能特性，包括測量不同的可能的鍵配置配置。我們尚未在權衡效能、安全性和隱私權的取捨方面做出決定，因此需要更多資料。 |
打擊垃圾內容和詐欺
Trust Tokens API
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 法規意見回饋 | 擔心在監管機構未明確指出長期可行性的情況下，投入時間和資源投資信任權杖 | 我們的目標是打造適合生態系統的技術，並讓業界和監管機構針對這個流程提供意見回饋。在開發 Privacy Sandbox 並向開發人員提供提案 (包括信任權杖) 的過程中，我們會持續諮詢世界各地的監管機構。和所有新技術一樣，公司應根據自身的法規需求來制定決策。 |
| 啟動時間 | 信任權杖何時會在 Google Analytics (分析) 推出？ | 我們在 privacysandbox.com 上的公開時程提供目前的預計送達時間。在決定推送日期至正式發布前，我們會透過 Chrome 的發布程序公開這項資訊，並在網站上更新時間表。 |
| 信任權杖與其他來源 | 其他正在經過標準化的權杖 (例如私人存取權杖) 中，信任權杖的作用是怎樣 | 因此積極參與標準化討論，我們的目標是盡可能協調其他工作，同時運用不同技術能創造的不同使用情境。舉例來說，信任權杖和私人存取權杖都仰賴 Privacy Pass 通訊協定。 |
| 數據用量上限 | 每頁兌換代碼時最多應有 2 個核發者， | 我們正在尋找長期可行的方案，讓公司可以安全地兌換權杖，而不會面臨更多使用者熵，也許可以分區取得權杖的存取權。 |
| 存取限制 | 只有獲得核准 (且經驗證/非假冒的參照網址) 來源，才能驗證權杖是否存在並兌換 | 我們正在研究可以查看及兌換權杖的權限。 |
| 裝置支援 | 限制在某些裝置上使用 JavaScript 執行階段依附元件。TT 支援功能可以擴及其他類型的裝置嗎？ | 這是我們日後的開發方向，我們非常樂意在 W3C 論壇中收到更多開發人員的意見。此外，我們也有尚未解決的問題，說明如何討論由 HTTP 標頭觸發的權杖兌換作業，但我們也邀請使用者提供意見回饋。 |
| 用途 | 不清楚信任權杖的正確用途。不清楚預定用途。 | 我們的目標是促進反詐欺空間的創新，也瞭解每家公司可能會使用信任權杖的獨家技術，因此我們尚未針對預期用途提供規範。不過，我們可能還會擴充說明文件，以提供更多範例，協助正在考慮進行實驗或採用這項技術的合作夥伴。 |
| 信任權杖涵蓋範圍 | 移除這項「trust-token-redemption」功能政策應可大幅增加信任權杖涵蓋率。 | 這是因為我們會收集 OT 的意見回饋，並做出後續步驟。 |
| 核發者信任 | 為何我們應該信任核發信任權杖的網站？ | 如何成為核發機構，我們並未制定任何準則，不過，發布商只能與自己信任的發卡機構合作。此外，廣告生態系統中的其他合理行為人最終也會調降 (或停止購買) 與可疑或不明發卡機構相關的流量。 |
| 第三方嵌入服務 | 第三方嵌入服務可以兌換及/或要求信任權杖嗎？ | 可以，第三方嵌入服務可以核發及兌換信任權杖。 |
| 發卡機構生態系統 | 只要與其他公司共用信任信號，就能發揮更大的效用 | 信任權杖採用低階基元設計，可供合作的核發機構/兌換者用來分享信任/信譽信號。 |
| 維護負擔 | 針對密碼編譯實作的基礎「Trust Token」作業採用 BoringSSL，Google 則是唯一維護者。如何管理程式庫？ | 信任權杖採用標準化的加密編譯作業 (請參閱 Privacy Pass 通訊協定)，這也適用於其他程式庫。建議開發人員在所選的程式庫中要求/開發/維護這些作業的支援服務。 |
| 維護負擔 | 不清楚通訊協定版本的支援時間長短 | 我們正致力於開發及記錄更具體的通訊協定版本支援時間範圍。 |
| 發卡機構限制 | 如果您位於供應鏈中更進一步，可能就無法獲得執行信任權杖的機會 | 隨著越來越多機構開始使用信任權杖，我們有越來越多這類時程運用在運作中的變化，目前正在研究可行的解決方案。如前所述，我們正在尋找長期可行的方案，讓企業能夠安全地兌換代幣，而不必擔心使用者會流失，以便降低位置在頁面位置或載入順序的重要性。 |
推出全新反詐欺解決方案
| 意見回饋主題 (Ranked by Prevalence) |
問題與疑慮摘要 | Chrome 回應 |
| 裝置完整性認證信號 | 一般來說，強力支援可運用平台認可的裝置完整性信號，並開放網路使用 | 我們會持續透過公開設計與疊代收集意見回饋及追求提案。 |
| 裝置完整性認證信號 | 問題在於新信號能夠傳達多少使用者熵，以及特定用途 (例如使用者登入銀行) 是否能證明較高的熵信號。 | 我們致力提供高價值信號，並盡可能減少使用者熵，以維護使用者隱私。 |
| 裝置完整性認證信號 | 這個信號是否會限制舊型裝置或開放原始碼/經過修改的平台的存取權？ | 凡是新的信號，都應該將通用存取視為開發過程中的關鍵原則，這些重要問題都必須及早解決，我們會持續發展。 |
| 裝置完整性認證信號 | 新信號會讓安全機制和反詐欺公司過度仰賴瀏覽器和平台，會擔心
|
任何新信號都應該視為補充資料，不代表瀏覽器「信任」。我們期盼資安公司能繼續仰賴自家專屬資料、模型和決策引擎，同時取得裝置認證。希望新信號能改善整個生態系統的偵測機制，讓詐欺活動更難以執行。 |
| Cookie 年齡層信號 | 這項概念感興趣，但可能需要進一步研究適用用途。 | 視興趣程度而定，Chrome 可能會對這個概念進行進一步的構思，並在日後提供生態系統意見回饋時參考。 |
| 用於防範詐欺的受信任伺服器 | 這項概念感興趣，但可能需要進一步研究適用用途。 | 視興趣程度而定，Chrome 可能會對這個概念進行進一步的構思，並在日後提供生態系統意見回饋時參考。 |