← 返回 Siami 首頁

AliExpress 網頁悄悄啟動 WebAudio API 偷偷做裝置指紋還把你的藍牙耳機卡死

▲ 497 💬 159
AliExpress 網頁悄悄啟動 WebAudio API 偷偷做裝置指紋還把你的藍牙耳機卡死

編按:本文綜合整理自 laserphile 原技術分析、Hacker News 討論串 與 Firefox 工程師 Tom Ritter 的延伸分析,並加入 Siami 編輯部觀點。

事件:一個安靜的藍牙 bug 揭開電商巨頭的指紋黑箱

2026 年 8 月,網友 emctech(部落格名 laserphile)在 Hacker News 上發了一篇讓人背脊發涼的技術紀錄:他在 Firefox 打開 AliExpress 首頁後,電腦上的多點連線藍牙耳機會立刻「卡」在電腦端,手機音樂再也切不回來。關掉分頁立刻恢復;靜音分頁、靜音 Firefox、靜音 Windows 全部沒用。

關鍵是:頁面上沒有任何 <audio>、<video> 元素、沒有媒體播放請求、沒有 Media Session 啟用,從所有常見指標看都是「靜音狀態」。但藍牙硬體就是被佔住了。


調查過程:把 AudioContext 包起來觀察

emctech 採取的偵測手法是直接覆寫 window.AudioContext 建構子,並攔截 AudioNode.prototype.connect(),記錄所有建立音訊處理圖的呼叫。

結果發現:AliExpress 首頁載入後幾秒鐘,靜默地建立了兩個 AudioContext 物件,兩個都進入 running 狀態,而且都接到了 AudioContext.destination(系統音訊目的地)。呼叫堆疊指向兩支 Alibaba 的腳本:

https://assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
https://assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js

這兩支腳本都放在 AWSC 目錄下,是阿里巴巴瀏覽器安全與反濫用工具的一部分,原始碼經過重度混淆。


技術原理:鋸齒波 → 分析節點 → 零增益輸出

兩支腳本各建立一條 WebAudio 處理鏈:

鋸齒波振盪器 → AnalyserNode → ScriptProcessorNode → 增益設為 0 → 系統音訊輸出

振盪器產生已知波形,分析節點測量瀏覽器音訊引擎處理後的結果,腳本讀取頻率數據。音量歸零所以使用者聽不到,但「接上 destination」這件事本身會讓瀏覽器真的處理這條音訊鏈。

這跟自動播放影片完全不同:

  1. 沒有 <audio> / <video> 元素 → 分頁靜音鍵沒東西可靜
  2. 沒有 MediaSession 活動 → 作業系統不知道有媒體
  3. 沒有發聲 → 使用者無感

但在 OS 與藍牙驅動層,這條處理鏈真的存在、真的佔住了音訊路徑,於是「多點連線」耳機就再也切不回手機。


不只是音訊:完整裝置指紋採集清單

WebAudio 只是冰山一角。檢視這兩支混淆 bundle 後發現,它們同時查詢或測量:

  • Canvas 渲染與 toDataURL() 雜湊
  • WebGL renderer、擴充、shader 精度
  • 螢幕與視窗尺寸、device pixel ratio
  • CPU 核心數、navigator.deviceMemory
  • 已安裝瀏覽器外掛
  • 支援的 audio / video 編碼格式
  • WebRTC 行為
  • performance.timing 微秒級時序
  • 滑鼠、觸控、焦點、捲動事件
  • 裝置動作感測器(devicemotion / deviceorientation)
  • 自動化瀏覽器特徵

最後把結果序列化、加密後,送到阿里巴巴遙測服務。


🚨 為什麼這件事重要

這是第一個有完整技術取證的案例,證明主流電商在「無敏感操作發生時」就在首頁對所有訪客做廣譜裝置指紋。幾個關鍵意義:

第一,使用者沒辦法防禦。傳統的「看到媒體播放就靜音」對這條攻擊鏈無效,因為它走的是 WebAudio 即時處理 API,不是媒體元素。分頁靜音鍵、Windows 音量鍵、瀏覽器右鍵關閉音訊 — 全部失效。

第二,硬體副作用是真的。藍牙 multipoint 切不回來不是抽象的「隱私洩漏」,而是實際干擾使用者日常。其他網友實證:iOS 版 AliExpress app 在背景執行時,車用音響會以為在下語音指令(@patspam);Wolt app 在歐洲也出現同樣的 VoiceOver 爆音狀況(@miki123211)。指紋追蹤不只是看,還會動到你的硬體。

第三,這是黑箱作業。腳本經過重度混淆,沒有任何使用者告知、沒有授權請求、沒有 cookie 同意橫幅覆蓋這個行為。歐盟 GDPR、英國 DPA、各國電子通訊法對「未經同意的指紋追蹤」都有罰則,但目前沒看到任何監管機構對電商首頁的隱形 AudioContext 採取行動。


🚨 數據解讀:阿里到底偷了什麼、為什麼可以

單看 WebAudio 指紋本身並不強:瀏覽器版本、作業系統、音訊函式庫、硬體差異造成的波形差異有限。但當它跟 canvas、WebGL、硬體規格、時序、互動資料結合時,雜湊出來的「裝置 ID」就比 cookie 更難繞 — cookie 可以清、指紋很難複製。

從阿里巴巴的角度,這套機制有商業邏輯:

  • 阻擋機器人搶購熱門商品(黃牛自動化)
  • 偵測帳號被盜用、異常登入
  • 防止新客優惠券被一機多帳號濫用
  • 評價造假、刷單偵測

但「合理的反詐欺目的」不等於「可以無告知、無授權、無使用者中控」。Web 平台可以提示「我們為了保護帳號會檢查裝置特徵」、可以在要求麥克風/視訊授權時順便要求音訊播放授權、可以讓使用者在隱私設定裡關閉指紋採集 — 但這些全部都沒有做。


Firefox 開發者親上火線:「WebAudio 指紋其實沒那麼有效」

事件在 HN 爆紅後,Firefox 工程師 Tom Ritter 親自發了一篇技術澄清,核心論點是:

WebAudio 指紋追蹤在 Firefox 已經幾乎失效。

關鍵數據:

  • Firefox 在 3 年前的 118 版本就把 WebAudio 處理結果做成了常數
  • 99.24% 的使用者會落入 3 個值之一,剩下 0.76% 採集失敗
  • 這 3 個值對應 CPU 架構差異:x86 / 無 FMA 的 x64、有 FMA3 的 x64、ARM NEON 指令集
  • Chrome、Brave、Safari 也都做了類似的常數化處理
  • 「Alibaba 這次被發現,是因為他們改了一個東西剛好讓使用者聽得到/感覺到。如果受害者沒注意到,這個後門可能還在」

Tom Ritter 的結論很直白:「WebAudio 指紋追蹤在現代瀏覽器幾乎沒用,但其他向量的指紋追蹤還是會存在。除非有監管行動介入,否則網站還是會繼續這樣做。」


🚨 質疑:作者的反指紋行為,跟產業現實的落差

emctech 最後決定用 uBlock Origin 兩條窄規則封鎖 collina.js 與 fireyejs.js:

! AliExpress AWSC fingerprinting scripts
||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

測試結果封鎖後首頁正常顯示,沒有 AudioContext 跑起來,音樂也不會被中斷。

但他自己也點出三個問題:

  1. 這只是治標:規則只蓋兩支腳本,未來阿里換檔名或改目錄就失效
  2. 封鎖可能引發額外 CAPTCHA:因為這兩支是反詐欺系統,封鎖後系統可能把你當機器人,登入、結帳都可能被擋
  3. 沒有業界標準:這件事發生後,沒有任何瀏覽器廠商正式公告「電商首頁靜默 AudioContext 違反我們的條款」、沒有任何監管機關發出指引

給讀者的行動建議

  1. 如果你是 AliExpress 用戶:裝 uBlock Origin,把上面兩條規則加到「My filters」。結帳失敗時暫時關閉規則。
  2. 如果你是開發者:檢查自己網站有沒有任何「沒在使用者感知下呼叫 AudioContext.connect(destination)」的第三方腳本。這是新的合規紅線。
  3. 如果你是 macOS / Windows / Linux 多點耳機使用者:發現音樂突然卡住、分頁靜音無效時,先關閉電商分頁再說,別急著重灌藍牙驅動。
  4. 如果你是監管者:這個案例是教科書等級的「無告知隱形追蹤」範本,可以拿來當 GDPR / 個資法裁罰示範。

這件事接下來會怎麼走

  • 短期:AliExpress 大概率會改檔名、換目錄規避 uBlock 規則,進入貓抓老鼠循環
  • 中期:蘋果 Safari、Chrome 可能會對「未經使用者互動就 connect AudioContext 到 destination」加強限制或預設阻擋
  • 長期:如果歐盟或英國 DPA 真的因為這個案例開罰,會是第一次有監管機關針對「隱形 WebAudio 指紋」做出明確判決,對整個電商產業會有寒蟬效應

但 Tom Ritter 說得最直接:「除非有監管行動,我不期待它會消失。」


來源與延伸閱讀

網友熱門留言 (5)

#1 patspam ▲ 612
我過去幾週也注意到同樣的事:如果最近開過 iOS 版 AliExpress app(即使在背景),我的車用音響會突然以為我在下語音指令。把 app 砍掉就立刻恢復。發生幾次後我直接卸載了。
#2 CTDOCodebases ▲ 487
他們做這件事已經好幾個月了。沒有聲音播放,但音訊會像麥克風被啟用那樣變化。我檢查過權限確認沒有麥克風存取,當時就猜是在做指紋追蹤。
#3 compsciphd ▲ 341
我認為播放音訊的能力應該像 webcam 一樣需要使用者授權。但很多人會願意讓 AliExpress 播放音訊,因為網站上確實有影片要看。如果設計成『單次授權』會是比較合理的折衷。
#4 spicyjpeg ▲ 289
瀏覽器指紋追蹤的花樣可以很有創意。eBay 之前的 WebSocket 埠號掃描、Reddit 多年前濫用 DRM 與 JavaScript JIT 的漏洞,都是只靠普通瀏覽器 API 就能在背景做深度探測的經典案例。
#5 miki123211 ▲ 156
啊,原來這就是 Wolt(歐洲版 DoorDash)在做的事!我用 app 時 Voice Over (iOS 螢幕閱讀器) 會爆音、隨機變音量,我本來以為只是 iOS 的怪問題。