第三方 Cookie 結尾的準備

如果您的網站使用第三方 Cookie,請在淘汰第三方 Cookie 的同時採取行動。為協助進行測試,自 2024 年 1 月 4 日起,Chrome 已限制 1% 使用者使用第三方 Cookie。自 2024 年第 3 季起,Chrome 計劃逐步向 100% 的使用者提供更多第三方 Cookie 限制,以解決英國競爭與市場管理局的其他競爭疑慮。

Privacy Sandbox 的目標是減少跨網站追蹤,同時確保所有使用者都能免費使用線上內容和服務。淘汰和移除第三方 Cookie 可以滿足一大難題,因為這類 Cookie 提供登入、詐騙防護和廣告等重要功能,還能在網站上嵌入豐富的第三方內容,但也是跨網站追蹤的重要推手。

在先前的重要里程碑中,我們推出一系列 API,為保護身分、廣告及詐欺偵測等用途提供因應現況的 API。現在有了替代方案,我們就可以開始逐步淘汰第三方 Cookie。

在本系列的《Cookie 倒數計時》系列中,我們會逐步說明時程,以及您可以立即採取的行動,以確保您的網站做好準備。

1% 淘汰第三方 Cookie,並由 Chrome 協助測試

privacysandbox.com 發布時程中,您可以查看 2023 年第 4 季和 2024 年第 1 季的兩個里程碑,這是 Chrome 協助測試模式的一部分。這項測試主要是協助測試 Privacy Sandbox 關聯性和評估 API 的機構,但我們將為 1% 的 Chrome 穩定版停用第三方 Cookie。

第三方 Cookie 淘汰時間表。根據 Chrome 協助進行的測試,我們將自 2023 年第 4 季展開加入標籤模式的測試,並從 2024 年 1 月 4 日起淘汰 1% 的 3PC 淘汰模式。兩種做法都會持續到 2024 年第 3 季中,屆時第三方 Cookie 將逐步淘汰。

這表示自 2024 年初起,即使你未積極參與 Chrome 促成的測試,網站的 Chrome 使用者仍可能在停用第三方 Cookie 的情況下增加。這段測試期會持續到 2024 年第 3 季,屆時在與 CMA 協商並解決任何競爭疑慮後,我們打算開始為所有 Chrome 使用者停用第三方 Cookie。

我們將整個程序細分為重要步驟 (詳情如下),確保您的網站在沒有第三方 Cookie 的情況下順利執行:

  1. 稽核第三方 Cookie 使用情形
  2. 測試故障
  3. 如果是針對個別網站儲存資料的跨網站 Cookie (例如嵌入項目),請考慮使用 Partitioned 搭配 CHIPS
  4. 如果是一小群有意義的連結網站中的跨網站 Cookie,建議您使用相關網站集
  5. 如果是其他第三方 Cookie 用途,請遷移至相關的網路 API

1. 稽核第三方 Cookie 使用情形

第三方 Cookie 可以用各自的 SameSite=None 值識別。您應該搜尋程式碼,尋找將 SameSite 屬性設為這個值的執行個體。如果您先前在 2020 年左右曾將 SameSite=None 新增至 Cookie,建議您採用這些變更,這或許是很好的起點。

Chrome 開發人員工具

Chrome 開發人員工具「Network」面板會顯示設定並在收到要求時傳送的 Cookie。在「應用程式」面板中,您可以在「儲存空間」底下看到「Cookie」標題。對於網頁載入期間,您可以瀏覽每個網站所儲存的 Cookie。你可以依 SameSite 欄排序,將所有 None Cookie 分組。

「開發人員工具」分頁會顯示「SameSite=None Cookie」的警告。

在 Chrome 118 版中,開發人員工具分頁會顯示破壞性變更問題:「未來的 Chrome 版本將封鎖跨網站結構定義傳送的 Cookie」。問題會列出目前網頁可能受影響的 Cookie。

Privacy Sandbox 分析工具 (PSAT)

此外,我們也打造了 Privacy Sandbox 分析工具 (PSAT),這項 DevTools 擴充功能可在瀏覽工作階段期間分析 Cookie 使用情形。此做法提供了 Cookie 和 Privacy Sandbox 功能的偵錯途徑,並介紹深入瞭解 Privacy Sandbox 計畫的存取點。

「開發人員工具」分頁會顯示「SameSite=None Cookie」的警告。

這項擴充功能可與開發人員工具搭配使用,針對淘汰第三方 Cookie 和採用新的隱私權保護替代方案,分析及偵錯相關情境。

您可以前往 Chrome 線上應用程式商店下載這個擴充功能,或是存取 PSAT 存放區和維基

使用 Cookie 檢查第三方

如果您發現第三方設定的 Cookie,請聯絡相關供應商,確認對方是否制定了逐步淘汰第三方 Cookie 的計畫。例如,您可能需要升級您使用的程式庫版本、變更服務中的設定選項,或者如果第三方自行處理必要變更,則不採取任何行動。

2. 測試損壞

你可以使用 --test-third-party-cookie-phaseout 指令列旗標啟動 Chrome,或是在 Chrome 118 中啟用 chrome://flags/#test-third-party-cookie-phaseout。這項設定會讓 Chrome 封鎖第三方 Cookie,並確保新功能和緩解措施已啟用,以便充分模擬逐步停用後的狀態。

你也可以試著使用透過 chrome://settings/cookies 封鎖的第三方 Cookie 進行瀏覽,但請注意,這個旗標可確保系統一併啟用新的和更新功能。封鎖第三方 Cookie 有助於偵測問題,但不一定能確認問題是否已修正。

如果您為網站維護一個有效的測試套件,則應執行兩個並排執行:一個執行一般設定的 Chrome 測試,另一個則使用 --test-third-party-cookie-phaseout 旗標啟動的相同 Chrome 版本。在第二次執行時,如果測試失敗 (以及第一個測試失敗),建議檢查第三方 Cookie 依附元件。請務必回報您發現的問題

找出有問題的 Cookie 並瞭解其用途後,您可以透過下列選項挑選必要的解決方法。

3. 將 Partitioned Cookie 與 CHIPS 搭配使用

如果您在頂層網站的 1:1 內嵌環境中使用第三方 Cookie,不妨考慮將 Partitioned 屬性用於具有獨立分區狀態 (CHIPS) 的 Cookie,以便透過每個網站使用的不同 Cookie 進行跨網站存取。

分區屬性可讓系統為每個頂層網站設定獨立的 fav_store Cookie。

如要導入 CHIPS,請在 Set-Cookie 標頭中加入 Partitioned 屬性:

設定 Partitioned 後,網站會選擇將 Cookie 儲存在依頂層網站劃分的個別 Cookie jar 中。在上述範例中,Cookie 來自 store-finder.site,代管了商店地圖,讓使用者儲存喜愛的商店。使用 CHIPS 時,當 brand-a.site 嵌入 store-finder.site 時,fav_store Cookie 的值為 123。接著,當 brand-b.site 也嵌入 store-finder.site 時,便會設定並傳送專屬的 fav_store Cookie 分區例項,例如值為 456

這表示嵌入的服務仍可儲存狀態,但沒有共用跨網站儲存空間來進行跨網站追蹤。

可能的用途:第三方即時通訊嵌入、第三方地圖嵌入、第三方付款嵌入、子資源 CDN 負載平衡、無頭 CMS 供應商、用來提供不受信任使用者內容的沙箱網域、使用 Cookie 進行存取權控管的第三方 CDN、需要請求 Cookie 的第三方 API 呼叫、依發布商設定狀態的內嵌廣告。

進一步瞭解 CHIPS

4. 使用 Storage Access API 和相關網站集

如果您的第三方 Cookie 只用於一小部分的相關網站,不妨使用「相關網站集」(RWS),在已定義網站的情境下,允許該 Cookie 跨網站存取。

如要導入 RWS,你必須為網站組合定義並提交一組網站。為確保網站之間有實質關聯,有效組合的政策需要按照彼此關聯的明顯關聯網站分組 (例如公司提供的產品子類)、服務網域 (例如 API、CDN) 或國家/地區代碼網域 (例如 *.uk、*.jp)。

相關網站集可讓您在已聲明網站的結構定義 (但不得跨第三方網站) 存取 Cookie。

網站可以使用 Storage Access API 透過 requestStorageAccess() 要求跨網站 Cookie 存取權,或是使用 requestStorageAccessFor() 委派存取權。如果網站屬於同一個組合,瀏覽器將自動授予存取權,且使用者仍可使用跨網站 Cookie。

也就是說,在少數情況下,相關網站群組仍可使用跨網站 Cookie,但不得透過允許跨網站追蹤的方式,跨不相關的網站共用第三方 Cookie。

可能的用途:應用程式專屬網域、品牌專屬網域、國家/地區專屬網域、用來提供不受信任使用者內容的沙箱網域、API 的服務網域、CDN。

進一步瞭解 RWS

5. 遷移至相關的網路 API

CHIPS 和 RWS 可以實現特定類型的跨網站 Cookie 存取,同時保留使用者隱私,但第三方 Cookie 的其他用途必須改用以隱私權為重的替代方案。

Privacy Sandbox 提供一系列專為特定用途所設計的 API,不需要使用第三方 Cookie:

此外,Chrome 支援 Storage Access API (SAA),以便在有使用者互動的 iframe 中使用。Edge、Firefox 和 Safari 已支援 SAA。我們認為在維護使用者隱私的同時,還能兼顧跨網站相容性,而具備理想的跨網站功能。

請注意,Storage Access API 會向使用者顯示瀏覽器權限提示。為提供最佳的使用者體驗,只有在呼叫 requestStorageAccess() 的網站與內嵌網頁互動,並且先前已在頂層結構定義中造訪第三方網站時,我們才會提示使用者。授權成功後,該網站的跨網站 Cookie 存取期限為 30 天。這些可能的用途都是經過驗證的跨網站嵌入,例如社群網路留言小工具、付款服務供應商、訂閱的影片服務。

如果您仍有這些選項未涵蓋的第三方 Cookie 用途,請向我們回報問題,並考慮是否有其他導入方式不仰賴支援跨網站追蹤功能的功能。

企業支援

與一般網路使用情形相比,企業管理的 Chrome 在各方面都具有獨特需求,我們也會確保企業系統管理員能適當地控管瀏覽器淘汰第三方 Cookie 的相關事宜。

與大多數 Chrome 實驗功能一樣,第三方 Cookie 淘汰後,大多數企業使用者都將自動排除這些使用者。針對部分可能受到影響的部分,企業管理員可以將 BlockThirdPartyCookies 政策設為 false,在實驗開始前就選擇不採用受管理的瀏覽器,並預留時間進行必要變更,停止仰賴這項政策或第三方 Cookie。詳情請參閱 Chrome Enterprise 版本資訊

我們也希望能進一步提供報表和工具,以識別企業網站上的第三方 Cookie 使用情況。Chrome 的使用指標較不開放企業瀏覽器查看,這對於企業來說,測試服務中斷向我們回報問題特別重要。

企業軟體式服務 (SaaS) 整合將可使用下方所述的第三方淘汰試用服務。

針對非廣告用途,要求第三方淘汰試用計畫來延長使用時間

如同網路上許多過去的淘汰功能,我們瞭解有些網站需要更多時間進行必要變更。而在這類隱私權相關異動方面,我們也必須權衡網路使用者的需求。

我們計劃提供淘汰試用計畫,讓跨網站使用的網站或服務註冊在限定期間內繼續存取第三方 Cookie。

隨著計畫進度,我們會分享更多詳細資料,但先從以下幾項重要原則開始:

  • 第三方嵌入功能即將進入第三方淘汰試用計畫,可選擇暫時繼續使用第三方 Cookie。
  • 註冊時必須完成審查程序,以確保淘汰試用計畫只適用於對關鍵使用者旅程和註冊事件大幅影響的函式。
  • 因此廣告用途將不會列入淘汰試用的考量範圍。

後續步驟:我們將在 blink-dev 郵寄清單中發布 Intent,並於本月提供更多詳細資料。另外,我們也會繼續在這裡更新說明文件。

保留關鍵使用者體驗

十多年來,跨網站 Cookie 一直是網路不可或缺的一環。這會做出任何變更,尤其是破壞性變更,更複雜的程序需要協調及漸進式。雖然大多數用途會使用額外的 Cookie 屬性和以隱私權為重的 API,但在某些特定情況下,我們希望確保這些網站的使用者體驗不會因此中斷。

主要包括驗證或付款流程,以下情況是指頂層網站開啟彈出式視窗,或重新導向至第三方網站進行作業,然後返回頂層網站、在回訪歷程或嵌入內容中使用 Cookie。我們的目標是提供一系列暫時性的經驗法則,以找出這類情況,並且允許第三方 Cookie 在一段時間內執行必要變更。

下一步:我們會將 Intent 發布到 blink-dev 郵寄清單,和本月提供更多詳細資料,並持續在這裡更新說明文件。

回報第三方 Cookie 相關問題,並取得相關協助

我們希望確保網站在沒有第三方 Cookie 的情況下能運作時,能擷取多種情境資訊,確保網站能順利遷移第三方 Cookie 依附元件,並提供相關指引、工具和功能。如果你的網站或所用服務因為第三方 Cookie 停用而無法運作,你可以透過 goo.gle/report-3pc-broken 向我們的破壞性追蹤工具提交網站。

如果您對於淘汰程序和 Chrome 的計畫有任何疑問,可以在開發人員支援存放區中使用「淘汰第三方 Cookie」標記提出新問題