沒有令人毛骨悚然的 Cookie

Cookie 最新鮮的風格，哪些最新食譜可確保即使沒有過時的餅乾，也能繼續享受恐怖節日的樂趣。

Cookie 是最新鮮的，所以有什麼最新食譜能確保在沒有過時 Cookie 的情況下，仍能享受充滿詭譎氣氛的節慶？

我們正逐步在網路平台上淘汰第三方 Cookie。這是跨網站追蹤處理的重要里程碑，但這是相當漫長的旅程的一部分。讓我們看看目前的進度及未來有哪些建議...

在介面上，Cookie 是可在瀏覽器和伺服器之間傳送的簡易鍵/值存放區。這樣做就能在網站上提供實用的功能，例如儲存偏好設定 theme=bats 或儲存已登入使用者的工作階段 ID。

帶有一個簡單值 (如 theme=bats 或 fav_pumpkins=us-nyc) 的第三方 Cookie

如果該 Cookie 也用於設定該 Cookie 的網站，我們通常會稱之為第一方 Cookie。如果與設定網站不同時採用，就稱為第三方 Cookie。舉例來說，假設我造訪的 theme=bats Cookie 是屬於第一方 Cookie 的網站，但如果我造訪該網站的 iframe 或其他跨網站資源，則會成為第三方 Cookie。

第三方 Cookie 的問題在於，他們可以啟用跨網站追蹤。共用服務可能會將整個 ID 儲存在其中，而非主題設定。當您瀏覽包含共用服務 Cookie 的不同網站時，系統就會傳送相同的 ID，這表示某項服務可以觀察和連結您在這些網站上的活動。

第三方 Cookie 會使用專屬 ID，可讓第三方網站追蹤使用者在網路上的活動

預設第一方 Cookie

我們已經在這趟旅程取得進展！過去就是設定純 Cookie：theme=pumpkins 會在所有內容 (相同網站或跨網站) 中傳送！大多數網站都只想讓系統在同一網站環境中傳送 Cookie。這項設定可透過 Cookie 上的 SameSite 屬性控制。例如：

Set-Cookie: theme=bats; SameSite=Lax

這樣會指示瀏覽器只在資源與頂層網站相符時傳送 Cookie。但這表示網站必須在想要第一方 Cookie 時指定。這樣在安全性方面有點反過，因為當您想取得更多權限時，不只是預設取得權限而已。

因此，現在 SameSite=Lax 是預設值。如果您才剛設定 theme=bats，則只會在相同網站環境中傳送。

預設的 SameSite=Lax 值會停止在第三方內容中傳送 Cookie

若要使用跨網站或第三方 Cookie (可能需要顯示在嵌入式小工具中的主題)，則必須指定：

Set-Cookie: theme=bats; SameSite=None; Secure
明確的 SameSite=None 值會標示要在跨網站結構定義中傳送的 Cookie

這會讓瀏覽器知道您希望 Cookie 在任何跨網站環境中傳送，但我們想限制只有安全連線。

甚至適合使用第一方 Cookie

儘管預設值變得更加好，但您仍然有足夠空間改善該食譜。範例如下：

Set-Cookie:  __Host-theme=bats;
  Secure;
  Path=/;
  HttpOnly;
  Max-Age=7776000;
  SameSite=Lax;

這樣可確保您取得的第一方 Cookie 僅限於單一網域、安全連線、禁止 JavaScript 存取、在網頁過時前自動到期，並且 (當然！) 只能在相同網站環境中使用。

CHIPS 讓餅乾更美味！

網路的其中一項神奇之處，就是能整合多個網站。假設我想建立地圖小工具，讓其他網站顯示最佳南瓜園導覽或「不給糖就搗蛋」路線。我的服務會使用 Cookie，讓使用者儲存路線沿途的進度。問題是，同一個第三方 Cookie 會傳送到「誘騙」網站我不想追蹤網站之間的使用者，但瀏覽器只會使用一個 Cookie jar，因此無法區分這些使用！

含有 SameSite=None 的跨網站 Cookie 仍會歸入共用 Cookie jar

此時，提案便可派上用場，具有獨立分區狀態 (CHIPS) 的 Cookie。我的頂層網站會有一個獨立且分區的 Cookie jar，而不是一個共用 Cookie jar。網站會在 Cookie 上使用 Partitioned 屬性選擇加入此功能。

Set-Cookie: __Host-route=123;
  SameSite=None;
  Secure;
  Path=/;
  Partitioned;
Cookie 的分區屬性會為每個頂層網站建立個別的 Cookie jar

每個人都能取得個人專屬的餅乾，不必再分享 Cookie！更簡單、更安全、衛生。

我們已在 Chrome 109 版中，將具有獨立分區狀態 (CHIPS) 的意圖傳送至。也就是說，這類 Cookie 會在 12 月推出 Beta 版測試，並在 2023 年 1 月推出穩定版。因此，如果您想找出新年的希望來改善網站的 Cookie 方案，不妨看看您是否能開始將 CHIPS 納入跨網站 Cookie 之中！

透過第一方集合邀請 Cookie 加入派對

從開發人員的意見回饋中，許多人也明確表示在某些情況下，您會在自己管理的各網站之間共用服務，而且希望跨網站使用 Cookie，但不得允許透過真正的第三方內容傳送 Cookie。例如，假設您有 pretty-pumpkins.com 和 pretty-pumpkins.co.uk。您可能有可在這些網站上使用的 Cookie 式單一登入系統。CHIPS 就無法運作，因為我只需要在兩個網站皆登入，而且我需要兩個相關網站使用相同的 Cookie。

我們正努力製作第一方集合提案，希望能達成這個目標。 我們經歷了一次來源試用，並參與了許多社群討論，最新版本為：

  • 讓機構定義一組應彼此相同的網站。
  • 使用 Storage Access API 要求存取第一方集合內的跨網站 Cookie。
第一方集合僅允許相關網站之間共用 Cookie jar

這些 Cookie 還是會在烤箱中烘焙，但當您有更多測試需要時，可以查看第一方集合開發人員指南；如果您想參與討論，也可以直接參加「WICG/第一方集合」提案。

別讓 Cookie 過期了！

我們的目標是從 2024 年中開始逐步停止支援 Chrome 的第三方 Cookie。雖有準備時間，但建議你立即開始規劃。

  1. 透過 SameSite=None 稽核程式碼是否有 Cookie。這些 Cookie 需要更新
  2. 如果您沒有任何第三方 Cookie，請確認相同網站 Cookie 採用最佳的第一方 Cookie 方案
  3. 如果您在完全包含的情境中使用這些 Cookie，請調查並測試 CHIPS 提案。
  4. 如果需要跨多個網站使用這些 Cookie，使網站組成一個共通群組，請查看第一方集合提案。
  5. 如果上述方法不適用，您需要調查其他 Privacy Sandbox 提案。在這些提案中，您需要針對不需要跨網站追蹤的個別用途開發專用 API。

這只是簡短的總覽，隨著工作進行，我們會持續分享更多最新消息和指引。如果你有任何疑問、問題，或想要分享自己的工作結果，我們有許多路線可協助您聯絡。

因此，請謹記：Cookie 可能很美味，但一次只能處理幾次，而且絕對不會試圖竊取他人！