深入瞭解 Privacy Sandbox

Privacy Sandbox 是一系列提案,專為缺少第三方 Cookie 或其他追蹤機制的第三方用途所設計。

摘要

  • 本文將概述 Privacy Sandbox 提案中的 API 和概念。
  • 提案作者會邀請社群成員 (特別是發布商、廣告客戶和廣告技術公司) 提供意見,藉此建議缺少的應用實例,並提供進一步協助業務用途的相關資訊。
  • 您可以在與下方連結連結的存放區中回報問題,對提案做出評論。
  • 請參閱本文結尾處的提案詞彙解釋

最新的網路隱私權狀態

網站會使用其他公司的服務來提供數據分析、提供影片及處理許多其他有用的資訊。可組合性是網路的強大威力之一。最重要的是,廣告會透過第三方 JavaScript 和 iframe 顯示在網頁上。廣告瀏覽、點擊和轉換是透過第三方 Cookie 和指令碼追蹤。

不過,當您瀏覽網站時,可能不會注意到相關的第三方,以及他們如何處理您的資料。即使是發布商和網頁程式開發人員,可能也無法瞭解整個第三方供應鏈。

廣告選擇、轉換評估和其他用途目前需要建立穩定的跨網站使用者身分。過去,瀏覽器早已採用第三方 Cookie,但瀏覽器已開始限制存取這些 Cookie。此外,透過其他機制追蹤跨網站使用者追蹤的情況,這些機制包括隱密瀏覽器儲存空間、裝置數位指紋採集,以及電子郵件地址等個人資訊的要求。

這種情況對網頁版服務來說並不容易。如何在不讓使用者跨網站追蹤使用者的情況下,支援合法的第三方用途?

具體來說,網站該如何讓第三方顯示廣告並評估廣告成效,卻不能允許個別使用者剖析,藉此製作內容資金。在不採用裝置數位指紋採集等黑暗模式的情況下,廣告客戶和網站擁有者該如何評估使用者的真實性?

當下的行為模式可能會對整個網路生態系統產生問題,而不只是使用者而已。對發布商和廣告客戶而言,追蹤身分及使用各種非標準第三方解決方案可能會增加技術債、程式碼複雜度和資料風險。使用者、開發人員、發布商和廣告主必須確信網路確實保護使用者的隱私權選擇。

廣告是網際網路的核心商業模式,但廣告必須適合所有人瀏覽。Privacy Sandbox 的使命是打造蓬勃發展的網路生態系統,尊重使用者並保護隱私。

隆重推出 Privacy Sandbox

Privacy Sandbox 導入了一組隱私權保護 API,可支援在沒有第三方 Cookie 等追蹤機制的情況下,為開放網路提供資金的商業模式。

如要使用 Privacy Sandbox API,就必須在網路瀏覽器中指派新角色。與其使用有限的工具和保護措施,使用者的瀏覽器可以根據使用者的裝置在本機端執行動作,從而保護使用者在瀏覽網路時的識別資訊。這些 API 可用於廣告選擇和轉換評估等用途,但不會提供個人私人和個人資訊。在工程術語中,「沙箱」sandbox是受保護的環境;Privacy Sandbox 的重要原則是應保護使用者的個人資訊,而且不應以允許使用者在各個網站上識別使用者身分。

這會改變瀏覽器方向。Privacy Sandbox 的未來展望:提供特定工具以因應特定用途,同時保護使用者隱私。網路的潛在隱私權模型載明 API 背後的核心原則:

  • 建立網路活動範圍,讓使用者瀏覽器可以將其視為單一身分。
  • 瞭解資訊如何跨越身分界限移動,同時又不損及資料區隔。

Privacy Sandbox 提案

為順利轉換第三方 Cookie,Privacy Sandbox 計畫需要您的協助。這項提案說明需要開發人員、發布商、廣告客戶和廣告技術公司提供意見回饋,藉此建議缺少的應用實例,並說明如何以保護隱私權的方式達成目標。

您可以提交每個存放區的問題,以對提案說明加註:

  • 網路隱私權模型
    建立網路活動的範圍,讓使用者瀏覽器能跨網站視為擁有單一身分。瞭解資訊如何跨越識別資訊界限,且不會影響資料分隔。
  • 隱私預算
    限制網站可存取的潛在可識別資料總量。更新 API,減少潛在可識別資料量。存取可評估的資料。
  • Gnatcatcher
    藉由存取 IP 位址限制識別個別使用者的能力。
  • Trust Token API
    啟用來源後,信任的使用者會透過使用者瀏覽器儲存的加密編譯權杖來核發憑證,以便用於其他情境中評估使用者的真實性。
  • 第一方集合
    允許同一個實體擁有的相關網域名稱宣告自己屬於同一個第一方集合。
  • 匯總報表
    提供可保障隱私權的機制來支援各種用途,例如瀏覽後轉換、品牌、升幅和觸及評估。
  • Attribution Reporting
    透過事件層級和匯總報表,提供可保障隱私權的點擊與觀看次數評估方法。
  • Topics API
    啟用按照興趣顯示廣告的功能,不必另外追蹤使用者造訪的網站。本 API 的設計根據我們早期 FLoC 試驗的社群意見回饋而設計,並取代 FLoC 提案
  • FLEDGE
    提供再行銷用途的解決方案,確保第三方無法用來追蹤使用者的跨網站瀏覽行為。

您可以立即深入瞭解 API 提案內容。我們會在未來幾個月內逐一發布每個提案的相關文章。

我們也會在播放清單中加入五分鐘的影片播放清單,簡單說明每個 API。

用途和目標

評估轉換

目標:讓廣告客戶評估廣告成效。

Attribution Reporting API 可用於評估兩個連結的兩個事件: 1. 發布商網站上的事件,例如使用者瀏覽或點擊廣告。 1. 廣告客戶網站的後續轉換。

這個 API 支援點閱後瀏覽後轉換評估。

此 API 中的其他功能包括跨裝置歸因報表和「應用程式到網頁」歸因報表。

API 也提供兩種歸因報表

  • 事件層級報表會將特定廣告點擊或瀏覽 (廣告端) 與轉換端的資料建立關聯。為保護使用者隱私,藉由避免跨網站將使用者身分加入,轉換端資料將非常有限,且資料也會「雜訊」(這表示在極少數情況下,系統會傳送隨機資料)。做為額外的隱私權保護,系統不會立即傳送報表。

  • 匯總報表不會根據廣告上的特定事件顯示,相較於事件層級報表,這類報表提供更豐富、更精確的轉換資料。結合隱私權技術、加密編譯、信任分佈和差異化隱私,就能降低身分加入跨網站身分的風險。

這兩種報表可同時使用:相輔相成。

Attribution Reporting 簡介:進一步瞭解這些功能的狀態和試用方式。

請選取廣告

目標:讓廣告客戶顯示與使用者相關的廣告。

相關廣告對使用者來說更實用,發布商 (付費刊登含廣告內容的網站) 也能創造更多利潤。第三方廣告選擇工具能為廣告客戶 (在網站上購買廣告空間的使用者) 提供更有價值的廣告空間,因此含廣告內容的網站可增加收益,協助製作並發布內容。

您可以運用多種方式讓廣告與使用者相關的廣告,包括:

  • 第一方資料:顯示與使用者曾表示感興趣的網站,或是使用者在目前網站上瀏覽過的內容相關的廣告。
  • 內容比對:根據網站內容選擇顯示廣告的位置。例如,「將這則廣告放在編織相關報導旁邊。」
  • 再行銷:向曾經造訪您網站的使用者放送廣告,但不包括他們。例如:「向造訪過您的商店,並將編織品儲存在購物車的訪客顯示這則廣告的折扣羊毛消費者,在他們瀏覽手工藝網站時放送這則廣告。」
  • 按照興趣:根據使用者的瀏覽記錄選取廣告。例如:「向瀏覽行為表示可能對編織內容感興趣的使用者顯示這則廣告」。

第一方資料和內容相關廣告選擇可以達成,而不需要瞭解使用者在網站上的活動以外的任何資訊。這些技術不需要跨網站追蹤。

一般而言,再行銷的方法是使用 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

討論和參與

用途、政策和規定


附錄:提案說明中所用詞彙的詞彙表

點閱率 (CTR)

使用者點擊廣告並看到廣告的比例。(另請參閱曝光次數)。

點閱後轉換 (CTC)

轉換歸因於發生「已點擊」的廣告。

轉換

先前曾與廣告客戶廣告互動的使用者在廣告客戶網站上完成操作。例如購買產品或訂閱電子報,並連到廣告客戶的網站。

差異化隱私

分享資料集相關資訊以揭露行為模式,而不揭露使用者的私人資訊,也不會影響資料是否屬於特定資料集。

網域

請參閱「頂層網域」和「eTLD」。

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

另請參閱頂層網域

一個資料項目用來透露個人身分的比例。

資料熵測量單位為位元。這些資料越能透露身分,熵就越高。

資料可以結合來識別個人,但要判斷新資料是否增加熵。比方說,即使知道某個人來自澳洲,如果已知對方來自袋鼠島,也不會影響熵。

數位指紋採集

識別和追蹤個別使用者行為的技巧。指紋功能採用使用者不認識且無法控制的機制,有些網站 (例如 Panopticlickamiunique.org ) 會說明如何整合指紋資料,以識別個人身分。

指紋識別介面

可用來識別特定使用者或裝置的內容 (可與其他途徑搭配使用)。舉例來說,navigator.userAgent() JavaScript 方法和 User-Agent HTTP 要求標頭提供了指紋功能介面 (使用者代理程式字串) 的存取權。

第一方

來自你所造訪網站的資源。舉例來說,您現在閱讀的網頁是 site.dev 網站,其中包含該網站的資源。另請參閱第三方

曝光

廣告的觀看次數。(另請參閱點閱率)。

k-anonymity

用來評估資料集內的匿名性。如果您的身分是 k,就無法與資料集中的其他 k-1 個人區分。換句話說,k 人擁有相同的資訊 (包括您本人)。

Nonce

只用於加密編譯通訊的任意數字。

來源

要求的來源,包括伺服器名稱但不含路徑資訊。例如 https://web.dev

被動表面

無論網站是否要求,每個網站都能使用某些數位指紋採集介面,例如使用者代理程式字串、IP 位址和接受語言標頭。這表示被動介面可以輕鬆消耗網站的隱私預算。

Privacy Sandbox 計畫提議以主動的方式取代被動介面,以便主動取得特定資訊。例如,使用 Client Hints 一次取得使用者語言,而不是讓每個伺服器每次回應都只能提供接受語言標頭。

發布者

Privacy Sandbox 提案說明主要與廣告有關,因此所指的發布商類型是指會在自家網站上顯示廣告的發布商。

觸及率

看到廣告的使用者總數。

再行銷

向曾經造訪您網站的使用者放送廣告。舉例來說,某網路商店可以向網站舊訪客顯示玩具特賣廣告。

網站

請參閱「頂層網域」和「eTLD」。

途徑

請參閱「指紋表面」和「被動表面」。

第三方

由你造訪網站的網域提供資源。舉例來說,foo.com 網站可能會使用 google-analytics.com (透過 JavaScript) 提供的分析程式碼、 use.typekit.net 的字型 (透過連結元素) 以及 vimeo.com 的影片 (在 iframe 中)。另請參閱「第一方」。

頂層網域 (TLD)

「根區域資料庫」會列出頂層網域 (例如 .com 和 .org) 。

請注意,某些「網站」實際上只是子網域。舉例來說,translation.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 BaminUnsplash 上提供。