Privacy Sandbox 隱私沙盒解決方案 : Related Website Sets (RWS) 是什麼?

本刊62期曾報導過 Chrome Privacy Sandbox First-Party Sets,如今已改名為 Related Website Sets(簡稱 RWS)。RWS 的概念就是讓企業、組織、媒體集團可以在旗下所擁有的跨網域,可以整合共用所屬的跨網域 Cookies。包含:

  • 品牌網域,例如: fly-brandx.com, drive-brandx.com
  • 應用網域,例如: calendar-brandx.com, mail-brandx.com
  • 跨國網域,例如: brandx.co.uk, brandx.rs
  • 服務網域,例如:使用者看不到的 brandx-assets.com
  • 沙盒網域,例如:安全性考量 brandx-usercontent.com

Related Website Sets 是一個網頁平台機制,讓瀏覽器能夠去辨別不同網域之間,實際上是屬於同一個單位的情況,以便後續能做資料的共享或是保護不被存取。

打個比方來說,Google.com 的網域和 YouTube.com 網域不同,對於瀏覽器而言這是跨網域的狀況,要在跨網域之間共享數據,即便是 Google 和 YouTube 顯而易見都是同屬一方,仍然要透過第三方 Cookies。而 RWS 就是可以將不同的網域宣告成屬於同一個單位所擁有,在第三方 Cookies 淘汰後,透過 RWS 就可以讓這些網域仍屬於同樣的第一方,繼續共享資料。

如何送審 RWS,將網域指定為同樣的第一方

來源 : related-website-sets/RWS-Submission_Guidelines.md

要能夠讓網域加入到 RWS 當中,需要有三個步驟:

  1. 首先需要遵循 RWS 的規範,產生 JSON 檔案去標註哪些網域是屬於同一方,且網域之間的關係為何,比如說是 A 網域是英文版的網站、B 網域是客服網站等
  2. 在加入 FPS 的網站當中,在 /.well-known/related-website-set.json 路徑中提供上述的檔案,以便驗證擁有權,證明該網域確實願意加入指定的 FPS
  3. 最後需要透過 GitHub 的 Pull Request 機制,將 RWS 的 JSON 檔案提交到 Chrome 的程式庫當中審查,待官方確認後、合併才算完成上線

換而言之,中間會有一段人工審查的部分,為了避免讓人覺得是黑箱作業,因此透過 GitHub 的開放平台進行審查,一切的討論以及最後審核結果與否都是公開資訊,提供大眾檢閱。

加入 RWS 之後如何共享跨站資訊

當網域加入 RWS 後,並非是直接可以在 A 站中讀取到 B 站的 Cookies,而是如過往使用第三方 Cookies 一樣,在 A 站跨網域呼叫 B 站時(比如追蹤 Pixel),B 站會記得帶上原有的 Cookies,而不會變成一片白紙、無法追蹤。

為使網站開發者能夠確認是否是屬於 RWS 的環境,Chrome 也透過目前跨瀏覽器普遍支援的 Storage Access API(SAA)requestStorageAccessFor API 提供了查詢功能,讓網站程式碼能夠先行判斷是否網域之間有加入 RWS並共享 Cookies。

若是沒有加入 RWS 的情況,網站也可以利用 SAA 來呼叫彈跳視窗,主動詢問使用者是否願意提供 A 網站存取 B 網站的 Cookies。此一機制在 Safari 上已行之有年,如點選 Facebook 的網頁嵌入按讚按鈕時,便會跳出一個瀏覽器畫面,詢問是否願意授權使用第三方 Cookies。

結論

此功能雖被業界批評,是 Google 自身想要解決 Google 與 YouTube 跨網域之間的問題。甚至讓人聯想這是開了一個第三方 Cookies 的後門,讓市場的 ID Solutions 更加破碎。然而,本刊認同這些批評的確有其道理,但仍是認為廣告主及媒體陣營, 須儘早採用 RWS 的跨網域共享 Cookies 申請,及投入 Privacy Sandbox 各項 API工具的理解及應用 ,積極準備今年第四季 Cookieless 正式的到來 。

延伸閱讀