深入瞭解 Privacy Sandbox

Privacy Sandbox 是一系列提案,可在不使用第三方 Cookie 或其他追蹤機制的情況下,滿足第三方用途。

摘要

  • 本文將概略說明 Privacy Sandbox 提案的 API 和概念。
  • 提案作者邀請社群 (發布商、廣告客戶和廣告技術公司) 提供意見,藉此建議缺漏的用途,並分享如何支援您的商業用途的資訊。
  • 您可以在下方連結的存放區中提出問題,針對提案提供意見。
  • 請參閱本文結尾處有關提案的詞彙解釋

網路隱私權的目前狀態

網站會使用其他公司的服務來提供數據分析、提供影片及執行其他許多實用服務。可組合項是網路的強大威力,最值得注意的是,透過第三方 JavaScript 和 iframe 包含在網頁中。廣告瀏覽、點擊和轉換是透過第三方 Cookie 和指令碼追蹤。

不過,當您造訪網站時,可能無法得知參與的第三方以及他們如何運用您的資料。即使是發布商和網頁開發人員,也不一定能瞭解整個第三方供應鏈。

廣告選擇、轉換評估和其他用途目前仰賴建立穩定的跨網站使用者身分。過去這項功能是透過第三方 Cookie 達成,但瀏覽器已開始限制對這些 Cookie 的存取權。同時,使用其他機制的應用也降低了跨網站使用者追蹤的比例,例如隱藏瀏覽器儲存空間、裝置數位指紋採集,以及索取個人資訊 (例如電子郵件地址) 的要求。

這是網路的兩難。如何在不讓其他網站追蹤使用者的情況下,支援第三方的用途?

尤其是讓第三方顯示廣告及評估廣告成效,但不能允許他們透過剖析的方式,透過網站賺取收益的方式。如果廣告主和網站擁有者不想採用裝置數位指紋採集等深色模式,該如何評估使用者的真實性?

當下的運作方式對整個網路生態系統都有可能問題,使用者而不僅是使用者。對發布商和廣告客戶來說,追蹤身分及使用各種非標準的第三方解決方案,都可能會造成技術債、程式碼複雜性和資料風險增加。使用者、開發人員、發布商和廣告主應確信網路會保護使用者的隱私權選擇。

廣告是網路的核心商業模式,但廣告必須人人受惠。而隱私權沙箱的使命是:打造蓬勃發展的網路生態系統,尊重使用者且預設隱私。

Privacy Sandbox 簡介

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

使用 Privacy Sandbox API 時,網路瀏覽器必須扮演新角色。相較於運用有限的工具和保護措施,API 可讓使用者的瀏覽器在本機裝置上代表使用者,於瀏覽網路時保護身分識別資訊。這些 API 能夠實現廣告選擇和轉換評估等用途,但不會揭露個人隱私和個人資訊。以工程術語來說,沙箱是一種受保護的環境。Privacy Sandbox 的一項主要原則是保護使用者的個人資訊,不得以可讓各個網站辨識出使用者身分的方式分享。

這是針對瀏覽器的方向轉變。Privacy Sandbox 的未來願景,能夠在瀏覽器上提供特定工具,以滿足特定用途,同時維護使用者隱私。網路的潛在隱私權模型列出 API 背後的核心原則:

  • 建立多種網路活動,使用者瀏覽器可讓網站將單一身分視為單一身分。
  • 找出資訊在身分界線之間移動的方式,而不破壞身分區隔。

Privacy Sandbox 提案

Privacy Sandbox 計畫需要支援,才能順利停用第三方 Cookie。這項提案說明需要開發人員、發布商、廣告主和廣告技術公司的意見回饋,才能建議缺少的用途,並說明如何以保護隱私權的方式達成目標。

您可依據每個存放區提交問題,為提案說明內容加註:

  • 網頁版隱私權模型
    建立各種網路活動,使用者瀏覽器可讓網站將單一身分視為單一身分。瞭解資訊在身分界線之間移動的方式,而不破壞身分劃分。
  • 隱私公開程度上限
    限制網站可以存取的潛在識別資料總量。更新 API,減少揭露的潛在識別資訊。將潛在識別資料的存取權用於評估。
  • Gnatcatcher
    存取個別使用者的 IP 位址來限制識別個別使用者的功能。
  • 信任 Token API
    啟用信任使用者提供給其瀏覽器儲存的密碼權杖,供其用於其他內容,用於評估使用者的真實性。
  • 第一方集合
    允許同一實體擁有的相關網域名稱,聲明自己屬於同一第一方所有。
  • 匯總報表
    提供隱私權保護機制,以因應瀏覽後轉換、品牌、升幅和觸及評估等多種用途。
  • 歸因報表
    透過事件層級和匯總報表,以保護隱私權的方式評估點擊和觀看行為。
  • Topics API
    啟用按照興趣顯示廣告的功能,而不需追蹤使用者造訪的網站。這個 API 的設計是在我們早期 FLoC 試用階段的社群提供的意見,並且取代了 FLoC 提案
  • FLEDGE
    針對再行銷廣告用途提供解決方案,讓第三方無法藉此追蹤使用者的瀏覽行為。

您可以立即深入瞭解 API 提案說明,未來幾個月內,我們會個別發布各項提案的貼文。

我們也會在播放清單中,新增 5 分鐘的影片,針對各個 API 提供簡單說明。

用途和目標

評估轉換

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

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

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

這個 API 的其他功能包括跨裝置歸因報表和應用程式至網頁歸因報表。

API 也提供兩種歸因報表

  • 事件層級報表會將特定廣告點擊或觀看 (廣告端) 與轉換端的資料建立關聯。為了維護使用者隱私,避免跨網站彙整使用者身分,轉換端資料會非常有限,且資料會「雜訊」(這表示在一小部分案例中,系統會傳送隨機資料)。為了保障隱私,系統不會立即傳送報告。

  • 匯總報表不會與廣告端的特定事件建立關聯。比起事件層級報表,這類報表提供更豐富、更精確的轉換資料。結合密碼編譯、信任發布和差異化隱私等各項隱私權技術,有助於降低跨網站彙整身分的風險。

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

Attribution Reporting 簡介」一文,進一步瞭解這些功能的狀態和試用方法。

請選取廣告

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

關聯性高的廣告對使用者來說較有利,能為發布商帶來更高的收益 (也就是經營廣告贊助網站的人)。藉由第三方廣告選擇工具,廣告客戶 (也就是在網站上購買廣告空間的使用者) 可以提高廣告空間的價值,進而增加含廣告內容的網站收益,並讓內容可建立及發布。

您可以透過多種方式確保廣告符合使用者的需求,包括:

  • 第一方資料:根據使用者曾搜尋過的網站、使用者先前在目前網站上瀏覽過的內容,顯示相關廣告。
  • 內容比對:根據網站內容選擇多媒體廣告的位置。例如:「把這則廣告放在編織相關報導旁。」
  • 再行銷:針對造訪過網站的使用者放送廣告,即使他們不在網站內。例如,「對造訪過您的商店,並在造訪手工藝網站時留著編織品的使用者顯示這則折扣羊毛廣告」。
  • 按照興趣:根據使用者的瀏覽記錄選擇廣告。例如,「對瀏覽行為表示他們可能有興趣編織的使用者顯示這則廣告」。

您不需要瞭解使用者 (而非他們在網站上的活動) ,就能完成第一方資料和內容相關廣告選擇。這些技術不需要跨網站追蹤。

再行銷通常使用 Cookie 或其他方式來識別網站上的使用者,也就是將使用者加進名單,然後選取要向他們展示的特定廣告。

按照興趣顯示的廣告選擇功能目前會使用 Cookie 追蹤使用者在最多的網站上的行為。許多人擔心廣告選擇會侵犯隱私權。Privacy Sandbox 提供兩種再行銷解決方案,以及按照興趣選擇的替代方案:

  • FLEDGE:適用於再行銷用途
    這個 API 的設計是為了讓第三方無法利用這個 API 追蹤使用者的瀏覽行為,亦即使用者的瀏覽器,而非廣告客戶或廣告技術平台,這類 API 會儲存使用者瀏覽器相關聯且由廣告客戶定義的興趣群組。使用者的瀏覽器結合興趣群組資料與廣告買方/賣方資料和商業邏輯,進行「競價」以便選取廣告,而不是與第三方分享資料。

  • Topics API:適用於依興趣指定目標對象
    啟用按照興趣顯示廣告的功能,而不需追蹤使用者造訪的網站。API 提議採用機器學習技術,從主機名稱推斷出主題,再搭配 JavaScript API,根據近期造訪網站的主機名稱,傳回使用者目前可能感興趣的概略主題。

對抗數位指紋採集

目標:減少 API 揭露的潛在識別資料數量,並開放存取可由使用者控制且可評估的資料。

瀏覽器已採取淘汰第三方 Cookie 的措施,但識別及追蹤個別使用者行為 (即數位指紋採集) 的技術持續演進。使用者無法得知和無法控制數位指紋採集的機制。

  • 隱私預算提案旨在藉由確定 JavaScript API 或其他「介面」公開的指紋資料數量,以限制數位指紋採集的可能性。(例如 HTTP 要求標頭),以及設定可存取的資料量上限。

  • 使用者代理程式標頭等數位指紋採集介面的檢查範圍會縮減,而用戶端提示等替代機制提供的資料亦須遵守隱私預算限制。其他介面 (例如裝置螢幕方向電池層級 API) 將會更新,盡可能減少資訊暴露量。

IP 位址安全性

目標:控管 IP 位址存取權以減少隱密數位指紋採集,並允許網站選擇拒絕查看 IP 位址,以免消耗隱私預算

使用者的 IP 位址為公開的「位址」電腦的檔案,在大多數情況下,網路是由使用者連上網路時,由網路動態指派。不過,即使是動態 IP 位址,也可能會在很長時間內保持穩定。因此,這意味著 IP 位址是重要的指紋資料來源。

Gnatcatcher 提案的目標是 隱私權保護做法,避免消耗隱私預算,同時確保 出於正當目的 (例如防止濫用) 需要存取 IP 位址, 以便進行認證和稽核

提案分為兩個部分: * 惡意 IP 盲人 網站可讓瀏覽器知道未將 IP 位址連線至使用者的 IP 位址。 * 近距離 NAT 允許 使用者群組,透過相同的伺服器傳送流量,有效隱藏 網站代管商提供的 IP 位址

打擊垃圾內容、詐欺和阻斷服務攻擊

目標:驗證使用者真實性,但不使用數位指紋採集。

除了保護使用者的安全,也要確保廣告主和網站擁有者獲得準確的廣告成效評估結果,就必須防範詐欺行為。廣告客戶和網站擁有者必須能夠分辨惡意漫遊器和真實使用者。如果廣告主無法準確判斷哪些廣告點擊來自真人,支出就會減少,網站發布商的收益也會減少。許多第三方服務目前都使用裝置數位指紋採集等技術來防範詐欺。

然而,用於識別合法使用者及封鎖垃圾內容發布者、詐騙者和機器人的技術,其運作方式與有損隱私權的指紋技術相似。

  • Trust Tokens API 提供了另一種方法,在社交媒體網站等情況下,將使用者建立真實性,藉此將訊息傳遞到另一個情境 (例如新聞網站放送的廣告),而無需識別使用者身分或連結兩個身分。

允許網域屬於同一個第一方

目標:啟用實體,宣告相關網域名稱為相同第一方所有。

許多機構都擁有多個網域的網站。如果限制在認定為「第三方」的網站上追蹤使用者身分,就可能會造成問題但實際上屬於同一個組織。

  • 第一方集合旨在讓多個網域聲明自己屬於同一個第一方,使網路第一方和第三方的概念更貼近現實世界。

瞭解詳情

Privacy Sandbox 提案說明

Privacy Sandbox 計畫需要你的支持。API 提案說明需要意見回饋,特別是針對缺少的用途和目標更保障隱私的方式。

可能的網路隱私模型》概述了 API 的基礎原則。

Privacy Sandbox

討論及參與

用途、政策與規定


附錄:提案說明使用的詞彙解釋

點閱率 (CTR)

有多少比例的使用者在按下廣告後,看到了廣告。(另請參閱曝光一節)。

點閱後轉換

轉換歸給「已點擊」的廣告。

轉換

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

差異化隱私

共用資料集資訊以揭露行為模式,而不揭露個人的私人資訊或是否屬於資料集。

網域

請參閱頂層網域eTLD

eTLD、eTLD+1

「Effective」(有效)頂層網域是由公開尾碼清單定義。例如:

co.uk
appspot.com
glitch.me

有效的 TLD 是讓 foo.appspot.com 從 bar.appspot.com 的其他網站。在這種情況下,有效的頂層網域 (eTLD) 是 appspot.com,完整的網站名稱 (foo.appspot.com、bar.appspot.com) 稱為 eTLD+1

另請參閱頂層網域

衡量資料項目中代表個別身分的資訊量。

資料熵的測量單位為位元。充分透露身分資料越多,熵值越高。

可以合併資料以識別個人身分,但很難判斷新的資料是否會加入熵。舉例來說,如果您知道某位使用者來自澳洲,即使您知道對方來自袋鼠島,也不會減少熵。

數位指紋採集

辨識及追蹤個別使用者行為的技巧。使用者無法得知和無法控制數位指紋採集的機制。

數位指紋採集

可用來 (可能與其他介面併用) 來辨識特定使用者或裝置的工具。舉例來說,navigator.userAgent() JavaScript 方法和 User-Agent HTTP 要求標頭可讓您存取數位指紋採集介面 (使用者代理程式字串)。

第一方

來自你所造訪網站的資源。舉例來說,您看到的網頁位於 site.dev 網站上,並含有該網站的資源。另請參閱第三方

曝光

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

k-anonymity

資料集內的匿名性指標。如為 k 去識別化,就無法與資料集中其他使用者的 k-1 區分。換句話說,「k」個別使用者所擁有的資訊 (包括您本人) 都相同。

Nonce

僅在加密編譯通訊中使用一次的任意號碼。

來源

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

被動表面

無論網站是否要求提供數位指紋採集,都會開放所有網站使用,這類途徑,例如使用者代理程式字串、IP 位址和接受語言標頭。也就是說,被動介面很容易消耗網站的隱私預算。

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

發布商

Privacy Sandbox 提案說明主要涉及廣告,所指的發布商類型就是在網站上刊登廣告。

觸及率

看到廣告的使用者總數。

再行銷

向造訪過您網站的使用者放送廣告。舉例來說,網路商店可以向曾在自家網站上瀏覽玩具的使用者放送玩具特賣廣告。

網站

請參閱頂層網域eTLD

Surface

請參閱「數位指紋採集」和「被動介面」一節。

第三方

資源來源網域與你目前造訪網站的網域不同。舉例來說,假設網站 foo.com 使用了 google-analytics.com 的分析程式碼 (透過 JavaScript)、 use.typekit.net 的字型 (透過連結元素),以及來自 vimeo.com 的影片 (在 iframe 中),另請參閱「第一方」一節。

頂層網域 (TLD)

.com 和 .org 等頂層網域會列在「Root Zone Database」(根區域資料庫) 中。

請注意,部分「網站」實際上就是子網域舉例來說, 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 網站上。