
AliExpress:Web Audio APIによるフィンガープリンティング
Security Network目次
オンラインショップを開いた途端、スマートフォンの音楽が止まります。ブラウザでは動画を再生しておらず、広告の音も聞こえません。タブをミュートしても変化せず、AliExpressのタブを閉じて初めてBluetoothヘッドフォンが正常にスマートフォンへ戻ります。
Bluetooth Multipointの不具合に見えた現象は、開発者のMatt CallaghanをAliExpressのホームページにある二つの高度に難読化されたJavaScriptファイルへ導きました。どちらもバックグラウンドで動作し続けるWeb Audioグラフを作成していました。出力レベルはゼロなので音は聞こえません。それでもブラウザ、OS、ヘッドフォンにとって音声経路はアクティブなままでした。
意図しないハードウェア上の副作用が、目に見えないブラウザ測定を暴いた点で技術的に興味深い発見です。セキュリティ上はさらに重要です。Web Audioは一要素にすぎず、スクリプトはCanvas、WebGL、画面、ハードウェア、対応メディア形式、WebRTC、ユーザー操作も調べていました。結果は包括的なブラウザおよび端末フィンガープリントに見えます。
この事例を深刻にしているのは秘密めいた音声トリックではなく、測定範囲の広さと、通常のショップホームページを開いた時点で見えないまま始まることです。
Bluetoothの不具合ではなかった不具合
CallaghanはPCとスマートフォンへ同時接続できるMultipointヘッドフォンを使っています。通常は電話から音楽を聴き、PCが実際に音声を再生するとPCへ切り替わります。この優先順位の切り替えが、FirefoxまたはChromeでAliExpressを開くと止まるようになりました。他のブラウザはテストしていません。
一般的な原因は除外されました。音声や動画要素、HTMLMediaElement.play()の呼び出し、アクティブなMedia Session、ネットワーク通信中の明確なメディアファイルはありません。目立ったのは、ページ読み込みの数秒後に問題が始まることだけでした。
そこでCallaghanはWeb Audio APIを計測できるようにしました。AudioContextコンストラクターをラッパーに置き換え、新しい音声コンテキストを記録し、AudioNode.connect()による接続を監視しました。すると二つの実行中コンテキストが現れ、スタックトレースは次のスクリプトを指しました。
assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js
どちらもAWSCパスにあり、その機能からAlibabaのブラウザセキュリティおよび不正検出インフラの一部と考えられます。この帰属は妥当ですが、ファイル名だけでは確定できません。ただしAlibaba CloudはAnti-Bot Web SDKについて、サーバー側評価と組み合わせるWeb Collectorを明記しています。
挙動はさらに絞り込めました。両スクリプト群をブロックすると、Callaghanの対照測定では音声コンテキストも音声出力への接続も作成されませんでした。テストではホームページと通常の商品検索は引き続き機能しました。
Web Audioグラフが実際に行うこと
Web Audioは隠れた盗聴機能ではありません。ゲーム、シンセサイザー、ビデオ会議などのインタラクティブな用途に使われる強力なブラウザインターフェースです。単一の音声ファイルを再生するだけでなく、複数の処理ノードをグラフとして接続できます。
調査されたAliExpressスクリプトは、簡略化すると次のチェーンを構築していました。
のこぎり波を生成するOscillatorNode
-> AnalyserNode
-> ScriptProcessorNode
-> ゲイン0のGainNode
-> AudioContext.destination
オシレーターが既知の信号を生成します。AnalyserNodeが処理データを提供し、JavaScriptが周波数値を読み取ります。その後GainNodeがレベルをゼロにします。信号は聞こえなくなりますが、グラフはAudioContext.destination、つまりリアルタイム出力に接続されたままです。
この接続が副作用を説明します。音量ゼロは処理ゼロではありません。ブラウザはグラフを計算し続け、CallaghanのWindows環境ではPCの音声経路をアクティブに保つのに十分だったようです。そのためMultipointの自動切り替えはPCをアクティブな音源と判断し続けました。
純粋な計算にはOfflineAudioContextの方が自然です。音声グラフをスピーカーやOSの音声デバイスへ送らず、メモリバッファへ直接レンダリングします。AliExpressのグラフでは、オシレーターと分析もゼロ出力の前にあります。ライブ出力への接続は、すでに読み取った周波数データに明確な追加価値を与えず、目に見える副作用だけを引き起こしました。
Mozillaは同じ現象を2023年に記録していた
2026年にはCallaghanのヘッドフォンが注目を集める手がかりとなりました。しかし基礎となるブラウザ現象は、Mozillaで2023年11月からBug 1863193として記録されています。Firefox 119に関する当初の報告では、AliExpressページがWindows 11で永続的な音声電源要求を発生させました。タブに再生表示がなくてもpowercfg /requestsはアクティブな音声ストリームを示し、PCが自動スリープへ移行しなくなりました。タブを閉じると要求は消えました。
Mozilla開発者Karl TomlinsonがWeb Audioログを有効にすると、後にCallaghanが説明したものと同じOscillatorNode、AnalyserNode、ScriptProcessorNode、ミュートされたGainNode、AudioDestinationNodeのチェーンが二度記録されました。TomlinsonはChromeでも同様の継続的なデバイス使用を確認し、AliExpressはAudioContext.suspend()で終了できると指摘しました。
これは重要な独立確認です。ハードウェア副作用は、難読化スクリプトに対するCallaghanの解釈だけに依存しません。Mozillaは数年前に動作中のグラフとWindows電源管理への影響をブラウザ内で直接記録していました。バグは現在も未解決です。同時に責任が分かれることも示します。AliExpressは測定後にコンテキストを停止でき、ブラウザも実質的に無音で不要なグラフを音声デバイスから早く切り離せます。
マイクも室内の超音波も使っていない
ここでは表現の正確さが重要です。このテストでAliExpressはマイクを録音せず、部屋の音も聞いていません。マイクへのアクセスはgetUserMedia()を通じて行われ、ユーザーの許可が必要です。
ショップがスピーカーから超音波信号を発し、それを物理的に再取得したという説明も誤りです。測定はブラウザ内部の音声処理で行われました。のこぎり波は計算、分析され、出力前にゼロへ設定されました。仮想グラフが現実の出力につながったままだったため、ヘッドフォンへの副作用が生じました。
同じ計算でも結果が異なる理由
デジタル信号処理には多くの浮動小数点演算があります。CPUアーキテクチャ、数学ライブラリ、コンパイラの判断、ブラウザ実装、丸め処理が小さな差を生みます。Web Audio標準はOscillatorNode、DynamicsCompressorNode、サンプルレート、レイテンシ、時間測定を潜在的なフィンガープリンティング面として明記し、ブラウザに差異の抑制を求めています。
しかしWeb Audioの結果は魔法のハードウェアシリアル番号ではありません。複数端末が同じ値を返すことがあり、ブラウザも結果を統一または変更できます。他の特徴と組み合わせて初めて識別力が高まります。
この手法は少なくとも2016年から使われている
音声フィンガープリンティングは2026年の新発見ではありません。Steven EnglehardtとArvind Narayananは、2016年にACM CCSで発表したOpenWPM研究で100万サイトを調査しました。合計67サイトの三つのスクリプトでAudioContextフィンガープリンティングを発見し、手作業の分析では二つが実際に能動利用していました。
そこでもオシレーターが既知信号を生成し、処理後に読み取ってハッシュ化しました。記録された一例では、AnalyserNode、ScriptProcessorNode、無音のGainNodeを経て出力へ接続しており、AliExpressのパターンと非常に近い構造です。Princetonの研究者も、マイクが不要であり、フィンガープリンティング技術は通常組み合わせられると強調していました。
AliExpress事例で新しいのは基本的な発想ではありません。最大級のオンラインマーケットで具体的に発見され、多数の特徴が組み合わされ、何より測定を露呈させるサイドチャネルが存在したことです。
音声値はパズルの一片にすぎない
調査したbundleで、Callaghanは他にも多くの特徴に対する照会や測定を発見しました。
- Canvasレンダリングと
toDataURL() - WebGLレンダラー、拡張、シェーダー精度
- 画面とviewportの寸法、Device Pixel Ratio
hardwareConcurrencyとdeviceMemory- インストール済みプラグインと対応メディア形式
- WebRTCの挙動とパフォーマンスタイミング
- マウス、タッチ、フォーカス、スクロールイベント
- 端末の動きと向き
- ブラウザ自動化やボットを示し得るプロパティ
コードには結果のシリアライズと暗号化、fetch()またはsendBeacon()による送信処理もありました。クライアント側では、フィンガープリンティングに使える広範なデータが収集され、Alibabaサービスへ送信され得ることが確認できます。
サーバー側で何が行われるかは確認できません。保存期間や、アカウント、注文、他のAlibabaサービス、広告プロファイルとの後の関連付けはブラウザから見えません。Callaghan自身もこの限界を明記しています。
AliExpressのプライバシーポリシーは、ブラウザとOSのデータ、ハードウェア・ソフトウェア特性、固有の端末識別子、利用パターン、操作などを挙げています。運営やパーソナライズに加え、詐欺、マネーロンダリング、セキュリティインシデントの検知も目的としています。観察された技術実装を透明にはしませんが、広範な端末・利用データが説明上のデータモデルに含まれることを示します。
フィンガープリンティングは必ずしも広告追跡ではない
ブラウザフィンガープリントは多様な場面で使われます。広告ネットワークはCookie削除後もブラウザを再認識できます。一方、オンラインショップや決済サービスも、リスク評価、アカウント乗っ取り、クーポン悪用、スクレイピング、ボット、自動購入への対策として同様の信号を使います。
両目的は排他的ではありません。同じ端末識別子が安全とマーケティングの双方に利用される可能性があります。ただし発見されたJavaScriptだけでは具体的なクロスサイト広告キャンペーンを証明できません。「AliExpressが全サイトで全ユーザーを追跡している」という結論は証拠を超えています。
それでもセキュリティ評価上の問題は残ります。
- 測定はログインや決済時だけでなく、一般のホームページから始まりました。
- スクリプトは高度に難読化され、ユーザーにはほぼ理解不能でした。
- 収集範囲は単一のアンチボット信号を大きく超えていました。
- 稼働中の音声グラフはインターフェース上で意味のある形で見えず、タブのミュートでも止まりませんでした。
- バックグラウンド機能がローカル音声経路へ深く介入し、外部ハードウェアの動作を変えました。
理解可能な不正対策に、実装手順の公開が必須とは限りません。しかしデータ最小化、明確な目的制限、ユーザーの期待と矛盾しないインターフェース動作は必要です。無音のショップタブがリアルタイム音声経路を占有すべきではありません。
この音声フィンガープリントはどれほど固有だったのか
Firefox開発者Tom Ritterは該当するWeb Audio計算を抽出し、Firefoxのテレメトリと比較しました。結果は過度に警戒的な説明を大きく相対化します。
Firefox 118以降、Web AudioはすべてのプラットフォームでFDLIBM数学ライブラリを使い、システム依存差を減らしています。Ritterの分析では、ユーザーの**99.24%**がわずか三つの結果値に集中しました。別の0.76%では測定点が失敗し、ゼロを返しました。三つの大きな群は、FMAなしのx86またはx64、FMAありのx64、NEONありのARMというCPUクラスにほぼ対応しました。
具体的なAliExpress手法について言えば、Firefoxでは調査対象のほぼ全ユーザーで音声値は個別固有ではありませんでした。単一端末より大まかなプロセッサクラスを示していました。ただし他の値を持つ小さなロングテールが残り、希少な値ほど対象システムを目立たせる場合があります。
単独では弱い値でも、グラフィックス、ハードウェア、行動、既存のアカウント情報からなる強い総合プロファイルの一部なら無害ではありません。
フィンガープリンティングは組み合わせで機能します。画面サイズ、タイムゾーン、CPUクラスは単独では普通です。しかしCanvas、WebGL、フォント、ハードウェア情報、ブラウザ特性、操作パターン、ログイン状態を合わせれば、区別しやすさは大きく上がります。Web Audio値は総合スコアで有用であるために固有である必要はありません。
ブラウザ保護は副作用を伴う軍拡競争
ブラウザは異なる戦略を取ります。Firefoxは特定の計算を統一し、既知のフィンガープリンティングサービスをブロックします。Firefox 145以降、より広い保護はまずプライベートモードと厳格な強化型トラッキング防止で有効です。Mozilla自身も、積極的な統一は正当な機能を壊し得ると述べています。
BraveはCanvasやWeb Audioなど指紋に使える結果をわずかに変化させます。Farblingと呼ばれる方法は同一セッションとサイト内では安定し、サイトやセッションが変わると異なる結果を返すよう設計されています。アプリは妥当な値を得られますが、持続的なグローバル識別子には使いにくくなります。
WebKitはSafariで、ローカルフォントや一部端末情報などの指紋面を制限します。特に危険なインターフェースについて、安全と考える方法がない限り実装自体を見送る場合もあります。同じインターフェースが高度なWebアプリを可能にする一方で、ブラウザの測定面も広げるという根本的な対立を示しています。
通常のブラウザがすべてのフィンガープリンティングの消滅を保証することはできません。一つの特性が統一されれば、事業者は別の特性や行動信号へ移ります。拡張機能、フォント、手動保護設定の極端に珍しい組み合わせは、最悪の場合、自分のブラウザをさらに希少にします。
ユーザーが具体的にできること
基本は、フィンガープリンティング保護を有効にした最新ブラウザです。Firefoxで強い保護を得るには、厳格な強化型トラッキング防止かプライベートウィンドウが重要です。BraveはShieldsとフィンガープリンティング防御を標準で有効にします。Safariでは最新のOSとブラウザを使います。Tor BrowserとMullvad Browserは機密性の高いセッションでさらに進み、多くのユーザーを類似フィンガープリントの同じ集団に見せようとします。そこでは独自設定や追加拡張を避けるべきです。
プライベートウィンドウだけでは完全ではありません。保存状態は制限しますが、ハードウェアやブラウザ特性を自動的に隠すわけではありません。Cookie削除もCookie IDと同じようにフィンガープリントをリセットしません。
VPNは別の問題を解決します。見える公開IPアドレスを置き換え、用途に応じてVPN事業者までの通信を保護します。しかしCanvas、WebGL、音声計算、フォント、ハードウェア特性は自動的に変わりません。VPNは有用でも、単独ではブラウザフィンガープリンティング対策になりません。
uBlock Originで二つのスクリプトを狙ってブロックする
CallaghanはuBlock Origin向けに意図的に範囲を狭くした二つのフィルターを公開しました。
! 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
マイフィルターへ追加した後、開いているAliExpressタブを閉じる必要があります。後からスクリプトをブロックしても、すでに作成された音声コンテキストは終了しません。
これらのルールは現時点のスナップショットです。パス、バージョン、ファイル名は変わり得ます。スクリプトはアンチボットおよびリスク基盤に属する可能性が高く、CAPTCHAの増加やログイン、チェックアウトの問題も起こり得ます。正当な取引を完了できない場合、その処理だけ一時的にルールを無効化し、完了後にタブを閉じます。
DNSでassets.aliexpress-media.comホスト全体をブロックするのは、はるかに大雑把です。他のショップ資源も置かれている可能性があります。限定的なURLルールの方が全面的なドメイン遮断より制御しやすい方法です。
JavaScriptの完全無効化は現実的でない
JavaScriptがなければこの測定は動きません。しかし現代のショップもほぼ機能しなくなります。全体的な無効化は珍しいブラウザ状態を作り、アカウント、プロファイル、機密作業を適切に分離する代わりにはなりません。
特に機密性の高い調査では、変更を最小限にした別ブラウザが役立つ場合があります。日常プロファイルとの関連付けは抑えられますが、匿名性は保証しません。IPアドレス、ログイン、決済情報、サーバー側信号は影響を受けません。
法的論点はCookieだけではない
欧州では「Cookieを使わない」は「同意不要」と同義ではありません。欧州データ保護会議の最終ガイドライン2/2023は、ePrivacy指令第5条3項の技術的範囲を従来のCookieより意図的に広く扱っています。端末に保存された情報や、端末のソフトウェア・ハードウェアが生成した情報へのアクセスも対象になり得ます。
具体的なAliExpress実装が適法かは、実際の目的、必要性、地域ごとのePrivacy規則の実装、透明性、その後の処理などに左右されます。不正対策は正当な目的になり得ます。しかし一般ホームページで収集されるすべての特性が必要なのか、同意が要るのかを自動的に決めるものではありません。
この記事は法的審査の代わりではありません。技術的には、Cookieバナーだけでは現代の識別を完全に表せない理由を示します。ユーザーが目に見えるマーケティングCookieをすべて拒否しても、ファーストパーティJavaScriptによって測定される可能性があります。
テストの根拠と限界
技術分析、ブラウザ情報、公開ポリシーを最後に確認したのは2026年8月31日です。具体的なAliExpressの発見は、CallaghanがWindows上のFirefoxとChromeで行った記録済みテストとWeb Audio APIの計測に基づきます。Mozillaの独立バグ報告、Ritterによる抽出音声手法の評価、OpenWPM研究、W3C、Mozilla、Brave、WebKit、Alibaba Cloud、AliExpress、EDPBの一次資料も使用しました。
Callaghanが示した二つのバージョン付きスクリプトURLは、私の確認時にもHTTP 200とapplication/javascriptを返しました。ただし私は管理したAliExpressアカウントでスクリプトを実行せず、自分のヘッドフォンでBluetooth副作用を再現していません。他のOS、ブラウザ、地域、A/Bテスト、変更されたスクリプト版は異なる可能性があります。サーバー側の保存、スコアリング、ID関連付け、送信値の利用は見えず、本記事自身の確認事項ではありません。
私の結論
この事例は秘密の超音波監視を証明せず、一つの音声値が各コンピュータを一意に識別する証拠でもありません。しかし現代のサイトがユーザーに見えないままブラウザを幅広い測定器として使えることを強く示します。
不正対策という説明には技術的な説得力があります。大規模マーケットはボット、アカウント乗っ取り、決済詐欺、クーポン悪用に対処しなければなりません。それでも顧客体験のあらゆる段階であらゆる測定が自動的に正当化されるわけではありません。一般ホームページから音声、グラフィックス、ハードウェア、WebRTC、行動特性を収集するなら、必要性、透明性、副作用への説明が必要です。
結局、測定を可視化したのはプライバシーダッシュボードではありません。ブラウザが静かだというふりを拒んだ一組のBluetoothヘッドフォンでした。
また次回、
Joe
参考資料
- Matt Callaghan:AliExpressスクリプトとuBlockフィルターの原分析
- Tom Ritter:FirefoxにおけるAliExpress Web Audioフィンガープリントの値とCPUクラス
- Mozilla Bug 1863193:AliExpressがWindows音声経路をアクティブに保つ
- Princeton Web Census:67サイトにおけるAudioContextフィンガープリンティング
- W3C:Web Audio APIのセキュリティとプライバシーに関する考慮事項
- AliExpress:端末、利用、安全データに関するプライバシーポリシー
- EDPB:ePrivacy指令第5条3項の技術的範囲に関するガイドライン2/2023


