Web 隱私沙箱：不斷變化的隱私格局及其對您網站的影響

Chrome 將在整個 2023 年通過隱私沙盒計劃對隱私進行更改，同時構建新技術來保護用戶信息的私密性。 同時，網絡出版商和品牌正在改變他們的數字戰略，以幫助保持依賴第三方 cookie 的廣告收入和有價值的營銷分析。

這種對擴展瀏覽器隱私的推動推動了對網站個性化的更多需求。

在本次會議中，Google 開發者倡導者 Sam Dutton 介紹了即將發生的變化，分享了隱私沙盒計劃的目標，並幫助您更好地了解如何進行調整以確保您擁有所需的數據來幫助您的業務和網站保持穩定向前進。

會議幻燈片：

成績單：

山姆·達頓：大家好，我是山姆·達頓。 我是倫敦 Chrome 團隊的一名開發者倡導者。 非常感謝你今天加入我。 在接下來的 25 分鐘內我會做三件事。 我將為您概述隱私沙盒 API。 我將解釋您現在需要做什麼，並向您展示如何成為一名測試人員並加入 API 的討論並提供反饋。

因此，讓我首先解釋為什麼我們需要隱私沙盒。 你們中的許多人都非常了解背後的故事，但值得快速重申一下我們為什麼需要這個以及我們是如何走到今天這一步的。 因此，Privacy Sandbox 是一項旨在幫助構建一組隱私保護 API 的計劃，以支持為未來的開放網絡提供資金的商業模式，而無需第三方 cookie 等跟踪機制。

現在您可能已經在 Google I/O 上看到了這個示例。 這是一個典型的站點，包含來自不同來源的組件。 當然，可組合性是網絡的超能力之一。 你有一張來自一個來源的地圖，一些來自另一個來源的腳本，等等，當然還有廣告，不管我們喜歡與否，無論未來如何，廣告已經成為收入的重要來源和商業的驅動力網。

現在在歷史的這一點上，我認為瀏覽器和 CMS 需要支持廣告用例。 所以有什麼問題？ 好吧，廣告選擇、轉化測量、欺詐檢測、設備定制以及許多其他用例都依賴於跨站點身份，使用的機制在構建時並未考慮隱私。

現在，不僅是第三方 cookie，指紋識別也用於跨站點跟踪用戶行為，或者站點請求個人信息，例如電子郵件地址，此外，第三方生態系統非常複雜，尤其是對於廣告。 甚至開發商、廣告商或出版商也不了解第三方服務的供應鏈。

所以當然，當我訪問一個網站時，我並不知道所有相關的第三方以及他們對我的數據做了什麼，而不僅僅是我，研究表明人們真的很關心控制他們的數據。 隱私問題越來越多地推動人們選擇在線做什麼，世界各地的監管機構都在加強隱私要求，而且這種情況發生得非常快。

因此，考慮到有多少企業依賴有效的在線廣告，有多少出版商依賴廣告來通過他們的網站獲利，以及一大堆其他用例，這對整個網絡生態系統來說都是一個問題，而不僅僅是科技公司和廣告平台。 但當然，因為網絡是一個開放平台，所以改變建議需要接受和反饋，Chrome 等瀏覽器不能也不想單方面行動。

瀏覽器不是瀏覽器供應商可以孤立地做出決定的產品，現實情況是，網絡並不是為當今平台的許多核心要求而設計的，這些要求包括廣告欺詐檢測、身份管理和所有這些其他要求用例和很快。 因此，我們需要的是為這個以隱私為中心的網絡專門構建的技術，這就是隱私沙盒的用武之地。

因此，Chrome 一直與網絡社區以及行業利益相關者和監管機構合作，開發新的隱私保護技術，以支持健康、可持續的生態系統。 現在，一旦這些新的專用 API 可用，我們需要確保公司有時間採用它們，以便我們可以安全地逐步停止 Chrome 中對第三方 cookie 的支持，並繼續我們的工作以減輕其他類型的跟踪。

現在，該計劃的核心原則集是網絡的潛在隱私模型，由 Google 的隱私專家和計算機科學家開發。 這種隱私模型為設計技術制定了一套基本規則，這些技術可以滿足我談到的網絡平台用例，同時也遵守我們不斷變化的隱私需求。

特別是，該提案涵蓋瞭如何在不損害隱私的情況下啟用跨站點連接的難題。 現在，Privacy Sandbox API 的主要創新之一是使瀏覽器能夠代表用戶行事，從某種意義上說，回到瀏覽器的核心角色，即我們所說的用戶代理。

使用當前技術，數據由第三方收集、匯總和共享，以跟踪用戶跨站點瀏覽。 隱私沙盒 API 可以允許廣告拍賣轉換測量和這些其他任務由用戶設備上的用戶瀏覽器完成。

因此，我們需要通過跨瀏覽器供應商、平台、廣告商、出版商廣告技術、用戶、監管機構和隱私社區的協作來重建廣告平台和網絡，尤其是像您這樣使用 CMS 平台的開發人員。

因此，考慮到所有這些，我只想讓您快速瀏覽一下 Privacy Sandbox API 本身。 所以在谷歌，這是一個跨網絡和 Android 的共享計劃。 Android 上的隱私沙盒專注於引入新的更私密的廣告解決方案，無需跨應用標識符。

當然，Web 和 Android 共享相同的原則，並且正在為 Android 開發一些 Web 提案。 然而，Web 和 Android 移動平台當然依賴於根本不同的技術。

所以這是在 Android 上的一項獨特舉措，但對於那些構建 Android 應用程序以及在 Web 上工作的人來說，這是一個需要密切關注的舉措。 因此，谷歌一直在與全球範圍內的合作夥伴合作測試新的 API。

數百家公司參與公共論壇，無論是 W3C，還是在 GitHub 等上解釋問題，發表觀點和分析，加入行業圓桌會議，與 Chrome 和 Android 分享反饋，當然，還參與測試。

別搞錯了，Privacy Sandbox 有很多要求要滿足，而且一路走來會很艱難。 我的意思是，我認為好消息是，所有這一切的結束將擁有對用戶來說更安全、更私密的平台，對廣告商、出版商、開發商，當然還有像 WordPress 這樣的平台來說更好。

所以我不打算描述所有的隱私沙盒 API。 相反，我想專注於隱私沙盒中的三個主要廣告 API。 這就是主題、FLEDGE 和歸因報告。 我們的主題和 FLEDGE 被稱為相關 API。

Now Topics 根據用戶最近的瀏覽歷史記錄提供用戶興趣的高級信號。 主題可以結合上下文信號和第一方數據來選擇相關廣告。

FLEDGE 支持更精細的再營銷和自定義受眾用例，在這些用例中，營銷人員希望接觸到對特定網站或產品表現出興趣的受眾，但當然，要以保護隱私的方式實現這一點。

最後，歸因報告是 Chrome 為保護隱私的活動衡量提出的建議，提供匿名的性能報告以及人們何時查看或點擊廣告，然後繼續完成購買或其他類型的轉化。

因此，這些 API 已經在 Android 和桌面和移動設備上的 Chrome 中進行了一段時間的測試。 如果您正在使用廣告技術平台，則需要確保您了解這些平台解決這些用例的計劃，以及這些 API 在未來沒有第三方 cookie 或其他跟踪機制的情況下滿足的用例。

因此，現在我們已經對使用 Chrome 標誌激活的 API 進行了一段時間的技術測試，現在最初只為一小部分 Chrome 用戶激活了原始試用版。 所以現在我們處於實用程序測試階段，50% 的 Chrome Canary 開發和測試版用戶在提供有效令牌的頁面上激活了廣告來源試用 API，5% 的穩定用戶。

現在，這當然只佔 Chrome 總流量的一小部分，但足以讓真實用戶對 API 進行有限測試。 我們現在正朝著在 Chrome 穩定版中發布的方向邁進，默認情況下所有用戶都可以使用 API，稍後我會回到時間表。

因此，重申一下，對於單個用戶，您可以使用 Chrome 標誌激活 API，但要進行大規模測試，您需要參加 Privacy Sandbox 原始試用，稍後我將分享鏈接以獲取有關如何完成所有操作的指導.

因此，順便說一下，Chrome 也在更新用戶隱私控件，例如 UI 並且隱私沙盒控件實際上作為廣告 API 原始試用版的一部分提供。 人們將能夠查看和管理與其瀏覽相關的興趣或完全關閉 API。

所以實際上還有其他三種隱私沙盒技術，我認為您可能還想測試或肯定要標記給您的任何第三方提供商。 首先，籌碼。 這就是具有獨立分區狀態的 Cookie 允許開發人員選擇一個 cookie 來分區存儲，每個頂級站點都有一個單獨的 cookie jar。

第一方集允許由同一實體擁有和運營的相關域名聲明自己屬於同一第一方和私有狀態令牌。 您可能聽說過這個初始名稱，即 Trust Tokens。 這是一個 API，用於將有限數量的信息從一個瀏覽上下文傳遞到另一個瀏覽上下文，例如，跨站點幫助打擊欺詐，但不使用被動跟踪技術。

所以首先，讓我們更深入地了解主題 API。 主題 API 提供了一種機制來啟用基於興趣的廣告，但不允許第三方跟踪用戶瀏覽活動。 因此，從某種意義上說，API 具有三個主要組成部分，首先，基於興趣的廣告需要對感興趣的主題進行分類。

Topics API 分類法如下所示。 這是一個公開維護的人類可讀主題列表，避免了敏感主題。 現在，隨著與網絡生態系統的協商，這可能會隨著時間的推移而改變和發展，這意味著像您這樣的人，我們需要您對此以及其他一切的反饋。

因此，Topics API 需要根據用戶的瀏覽活動來推斷他們的興趣，但正如我所說，這樣做是為了保護他們的隱私。 因此，用戶設備上的瀏覽器再次根據他們最近的瀏覽活動，為用戶在他們設備上的瀏覽器中記錄最感興趣的主題。

目前，主題通過使用機器學習將用戶訪問的頁面主機名映射到分類法中的主題來實現這一點。 現在與主題分類法本身一樣，該方法將隨著時間的推移而發展。 但是從瀏覽活動中推斷興趣需要取得正確的平衡。

如果您有太多關於用戶瀏覽情況的詳細信息，這對隱私不利，但粒度太少意味著 API 沒有用。 我認為從某種意義上說，這裡要理解的主要事情是感興趣的主題只是找到與用戶相關的內容的一個信號。

因此，一旦瀏覽器為用戶推斷出感興趣的主題，主題就需要為 API 調用者提供訪問他們為用戶觀察到的感興趣主題的權限。

因此，當用戶瀏覽網頁時，API 有兩個階段。 API 調用者（例如，可能是廣告技術平台）調用頁面上的 API 以表示他們想要觀察當前頁面和當前用戶的主題。

現在，API 調用者可以訪問他們為用戶觀察到的主題。 現在，所有這一切都必須在不透露更多關於用戶瀏覽活動的信息的情況下完成，除了所觀察到的感興趣的主題之外。

因此，主題 API 提供了兩種方法來觀察用戶感興趣的主題，然後訪問觀察到的那些主題，首先是使用 JavaScript API 或使用獲取請求中的請求和響應標頭。

Topics API 調用者可以向瀏覽器發出它已觀察到用戶主題的信號的第一種方法是從嵌入在用戶訪問的站點上的 iframe 調用 document.browsingTopics。

現在，稍後 API 調用者可以調用相同的 document.browsingTopics 方法來訪問它為當前用戶觀察到的主題。 順便說一下，此方法需要 iframe 的原因是觀察主題的上下文必須與訪問主題的上下文相同。

另一種觀察和訪問主題的方法是使用獲取、請求和響應標頭。 首先，API 調用者需要向其來源的 URL 發出獲取請求，包括選項參數中的瀏覽主題 true 對象。

如果對獲取請求的響應包含一個 Observe-Browsing-Topics ?1 標頭，那麼，這會向瀏覽器發出信號，表明調用者希望瀏覽器記錄調用者已經為當前用戶觀察了當前用戶感興趣的主題頁。 我希望這是有道理的。

現在，可以通過訪問 sec-browsing-topics 請求標頭從調用者的提取請求中檢索用戶觀察到的主題。 所以這是從開始到結束的整個過程。 我知道時間問題，所以我現在不會詳細介紹，但我們稍後會分享它，這樣您就可以看到它是如何工作的，整個過程，我們將為每個 API 提供它。

您可以試用使用 JavaScript iframe 方法觀察和訪問主題的主題演示，或者您可以試用我們使用獲取請求標頭方法的演示。 chrome://topics-internals 顯示當前用戶的主題、為主機名授予的主題和有關 API 實現的技術信息。

您還可以運行主題合作實驗室，以使用主題分類器模型測試主題推理。 在我離開主題之前，現在有三個主要的未解決問題，我們如何才能根據用戶的瀏覽活動更好地推斷他們感興趣的主題？ 我們如何改進分類法的內容和結構，使其在保護用戶隱私的同時更有用？ 我們如何改進 API 的整體架構？

我認為這裡要記住的一件事是我們是否有主題或不同的東西，我們仍然需要滿足它的用例。 接下來，FLEDGE。 因此，這是一個用於設備廣告選項的 API，無需跨站點第三方跟踪即可服務於再營銷和自定義受眾用例。

我認為 FLEDGE 的代碼細節稍微多一點，因為它比主題更複雜。 因此，FLEDGE 過程分為三個部分。 首先，廣告購買者將用戶或個人瀏覽器真正添加到所謂的興趣組中。 這些類似於自定義受眾，但興趣組成員身份存儲在用戶設備的瀏覽器中。

現在，當用戶訪問顯示廣告的網站（例如發布商網站）時，廣告銷售商可以發起廣告拍賣來為他們選擇廣告，而藉助 FLEDGE，該拍賣可以在用戶的設備上運行。

為了選擇廣告，拍賣代碼運行來自買家的出價邏輯和來自賣家的拍賣邏輯。 最後，瀏覽器會向買賣雙方提供的端點發布拍賣報告。

所以我只是非常簡要地逐步介紹 FLEDGE。 首先想像一個用戶訪問在線鞋店，進行一些瀏覽。 廣告技術平台或廣告商自己進行 JavaScript 調用以告知瀏覽器加入興趣小組。 這個組的名稱可能類似於 Trail Running Shoes。

興趣小組的配置對象可能如下所示。 在此示例中，鞋店的廣告技術人員可能有一個興趣小組用於再營銷，他們希望將用戶添加到該小組，並且他們將這個小組很好地稱為 Trail Running Shoes。 鞋店的廣告技術平台調用加入廣告興趣組，要求用戶的瀏覽器使用我剛剛向您展示的配置加入他們的 Trail Running Shoes 興趣組。

第二個參數指定興趣組的持續時間，上限為 30 天。 現在用戶訪問了一個發布廣告的網站。 在這個例子中，一個新聞網站。 選擇要向用戶顯示的廣告的拍賣由賣家使用運行廣告拍賣在用戶設備上以 JavaScript 運行，賣家可能是廣告技術平台，但也可能是發布商本身，在本例中是新聞網站。

現在，此拍賣為用戶瀏覽器所屬的每個興趣組以及來自賣家和瀏覽器本身的其他因素選擇最合適的廣告給定出價。

現在查看代碼，發布商或在發布商網站上銷售廣告空間的平台為廣告拍賣創建配置數據。 然後賣家要求瀏覽器運行廣告拍賣以在瀏覽器中選擇一個廣告，運行廣告拍賣返回的值被傳遞到一個稱為圍欄的元素，這樣網站就可以展示獲勝的廣告。

現在，圍欄框架可用於顯示廣告，但無法與其周圍的頁面進行交互。 然後賣家和獲勝的買家每個人都有機會執行日誌記錄和報告，這是通過調用 navigator.reportresult 完成的。

最後，如果一切順利，用戶點擊或點擊廣告，現在歸因報告 API 將接管。 同樣，我們有一張圖表顯示了從開始到結束的整個過程，我們將在主題演講後與您分享。

現在，最後我想向您介紹一下用於廣告衡量的 Privacy Sandbox API，即歸因報告。 歸因報告用於衡量廣告點擊或廣告展示何時帶來了轉化。 例如，當瀏覽新聞網站上的廣告導致在在線鞋店購買商品時。

現在與主題和 FLEDGE 一樣，此 API 旨在避免跨站點跟踪。 因此 API 允許兩種類型的測量結果，事件級別報告和摘要報告。 那麼讓我簡要描述一下它是如何工作的。

首先讓我們看一下事件級別的報告。 因此，可以使用特定於歸因報告 API 的屬性來配置廣告鏈接，這樣就可以在轉換端通過請求來統計觀看次數和點擊次數。

現在，當用戶點擊廣告或看到廣告然後進行轉換時，瀏覽器會生成一份報告，廣告公司或廣告技術人員在該報告中包含兩條數據。 第一，他們想要的有關廣告點擊或展示的任何數據，這些數據可以非常詳細，例如創意 ID、有關發布者的信息、時間戳等。 其次，關於廣告轉化的一小部分數據。

現在，為了保護用戶隱私，這個不能太詳細。 稍後瀏覽器會發送關於——好吧，該報告包含我剛剛向廣告技術人員或廣告商解釋的數據，其中包括延遲以幫助避免用戶跟踪。

該報告包含兩部分數據，有關廣告點擊或展示的詳細數據、事件和有關轉化的高級數據。 所以這是一個事件級別的報告。 現在讓我們看一下摘要報告。

現在生成摘要報告的瀏覽器 API 類似，但結果和機制略有不同。 同樣，當用戶點擊廣告或看到廣告然後進行轉換時，瀏覽器會生成報告，廣告公司或廣告技術人員可以在該報告中包含他們想要的有關廣告點擊或展示的任何數據以及他們想要的任何數據想要了解廣告轉換，但此報告已加密。

這是一種隱私保護，因為此報告包含有關轉換和印象的詳細數據。 因此，如果報告未加密，則可用於跨站點跟踪。 稍後，瀏覽器將再次發送此加密報告，但會有一小段延遲。

通過這種方式，廣告技術平台將從許多用戶那裡收集許多報告，然後將所有報告發送到一個被調用的聚合服務，該服務將聚合所有這些報告，解密它們，添加一些噪音以保護用戶隱私，然後返回最終結果，最終結果稱為總結報告。 它包含許多用戶的測量數據。

這就是歸因測量。 我希望這是有道理的。 我將鏈​​接到更多資源，以幫助您更詳細地了解和測試 Privacy Sandbox API。 但我想提及的最後一件事是 Privacy Sandcastle。

這是一個結合了所有主要 Privacy Sandbox API 的演示。 它是由我們在東京的團隊建造的。 它仍然很新。 但您可以從 GitHub 獲取代碼並在本地運行它，它旨在幫助您了解所有這些 API 如何組合在一起。

在結束之前，我想回顧一下 Privacy Sandbox 的時間表。 如您所見，我們即將開始交付 API 的季度即將到來，這意味著它們將默認在 Chrome 穩定版中可用，並準備好在生產規模上進行測試。 現在這只是日曆上很短的時間，我可以看到自己。 我快到時間了。

所以我認為你現在需要做的一些事情。 首先，了解 Web 和 Android 的時間表。 確保您和您的第三方提供商已為即將發生的變化做好準備。 其次，審核您的網站以了解它們在哪裡依賴第三方 cookie 和其他已棄用的機制。 我們將在今天的活動結束後分享工具鏈接和操作說明。

接下來，詢問您的第三方提供商，例如廣告技術平台等，在沒有第三方 cookie 或其他跨站點跟踪機制的情況下，他們如何準備滿足其核心用例，最後，測試 Privacy Sandbox API 並提供反饋並要求您的第三方供應商也這樣做。

如果他們不舒服，請問他們為什麼不好，然後讓我們知道該問題的答案是什麼。 因此 privacysandbox.com 提供時間表、常見問題解答以及有關跨平台工作的更多信息。 我將在此次活動後分享 URL，但您可以從 developer.chrome.com 的隱私沙盒部分找到我在這裡提到的很多內容。

特別是，這裡有解釋如何為我們提問和提供反饋的資源，您可以在 developer.chrome.com 上找到有關原始試用的更多信息。 我們還創建了一系列短視頻和文章來幫助解釋 Chrome 概念，例如原始試用、Chrome 標誌、閃爍內容等。

所以謝謝你的聆聽。 我就是這樣。 就像我說的，如果您確實需要支持，請訪問這些資源，或者您可以在 Twitter 上直接給我 SW12 發消息。 非常感謝。