第三方 cookie
本文解釋了什麼是第三方 Cookie，描述了與之相關的問題，並說明了如何解決這些問題。
什麼是第三方 Cookie？
Cookie 與特定域名和方案（通常是 https）相關聯，如果設定了 Set-Cookie Domain 屬性，則可能也與子域名相關聯。
- 如果 Cookie 域名和方案與使用者當前正在檢視的頁面（瀏覽器位址列中顯示的 URL）匹配，則該 Cookie 被視為與頁面來自同一站點，並被稱為第一方 Cookie。
- 如果域名和方案不同，則該 Cookie 不被視為來自同一站點，並被稱為第三方 Cookie。
注意：第三方 Cookie 有時被稱為跨站點 Cookie。這可以說是一個更準確的名稱，因為第三方 Cookie 暗示由第三方公司或組織擁有。然而，無論您是否擁有所有相關站點，行為和潛在問題都是相同的。例如，一個站點可能會從其擁有的不同域訪問資源，例如影像。
當用戶首次訪問頁面、點選同一站點上的內部連結到另一個頁面，或請求駐留在同一站點上的資源（例如，嵌入的影像、網路字型或 JavaScript 檔案）時，可能會設定第一方 Cookie。
第三方 Cookie 在以下常見情況下發送：
- 當在一個站點上點選連結導航到另一個站點時。
- 當頁面嵌入來自其他站點的元件時，例如嵌入在
<iframe>中的影像或其他文件（通常被稱為第三方內容）。除了對元件的原始請求外，這些元件可能會生成進一步的請求，從而設定更多第三方 Cookie。
第三方 Cookie 有何用途？
點選連結到其他站點時設定的第三方 Cookie 用於各種目的。例如，您可能有一個指向合作站點的聯盟連結，並在使用者點選連結時設定一個 Cookie，以便在購買特定產品時顯示獎勵橫幅折扣，或向推薦人支付佣金。
設定 Cookie 的第三方內容也有許多不同的用途。例如，您可能在多個不同但相關的站點上嵌入了一個登入小部件，該小部件在所有站點之間共享一個 Cookie，確認使用者已登入，這樣他們就不必在每個站點上再次登入。
第三方 Cookie 的其他用例包括：
- 在多個站點之間共享使用者偏好或主題資訊。
- 在多個站點之間收集分析資料。
- 計算廣告展示次數，並記錄使用者興趣，以便廣告技術平臺能夠提供更相關的廣告。
讓我們透過一個虛構的公司進一步說明上面提到的登入小部件示例，該公司為其線上商店 (shop.site)、社群討論論壇 (forum.site) 以及客戶服務和退貨 (service.site) 擁有獨立的域名。
這三個站點都有一個嵌入的登入小部件，託管在 auth.site 上，用於在站點之間保持登入狀態。使用者可以登入到其中任何一個站點，從而為 auth.site 在瀏覽器中建立一個包含會話 ID 的 Cookie。當用戶訪問其他站點之一時，嵌入的 auth.site 例項將有權訪問使用者在第一個站點登入時設定的會話 ID Cookie。它可以將其傳送到伺服器，檢查它是否仍然有效，並立即登入到該站點。
第三方 Cookie 有何問題？
上述用例聽起來足夠無害。然而，第三方 Cookie 也可能在未經使用者同意的情況下用於非法目的，這在技術上與有效用例無法區分。
點選連結到第三方或與嵌入在 <iframe> 中的第三方內容進行互動（例如，填寫表單或點選按鈕）可能會導致設定 Cookie，從而將使用者的個人資訊交給他們不期望的人。這些資訊可用於：
- 當用戶搜尋特定產品的資訊時，透過定向廣告在網路上追蹤使用者。
- 向用戶傳送垃圾郵件或電話。
- 操縱他們的行為，選擇某些選項以增加聯盟收入或操縱統計資料。
單獨來看，這些情況已經足夠糟糕，但情況還會變得更糟。第三方伺服器可以結合來自嵌入第三方內容的各種站點上的多個第三方 Cookie 的資訊，建立使用者瀏覽歷史、興趣、習慣和個人資訊的詳細檔案。這可能導致令人毛骨悚然、侵入性的使用者體驗，欺詐使用者，甚至身份盜竊。
在這種情況下，第三方 Cookie 被稱為跟蹤 Cookie。
注意：透過非法手段獲取的使用者資訊也常常出售給其他第三方，進一步加劇了問題。
歐盟的通用資料隱私條例 (GDPR) 和加州消費者隱私法 (CCPA) 等立法透過規定公司必須透明地公開其設定的 Cookie 和收集的資訊，從而有所幫助。例如，要求客戶選擇加入此類資料收集，允許他們檢視公司持有的資料，並根據需要刪除資料。然而，客戶仍然不總是清楚他們的資料是如何使用的。
瀏覽器如何處理第三方 Cookie？
瀏覽器供應商知道使用者不喜歡上述行為，因此都開始預設阻止第三方 Cookie，同時也在其原始碼中包含例外和啟發式演算法，以解決流行網站長期存在的第三方 Cookie 問題。
- 如果啟用了增強跟蹤保護（預設情況下已啟用），Firefox 會啟用全面 Cookie 保護。這為第三方 Cookie 提供了每個站點獨立的 Cookie 罐，從而防止了跨站點跟蹤。
- Safari 也有類似的跟蹤預防策略；遵循此策略導致了一系列類似的預設啟用的第三方 Cookie 保護措施；有關詳細資訊，請參閱智慧跟蹤預防 (ITP)。
- 在撰寫本文時，Google Chrome 預設只在隱身模式下阻止第三方 Cookie，儘管使用者可以透過
chrome://settings根據需要將其設定為始終阻止第三方 Cookie。Google 已開始為有限比例的 Chrome 使用者停用第三方 Cookie，以測試其影響，同時開發無需第三方 Cookie 即可實現關鍵用例的技術。有關詳細資訊，請參閱替換第三方 Cookie。 - Edge 預設阻止來自未訪問站點的跟蹤器，並阻止已知有害的跟蹤器。在撰寫本文時，微軟也開始探索預設在 Edge 中阻止第三方 Cookie。有關更多資訊，請參閱跟蹤預防。
- Brave 瀏覽器預設阻止跟蹤 Cookie。
可以透過瀏覽器設定在 Firefox 中逐案允許使用第三方 Cookie。然而，在 Safari 中，控制更為有限——您可以關閉跨站點跟蹤預防，但只能透過 Storage Access API 在程式碼級別允許訪問每個框架的第三方 Cookie。
注意：第三方 Cookie（或僅跟蹤 Cookie）也可能被瀏覽器擴充套件阻止。
Cookie 阻止可能會導致某些第三方元件（例如社交媒體小部件）無法按預期執行。隨著瀏覽器對第三方 Cookie 施加進一步的限制，開發人員應該開始尋找減少對其依賴的方法：請參閱替換第三方 Cookie。
使用第三方 Cookie
使用 SameSite 啟用第三方 Cookie
SameSite 屬性允許伺服器指定是否/何時傳送第三方 Cookie。如果您在 Set-Cookie 頭部中不指定 SameSite，則使用預設值 Lax。這指示瀏覽器不要傳送第三方 Cookie，除非使用者從不同站點導航到 Cookie 的源站點。當您希望使用者從其他站點導航到您的站點後立即傳送 Cookie 時，這很有用，例如，在他們到達後立即個性化體驗。
然而，如果您想在 <iframe> 中嵌入跨站點內容並在功能上依賴第三方 Cookie（例如，在我們上面看到的登入示例中），這就不太合適了。在這種情況下，您需要明確設定 SameSite=None 以允許瀏覽器傳遞這些 Cookie。
Set-Cookie: widget_session=7yjgj57e4n3d; SameSite=None; Secure; HttpOnly
請注意，如果設定了 SameSite=None，則還必須設定 Secure 屬性 — SameSite=None 需要安全上下文。在上面的示例中，我們還設定了 HttpOnly 屬性，以停用 JavaScript 對 Cookie 的訪問（例如，透過 Document.cookie）。儲存敏感資訊的 Cookie 應始終設定 HttpOnly 屬性 — 將它們暴露給 JavaScript 是非常不安全的。此預防措施有助於緩解跨站點指令碼 (XSS) 攻擊。
注意：用於敏感資訊的 Cookie 也應具有較短的生命週期。
從第三方 Cookie 過渡
有多種策略可以幫助網站最大限度地減少瀏覽器阻止第三方 Cookie 時造成的損壞：
- 審計您的第三方 Cookie 使用情況。Cookie 必須設定
SameSite=None屬性才能在跨站點上下文中使用。因此，您可以透過在程式碼中搜索SameSite=None，或在瀏覽器開發者工具中檢查儲存的SameSite=NoneCookie（例如，在 Firefox 儲存檢查器中）來識別第三方 Cookie。Chrome 的問題面板也報告第三方 Cookie 阻止問題以及受影響的 Cookie 列表。 - 在阻止第三方 Cookie 的情況下測試您的功能，看看哪些會中斷。您可能會發現某些 Cookie 不再需要。
- 至少在開始階段，您可以讓您的程式碼更具彈性，以便在第三方 Cookie 資料不可用時提供不太個性化的體驗，而不是完全中斷。遵循優雅降級的原則。
- 透過替代方式（例如使用者調查或測驗）收集資料，或檢視您已有的資料以推斷趨勢（例如，產品訂單歷史記錄）。
- 使用替代的客戶端儲存機制（例如 Web 儲存）來持久化資料，或考慮伺服器端解決方案。
- 如果您的第三方 Cookie 僅用於少數相關的已知網站，您可以使用 Storage Access API 和/或 Related Website Sets 僅允許這些特定站點進行跨站點 Cookie 訪問。Storage Access 會提示使用者允許站點按幀使用第三方 Cookie。
- 如果您已經為 Firefox 或 Safari 實現了使用 Storage Access API 的解決方案，那麼現在是根據 Chrome 的行為檢查您的實現的好時機，Chrome 的行為已更新以在版本 119 中提供全面支援。
- 相關網站集可以被認為是 Storage Access API 的漸進增強：API 可以以同樣的方式使用，但集合中的網站不會提示使用者允許訪問第三方 Cookie。
- 如果您的第三方 Cookie 以 1:1 的方式與生成它們的頂級站點一起使用，您可以使用具有獨立分割槽狀態的 Cookie (CHIPS，也稱為可選分割槽 Cookie) 來選擇將您的 Cookie 儲存在分割槽儲存中，每個頂級站點一個獨立的 Cookie 罐。這隻需要在您現有的跨站點 Cookie 中新增
partitioned屬性。然後它們可以不受限制地使用，但不能與其他站點共享。
替換第三方 Cookie
開發人員可以使用多種功能，以停止使用第三方 Cookie，尊重使用者隱私並最大限度地減少跟蹤，同時繼續實現相關用例。其中一些功能處於早期實驗階段，但隨著您開始為未來做準備，它們值得考慮。
您可以開始探索 Google 隱私沙盒專案中的不同功能，看看它們是否適合您的用例（這些功能目前是實驗性的，僅限於 Chromium）：
- 聯合身份管理 (FedCM) API：啟用聯合身份服務，允許使用者登入多個站點和服務。
- 私有狀態令牌：透過在站點之間交換有限的非識別資訊來啟用反欺詐和反垃圾郵件。
- 主題 API：啟用基於興趣的廣告和內容個性化。
- Protected Audience API：當用戶訪問其他應用或站點時，使用來自一個應用或站點的資料來幫助選擇廣告。
- 歸因報告 API：啟用廣告展示和轉化的衡量。