ステルスプラグインを超えて：Clark-Browserによる真のブラウザ匿名性の実現

ブラウザ自動化エージェントを構築する開発者にとって、ボット検知との「いたちごっこ」はますます巧妙になっています。PuppeteerやPlaywrightのようなツールは業界標準ですが、それらのデフォルトのヘッドレスモードは、現代のセキュリティサービスにとって検知が容易なものです。ほとんどの開発者は、これらのシグナルを隠蔽するためにJavaScriptレベルの「ステルス」プラグインに頼っていますが、検知エンジンが進化するにつれ、これらのシim（継ぎ当て）は、隠そうとしているボットそのものと同じくらい検知されやすくなっています。

そこで登場するのが Clark-Browser です。これは ungoogled-chromium のオープンソースフォークであり、戦場をJavaScriptレイヤーからC++ソースレベルへと移すように設計されています。ブラウザのバイナリ自体にパッチを当てることで、Clark-Browserは自動化されたインスタンスを、本物のユーザーによるインストールと区別がつかないようにすることを目指しています。

JSレベルのステルスの限界

なぜClark-Browserが必要なのかを理解するには、ボット検知がどのように機能しているかを理解する必要があります。標準的な chromium --headless は、明白なシグナルの痕跡を残します：

  • navigator.webdriver が true に設定されている。
  • プラグインリストが空である。
  • User-Agent に明示的に HeadlessChrome が含まれている。
  • WebGL文字列が、物理的なGPUではなくソフトウェアレンダラーであることを示している。

多くの開発者は puppeteer-extra-plugin-stealth や playwright-stealth のようなライブラリを使用しています。これらのツールは、JavaScriptを注入してこれらのプロパティを上書きすることで機能します。しかし、FingerprintJS、BrowserScan、Cloudflare Turnstileなどの高度な検知スイートは、ステルスプラグインの「存在」自体を検知できることがよくあります。ウェブサイトが、JSプロキシやgetterのオーバーライドを介してプロパティが変更されたことを検知すると、高リスクのフラグが立てられます。

C++アプローチ：ソースへのパッチ適用

Clark-Browserは、根本的に異なるアプローチを取ります。ブラウザが起動した後に証拠を隠そうとするのではなく、バイナリがコンパイルされる前に blink、v8、net のソースコードを修正します。

C++レベルでアンチフィンガープリントを実装することで、JavaScript環境に返される値は、伝統的な意味での「偽装（spoofing）」ではなく、ブラウザエンジンが実際に持っている値となります。これにより、JSレベルのシムが作成する不整合が排除され、JavaScriptから見えるフィンガープリントの全領域において、ブラウザがネイティブのChromeインストールとして見えるようになります。

ステルス・サーフェス

Clark-Browserは、一連の --fingerprint-* コマンドラインスイッチを導入しており、開発者がブラウザインスタンスの決定論的なアイデンティティを定義できるようにしています。これにより、以下を精密に制御できます：

  • ハードウェアプロファイル: GPUベンダー、レンダラー、デバイスメモリ、ハードウェアコンカレンシーの偽装。
  • 環境データ: IANAタイムゾーン、BCP 47ロケール、地理位置情報座標の設定。
  • ネットワークアイデンティティ: WebRTC IPアドレスの偽装によるリーク防止。
  • ビジュアルノイズ: 決定論的なフィンガープリントを防ぐためのキャンバスおよびオーディオノイズの実装（Braveのインフラを継承）。

パフォーマンスと検証

プロジェクトのドキュメントによると、リリースされたバイナリはすでにいくつかの重要なテストに合格しています。SannySoft WebDriverテストとAntoine Vastelのヘッドレステスト（正しい Accept-Language ヘッダーが使用されている場合）に合格しています。また、BrowserLeaksのClient HintsおよびWebGLテストにも合格しており、ヘッドレス環境に典型的な SwiftShader や llvmpipe のマーカーを回避しています。

しかし、コミュニティは慎重な姿勢を崩していません。Hacker Newsのディスカッションでユーザーが指摘しているように、現代の検知、特にCloudflareによる検知は、単純なプロパティチェックを超えたものになっています。

「彼らはもはやnavigatorプロパティを見ているだけではない。キャンバス操作のタイミングを計り、レンダリングパイプラインの不整合をチェックしているのだ。」

Clark-Browserは静的なフィンガープリントには対処していますが、動的な挙動（タイミング攻撃やレンダリングパイプラインの分析）は、依然としてボット検知戦争の最前線です。

はじめに

Clark-BrowserはMITライセンスで提供されており、Playwrightでの使用を容易にするためのPythonラッパーが用意されています：

from clarkbrowser import launch

browser = launch()
page = browser.new_page()
page.goto("https://bot.sannysoft.com")
print(page.title())
browser.close()

最大限の透明性やカスタム構成を必要とする方のために、プロジェクトはLinuxおよびmacOS用のフルビルドスクリプトを提供していますが、ビルドプロセスはリソースを大量に消費し、約80 GBのディスク容量と32 GB以上のRAMを必要とします。

結論

Clark-Browserは、よりプロフェッショナルなグレードのブラウザ自動化への転換を象徴しています。検知回避ロジックをバイナリ内に移動させることで、非常に制限の厳しい環境で動作する必要があるエージェントに対して、より堅牢な基盤を提供します。最も高度なAI駆動の検知システムに対して100%の不可視性を保証できるツールはありませんが、ソースにパッチを当てることは、DOMにパッチを当てることよりも客観的に見て効果的です。

Sources