隱私視窗不只隱藏瀏覽紀錄，還會改變儲存 API 的運作方式，而這正是網站用來偵測無痕模式的關鍵所在。
無痕視窗與隱私瀏覽視窗承諾的是：網站無法得知你之前來過。它們並沒有承諾網站無法得知你「現在」正處於這種模式——而過去十年來，出版商、廣告網路與反詐欺工具正是利用了這道落差。因為隱私視窗在底層必須有不同的行為——不同的儲存空間限制、不同的磁碟寫入方式——一支探測這些差異的指令碼，往往能在完全不讀取任何 Cookie 的情況下，就相當有把握地判定「這是一個隱私視窗」。
核心要點
- 隱私瀏覽隱藏的是歷史紀錄，而不是行為——像
navigator.storage.estimate()這類儲存 API，在一般工作階段與隱私工作階段之間，依然會回報真實且可量測的差異。 - Chromium 最古老的一招，是量測寫入（現已淘汰的）FileSystem API 的速度——這個 API 在無痕模式下是在記憶體中執行的，速度大約比一般模式下實際的磁碟寫入快 3 到 4 倍。
- Chrome 在 2019 年封堵這個漏洞後，偵測指令碼便轉向 Chrome 透過
navigator.storage.estimate()回報的儲存配額——在無痕模式下數值較小且較為一致，在一般模式下則較大，並與磁碟容量成比例。 - 此後 Chrome 開始在所有模式下都回報一個固定的「可預測」配額，目的正是為了扼殺這種判別法——這是一項仍在進行中的修補措施，而非已經塵埃落定的解方。
- Firefox 與 Safari 也各自有一段隱私模式洩漏破綻的歷史，主要圍繞在
localStorage與IndexedDB在隱私工作階段中行為不同（或直接失效）。 - BrowserInsight 的指紋檢測會顯示你的瀏覽器目前暴露出的儲存、Canvas 及其他訊號，無論是否處於隱私視窗中。
網站為什麼要費心偵測無痕模式
兩大主要動機都屬於商業性質，而非資安意義上的對抗行為。採用計次付費牆的出版商——其中最有名的是《紐約時報》——利用無痕偵測，來阻止讀者每次開啟新的隱私視窗，藉此重設免費文章的閱讀次數。廣告技術與反詐欺工具則把它當作眾多訊號之一：隱私視窗流量中，有不成比例的一部分與廣告詐欺點擊農場、優惠券／促銷濫用相關，因此標記出這類流量能餵入更廣泛的風險評分——這與機器人偵測系統整合多項微弱訊號、而非只信任單一訊號的做法如出一轍。
這兩種用途都不需要辨識出「你是誰」——只需要知道你目前使用的視窗是不是隱私視窗。正是這個較為侷限的目標，讓這項技術有別於瀏覽器指紋辨識：它並不打算建立一個持久識別碼，只是要在頁面載入期間，回答一個是非題。
FileSystem 寫入速度伎倆
最早可靠的無痕偵測技術，鎖定的是 Chrome 對（現已淘汰、僅 Chromium 支援的）File and Directory Entries API 的實作方式——也就是 window.webkitRequestFileSystem 之類的介面。在一般視窗中，Chrome 會用磁碟上的真實檔案來支援這個 API；在無痕模式下，為了避免視窗關閉後留下任何痕跡，Chrome 改用記憶體中的虛擬檔案系統來支援它。
記憶體的速度遠遠快於磁碟，因此一支指令碼只要寫入一批暫存檔案，計時寫入所花的時間，就能得到一個乾淨的訊號：如果寫入速度比一般模式的基準快上三到四倍，就代表檔案系統根本沒有碰觸磁碟，也就代表這是一個隱私視窗。不需要任何權限彈窗，也不需要使用者互動——只是針對一個當時預設就已暴露的 API 做一次計時量測。
Chrome 在 76 版（2019 年）封堵了這個特定漏洞，把無痕模式下 FileSystem 的實作方式改為同樣寫入磁碟，而非記憶體，藉此抹除了計時上的差距。這是對「付費牆偵測」這項用途引發主流媒體關注的直接回應——是一次貨真價實的漏洞修補，而非表面功夫。
StorageManager 配額伎倆
這項修補並沒有終結這場貓捉老鼠的遊戲，只是把戰場挪到了另一個 API 上。每個現代瀏覽器都會暴露 navigator.storage.estimate()——它是 Storage API 的一部分——會回傳一個 Promise，解析為目前的儲存 usage，以及該來源可用的 quota：
// Illustrative sketch — not the exact detectIncognito heuristic
async function looksLikeIncognito() {
const { quota } = await navigator.storage.estimate();
const ONE_TWENTY_MB = 120 * 1024 * 1024;
// Historically: Chromium capped Incognito quota well below
// the large, disk-proportional value normal windows report.
return quota < ONE_TWENTY_MB;
}
在一般瀏覽模式下，Chromium 過去是根據實際可用磁碟空間的一部分來計算回報的配額——通常是幾十到幾百 GB。在無痕模式下，由於設定檔是暫時性的，且配額通常受限於可用記憶體而非磁碟容量，回報的數字會小得多，且在不同機器之間相對一致。指令碼只需要檢查回報的數字是否低於某個低門檻（公開文章引用的分界值大約是 120 MB），就能相當有把握地做出判定。
這套判別法——連同 Chromium 專屬的後援方案，以及針對 Firefox、Safari、Edge 與 Opera 各自獨立的檢查——目前以開源參考實作的形式，維護在 GitHub 上的 Joe12387/detectIncognito 專案中，是了解這些檢查手法隨時間演變得多麼多樣化、多麼因瀏覽器而異的實用一手資料。
Firefox 與 Safari 各自的破綻
Chromium 的儲存配額破綻之所以最受關注，是因為 Chrome 的市佔率讓它成為最有價值的目標，但 Firefox 與 Safari 也都曾在不同時期，各自出過可被偵測的隱私模式怪癖：
| 瀏覽器 | 歷史上的隱私模式破綻 | 根本原因 |
|---|---|---|
| Chrome / Chromium | FileSystem 寫入速度（2019 年之前）；儲存配額（2019 年之後） | 記憶體內檔案系統；較小的、以 RAM 為基礎的配額 |
| Safari | localStorage.setItem() 會擲出配額超出（quota-exceeded）錯誤 | 隱私模式將 Web Storage 配額上限設為 0 位元組 |
| Firefox | indexedDB 為 null，或請求會靜默失敗 | 隱私視窗中 IndexedDB 曾多年無法使用 |
Safari 的版本可以說是最粗糙的：多年來，在隱私視窗中呼叫 localStorage.setItem() 會立刻擲出例外，因為 Safari 把隱私模式的儲存配額直接設為零，而不是加以隔離。只需要用一個 try/catch 包住一次測試寫入，就能以近乎完美的準確度偵測出這個模式。Apple 在 Safari 11 中修正了這個問題，讓 localStorage 在隱私視窗中重新變得完全可寫——資料只是存放在記憶體中，工作階段結束後就會消失，而不是直接被封鎖。
Firefox 的 IndexedDB 則從另一個方向講述了類似的故事：隱私視窗要麼根本不暴露 indexedDB 物件，要麼讓開啟請求失敗，指令碼同樣可以像捕捉 Safari 的儲存例外一樣輕鬆捕捉到這一點。此後 Firefox 逐步改用加密、限定工作階段範圍的儲存方式，在隱私瀏覽中支援 IndexedDB，以此封堵了這個特定破綻——做法與 Chrome 封堵 FileSystem 破綻如出一轍：讓隱私模式的實作方式變得與一般模式足夠相似，使計時／可用性訊號消失。
十年的貓捉老鼠
每個瀏覽器都遵循相同的三步驟循環，只是時間軸各不相同：某個實作細節洩漏出隱私模式的差異 → 這項差異被武器化，用於付費牆或詐欺偵測 → 廠商重新設計隱私模式的實作方式以消除這道破綻，而這通常又會在別處打開一道更小、更隱晦的破綻。儲存 API 之所以一直是戰場，是因為隱私模式的整個任務，就是要讓資料的處理方式與平常不同——而這正是偵測指令碼永遠可以嘗試量測的那個特性。
截至 2026 年的現況
StorageManager 配額伎倆對目前的 Chrome 穩定版仍然有效，但看來為時不多了。Chrome 一直在推出一項名為「可預測回報儲存配額」的緩解措施：對於沒有提升儲存權限的網站，它會在所有瀏覽模式下都回報一個人工配額——即目前用量，再加上 10 GiB 與你四捨五入後磁碟容量兩者中較小的那一個——目的正是讓一般視窗與無痕視窗在這項量測上變得無法區分。截至 2026 年年中，這項措施正逐步推行到儲存權限受限的網站；已獲得無限儲存權限，或觸及強制配額上限的網站則明確不受影響，因此這種判別法並沒有一次性地在所有地方消失。
實際上的結論是：沒有任何單一的儲存檢查能成為長久有效的無痕偵測手段，而且這些技術從來都不需要 Cookie、Canvas 或持久識別碼——比起指紋辨識，這是一場範圍更窄、變化更快的遊戲，戰場是一個個 API，而不是一個個訊號。
無痕模式能保護你不被指紋辨識嗎？
單靠它自己不行——而一旦偵測與否的問題有了答案，這一點其實更加重要。隱私視窗改變的是儲存了什麼——歷史紀錄、Cookie、快取的表單資料——而不是你的瀏覽器在即時頁面上暴露了什麼：無論視窗是否為隱私模式，同樣的 Canvas 雜湊值、WebGL 算繪器字串、字型與螢幕特徵，都會算繪出完全相同的結果。如果你使用無痕模式，是期待能藉此躲過指紋辨識，瀏覽器指紋技術完全指南說明了為什麼這種期待站不住腳，以及真正能降低暴露程度的做法。
分別在一般視窗與隱私視窗中各執行一次 BrowserInsight 的指紋檢測——底層訊號看起來幾乎一模一樣，這是理解「隱私」與「無法被指紋辨識」是兩種不同保證的最清楚方式。
常見問題
網站是否永遠都能判斷出我正處於無痕模式？
不能。偵測手段一直都仰賴特定瀏覽器版本中的特定實作怪癖，而這些怪癖遲早會被修補。去年還能可靠運作的技術，在瀏覽器更新後可能悄悄失效，反之亦然——這是一場不穩定的軍備競賽，而不是一項已經塵埃落定的能力。
清除 Cookie 或使用 VPN 能阻止無痕偵測嗎？
不能，因為這些技術一開始就不會去看 Cookie 或你的 IP 位址。它們量測的是儲存 API 在目前工作階段中的行為方式，這與 VPN 或清除 Cookie 所改變的東西毫無關聯。
偵測無痕模式合法嗎？
偵測本身並不當然違法，但網站拿這項資訊做了什麼，可能會引發另一層法律與倫理上的疑慮——尤其是當它被用來規避使用者刻意做出的隱私選擇，以達成商業目的時，例如強制重設付費牆的計次。各法域的法規不盡相同，本文亦不構成法律建議。
為什麼 Chrome 花了好幾年才完全修好這個問題？
因為每一次修補都只封堵了一個特定漏洞，而那項根本限制——隱私工作階段的儲存機制，總得在某個地方與一般工作階段表現得不一樣——不斷重新打開新的、更狹窄的破綻。2019 年的 FileSystem 修補並沒有觸及 StorageManager 配額破綻，而目前的配額緩解措施本身也仍在逐步推行、且帶有例外情況，這正好說明了要徹底做到「設計上就無法區分」有多麼困難。
結語
無痕偵測是瀏覽器指紋辨識範圍更窄、變化更快的近親：它不是要從數十種訊號中建立一個持久識別碼，而是只問一個問題——儲存機制的表現像不像隱私工作階段？——並借用當下任何能回答這個問題的 API。每一次修補都封堵了一個真實的破綻，而每一個新的破綻遲早又會被發現，這正是為什麼理解其運作機制，遠比照單全收任何一則「無痕模式無法被偵測」的說法更加重要。
推薦閱讀：
