儲存訪問策略：阻止跟蹤器中的 Cookie

此 Cookie 策略自 Firefox 63 版起開始提供。本文件描述了我們打算提供給 Firefox 正式版使用者的策略，但可能與 Firefox 正式版當前版本中實施的策略不匹配。這是因為我們會在新策略的功能新增到 Firefox Nightly（我們的預釋出通道）後立即對其進行記錄。Firefox Nightly 還可能包含一些我們尚未計劃提供給正式版使用者的實驗性功能；實驗性功能不會包含在此文件中，但可能會影響被歸類為跟蹤器的域的功能。

我們建議網站使用 Firefox Nightly 進行測試，因為該版本包含我們保護措施的最新版本。如上所述，請注意 Nightly 可能包含最終會被刪除或更改的其他保護措施，然後才會提供給我們的正式版使用者。我們會隨著保護措施的加強而持續更新此頁面，以提供最新的資訊。

這些保護措施在 Nightly 中預設啟用。Cookie 策略可以透過 內容阻止設定 在 Firefox 的其他版本中啟用（這些步驟會因版本而異；連結的文件包含一個下拉選單，用於選擇相應的 Firefox 版本）。

如果您發現因此更改而導致某個網站出現故障，請在 Bugzilla 上的 Firefox 產品中的跟蹤保護元件下提交錯誤。或者，您也可以透過單擊 控制中心 中內容阻止部分的“報告問題”來直接在 Firefox 中報告已損壞的站點（此快捷方式可能並非在所有 Firefox 版本中都可用）。

Firefox 如何確定哪些資源是跟蹤資源？

Firefox 使用跟蹤保護列表來確定哪些資源是跟蹤資源。跟蹤保護列表由 Disconnect維護。當在 Firefox 中應用此列表時，我們會進行兩個重要的更改。

• 首先，我們只使用列表的“基本保護”版本，該版本 不包含某些類別的跟蹤器。將來，我們可能會擴充套件保護措施以使用列表的“嚴格保護”版本。
• 其次，Firefox 使用一個額外的 實體列表，該列表會 防止在由同一組織擁有的頂級站點上載入域時將其歸類為跟蹤器。

Firefox 使用內建的 跟蹤保護 URL 分類器來確定哪些資源與跟蹤保護列表匹配。根據 SafeBrowsing v4 規範，會將域與列表進行匹配。具體來說，我們會檢查資源的精確主機名是否與列表匹配，以及從後五部分開始依次刪除開頭部分所形成的後四部分主機名是否與列表匹配。請考慮以下示例。

儲存訪問策略會阻止被識別為跟蹤器的資源訪問在第三方上下文中載入的 第三方 Cookie 和其他站點儲存。這會阻止這些資源檢索跟蹤識別符號並使用它們跨多個第一方訪問來識別使用者。具體來說，Firefox 會透過實施以下限制來實現此目的。

Cookie

• 阻止 Cookie 請求標頭，並忽略 Set-Cookie 響應標頭。
• 對於 Document.cookie 的呼叫返回空字串，並忽略透過 Document.cookie 設定 Cookie 的請求。

DOM 儲存

• localStorage: Window.localStorage: 讀取和寫入嘗試將引發 SecurityError 異常。在 Firefox 70 之前：Window.localStorage 為 null。因此，使用此物件進行讀取和寫入嘗試將引發 TypeError 異常。
• sessionStorage: 允許讀取和寫入嘗試。
• IndexedDB: 嘗試訪問 IndexedDB 工廠物件將引發 SecurityError 異常。

訊息傳遞和工作執行緒

• 廣播通道: 嘗試建立新的 BroadcastChannel 將引發 SecurityError 異常。
• 共享工作執行緒: 嘗試建立新的 SharedWorker 將引發 SecurityError 異常。
• 服務工作執行緒: 嘗試建立新的 ServiceWorker 將引發 SecurityError 異常。

DOM 快取

• 對 CacheStorage 的呼叫將始終拒絕並引發 SecurityError。

瀏覽器快取

• HTTP 快取、影像快取和 備用服務 (Alt-Svc) 快取 針對跟蹤資源進行分割槽，這樣每個頂級來源將擁有一個獨立的分割槽，而不同頂級來源上的跟蹤資源將分別快取。

網路連線

• 當與被歸類為跟蹤器的嵌入式第三方資源建立 HTTPS 連線時，將不會使用會話票證來恢復 TLS 會話。
• 被歸類為跟蹤器的域的 HTTP 連線重用 僅限於在同一頂級來源下發生的請求。例如，從 news.example 上的 tracker.example 請求內容不會與從 shopping.example 上的 tracker.example 請求內容或直接訪問 tracker.example（即作為第一方）時發生的請求重用 HTTP 連線。

HTTP 來源

• 被歸類為跟蹤器的第三方資源的預設 來源策略 設定為 strict-origin-when-cross-origin。

1. 此策略當前不會限制未被歸類為跟蹤資源的資源的第三方儲存訪問。將來，我們可能會選擇對第三方儲存訪問施加更多限制。
2. 策略實施的限制不會阻止被歸類為跟蹤資源的第三方指令碼訪問頁面主上下文中的儲存。這些指令碼可以繼續使用針對頂級來源進行範圍限定的儲存。
3. 被歸類為跟蹤器的來源在以第一方上下文載入時將可以訪問自己的儲存。
4. 從與頂級上下文相同的 eTLD+1 載入的跨來源資源仍將可以訪問其儲存。
5. 通常被歸類為跟蹤器的來源 如果確定頂級頁面來源與它們來自同一組織，則不會被阻止。

為了提高 Web 相容性並允許需要儲存訪問的第三方整合，Firefox 將授予針對特定第三方來源在第一方範圍內的儲存訪問許可權，如本節所述。當前，Firefox 包含一些 Web 相容性啟發式演算法，這些演算法會在使用者與這些第三方互動時向被歸類為跟蹤器的第三方資源授予儲存訪問許可權。我們會在預計不授予訪問許可權會導致網頁出現故障時執行此操作。我們還支援 儲存訪問 API 的初始實施，透過該 API，嵌入式 <iframe> 可以透過呼叫 Document.requestStorageAccess() 來請求儲存訪問許可權。雖然這兩種方法都提供了相同級別的儲存訪問許可權，但我們建議第三方切換到使用儲存訪問 API，以確保他們可以訪問儲存。

為了提高 Web 相容性，Firefox 目前包含一些啟發式方法，以自動授予接收使用者互動的第三方儲存訪問許可權。這些啟發式方法旨在允許 Web 上常見的某些第三方整合繼續執行。它們旨在是臨時的，將在 Firefox 的未來版本中刪除。對於當前和未來的 Web 開發，不應依賴它們。

當用戶手勢觸發具有opener 訪問許可權的彈出視窗時，可能會向已分類為跟蹤資源的資源授予第三方儲存訪問許可權。發生這種情況時，第三方來源可以獲得訪問許可權的三種可能方法。

• 如果資源的來源最初在彈出視窗中載入，並且該來源在過去 30 天內作為第一方收到了使用者互動，則該資源的來源將獲得對 opener 文件的儲存訪問許可權。
• 在初始資源載入到彈出視窗後，該視窗可能會經過一系列重定向到其他主機。如果使用者在重定向後與彈出視窗互動，則在彈出視窗中載入的內容的來源將獲得對 opener 文件的儲存訪問許可權。
• 當從跟蹤來源到非跟蹤來源進行頂級重定向時，跟蹤來源會獲得對非跟蹤來源以及重定向鏈中出現的任何其他非跟蹤來源（即，如果載入繼續重定向）的短期儲存訪問許可權。跟蹤來源必須在過去 30 天內作為第一方接收使用者互動，並且儲存訪問許可權將在 15 分鐘後過期。

授予儲存訪問許可權後，它將限定在 opener 文件的站點或該來源的子域。授予對來源子域的訪問許可權不會擴充套件到頂級來源。例如，如果從 tracker.example 載入的資源在 foo.example.com 上獲得儲存訪問許可權，則 tracker.example 將能夠訪問其在 bar.foo.example.com 和 example.com 上的 cookie。

當向 example.com 上的 tracker.example 授予儲存訪問許可權時，從 example.com 載入的任何頂級文件上從 tracker.example 載入的所有資源都會立即獲得儲存訪問許可權。這包括在頁面的主上下文中載入的所有資源，嵌入的 <iframe> 以及在嵌入的 <iframe> 中載入的資源。儲存訪問許可權不會擴充套件到 example.com 上載入的其他資源（例如 other-tracker.example），也不會擴充套件到嵌入 tracker.example 的其他第一方（例如 example.org）。

儲存訪問許可權授予擴充套件到巢狀上下文的第一個級別，但不會再深入。這意味著在頁面主上下文中嵌入並從分類為跟蹤程式的域載入的 <iframe> 將完全訪問所有透過 JavaScript 訪問的儲存位置。同樣，在頁面主上下文中嵌入的 <iframe> 中載入的資源請求將能夠訪問 HTTP cookie。但是，進一步巢狀的上下文（包括但不限於分類為跟蹤程式的來源的上下文）將不會被授予儲存訪問許可權。

考慮在從 example.com 載入的頂級頁面上以下嵌入場景，在該頁面上已授予 tracker.example 儲存訪問許可權。

儲存訪問許可權授予在 30 天后過期。分類為跟蹤資源的域可能會在多個第一方獲得第三方儲存訪問許可權，並且每個方的儲存許可權獨立過期。上述啟發式方法還將有助於延長已獲得訪問許可權的來源上的第三方儲存許可權的壽命。每次啟發式方法被啟用或對 Storage Access API 進行成功呼叫時，預先存在的儲存訪問過期時間將延長 30 天，從上次授予訪問許可權的時間開始計算。

請注意，將來我們預計會更改儲存訪問許可權的有效時間。如前所述，瞭解將來您是否能夠作為第三方使用儲存的方法是使用 Storage Access API。

我們鼓勵網站所有者測試他們的網站，尤其是那些依賴第三方內容整合的網站。我們已在 Firefox 中添加了一些新功能，以使測試更容易。

Firefox 開發者工具中的網路監視器現在包含一個指示器，用於所有已分類為跟蹤資源的資源請求。該指示器在域列中顯示為盾牌圖示。在下圖示例中，trackertest.org 被分類為跟蹤資源，而對 example.com 的請求則沒有。

好奇如果您的網站上的第三方域被分類為跟蹤程式，情況會如何？我們添加了一個首選項，允許您將自定義域新增到跟蹤保護 URL 分類器。為此

1. 在位址列中鍵入 about:config。如果您看到一個警告您“這可能會使您的保修失效！”的頁面，請單擊“我接受風險！”。
2. 搜尋首選項名稱“urlclassifier.trackingAnnotationTable.testEntries”。
3. 如果首選項已存在，請編輯首選項值。
4. 如果首選項不存在，請單擊“字串”，然後單擊“+”以建立新首選項。
5. 對於首選項值，輸入要分類為跟蹤程式的以逗號分隔的來源。例如，“example.net,example.org”。

此 cookie 策略有可能導致網站中斷，但旨在允許常見的第三方整合繼續工作，同時防止跨站點跟蹤。在本節中，我們將描述您在不同整合場景中可以預期的功能。

不會 - 此功能僅限制對可以用來跨網站跟蹤使用者的 cookie 和網站資料的訪問。阻止跟蹤識別符號不會阻止廣告的顯示。

這取決於第三方分析服務的實現方式。第三方分析提供者將不再能夠使用其第三方儲存來收集資料。這意味著使用限定在其第三方域的 cookie 或在其來源下儲存的本地儲存和其他網站資料的提供者將不再能夠訪問跨其他網站的這些識別符號。

如果這些服務嵌入到頁面的主上下文中，它們可以繼續使用第一方 cookie 和網站儲存來跨特定第一方域的頁面訪問跟蹤使用者。

這取決於社交整合的實現方式。我們預計，許多流行的社交整合將繼續像在 Firefox 的當前 cookie 策略下那樣執行，只是使用者體驗略有不同。

被分類為跟蹤程式的社交內容提供者在使用者首次訪問新的第一方時將無法訪問其第三方 cookie。因此，使用者可能看起來已登出該服務，儘管他們在直接訪問提供者的網站時已登入。根據整合的型別，使用者可能需要採取一些操作來與社交內容提供者進行互動，然後提供者才能訪問他們的 cookie。例如

• 對於社交登入，使用者可能需要點選第一方的登入按鈕。
• 對於社交點贊或分享按鈕，使用者需要先在登出狀態下與按鈕進行互動。一旦他們這樣做，許多社交內容提供者會提示他們登入。

在這些互動之後，如果提供者以被上述儲存訪問啟用啟發式方法捕獲的方式提示使用者，則該提供者將獲得第三方儲存訪問許可權。這些提供者應儘快考慮透過 Storage Access API 明確請求儲存訪問許可權。該 API 的初始實現目前在 Nightly 中可用。

這取決於第三方如何實現衡量工具，但通常廣告轉化衡量會更加困難。請考慮以下示例

1. 您在社交媒體網站上投放的廣告被使用者看到了很多次，但從未被點選。該使用者後來訪問了您的網站，其中包含來自同一社交媒體網站的轉化跟蹤標籤。這種型別的轉化通常被稱為“觀看後轉化”。由於社交媒體網站無法訪問其第三方儲存，因此它們無法識別使用者為在他們的網站上看到廣告的同一使用者，並且不會跟蹤轉化。我們預計，大多數觀看後轉化跟蹤技術將不再有效，包括那些由展示網路提供的技術。
2. 您在展示網路或社交媒體網站上投放的廣告被使用者點選。該使用者訪問了您的網站，其中包含來自顯示廣告的同一網站的轉化跟蹤標籤。這種型別的轉化通常被稱為“點選後轉化”。由於社交媒體網站或展示網路無法訪問其第三方儲存，因此它們無法識別使用者為在他們的網站上看到廣告的同一使用者，並且不會跟蹤轉化。我們預計，這種型別的點選後轉化將不再有效。
3. 您投放的廣告出現在社交媒體網站上。使用者點選您的廣告並被帶到包含來自第三方網路的轉化跟蹤標籤的著陸頁。在社交媒體網站上，網路使用查詢引數註釋廣告著陸頁 URL，以表明訪問是點選廣告的結果。在您的網站上，展示網路的標籤檢查 URL 查詢引數並將任何廣告跟蹤引數儲存到第一方儲存。如果使用者後來完成了轉化事件，網路的標籤會檢查第一方儲存以確定哪些點選（或點選）導致了訪問。我們預計，以這種方式實現的點選後轉化將繼續有效。