大家好，我是TIMEWELL股份有限公司的濱本 隆太。
「一打開 AliExpress 的網頁，手機上正在播放的音樂就停了。」
2026年8月20日，一位工程師公開了追查這個現象的完整紀錄1。往下挖之後發現，運作中的是透過 Web Audio API 進行的裝置識別（音訊指紋辨識）。同一天，Firefox 的開發者也發表了技術分析2。
這件事在轉述時，有三點特別容易被講錯，先在這裡釐清。
第一，這不是超音波。 講到「用聲音追蹤」，多數人會想到用人耳聽不到的超音波信標串接不同裝置的做法。這次的東西完全不是那一類。
第二，沒有使用麥克風。 被用到的只有音訊的輸出端。並不是有人在聽你說話。這一點若是混淆，對策的方向就會走偏。
第三，並不是主管機關查獲。 經過是：一位工程師追查症狀，瀏覽器開發者做了分析。既沒有行政處分，也沒有任何法律上的認定。
在此前提下，這個手法本身相當值得一看，對策也有其價值。 以下逐步說明。
本文重點
- 症狀是「打開 AliExpress 分頁，多點連線藍牙耳機上來自手機的音樂就停了」。把分頁靜音也沒用
- 原因是一段在音量為零的狀態下連上音訊輸出端的程式碼。沒有聲音，但音訊路徑被占用
- 目的是識別裝置。即使執行相同的計算，不同的 CPU 與瀏覽器所得到的浮點數結果會有些微差異，那個差異就成了指紋
- 沒有使用麥克風，只有輸出端
- 據稱同時還蒐集了 canvas 繪製結果、WebGL、螢幕尺寸、裝置記憶體、外掛程式、WebRTC 行為與效能量測等資訊
- Firefox 早在 2023 年的 118 版就已因應。 輸出值被固定化，99.24% 的使用者落在三個值之中
- 對策是選擇瀏覽器與封鎖程式碼。但只堵住音訊，並不能阻止整體的追蹤
發生了什麼事
症狀
發現者最初注意到的情況是這樣的1。
- 一副多點連線的藍牙耳機，同時連著電腦與手機
- 手機上正在播放音樂
- 在電腦的 Firefox 或 Chrome 打開 AliExpress，手機的音樂就停了
- 關掉 AliExpress 的分頁，馬上就恢復
- 把分頁靜音沒有用
- 網頁上也沒有影片之類的東西在播放
「多點連線」是指耳機可以同時連上兩台裝置，並自動切換到有聲音的那一邊。方便歸方便，但被裝置判定為「正在發出聲音」的那一邊會優先，所以問題就這樣浮上檯面。
追查
發現者先確認網頁上沒有一般的媒體元素或播放呼叫，接著在 AudioContext 的建構子上加了量測，監看 Web Audio API 的使用情形1。
結果發現，有兩個 AudioContext 物件被悄悄建立、進入 running 狀態，而且節點連上了音訊輸出端。
找到的東西
問題出在兩段經過混淆處理的程式碼1。
| 程式碼 | 來源 |
|---|---|
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
用白話說：
- 用鋸齒波振盪器產生聲音
- 用分析節點解析頻率成分
- 用指令碼處理節點處理訊號
- 用增益節點把音量設為零
- 再把它連上音訊的輸出端
第四步把音量設為零，所以人什麼都聽不到。 但第五步連上了輸出端，從作業系統的角度看，這個應用程式正在發出聲音。
這就是藍牙切換被打亂的原因。沒有聲音，音訊路徑卻被占用。 分頁靜音之所以無效，是因為靜音處理的是「聽得到的聲音」，並不會釋放音訊路徑本身。
因為副作用才被發現，是這件事有趣的地方。如果耳機不支援多點連線，很可能到現在都沒有人會注意到。
為什麼用聲音就能識別裝置
這是理解上的關卡，仔細說明。
同樣的計算，答案會有些微不同
電腦處理小數時使用浮點數這種格式，而這種計算一定會產生微小的誤差。
重點在於，誤差出現的方式會因 CPU 的種類與瀏覽器的實作而略有不同。 執行同樣的音訊處理，回傳數值的低位數會有差異。
把這些「微小的差異」收集起來，就能相當細緻地區分裝置。 不需要真的發出聲音，只要在內部執行音訊處理，再讀出計算結果的數值就能成立。
為什麼不是用 Cookie
Cookie 可以刪除，瀏覽器也可以拒絕。指紋辨識是從裝置本身的特性做出識別碼，沒有東西可以刪。即使用無痕模式，基本上也會得到相同的值。
對追蹤方而言有價值，對被追蹤方而言就麻煩。
不只是音訊
據稱這次的程式碼還廣泛蒐集了其他資訊1。
- canvas 的繪製結果（畫同樣的圖形，不同的 GPU 與驅動程式會有些微差異）
- WebGL 的資訊
- 螢幕尺寸
- 裝置記憶體
- 瀏覽器外掛程式
- WebRTC 的行為
- 效能量測
指紋辨識靠的是組合而非單一要素來提高精度。 每一項單獨看都算不上什麼，疊上十項二十項，就能相當有把握地鎖定個體。
這一點在思考對策時很重要。 只堵住音訊，其他路徑依然存在。
Firefox 三年前就出手了
Firefox 的開發者 Tom Ritter 在同一天，也就是2026年8月20日發表了技術分析2。重點如下。
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 的建立1。
||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日施行3。
經營電信事業者（網站經營者、應用程式提供者等）在向使用者終端發送指示外部傳送的程式時，應事先將所傳送的使用者相關資訊之內容等，通知或公告（置於使用者易於知悉的狀態）
對象不限於 Cookie，而是涵蓋「使用標籤或資訊蒐集模組將使用者相關資訊傳送至外部的情形」。透過指紋辨識取得的資訊往外傳送，在概念上也落在這個射程內。
關於適用對象，日本總務省的說明是3：
像線上購物商城這樣，提供可透過網際網路在多家商店購物、或購買多個賣家商品之「場域」的服務，屬於「電信事業」，並且也屬於「對使用者利益影響不小的電信服務」，因此適用外部傳送規律
也就是說，這類服務對日本的使用者負有通知、公告的義務。
先說清楚，我並不是在主張哪一家業者違反了這項規律。 通知與公告是否適當，需要逐一檢視各家公開的內容，主管機關也未做出任何認定。
台灣的情況
台灣目前沒有與上述日本規定直接對應的專門條文。不過個人資料保護法的定義本身相當寬。
該法第2條第1款這樣定義4：
個人資料：指自然人之姓名、出生年月日、國民身分證統一編號、護照號碼、特徵、指紋、婚姻、家庭、教育、職業、病歷、醫療、基因、性生活、健康檢查、犯罪前科、聯絡方式、財務情況、社會活動及其他得以直接或間接方式識別該個人之資料。
關鍵在最後的「其他得以直接或間接方式識別該個人之資料」。裝置指紋本身不會直接寫出姓名，但若與其他資訊結合而能夠間接識別特定個人，就有可能落入這個範圍。
不過我要誠實說明，這是就條文文義所做的推論，並非已確立的行政解釋或判決見解。 個別案件如何認定，仍需視具體情況。
另外，台灣正在建立個人資料保護的獨立監督機制，目前設有個人資料保護委員會籌備處。制度仍在成形階段，後續的解釋與函釋值得持續留意。
站在使用者的角度，能做的是實際去讀服務所公開的隱私權政策。 究竟蒐集了什麼、傳送到哪裡，理應寫在那裡。
從這件事可以學到的
一、「看不見的處理」是靠副作用被發現的
這次的起點是音樂停了。不是有人偵測到隱私侵害，而是有人注意到不方便。
反過來說，只要實作上沒有副作用，就會一直運作而無人察覺。 這不限於這個案例，對所有在客戶端執行的程式碼都成立。
二、瀏覽器端的防護確實有效
Firefox 三年前加入的措施，這次直接發揮了作用。使用者什麼都不用做就被保護了。
「隱私保護功能」常常被抽象地談論，能看到具體手法被具體防住的案例，相當難得。
三、單一對策不夠
再說一次，堵住音訊，canvas 與 WebGL 依然存在。指紋辨識是整體戰。 堵住一個就安心，才是最危險的。
結語
- AliExpress 的網頁上有一段程式碼，在音量為零的狀態下連上音訊輸出端。沒有聲音，但音訊路徑被占用，打亂了藍牙多點連線的切換
- 目的是識別裝置，做法是利用浮點數計算的細微差異，並未使用麥克風
- 這與超音波信標是不同的技術，也不是主管機關查獲
- 據稱同時還蒐集了 canvas、WebGL、螢幕尺寸、裝置記憶體等資訊
- Firefox 118 版（2023年）已因應。 99.24% 的使用者落在三個值之中，作為指紋已不成立
- 個人的對策是瀏覽器的防護功能與封鎖程式碼。封鎖規則容易因路徑變更而失效
- 組織應以政策統一，不要交給個人設定
- 日本已有明文的外部傳送規律；台灣則需就個資法「間接識別」的文義來理解，且監督機制仍在建置中
我們平時處理的是 AI 與資訊安全的實作。這件事讓我印象深刻的是，在「有沒有惡意」之前，先成為問題的是「使用者是否看得見自己身上發生了什麼」。
把音量設為零的實作，推測當初的判斷是「聽不到所以無害」。但在使用者的環境中，確實造成了不便。 在撰寫那些會在看不見的地方運作的程式碼時，我希望自己能保有這個視角。
Footnotes
-
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 ↩3 ↩4 ↩5 ↩6
-
Tom Ritter「WebAudio Fingerprinting and Alibaba」（2026年8月20日）. https://ritter.vg/blog-webaudio_alibaba.html ↩ ↩2
-
日本總務省「外部傳送規律」說明頁（日文）. https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/gaibusoushin_kiritsu.html ↩ ↩2
-
個人資料保護法 第2條. 全國法規資料庫. https://law.moj.gov.tw/LawClass/LawSingle.aspx?pcode=I0050021&flno=2 ↩
