The Rise of Privacy

11 min readApr 6, 2020

Introduction

這些年來 web user 迅速攀升，從網際網路上人們可以輕易獲取各項所需的資訊、技能以及娛樂。對於網際網路的態度也不斷的翻新進化，從早期不明就裡看到 dialog 出現就狂按「確定」的懵懂無知，直到今日已懂得個資的重要，不經過一番確認絕不輕易授權。再加上這兩年來 facebook 個資的濫用與販賣，更加強化 web user 對於「隱私權」的重視與保護。

除了主觀意識抬頭外，瀏覽器開發商更直接從瀏覽器下手，藉由新穎的制約讓跨網站追蹤這檔事兒變的更為困難且近乎無懈可擊。由於瀏覽器的開發商不同，自然而然對於實作面上便會有所差異，也因為這些差異點，造成了 web developers 莫大的困擾。

透過 3rd Party Cookie injection，一些廣告商或者不良的團體可以更輕易的 web user 進行標記或者做些壞事，這就是為什麼常常會在不同的網站接受到同樣類型的廣告推播。因為這些緣故，有效的屏蔽 3rd party cookie injection 便是瀏覽器主要的切入點。

接下來將以 Google Chrome 以及 Apple Safari 這兩大瀏覽器進行介紹以及討論。看看兩者對於 3rd party cookie 的態度又是如何？！

Chrome

主要針對 Cookie 的 SameSite 屬性進行制約，SameSite 基本上依據嚴謹度的差異劃分成三個類別，分別是

Strict: 僅有在 same-site 的 request 可以傳遞 cookie
Lax: same-site request 以及部分 cross-site request 可以寫入 cookie (<a>、<link rel=”prerender”>、<form method=get>)
None: 沒有任何限制，不管 same-site 或是 cross-site 都可以傳遞 cookie

有興趣的朋友可以點擊下方連結一覽相關介紹。

SameSite cookies explained

為了加速整個生態落實，Google 更照表定行程於 Chrome 80+ 的版本強制將沒有設定的 cookie 預設為 SameSite=Lax，也就是說 Google 默默地將你的 cookie 使用權限做一有效的限制了。

除此之外，所有 cross-site 的 cookie 更被制約成唯有 SameSite=None; Secure 的先決條件才能有效的傳遞 cookie 至標的 domain。

SameSite cookie recipes

Cookies without a SameSite attribute will be treated as SameSite=Lax, meaning the default behavior will be to restrict cookies to first party contexts only.
Cookies for cross-site usage must specify SameSite=None; Secure to enable inclusion in third party context.

如上所述，Google 認為 website owner 對於 3rd party 的串接服務應該要更加的嚴緊。對於兩者間溝通的 Cookie 更要負責。並留下了 SameSite=None; Secure 這樣的許可，可以說嚴律下尚有有一絲寬容。

Safari

除了有支援 Cookie SameSite 屬性外，倒是沒有和 Google 一致對於沒有設置 SameSite 屬性的 Cookie 一律視同 Lax，對於 3rd party cookie 也沒有明確的規定唯有SameSite=None; Secure 的前提下才能傳遞，是不是覺得 Safari 友善許多呢？

其實 Safari 一點都不友善

因為 Safari 實作了一另一套制約的條件 — Intelligent Tracking Prevention (以下簡稱 ITP，目前最新版本為 2.3)，透過 ITP 的蹂躪，在 Safari 上面透過 3rd party cookie 標記 web user 其實已經很難了，主要是因為其 rule 不斷的進化，沒有最嚴，只有更嚴。

我們來看一下 ITP 對於 3rd party cookie 的應對時間軸

ITP timeline for 3rd party cookie. (image from https://webkit.org/blog/7675/intelligent-tracking-prevention/)

主要分成三個週期，分別是 0 day, 1 day 以及 30 days

3rd party cookie 被種下的當下可以傳遞至標的網站。
如果往後一天內沒有去標的網站進行訪問及互動，則該 3rd party cookie 將無法被傳遞至標的網站﹔反之，如果有前往標的網站晃一晃，則又可以繼續使用了並且重置了 24hr 這個 timer。
如果 30 天內都沒有去標的網站晃一晃，那麼該 3rd party cookie 就會被 Safari 回收，再也不復存。(timer 重新回到步驟一)

以上便是 ITP 阻檔 3rd party cookie 的相關應對時間軸。

不要以為這樣就結束了，Safari 更針對 iOS and iPadOS 13.4 and Safari 13.1 on macOS 這些版本，

直接封殺了 3rd party cookie！

是的！你沒有看錯，有別於 Chrome 尚留一條活路的做法，Safari 就是直接封殺了 3rd party cookie。

Full Third-Party Cookie Blocking and More

作法既霸道且強硬，這年頭只要高舉著隱私權大旗的人總是能凌駕一切！此外，這個 3rd party cookie blocking 更凌駕且無視 ITP 的 timeline，不能用就是不能用！

不過 Safari 也有建議 web developer 該怎麼做︰

使用 OAuth 2.0 作為授權準則，將 cookie based 的串接均改為 OAuth ready (找地方存放 auth token 便是另一個難題)
如果非 Cookie 不可的話，倒也不是不行，只要透過 Storage API 取得使用者授權的話，那我就給你用。如同一般 Web API 的做法，取得使用者授權後便可以使用 web storage。這樣的做法其實非常的合理，不過我相信絕大部分的使用者看到授權 dialog 應該馬上就關閉或者直接被嚇跑了吧！
短暫開放 popup window + at least one tap or click rule，只要符合這兩個必要條件，那麼 Safari 也會允許 cookie 的使用權限。<amp-access />剛好就是符合了這兩個條件 (開啟新視窗至標的網站進行 member login)，所以在 3rd party cookie blocking 的制約下仍然可以正常運行該功能。筆者建議這僅能是暫時的替代方案，因為文件中有闡述這個短暫開放將會在日後版本進行移除，所以還是以上述兩個方法尋求正常流程方為正解。

Is SameSite or 3rd party cookie blocking active ?

看完以上兩個瀏覽器的制約做法後，相信所有的 web developers 心都涼了，但這還不是最麻煩的，以 Chrome 來說，它似乎是 by region 以及 bucket 的機制來慢慢開啟 SameSite Cookie Policy，造成有的使用者已經被開啟，有的則還是關閉的狀態。(Safari 不知道是隨著 OS 更新開啟還是 bucket)

雖然 web developers 可以透過 SameSite Cookie 測試網站來確認 Chrome SameSite 是否已經被啟用了。

左圖尚未啟用, 右圖已啟用 (Test your browser’s SameSite cookie behavior)

不過知道瀏覽器是否開啟 SameSite Cookie Policy 僅僅方便 debug，並無助於 web developers 的流程開發，所以筆者建議直接透過 chrome://flags 將 SameSite 的相關項目強制開啟。

針對 Safari，也可以透過 Safari Technology Preview (以下簡稱 STP) 來做為開發用瀏覽器，所有最新的 feature 都會在 STP 中實作，避免 web developers 無法在 3rd party cookie blocking 未開啟的瀏覽器中開發。

Inspections

筆者一向都很反骨，對於別人給的速成數據或資訊均持懷疑的態度，天曉得數據是否加工抑或是實作上與文件描述有所差異，所以針對 SameSite Cookie Policy 以及 3rd party cookie blocking 這兩件事情的影響範圍總心存疑惑，索性，直接寫個 Inspection Page 來測試自己當前常用的一些 scenarios 是否可以正常運作。

請先訪問 3rd party cookie blocking inspections 。
於頁面中點擊「 INSPECT」按鈕進行檢測 (可選擇是否要設定 SameSite:none)
讓子彈飛一會兒，便可以看到相關的檢測結果，綠色打勾的項目表示說 cookie 有正常的傳遞至標的網站，反之則表示 cookie 已被 trim 了。(如果有藍色問號，則需要再次點擊該藍色問號進行檢測)

本頁面主要是針對 cross-site 的部分進行檢測，檢測涵蓋的範圍如下所示︰

image source
iframe
form[method=GET] (to current page iframe)
form[method=POST] (to current page iframe)
JSONP
fetch[method=GET]
fetch[method=POST]
postMessage (to current page iframe)
Direct Submission — GET (form action 為標的網站, 需要再次點擊藍色問號進行測試)
Direct Submission — POST (form action 為標的網站, 需要再次點擊藍色問號進行測試)

這些都是筆者日常會使用到的技巧與方法，透過快速檢測便能快速地知道這些技巧的行與不能。有興趣的朋友也可以將之加入主畫面，更方便時時刻刻做檢測。

3rd party cookie blocking inspections demo

除此之外，筆者亦有做 cross-subdomain 的相關測試，有興趣的朋友亦可點擊下方連結一覽。

3rd party cookie blocking inspections (cross-subdomain)

Conclusion

以上便是筆者近期的一點心得分享，希望透過資訊的散播，可以讓更多人體會 3rd party cookie 的變革以及 web developers 應有的應對態度與對策。分享給一同在這領域奮鬥的朋友們，希望對大家有所助益。