Privacy Sandbox 是一系列的提案，可以滿足第三方使用情境，不需要使用第三方 Cookie 或其他追蹤機制。
摘要
- 本文將概述 Privacy Sandbox 提案的 API 和概念。
- 提案作者正向社群徵求意見回饋，尤其是廣告空間成員 (發布商、廣告客戶和廣告技術公司) 的意見回饋，提供遺漏的應用實例，並說明如何支援業務用途。
- 您可以在下方連結的存放區中提問，針對提案加註。
- 本文結尾處會提供提案的詞彙解釋。
網路隱私權目前的現況
網站會使用其他公司提供的服務來提供數據分析、放送影片，以及執行許多其他實用功能。可組合性是網路的強大優勢之一。最值得注意的是，廣告會透過第三方 JavaScript 和 iframe 呈現在網頁中。廣告觀看、點擊和轉換是透過第三方 Cookie 和指令碼追蹤。
不過，當您造訪網站時，也許不知道第三方牽涉到第三方，他們會如何處理您的資料。即使是發布商和網頁程式開發人員，也可能不瞭解整個第三方供應鏈。
廣告選擇、轉換評估和其他用途目前必須建立穩定的跨網站使用者身分。過去，這種情況已使用第三方 Cookie 完成，但瀏覽器已開始限制這些 Cookie 的存取。此外，跨網站使用者追蹤的其他機制也越來越高，例如隱密瀏覽器儲存空間、裝置數位指紋採集，以及索取電子郵件地址等個人資訊的要求。
這對網路來說是一大挑戰。如何在不開放跨網站追蹤使用者的情況下，支援正當的第三方使用情境？
具體而言，如果讓第三方放送廣告及評估廣告成效，卻不允許個別使用者分析使用者的數據內容，那麼網站又該如何製作內容資金？如果不防範裝置數位指紋採集等黑暗模式，廣告客戶和網站擁有者該如何評估使用者的真實性？
當下的運作方式可能會對整個網路生態系統造成問題，而不只是使用者而已。對於發布商和廣告客戶來說，追蹤身分識別及使用各種非標準第三方解決方案可能會導致技術債、程式碼複雜性和資料風險增加。使用者、開發人員、發布商和廣告客戶應有責任保護使用者的隱私權選擇。
廣告是網際網路的核心業務模式，但廣告必須力求適合所有人使用。因此，我們得到 Privacy Sandbox 的使命：打造蓬勃發展的網路生態系統，讓使用者尊重個人和隱私權，
Privacy Sandbox 簡介
Privacy Sandbox 推出一組隱私權保護 API，支援使用第三方 Cookie 等追蹤機制，為開放網路提供資金的商業模式。
Privacy Sandbox API 需要網路瀏覽器採用新角色。相較於有限的工具和防護機制，API 讓使用者的瀏覽器可以代表使用者在本機 (在本機上) 執行動作，保護使用者在瀏覽網路時的身分資訊。這些 API 可在不揭露個人隱私和個人資訊的情況下，提供廣告選擇和轉換評估等用途。在工程條款中，sandbox是受保護的環境；Privacy Sandbox 的關鍵原則在於，不應以保護使用者個人資訊的方式，跨網站識別使用者。
這成了瀏覽器方向的轉變。Privacy Sandbox 的未來願景，就是提供能滿足特定用途的特定工具瀏覽器，同時維護使用者隱私。A Potential Privacy Model for the Web 擬定了 API 背後的核心原則：
- 建立網路活動範圍，讓使用者的瀏覽器允許網站將個人視為單一身分。
- 設法找出資訊在身分界線間移動的方式，同時兼顧兩者。
Privacy Sandbox 提案
為了順利淘汰第三方 Cookie，Privacy Sandbox 計畫需要您的支援。這份提案說明需要開發人員與發布商、廣告客戶和廣告技術公司的意見回饋，以提供缺少的應用實例，並說明如何以保護隱私權的方式達成目標。
您可以對每個存放區回報問題，藉此對提案說明內容加註：
- 網路隱私模型
建立網路活動範圍，供使用者在瀏覽器中將個人身分視為單一身分。瞭解資訊在身分界線間移動的方式，且不會破壞區隔。 - 隱私預算
限制網站可存取的潛在識別資料總量。更新 API，減少潛在可識別資料外洩的數量。運用潛在的可識別資料評估成效。 - Gnatcatcher
藉由存取 IP 位址，限制識別個別使用者的能力。 - Trust Token API
啟用可信任使用者以核發使用者瀏覽器加密編譯權杖的來源，以便於其他情境中使用這類權杖來評估使用者的真實性。 - 第一方集合
允許相同實體擁有的相關網域名稱宣告自己屬於同一個第一方。 - 匯總報表
提供隱私權保護機制，以支援各種用途，例如瀏覽後轉換、品牌、升幅和觸及率評估。 - 歸因報表
透過事件層級和匯總報表，提供點擊和觀看次數的隱私保護評估服務。 - Topics API
啟用按照興趣顯示廣告的功能，不必追蹤使用者造訪網站。我們在設計這個 API 時，參考了先前 FLoC 試用期間提供的社群意見回饋，取代了 FLoC 提案。 - FLEDGE
提供再行銷用途的解決方案，讓第三方無法運用該解決方案追蹤使用者在各網站的瀏覽行為。
您可以立即深入瞭解 API 提案說明，在接下來的幾個月，我們將個別發布每個提案的貼文。
我們也將新增 5 分鐘影片的播放清單，以簡單說明每個 API。
用途和目標
評估轉換
目標：讓廣告客戶能評估廣告成效。
Attribution Reporting API 可用來評估兩個已連結的事件： 1. 發布商網站上的事件 (例如使用者觀看或點擊廣告)。 1. 廣告客戶網站上的後續轉換。
這個 API 支援點閱後和瀏覽後評估。
這個 API 中的其他功能包括跨裝置歸因報表和應用程式至網頁歸因報表。
API 也提供兩種歸因報表：
事件層級報表，將特定廣告點擊或瀏覽 (在廣告端) 與轉換端的資料建立關聯。為保護使用者隱私，避免跨網站彙整使用者身分，轉換資料會受到限制，而且資料會「隱藏」(也就是說，在少數情況下，系統會傳送隨機資料)。為加強隱私保護，系統不會立即傳送報表。
匯總報表不會連結至廣告端的特定事件。相較於事件層級報表，這類報表提供更豐富、更精確的轉換資料。我們結合密碼編譯、信任發布和差異化隱私等隱私權技術，可降低跨網站身分登錄的風險。
這兩種報表都能相輔相成。
「歸因報表簡介」一文進一步說明瞭這些功能的狀態，以及如何試用這個 API。
請選取廣告
目標：讓廣告客戶能顯示與使用者相關的廣告。
關聯性高的廣告不但更符合使用者的需求，也提高發布商獲利 (也就是放送含廣告網站的使用者)。第三方廣告選擇工具讓廣告客戶 (也就是在網站上購買廣告空間的使用者) 更有價值的廣告空間，進而增加含廣告網站的收益，並製作並發布內容。
您可以透過多種方式根據使用者的需求放送貼近需求的廣告，包括：
- 第一方資料：根據使用者在目前網站上看到感興趣的主題，或使用者先前在目前網站上看過的內容，顯示與主題相關的廣告。
- 內容比對：根據網站內容選擇廣告的顯示位置。例如：「將這則廣告放在編織相關文章旁邊」。
- 再行銷：鎖定曾經造訪您網站的使用者，無論他們不在您的網站內，您都可以向他們放送廣告。例如：「對逛過手工藝商品的訪客顯示折扣 羊毛 廣告，並在他們造訪手工藝網站時放送促銷商品。」
- 按照興趣顯示：根據使用者的瀏覽記錄來選取廣告。例如，「向瀏覽行為表明可能有興趣編織的使用者顯示這則廣告」。
如此一來，您不必瞭解使用者在網站上的活動，就能取得第一方資料和內容相關廣告。這些技術不需要跨網站追蹤。
再行銷方法通常是使用 Cookie 或其他方式來識別不同網站上的使用者，也就是將使用者加入名單，然後選取要顯示的特定廣告。
按照興趣顯示的廣告選擇功能目前會使用 Cookie 盡可能追蹤眾多網站的使用者行為。許多人都擔心廣告選擇程序對隱私權的影響。Privacy Sandbox 提議採用以下兩種替代選項，供再行銷和按照興趣顯示選項：
FLEDGE：適用於再行銷用途。
為了追蹤使用者的瀏覽行為，第三方無法使用這個 API 來追蹤使用者的瀏覽行為：使用者的瀏覽器 (而非廣告客戶或廣告技術平台) 會儲存與使用者瀏覽器相關聯的廣告客戶定義興趣群組。使用者瀏覽器會結合興趣群組資料與廣告買方/賣方資料和商業邏輯，在使用者裝置本機上進行「競價」選擇廣告，而不是與第三方分享資料。Topics API：適用於以興趣為依據的目標對象。
啟用按照興趣顯示廣告的功能，不必追蹤使用者造訪網站。這個 API 提議使用機器學習技術從主機名稱推測主題，而 JavaScript API 則會根據最近造訪過的網站主機名稱，傳回使用者目前可能感興趣的概略主題。
戰鬥數位指紋採集
目標：減少 API 揭露的可識別資料數量，讓使用者能控管可能識別資料且可評估的資料。
瀏覽器已著手淘汰第三方 Cookie，但為了辨識和追蹤個別使用者的行為 (也就是數位指紋採集) 持續不斷演進。數位指紋採集使用了使用者不知道且無法控制的機制。
隱私預算提案的用意是找出 JavaScript API 或其他「介面」(例如 HTTP 要求標頭) 公開的指紋資料數量，並設定這類資料的存取量上限，藉此限制數位指紋採集的潛力。
User-Agent 標頭等指紋途徑的涵蓋範圍將縮減，而且透過其他機制 (例如用戶端提示) 存取的資料會受到「隱私權預算」的限制。其他介面 (例如裝置螢幕方向和電池層級 API) 則會更新，盡可能減少資訊暴露的情況。
IP 位址安全性
目標：控管 IP 位址的存取權，藉此減少數位指紋採集，並允許網站選擇不查看 IP 位址，以免佔用隱私預算。
使用者的 IP 位址是電腦在網際網路上的公開「位址」，在多數情況下，這類位址是由網際網路連線的網路動態指派。不過，即使動態 IP 位址在短時間內可能仍保持穩定。令人驚訝的是，這表示 IP 位址是指紋資料的重要來源。
Gnatcatcher 提案旨在提供能避免消耗隱私預算的隱私保護方法，同時確保網站會基於正當目的 (例如防範濫用行為) 要求 IP 位址存取權，且須通過認證和稽核。
提案分為兩個部分： * 實用的 IP 盲，可讓網站讓瀏覽器瞭解不會與使用者連接 IP 位址。* 近路徑 NAT 可讓一群使用者透過同一個合併伺服器傳送流量，有效隱藏網站主機中的 IP 位址。
打擊垃圾內容、詐欺和阻斷服務攻擊
目標：在不進行數位指紋採集的情況下驗證使用者的真實性。
反詐騙防護功能對於確保使用者安全，以及廣告客戶和網站擁有者取得準確的廣告成效評估結果至關重要。廣告客戶和網站擁有者必須能區分惡意漫遊器和真人使用者。如果廣告客戶無法準確判斷哪些廣告點擊來自真人，廣告費用就會降低，網站發布商的收益也會因此減少。許多第三方服務目前都會使用裝置數位指紋採集等技術來防範詐欺行為。
不過，識別合法使用者以及封鎖垃圾內容發布者、詐欺者和機器人的技術，與危害隱私權的數位指紋技術類似。
- Trust Tokens API 提供了另一種做法，允許在某個情境下對使用者建立真實身分 (例如社群媒體網站)，而不需要識別使用者或連結兩種身分，而是透過另一種情境傳遞使用者的真實性。
允許網域屬於同一第一方
目標：讓實體聲明相關網域名稱的擁有者為同一個第一方。
許多機構擁有橫跨多個網域的網站。如果限制在名為「第三方」但實際上屬於同一機構的網站，卻對跨網站追蹤使用者身分，則可能會發生問題。
- 第一方集合的目標是讓多個網域聲明自己屬於同一個第一方，使網路的第一方和第三方概念更符合實際需求。
瞭解詳情
Privacy Sandbox 提案說明
需要您的支援，才能使用 Privacy Sandbox 計畫。API 提案的說明者需要提供意見回饋，特別是指出未達成的用途，以及更保護隱私的方式達成目標。
網路的潛在隱私模型說明瞭 API 的基礎核心原則。
Privacy Sandbox
- 技術總覽：Privacy Sandbox
- 非技術性總覽：privacysandbox.com
- 專案原則：打造更私密的網路環境
- 第三方 Cookie 的未來發展
討論和參與
用途、政策與規定
附錄：提案說明中使用的詞彙詞彙
點閱率 (CTR)
按下廣告後看到廣告的使用者比例。(另請參閱曝光)。
點閱後轉換
由「已點擊」廣告產生的轉換。
轉換
先前與廣告客戶的廣告互動後，在廣告客戶的網站上完成某個動作。例如，在點按連結至廣告客戶網站的廣告後，購買產品或訂閱電子報。
差異化隱私
分享資料集的資訊以揭露行為模式，而不用揭露使用者的私人資訊，也不會指出資料是否屬於特定資料集。
網域
eTLD、eTLD+1
「有效」頂層網域是由公開字尾清單所定義。例如：
co.uk
appspot.com
glitch.me
有效 TLD 可讓 foo.appspot.com 成為 bar.appspot.com 以外的網站。在這種情況下，有效的頂層網域 (eTLD) 就是 appspot.com，而整個「網站」名稱 (foo.appspot.com、bar.appspot.com) 則稱為 eTLD+1。
另請參閱頂層網域。
熵
表示某項資料項目揭露個人身分的程度。
資料熵是以位元測量。資料揭露越多，熵價值就越高。
資料可以合併以辨識個人，但難以判斷新資料是否會新增至熵。舉例來說，如果你知道某人來自澳洲人，即使知道對方是袋鼠島，雖說對方依然無法減少熵。
數位指紋採集
識別及追蹤個別使用者行為的技巧。數位指紋採集使用了使用者不知道且無法控制的機制。Panopticlick 和 amiunique.org 等網站會顯示如何結合指紋資料，以便識別您的個人身分。
指紋辨識表面
可以使用的元件 (可能會與其他介面搭配使用) 來識別特定使用者或裝置。舉例來說，navigator.userAgent() JavaScript 方法和 User-Agent HTTP 要求標頭會提供指紋途徑 (使用者代理程式字串) 的存取權。
第一方
您所造訪的網站提供的資源。舉例來說，你正在閱讀的網頁位於 web.dev，且包含該網站的資源。另請參閱第三方。
曝光
廣告檢視畫面。(另請參閱點閱率)。
k-anonymity
資料集內的去識別化措施。如果您同時設定了 k 匿名性，就無法與資料集內的其他 k-1 個人區別。換句話說，k 個人的資訊相同 (包括您本人)。
Nonce
只在加密編譯通訊中使用一次的任意數字。
來源
要求的來源，包括伺服器名稱，但沒有路徑資訊。例如 https://web.dev。
被動途徑
無論網站是否要求提供部分數位指紋驗證，例如使用者代理程式字串、IP 位址和接受語言標頭，都可供每個網站使用。也就是說，被動途徑可以輕鬆消耗網站的隱私預算。
Privacy Sandbox 計畫提議以被動途徑取代被動途徑來取得特定資訊，例如使用 Client Hints 一次取得使用者的語言，而不要在每個伺服器回應中都提供接受語言標頭。
發布商
Privacy Sandbox 提案說明主要以廣告為主，因此這類發布商是指在自家網站中刊登廣告的發布商。
觸及率
看到廣告的使用者總數。
再行銷
向造訪過您網站的使用者放送廣告。舉例來說，網路商店可以向先前在網站上瀏覽過玩具的使用者顯示玩具特賣廣告。
網站
介面
第三方
來自你造訪的網站網域以外的資源。舉例來說，foo.com 網站可能會使用來自 google-analytics.com (透過 JavaScript)、使用.typekit.net 的字型 (透過連結元素) 的分析程式碼，以及來自 vimeo.com 的影片 (在 iframe 中)。另請參閱第一方一文。
頂層網域 (TLD)
頂層網域 (例如 .com 和 .org) 則列在「根區域資料庫」中。
請注意，有些「網站」實際上只是子網域。舉例來說，translate.google.com 和 maps.google.com 只是 google.com 的子網域 (也就是 eTLD + 1)。
.well-known
在提出要求之前存取政策或其他主機資訊會很有幫助。舉例來說，robots.txt 會指示網頁檢索器要造訪哪些網頁，以及要略過哪些網頁。網際網路工程任務組 (IETF) RFC8615 概述了一種標準化做法，讓 /.well-known/ 子目錄中的標準位置存取整個網站的中繼資料。您可以在 iana.org/assignments/well-known-uris/well-known-uris.xhtml 中查看相關清單。
感謝各位撰寫及評論這篇文章的貢獻者。
Pierre Bamin 相片由 Unsplash 提供。