AliExpress 的音訊指紋辨識｜藍牙為什麼會斷，以及現在能採取的對策

大家好，我是TIMEWELL股份有限公司的濱本 隆太。

「一打開 AliExpress 的網頁，手機上正在播放的音樂就停了。」

2026年8月20日，一位工程師公開了追查這個現象的完整紀錄¹。往下挖之後發現，運作中的是透過 Web Audio API 進行的裝置識別（音訊指紋辨識）。同一天，Firefox 的開發者也發表了技術分析²。

這件事在轉述時，有三點特別容易被講錯，先在這裡釐清。

第一，這不是超音波。 講到「用聲音追蹤」，多數人會想到用人耳聽不到的超音波信標串接不同裝置的做法。這次的東西完全不是那一類。

第二，沒有使用麥克風。 被用到的只有音訊的輸出端。並不是有人在聽你說話。這一點若是混淆，對策的方向就會走偏。

第三，並不是主管機關查獲。 經過是：一位工程師追查症狀，瀏覽器開發者做了分析。既沒有行政處分，也沒有任何法律上的認定。

在此前提下，這個手法本身相當值得一看，對策也有其價值。 以下逐步說明。

本文重點

• 症狀是「打開 AliExpress 分頁，多點連線藍牙耳機上來自手機的音樂就停了」。把分頁靜音也沒用
• 原因是一段在音量為零的狀態下連上音訊輸出端的程式碼。沒有聲音，但音訊路徑被占用
• 目的是識別裝置。即使執行相同的計算，不同的 CPU 與瀏覽器所得到的浮點數結果會有些微差異，那個差異就成了指紋
• 沒有使用麥克風，只有輸出端
• 據稱同時還蒐集了 canvas 繪製結果、WebGL、螢幕尺寸、裝置記憶體、外掛程式、WebRTC 行為與效能量測等資訊
• Firefox 早在 2023 年的 118 版就已因應。 輸出值被固定化，99.24% 的使用者落在三個值之中
• 對策是選擇瀏覽器與封鎖程式碼。但只堵住音訊，並不能阻止整體的追蹤

發生了什麼事

症狀

發現者最初注意到的情況是這樣的¹。

• 一副多點連線的藍牙耳機，同時連著電腦與手機
• 手機上正在播放音樂
• 在電腦的 Firefox 或 Chrome 打開 AliExpress，手機的音樂就停了
• 關掉 AliExpress 的分頁，馬上就恢復
• 把分頁靜音沒有用
• 網頁上也沒有影片之類的東西在播放

「多點連線」是指耳機可以同時連上兩台裝置，並自動切換到有聲音的那一邊。方便歸方便，但被裝置判定為「正在發出聲音」的那一邊會優先，所以問題就這樣浮上檯面。

追查

發現者先確認網頁上沒有一般的媒體元素或播放呼叫，接著在 AudioContext 的建構子上加了量測，監看 Web Audio API 的使用情形¹。

結果發現，有兩個 AudioContext 物件被悄悄建立、進入 running 狀態，而且節點連上了音訊輸出端。

找到的東西

問題出在兩段經過混淆處理的程式碼¹。

程式碼	來源
collina.js	assets.aliexpress-media.com/g/AWSC/uab/1.140.0/
fireyejs.js	assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/

它們所建構的音訊圖，正是這件事的核心。

Sawtooth oscillator → AnalyserNode → ScriptProcessorNode → GainNode（gain = 0）→ AudioContext.destination

用白話說：

1. 用鋸齒波振盪器產生聲音
2. 用分析節點解析頻率成分
3. 用指令碼處理節點處理訊號
4. 用增益節點把音量設為零
5. 再把它連上音訊的輸出端

第四步把音量設為零，所以人什麼都聽不到。 但第五步連上了輸出端，從作業系統的角度看，這個應用程式正在發出聲音。

這就是藍牙切換被打亂的原因。沒有聲音，音訊路徑卻被占用。 分頁靜音之所以無效，是因為靜音處理的是「聽得到的聲音」，並不會釋放音訊路徑本身。

因為副作用才被發現，是這件事有趣的地方。如果耳機不支援多點連線，很可能到現在都沒有人會注意到。

為什麼用聲音就能識別裝置

這是理解上的關卡，仔細說明。

同樣的計算，答案會有些微不同

電腦處理小數時使用浮點數這種格式，而這種計算一定會產生微小的誤差。

重點在於，誤差出現的方式會因 CPU 的種類與瀏覽器的實作而略有不同。 執行同樣的音訊處理，回傳數值的低位數會有差異。

把這些「微小的差異」收集起來，就能相當細緻地區分裝置。 不需要真的發出聲音，只要在內部執行音訊處理，再讀出計算結果的數值就能成立。

為什麼不是用 Cookie

Cookie 可以刪除，瀏覽器也可以拒絕。指紋辨識是從裝置本身的特性做出識別碼，沒有東西可以刪。即使用無痕模式，基本上也會得到相同的值。

對追蹤方而言有價值，對被追蹤方而言就麻煩。

不只是音訊

據稱這次的程式碼還廣泛蒐集了其他資訊¹。

• canvas 的繪製結果（畫同樣的圖形，不同的 GPU 與驅動程式會有些微差異）
• WebGL 的資訊
• 螢幕尺寸
• 裝置記憶體
• 瀏覽器外掛程式
• WebRTC 的行為
• 效能量測

指紋辨識靠的是組合而非單一要素來提高精度。 每一項單獨看都算不上什麼，疊上十項二十項，就能相當有把握地鎖定個體。

這一點在思考對策時很重要。 只堵住音訊，其他路徑依然存在。

Firefox 三年前就出手了

Firefox 的開發者 Tom Ritter 在同一天，也就是2026年8月20日發表了技術分析²。重點如下。

Firefox 118 版（2023年）的防指紋追蹤功能，已納入將 Web Audio 輸出值固定化的措施。

結果就是這個數字。

99.24% 的使用者屬於三個值之一

換句話說，從絕大多數使用者身上只能取到相同的值。指紋若要有用，數值必須夠分散。只有三種的話，作為識別碼幾乎沒有作用。

剩下的三種差異，來自 CPU 架構。

分類	內容
1	不支援 FMA 的 x86 / x64
2	支援 FMA3 的 x64
3	ARM NEON

這是積和運算實作差異反映在結果上。屬於硬體層面的根本差異，無法完全抹平。 不過只有三個分類，作為識別碼的價值已經很低。

他的結論是：在重視隱私的瀏覽器上，Web Audio 指紋辨識幾乎無用；但瀏覽器指紋辨識整體而言依然有效。

這個整理是準確的。 不是「用 Firefox 就不會被追蹤」，而是「這個手法對 Firefox 無效」。

對策

以下依立場整理。

個人可以做的

一、啟用瀏覽器的防指紋追蹤

使用 Firefox 時，若防指紋追蹤功能已啟用，Web Audio 的部分就會如前所述被固定化。請在設定的「隱私權與安全性」中確認加強型追蹤保護的層級。

Tor Browser 有更徹底的措施。Brave 也實作了同類的防護（將數值稍作隨機化的方式）。

二、用內容封鎖器擋掉相關程式碼

發現者在 uBlock Origin 中加入了以下規則，直接阻止 AudioContext 的建立¹。

||assets.aliexpress-media.com/g/AWSC/uab/*/collina.js$script,domain=aliexpress.com
||assets.aliexpress-media.com/g/AWSC/fireyejs/*/fireyejs.js$script,domain=aliexpress.com

據其說明，藍牙的行為也因此恢復正常。

不過有一點要注意。 程式碼的路徑中含有版本號，規則是用 * 吸收的。只要來源的路徑結構改變，規則就會失效。 作為長期對策，前述的瀏覽器端防護比較可靠。

三、只想解決症狀的話

如果「追蹤先放一邊，音樂會停比較困擾」，關掉那個分頁是最確實的做法。靜音沒有用。暫時關閉耳機的多點連線，也是一種迴避方式。

組織（資訊部門）可以做的

以企業角度來看，視角就不同了。問題是**如何看待「公司配發的裝置在外部網站被唯一識別」**這件事。

一、用瀏覽器政策統一防護

不要交給員工個別設定，而是以管理者政策啟用防指紋追蹤。Firefox 有 Enterprise Policy，Chrome 有 Group Policy 或 Cloud Management。「請各位自行開啟」在營運上是不成立的。

二、集中派送擴充功能

內容封鎖器不要交給個人處理，而是以允許清單的方式由組織派送。員工能夠任意安裝擴充功能的狀態，本身就是另一種風險。

三、不讓公務裝置開啟不必要的網站

講白一點，多數情況下並沒有在公務裝置上開購物網站的必要。 用網址過濾來處理最有效。

四、要能察覺「沒有聲音卻占用了音訊裝置」

這次的事情，是因為出現副作用才被發現的。 沒有副作用就不會有人注意到。反過來說，具備察覺裝置異常行為（音訊裝置被意外占用、CPU 使用率不自然上升）的機制，遇到這類東西時發現的機會就會提高。

五、不要反應過度

這一點也要寫下來。指紋辨識本身在廣告與防詐兩種脈絡下都被廣泛使用。 這次被點名的程式碼中，至少有一支看來是用於偵測異常行為的。若把「追蹤」直接等同於「惡意」，判斷就會出錯。

問題與其說在技術本身，不如說在使用者無從得知的情況下進行，以及這次確實產生了副作用。

制度面怎麼看

法規部分，先說一個已經有明文規定的例子，再回到台灣。

日本已有明文的「外部傳送規律」

日本於2022年6月修正電信事業法，新增了外部傳送規律，並自2023年6月16日施行³。

經營電信事業者（網站經營者、應用程式提供者等）在向使用者終端發送指示外部傳送的程式時，應事先將所傳送的使用者相關資訊之內容等，通知或公告（置於使用者易於知悉的狀態）

對象不限於 Cookie，而是涵蓋「使用標籤或資訊蒐集模組將使用者相關資訊傳送至外部的情形」。透過指紋辨識取得的資訊往外傳送，在概念上也落在這個射程內。

關於適用對象，日本總務省的說明是³：

像線上購物商城這樣，提供可透過網際網路在多家商店購物、或購買多個賣家商品之「場域」的服務，屬於「電信事業」，並且也屬於「對使用者利益影響不小的電信服務」，因此適用外部傳送規律

也就是說，這類服務對日本的使用者負有通知、公告的義務。

先說清楚，我並不是在主張哪一家業者違反了這項規律。 通知與公告是否適當，需要逐一檢視各家公開的內容，主管機關也未做出任何認定。

台灣的情況

台灣目前沒有與上述日本規定直接對應的專門條文。不過個人資料保護法的定義本身相當寬。

該法第2條第1款這樣定義⁴：

個人資料：指自然人之姓名、出生年月日、國民身分證統一編號、護照號碼、特徵、指紋、婚姻、家庭、教育、職業、病歷、醫療、基因、性生活、健康檢查、犯罪前科、聯絡方式、財務情況、社會活動及其他得以直接或間接方式識別該個人之資料。

關鍵在最後的「其他得以直接或間接方式識別該個人之資料」。裝置指紋本身不會直接寫出姓名，但若與其他資訊結合而能夠間接識別特定個人，就有可能落入這個範圍。

不過我要誠實說明，這是就條文文義所做的推論，並非已確立的行政解釋或判決見解。 個別案件如何認定，仍需視具體情況。

另外，台灣正在建立個人資料保護的獨立監督機制，目前設有個人資料保護委員會籌備處。制度仍在成形階段，後續的解釋與函釋值得持續留意。

站在使用者的角度，能做的是實際去讀服務所公開的隱私權政策。 究竟蒐集了什麼、傳送到哪裡，理應寫在那裡。

從這件事可以學到的

一、「看不見的處理」是靠副作用被發現的

這次的起點是音樂停了。不是有人偵測到隱私侵害，而是有人注意到不方便。

反過來說，只要實作上沒有副作用，就會一直運作而無人察覺。 這不限於這個案例，對所有在客戶端執行的程式碼都成立。

二、瀏覽器端的防護確實有效

Firefox 三年前加入的措施，這次直接發揮了作用。使用者什麼都不用做就被保護了。

「隱私保護功能」常常被抽象地談論，能看到具體手法被具體防住的案例，相當難得。

三、單一對策不夠

再說一次，堵住音訊，canvas 與 WebGL 依然存在。指紋辨識是整體戰。 堵住一個就安心，才是最危險的。

結語

• AliExpress 的網頁上有一段程式碼，在音量為零的狀態下連上音訊輸出端。沒有聲音，但音訊路徑被占用，打亂了藍牙多點連線的切換
• 目的是識別裝置，做法是利用浮點數計算的細微差異，並未使用麥克風
• 這與超音波信標是不同的技術，也不是主管機關查獲
• 據稱同時還蒐集了 canvas、WebGL、螢幕尺寸、裝置記憶體等資訊
• Firefox 118 版（2023年）已因應。 99.24% 的使用者落在三個值之中，作為指紋已不成立
• 個人的對策是瀏覽器的防護功能與封鎖程式碼。封鎖規則容易因路徑變更而失效
• 組織應以政策統一，不要交給個人設定
• 日本已有明文的外部傳送規律；台灣則需就個資法「間接識別」的文義來理解，且監督機制仍在建置中

我們平時處理的是 AI 與資訊安全的實作。這件事讓我印象深刻的是，在「有沒有惡意」之前，先成為問題的是「使用者是否看得見自己身上發生了什麼」。

把音量設為零的實作，推測當初的判斷是「聽不到所以無害」。但在使用者的環境中，確實造成了不便。 在撰寫那些會在看不見的地方運作的程式碼時，我希望自己能保有這個視角。

---

Footnotes

1. laserphile「AliExpress webpage keeping multipoint bluetooth headphones from playing phone audio」（2026年8月20日）. https://blog.laserphile.com/2026/08/aliexpress-webpage-keeping-multipoint.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Tom Ritter「WebAudio Fingerprinting and Alibaba」（2026年8月20日）. https://ritter.vg/blog-webaudio_alibaba.html ↩ ↩²

3. 日本總務省「外部傳送規律」說明頁（日文）. https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/gaibusoushin_kiritsu.html ↩ ↩²

4. 個人資料保護法 第2條. 全國法規資料庫. https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=I0050021&flno=2 ↩