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

在 Firefox 中測試

此 Cookie 策略自 Firefox 63 版本起已可用。本文件描述了我們計劃向 Firefox Release 使用者釋出策略，但可能與當前 Firefox Release 版本中實現的不符。這是因為我們會在策略的新方面一經發布到我們的預釋出渠道 Firefox Nightly，就立即進行文件記錄。Firefox Nightly 還可能包含我們尚未計劃向 Release 使用者釋出的功能；實驗性功能將不包含在本文件中，但仍可能影響被歸類為跟蹤器的域的功能。

我們建議網站使用 Firefox Nightly 進行測試，因為它包含了我們最新版本的保護功能。如上所述，請注意 Nightly 可能包含最終會在釋出給我們的 Release 使用者之前被刪除或更改的額外保護功能。隨著我們加強保護功能，我們將不斷更新此頁面，提供最新資訊。

這些保護措施在 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 異常。

訊息傳遞和 Worker

• Broadcast Channel: 嘗試建立新的 BroadcastChannel 將丟擲 SecurityError 異常。
• Shared Worker: 嘗試建立新的 SharedWorker 將丟擲 SecurityError 異常。
• Service Worker: 嘗試建立新的 ServiceWorker 將丟擲 SecurityError 異常。

DOM 快取

• 對 CacheStorage 的呼叫將始終因 SecurityError 而被拒絕。

瀏覽器快取

• HTTP 快取、圖片快取和 替代服務 (Alt-Svc) 快取 都為跟蹤資源進行了分割槽，以便每個頂級源都將有一個獨立的分割槽，並且不同頂級源上的跟蹤資源將彼此獨立快取。

網路連線

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

HTTP 引用者

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

該策略沒有阻止什麼？

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

儲存訪問授權

為了提高網路相容性並允許需要儲存訪問的第三方整合，Firefox 將授予特定第三方源的儲存訪問許可權，該許可權限定於第一方，如本節所述。目前，Firefox 包含一些網路相容性啟發式演算法，當用戶與這些第三方互動時，這些演算法會授予被歸類為跟蹤器的第三方資源儲存訪問許可權。我們這樣做是因為我們預計不授予訪問許可權會導致網頁損壞。我們還支援 Storage Access API 的初始實現，透過該 API，嵌入式 <iframe> 可以透過呼叫 Document.requestStorageAccess() 請求儲存訪問許可權。儘管這兩種方法都提供相同級別的儲存訪問許可權，但我們建議第三方切換到使用 Storage Access API，以保證它們對儲存的訪問許可權。

互動時自動儲存訪問

為了提高網路相容性，Firefox 目前包含一些啟發式演算法，可在使用者與第三方互動時自動授予其儲存訪問許可權。這些啟發式演算法旨在允許一些常見的第三方整合繼續正常執行。它們旨在作為臨時措施，並將在 Firefox 的未來版本中移除。不應依賴它們進行當前和未來的網路開發。

當用戶手勢觸發具有對原始文件的 opener 訪問許可權 的彈出視窗時，可能會授予第三方儲存訪問許可權。如果使用者與彈出視窗互動，則如果該源在過去 30 天內作為第一方接收過使用者互動，則彈出視窗中最初載入的資源的源將獲得對 opener 文件的儲存訪問許可權。

當用戶在同一視窗中導航到另一個源時，也可能授予第三方儲存訪問許可權。如果使用者與該源互動，然後快速導航到初始源中的文件，則中間頁面將獲得對該最終文件的儲存訪問許可權。

儲存訪問範圍

授予儲存訪問許可權時，它會限定於 opener 文件的站點或該源的子域。在源的子域上授予的訪問許可權會擴充套件到頂級源。例如，如果來自 tracker.example 的資源在 foo.example.com 上獲得儲存訪問許可權，那麼 tracker.example 將能夠訪問其在 bar.foo.example.com 和 example.com 上的 Cookie。

當 tracker.example 在 example.com 上獲得儲存訪問許可權時，從 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 查詢引數並將任何廣告跟蹤引數儲存到第一方儲存。如果使用者稍後完成轉化事件，網路的標籤會檢查第一方儲存以確定哪個點選（或哪些點選）導致了訪問。我們預計以這種方式實現的點選型轉化將繼續有效。