Privacy Sandbox 隱私沙盒解決方案 : Related Website Sets (RWS) 是什麼？
Related Website Sets（簡稱為 RWS）是什麼？ RWS 一個網頁平台機制，讓瀏覽器能夠去辨別不同網域之間，實際上是屬於同一個單位的情況，以便後續能做資料的共享或是保護不被存取。當網域加入 RWS 後，並非是直接可以在 A 站中讀取到 B 站的 Cookies，而是如過往使用第三方 Cookies 一樣，在 A 站跨網域呼叫 B 站時（比如追蹤 Pixel），B 站會記得帶上原有的 Cookies，而不會變成一片白紙、無法追蹤。
本刊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
Related Website Sets 是一個網頁平台機制，讓瀏覽器能夠去辨別不同網域之間，實際上是屬於同一個單位的情況，以便後續能做資料的共享或是保護不被存取。
打個比方來說，Google.com 的網域和 YouTube.com 網域不同，對於瀏覽器而言這是跨網域的狀況，要在跨網域之間共享數據，即便是 Google 和 YouTube 顯而易見都是同屬一方，仍然要透過第三方 Cookies。而 RWS 就是可以將不同的網域宣告成屬於同一個單位所擁有，在第三方 Cookies 淘汰後，透過 RWS 就可以讓這些網域仍屬於同樣的第一方，繼續共享資料。
如何送審 RWS，將網域指定為同樣的第一方
要能夠讓網域加入到 RWS 當中，需要有三個步驟：
- 首先需要遵循 RWS 的規範，產生 JSON 檔案去標註哪些網域是屬於同一方，且網域之間的關係為何，比如說是 A 網域是英文版的網站、B 網域是客服網站等
- 在加入 FPS 的網站當中，在
/.well-known/related-website-set.json路徑中提供上述的檔案，以便驗證擁有權，證明該網域確實願意加入指定的 FPS - 最後需要透過 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 正式的到來 。
延伸閱讀
