逐一拆解 Safari ITP 的運作機制：追蹤網域分類、7 天儲存空間上限、Cookie 封鎖、Referrer 精簡，以及它擋不住的追蹤手法。
「Safari 會擋追蹤器嗎？」這個問題的簡短答案是「會」，但較長的答案更有用。**智慧型追蹤防護（Intelligent Tracking Prevention，ITP）**並不是單一開關，而是 WebKit 裡一整疊各自獨立的機制，每一項都針對「把識別碼從一個網站帶到另一個網站」的不同手法：有替具備追蹤能力的網域貼標籤的分類器、對第三方 Cookie 的全面封鎖、限制指令碼能保存資料多久的上限、對 Referrer 的精簡處理，還有更多。本文會逐項說明，並對每一項都提出同樣三個問題：它做了什麼、追蹤者會失去什麼、一般網站又會失去什麼？
核心要點
- ITP 是一整疊機制，不是單一功能。 根據 WebKit 的追蹤防護（Tracking Prevention）文件，它結合了第三方 Cookie 封鎖、Referrer 降級、裝置端追蹤器分類、儲存空間刪除，以及到期時間上限。
- 「7 天限制」針對的是由指令碼寫入的儲存空間。 使用者若在 7 天內沒有與某網站互動，WebKit 就會刪除該網站以 JavaScript 建立的 Cookie，以及
localStorage、IndexedDB、sessionStorage、媒體金鑰，還有 Service Worker 的註冊與快取。 - 第三方 Cookie 一律封鎖。 WebKit 明言沒有任何例外；只有透過 Storage Access API（以及針對彈出視窗的暫時性相容性修正）才能取得存取權。
- ITP 只防禦以狀態為基礎的追蹤。 它移除的是已儲存的識別碼與共用儲存空間，並不會阻止網站蒐集自家訪客的資料，也不是反指紋系統——WebKit 是用另一組獨立的改動來處理指紋問題。
- 在 iOS 上，它涵蓋每一款瀏覽器。 由於 iPhone 上所有瀏覽器都以 WebKit 算繪，ITP 的行為並不是只有選擇 Safari 才有——請見為什麼 iPhone 上的每款瀏覽器底層都是 Safari。
ITP 的起點，以及為什麼文件頁才是重點
WebKit 在 2017 年 6 月推出 ITP。最初的公告是 John Wilander 撰寫的 Intelligent Tracking Prevention，把它定位為「進一步限制 Cookie 與其他網站資料」以減少跨站追蹤的做法，而它建立在一項早已存在的預設之上：自 Safari 1.0 起，WebKit 就不允許尚無 Cookie 的第三方設定新的 Cookie。
這個最初的設計後來已經改變。在 2017 年的版本中，被歸類的網域若在最近 24 小時內與使用者有過互動，仍可在第三方情境下使用自己的 Cookie；若互動發生在最近 30 天內，Cookie 會保留，但改以分割形式存在。現行的 WebKit 文件則把第三方 Cookie 封鎖描述為全面封鎖。這正是為什麼依時間順序整理版本歷史，是學習 ITP 的錯誤方式——它很快就會過時。持續維護的參考資料是 WebKit 的追蹤防護頁面，本文其餘部分便是依據該頁撰寫。
機制 1：為具備追蹤能力的網域分類
它做了什麼。 ITP 會蒐集資源載入的統計資料，並與已知的跨站追蹤模式比對。如果某個可註冊網域符合某種模式，就會被歸類為具有跨站追蹤能力。機器學習模型會看三個數字：該網域以第三方子資源身分出現在多少個不同網站上、以第三方 iframe 身分出現在多少個網站上，以及它在多少個網站下執行過跨站重新導向。WebKit 在 2017 年的公告中表示，所有資料蒐集與分類都在裝置端完成。
另有兩種模式也會導致同樣的標籤。反覆出現的頂層頁框重新導向（彈跳追蹤）會被計入，即使重新導向延遲了幾秒鐘也一樣。而追蹤者串通會讓標籤擴散：一旦某個網域被歸類，先前曾重新導向到它的每個網域也會跟著被歸類，並沿著重新導向關係圖遞迴延伸。
追蹤者會失去什麼。 被歸類的網域，其所有網站資料都會被刪除，除非它在最近 30 天的瀏覽器使用期間，曾以第一方身分獲得使用者互動，或被授予儲存空間存取權。一個只會在背景出現的網域永遠得不到那種互動，所以什麼也留不下來。
一般網站會失去什麼。 什麼都不會失去，除非它看起來像追蹤者。你真正在用的網站會累積互動紀錄，這就是豁免的依據。代價落在使用者很少直接造訪的正當嵌入式服務上——你從不會在獨立分頁中開啟的小工具供應商，可能被誤判為追蹤者。
機制 2：完全封鎖第三方 Cookie
它做了什麼。 自 Safari 1.0 起，WebKit 的預設 Cookie 政策就是：除非第三方原本就已有 Cookie，否則不允許它設定新的 Cookie。ITP 則更進一步：預設封鎖所有第三方 Cookie，沒有任何例外。兩條相關規則堵住了旁門。**閂鎖模式（latch mode）**的意思是，一旦某個請求被封鎖、無法使用 Cookie，該請求的所有重新導向也會一併被封鎖。此外，第三方的 HSTS 也被封鎖：只有第一方網站才能為自己的主機與可註冊網域設定 HSTS。
追蹤者會失去什麼。 典型的做法是：載入在許多網站上的廣告或分析網域，在每個網站上讀取同一個 Cookie。在 ITP 之下，那個 Cookie 永遠不會被送出，所以追蹤者每次看到的都是陌生人。
一般網站會失去什麼。 任何仰賴共用第三方 Cookie 的嵌入式服務：單一登入頁框、能認出已登入使用者的嵌入式留言系統、付款小工具。它們必須明確地請求存取權（見機制 6）。
機制 3：限制由指令碼寫入之儲存空間的壽命
它做了什麼。 對於在第一方情境中由 JavaScript 建立的儲存空間，有兩項上限，因為以第一方指令碼形式運作的追蹤者，會把識別碼存在那裡：
- 7 天。 若使用者在 7 天內沒有與網站互動，ITP 會刪除所有以 JavaScript 建立的 Cookie，以及其他所有可由指令碼寫入的儲存空間。WebKit 列出了受影響的儲存項目：IndexedDB、LocalStorage、媒體金鑰、SessionStorage，以及 Service Worker 的註冊與快取。
- 連結裝飾為 24 小時。 有些追蹤者會把「點擊 ID」加成網址參數，再由著陸頁上的指令碼取走。ITP 會偵測這種模式，並把該著陸頁上以 JavaScript 建立的 Cookie，到期時間上限壓到 24 小時。
計時的依據是使用者的互動——點擊、輕觸或按鍵；WebKit 表示捲動不算——而不是自建立起算的日曆時間。你每隔幾天就會使用的網站，資料會保留下來。
追蹤者會失去什麼。 第三方指令碼寫進頁面自身儲存空間的那個長效第一方識別碼。任何隔了一週以上才回來的訪客，在它眼中都像是新訪客。
一般網站會失去什麼。 任何存放在用戶端、且必須在一週沒人造訪後仍要保留的資料：由 JavaScript 設定的「記住我」旗標、存在 localStorage 裡的草稿、偏好設定 Cookie。需要持久狀態的網站，應改為存放在伺服器端，或由伺服器回應來設定。WebKit 的頁面也提到，加入主畫面的網頁 App 不受 7 天上限限制，並且與 Safari 本身的資料保持隔離。
機制 4：Referrer 降級
它做了什麼。 預設情況下，所有第三方 Referrer 都會被精簡到只剩來源（origin），不論是 HTTP 的 Referer 標頭還是 document.referrer 都一樣。WebKit 舉的例子：完整的 Referrer https://www.social.example/feed?clickID=123456，會顯示為 https://www.social.example/。
追蹤者會失去什麼。 路徑與查詢字串。在 Referrer 中傳遞的點擊 ID 或文章網址不會再抵達目的地；只有來源網站會。
一般網站會失去什麼。 細緻的參照來源分析。網站仍然看得到是哪個來源送來訪客，但看不到是該來源上的哪個頁面或哪些活動參數。
機制 5：重新導向與彈跳追蹤的對策
它做了什麼。 彈跳追蹤會讓你短暫經過追蹤者的網域，使它以第一方身分執行並讀取自己的 Cookie。ITP 會依網域計算頂層頁框的重新導向次數，並將結果餵給機制 1 的分類器。對於一個確實有過使用者互動或儲存空間存取權、卻被發現在做彈跳的已歸類網域，WebKit 表示它的 Cookie 可能會被改寫成 SameSite=strict——於是在跨站導覽時就不會再被送出。Cookie 封鎖的閂鎖模式（機制 2）則涵蓋重新導向鏈。
針對 CNAME 偽裝也有相關對策：當一個看似第一方的子網域，實際上解析到第三方追蹤器時，ITP 會把 HTTP 回應中所設定 Cookie 的到期時間上限壓到 7 天。WebKit 對第三方 IP 位址偽裝也套用同樣的上限。技術本身請見我們的 CNAME 偽裝解析。
追蹤者會失去什麼。 利用經過自身網域的短暫重新導向，藉此成為第一方並取回自己 Cookie 的能力。
一般網站會失去什麼。 正當的重新導向流程，例如單一登入的跳轉或縮網址服務，看起來可能像彈跳追蹤。互動豁免保護的是使用者確實會與之互動的供應商。技術本身請見彈跳追蹤解析。
機制 6：Storage Access API 這條獲准的例外
它做了什麼。 ITP 的封鎖會弄壞正當的嵌入式服務，所以 WebKit 加上了例外：第三方頁框可以透過 Storage Access API，通常是在回應使用者操作時，請求取用它自己的第一方 Cookie。MDN 把這個 API 記載為 document.hasStorageAccess() 與 document.requestStorageAccess()，授權範圍限定於特定的頂層網站與嵌入網站配對。目前的行為與各瀏覽器詢問方式的差異，請參閱 MDN 的 Storage Access API 參考資料。
WebKit 的文件指出，取得儲存空間存取權，是（與第一方使用者互動並列）能讓已歸類網域免於資料被刪除的兩項條件之一。
追蹤者會失去什麼。 悄悄取得存取權的能力。它必須在情境中、於真實互動之後提出請求，而使用者或瀏覽器可以拒絕。
一般網站會失去什麼。 少許的操作阻力：原本無形中就能運作的嵌入內容，現在需要一次點擊與一次 API 呼叫。
底層的分割層
除了上述六項機制，WebKit 的文件還描述了一個分割層：第三方的 LocalStorage 與 IndexedDB 會依第一方網站分割並設為暫時性；第三方 Service Worker 連同它的快取與 IndexedDB 一併分割；而第三方內容的 HTTP 快取項目，也依第一方網站分割。為被歸類為追蹤者的網域所建立的項目，還會被標記為需要驗證：七天後，快取命中會被當成未命中，資源會重新載入並比對，若回應不同就捨棄該項目——這是針對 ETag 這類以快取為基礎之識別碼的防禦。整體概念請見儲存空間分割解析。
ITP 做不到的事
這是多數文章一筆帶過的部分，所以在此直接講明白。
- 它不會阻止第一方資料蒐集。 ITP 針對的是跨站追蹤。網站仍然可以認出自己的回頭客、記錄他們的行為，並在自己的 HTTP 回應中設定 Cookie。上述的上限適用於由指令碼寫入的儲存空間；WebKit 文件並未把一般由伺服器設定的第一方 Cookie 列入受影響的儲存項目（CNAME 偽裝的情況是例外）。
- 它不會阻止指紋辨識。 指紋是由瀏覽器與硬體訊號算出來的，不儲存任何東西，所以 ITP 沒有東西可以刪除、設上限或分割。機制請閱讀我們的瀏覽器指紋技術完全指南，或執行指紋檢測，看看你自己的瀏覽器暴露了什麼。
- 它不會讓連結裝飾變得無害。 一旦偵測到點擊 ID，ITP 會限制著陸頁上由指令碼寫入之 Cookie 的壽命，但在請求中收到點擊 ID 的伺服器，仍然可以把它記錄下來。
- 它無法取代訊號聲明。 Do Not Track 標頭是客氣地請網站配合；ITP 則是強制執行。WebKit 甚至移除了自己的 DNT 旗標，因為它「被當成一種指紋辨識向量」。請見 DNT 為何失敗。
ITP 與指紋防護是不同的子系統
很容易把 WebKit 分開處理的兩件事混為一談。ITP 管的是狀態：Cookie、儲存空間、Referrer、快取與重新導向。反指紋則是另一組改動，列在同一份文件頁面的另一個章節：要求 Device Orientation/Motion API 必須取得權限、限制 WebRTC 對已連接攝影機與麥克風所透露的資訊、把字型可用範圍限制為網頁字型與系統字型、在行銷版本之間凍結 User-Agent 字串、移除 macOS 上的外掛支援，以及拒絕實作 Web Bluetooth、Web MIDI 與 Battery Status API 等功能。
兩者的目標不同，失效的方式也不同。ITP 擊敗的是追蹤者儲存起來的識別碼。反指紋則是縮減追蹤者計算出來之識別碼所能運用的辨識訊號數量。Safari 每推出一項以狀態為基礎的防禦，對仍想做跨站串連的追蹤者來說，無狀態的路線相對就更有價值——這也是為什麼由瀏覽器訊號建立的持久訪客 ID，能夠撐過上述所有機制。
常見問題
Safari 會擋追蹤器嗎？
會，而且同時用好幾種方式：它封鎖第三方 Cookie、精簡第三方 Referrer、為具備追蹤能力的網域分類並刪除它們的資料，還限制由指令碼寫入之儲存空間的保存時間。但它並不會擋下所有追蹤——第一方蒐集與指紋辨識依然存在。
ITP 的 7 天 Cookie 限制是什麼？
這是針對可由指令碼寫入之儲存空間的上限。使用者若在 7 天內沒有與某網站互動，WebKit 就會刪除該網站以 JavaScript 建立的 Cookie，以及 localStorage、IndexedDB 等其他可由指令碼寫入的儲存空間。與該網站互動就會重設計時。
ITP 也適用於 iPhone 上的 Chrome 或 Firefox 嗎？
適用，因為在 iOS 上，這些 App 是以 WebKit 算繪——不過在部分地區，實際情況正在改變，詳見為什麼 iPhone 上的每款瀏覽器底層都是 Safari。ITP 的行為是引擎的特性，而不是 Safari 這個品牌的專屬功能。
我可以關閉 ITP 嗎？
WebKit 的文件把預設的 Cookie 政策與 Safari 的「防止跨網站追蹤」設定連結在一起。關掉它會讓跨站追蹤更容易，而且很少是修復壞掉之嵌入內容的正確辦法；官方認可的途徑是 Storage Access API。
ITP 能阻止瀏覽器指紋辨識嗎？
不能。ITP 關心的是已儲存的狀態。指紋不儲存任何東西，而 WebKit 另外採取的反指紋措施，只能減少、無法消除可用來建立指紋的素材。
結語
ITP 之所以有效，是因為它不靠單一招數。分類機制依行為找出追蹤者，Cookie 封鎖撤掉跨站共用的 Cookie，儲存空間上限縮短指令碼能保存的時間，Referrer 精簡去掉網址細節，而 Storage Access API 則為正當的嵌入內容，留下一條看得見、需要使用者操作才能走的回頭路。它放過的東西同樣重要：網站對自家訪客的紀錄，以及任何靠計算而非儲存得出的識別碼。如果你想親眼看看第二類，請在 Safari 中執行指紋檢測，並與另一款瀏覽器比較。
推薦閱讀：
