2026年7月12日、アンチスクレイピング技術企業 Scrapfly のエンジニアが技術ブログを公開し、不安を抱かせる発見を明らかにした。Chrome 148 以降、一見何の変哲もない数学関数 Math.tanh() が、OS によってわずかに異なる結果を返すというのだ。つまり、どのサイトでもあなたに一行の数学計算を実行させるだけで、Windows を使っているか、macOS か、Linux かを判断できる。
▲ 画像出典：Scrapfly ブログ記事のスクリーンショット
この発見は当日に Hacker News のトップページに載り、207の推薦と90のコメントを集めた。開発者コミュニティの反応は「驚き」の一言だった——ブラウザフィンガープリントは Canvas 描画や WebGL レンダリング、音声処理といった「重火器」でユーザーを追跡するものだと皆が慣れており、平凡な双曲線正接関数がOSを識別する手がかりになり得るとは想像もしていなかった。
同じ数学の問題に、三つの異なる答え
具体的な例で説明しよう。Chrome 150 のブラウザコンソールで Math.tanh(0.8)、つまり0.8の双曲線正接を計算すると、三つの異なるOSの実機は三つの異なる結果を返した。
| OS | Math.tanh(0.8) の戻り値 |
|---|---|
| Linux (glibc) | 0.6640367702678491 |
| macOS (libsystem_m) | 0.664036770267849 |
| Windows (UCRT) | 0.6640367702678489 |
最後の数桁に注目してほしい。Linux は macOS より一桁多く、値は最大。macOS は Windows より一桁少なく、中間。Windows の値はやや小さい。三つの差は最後の一桁か二桁だけで、肉眼ではほとんど見分けがつかない——しかしコンピュータにとっては、これらの差で明確なOSの署名を構成するには十分なのだ。
面白いことに、すべての入力が差異を生むわけではない。Scrapfly のテストデータによれば、約四分の三の入力値は三系統で結果が完全に一致する。たとえば Math.tanh(0.5) は、Linux、macOS、Windows いずれも 0.46211715726000974 を返す。一方 tanh(0.7) では Linux の値だけが他二者と異なり、tanh(0.9) では Windows だけが一線を画す。tanh(0.8) はまさに三者をすべて見分ける「スイートスポット」だった。
▲ 画像出典：Scrapfly ブログの比較表スクリーンショット
これが意味するのは、追跡者が複雑な操作をする必要がないということだ。ウェブページ上で Math.tanh() を数回実行し、いくつかの重要な入力値を選んで戻り値を比較するだけで、訪問者のOSを推測できる。もし訪問者の User-Agent が macOS を名乗っていても、tanh の戻り値が典型的な Linux の結果なら——その訪問者がなりすましている可能性は高い。
誰のせいか。バグか、それとも数学の宿命か
ここまで読んだ読者は、「これは Chrome のバグではないのか」と問うかもしれない。
答えは微妙だ。完全なバグというわけではないが、ある「修正」がもたらした意図せぬ副作用だ。
Chrome 148 以前、V8 エンジン（Chrome の JavaScript 実行の中核）の Math.tanh の実装は、自ら同梱した fdlibm という数学ライブラリを使っていた。すべてのプラットフォームで同じコードを使っていたため、ユーザーが Windows、macOS、Linux のどれで Chrome を使おうと、Math.tanh の結果は完全に一致し——当然、OS情報を漏らすことはなかった。
しかし2025年末、V8 チームはコード変更（commit c1486295ae5）を提出し、Math.tanh の実装を自前の fdlibm から C++ 標準ライブラリの std::tanh に置き換えた。この変更の動機はもっともらしい。V8 自身のコードサイズを減らし、OS の奥底で高度に最適化された数学ライブラリを活用し、理論上は性能も向上するはずだった。この変更は V8 14.8.57 でリリースされ、Chrome 148 に相当する。
問題はこうだ。異なるOSの奥底にある数学ライブラリ（Linux の glibc、macOS の libsystem_m、Windows の UCRT）は、双曲線正接関数の実装がそれぞれ異なっている。
これは数学上の根本的な制約だ。IEEE 754 規格は浮動小数点数の格納形式と基本演算（加減乘除、平方根）の精度要件を定めているが、三角関数、指数関数、双曲関数といった「超越関数」については、「正しく丸められる」こと——すなわち計算結果が最後の一ビットまで正確であること——を強制していない。その理由は実際的だ。正しく丸めを行う計算量は膨大で、性能に深刻な影響を及ぼすからだ。そのため、各OSの数学ライブラリは独自の近似アルゴリズム、係数表、定数を持ち、その目標は速度を保証しつつ誤差を「最小精度単位」（ULP）の範囲内に抑えることだ。
だから、Chrome 148 以降の Math.tanh のOSごとの微小な差異は、本質的には数学的近似アルゴリズムの多様性の現れだ。これは単純に「修正」できるバグではない——それは実は浮動小数点演算の分野で数十年間存在してきたトレードオフ、速度か精度か、なのだ。ただ、このトレードオフがブラウザというユーザーインタフェース層に晒されたとき、それは意図せずプライバシー漏洩の経路になってしまったのだ。
tanh だけではない——ブラウザ全体に広がる漏洩面
より警戒すべきは、Math.tanh が氷山の一角に過ぎないことだ。
Scrapfly のブログは、ホストOSの数学ライブラリ（libm）を介して計算されるブラウザAPIは、理論上すべて同じ漏洩リスクを抱えていると指摘している。これには CSS の三角関数（sin()、cos()、tan() など）や、Web Audio API のダイナミックコンプレッサーが含まれる。これらの機能はすべて、浮動小数点計算にホストOSの数学ライブラリに依存している。
言い換えれば、Chrome チームが Math.tanh を修正したとしても、ブラウザにホストOSの数学関数を呼ぶAPIが一つでも残り、統一的な処理がなされていなければ、フィンガープリントの窓は残り続ける。
これは古典的な「モグラ叩き」式の軍備競争だ。ブラウザ開発者はユーザーの身元を漏らし得るすき間を一つずつ塞ごうとし、追跡者やアンチスクレイピングシステムは新たなシグナルを絶えず探し続ける。フィンガープリントの歴史とは、双方が新たな戦場を発見し続けた歴史だ。Canvas から WebGL へ、フォントリストから音声波形へ、そして今の数学関数の結果の差異へ。開発者が一つの穴を塞ぐたび、追跡者は次に、まさか手がかりになるとは思えない指標を見つける。
HN コミュニティの二極化した反応
HN の議論は、まったく異なる二つの視点を示した。
一部の開発者は、この発見が普通のユーザーへの実害は限定的だと考える。ユーザー “Aurornis” は、ほとんどのユーザーは自らの User-Agent を偽装しないため、tanh でOSを識別しても追跡者に追加の情報はもたらさない——User-Agent 自体がすでにサイトにあなたのOSを教えている——と指摘した。この脆弱性はブラウザバージョンの範囲のフィンガープリントには意味があるが、それでも多くのフィンガープリントシグナルの中の小さな一片に過ぎない、と彼はみる。
一方、まったく別の視点もある。ユーザー “jeroenhd” は、この発見が Scrapfly のようなアンチスクレイピング企業にとって重要なのは、彼らがクローラープログラムを本物のブラウザに偽装させる必要があるからだと指摘した。Linux の仮想マシン上で動くクローラーが、自分は macOS 上の Chrome だと名乗っていても、tanh の戻り値が本当のOSを売ってしまえば、アンチスクレイピングシステムは容易にそれがボットだと見抜ける。
筆者は、双方にそれぞれ道理があると思う。普通の、誠実なブラウザユーザーにとっては、Math.tanh の漏洩は確かに余計なお世話だ——あなたの User-Agent はすでに能動的にサイトにあなたのOSを教えているのだから。しかし身元を隠そうとするユーザー（プライバシー保護の目的であれ、データ収集の目的であれ）にとって、この新発見のシグナルはこういうことを意味する。User-Agent を偽装するだけでなく、数学関数の戻り値まで偽装しなければならない、と。
ここからより深い問いが浮かぶ。インターネットのアーキテクチャの中で、私たちが「中立的」「標準化されている」と信じていたインフラのうち、どれほどのものが実は、私たちのデバイスについての固有のシグナルを静かに伝えているのか。一つの数学関数、一行の CSS、一片の音声処理——それらは本来、身元の手がかりになるべきではない。だが、下層の実装の多様性ゆえに、事実上の追跡識別子になってしまう。
これから何が起きるか
現在、この漏洩経路は Chrome 148、149、150 に影響している。Chrome チームはこの問題についてまだ公に回答していない。Scrapfly チームによれば、この漏洩経路を完全に閉じるには、ブラウザが各層（V8、Blink、Web Audio）で統一された数学ライブラリを使うか、少なくとも出力に対して「平滑化」の処理を施す必要がある。しかしそれは性能の低下を招く可能性があり、互換性と保守の面でも少なくない困難がある。
普通のユーザーに向けて、筆者はこう言いたい。パニックを起こす必要はない。この発見はプライバシー研究の分野での、興味深いが緊急ではない新シグナルであり、あなたのアカウントが盗まれるような深刻なセキュリティホールではない。注目に値するのは、ユーザーのデジタル足迹が完全に隠すのがますます難しくなっているという傾向を代表しているからだ。
この物語の真の意味は、おそらくより普遍的な観察を浮き彫りにしていることだ。ソフトウェアシステムの複雑な依存チェーンの中で、一見取るに足らない下層の選択のどれもが、上層で予期せぬプライバシーの帰結を生み得る。Chrome チームの一度のコード整理——冗長を減らし、性能を上げるためのものだった——が、思いがけずOS識別の新たな窓を開けてしまった。この意味で、Math.tanh の物語は「意図と副作用」についての古典的な事例だ。
参考リンク：
- Scrapfly: Browser Math OS Fingerprint
- HN ディスカッション (item?id=48884853)