AliExpressを開いたPCで、Bluetoothマルチポイント対応ヘッドホンがスマートフォン側へ戻らない。2026年8月20日、独立開発者laserphileはこの症状を追い、ホーム画面が2本の難読化スクリプトから無音のWebAudioグラフを動かしていることを確認した。タブを閉じると症状は消え、対象スクリプトをブロックした環境ではAudioContextもBluetoothの症状も消えた。
ここで測っているのはマイク入力ではない。スピーカーから出した音や部屋の反響を拾う処理でもない。ブラウザ内部で生成した波形をFFTで読み取るWebAudioの実装であり、マイク取得には別途getUserMediaの許可が要る。
今回つながったのは、古くから知られるWebAudio指紋の存在ではなく、物理的な副作用から具体的な実装、送信経路、Firefoxで以前から報告されていた挙動までを追える材料である。値そのものの識別力と、複数信号を束ねて見えないまま実行する設計は、分けて考える必要がある。
Bluetooth障害が暴いた2本の無音グラフ
laserphileが確認したのは、assets.aliexpress-media.com配下のcollina.jsとfireyejs.jsで作られる2個のAudioContextである。どちらもrunningの状態で、AudioContext.destinationへ接続されていた。グラフは概ね「Sawtooth Oscillator → AnalyserNode → ScriptProcessorNode → GainNode（gainは0）→ destination」の順でつながる。
AnalyserNodeはgainが0になる前段に置かれ、生成波形の周波数成分を読む。したがって音を可聴出力する必要はない。しかしdestinationへ接続したままにすると、ブラウザとOSが音声経路を保持する場合がある。調査者のBluetooth機器はPCが再生中だと扱った可能性があり、これがスマートフォン側への切替を妨げたとみられる。
この症状は、指紋値を得るために必要な工程ではない。無音の実装がOSやBluetoothへ及ぼした副作用である。全OS、全ブラウザ、全ヘッドホンで再現するかは未確認だ。FirefoxとWindowsのどちらに起因するのか、Bluetoothスタックやヘッドホンのファームウェアがどこまで関わるのかも、この観測だけでは決められない。
2026年8月24日時点で、同じスクリプトがどの地域、ページ、ブラウザへ配信されているかも未検証である。8月20日の観測をAliExpress全体の現状へ広げることはできない。
Tom Ritterが抽出して注釈を付けたfireyejs 1.231.69のコードでは、FFTサイズ2048のAnalyserNodeから、最初のonaudioprocessで1024個の周波数ビンを取得し、文字列化している。元コードはAudioContextをclose()しない。音声経路を開いたままにする実装上の選択が、利用者には見えない形で残っていた。
音声単体は端末IDにならない
WebAudioの出力差には、DSPの実装と再サンプリング、浮動小数点の丸めが影響し得る。コンパイラ設定やCPUアーキテクチャも値を変える。W3CのWeb Audio仕様は、通常は聞き分けられない差が指紋の情報量になり得ると説明する。一方で、WebAudio単体ではブラウザやOSの種類を分ける程度にとどまりやすい。
IMC 2022の査読論文は、57カ国の2,093人に7方式を各30回測定した。音声ベクトルを統合した方式では95種類に分かれ、そのうち49種類は1人にしか現れなかった。情報量は2.803ビットである。Canvas単体の6.109ビットへ音声を加えると6.699ビットになり、同じ標本では9.6%増えた。
この数値は、現在の全利用者を一意に識別できる割合ではない。弱い信号でも既存の端末属性と重ねれば、候補集合をさらに狭められる。Cookieのように端末側へ識別子を保存せず、複数の準識別子を組み合わせる方式では、個々の値が弱くても無意味にはならない。
Firefoxでは防御も進んでいる。Ritterによれば、Firefox 118以降はWebAudio結果を概ね一定化し、テレメトリの99.24%は3値に収まった。残る0.76%は収集失敗値の0であり、3値はx86/x64の非FMA、x64 FMA、ARM NEONというCPU級の違いに対応する。Firefox上では、音声値だけで個体を強く識別するのは難しい。
2年前のBugzillaに同じ痕跡
Mozilla Bugzillaには、Firefox 119でAliExpressページを開くと、無音でもWindowsの音声デバイスに対する電源要求が残り、スリープを妨げるという報告がある。今回の調査より約2年前のもので、2026年8月24日時点の状態はNEWである。
Mozilla開発者はWebAudioログを確認し、指紋採取以外の用途が見えない処理だと述べた。AudioContextはsuspend()で止められるとされ、ページが音を聞かせなくても音声処理を継続していたことが問題になった。今回見つかったグラフと完全に同一のスクリプト版が動いていたことまでは、公開バグだけから確認できない。
WebAudioによる指紋採取自体は新技術ではない。2016年の大規模Web計測研究でも実地利用が検出されている。AliExpressで観測された方式は、よく知られるOfflineAudioContextとDynamicsCompressorを組み合わせる型ではなく、リアルタイムのAudioContextとAnalyserNodeのFFTを使う型だった。
難読化コードの初期解析にはAIも使われたとlaserphileは記している。そのため構造を断定できるのは、Mozillaのログ、Ritterの抽出コード、Web Audio仕様で裏付けられる部分までである。それでも、無音処理が一時的な偶然ではなく、以前からブラウザ資源を保持していた痕跡は残っている。
不正対策と追跡は同じ材料を使う
同じバンドルは、CanvasとWebGLに加え、画面寸法やdevice pixel ratioを調べる。CPUコア数とメモリ容量、プラグインやコーデックの情報も対象だ。さらにWebRTCや処理時間を測り、マウス操作、タッチ、画面のフォーカスとスクロールも記録する。端末の向きや動き、ブラウザ自動化に特有の属性まで照会していた。結果を直列化・暗号化し、AlibabaのテレメトリーサービスへfetchまたはsendBeaconで送るコードも確認された。
AliExpressのプライバシーポリシーは2026年7月30日に発効した。IPアドレスや端末種別、固有端末識別番号を自動収集すると開示する。ブラウザとOS、ソフトウェア・ハードウェア属性、閲覧や操作の履歴も対象である。利用目的にはアカウント・取引の安全確保と不正防止のほか、パーソナライズや広告、調査・分析が並ぶ。またALIBABA.COM CHINA LIMITEDをリスク管理事業者として挙げている。
ポリシー本文は「fingerprint」「WebAudio」「Canvas」を名指ししていない。AWSCや自動化判定のコード、ポリシーにあるセキュリティとリスク管理の記述は、不正対策の用途と整合する。ただし、今回の送信データが最終的に何へ使われるかを直接には証明しない。広告追跡や永続的な端末IDへの利用は未確認だ。Alibaba内の横断利用、保存期間、サーバー側の照合、個人との紐付けも分からない。
CNILは、端末構成から算出する指紋をトラッカーに含める。原則として事前同意が必要だが、利用者が求めたサービスに厳密に必要な認証や不正ログイン抑止なら例外になり得る。本件のEU・英国での評価は、処理目的と厳格な必要性の有無で変わる。同意の状態に加え、二次利用をせずデータを分離しているかも判断を左右する。
ブラウザが値を潰しても実行は見えない
Firefoxの一定化は、音声出力の識別力を抑える対策である。Braveも2020年からCanvasとWebAudioにサイト・セッション単位のfarblingを適用している。同じセッション内では互換性のため値を安定させ、サイトやセッションが変われば別の値を返す。値を変える防御は、指紋の再利用を難しくする。
ただし、値を潰しても、ページがWebAudio APIを呼び出した事実や、CPU・OSの音声資源を保持した事実まで自動的に消えるわけではない。タブをミュートしても音が鳴らないため、利用者は2個のAudioContextが動いていることをUIから判断しにくい。今回のBluetooth障害は、通常は見えない実行を物理的な挙動が知らせた例である。
対策の評価は、WebAudioの値がどれだけ識別しにくくなったかだけでは足りない。API実行を利用者が把握できるか、不要になったAudioContextを停止してclose()できるかも問われる。送信先と利用目的をどこまで限定したかも確認対象だ。AliExpressまたはAlibabaから本件に関する公式回答は、2026年8月24日時点で確認できない。
Bluetoothの症状が再現するかより先に、どのページでどのスクリプト版が動き、何を送信し、どれほど保持するかが明らかになる必要がある。値の識別力を下げるブラウザ防御と、見えない実行を減らす実装の後始末は、別の判断材料である。