“目前網路協定走的是 Same-origin policy，兩個網頁 scheme, hostname, port 都相同，就算 same-origin，彼此可以存取資源 (例如圖片、CSS、JS)。”

再來看 same-site。首先我們要知道，網址有一個 Top-level domain (TLD)，.com, .tw 都算 TLD，所有的 TLD 定義在 Root Zone Database。但是後來又有問題，.co.jp, .github.io 這些不算 TLD 阿，但實際網址會使用這些後綴，所以後來又出了一個 effective TLD (eTLD)。.co.jp, .github.io 這些就是屬於 eTLD。

eTLD+1 指的則是網址的 TLD，和 TLD 前的部分。例如 my-project.github.io，eTLD 是 github.io，eTLD+1 則是 my-project.github.io。

只要 eTLD+1 相同的兩個網頁就算 same-site，不用管 scheme 同不同，不用管 port 同不同，不用管 sub-domain 同不同，只要 eTLD+1 相同就算 same-site。

https://web.dev/schemeful-samesite/
後來為了更好的安全性，尤其 same-site 的判斷跟 cookie 是否能發送有關，又出了一個 schemeful same-site。其中 scheme 會納入考量，即使網址完全相同，HTTP / HTTPS 視為 cross-site。

但必須提醒讀者，schemeful same-site 還算是新東西 (目前是 2021 年 8 月)，每種瀏覽器，每個瀏覽器版本行為可能不同。但大趨勢應該是往這方向走。

上方連結有特別舉例，http://site.example, https://site.example 兩站互相站外連結。兩站本來算 same-site，SameSite=Strict cookie 可被送回。但如果用 schemeful same-site 規則，兩站算 corss-site，SameSite=Strict cookie 不會被送回。但因為是簡單站外連結，SameSite=Lax cookie 仍可以送回。

如果 http://site.example 中嵌入 https://site.example 的圖片。兩站本來算 same-site，SameSite=Strict cookie 可被送回。但如果用 schemeful same-site 規則，兩站算 corss-site，SameSite=Strict cookie 不會被送回。SameSite=Lax 嵌入資源的情況，cookie 也不會被送回。

SameSite=Strict, Lax, None;Secure 行為上的不同，請參考之前的文章 Chrome 80 開始更新 SameSite 規則，預設禁止存取第三方 cookie

要知道一個 request 到底屬於哪一種，檢查它的 HTTP header Sec-Fetch-Site。它有四種值：1) cross-site, 2) same-site, 3) same-origin, 4) none

文件有說 Sec-Fetch-Site 不包含 schemeful same-site，所以 Sec-Fetch-Site 的 same-site 應該是不看 scheme 的。再來，因為 same-origin 的條件是 scheme, hostname, port 都要相同，比 same-site 還嚴謹，所以如果是 same-origin 的話資源、cookie 傳輸都沒問題。

結論

現代網站一定要使用 HTTPS，不使用的話從安全性到 SEO，各個角度來講都不行。如果使用 HTTPS 是前提的話，倒是不用糾結 schemeful same-site。

至於 cookie 的傳輸，Google 已宣布長期的方向是完全不支援第三方 cookie，SameSite=None;Secure 只是一個暫時的解法。

本篇走了一遍 same-site 的來龍去脈，因為 same-site 的定義以及 cookie 傳輸的協定，將來還會再改。我們要知道的是脈絡，而不是死背現在的規格。

前幾天 Google Webmaster blog 有一篇文章，再次公告 Chrome 80 (有可能是 2020 二月) 開始預設禁止存取第三方 cookie.
https://webmasters.googleblog.com/2020/01/get-ready-for-new-samesitenone-secure.html

Chrome plans to implement the new model with Chrome 80 in February 2020.

這個 new model 指的就是 cookie 的使用規範。larry 看問題喜歡看問題的本質，什麼叫 cookie, 什麼叫「第三方」cookie, 又為什麼第三方 cookie 有可能的安全性問題？

我們來看 web dev 這篇好文 https://web.dev/samesite-cookies-explained/

什麼叫 cookie?

cookie 就是一筆一筆的資料，由網站或嵌入網站的服務存入用戶的瀏覽器。例如你到 CNN 看新聞，www.cnn.com 就會存幾筆 cookie 到你的瀏覽器，有可能是記錄你的登入登出狀態，瀏覽紀錄等等。嵌入網站的服務大家最熟悉的就是 GA (Google Analytics), GA 一樣是發 cookie 到使用者的瀏覽器，它才能區別你第一次來逛網站，和第二次來逛網站是同一個人 (正確來講是同一個瀏覽器。)

上面 web dev 文章提供一個範例，例如你逛一個購物網站，該網站會發一筆 cookie 給你 (存在你的瀏覽器)

Set-Cookie: promo_shown=1; Max-Age=2600000; Secure

promo_shown=1 是客製化資料 (下次來這個購物網站時跳出促銷訊息)，Max-Age=2600000 指的是 2600000 秒後 (約一個月) 這筆 cookie 會自動失效，Secure 指的是存取這 cookie 需要 https 連線。

當你下次來這個購物網站時瀏覽器會自動送出給該購物網站，所以它知道要跳出促銷訊息

Cookie: promo_shown=1

因為每個網站「不知道」現在連線的是誰，是登入還是登出，用 cookie 可以紀錄使用者狀態，達到好的使用體驗 (例如臉書不用開一個分頁就要登入一次)。

什麼叫「第三方」cookie

網站叫第一方 (瀏覽器網址列顯示的網址叫第一方)，使用者叫第二方，第一方網站嵌入的 code 叫第三方。大家最熟悉的第三方例子就是 GA (Google Analytics), 有一些網站會嵌入臉書的 code, 也是第三方。

為什麼第三方 cookie 有可能的安全性問題

還記得上方跳促銷訊息的例子，當你回到網站，或是再次觸發第三方服務時 (例如 GA)，你瀏覽器會自動送出第一方網站發的 cookie 給第一方網站，第三方發的 cookie 給第三方。

上方 web dev 文章提到，例如網站A 嵌了一個網站B 的圖檔進來，此時網站A 就是第一方，網站B 就是第三方。當你開啟網站A，屬於網站B 的 cookie 也會送給網站B。那如果網站A 是一個惡意網站呢？它不停的用程式去 run 網站B 的連結，照目前的機制，瀏覽器上的 cookie 也會拼命的送給網站B (此時網站B 就算是被攻擊)。網站A 只是一個例子，網路上有無窮無盡的網站有可能是惡意的，網站B 是不是處於風險之中。

了解什麼叫 cookie, 什麼叫第三方 cookie, 又為什麼第三方 cookie 有可能的安全性問題後，我們來看目前 cookie 分為三類

• SameSite=Strict. 此類 cookie 當使用者瀏覽器網址列的網址，等於 cookie 的發行者時 (精確來講是符合 same-site 規則)，cookie 才會被送回去。上述網站A嵌入網站B的圖檔的例子，如果網站B發的 cookie 是 Strict, 使用者開啟網站A 時，屬於網站B 的 cookie 「不會」被送回。
• SameSite=Lax. 在 SameSite=Strict 之外，允許某些低風險的 cross-site cookie。例如點一個外部連結，HTTP method GET 等，可以允許 cross-site cookie 送回。一般來說是網頁會跳轉的情況，但不包含嵌入外部資源。
• SameSite=None. 不看 same-site 或 cross-site，不管哪種 HTTP method，一律送回 cookie。有潜在安全性的問題。也是目前大部分瀏覽器的現狀。

以下是 web dev 文章附的 sample cookie, 有 sample 看起來會比較有感覺

Set-Cookie: promo_shown=1; SameSite=Strict

Set-Cookie: promo_shown=1; SameSite=Lax

Set-Cookie: widget_session=abc123; SameSite=None; Secure

那 Chrome 80 要怎麼改？

1. 如果 cookie 發行者「沒有」指定 SameSite (Strict, Lax, None), 預設為 Lax.
2. 如果 cookie 發行者指定 SameSite=None, 一定要加 Secure, 如上方 sample. Secure 指的是一定要是 https 連線。

那 GA 等第三方服務有沒有影響？

照以上結論，往後第三方服務發行商一定要把自己發的 cookie 加上 SameSite=None, Secure. GA 發的 cookie 由 GA team 來負責，Google Ads 發的 cookie 由 Google Ads team 來負責。我相信 Google 自己出的第三方服務 (GA, Google Ads, 等) 早已準備好了。有影響的是第三方服務發行商，例如智能推薦系統，廣告系統，這些廠商要去確認自己發的 cookie.