Cloudflare Turnstile、フィンガープリント取得可能なWebGLを要求

 (hacktivis.me)
1 ポイント 投稿者 GN⁺ 2026-06-01 | 2件のコメント | WhatsAppで共有
  • Cloudflare Turnstile の「Verify you're human」デバイス検証が、約1週間前から WebKitGTK ベースのブラウザーで無限に繰り返されるようになっている
  • 複数のウェブサイトへのアクセスが阻害されている直接の原因は、Cloudflare が WebGL を通じてデバイスのフィンガープリントを取得しようとしている挙動にあるとみられる
  • Turnstile の案内では、ブラウザーのフィンガープリント取得 を人間かどうかの確認に使っており、ブロックやランダム化ツールがボットのように見える原因になると説明している
  • WebKit はこのような機能を何年も前からブロックしており、ユーザーが簡単に無効化できるプライバシー保護オプションには見えない
  • Safari には例外があると推定される一方で、WebKitGTK ブラウザー全体 がブロックされており、Firefox の保護設定ユーザーにも影響する可能性がある

WebKitGTK で繰り返される Turnstile 検証

  • Cloudflare Turnstile の「Verify you're human」デバイス検証が、約1週間前から WebKitGTK ベースのブラウザー で無限に繰り返され、複数のウェブサイトへのアクセスを妨げている
  • アクセス遮断の原因は、Cloudflare が WebGL を通じてデバイスのフィンガープリントを取得しようとしている挙動にあるとみられる
  • Turnstile の案内文は、ブラウザーのフィンガープリント取得を人間かどうかの確認に利用すると明記している
  • フィンガープリント取得をブロックしたりランダム化したりするプライバシー保護ツールは、ブラウザーを正体を隠そうとするボットのように見せる可能性がある
  • WebKit はこのような機能を何年も前からブロックしており、簡単に無効化できるプライバシー機能には見えない
  • Cloudflare が Safari には例外を設けたと推定される一方で、WebKitGTK ブラウザー全体がブロックされた状態になっている

Firefox の関連保護挙動

関連記事

2件のコメント

 
GN⁺ 2026-06-02
Lobste.rs の意見

  • 記事では Firefox に関するいくつかの話が混同されているように見える。この作業を実際に行ったチームにいた立場から言うと、Firefox のフィンガープリント防御は複数の方法で動作している。
    まず、Firefox はいわゆる “unmasked” 文字列を含め、WebGL の vendor/renderer 文字列の情報を制限している。直接確認できるサンプルコードは Fatih が comment 14 に投稿している。何かを壊したという主張は完全に誤りだ。
    次に、Firefox は canvas 出力もランダム化している。同じ canvas で toDataURL() を呼び出してみると、セッションごとに返り値が微妙に異なる。たとえばプライベートブラウジング/通常モードや、異なる container tabs でテストできる。
    3つ目に、上記機能やその他の 最近のフィンガープリント防御機能 は、実証分析に基づいて Web を壊さず効果的に動作するよう作られている。その大半はデフォルトで有効で、さらに強化したければ設定で “Enhanced Tracking Protection” を strict に変更すればよい。
    4つ目に、resistFingerprinting モードは設定画面にはなく about:config からのみアクセスできるが、これは Web を壊す可能性があることが知られているため だ。Firefox フォークである Tor Browser のために残されているが、個人的には Enhanced Tracking Protection 側の保護のほうがはるかに優れていると思う。

  • フィンガープリント追跡を擁護するつもりはないが、今の仕事の一部として ボット対策ツールに関心がある。
    Cloudflare が Turnstile で目指しているのは、人間が CAPTCHA を解く必要のないボット防御ウィジェットを作ることのように見える。おそらくフィンガープリント追跡によって複数サイトでの行動を観察しつつ、大半のユーザーを通過させる方式なのだと思うが、この理解で合っているのだろうか。
    フィンガープリント追跡なしでも CAPTCHA 解答不要のウィジェットは実現可能なのか。そもそも可能なのか。Turnstile の回避はそれほど難しくないという話も聞いたことがある :tm:。すべてのボット対策ウィジェットは結局 曖昧さに依存したセキュリティに頼るしかないのだろうか。

    • この分野で働いていたが、前職を代表して話しているわけではない。フィンガープリント追跡は、複数の IP にまたがる 同一サイト内の単一行為者トラフィック を結び付けるために使われる。
      複数サイトをまたいで回遊しているかどうかはあまり重要ではなく、同じサイトに繰り返しアクセスしていることを検出するのが本質だ。
      フィンガープリント追跡なしで CAPTCHA なしのウィジェットを作るなら、ハードウェア証明も一応は機能する。ただし みんな嫌っている。Apple はハードウェア証明を提供しており、Cloudflare が Safari でこれを使っているため、Safari は canvas ランダム化をしていても通過できる。このブログ記事と違って、Cloudflare が Safari だけを特別扱いしているわけではない。
      あるいは proof of work を要求することもできるが、その場合は低価格帯の Android フォンしか持たない多くの Web ユーザーを排除してもよく、かつ個々のボット行為の価値が低くて、ボット運営者に proof of work を実行する動機がないことが前提になる。こうした条件はたまに当てはまるが、EC サイトや銀行のような場所には向かない。
      それ以外に良い解決策はない。Turnstile については詳しくないが、私がいた会社の製品では大規模な回避は確かに難しかった。ただし大規模でない場合には、あえて難しくはしていなかったし、Cloudflare も同じ判断をしていても驚かない。
      すべてのボット対策ウィジェットの目的は、ボットを不可能にすることではなく、Web サイトをボットで攻撃することを 経済的に不可能にする ことだ。だから他のサイバーセキュリティとはゲームが異なり、曖昧さはかなりうまく機能する。時間がたっても相手に継続的な追加コストを払わせることが目的だ。
    • canvas/webgl フィンガープリント追跡は、Web スクレイパーにとっては事実上 解決済みの問題だ。Web スクレイピング関連の職種では面接質問にすらなる。
      よくある解法は、描画コマンドを抽出することだ。コマンドをダンプする改変ブラウザを使うか、スクリプトを難読化解除して取得できる。
      その後、抽出した canvas/webgl スクリプトを自分の持つサイトに載せ、訪問者からボットに再利用できるフィンガープリントを生成すればよい。
      この方法はかなり堅牢だ。こうしたフィンガープリント追跡スクリプトはほとんど変更されない。変更すると canvas → GPU/vendor/browser/OS の組み合わせデータベースが無効になってしまうからだ。
      要するに、一般ユーザーをさらに不便にするだけで、深刻な Web スクレイパーたちはすでにさまざまな 回避戦略 を知っている、というまた一つの例だ。
 
GN⁺ 2026-06-01
Hacker News のコメント

  • Cloudflare はスクレイパー検知に ブラウザーフィンガープリンティング を使っていることで知られている。たとえば JA3 フィンガープリントをユーザーエージェントと照合して cURL のようなものはブロックし、OkHttp（Android クライアント）は許可するが、CycleTLS のようなパッケージで簡単に偽装できる [1]
    「ボット対策」としてインターネットの大きな部分を塞いでいるので擁護したくはないが、仕事量証明（PoW）を使わないならフィンガープリンティングは現実的な方法かもしれず、その結果、関係する全員のプライバシーは完全に台無しになる
    Android 向け Chromium のプライバシー重視フォークである Cromite は Cloudflare Turnstile と継続的に問題を抱えているが [2]、これは Cloudflare がチャレンジを通過させるためにさまざまな方法でフィンガープリンティングを行うためだ
    解決するには Cloudflare Browser Developer プログラムに参加する必要があるが、NDA への署名が必要で、プロジェクト管理者が拒否したのは妥当に見える
    Cloudflare がどれほど深くブラウザーフィンガープリンティングを掘っているか見たければ、issue [2] でチャレンジを通すためにどのフラグを無効にしなければならないかを見ればよい。少なくとも Cloudflare は、人をフォーム送信やウェブサイトへのアクセスから単に締め出す代わりに、仕事量証明に置き換える くらいの柔軟さは持てると思う
    [1]: https://github.com/Danny-Dasilva/CycleTLS
    [2]: https://github.com/uazo/cromite/issues/2365

    • Cloudflare の「ボット対策」はインターネットの大きな部分だけでなく、多くの人々 も締め出している。ウェブサイトのアクセス制御をろくに考えずに 1 社へ外注する流れは非常に心配だ
    • フィンガープリンティングベースの ボット対策は幻想 に近い。クライアント側のシグナルは平均以上の腕があれば偽造できるし、フィンガープリンティングは広告事業のための市場集中手段にすぎない
      家庭向け IP と商用帯域にレピュテーションを与えることも、望む結果を得る別の方法かもしれない。事業者が IP の悪用にずっと慎重になるだろうが、そうなると攻撃者側と防御側の両方の DDoS ビジネスが一緒に崩れる可能性がある
      皮肉なことに、自社ボットを作りながら他社ボットを止める方法にも投資している会社はかなり多い
    • Cloudflare のスクレイピング防止は 5ドルの南京錠 程度で、全部無駄骨だ。暇なティーンは止められても、素人泥棒すら止められないレベルで、誰かが公開データをスクレイプしたければ結局は持っていく。止める方法はない
    • 「ボット対策」のための フィンガープリンティング は、大規模監視のためのフィンガープリンティングと区別できない
    • 仕事量証明が生態学的に悪夢だという点をもっと説明してほしい。ざっくり計算すると大した問題には見えない
      5W の負荷を 2 秒かけると 0.002Wh で、スマートフォンも通さなければならないのだから、数十秒の仕事量証明を課すことはできない。1 日 80 億回の検査を 1 年続けても 8GWh だ

  • privacy.resistfingerprinting が「Strict」「Enhanced Privacy Protection」を選んでも有効にならないのには理由がある。長く有効にして使ってみたが、ウェブサイトが奇妙に壊れるので結局ずっと無効にしなければならず、回避策も追加する必要があった
    特定サイトの タイムゾーン処理 が狂って、予定を何度か逃しかけた。Firefox が壊れたのではないとユーザーに知らせるには、「ウェブサイトが壊れたり奇妙なグリッチが見えたり、コンピューターの時刻が違ったり、フォントがおかしかったり、動画がときどき再生されないなら、ここを押してフィンガープリント保護を無効にしてください」という常設バナーが必要なほどだ
    興味深いことに、Turnstile は resistfingerprinting では壊れるが fingerprintingProtection では動作する。後者はこうしたひどい状況を考慮しているようだ

    • デフォルトで有効にしない理由としては理解できるが、Strict 設定 でも有効にしない理由としては不十分だ
      Strict 設定ではサイトが壊れることはある程度予想するが、追跡経路が依然として大きく開いたままだとは思わない。欺瞞的に感じる

  • 少数派ブラウザーをメンテナンスしているが[0]、数週間前から複数のユーザーがこの問題に遭遇している[1]。今のところブラウザーのバグだとは見ていないが、もちろん関連バグがある可能性はあり、もっと多くの人に見てもらえれば状況を改善または緩和するアイデアや助けが得られるとありがたい
    [0]: https://konform-browser.codeberg.page/
    [1]: 大半なのか全員なのかは不明。テレメトリーなしで、ユーザー報告と自前のテストに依存している

  • 「偽装していると見破られたなら、十分に本気で偽装していなかったということだ。」
    この愚かな ボットとの戦争 はインターネットの衰退につながり、最終的には「承認された」ユーザー敵対的エージェントだけが許可される、もう一つの閉じた庭へと変えてしまうだろう。「AI スクレイパー」云々というたわごとに乗せられてはいけない。同意を捏造するための手段にすぎない

    • ボットがサーバーを叩くなら レート制限 をかければいい。他人にアクセスしてほしくないコンテンツなら、ウェブサーバーで配信しなければいい

  • Google と Cloudflare は Chrome 以外のブラウザー を使いにくくすることで取引でもしたのか？ Chrome を使えという圧力は強まる一方で、Chrome でできる広告フィルタリングはどんどん減っている

    • Chrome がウェブで最も人気のあるブラウザーだから起きる自然な結果の一つである可能性が高い。正常なトラフィックの大半が Chrome から来るのだから
    • 5 年前に Cloudflare を辞めたとき、社内利用が承認されていたブラウザーは Chrome だけだった
    • そこで終わりではない: https://blog.cloudflare.com/eliminating-captchas-on-iphones-...

  • 何かを隠すと自動的に「隠す理由のあるエージェント」側に分類される
    はっきり言えば、それこそが根本的な問題だ。インターネットのそれほど多くの部分が Cloudflare を経由しているのだから、特定のシグナル 1 つよりも強く悪意ある行為者ではないことを示せる 代替シグナル が十分にあるべきだ
    ただし同じ設定を使うユーザーが母集団にほとんどいないため、実際の解決策が出るまで非常に長くかかるかもしれない

  • 「身元を隠そうとしているようです」と言うが、そもそも彼らにそれを要求する権利はなかった

    • 同じ理屈なら、ウェブサイトのコンテンツを見る権利もないことになる

  • privacy.resistfingerprinting を知らなかったが、これからはすべての Cloudflare Turnstile を失敗させたままにするつもりだ

    • 有効にしたままでも Turnstile は問題なく動作する

  • privacy.resistfingerprinting 設定は Tor Browser のためのものだ

    • Tor Browser ではデフォルトで有効になっており、無効にできるかどうかも定かではない
      Tor Browser のプライバシー・セキュリティ関連パッチを多く取り込んだ Konform Browser や Mullvad Browser でもデフォルトで有効になっている

  • 犯罪に関する格言で、人口の X% がある法律を破っているならその法律は廃止すべきだ、というものが好きだ。嗜好用ドラッグが明白な例だ
    ランダムな canvas 処理 がボット行為として取り締まられていたのに、今では Firefox を使う全員がそれをしているのなら、Cloudflare も単に「合法化」すべきではないかと思う