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