AliExpress(アリエクスプレス)のサイトでWebAudioフィンガープリンティングを確認との報告-サイト利用者特定や追跡に利用か

ECサイト「AliExpress(アリエクスプレス)」のWebページで、ブラウザのWeb Audio APIを利用して端末特性を測定するフィンガープリンティング処理が動作していたと、開発者が2026年8月20日に報告しました。

調査のきっかけは、AliExpressをFirefoxやChromeで開いた際、PCとスマートフォンへ同時接続していたBluetoothマルチポイント対応ヘッドホンがスマートフォン側へ音声を切り替えられなくなる現象でした。ページを閉じると復旧する一方、タブやブラウザ、Windowsをミュートしても改善しなかったため、開発者がWeb Audio APIの動作を調査したところ、AliExpressのページ上で2つのAudioContextが実行状態になっていることを確認しました。

研究者によると、処理はブラウザ内で既知の波形を生成し、その処理結果を読み取る仕組みで、最終段の音量はゼロに設定されていました。マイクを利用して利用者の会話や周囲の音声を録音していたわけではありません。

一方、WebAudioだけでなく、Canvas、WebGL、画面サイズ、CPUコア数、デバイスメモリ、WebRTC、マウスやタッチ操作など多数の情報を取得するコードも確認されており、研究者はこれらを組み合わせたブラウザ・デバイスフィンガープリンティングと分析しています。

プライバシー重視ブラウザ「Brave」も8月23日、公式Xで今回の事例に言及し、AliExpressが音声処理結果を端末識別に利用していたと説明しました。ただし、元の調査を行った研究者は、送信後のデータがサーバー側でどのように利用・保持されているかまでは確認できておらず、永続的な追跡識別子として使われているのか、不正利用・ボット対策のリスクスコアの一要素なのかは断定していません。

AliExpressのWebAudioフィンガープリンティング報告のサマリー

• 【確認済み】開発者が2026年8月20日、AliExpressのホームページで2つのAudioContextが実行されていることを確認しました。
• 【確認済み】AudioContextを生成していたのは、AliExpressのドメインから読み込まれる「collina.js」「fireyejs.js」の2系統のスクリプトでした。
• 【確認済み】両スクリプトでは、波形生成、解析、音声処理結果の取得を行うWebAudioグラフが確認されています。
• 【確認済み】最終的なGainNodeはゼロに設定されており、利用者には音声が聞こえない設計でした。
• 【確認済み】マイクから利用者の音声を録音していたことを示す証拠は確認されていません。
• 【確認済み】研究者の環境では、音声処理がBluetoothマルチポイントの切り替えを妨げる副作用が発生しました。
• 【確認済み】同じスクリプト群には、Canvas、WebGL、画面情報、ハードウェア情報、WebRTC、操作情報など多数の端末特性を取得する処理も確認されています。
• 【確認済み】取得結果をシリアライズ・暗号化し、Alibaba側のテレメトリサービスへ送信する処理が存在すると研究者は報告しています。
• 【確認済み】AliExpressのプライバシーポリシーは、端末種別、一意な端末識別番号、ブラウザ、OS、ソフトウェア・ハードウェア属性、閲覧パターンなどを自動収集すると説明しています。
• 【確認済み】同ポリシーは、収集情報の利用目的としてアカウント・取引リスクの評価、不正防止、セキュリティ、広告、パーソナライズ、分析などを挙げています。
• 【確認できず】WebAudioから取得した値が、AliExpress側で永続的なユーザー追跡IDとして利用されているかは公開情報から確認できませんでした。
• 【確認できず】WebAudio値の保存期間、Alibabaの他サービスとの横断的な紐付け有無も確認できませんでした。

項目	内容
公表日	2026年8月20日
調査主体	laserphileブログの開発者
対象	AliExpressのWebページ
技術	Web Audio APIを利用したフィンガープリンティング
確認されたAudioContext	2つ
関連スクリプト	collina.js、fireyejs.js
音声録音	確認されていない
音声出力	最終段のゲインは0で、可聴音を出さない設計
その他の取得情報	Canvas、WebGL、画面情報、ハードウェア情報、WebRTC、操作情報など
Bluetoothへの影響	研究者の環境でマルチポイント切り替えを阻害
サーバー側の利用目的	永続追跡か不正・ボット対策かは確認できず
Braveの対応	WebAudioを含むフィンガープリンティング可能なAPIの値をランダム化する保護機構を実装

Bluetoothヘッドホンの異常から発覚

今回の調査は、典型的なプライバシー調査から始まったわけではありません。

報告者はPCとスマートフォンの2台へBluetoothマルチポイント対応ヘッドホンを接続し、普段はスマートフォンから音楽を再生していました。

ところがFirefoxまたはChromeでAliExpressのページを開くと、数秒後にスマートフォン側の音声が停止し、PC側が音声経路を保持した状態になりました。AliExpressのタブを閉じると直ちにスマートフォン側へ戻りました。

通常であれば、動画広告や自動再生される音声が原因と考えられます。

しかし調査では、audio要素やvideo要素、通常のメディア再生処理、Media Sessionによる再生状態はいずれも確認されませんでした。

そこでWeb Audio APIを調べたところ、AliExpressのページが2つのAudioContextを作成し、どちらも実行状態でAudioContext.destinationへ接続していることが判明しました。

つまり、利用者に音を聞かせるための通常のメディア再生ではなく、ブラウザ内部で音声信号を生成・解析する処理がシステムのオーディオ経路を使用していました。

「無音の音を流して盗聴」ではない

今回の報告は、「AliExpressが利用者のマイクを盗聴していた」という内容ではありません。

研究者が確認した処理では、ブラウザ内部で既知の波形を生成し、その波形がブラウザやOSのオーディオ処理を通過した後の結果を解析しています。

最終的な音量はゼロに設定されているため、人には聞こえません。

しかし、音量がゼロでもAudioContext自体は実行され、システム側では音声処理が継続します。このため、研究者の環境ではPC側のオーディオ経路がアクティブな状態になり、Bluetoothマルチポイントの切り替えに影響したとみられます。

Braveは公式Xで今回の事例について、録音ではなく、無音の音声処理結果を利用したフィンガープリンティングだと説明しています。

「マイクを使って周囲の音を収集する処理」と「ブラウザ自身が生成した音声信号の計算結果を調べる処理」は別物です。

WebAudioフィンガープリンティングとは

ブラウザ・フィンガープリンティングは、ブラウザや端末がWebサイトへ公開する複数の特徴を組み合わせ、利用者を識別しやすくする技術です。

Cookieのように端末へ識別子を書き込む必要がないため、Cookieを削除しても同一端末を推測できる場合があります。

WebAudioフィンガープリンティングでは、Web Audio APIで同じ音声信号を生成し、ブラウザ、OS、CPU、音声処理ライブラリなどによって生じる計算結果の差を測定します。

1つのWebAudio値だけで端末を一意に識別できるとは限りません。

しかし、Canvas描画、WebGL、画面解像度、CPU、メモリ、フォント、ブラウザ情報などと組み合わせれば、識別材料を増やすことができます。

Braveも公式のプライバシー解説で、グラフィックスハードウェア、オーディオハードウェア、端末種別など複数のデータポイントを組み合わせることでデジタルフィンガープリントを形成できると説明しています。

サイト利用者の特定のために利用か

WebAudioフィンガープリンティングが確認されたからといって、直ちにアカウントが乗っ取られたり、PCへマルウェアが感染したりするわけではありません。

主な懸念は、利用者が明示的な識別子を保存していなくても、ブラウザや端末の特徴を組み合わせることで、同じ利用者・同じブラウザである可能性を推測できる点にあります。

Mozillaはブラウザ・フィンガープリンティングについて、Cookieをブロックした場合やプライベートブラウジングを利用した場合でも、端末・ブラウザの特徴を組み合わせることで利用者を識別し続けられる場合があると説明しています。

ただし、WebAudioの値だけで長期間・高精度に個人を一意識別できるとは限りません。ブラウザのアップデート、OS、CPU、オーディオ処理環境、プライバシー保護機能などによって値が変化する場合があります。

今回のAliExpressの事例でも、WebAudioだけではなくCanvas、WebGL、画面情報、CPUコア数、デバイスメモリ、WebRTC、操作情報など、多数のシグナルを同時に収集する処理が確認されています。

懸念の中心は「WebAudioの値そのもの」ではなく、複数の弱い識別情報を組み合わせることで、より安定した端末フィンガープリントを構成できる点です。

Cookieを削除しても識別材料が残る可能性

Cookieを利用した追跡では、利用者がCookieを削除したり、ブラウザがサードパーティCookieを制限したりすることで識別子を失わせることができます。

一方、フィンガープリンティングでは、識別材料がブラウザや端末の構成そのものから生成されます。

そのため、Cookieやローカルストレージを削除しても、同じ端末構成から似たフィンガープリントが再生成される可能性があります。

Braveも、Cookieなどのストレージを消去しても安定したフィンガープリントが取得できれば、閲覧セッション同士を結び付けられることがフィンガープリンティングの問題だと説明しています。

ただし、あるWebサイトが別の無関係なWebサイトでの閲覧履歴を自動的に把握できるわけではありません。

サイト間で同じ第三者トラッカーが利用されている場合や、取得した識別情報が共有・照合される場合などに、複数サイトや複数セッションをまたいだ追跡材料となる可能性があります。

利用者が「削除」しにくい識別子であることも問題

Cookieには保存場所があり、利用者はブラウザの設定から削除できます。

フィンガープリントには、削除すべき単一のファイルやCookieが存在しません。

画面解像度、GPU、CPU、ブラウザ設定、AudioContextの処理結果といった端末特性から、その都度識別情報を再計算できるためです。

このため利用者から見ると、

• 何が識別に使われているのか分かりにくい
• 識別情報がどこに保存されているのか分かりにくい
• Cookie削除のような明確なリセット手段がない
• どのサイトや事業者間で照合されているのか把握しにくい

という透明性の問題があります。

Mozillaはフィンガープリンティングを、利用者の知識や同意なしに行われ得る「隠れた追跡手法」と位置づけ、Firefoxで取得可能な端末情報を制限する対策を進めています。

WebAudio単独より「他の情報との組み合わせ」が重要

今回のAliExpressのケースでは、Firefox開発者のTom Ritter氏が、現在のFirefoxではWebAudio単独から得られる識別力は大きく低下していると分析しています。

同氏が示したFirefoxのテレメトリでは、99.24％の利用者が3種類のWebAudio値のいずれかに分類されていました。

この数字だけを見ると、WebAudioは高精度な識別子ではないように見えます。

しかし、フィンガープリンティングでは一つの属性だけで利用者を識別する必要はありません。

例えば、

「OS」
「ブラウザ」
「画面サイズ」
「GPU」
「CPU」
「言語」
「タイムゾーン」
「WebAudio」
「Canvas」

のそれぞれが単独では多数の利用者と一致していても、組み合わせることで一致する利用者を大幅に絞り込める可能性があります。

そのため、「WebAudio単独では識別力が低いから問題はない」と判断するのも適切ではありません。

今回のAliExpressのコードで多数の端末特性が同時に取得されていたことは、この点を考えるうえで重要です。

不正利用・ボット対策という正当な用途もある

フィンガープリンティングは、広告追跡だけに利用される技術ではありません。

ECサイトや金融サービスでは、同じ端末から大量のアカウントが作成されていないか、不自然な自動操作が行われていないか、既知の不正端末と特徴が一致しないかなどを判定するため、端末フィンガープリントを不正利用対策へ利用する場合があります。

今回のAliExpressについても、元の調査では関連スクリプトがAlibabaのセキュリティ・不正利用対策系の処理に関連する可能性が指摘されています。

そのため、「フィンガープリンティングを行っている＝広告目的の追跡」とは断定できません。

一方、不正利用対策を目的とする場合でも、取得する端末情報の範囲、保存期間、第三者提供、他目的への転用、利用者への説明が適切かという問題は残ります。

セキュリティ目的で収集した識別情報が、広告や行動分析など別の目的にも利用される場合には、目的の切り分けと透明性が重要になります。

フィンガープリントを本人確認の唯一の根拠にするのは難しい

フィンガープリントは端末の特徴から生成されるため、必ずしも永続的で正確な本人識別子ではありません。

OSやブラウザの更新、GPUドライバの変更、外部ディスプレイやオーディオ機器の接続、プライバシー保護機能の利用によって、取得値が変わる場合があります。

反対に、同じ構成の端末では似た値になる可能性もあります。

そのため、フィンガープリントは不正利用のリスク評価には利用できても、本人認証や「この人物が操作した」という判断の唯一の根拠として扱うべきではありません。

企業が不正検知へ導入する場合も、IPアドレス、ログイン履歴、MFA、取引行動など複数のシグナルと組み合わせ、誤検知によるアカウント停止などを考慮する必要があります。

欧州ではフィンガープリンティングも「トラッカー」として扱われる

プライバシー規制の観点でも、フィンガープリンティングはCookieとは別物だから規制対象外になるとは限りません。

フランスのデータ保護機関CNILは、端末構成などを利用して一意の識別子を計算するフィンガープリンティングを「cookieやその他のトラッカー」に含めています。

CNILは、追跡目的のフィンガープリンティングについて、ePrivacy指令に基づくCookie等と同様のルールが問題になると説明しています。

欧州データ保護会議（EDPB）も、ePrivacy指令5条3項の技術的適用範囲に関するガイドラインで、Cookieに代わる新しい追跡技術を含め、端末情報へアクセスする技術について検討しています。

英国ICOも2026年4月に公表したStorage and Access Technologiesのガイダンスで、Cookie、トラッキングピクセル、デバイスフィンガープリンティングなどを同じ「storage and access technologies」の枠組みで扱っています。

ただし、必要な同意や法的根拠は利用目的、実装方法、地域の法令によって異なります。

今回のAliExpressについて、これらの欧州規制に違反していると確認されたわけではありません。

利用者側で想定される主な影響

WebAudioフィンガープリンティングが利用されている場合に、利用者側で想定される影響は次のように整理できます。

懸念	想定される影響
セッションをまたぐ識別	Cookie削除後も同じブラウザ・端末である可能性を推測される
複数シグナルとの結合	WebAudio単独より高い精度でブラウザを絞り込まれる可能性
行動プロファイリング	同一と判断された端末の閲覧・購入行動を結び付ける材料になる
利用者による制御の難しさ	Cookieのように単一の識別子を削除してリセットしにくい
説明・同意の不透明さ	バックグラウンド処理のため、利用者が収集を認識しにくい
誤判定	端末環境変化でフィンガープリントが変わり、不正検知等で誤判定する可能性
端末機能への副作用	今回の報告のようにAudioContextがBluetoothオーディオ経路へ影響する場合がある

これらは、AliExpress利用者にすべて実際に発生したことが確認されているという意味ではありません。

今回確認されているのはWebAudioを含む端末情報取得処理と、研究者の環境で発生したBluetoothマルチポイントへの影響です。

追跡期間、他サイトとの照合、広告プロファイリングへの利用、個々の利用者への具体的な影響については確認されていません。

AliExpressではWebAudio以外の情報も取得

今回の調査で重要なのは、音声処理だけが単独で実行されていたわけではない点です。

研究者がスクリプトを調べたところ、WebAudio以外にも次のような情報を取得・測定する処理が確認されました。

• Canvasの描画結果
• WebGLのレンダラー、拡張機能、シェーダー精度
• 画面・ブラウザ表示領域のサイズ
• Device Pixel Ratio
• CPUの論理コア数
• デバイスメモリ
• ブラウザプラグイン
• 対応する音声・動画形式
• WebRTCの挙動
• ブラウザのパフォーマンスタイミング
• マウス、タッチ、フォーカス、スクロール
• モーション・端末方向
• ブラウザ自動化を判定するために利用できる属性

さらに、取得結果をシリアライズ・暗号化し、fetchやsendBeaconなどを用いてAlibaba側のテレメトリへ送信する処理も存在すると報告されています。

こうした構成から、研究者は単一のWebAudioテストではなく、包括的なブラウザ・デバイスフィンガープリンティング処理と評価しています。

追跡目的か、不正利用対策かは断定できない

今回の報告で最も慎重に扱う必要がある点です。

研究者はブラウザ上でどの情報が取得され、送信されるかを確認しています。

一方、送信された値がAlibaba側のサーバーでどのように処理されるかは確認できていません。

研究者自身も、永続的なデバイス識別子として利用されている可能性と、不正利用やボットを判定するリスクスコアの入力情報として利用されている可能性の両方を挙げています。

関連スクリプトは「AWSC」配下から提供されており、研究者はAlibabaのブラウザセキュリティ・不正利用対策系の処理に関連するとみています。

AliExpressの2025年5月27日付プライバシーポリシーも、端末から自動的に収集する情報として、IPアドレス、端末種別、一意な端末識別番号、ブラウザ種別、OS、ソフトウェア・ハードウェア属性、閲覧パターンなどを挙げています。

利用目的には、Buyer・Sellerのアカウントセキュリティや取引リスクの評価、不正・マネーロンダリングなどの検知・防止、広告、パーソナライズ、研究・分析などが記載されています。

ただし、同ポリシーでWebAudioフィンガープリンティングそのものが個別に説明されていることは、今回確認できませんでした。

そのため、「AliExpressが広告追跡のためにWebAudioを使っていた」「不正検知専用だった」とどちらか一方に断定することはできません。

Firefox開発者は「WebAudio単独の識別力は低い」と指摘

今回の報告を受け、Firefoxの開発に携わるTom Ritter氏もAliExpressのWebAudio処理を追加調査しています。

Ritter氏によると、Firefoxは2023年のFirefox 118でWebAudioから得られる値のばらつきを大幅に抑制しました。

同氏が示したFirefoxのテレメトリでは、99.24％の利用者が3種類の値のいずれかに分類され、残る差の多くはCPUアーキテクチャレベルの違いによるものだったとしています。

このためRitter氏は、現在のFirefoxではWebAudio単独によるフィンガープリンティングの有効性はかなり低いと評価しています。

これは「AliExpressのコードがフィンガープリンティングではない」という意味ではありません。

WebAudio単独の識別力が低くても、Canvas、WebGL、画面情報、ハードウェア情報、操作情報などと組み合わせれば、フィンガープリント全体の一要素として利用できます。

今回の事例は、フィンガープリンティングを1つのAPIだけで評価せず、複数のシグナルを組み合わせた処理として見る必要があることを示しています。

BraveはWebAudioの値をランダム化

Braveは、ブラウザ・フィンガープリンティングへの対策として「farbling」と呼ぶランダム化方式を実装しています。

Braveの公式資料によると、Web Audioを含むフィンガープリンティング可能なAPIの出力へわずかなランダム性を加え、サイトやブラウザセッションごとに異なる結果を返すことで、安定した識別子として利用しにくくします。

Braveのヘルプ文書でも「Web Audio Serialization」はランダム化対象として明示されています。

Braveは8月23日の公式X投稿で今回のAliExpressの事例に触れ、「Brave stops this」と説明しました。

また、Braveは2026年8月13日に公開したアップデートで、WebGLとWebGPUから取得できるGPU・グラフィックスドライバ情報への追加対策も発表しています。

Brave 1.93から、WebGLのベンダー・レンダラー情報を一般化し、WebGPUのアダプター情報を空にし、WebGL拡張リストへランダム性を加える仕組みを展開しています。

今回AliExpressで確認されたコードはWebAudioだけでなくWebGLも測定しているため、ブラウザ側では複数のフィンガープリンティング経路を同時に減らすことが重要になります。

Bluetoothへの影響はフィンガープリンティング処理の副作用

今回の問題が発覚した理由は、プライバシー通知やブラウザの警告ではなく、Bluetoothヘッドホンの挙動でした。

研究者の環境では、音量ゼロのAudioContextがAudioContext.destinationへ接続されたまま動作したことで、PC側のオーディオ経路がアクティブな状態になりました。

その結果、スマートフォンとPCの双方に接続していたBluetoothヘッドホンが、スマートフォン側へ正常に切り替わらなくなりました。

タブをミュートしても改善しなかったのは、通常のaudio・video要素による再生ではなく、Web Audio APIによるリアルタイム処理だったためです。

この症状がすべてのBluetooth機器やOSで発生することは確認されていません。

元の調査も、FirefoxとChromeを利用した特定のPC・Bluetooth構成で確認されたものです。

そのため「AliExpressを開くとBluetoothが壊れる」と一般化するのは適切ではありません。

ブラウザのフィンガープリンティングはCookieより見えにくい

Cookieはブラウザ設定から削除でき、サードパーティCookieを制限する機能も一般化しています。

一方、ブラウザ・フィンガープリンティングは、Webサイトが本来の機能提供にも利用するAPIから端末特性を取得します。

Canvasは画像描画、WebGLは3Dグラフィックス、WebAudioは音声処理に必要です。

これらを全面的に無効化すると、正常なWebサービスまで動作しなくなる可能性があります。

BraveがAPIを完全に禁止するのではなく値をランダム化し、Firefoxが公開情報を制限・一般化する方式を取っているのも、この互換性とのバランスが理由です。

企業のWebアクセス管理でも、「Cookieをブロックしているから追跡対策は完了」とは考えにくくなっています。

情報システム・プライバシー部門への示唆

今回の事例は、端末フィンガープリンティングが広告技術だけの話ではなく、不正利用対策、ボット検知、アカウント保護などのセキュリティ機能にも組み込まれていることを示しています。

企業が自社サイトで外部の不正検知SDKやタグ、分析ツールを導入する場合、Cookieだけを確認するのではなく、ブラウザAPIからどの情報を取得しているかを把握する必要があります。

特に確認したいのは、Canvas、WebGL・WebGPU、WebAudio、WebRTC、Device Memory、Hardware Concurrency、フォント、センサー、マウス・タッチ操作などです。

不正検知の目的自体が正当であっても、取得項目が多く、利用者から見えない形で端末識別を行う場合には、プライバシーポリシーやCookie Notice、同意管理との整合性を確認する必要があります。

また、サードパーティ製SDKだけでなく、今回のように自社・グループ企業のドメインから配信されるスクリプトも対象に含めるべきです。

ブラウザ側の対策としては、最新版への更新、フィンガープリンティング防止機能の有効化、トラッキング防止設定の確認が基本になります。

BraveはデフォルトのShieldsでフィンガープリンティング対策を提供しており、Firefoxも既知・疑わしいフィンガープリンターに対する保護機能を実装しています。

一方、研究者が示した特定スクリプトの個別ブロックを企業全体へそのまま適用することは推奨しません。

フィンガープリンティング処理が不正利用対策やログイン・決済のリスク判定にも利用されている場合、スクリプトを遮断することでCAPTCHAの増加やログイン・決済障害を引き起こす可能性があります。

企業環境では、ブラウザの標準的なプライバシー保護機能、Webフィルタリング、ブラウザ管理ポリシーなどを組み合わせ、業務影響を検証したうえで運用する必要があります。

今回のAliExpressの事例で注目すべきなのは、「聞こえない音」そのものではありません。

Webブラウザが提供する多数のAPIから得られる小さな端末差を組み合わせれば、Cookieとは異なる識別材料を作れること、そして利用者から見えないバックグラウンド処理が、Bluetooth機器の挙動を変えるほどOSのリソースを利用する場合があることです。

Webサイトのプライバシーを評価する際は、保存されるCookieだけでなく、ブラウザがサイトへ何を公開しているかまで確認する必要があります。

出典

• AliExpress webpage keeping multipoint Bluetooth headphones active with WebAudio fingerprinting – laserphile
• webaudio fingerprinting on alibaba – Tom Ritter
• AliExpress.com Privacy Policy – AliExpress
• AliExpress Cookie Notice – AliExpress
• Brave Shields – Brave
• Fingerprinting defenses 2.0 – Brave
• Brave improves protections against GPU fingerprinting – Brave
• Firefox’s protection against fingerprinting – Mozilla
• Resist Fingerprinting – Mozilla
• Firefox expands fingerprint protections: advancing towards a more private web – Mozilla
• Fingerprinting – MDN Web Docs
• Cookies et traceurs : que dit la loi ? – CNIL
• Alternatives aux cookies tiers : quelles conséquences en matière de consentement ? – CNIL
• Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive – European Data Protection Board
• Final storage and access technologies guidance published – ICO