Apple 之前有宣告要完全阻擋 3rd-party cookie，iThome 也有相關的報導，iOS 和 iPadOS 應該是已經上線了，然後最近 Mac 版 Safari 也快要上線了，所以這篇來記錄一下要怎樣因應還有一些參考資料。
其實真的會寫到第三方 cookie 的服務是沒想像多的，如果不是開發給其它網站用的第三方服務的話（不是掛 script 而已），那其實沒那麼常見，舉例來說：很多人可能會覺得 Google Analytic 會受影響，但是其實並沒有，一般網站掛 Google Analytic 算是掛上 3rd-party script，但是它寫的 cookie 是 1st party cookie，也就是寫在你的網站的 domain 下，Google 的文件也有很詳細的說明他的每個 cookie 的用途，然後仔細看就會找到還有寫如何跨網域追蹤，而這其實是需要帶一些參數過去的，如果 GA 是用 3rd-party cookie 寫在 Google 自己的 domain 的話，要跨網域追蹤就不需要這樣帶參數了，我是覺得 Apple 的 ITP 比較是針對廣告和 Facebook，早幾年前 Facebook 可以用 like button 來簡單的做到跨站追蹤，現在那些 iframe 都會被認為是 3rd-party，cookie 會和 1st-party 放不同區（partition），甚至本來如果有先去看過 facebook.com 之後，會有 24 小時可以存取該網域 3rd-party cookie 的能力也在 ITP 2.0 移除，facebook 後來加上了fbclid這個參數來追蹤連出去的連結，然後 ITP 2.2 就又針對這種連結裝飾（link decoration）也設了 cookie 的存取限制（剛好同時也影響到 Google Analytic）。
如果真的是需要作為 3rd-party 端提供服務的話怎麼辦呢？其實一開始 Apple 那篇文章，有列了幾個方案，其中正規的兩個方案：
- 用 OAuth 2.0 作為 user auth 的方案，然後第一方網站拿到 token 後自己存好（作為 1st-party cookie 或是其它儲存方法）。
- 用 Storage Access API，這是 Apple 所提出的 Web API，在被視為第三方的 context 中（例如 iframe），可以透過 Storage Access API 來取得 1st-party cookie 的存取權限，不過一般人直接用這個 API 要權限，可能會覺得奇怪怎麼 Safari 都沒有問使用者要不要給，權限就拿到了，其實這是因為 Apple 那邊的想法是這個 API 要盡可能的不干擾使用者，所以只有被歸類（classified）為有追蹤能力的域名才會跳出視窗跟使用者詢問，至於這個歸類的方法是在 ITP 1.0 中提出的，Apple 考慮到隱私問題，所以這個機制是用機器學習的，每台電腦/裝置都維護自己的清單，沒有中心化的黑名單（Firefox 應該是用這種方法），而如果想要親自驗證自己的 domain 要是被歸類為追蹤網站的話，會發生什麼事的話，也有篇文章介紹，我自己有測試過也確實看到了那個詢問視窗。
然後如果要用 Storage Access API，其實還有些限制，Safari 從 1.0 開始，就有個針對 3rd-party cookie 的限制，就是使用者要曾經直接訪問過該網域，並且寫入過 1st-party cookie，之後該網域才能對 3rd-party cookie 做存取，而這項限制也延伸到 Storage Access API 這邊，一樣要先作為 1st-party 寫入過 cookie，之後才能夠透過 Storage Access API 取得 1st-party cookie 的存取權限，Apple 負責 ITP 的 John Wilander 最近正在寫相關的文件，裡面就有提到，然後這個限制 Firefox 也有，不過 Firefox 似乎是 30 天內有訪問過該網域就可以。
寫到這邊，其實有件事情忘記先提，就是網路上你去搜尋 Safari 3rd Party Cookie 會找到一些方法說可以成功讀寫 3rd-party cookie 的，那些全部都已經失效了，而且不只是 cookie，所有可以寫入的東西像是 DOM Storage 也是有受到一樣的限制保護的（然後 Storage Access API 現在只能拿到 cookie 的權限），目前也沒有出現其它的繞過方式，而且就算有人找到，Apple 都會修掉的，所以如果有這需求還是趕快用 Storage Access API 實做吧（別忘了 feature detection）。
然後或許有人會覺得 ITP 沒檔到 Google Analytic 好像沒什麼意義，其實 John Wilander 早在 2017 年就有在 WebAppSec 稍微提過 Single Trust 這件事，提的就是網頁內掛的 3rd-party script 其實是安全性隱憂，應該只有同 domain 的東西可以信任，在 cookie 這邊來說就是 3rd-party script 不應該有存取網站 1st-party cookie 的權限（不過後來發生的是某航空公司的信用卡資訊輸入頁面放的第三方 script 會做 key log），如果真的進行，這個改變可以想像的到影響非常的巨大，舉例來說，以前的 Performance Practice 其中一項是把 static file 放到 CDN 並且用不同 domain host，但是這樣其實就會被當成是 3rd-party script 了，雖然他在我們的認知下是可信任的，然後目前也有非常大量的現存網站是這樣做。目前 Apple 也有在做一些相關的研究，其中一個已經廣為人知(?)的就是 Safari 現在有在紀錄 3rd-party script 的數量，另外就是我之前在 SameSite Cookie 這篇文章有提到的，Mike West 起草的 First-Party Sets，透過/.well-known/下的檔案定義可以被認為是 1st-party 的 domain 清單，假設未來真的要做到 single trust 的程度，要處理 CDN 之類的問題，像是 First-Party Sets 的機制就不可少。
最後附上一些延伸的參考資料：