動作感測器透過校準雜訊洩露穩定的裝置指紋。iOS 已用權限提示封堵，而 Android 上的 Chrome 至今仍是預設放行、靜默可讀。
Canvas 與 WebGL 指紋識別讀取的是裝置如何渲染。感測器指紋識別讀取的是完全不同的東西：裝置的實體硬體如何運動——或者更精確地說，它如何回報一次從未真實發生過的運動。每一顆加速度計、陀螺儀與磁力計，出廠時就帶有微小、永久的製造誤差，而這些晶片暴露給網頁的原始資料，正帶著這份誤差作為一種簽章。本文將探討 DeviceMotion、DeviceOrientation 與 Generic Sensor API 家族如何暴露這項訊號、為什麼它幾乎完全是手機與平板電腦特有的現象，以及那道在 iOS 上封堵了它的權限關卡，為何始終沒有出現在 Android 上。
核心要點
DeviceMotionEvent與DeviceOrientationEventAPI 會暴露裝置運動硬體的即時讀數。較新的 Generic Sensor API 系列類別（Accelerometer、Gyroscope）讀取的是同一套硬體，但僅 Chromium 支援——Safari 與 Firefox 都未實作。- 製造公差讓每一顆加速度計與陀螺儀晶片都帶有輕微但一致的偏移與雜訊模式——一種校準指紋，它在不同工作階段、不同瀏覽器甚至恢復原廠設定後依然保持穩定，因為它烙印在實體矽晶片本身，而不是任何軟體狀態裡。
- 這是一種行動裝置專屬向量：筆記型電腦與桌上型電腦通常根本沒有加速度計或陀螺儀，因此這項訊號幾乎只存在於手機與平板電腦上。
- 權限管控是分裂的，而非普遍存在。 自 iOS 13 起，蘋果要求必須先跳出明確的權限提示，這確實關閉了這項技術在 iOS 上的靜默版本。而 Chromium 從不跳出提示：它自己的設計文件就把加速度計與陀螺儀定為自動授予。在 Android 上，頂層 HTTPS 頁面至今仍可在毫無提示的情況下讀取校準雜訊。
- BrowserInsight 的指紋檢測會將裝置暴露的訊號一併呈現，行動裝置指紋識別指南則介紹了這項訊號如何融入更廣泛的行動追蹤全貌。
DeviceMotion、DeviceOrientation 與 Generic Sensor API
有兩代彼此重疊的 API 會向網頁暴露動作資料。較舊的一對——DeviceMotionEvent 與 DeviceOrientationEvent——只要綁定監聽器就會持續觸發，以一般事件屬性的形式提供加速度、旋轉速率與方向角：
window.addEventListener('devicemotion', (event) => {
const { x, y, z } = event.accelerationIncludingGravity;
// 即使裝置靜止放在桌上，x、y、z 也會有輕微飄移
});
較新的 Generic Sensor API 家族——Accelerometer、Gyroscope 與 Magnetometer——用專屬的感測器物件取代了以事件為基礎的模型，指令碼可以直接建構、設定並輪詢這些物件。（W3C 的動作感測器說明文件是一份非規範性的工作小組說明，有助於理解它們之間的關係；這些介面本身則由各自獨立的規範定義。）
const sensor = new Accelerometer({ frequency: 60 });
sensor.addEventListener('reading', () => {
console.log(sensor.x, sensor.y, sensor.z);
});
sensor.start();
關於適用範圍有兩點需要說明。Generic Sensor 系列類別是 Chromium 獨有的特性：Chrome、Edge 與 Opera 支援它們，而 Safari 與 Firefox 既未實作 Accelerometer 也未實作 Gyroscope，因此那對較舊的事件 API 仍是唯一能跨所有引擎運作的途徑。此外在 Chromium 內部，Magnetometer 被放在 #enable-generic-sensor-extra-classes 實驗旗標之後，並未預設開啟——一般頁面無法像讀取加速度計與陀螺儀那樣讀到磁力計資料。
兩種方式最終讀取的都是同一套底層硬體。就指紋識別而言，重要的不是哪個 API 提供了這些數字——而是即使裝置靜止不動，這些數字裡究竟藏著什麼。
校準雜訊作為穩定的裝置級 ID
把手機平放在桌上，查詢它的加速度計。理論上它應該回報 (0, 0, 9.8)——只有重力，別無其他。實際上它會回報類似 (0.013, -0.007, 9.79) 的數值：每個軸上都有微小的非零讀數。這種偏差並非日常意義上的量測誤差——它是加速度計的出廠校準值，而且相當一致。MEMS 加速度計與陀螺儀都是量產製造的，每顆晶片在製造過程中都會帶上略有不同的偏移量與比例因子誤差。針對以感測器為基礎的裝置指紋識別，學術研究已多次發現這個偏移向量確實帶有可觀的熵——足以協助區分同一型號的不同個體，在綜合多個軸、多個感測器的讀數時尤其如此。
這正是校準雜訊與 Canvas 或 WebGL 輸出在本質上不同之處。切換瀏覽器，或是 GPU 驅動程式改變了點陣化方式，Canvas 雜湊值就會跟著改變；安裝一款新字型，字型清單也會隨之改變。校準雜訊不會因為這些而改變——它能在瀏覽器更新、恢復原廠設定，乃至重灌作業系統之後依然存在，甚至在同一支手機上把 Chrome 換成 Firefox 也不會改變，因為它是實體感測器晶片本身的特性，而不是任何指令碼能夠清除的軟體狀態。指令碼只需擷取幾秒鐘「靜止」狀態下的讀數，取出每個軸的平均偏移量，就能得到一個在裝置整個使用壽命內都穩定不變的數值。
權限管控——以及它管不到的地方
多年來，DeviceMotionEvent 與 DeviceOrientationEvent 觸發時完全不需要任何權限提示——任何頁面只要綁定一個監聽器，就能在背景靜默開始讀取校準雜訊，使用者毫無察覺。這個狀況從 iOS 13 開始改變，蘋果開始要求先明確呼叫 DeviceOrientationEvent.requestPermission()——這個呼叫必須源自使用者手勢（例如一次點擊）——Safari 才會開始發送任何動作或方向事件。頁面不能再只靠載入就讀取加速度計；它必須先詢問，而使用者必須先看到並同意一個系統對話框。
人們很容易假設其他引擎也跟進了。Chromium 並沒有。這個細節值得說清楚，因為它牽涉到全球大多數的手機。
Chromium 確實限制了誰能碰到這些感測器。存取受 Permissions Policy 機制管控，accelerometer 與 gyroscope 的預設允許清單是 'self'——因此跨來源的第三方 iframe 讀不到它們——讀取還要求安全（HTTPS）環境，以及處於頂層且取得焦點的瀏覽環境。但 Chromium 不會做的事，是詢問使用者。它自己的 Generic Sensor 設計文件把這個模型寫得很直白：加速度計與陀螺儀是**「自動授予 + 允許退出」（auto-grant + opt-out）**。權限會被直接授予，全程不會出現任何提示。
這也是為什麼 accelerometer、gyroscope 與 magnetometer 會作為可查詢項目，出現在更廣泛的 Permissions API 指紋向量中——但一個名稱可被查詢，並不等於使用者被詢問過。
所以如實總結起來，這是一種分裂，而非一場乾淨的勝利：原始的校準訊號在所有平台的硬體裡都依然存在。在 iOS 上，指令碼確實無法在使用者點下「允許」之前採集到它。而在 Android 版 Chrome 上，一個普通的頂層 HTTPS 頁面照樣可以綁定 devicemotion 監聽器，在毫無提示、毫無可見跡象的情況下讀取校準雜訊——和十年前幾乎沒有差別。iOS 關閉了這項技術的靜默版本；Chromium 只是收窄了入口，卻從未把這個決定交到使用者面前。
為什麼這是行動裝置專屬向量
筆記型電腦或桌上型電腦內建加速度計與陀螺儀，通常只出於一個常見原因——某些機型的闔蓋偵測或搖動偵測功能——但絕大多數桌面硬體根本不配備這套感測器元件，DeviceMotionEvent 與 Generic Sensor 系列類別在一般桌面瀏覽器上也就無從讀取。手機與平板電腦則恰恰相反：動作與方向感測器幾乎無所不在，因為作業系統本身就仰賴它們來實現螢幕旋轉、計步與擴增實境等功能，所以這套硬體——以及暴露它的 API 層——在這類裝置上實際上是普遍存在的。
這也是這項技術能與更廣泛的行動裝置指紋識別全貌互補、而非重複的原因：螢幕尺寸與裝置像素比只能推斷出你手上拿的大概是哪個型號，而感測器校準雜訊——在仍可讀取的地方——卻能一路縮小到那一台具體的機器。正因為行動平台上的 GPU 與字型熵值早已被量產抹平，這種「精確到個體」的能力才顯得格外有價值。它只是整體瀏覽器指紋識別全貌中的一小塊，但在行動裝置流量裡，它是少數即使使用者把裝置上其他一切都重置了，依然能存活下來的訊號之一。
緩解措施
- 讓作業系統與瀏覽器保持在最新版本。 iOS 的權限關卡是透過瀏覽器更新推送的，而不是一個可選的開關設定——過時的行動瀏覽器可能仍會在不跳出提示的情況下暴露動作資料。
- 拒絕你想不出明確用途的動作／方向權限請求——同時也要知道什麼時候根本不會有提示。 在 iOS 上，一個既不是遊戲、也不是 AR 功能或計步應用程式的頁面卻要求加速度計權限，通常沒有正當理由，而且拒絕確實有效。但在 Android 版 Chrome 上，往往根本不會跳出任何可供拒絕的提示，所以在那裡，提示並不是一個你能依賴的控制手段。
- 在 Android 上，真正的施力點是你選擇哪一款瀏覽器。 既然 Chromium 是自動授予，有意義的緩解措施就不是權限提示，而是改用一款在政策層面限制或隨機化感測器存取的瀏覽器——這與我們在隱私工具比較中介紹的是同一類防禦思路。
- 把它當作眾多訊號中的一個來看待。 即使在可讀取的情況下，校準雜訊也只是更大指紋拼圖中的一個軸，與螢幕參數、GPU 字串與權限狀態並列——沒有哪個單一訊號是追蹤者的萬能鑰匙，也沒有哪個單一措施能徹底消除指紋識別風險。
- 檢查你自己的裝置暴露了什麼。 直接在你想評估的手機上執行 BrowserInsight 的指紋檢測，查看瀏覽器目前暴露的即時訊號集合。
常見問題
網站能在我不知情的情況下讀取手機的加速度計嗎？
這取決於你用的是什麼手機。在 iOS 上不行——自 iOS 13 起，Safari 要求透過 DeviceOrientationEvent.requestPermission() 明確跳出權限提示，在你同意之前不會送出任何事件。而在 Android 版 Chrome 上通常可以：Chromium 把加速度計與陀螺儀視為自動授予，不會跳出任何提示。它確實要求 HTTPS、頂層頁面（不能是跨來源 iframe）以及分頁處於焦點狀態——但在這些限制之內，頁面完全可以靜默讀取動作資料。
重置手機會改變它的感測器指紋嗎？
不會。校準雜訊來自加速度計與陀螺儀實體晶片的製造公差，而不是任何軟體狀態。恢復原廠設定、重灌作業系統或更換瀏覽器，都不會改變底層硬體的偏移量。
桌面與筆電瀏覽器也會暴露這項訊號嗎？
很少。多數桌面與筆電硬體根本不配備加速度計或陀螺儀，因此 DeviceMotionEvent 與 Generic Sensor API 系列類別無從回報任何內容。這幾乎完全是手機與平板電腦特有的訊號。
感測器指紋識別比 Canvas 或 WebGL 指紋識別更具識別力嗎？
單獨來看並非如此——它是一個更窄、單一維度的訊號。它對追蹤者的價值在於異常穩定（能在重置與更換瀏覽器後依然存在），並且在行動裝置上可用，而在行動裝置上，字型與 Canvas 渲染等其他高熵桌面訊號相對趨於扁平。
拒絕動作權限提示能完全保護我嗎？
在你確實會看到提示的地方——也就是 iOS——拒絕對該來源是有效的：一個從未取得權限的頁面將得不到任何動作或方向事件。但在 Chromium 上通常根本沒有提示可供拒絕，所以在那裡這並不是一個你能倚仗的控制手段。無論哪一種情況，它都不影響其他被動訊號，例如螢幕尺寸、GPU 渲染器字串或權限狀態，這些訊號頁面仍可在不跳出提示的情況下讀取。
結語
感測器指紋識別是一種狹窄但異常持久的訊號：Canvas 雜湊值或字型清單可能隨軟體更新而改變，而烙印在加速度計或陀螺儀晶片裡的校準偏移量，卻能在裝置的整個使用壽命內保持不變。它也清楚展現了行動裝置與桌面裝置指紋識別的真正分歧：一項在筆記型電腦上幾乎不存在的訊號，在手機上卻近乎無所不在，恰恰是因為這套硬體本身在手機上是普遍存在的。
而權限這個部分，恰恰是多數總結講錯的地方。iOS 在 2019 年確實關閉了這項技術的靜默版本，人們也很容易由此推廣成「瀏覽器已經把這個問題修好了」。但 Chromium 從未引入權限提示——它寫在文件裡的模型是自動授予加上允許退出——所以在佔行動流量多數的 Android 上，頂層 HTTPS 頁面今天讀取校準雜訊的自由度，和 iOS 13 之前相比幾乎沒有改變。無論在哪一邊，底層的物理特性都沒有改變——這正是為什麼這條向量值得被單獨理解，而不是簡單地併入以桌面為中心的指紋識別手冊。
推薦閱讀：
