2023 年第 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、Protected Audience 和 Attribution Reporting API 相關的問題和意見回饋。
目前報表統計期結束後，您收到的意見回饋可能尚未視為 Chrome 回應。
縮寫詞彙表
- 方塊
- 具有獨立分區狀態的 Cookie
- DSP
- 需求端平台
- FedCM
- Federated Credential Management
- FPS
- 第一方集合
- IAB
- 互動廣告局
- IdP
- 識別資訊提供者
- 網際網路工程任務組 (IETF)
- 網際網路工程任務組
- IP
- 網際網路通訊協定位址
- openRTB
- 即時出價
- 加時
- 來源試用
- PatCG
- 私人廣告技術社群團隊
- RP
- 信賴黨
- 賣方平台
- 供應端平台
- TEE
- 受信任的執行環境
- UA
- 使用者代理程式字串
- UA-CH
- 使用者代理程式用戶端提示
- W3C
- 全球資訊網協會
- 建構中
- 正視 IP 失明
一般意見回饋，不使用特定 API 或技術
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 3PCD 時間軸 | 分享更多有關 3PCD 時間軸的資訊。 | 為協助測試，自 2024 年 1 月 4 日起，Chrome 預設對 1% 的使用者限制 3PC 的存取權。為解決 CMA 後續問題，Chrome 計劃在 2024 年第 3 季逐步停止支援 3PC，並持續到 2024 年年底。 |
| 3PCD 時間軸 | 2024 年第 4 季 3PCD 的時間影響 (由於會同時落在節慶季節期間)，可能會對發布商造成負面影響。 | 淘汰 3PC 之後，據我們所知，在 2024 下半年，我們都很明確地決定淘汰 3PC。我們對於 CMA 的承諾 (包括考慮「待命」期間可能出現的時間) 並未改變。我們瞭解第 4 季的時間問題，但對時程做出調整的做法，往往讓整個產業做好萬全準備。 |
| Chrome 測試 (模式 A/b) | 每個執行個體還是每個 Chrome 設定檔，採用模式 A 和模式 B 的測試設定？ | 我們已在這裡說明文件中清楚說明 Chrome 瀏覽器是指 Chrome 用戶端：裝置上的 Chrome 安裝作業。每個個別使用者的資料目錄都會構成一個獨立的用戶端。 |
| 淘汰試用期 | 分享更多有關 3PCD 試用版的資訊。 | 我們已經在這裡提供了更多 3PCD 試用的相關資訊。 |
| 淘汰試用期 | 沒有足夠時間在 2024 年 1 月前為所有網站提供淘汰試用權杖。 | 我們瞭解，從淘汰試用計畫註冊開始，到 Chrome 輔助測試期開始封鎖 1% 的 Cookie 後，要等待一小段時間。為解決上述時間限制，Chrome 將為參與來源提供寬限期，並努力部署淘汰試用權杖。在寬限期 (2024 年 4 月 1 日) 內，註冊淘汰試用計畫的來源即使尚未部署權杖，仍然可以在 Chrome 中存取 3PC。寬限期是為了在過渡階段避免網路相容性問題。採用計畫的來源必須在寬限期結束前部署淘汰試用權杖，才能在寬限期結束後繼續使用 3PC。 |
| Chrome 測試 (模式 A/b) | 模式 B 對樣本太小，無法正確評估效能下滑情況。 | 要在流量百分比，以及對使用者和功能上可能影響的風險，必須謹慎小心。 |
| 測試控制項 | 只有規模極大且擁有豐富開發資源的大型發布商，才能瞭解測試期間的成效，並將這項資訊提供給 CMA。 | 我們發現發布商服務供應商已公開與廣大的生態系統分享洞察資料，並預計在 Privacy Sandbox 測試增加後持續運作。我們也期望根據 Privacy Sandbox API 建構的廣告技術公司，仍會繼續開發客戶需求功能，例如根據標籤製作報表。 |
| 第三方資料 | 對第三方資料公司有疑慮。 | 第三方資料公司有多種不同類型。有些網站可能會大幅成長，轉而採用更不透明的跨網站追蹤方法。其他公司則可能傾向於探索隱私強化技術，並與客戶發展新的價值主張。希望使用者和監管機關越來越要求採取後者，並朝著方向前進。改變是革新與創新的良機。 |
| Google Ad Manager | 需要更多 Google Ad Manager 指南，瞭解如何發布商測試 Privacy Sandbox。報表資料不足，發布商無法瞭解相關影響。 | Google Ad Manager 提供的回應： Google Ad Manager 說明瞭如何使用由 Chrome 提供的測試標籤來執行測試。詳情請參閱說明中心。 Ad Manager 目前為發布商提供 Topics 和 Protected Audience 報表。截至這份意見回饋報表為止，Ad Manager 可提供透過 Protected Audience API 放送的曝光報表，並指出特定曝光是否來自 Topics API 資料。 如果發布商想取得更精細的報表，例如根據 Chrome 協助標籤區隔報表等，可以直接在 Chrome 中讀取標籤 (使用 Chrome 說明文件)，然後在向 Ad Manager 發出的廣告請求中，將這些標籤當做鍵/值傳遞，並用鍵/值報表製作標籤報表。 |
| 測試獎勵 | 廣告主對 Privacy Sandbox 有充足的時間測試，以及日後是否有重大 API 變更的可能影響。 | 我們知道有些人想要更多時間，但業界屢次向我們反映，移動時程可能較不容易造成生態系統備妥，這並非由衷。雖然停用 3PC 的時程須能解決 CMA 其餘的競爭問題，但我們還是鼓勵所有人在 2024 年，為 3PCD 做好準備。 就像任何技術，Privacy Sandbox API 也會持續改進。隨著技術和生態系統的輸入持續進步，這波趨勢變化。我們會持續對我們做出變更，承擔相關責任，並認為技術上的變動不應永遠禁止使用。 |
| 連網電視 | 沒有支援線性或連網電視影片的路徑。 | 我們非常期待進一步探索連網電視的應用實例，但也認為連網電視裝置的 API 無法做為 Chrome 的 3PCD 服務。 |
| 廣告主廣告伺服器 | Google 似乎會將廣告指定目標轉移至 DV360。Google 將對廣告客戶廣告伺服器提供哪些支援服務？ | Chrome 提供的回應： PA API 可讓廣告客戶廣告伺服器使用 iframe / Fenced Frames 和信標報告功能，放送並評估向使用者放送的廣告。此外，他們也會與上游和下游方合作，按照目前的方式，整合到放送流程中。 |
| Google Ads 資料管理工具 | 最近宣布了「Google Ads 資料管理工具」，以「目標客戶比對」和「強化轉換」為基礎，讓廣告客戶能與 Google 共用第一方客戶資料，以便維護第三方服務的所有行銷活動。這項新功能如何與 Google 對 CMA 的承諾相符？ | Google Ads 提供的回覆： Google Ads 資料管理工具可方便廣告客戶上傳廣告主資料儲存系統 (雲端) 的第一方資料，供目標顧客比對 (CM) 和強化轉換 (EC) 使用，讓中小型企業的技術資源較少。Google Ads 資料管理工具不會為 Google 自有自營或第三方發布商的廣告可處理性或可評估度，為社群管理員或強化轉換提供任何全新功能。 Google 廣告平台能夠存取 Privacy Sandbox 技術中的功能，與其他廣告技術公司相同。 |
| Chrome 設定 | Chrome 的內部設定頁面應提供關於 Cookie 大小的詳細資訊。 | Chrome 開發人員工具已提供要求的功能。歡迎您前往設定頁面，瞭解為何應優先顯示這項功能。 |
| 經驗法則 | 在 3PCD 期間，Chrome 會部署哪些經驗法則來保留關鍵的使用者體驗？ | 查看我們針對 GitHub 上這個問題的回應。 |
| 瀏覽器版本 | 要區分穩定版與非穩定版的 Chrome 瀏覽器嗎？ | 不過，Chrome 主要版本與穩定版發布週期的大致一致。 |
| 法規遵循 | Chrome 可以提供 SOX 相關的報告嗎？ | Chrome 不提供 SOX 相關報告。Privacy Sandbox API 是 Chrome 為使用者造訪網站提供的眾多網路 API 之一。與所有網路 API 一樣，API 呼叫端不需要與 Chrome 簽訂協議，因此無法使用 Privacy Sandbox API；存取權取決於 API 呼叫端是否符合任何技術規定，且使用者已啟用適當設定。如果是的話，API 呼叫端本身就會決定 API 的使用方式，包括要儲存哪些資料、要設定的出價，以及要要求的報表等等。 |
| 法規遵循 | 擴充 Privacy Sandbox 法規遵循常見問題，解答更多問題。 | 感謝大家提供寶貴意見，日後將進一步納入常見問題集。 |
| Chrome 問題 | 淘汰 Chrome 的 3PC 是否會對 Android WebView (內嵌瀏覽器) 3PC 的可用性造成影響？ | 除了啟用跨應用程式和網站歸因評估之外，這個 3PCD 或 Privacy Sandbox API 推出和測試階段，我們目前尚未納入 WebView。 |
| API 問題 | 如何追蹤贊助產品的點擊次數和曝光次數？ | Attribution Reporting API 涵蓋這個用途。 |
| 時間表 | 為什麼 3PCD 的時間表有所調整？ | 請參閱這篇文章瞭解原因。 |
| Chrome 擴充功能單一登入 (SSO) | 允許在 3PCD 之後，於網站和 Chrome 擴充功能之間使用單一登入。 | 我們會討論這個問題，也歡迎針對其他用途提供意見回饋。 |
| API 使用量 | Google 是否可以確認要用來測試 API 的合作夥伴清單？ | 如要瞭解已公開辨識出自己身分的測試人員，請前往 GitHub 查看下列 API 的資料： - Topics API - Protected Audience API - Attribution Reporting API - 共用儲存空間 - CHIP |
| Utiq 計畫 | Chrome 對於 Utiq 計畫的看法為何？ | 我們會在這裡討論這項功能。 |
| Chrome 問題 | 如何偵測未使用 3PC 的使用者？ | 沒有明確的 3PC 封鎖偵測設定。至於一般的「功能偵測」做法，建議您建立 iframe / 跨網站要求，嘗試為必要用途設定類似的 Cookie，就是最接近的解決方案。 |
| Chrome 問題 | 無痕模式瀏覽是否與執行旗標測試相同 (使用 --test-third-party-cookie-phaseout 指令列旗標啟動 Chrome)？ | 無痕模式與旗標不同。旗標不僅可封鎖 3PC，還可啟用 FedCM 和第三方儲存空間分區。 |
| Chrome 問題 | 進一步瞭解各區域/國家/地區 3PCD 達 1% 的預期影響。 | 全球各地的客戶均以 1% 的比例隨機分配，但可能會因地區而異。舉例來說，裝置和 Chrome 版本的分佈可能有所不同。 |
| 替代隱私權強化技術 | 應允許替代隱私權強化技術，執行隱私保護的跨網域追蹤，防止 Chrome 和 Android 上的資料獨佔性。 | 除了我們目前提供的建構模塊外，開發人員還有充裕的機會，能建構隱私強化技術產品/服務。 |
| Cookie 圖表研究 | 如 Privacy Sandbox 架構中的這份文件所述，Chrome 對 Cookie 圖表方法的看法為何？ | 我們正在審閱這份白皮書，也歡迎您提供其他意見。 |
註冊與認證
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 註冊設有限制 | Google 推出了 Privacy Sandbox API 專屬使用條款。條款能有效防止擅長發布商辨識同意訪客，進而測試及/或在身分識別解決方案中整合 Privacy Sandbox 功能的公司。條款及細則以不公平的方式限制其在 Privacy Sandbox 中運作的能力。 | 註冊和認證程序並不涉及同意 API 使用條款。註冊和認證是為了讓開發人員更清楚瞭解 Privacy Sandbox API 呼叫，以及他們存取資料的方式。具體來說，認證是公開聲明，證明認證開發人員不會使用 API 跨網站或應用程式識別使用者，也不會以其他方式規避 API 的隱私保護措施。認證不需要聲明開發人員使用其他資料或技術。 |
| Privacy Sandbox 註冊 | 如何更新用於認證的聯絡窗口 / 電子郵件地址？ | 您可以使用註冊表單更新註冊資訊。詳情請參閱這裡。 |
| Privacy Sandbox 註冊 | 煩請說明在沒有認證的情況下，合適的存取權終止情境。 | Privacy Sandbox 將有 3 週的時間，讓技術聯絡人重新為已註冊的網站重新建立認證檔案，再拒絕已註冊的公司存取評估和關聯性 API。 |
| Privacy Sandbox 註冊 | 我們如何使用非實際工作環境端點測試本機環境中的 API？ | 我們已經在這裡回覆這個問題。 |
顯示相關內容和廣告
主題
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 適合不同類型的利害關係人 | 發布商擔心主題會對資料導向銷售產生哪些影響。系統一律會將一般的「新聞」主題指派給網站，但不會有資料連結至特定發布者。專業發布商會將資料提供給專員，只提供有限的資訊。 | 我們瞭解，比起小眾興趣領域較多的網站，內容越廣泛，主題越籠統的網站所能說明的主題就越少。不過，並非所有小眾網站都會提供商業有價值的主題。另外，這項動態資訊反映了現況，因為有些網站比 3PC 的廣告關聯性系統中的網站更有價值。Topics (和整體 Privacy Sandbox) 可讓發布商進一步控管合作的廣告技術公司如何使用個人資訊。此外，Topics 提供的資訊比現有信號少很多。 |
| 發布商廣告伺服器 | 使用專屬廣告伺服器的發布商廣告伺服器可能無法直接觀察 Topics API。 | 我們將在這裡討論這個問題，如有任何意見，也歡迎提出。 |
| 確認聲明 | 擴大認證要求，解決跨情境傳輸資訊造成的已知不理想結果。 | 目前認證不適用於涵蓋這類風險類別，而是專門用來解決 API 濫用情形。 |
| 主題流量 | 目前獲得的曝光量不足以進行測試。 | Chrome 瞭解程式輔助生態系統中 Topics 數量的意見回饋。我們正在調查可能的原因，包括瀏覽器內部和相關測試人員。如有必要，Chrome 會評估哪些潛在的 API 設計變更，以提高涵蓋率、大規模執行測試，同時保護使用者隱私。 |
| API 使用量 | Topics API 頻率限制嗎？ | 設定 Topics 的頻率限制，是為了避免濫用行為，以及保護使用者的網路使用體驗。詳情請參閱 這篇文章。 |
| V2 分類 | 美國互動廣告協會 (IAB) 針對主題詳情準備的指南，要包含在開放式即時出價通訊協定中？ | 可以，如要瞭解 IAB 在 Open RTB 通訊協定中加入 Topics 的相關規範，請參閱 這篇文章。 |
| 對第一方信號的影響 | 精細的主題分類第 v2 版結合了傳回最高精細區隔 (熱門主題) 最高值的流程，會扭曲廣告資料市場。 | 第 3 季的應對方式維持不變： 雖然 Topics API 較為精細，但運用發布商第一方資料或直接交易的解決方案，可能會間接降低其他解決方案的吸引力。開發 Topics API 的主要目標，是確保在 3PCD 之後，盡可能支援按照興趣顯示廣告的用途，協助所有相關人員使用。我們相信，擴大 Topics 的實用性將提升整體競爭程度，並使整個生態系統受惠。」 |
| 測試人員清單 | 您有多少發布商採用 Topics API 和 PA API？ | 我們無法提供這類資訊。你可以參考測試人員 名單，讓發布商選擇分享自己的測試狀態。 |
| 主題選項 | 要允許使用者主動選取感興趣的主題嗎？ | 我們當然考慮過讓使用者主動新增主題。我們並未計劃在短期內解決這個問題，但也開放更長期地探索這項解決方案。 |
| 主題選項 | 如果廣告技術在網站上提供程式碼來觀察主題，他們是否能知道系統可能觀察到的主題？ | 廣告技術公司可以決定與網站相關聯的主題。API 不會即時分享這些資訊，因為這可能會導致延遲成本。 |
| V2 分類 | Topics 最多可傳回 3 個 Topics，因此分類 v2 推出後預期會發生什麼行為？ | API 仍會傳回最多 3 個主題，且會在回應中加入每個主題的相關分類版本。 |
| (也適用於前季度的報表) Topics 觀察 |
允許發布商授予 Chrome 根據網頁內容 (例如標頭或內文) 分類主題的權限。 | 與第 3 季相比，我們的因應措施仍維持不變： 「我們先前考慮提供功能，根據網頁內容將網站分類為主題，並根據隱私權和安全性疑慮決定不繼續採用這項功能。本提案可能會減少部分這類疑慮，但不清楚相關程度。由於 CMA 實驗即將開始，我們預計在 3PCD 之前不會進行這項變更。歡迎按這裡提供更多意見回饋。」 |
| 主題選項 | 系統是如何根據一般性質將網域分類的網域？ | 我們只會使用主機名稱將網站分類為 Topics。而歸類為廣泛性質的網站則不會受到負面影響。這是因為網站的競價隨時都能進行競價，以便針對更廣泛的主題提供更明確的資訊。 |
| V2 分類 | 希望主題能與其他標準 (例如 IAB) 更一致。 | 進一步瞭解為何他們希望 IAB 和 Topics 分類能更貼近需求。他們需要採取哪些步驟才能使用 Topics API？更明確的分類會如何影響這些步驟？我們正在考慮發布 Topics 分類與 IAB 內容分類之間的對應關係。建議瞭解這麼做能否解決發布商面臨的難題。 |
| 資料儲存與使用 | 你想進一步瞭解資料的儲存方式和轉移位置嗎？ | 系統會產生主題資訊並儲存在使用者的裝置本機上。收到要求時，API 最多可將 3 個 Topics 傳回呼叫端。以 Google 觀點來看，呼叫端在處理及儲存 Topics 資訊時，有責任遵守當地法規。此外，所有呼叫端都必須確認並未使用 Topics 跨網站重新識別使用者。詳情請參閱隱私權相關法規遵循常見問題。 |
| V2 分類 | Topics 分類升級和瀏覽器狀態 (從第 1 版轉換至第 2 版) 的影響。 | 根據先前的分類推論出的主題仍可使用，而且在有效期限 (4 週) 前可由廣告技術擷取。 |
| API 說明 | Topics API 的使用者體驗會誤導使用者。 | 我們已將這份意見回饋提供給使用者體驗團隊。 |
| API 問題 | 系統如何判斷 Yahoo 網域是否屬於一般性質？ | 我們只會使用主機名稱將網站分類為 Topics。我們必須瞭解，廣泛分類的網站不會受到負面影響。 |
| Topics 可用性偏低 | 測試人員收到的 Topics 數量偏低。 | Google Ad Manager 推出了幾項最佳化功能以提升涵蓋率，屆時買方應會看到涵蓋率提高。某些預期因素可能會限制涵蓋率 (例如使用者偏好設定、呼叫者的觀察要求、可能會發生延遲/逾時)。 |
Protected Audience API (舊稱 FLEDGE)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 差異化教學 | 未清楚說明賣方平台為新競價帶來差異化優勢的方式。 | 先前我們聽過多項策略計畫，將 Protected Audience 和/或其他 Privacy Sandbox API 放在最顯眼的位置。 縱觀全局，生態系統的賣方常會發現眾多跨網站 ID 的減少情形，不僅是保障隱私權及商業價值的積極措施。擁抱這項異動的企業和規模的企業，都有機會找到商機。 |
| 顯示廣告 | Chrome 是顯示廣告的唯一途徑。Protected Audience 顯示功能降低了目前符合原生廣告標準的可行性。 | 在瀏覽器中顯示廣告始終都是透過瀏覽器技術呈現。這一點並未改變。這可能是出於特定計畫，要求日後將 Fenced Frames 與 Protected Audience 搭配使用。其中之一是因為我們希望 Fenced Frames 技術能夠支援生態系統革新，並在廣告顯示方面脫穎而出。感興趣的開發人員和公司仍有時間可以評估 Fenced Frames 的方向，包括如何支援原生廣告。 |
| 輸入 | 在許多廣告技術開始探索 Privacy Sandbox API 前，Concern Protected Audience API (PA API) 的提供量更大或更少。 | 根據我們從使用情況中學習的內容，以及 Chrome 內外的新想法，持續改進 API。現今可用的關聯性和評估 API 相當穩定，但這並不表示開發已停止，我們也歡迎您提出其他意見。 |
| 競價設計 | Protected Audience 設計會將所有目標對象建立和廣告選擇邏輯放在買方平台，讓賣方平台不再為在其平台上放送的廣告活動提供建立目標對象的功能和廣告選擇邏輯。 | Protected Audience 適用於建立目標對象和對目標對像出價的使用者。賣方平台可以為賣方建立興趣群組 (IG) 以供出價使用。賣方平台也可提供出價邏輯，這個邏輯似乎與許多賣方平台直接採用代理商的方向一致。雖然還有其他用途有空間可以運用，但 Protected Audience 的基礎具備靈活彈性，可支援建立和啟用目標對象的不同方法。這些基金會的隱私權特性也意味著不同網站之間不會共用原始的使用者層級資料。 |
| 競價設計 | Protected Audience 競價是否與生態系統供應路徑最佳化 (SPO) 相輔相成，以減少廣告客戶與發布商之間的中介總數，以及/或重複特定廣告商機的重複交易？ | 不會。在 Protected Audience 中，勝出的廣告最多會通過最多兩個賣方實體 (例如賣方平台和發布商廣告伺服器)；如果買方與發布商有直接整合，則只能傳遞少數實體。 發布商可自行決定是否透過多個中介機構複製相同要求。Protected Audience 不應相互影響。 Protected Audience 競價會在現今的伺服器對伺服器即時系統外進行，以免洩漏跨網站使用者資料。有些人可能會說這就與廣告請求重複。要在技術層面上實現隱私實證，確實需要一些取捨。不過，長遠來看，生態系統可能決定不使用 Protected Audience，而不使用傳統的伺服器端競價。這麼做有機會打造更優異的供應路徑。 |
| 競價設計 | Protected Audience 轉換至這個模式，賣方平台通常不會在網頁上「上次」競價，但 API 設計卻強制採用這個模式。 | 我們並不同意。我們發現，早期採用者的導入方式確實因此使參與元件競價的賣方平台勝過內容相關競價 (也就是在 Protected Audience 競價開始前) 的競價結果。執行完整內容競價後，系統會考量 Protected Audience 中的賣方平台元件競價結果。 |
| 競價設計 | 內容競價可能只與提供競價商機相關資料信號，做為 Protected Audience 競價的依據。 | 內容比對競價仍應考量各種情境因素，例如交易、非第一方目標對象廣告活動和大量情境情境，如果沒有任何 IG 事件，或 Protected Audience 中的出價未能達到底價或遵守廣告品質規則，這項功能也會很有價值。 |
| 流量型態 | 需求端平台是以固定的 QPS 運作。比對 Protected Audience 競價會降低舊版基礎架構的實用性。 | 據我們所知，每秒查詢的差別在於，許多賣方平台會使用跨網站 ID 來判斷是否要傳送 DSP 請求。無論發布商是否想要執行 Protected Audience 競價，結果都一樣。 我們與許多賣方平台研究流量型態，並發現了快取和內容導向篩選功能等解決方案。長期下來，我們預期開發人員將能利用「私人匯總」，進一步掌握需求端平台的出價偏好設定，並據此進行篩選。 最終，以跨網站 ID 為基礎所建構的部分舊版基礎架構將不再有用。 |
| 可用的信號 | 競價發生時可用的各種信號不夠明確，也不清楚內容比對競價的排序優缺點。 | 一般來說，如果是出價工具，系統會在建立 IG 時提供資訊，來源包括內容相關競價，以及透過即時鍵/值查詢。以計分者來說，系統會在競價設定時提供資訊，包括網頁和內容相關的競價資訊，以及對廣告轉譯網址進行即時鍵/值查詢。 |
| (前幾季記錄) 影片顯示 |
支援使用 Protected Audience 和 Fenced Frames 顯示影片。 | 與前幾季相比，我們提供的回應內容並無不同： 「Protected Audience API 支援透過仰賴 iframe 的機制顯示影片。然而，我們尚未設計出與 Fenced Frames 相容的解決方案，這也是我們決定將 Fenced Frames 強制執行延期至 2026 年的原因之一。換句話說，如果合作夥伴決定立即強制執行 Fenced Frame，該合作夥伴就不能支援影片。」 |
| 影片算繪 | iframe 中的影片 PA API 支援僅限於 HTML5 影片，且不支援廣泛使用的 VAST 標準。 | 您可以使用 Protected Audience 中提供的 iframe 顯示機制，導入 VAST 廣告。Google 瞭解，買方、賣方和發布商廣告平台需要有新的工程技術，因此我們將繼續努力簡化 VAST 過去的運作方式。 |
| (於前季記錄) 頂層競價 |
能夠使用 Google 的發布商廣告伺服器，但不能同時讓 Google Ad Manager 掌控頂層 PA API 競價。 | 與前幾季相比，我們的回應並無不同： 「Google Ad Manager 提供的回應： 在沒有頂層 Protected Audience 競價的情況下，Google Ad Manager 的 Protected Audience API 計畫不在支援頂層 Protected Audience 競價的情況下，才支援 Google 發布商廣告伺服器。 為了在發布商廣告放送市場妥善為客戶提供服務，Google 的發布商廣告伺服器必須保有頂層 Protected Audience 競價的控制權。身為發布商廣告伺服器，我們扮演的角色是為發布商提供預測功能，方便發布商在不超量預訂的情況下協商直接銷售廣告活動，並以最適當的方式調整並放送直接預訂廣告活動。具體做法是進行最終競價來比較所有符合資格的直接和間接需求。 預測和放送速度是發布商希望廣告伺服器提供的核心功能。如果沒有準確的預測功能，發布商最後可能會超量銷售廣告空間，進而使自家業務信譽降低。此外，若無法與廣告客戶履行預訂合約，發布商與廣告客戶之間的直接關係也會損害發布商與廣告客戶之間的直接關係，因此使用速度也很重要。 簡單來說，發布商廣告伺服器在執行頂層 Protected Audience 競價的活動，並不會與發布商廣告伺服器的其他活動不同。」 |
| (於前季記錄) 直接來自 SellerSignals |
DirectFromSellerSignals 可讓 Google Ad Manager 防止發布商看到內容相關競價的價格。 |
我們的回應與前幾季相同： 「Chrome 回應： 除非賣方從自己的 iframe 呼叫 runAdAuction()，否則賣方無法辨識傳遞至 runAdAuction() 的資訊。在多重賣方競價中，所有賣方將無法建立呼叫 runAdAuction() 的頁框。directFromSellerSignals 可以載入賣方來源所載入的子資源組合內容，藉此解決這個問題。這樣可確保賣方競價設定傳入競價的資訊真實性和完整性。如果發布商想使用 Protected Audience API 瞭解自家技術供應商傳送到 Protected Audience 競價的任何資訊，可以要求這些技術供應商提供這項功能。 Google Ad Manager 提供的回應： 多年來，我們一直相當重視競價公平性，包括承諾發布商的任何無保證廣告來源 (包括無保證委刊項的價格) 都不會在競價期間與其他買方分享，而我們之後也針對法國競爭主管機關的承諾。 在 Protected Audience 競價中，我們打算利用 DirectFromSellerSignals 來履行我們的承諾，而且在多重賣方競價的競價完成前，不會向任何其他競價參與者透露任何競價參與者的出價。明確來說，我們不會和自己的元件競價分享內容相關競價的價格 (詳情請參閱這項更新)。 |
| (於前幾季記錄) K-anonymity 值 |
如何決定「K」到「k-anon」的值以及發布時間？ | 我們在 2023 年 12 月發布了 K-anonymity 值。3PCD 程序開始後，我們會提高 k-anonymity 門檻的最終值 (k=50)，並將更新期間設為 1 小時 (p=1)。經評估後，K-anonymity 值為 50，可在公用事業和隱私權之間取得最佳平衡。這個值足以阻止基本機器人攻擊並維護差異化隱私，同時也能保持低落，確保 API 可持續發揮其預期用途。 |
| (在前幾季記錄) forDebuggingOnly |
如果 3PCD 之後仍存在，可能會濫用 forDebuggingOnly.reportAdAuctionWin。 | 我們分享瞭如何長期持續支援偵錯用途的提案，請見這篇文章。歡迎您對提案提出其他意見回饋。 |
| (於前幾季記錄) 相同來源政策 |
要求放寬相同來源政策，以允許子網域。 | 我們正在考量這項要求，如這裡所述。 |
| (於前幾季記錄) 廣告元件大小 |
將廣告元件數量從 20 個增加到 40 個。 | 我們在 10 月 4 日 WICG 通話和這個 GitHub 問題中討論了這項要求，預計 2024 年第 1 季結束前解決。 |
| (於前幾季回報) 金鑰值伺服器金鑰到期日 |
在相應的 IG 過期後，討論如何移除伺服器金鑰。 | TEE 外的工作流程管理方式較為複雜，因此如要降低複雜度，請前往這裡提供額外的意見回饋。 |
| 興趣群組觸發條件 | 單一 IG 是否可以在單一 (元件) 競價中觸發多個產生出價？ | 每次瀏覽器呼叫 IG 的 generateBid() 函式時，IG 可以傳回出價值。舉例來說，在多重賣方競價中，IG 會在每次的元件競價中多次呼叫同一個 IG。 開發人員不需明確採取其他動作，就能啟用/支援 IG 的行為。 |
| 法規遵循問題 | 透過使用者的 Chrome 瀏覽器收集同意聲明的許可範圍為何？ | 詳情請參閱隱私權相關法規遵循常見問題中的「Privacy Sandbox 如何因應 Chrome 的隱私權相關法規？」。 |
| 多代碼競價 | 如何參與多代碼競價？ | 我們正在評估這項要求，如有任何意見，歡迎按這裡。 |
| IP 保護可用性 | 如果 IP 保護功能未能在宣布日期前準備就緒，導致 Protected Audience 功能時間軸 (例如強制執行圍欄架構，以及移除或移除事件層級報表) 會受到什麼影響？ | 如這裡所述，我們相信 Protected Audience 的時間軸應與其他隱私保護功能的發布時程有所關聯。 |
| modelingSignals | 除了模擬只能編碼顯示和點擊資訊的模擬信號之外，也要求取得新欄位。 | 我們瞭解這項技術能帶來的公用程式收益，目前我們正在評估這項要求，歡迎按這裡查看更多意見回饋。 |
| 負面 IG | 可以允許一般 IG 指定負的 IG 名稱嗎？ | 目前這項說明不支援這項做法，但歡迎其他生態系統提供意見，說明這項規定的原因。 |
| API 使用量 | 在 generateBid() 層級產生匯總報表 | 您可以在 generateBid 中叫用「私人匯總」。 |
| 巨集 | 透過 IFrame 中的巨集將 PerBuyerSignals 的信號轉送至第三方。 | 我們會在這裡討論這個使用案例，也歡迎提供其他意見回饋。 |
| API 使用量 | 如果受信任評分信號擷取功能傳回錯誤，仍會呼叫 ScoreAd() 嗎？ | 如果擷取呼叫失敗， ScoreAd() 仍會執行。 |
| API 使用量 | 為 delta/snapshot 檔案寫入 metadata.shard_num 檔案。 | 我們現在會支援 shard_num 來解除封鎖。Riegeli 雖不像 Avro 這樣也獲得採用，但仍未放棄。由於 TEE 的限制與負擔較高，我們因此權衡利於提升效能，而非提升使用者體驗。我們考慮提供 gRPC 服務，以便透過要求建立檔案。此外，我們可能也會評估 Avro 等其他格式對成效的影響。 |
| API 測試 | PA API 和 Measurement API 如何支援成效增幅測試？ | Privacy Sandbox 無法透過反事實預先競價評估成效增幅。您可使用「共用儲存空間」和「私人匯總」，但只有在競價結束後才會進行「反事實」。 |
| API 使用量 | 使用 BiddingWasmHelperURL 進行每日更新是否會影響 k-anonymity 門檻？ | 由於 k-anonymity 不再考慮 IG 最新消息，因此 BidWasmHelperURL 可以更新並不影響門檻。 |
| API 使用量 | 我們能否收到 PA API 的錯誤通知？ | 我們很樂意向生態系統提供意見回饋，告訴他們需要哪類錯誤通知才能排解 PA API 問題。 |
| 廣告大小 | 廣告大小不會顯示在競價中，也無法提供報表。 | 我們正在解決這個提取要求的問題。 |
| API 使用量 | 如果 IG 未參與這次競價，系統是否會呼叫 IG 端點？ | 需要。系統會針對指定擁有者的所有 IG 呼叫 updateURL，即使他們沒有在特定競價中出價也一樣。唯一的條件如下： - 擁有者必須在特定競價中 (即競價設定中的買方) 加入 - 指定擁有者的 interestGroup 不得在過去 24 小時內更新。 |
| PA API 中的 Prebid | 測試階段需要使用哪個版本的 Prebid.js？ | 根據我們的技術說明文件，這個版本應為 8.9.0 以上版本。 |
| 在 PA API 中啟用第一方資料 | 他們該如何啟用自己的第一方資料，以便定義和使用 IG ？ | 您可以在這項工作中使用「權限委派」和「排除興趣群組」。 |
| PA API 和伺服器端代碼 | PA API 如何與伺服器端代碼搭配運作？ | 使用者瀏覽器的基本標記必須將 API 呼叫重新導向至伺服器端的其餘代碼，這樣使用者才能一併登錄呼叫。 |
| Chrome 測試 (模式 A/b) | 賣方平台是否預期在即時出價出價要求中也會傳送這些標籤？如果是，則會如何傳送？ | 會，標籤會從賣方平台傳送給需求端平台。我們建議實體存取標籤，並透過這個裝置額外資訊將未經修改的值提供給合作夥伴。 |
| 資料儲存與使用 | 你想進一步瞭解資料的儲存方式和轉移位置嗎？ | 我們不會提供法律諮詢，而是以更多方式/一般考量資料儲存、保留和其他隱私權問題的做法。請參閱這篇文章，查看與隱私權相關的法規遵循常見問題，或許會對您有所幫助。 |
| API 安全性 | 關於惡意用戶端程式碼操控 generateBid() 函式回傳值的疑慮。 | 我們已於這裡 討論這個問題，部分意見回饋已納入「私密匯總」提案中。 |
| 自訂目標位置 | 使用自訂目的地 reportEvent 呼叫時，您是要知道在 allowReportingOrigins 中是否已預先註冊某個 IG 中的自訂報表來源 (非買方或賣方)，是否需要使用 RegisterAdBeacon 的需求需求端平台在 reportWin 中宣告？ | 否，您不需要在 reportWin 中重新註冊，而且可以直接在 reportEvent 中使用 (如這裡所述)。 |
| API 限制 | 建立和更新期間的 IG 大小。 | 更新大小已更新為 1 MB，符合建立 IG 的新 1 MB 上限 (原為 50 KB)。 |
| K-anon 限制 | K-anon 。 | 我們在 2023 年 12 月發布了 K-anonymity 值，表明 K-anonymity 將「在 2025 年之後」開始檢查廣告大小。排除大小無法解決，因為這可能是跨網站追蹤向量 (如 10 月 11 日的 WICG 呼叫所述)。 |
| API 安全性 | 惡意玩家會偽造網頁的「主機名稱」嗎？ | 這個 API 支援設為發布者主機名稱的子金鑰。由於瀏覽器設定鑰匙，因此很難規避這項機制。 |
| API 使用量 | 不建議用於正式環境使用 ForDebuggingOnly 函式。 | 我們即將要讓生態系統瞭解，除了為 3PCD 疑難排解後的疑難排解之外， forDebuggingOnly 函式也完全不適合。 |
| 需要更多偵錯工具 | ForDebuggingOnly 不足以瞭解 ScoreAd() 之前可能發生的問題。 | 為了讓這項差距提供更多意見回饋，歡迎按這裡與我們分享。 |
| 永久退出興趣群組 | 要求使用者永久拒絕建立特殊 IG。 | 我們的策略是並未讓使用者在 IG 層級選擇停用，因為在現實生活中並不容易理解語意。 |
| 改善說明文件 | 請在規格和說明中，在 RenderUrls 參數中使用相同的大小寫。 | 感謝你提供寶貴意見，我們日後會更新說明文件。 |
| Protected Audience 交易支援 | 要求 Protected Audience 交易支援的其他選項。 | Chrome 團隊正在評估 3PCD 會如何支援這項功能。 |
| 巨集 | 需要巨集支援，才能確保 IG 大小不超過 IG 大小上限。 | 說明者最近有最新消息，針對這項要求部分處理了部分要求。 |
| 事件層級 ReportLoss API | 要求事件層級 ReportLoss API。 | 雖然事件層級損失報表可能會帶來嚴重的隱私權風險，但我們相信只要對 Private Aggregation API 進行適當修改，即可達成這項要求的基礎目標。歡迎按這裡提供更多意見回饋。 |
| API 使用量 | 如果出價分數未大於 0， forDebuggingOnly 方法會如何運作？ | 如果分數 <= 0，即為自動損失。因此系統會叫用 reportAdAuctionloss |
| 標準化 | PA API generateBid() 函式輸入/輸出值沒有對齊。 | 我們建議所有合作夥伴向 IAB Tech Lab 提出這類問題。這個小組特別針對 Protected Audience 等 API 制定業界標準。 |
| API 安全性 | Google 可以查看來自 IG 的哪些資料？ | K-anonymity 仰賴強大的隱私保護機制，防止使用者機密資料外洩給任何一方，包括 Google。Google 也正為這項技術規劃第三方實作程序 (快速)，以便降低這類風險。 |
| Chrome 測試 (模式 A/b) | 可以排除「k-anon」受限制的使用者嗎？ | 我們會在報表中顯示 k-anonymity 狀態，詳情請參閱這篇文章。 |
| 品牌安全 | 根據封鎖的網站或關鍵字清單，支援無法放送廣告的品牌安全用途。 | PA API 應已能處理這類品牌安全用途。 如要排除廣告活動指定某一組網域，他們可以將網域封鎖清單儲存在 Instagram 內部，如果列出每個網域會導致過多空間，就可以採用 Bloom 篩選器。或者，他們也可以從其鍵/值伺服器傳回允許或拒絕決定，並使用 UDF 來查詢答案的組合，而這些變數會組合出用於識別廣告活動的鍵，以及鍵值要求中包含的網域名稱。 有了 Protected Audience API，賣方平台和需求端平台也能將任何網頁內容相關資訊傳送給競價。這可能包括網頁上含有敏感主題或關鍵字的清單。需求端平台的出價邏輯可能會比較此資訊與廣告不應出現位置的任何已儲存資訊，並視需要選擇不出價。 如果生態系統認為某些特定用途並未可行，歡迎向我們提供意見。 |
| 權限委派 | 權限委派的運作方式為何？ | 我們在這裡提供了權限委派的相關說明文件。 |
| 批次要求 | 對部分 PA API 網址使用 POST 要求，以便支援批次要求。 | 我們歡迎您對這項提案提出意見，也歡迎您前往這裡提供更多意見回饋。 |
| 改善 API | 可能不應使用的欄位 (例如 X-fledge-bidding-signals-format-version-version)。 | 我們會討論此問題，歡迎點選這裡提供更多意見回饋。 |
| 改善 API | 要求將 GDPR 同意聲明傳遞給第三方廣告放送和評估服務供應商。 | 系統支援使用已淘汰的 ReplaceInURN 巨集替換 API，如這裡所述。 |
| 動態廣告素材最佳化 | Protected Audience 如何支援動態廣告素材最佳化？ | 我們會在這裡討論這個使用情境，並分享可能的解決方案。 |
| 改善 API | 申請第三方廣告放送網址，即可取得 IG 的相關資料 (主要 IG 名稱與贏得競價的 IG 相關)。 | 這類要求可能會增加使用者的追蹤風險。我們會討論這個問題，歡迎按這裡提供更多意見回饋。 |
| API 安全性 | 擔心「IG blob」的大小會洩漏所選 IG 的相關資訊。 | 如 Chrome B&A API 說明中隱私權注意事項一節所述，blob 大小與 navigator.getInterestGroupAdAuctionData() 的任何輸入內容都無關，只是將所有 IG 封裝在裝置上。這可確保網頁上的 blob 大小在頁面上具有相對一致性，並限制了跨網站資訊外洩的能力。就是這樣設計。 |
| Chrome 測試 (模式 A/b) | 在設定 Cookie 和 Chrome 協助的測試方面，其他賣方平台在未能首次載入時表現如何？ | 我們目前尚未聽到任何重大疑慮 (雖然其他人也已認同這種情況)，但如果這是重大問題，我們也歡迎生態系統提供意見。 |
| 支援 A/B 測試 | 要求支援 PA API A/B 測試。 | 我們在 11 月 WICG 會議中討論了這項要求，歡迎點選這裡取得更多意見回饋。 |
| 廣告大小 | 誰會選擇 Protected Audience 競價的規模？ | 這個問題可在 常見問題中獲得解答。 |
| 改善 API | 要求將鍵/值服務設定為接受 /bidding-signals/v1/getvalues 路徑。 | 我們在這個提取要求中新增了支援路徑前置字串。 |
| API 使用量 | 假設發布商屬於廣告客戶，應該如何使用代碼建立 IG，以便廣告客戶對其出價？ | 答案必須來自某些廣告技術合作夥伴，也就是想要參與 Protected Audience 競價的 DSP 或 SSP，並為這些目標對象建立外部來源。我們已在這個 GitHub 問題中進一步討論相關資訊。 |
| 改善 API | 請求將排除 IG 連結至「正面興趣群組」中的廣告。 | 我們正在考慮這項要求，並分享可能的支援服務提案。 |
| 資料分割數量 | 要求支援在中繼資料中傳遞「shard_num support」內容。 | 針對這項意見回饋，我們已新增對 shard_num 的支援。 |
| API 使用量 | 要求估算 K/V 伺服器中的金鑰負擔。 | 歡迎您前往這裡分享我們的想法，也歡迎您提出其他寶貴意見。 |
| K 匿名 | 要求說明及強化 K-Anonymity 計數器精細程度。 | 我們在這裡提供了 K-Anonymity 計數器精細程度的說明。 |
| 偵錯 | 根據近期提議的 forDebuggingOnly 變更，要求改進 PA API 偵錯功能。 | 我們會在這裡討論這項要求。如有任何意見，歡迎按這裡。 |
| 廣告大小 | 請求廣告版位大小，做為額外的 BTS 信號。 | 我們分享了可支援這項要求的提案，也歡迎您前往這裡提供更多意見回饋。 |
| API 安全性 | 可以依據來源限制「runAdAuction()」使用嗎？ | 歡迎參閱這篇文章，瞭解詳細回覆內容。 |
| IG 生命週期 | 要求將 IG 生命週期從 30 天延長至 90 天。 | 我們正在審核這項要求，也歡迎您前往這裡提供更多意見回饋。 |
| API 使用量 | 我可以與標頭出價和發布商的廣告伺服器呼叫同時執行 Protected Audience 競價嗎？ | 我們正在討論這項要求，也歡迎按這裡提供更多意見回饋。 |
| 偵錯 | 要求針對與開發人員工具通訊的 Chrome PA API 偵錯擴充功能提供更完善的支援。 | 如需提供更多偵錯工具的協助，我們也歡迎按這裡提供更多建議。 |
| API 使用量 | 如果元件賣方未出價爭取到排名最高的賣方，系統就不會觸發損失通知。 | 如要瞭解背後的原因，請參閱這篇文章。 |
| 改善 API | 要求在 Protected Audience 出價 Worklet 中支援 TextEncoder。 | 我們正在考慮這項要求，如有任何意見，歡迎按這裡。 |
| API 使用量 | 在用戶端中，網路呼叫和執行邏輯可能會封鎖主執行緒，並導致可能影響 SEO 的 JS 執行挑戰。 | 我們會討論這個問題，歡迎按這裡提供更多意見回饋。 |
| API 使用量 | 需求端平台是否可以使用目前的伺服器端出價漏斗，評估並傳送候選廣告，作為裝置端競價的一部分？ | 我們會討論這個問題，如有任何意見，歡迎按這裡。 |
| 擴展出價商機資料 | 要求以瀏覽器中內含有效 IG 的專屬來源網域清單，將瀏覽器傳遞給賣方平台的出價商機資料延展至賣方平台。 | 我們正在討論這項要求，也歡迎按這裡提供更多意見回饋。 |
| 單次即時出價 | 要求兩個新掛鉤在 ORTB 中，和 generateBid 回應調整作業。 | 我們正在審查這個問題，如有任何意見，歡迎按這裡。 |
| 前次獲勝 | 要求 IG 定義 prevWinsTransformer，後者會取得 IG 先前勝出，並輸出可序列化的項目。 | 我們正在審查這個問題，如有任何意見，歡迎按這裡。 |
| 內容類型 | 因應內容類型演進的策略，例如將 JSON 轉換為 CBOR 等格式。 | 我們正在審查這個問題，如有任何意見，歡迎按這裡。 |
| Protected Audience API 中的 Prebid | 要求使用預先出價的發布商範例頁面，執行 Protected Audience 競價的端對端流程。 | 我們認為這項要求應優先處理，也歡迎來自生態系統提出其他意見回饋。此外，我們也看到廣告生態系統參與者製作發布商頁面範例，可供生態系統中的其他人示範。 |
受保護的競價服務
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 可靠的執行環境 (TEE) | 相較於地端部署廣告技術資料中心，在公有雲上執行受信任的執行環境是否較昂貴？ | 我們目前的 TEE 安全性模型從採用公有雲的實作中獲益。特別是，目前的硬體式 TEE 並無法防禦所有實體攻擊。我們現有支援的公有雲端服務供應商 (AWS 和 GCP) 已設計並實施了緩解措施，以降低員工在內部存取的風險。如需內部部署支援的詳細資訊，請參閱下文 。 有我們提到，執行雲端服務的費用比地端部署廣告技術資料中心高。我們無權評估這些陳述，但歡迎對成本提出其他意見，並繼續評估 TEE 支援方案以擴大服務規模。 |
| (於前幾季回報) 地端部署 TEE |
成為 TEE 供應商需要符合哪些條件？ | 我們的回應方式與前幾季類似： 「除了繼續探索公有雲解決方案以外，我們繼續尋求其他支援選項，包括考量到安全性方面可接受哪些部署作業，但我們目前尚無計畫支援內部部署 TEE。在這個階段，由於 Privacy Sandbox 安全性要求，以及地端部署部署作業所面臨的重大挑戰，我們相信持續擴大及改善雲端式部署作業對生態系統最有助益。不過，我們還是歡迎您提供意見，說明為何在隱私權和安全性限制下，必須滿足這項條件和可行性。」 |
| 鍵/值伺服器限制 | 每部伺服器每次競價的鍵數量限制 | 我們會討論這個問題，歡迎按這裡提供更多意見回饋。 |
| K-anon 限制 | 確認日後不會針對 K/V 金鑰強制執行 K-anonymity。 | 由於我們的目標是日後將 K/V 伺服器移至 TEE，因此目前沒有強制對 K/V 伺服器要求金鑰強制執行 k-anon 計畫。 |
| 創建 K/V 服務 | Google 提供適用於 K/V 服務的預建構件嗎？ | 我們目前還沒有為 Protected Audience 鍵/值伺服器預先建構任何構件，但如果我們發現生態系統向您提出要求，我們可能會提供這些構件。 |
| B&A 中的 EgId 支援 | 要求在「出價和競價」程式碼中提供支援欄位 experimentGroupId，以及從 BuyerFrontEnd 向 KeyValue 服務發出的要求 | B&A 目前不支援 testGroupId，不過我們預計將在 Beta 版 2 推出 (目前預定於 2024 年 2 月推出)。如需瞭解詳情，請參閱這篇文章。 |
| API 使用量 | 要求 HTTP 結盟有助於防範路徑上攻擊者，但 TEE 的操作人員會學習大小。 | 我們正在討論這項要求，也歡迎按這裡提供更多意見回饋。 |
| 改善說明文件 | 規格並不清楚 k-v 伺服器要如何處理。 | 我們會討論這個問題，歡迎按這裡提供更多意見回饋。 |
| API 使用量 | 「Ad-Auction-Result」和「adAuctionHeaders」的用途為何？ | 我們將在這裡討論這個問題，如有任何意見，也歡迎提出。 |
| 改善說明文件 | 不確定第 2 版設計是否已套用至 FLEDGE.md。 | FLEDGE.md 說明 Chrome 如何將要求傳送至 BYOS-KV。第 2 版的通訊協定設計僅限於 TEE-KV，目前 Chrome 並不支援。 |
評估數位廣告
Attribution Reporting (和其他 API)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 跨環境評估 | 在 Chrome 行動版中移除 3PC，但目前還未提供 Android 版 Privacy Sandbox 的過渡階段，Chrome 會如何支援跨環境評估功能？ | 在 Android 方面，我們正努力擴大 PSB/ARA 的涵蓋範圍，Attribution Reporting API (ARA) 支援 Android 13 和 14。我們預計在今年稍晚開始將 Android 11 和 12 拓展至 Android 11 和 12，不過實際情況可能有所變動。我們不會將 Android 10 以下版本擴充至 Android 10 或更早的版本，但仍然預期搭載 Android 10 以下版本的 Android 裝置百分比會低於 3PCD 級別，且隨使用者升級裝置而自然減少。 我們也歡迎生態系統針對這項要求提供其他意見回饋。 |
| 篩選 | 從廣告素材掃描中篩選「轉換」。 | 為此，我們已與此利害關係人聯絡，希望能進一步瞭解他們的要求，也歡迎生態系統針對這個問題提供更多意見回饋。 |
| 第三方廣告伺服器 | PA API 和 ARA 如何與第三方廣告伺服器代碼搭配運作？ | 與目前的曝光和點擊代碼運作方式類似，廣告伺服器可以自行設定 ARA 的來源和觸發條件登錄 (包括來自 Protected Audience 競價)，也可以設定重新導向來傳遞及接受 ARA 的來源和觸發條件登錄。 |
| DCM | DCM 和其他第三方廣告伺服器支援 Attributionsrc。 | 這是 DCM 相關問題，並已由 DCM 團隊在這個 GitHub 問題中解決。 |
| 階層匯總鍵 | 是否需要將所有貢獻預算分配到所有的階層式鍵？ | 經過討論，並確定此利害關係人獲益良多。使用階層鍵結構時，廣告技術必須考量單次曝光的所有鍵輸出結果會共用貢獻預算。 |
| 使用其他子網域 | 要讓歸因報表使用在不同子網域登錄，但 eTLD+1 不同的情況下登錄的來源和觸發條件嗎？ | 我們已和相關人員討論這個問題，並建議下列解決方案。他們可以變更網址設定，讓來源和觸發條件採用相同的報表來源，也可以先將目前的網址重新導向至通用網址，再執行註冊作業。如果提出的解決方案不適用於自身用途，我們歡迎其他生態系統意見回饋。 |
| (另於前幾季回報) 正式版支援 |
對於使用 ARA 的合作夥伴，有哪些服務等級？ | 與前幾季相比，我們的回覆內容並無不同： 「Google 提供多種管道，讓廣告技術人員回報技術問題，並視需要提報解決這類問題。此外，Chrome 預計將進一步建立並擴充程序，解決會影響生態系統運作的技術問題和問題。Chrome 致力於確保這項作業所需的資源。 如要進一步瞭解公開和私人論壇，瞭解意見回饋和提報功能，請參閱我們的開發人員貼文。」 |
| (另於前幾季回報) 時間軸 |
Google 會在 CMA 量化測試開始時準備「第 2 階段完整彈性事件層級」嗎？ | 第 2 階段 (完整彈性活動層級) 預計於 2024 年第 1 季推出 Chrome 中。您可以前往這裡追蹤處理狀態。 |
| (另於前季記錄) 轉換漏斗 |
回報轉換中使用的多個網域。 | 由於新增了多個目的地，因此可以採用這種做法。歡迎提出其他意見回饋。 |
| 報表測試標籤 | 報告功能是否可讓測試人員回報使用者 (Chrome 瀏覽器) 加入 (模式 A/B) 的群組？ | 我們正致力發布測試指南，說明如何以 ARA 擷取 Chrome 測試標籤。 |
| 說明文件 | Attribution-Reporting-Register-Source 狀態說明文件的到期時間將四捨五入至最接近的天數，會如何四捨五入？ | 四捨五入為最接近的天數，表示 1.5 天會四捨五入為 2 天。 |
| 使用其他子網域 | 要求在不同的子網域接收 Attribution Reporting API 報表，做為來源和觸發條件登錄。 | 不可能。可以套用 HTTP 重新導向，但無法設定這類重新導向。如果這個要求對您有幫助，我們也歡迎生態系統提供意見。 |
| 事件層級報表延遲時間 | 7 天的歸因和報表回溯期，但由於事件層級的報表延遲，所有報表可能需要超過 8 天才能寄達。 | 我們瞭解各位的意見回饋，也歡迎生態系統向生態系統提供意見，瞭解這類延遲事件是否會造成問題，尤其是從固定的事件報表回溯期改為彈性的事件報表回溯期。 |
| 轉換觸發條件 | 在第一個 event_report_window (1h) 和到期時間 (1 天) 結束之間發生的轉換觸發條件不會產生報表。 | 我們導入了彈性的事件層級設定，可從固定不變的事件報表回溯期變為彈性的事件報表回溯期。 |
| 噪音 | 事件層級報表是否如 GitHub 說明所述，發生雜訊的假轉換？ | 是的，雜訊會套用至事件層級報表，用來代表所有可能的輸出狀態 (包括不同的 trigger_data，完全沒有在觸發事件實際發生時回報任何內容)，或者可能會針對該事件回報多份假報告。雜訊百分比採用開放原始碼，並可透過彈性事件層級設定靈活調整。 |
| 篩選 | 搭配 Attribution Reporting API 使用篩選功能時，即使未記錄匯總鍵，貢獻預算仍會消耗。 | 這項功能運作正常，因為 aggregatable_trigger_data 只能篩選觸發鍵本身，無法篩選值 / 鍵。頂層篩選器支援篩選鍵本身，但這項設定是以事件加上匯總的方式共用，因此不適用。如需過濾金鑰，請按這裡提供更多來自生態系統的意見。 |
| 儲存空間限制 | 要求導入儲存空間上限時，也會將報表來源納入考量。 | 這項限制將從 1024 年增加到 4096 年，自 M120 起將生效。如想收到來自生態系統的其他意見回饋，請按這裡。 |
| 直接歸因 | 標準歸因報表程序不適用於使用者直接造訪廣告客戶 (不需透過發布商)，因此如何取得指標？ | ARA 只能用於復原跨網站資訊 (也就是跨發布商/廣告客戶網站的資訊彙整)。如果不需要跨網站資訊，ARA 就無法提供協助。我們會討論這個問題，歡迎按這裡提供更多意見回饋。 |
| 報表時間 | 從時間伺服器取得 schedule_report_time 的時間，而非使用本機電腦時間。 | 我們目前並未打算使用時間伺服器，而且廣告技術的需求還不多。我們想瞭解生態系統是否提供其他實用的功能。 |
匯總服務
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| (另於前幾季回報) 內部部署解決方案 |
匯總服務可以部署至內部部署的資料中心嗎？ | 雖然我們正在探索雲端式解決方案以外的可能支援選項，但由於有地端部署安全性限制，因此 Privacy Sandbox 需要耗費大量評估時間，因此無法支援地端部署 TEE。考量到 Privacy Sandbox 安全性要求，以及地端部署部署作業帶來的重大挑戰，我們認為持續擴大及改善雲端式部署 (如在 AWS 之外支援 GCP) 對這個生態系統最有幫助。不過，我們也歡迎您在這裡提供更多意見回饋，說明這項規定的必要性。 |
| 安克拉夫 | 如果安全區未亮起或突然發生錯誤，Aggregation Service API 如何處理？ | 如果安全元件在啟動時失敗，而自動調度資源功能啟動，我們就會使用重試來啟動新的執行個體，並在執行個體健康狀態不良時啟動。廣告技術也可以使用記錄調查失敗情形。 為了在 AWS 上排除故障問題，廣告技術可以登入 AWS 控制台管理工具，檢查 EC2 執行個體的狀態。廣告技術也可登入 Nitro Enclave 主機執行個體，並使用 nitro-cli 工具查看安全檢查狀態。如果發生任何錯誤/失敗，客戶可以使用 AWS 指令列介面查看記錄並進一步調查。 廣告技術人員可以透過 Cloud 控制台檢查自己執行個體的狀態，以便在 GCP 上偵測出故障。他們也可以使用 list-errors-command 檢查錯誤。 |
| 使用其他子網域 | 要求註冊多個 (子網域) 網域，以在 dev 和 prod 環境中使用多個匯總服務執行個體。 | 已推出網站註冊功能，廣告技術人員可透過單一 AWS 帳戶或 GCP 專案註冊同一個網站的多個子網域。他們還可以在多個 AWS 帳戶或 GCP 專案中註冊相同的網域。歡迎對生態系統提供意見。 |
| 隱私預算 | 如何進一步解決隱私預算用盡相關問題？ | 我們正在設法針對用盡的預算提供更多詳細資訊，並改進說明文件，概略說明廣告技術可運用的策略，盡量避免這項錯誤發生。在有了提案之後，我們會更新 Aggregation Service GitHub 頁面。 |
| E 普西龍值 | 要求提高 Epsilon 值。 | 匯總服務的 epsilon 值最多會保留為 64 值，以利在 3PCD 期間針對不同參數進行實驗和意見回饋。我們會在 epsilon 的範圍值更新前，提前告知生態系統。 |
| 二進位檔 | 為匯總服務版本發布更完整的二進位檔組合。 | 我們正在審查這項要求，歡迎您提供其他意見回饋。 |
| API 使用量 | 根據《協調者服務條款》與協調人員分享資料。 | 我們希望藉此說明這個問題，並歡迎其他意見回饋。 |
私密匯總 API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 偵錯 | 啟用其他選項 B 測試期間的偵錯選項。 | 如這個 GitHub 問題所述，我們決定讓模式 B 支援偵錯模式。自 1 月 31 日起，在 M121 Beta 版中，系統將針對 50% 模式 B 流量調整這項資格條件。我們會先另行通知，再適應穩定版。 |
限制惡意追蹤
使用者代理程式縮減/使用者代理程式用戶端提示
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| ChromeOS | 支援使用者代理程式用戶端提示，以使用 Chrome 作業系統的靈活功能。 | 因此我們已按這裡回覆這項要求。 |
IP Protection (原稱 Gnatcatcher)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 濫用行為 | Google 則可以透過 IP 保護查看使用者的瀏覽資料。 | IP 防護會透過兩個 Proxy 傳輸流量，其中一個由 Google 運作，並由另一家公司營運。確保 Google 無法查看瀏覽資料。Chrome 和 Proxy 之間的所有流量都會經過加密，因此 Google Proxy 不會知道目前瀏覽的網站為何。此外，系統也會使用盲驗證權杖，盡量避免在 Proxy 存取使用者 ID。所有 Google Proxy 都能查看，特定 IP 中的未知用戶端正在使用 Proxy 系統。無法提供造訪過的網站或已載入廣告的相關資訊。 |
| 支援無頭模式 | 如何管理使用外掛程式和無頭模式的機器人？ | 減少濫用 IP 保護功能是團隊的首要之務。我們已仔細考量這些情況 (還有許多其他可能的威脅)，也正在設法降低濫用或詐欺行為成功的可能性。雖然我們目前無法提供更多詳細資料，但預計不久後就會提供這些資訊，並期望繼續參與討論。 |
| 現有的 Proxy | IP 保護功能如何與 Chrome 現有的 Proxy 設定搭配運作？ | 系統會繼續支援現有的 Proxy 設定。使用者可以像之前一樣自行設定自訂 Proxy。 |
| 檢舉濫用情形 | Google 如何處理濫用情形檢舉？ | 我們近期將提供更多詳細資訊，但也計劃推出讓機構和使用者分享檢舉內容和濫用行為證據的機制。 |
| 法規 | IP 保護如何遵循當地法律和法規？ | Google 致力於遵守當地法律和法規，因此可能不允許規避這類國家/地區層級封鎖的規定。本功能並非用於規避手段。 |
| 限制功能 | IP 保護是否會阻止我們的網路回應？ | 我們致力於在根據 IP 位址防止使用者在網路上遭到追蹤，同時在維持伺服器正常運作的情況下盡可能取得平衡，包括使用 IP 位址進行反濫用措施。雖然我們目前無法提供更多詳細資料，但預計不久後就會提供這些資訊，並期望繼續參與討論。 |
| 時間表 | 如果要在 2024 年底前強制執行這項措施，就幾乎不可能做好萬全準備。 | Chrome 最初會先針對特定地區推出「IP 保護」做為使用者選用設定，我們瞭解這會對部分公司依賴 IP 位址的方式造成重大改變，並希望能隨著大環境不斷調整，盡可能降低服務中斷的情況。最遲於 2025 年起，IP 保護功能就會改為預設模式。 |
| API 使用量 | 使用者第一次開啟 Chrome 時，可以選擇是否要切換 IP 保護功能？ | 我們計劃讓使用者自行選擇是否使用 IP Protection。向使用者展示這個選項的機制目前仍在開發階段， |
| API 使用量 | 系統會記錄多少資料，以及該資料會保留多久？ | 我們日後會分享更多詳細資訊，但是我們計劃只記錄最少的資料。 |
| 負面意見 | 使用者可以視需要使用 VPN。不需要 PS API。 | IP 保護的目標在於防止 IP 位址用於跨網站追蹤，這不是 VPN 服務。 |
| API 安全性 | 如何禁止第一方透過標頭參數存取 IP 位址和轉送資訊？ | 根據我們的觀察，我們一開始會把重點放在第三方，因為第三方影響力最大。我們會持續監控整個生態系統，判斷是否必須改良做法，以避免大規模的規避手段。 |
| API 使用量 | 如瞭解 API 用量正確，則必須進行確認。 | IP Protection 會使用清單式方法來辨識哪些第三方流量通過 Proxy。如果來源在清單中，但在第一方情境下存取，系統就不會透過這項服務進行 Proxy 處理這些連線。 舉例來說，如果分析公司在網域清單中，而使用者直接前往該網站，該網站仍可觀察使用者的 IP 位址，而非透過 Proxy 執行的 IP 位址。不過，如果清單中的網域是在第三方環境中提出網路要求，系統就會對連線進行 Proxy 處理，而且網站也不會顯示使用者的原始 IP 位址。 我們的終極目標是防止使用者跨網站追蹤網路使用者。我們正在瞭解細節，確認日後會著重於哪些第三方網域。 |
| VPN | 擔心 Google 的提案可能會對其他 VPN 供應商帶來負面影響。 | IP 保護的目標在於防止 IP 位址用於跨網站追蹤，這不是 VPN 服務。 |
| 時間表 | 什麼是「IP 保護」時間表？ | 系統一開始會選用 IP 保護功能。這有助於確保使用者能掌控隱私權決策，並能監控少量行為。IP 保護功能將分階段推出，最快在 2025 年內就會轉換至預設設定。與所有隱私權提案一樣，我們希望確保在學習過程中從中學習，也瞭解評估時應考量各區域性因素。我們目前採用以清單為準的做法，只有第三方平台上的網域會受到影響。我們深知這些提案可能會基於正當用途造成意外中斷，因此只會關注被視為追蹤使用者的指令碼和網域。 |
| 限制功能 | 無法再在 WHOIS 中查詢使用者的 IP 位址。 | 我們的立場是，IP 位址是一個穩定的 ID，其使用行為可能會對使用者造成隱私權影響，包括使用與 ASN 這類關聯的中繼資料。透過 IP 保護，我們希望在隱私權和提供實用的網路使用者體驗之間找到適當的平衡，例如透過我們的 IP 地理位置技術。如果這份中繼資料不足以滿足您的用途，我們很樂意與您進一步討論。 |
| HTTP 參照網址 | 系統會保留原本的 HTTP 參照網址嗎？ | 目前沒有計劃在 IP 保護過程中修改參照網址標頭，詳情請參閱這裡的說明。 |
| 開放原始碼 | IP 保護來源程式碼是否為開放原始碼？ | 這裡使用的軟體大多屬於 Chromium 和 Envoy Proxy 專案的開放原始碼，但部分元件是封閉原始碼，詳情請參閱這篇文章。 |
跳轉追蹤因應措施
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 刪除儲存空間 | 跳轉追蹤因應措施 (BTM) 會刪除共用儲存空間和歸因報表儲存空間嗎？ | 我們不打算讓 BTM 刪除 Privacy Sandbox API 儲存空間 (ARA、PA API、Shared Storage、私人匯總、Topics)。BTM 只能刪除在第三方環境中存取時，會有隱私風險的儲存類型。我們正在修正錯誤， |
| API 使用量 | BTM 會啟用哪個 Chrome 版本？10 秒後重新導向/跳出追蹤是否會算是 BTM 的跳出追蹤？ | 在 M116 期間，針對已封鎖 3PC 的 100% 使用者推出 BTM。目前，系統不會將 10 秒後的重新導向視為跳出。 |
| 登入用途 | 自動同步處理/維護多個網域的登入狀態，而不會因追蹤類似行為而受到損害？ | 歡迎前往這裡討論這項要求，也歡迎生態系統提供其他意見回饋。 |
| 使用者歷程 | 目前 BTM 可帶來複雜的使用者歷程。 | 我們正在討論此問題，並對此提供意見。 |
| Storage Access API | Chromium 的 BTM 將做出 Storage Access API (SAA) 3PC 補助。 | 我們在 2023 年與 TPAC 生態系統參與者討論了這項問題，歡迎按這裡提供更多意見回饋。 |
| 對廣告報表的影響 | 跳轉追蹤因應措施可能會導致生態系統中的小型公司仰賴 ARA 等其他 Privacy Sandbox API 執行廣告用途。 | 跳轉追蹤因應措施旨在防止規避 3PCD。ARA 是 3PCD 開發計畫後推出的眾多替代成效評估解決方案之一，但全公司不必採用。 |
隱私預算
本季沒有任何意見回饋。
強化跨網站隱私權界線
相關網站集 (舊稱第一方集合)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| (另於前季度回報) 相關網站集 (RWS) 網域限制 |
要求增加相關網域數量。 | 目前我們不會提高數字上限。這項限制是基於使用者隱私權考量、W3C 生態系統相關人員的意見回饋，以及其他瀏覽器中類似導入方式的考量而設。詳情請參閱我們的網誌文章 (1、 2)。 建議您檢查需要跨網站 Cookie 存取權超出數量限制的用途。若用途為識別身分、經驗證的嵌入和廣告用途，不妨參考我們的指南。 |
| Cookie 存取範圍 | 請留意，RWS 中的所有網域都會授予讀取和寫入所有網域所有 Cookie 的權限。 | 成為 RWS 會員不會讓各個成員能夠存取彼此的 Cookie。相反地，這麼做會讓成員在嵌入其他相同 RWS 網站時存取自己的 Cookie (在 Storage Access API 叫用後)。 |
| (另於前季度回報) RWS + CHIPS 整合 |
要求整合 RWS 與 CHIPS 以支援 A/B 測試等用途 | 我們會持續針對這項功能徵求用途和要求，請按 這裡。目前，我們會針對這項功能的需求，衡量跨瀏覽器互通性的相關風險。 |
| API 使用量 | 如果使用者從本機的 Chrome 設定中手動移除網站，會發生什麼情況？ | 我們目前無法讓使用者從群組中手動刪除網站。使用者只要在新的追蹤保護設定面板上使用「封鎖第三方 Cookie」或「封鎖所有第三方 Cookie」下方的切換鈕，即可選擇關閉「相關網站」功能。 |
| 跨網域通訊 | RWS 是否允許跨網域通訊？ | 我們目前正在進行來源試用，希望透過 Storage Access API 擴大對某些類型的未分區儲存空間 (包括 localStorage 和 Broadcast Channel) 的存取權，藉此啟用這項通訊。這項功能適用於所有支援的 Storage Access API 設定，包括相同的 RWS，以及 非 RWS 網站。詳情請參閱這篇 網誌文章。 |
| requestStorageAccessFor | 可以透過 document.requestStorageAccessFor(origin) 傳回承諾，進而解析來源的跨網站 Cookie 嗎？ | 不可能。叫用是在頂層來源 (與傳入引數的來源不同) 時發生，因此會違反相同來源政策。 |
Fenced Frame API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| (另於前幾季記錄) 原生廣告 |
原生廣告的 Fenced Frame 支援。 | 我們先前宣布一些 Privacy Sandbox 技術，日後會需要才能進一步強化隱私保護措施。以 Protected Audience 為例，在 2026 年以前，我們將需要使用 Fenced Frames 來顯示廣告，並停用事件層級報表。我們對這些未來發展的規定提供了「更早的日期」，讓業界清楚瞭解 API 的預期發展。多出時間讓我們能繼續與業界合作，針對更多關鍵用途設計和實作支援服務。舉例來說，我們會在 2026 年及之後更新 Fenced Frames，以便繼續透過 Protected Audience API 支援影片和原生廣告。根據我們的承諾，我們會諮詢 CMA，針對這類異動提出諮詢。在實施這些異動之前，我們會持續諮詢生態系統的意見回饋。 |
| 各平台的尺寸差異 | 回報 Fenced Frame 中顯示的內容大小在電腦和智慧型手機上有所不同。 | 我們正在調查這個問題，如有任何意見，歡迎按這裡。 |
| 顯示 adComponent | 提供如何在 Fenced Frame 中算繪 adComponents 的程式碼範例？ | 我們會提供說明文件，說明如何使用 Fenced Frame 中的 navigator.adAuctionComponents(numComponents) 顯示由多個部分組成的廣告。 |
| 改善 API | 為 FencedFrames 提供更多信號 (例如改善品牌安全)。 | 我們歡迎您對這項提案提出意見，也歡迎您前往這裡提供更多意見回饋。 |
共用儲存空間 API
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 反濫用 / 反詐欺使用案例 | 使用「共用儲存空間」進行詐欺或異常偵測的可能性。 | 我們已在這裡討論可能的可能原因，也歡迎你提供其他意見回饋。 |
| 展示頻率上限 | 在 PPA API 以外，提供跨網站展示頻率上限的方法。 | 我們很高興各位表示，在 PPA API 以外，跨網站展示頻率上限是非常實用的用途。Privacy Sandbox 目前仍著重於現有的 3PCD API 組合。不過，我們也歡迎生態系統對於這個使用案例分享其他意見回饋，詳情請參閱這裡。 |
方塊
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 彈出式視窗/重新導向 | CHIP 如何支援與彈出式視窗和重新導向相關的內嵌驗證用途？ | 我們最近曾分享一些指南，說明如何確認 3PC 逐步停用對登入工作流程的影響，歡迎按這裡提供更多意見回饋。 |
| 分區限制 | 將每個網站各分區的整體數量限制減少至 1 KiB。 | 我們正在考慮這項要求，如有任何意見，歡迎按這裡。我們會持續推出 3PCD 技術，且開發人員採用 CHIP 技術，並提供意見回饋，我們會持續監控相關意見回饋。 |
| Cookie 遷移 | 建議將網頁應用程式遷移以發出 Cookie 做為分區，該程序不會破壞進行中的 Cookie/工作階段？ | 我們在 這裡的回應中提出了遷移方案建議，但開發人員可以規劃出更適合其設定的 替代解決方案。 |
| API 使用量 | 使用者未選擇採用廣告隱私權 API 設定時，對分區儲存空間的存取權是否已停用？ | 即便使用者未選擇採用廣告隱私權 API 設定，分區儲存空間和分區 Cookie (CHIP) 仍會啟用；這是因為使用者無法啟用任何跨網站資訊移轉功能。一般原則上，跨網站移轉資訊將受到限制、檢查或由使用者選擇接受等限制，但目前不適用於 CHIPS。 |
| API 使用量 | 為何最終會封鎖未分區 Cookie，而不是只「無聲」分割 Cookie？ | 正如這裡所述，短期和中期並不可行。 |
FedCM
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| API 使用量 | 無法在開發環境中的 eTLD+1 提供「well-known file」。 | 我們更新了 Chrome Canary，現在不需要擷取這篇文章所述的已知內容。 |
| API 使用量 | 要求第三方登入權限或使用 FedCM 時，是否有任何特定的使用者互動規定？ | 沒有任何特定的使用者互動要求 (詳情請參閱這裡的說明)。 |
| API 安全性 | 是否有任何計畫能讓用戶端啟動 FedCM，但基本上會將權杖從 IdP 轉移至 RP 的後端系統？ | 如有任何有助於討論的事宜，歡迎按這裡查看。 |
| 選擇加入 | 允許 IDP 選擇接收 RP 的用戶端 ID，以便使用者決定是否要信任 IDP。 | 我們正在討論這項要求，也歡迎按這裡提供更多意見回饋。 |
| API 使用量 | 要求取得更多 FedCM 的說明文件。 | 我們瞭解此意見，並會持續改善說明文件，持續開發這個 API。 |
打擊垃圾內容和詐欺
Private State Token API (和其他 API)
| 意見回饋主題 | 摘要 | Chrome 回應 |
|---|---|---|
| 說明文件 | 索取詳盡的開發人員指南，以協助測試。 | 我們已在 2023 年第 4 季針對 Private State Tokens 發布開發人員指南。 |
| 年齡/性別驗證 | 在 3PCD 計畫發布後難以對目標對象進行「年齡和性別」驗證。 | Private State Token 目前不適用於年齡和性別驗證。我們希望能更加瞭解這個使用案例，以及今天的實現方式，歡迎提出其他意見回饋。 |