我們發現一個穩定的 Firefox 識別碼，可把你在 Tor 中所有私密身分串聯起來 （★ 131 分）
一項新揭露的隱私漏洞顯示，所有採用 Gecko (Firefox 的瀏覽器引擎) 的瀏覽器，都可能讓網站從 IndexedDB (瀏覽器端結構化資料庫 API) 的回傳順序中，推導出一個在瀏覽器行程存活期間固定不變的識別碼。網站只要先建立一組固定名稱的資料庫，再呼叫 indexedDB.databases() 觀察列出順序，就能在彼此無關的網站來源 (origin) 之間辨認出同一個 Firefox 或 Tor Browser (Tor 匿名瀏覽器) 執行個體。這不需要 cookie (網站儲存在瀏覽器的小型識別資料)、localStorage (瀏覽器本機儲存機制) 或任何明確的跨站管道，卻足以把不同網站的活動串在一起；在 Firefox 私密瀏覽模式中，甚至在所有私密視窗都關閉後，只要主程式仍未結束，這個識別碼就會持續存在。在 Tor Browser 裡，它還能穿透 New Identity 功能原本承諾的重設效果，削弱使用者期待的不可串聯性。
問題根源在於 Firefox 私密瀏覽時，會把網站自行命名的資料庫名稱對應到 UUID (通用唯一識別碼) 為基礎的檔名，並把這層對照放在以整個瀏覽器行程為範圍的雜湊表中，而不是限制在單一網站來源。之後 indexedDB.databases() 蒐集資料庫中繼資料時，又沒有先做固定排序，而是直接依照內部雜湊結構的迭代順序回傳結果；於是這個看似無害的 API，反而洩漏了穩定且高容量的指紋特徵。若網站控制 16 個資料庫名稱，理論上就可形成約 44 位元的熵 (entropy，代表可區分程度)，足以在實務上強力辨識同時存在的瀏覽器個體。Mozilla 已在 Firefox 150 與 Firefox ESR 140.10.0 (Extended Support Release，延長支援版本) 修正此問題，做法也相對直接，就是在回傳前先用固定規則排序，移除來自內部儲存排列的識別特徵。
討論焦點之一是 Tor Browser 的修補速度。有人起初擔心文章只提到已通報 Mozilla，卻沒交代 Tor Project 何時處理；隨後就有讀者補充，Tor Browser 平常就會緊跟 Firefox ESR，且隔天已發布修正版。另一條熱烈討論則圍繞在揭露者 Fingerprint.com 的角色：有人肯定研究品質，也好奇一家販售瀏覽器指紋產品的公司，為何會主動通報這種漏洞。贊成這種作法的人認為，這次屬於明顯的實作缺陷，與一般利用瀏覽器既有差異做辨識的作法仍有界線；質疑者則反問，幾乎所有指紋技術都建立在軟硬體未預期的行為上，兩者的道德差別沒有那麼清楚。也有人直言，這個識別碼只在單一瀏覽器行程內穩定，對數月等級的長期追蹤價值較低，或許正因如此才更容易被公開。
其餘回應則補上實務面的限制與緩解方式。多名讀者指出，若關閉 JavaScript (網頁腳本語言)，網站通常就無法輕易執行這類利用程式，但也有人提醒，在一般網站環境裡停用 JavaScript 可能讓自己落入更小的辨識群體；不過在 Tor Browser 的族群中，關閉 JavaScript 也許比外界想像更常見。另有人釐清，跨來源共享的不是 IndexedDB 內容本身，而是資料庫名稱與 UUID 的內部對照及其排列，因此網站看不到別站資料，只能藉由同一組順序取得相同指紋。還有人提到，雖然瀏覽器完整重啟後識別碼會改變，但許多人其實長時間不關瀏覽器，追蹤者也可能把這種短期指紋與 cookie 串接，延續辨識效果；相較之下，像 Qubes OS 這類把不同工作拆到獨立虛擬機器的作法，因每個 VM (Virtual Machine，虛擬機器) 都有不同瀏覽器行程，較能降低這類風險。也有少數人把問題延伸到整個 Web 標準設計，認為像 IndexedDB、Canvas (網頁繪圖 API) 這類功能若暴露過多內部差異，就會不斷成為指紋追蹤素材，瀏覽器應更嚴格收斂可被網站觀察的細節。
👥 46 則討論、評論 💬
https://news.ycombinator.com/item?id=47866697