私たち人間がオンライン世界とやり取りするためには、キーボード、画面、ブラウザ、デバイスなどのゲートウェイが必要です。オンラインで「人間検出」と呼ばれているものは、人間がこのようなデバイスとやり取りする際に使用するパターンです。こうしたパターンは近年変化しています。スタートアップ企業のCEOがブラウザでニュースを要約したり、テクノロジー愛好家が夜間のセールを開始するときにコンサートのチケット予約プロセスを自動化したり、視覚障害者がスクリーンリーダーでアクセシビリティを利用できるようにしたりする企業などです。従業員のトラフィックをZero Trustプロキシ経由でルーティングします
同時に、Webサイト所有者はデータ保護、リソース管理、コンテンツ配信の制御、不正使用の防止を求めています。これらの問題は、クライアントが人間かボットかを知るだけでは解決できません。必要なボットと望ましくない人間が存在するのです。これらの問題には、意図と行動を知る必要があります。自動化を検出できる能力は依然として重要です。しかし、アクター間の区別が曖昧になりつつあるため、私たちが今構築するシステムは、「ボット対人間」が重要なデータポイントでなくなる未来に対応する必要があります。
実際に重要なのは、抽象的な人間ではなく、この攻撃トラフィックか、そのクローラーの負荷は返信トラフィックに比例しているか、このユーザーがこの新しい国から接続するか、広告がゲームに統合されているか、などの質問です。
「ボット」という用語で議論しているのは、2つのストーリーです。1つ目は、Webサイトの所有者がトラフィックを回復できないときに、既知のクローラーを通過させるべきかどうかです。これについては、なりすましなしに識別したいクローラー向けのhttpメッセージ署名を使用したボット認証で触れました。2つ目は、Webブラウザが従来行ってきた動作と同じ動作を組み込んでいない新しいクライアントの出現です。これは、プライベートレート制限などのシステムにとって重要です。
この記事では、現在のWeb保護がどのように機能しているか、そしてボットと人間の境界が消失しつつある中で、どのように進化しなければならないかを探ります。
Webを利用するとき、私たちが毎日やり取りしている何千ものサーバーと直接通信することはありません。私たちはWebブラウザを使用しています。これらは、「ユーザーエージェント」として知られており、彼らは私たちの代わりに、コンピューター全体または携帯電話へのアクセスを許可することなく、安全に買い物をしたり、閲覧したり、Webを視聴したりできるように、私たちの利益を代表しています。
Webサイトは、ブラウザの動作にも関心を持っています。コンテンツが正確に表示される（モバイルの画面にフィットする、適切な背景色、正しい言語を使用する）ことを望んでいます。また、Webサイトは、ユーザーが購入、記事の読み、マイクを使用、パスワードなしで安全にサインインできるようにしたいと考えています。記事の横の広告を表示してもらうことも必要です。
ブラウザユーザーとWebサイトの利益間のこうした緊張関係は、長い間続いています。出版業者は通常、ユーザーの体験にピクセルレベルの制御を求めますが、ブラウザの反対側のユーザーは、多くの場合、出版業者が想定していない方法でデータにアクセスしたいと考えます。
Webブラウザベンダーとそれを取り巻く標準エコシステムは、これらの利益のバランスを取るために慎重な注意を払ってきましたが、時には大きな異論も生まれました。たとえば、ブラウザの拡張機能を使用して広告をブロックできますが、時間の経過とともに、ブラウザはそのような拡張機能ができることを制限してきました。アクセシビリティ標準（例：WCAG）は、ピクセルについてではない方法でWebコンテンツを使うための道を開き、多くの場所で規制要件に支えられています。それぞれのトレードオフの詳細については尋ねられますが、パッケージとして提供されます。Web上に居たいなら、出版業者であろうとユーザーであろうと、それを受け入れなければなりません。
しかし今、そのバランスは変化しつつあります。アシスタントがニュースの要約や調査を集約することは新しい概念ではありませんが、AIはこの能力を誰でも使えるようにします。新興クライアントの動作方法から摩擦が生じるのです。人間のアシスタントは、出版社に知らないうちに記事を印刷したり、スクリーンショットを作成したりするかもしれませんが、最初にサイトをレンダリングするために標準的なWebブラウザを使用しています。AIエージェントはこの手順を回避し、ブラウザが構築した出版業者とユーザーの権利に対するバランスの取れたアプローチを崩壊させます。ページをレンダリングせずに、生データを静かに取得します。パブリッシャーにとって、既存のブラウザトラフィックとのオーバーラップのため、これらのクライアントは本質的に不透明なものです。Webサイトの所有者には、取得されたコンテンツが1つのプライベートレポートを提供しているのか（おそらく歪曲された、場合によっては帰属していない）、または100万人のユーザーを対象としたモデルの訓練に取り込まれているのかがわかりません。これにより、サイトをオンラインに保つための予測可能な（そして収益化可能な）トラフィックが混乱に陥れるのです。
Webを機能させた暗黙の合意は、破綻しつつあります。その仕組みを理解するために、次のセクションではインターネット上の一般的なアーキテクチャについて取り上げます。
少し戻って、インターネット上の主要なデプロイメントパターンの1つであるクライアントサーバーモデルについて見てみましょう。クライアントは、リソースを取得するためにサーバーにリクエストを行います。
図1：クライアントサーバーモデルクライアントは、サーバーが応答するリクエストを送信します。
より多くのリクエストを処理するために、Webサイトが提供する容量を増やすことができます。追加のサーバーをデプロイしたり、静的トラフィックの前にキャッシュを配置したりできます。同様に、1人のクライアントがより多くのリクエストを行ったり、クライアントの数が増えたりした場合も、クライアント側から来るリクエストの数が増えることがあります。
図2：複数のクライアントが複数のリクエストを異なるサーバーに送信し、うち1つはCDNに配置されます。
そのシンプルさが、Webが成功した要因の1つだと思います。さまざまな種類のクライアントが存在できるようになり、各サーバーが反対側にどのようなソフトウェアがあるかを正確に知る必要なく、ネットワークが進化することになります。
図3：サーバーにリクエストを送信する2つの異なるクライアントコンテキスト各サーバーはリクエストしか見ませんが、その背後にあるエンドユーザーは見ません。
その開放さは、不確実性も生み出します。Webサイトは、リソースに対する有効なリクエストを確認できますが、通常、レスポンスがサーバーを離れた後はどうなっているか、キーボード、マウス、画面を使用してブラウザを制御する人のためにコンテンツがレンダリングされるかどうかはわかりません。あるいは、自動的にリクエストを行い、レスポンスをアーカイブし、インデックスを作成し、より大きなシステムにフィードする、独立したプログラムである場合もあります。
このモデルは驚くほどうまく機能します。そのため、Webサイトの運営は、インターネットに接続したWebサーバーを起動するという簡単な作業です。サーバーがどのリクエストに対応できるか、信頼するか、優先順位をつけるかを決定するまでしか保持されません。
容量の問題もあります。サービスがグローバルに1秒あたり100件のリクエストを処理するようにプロビジョニングされているにもかかわらず、200件のリクエストを受信している場合、特定のリクエストをドロップする必要があります。サーバーにCPUが1つしか搭載されておらず、着信リクエストに2つのCPUが必要な場合、リクエストをドロップしなければなりません。200通を配信するコストが高額である場合は、すべてのリクエストをレート制限する必要があります。
ランダムにリクエストをドロップすることができます。それはおそらく不当であり、必要なクライアントに影響を与えることで標的を見逃す可能性がありますが、うまく機能します。他のシグナルがない場合、他の選択肢はありません。
容量は全体像の一部に過ぎません。サーバーは、攻撃を通常のトラフィックと区別する、悪意のない負荷を管理する、データの不正利用を防ぐ、広告詐欺を制限する、偽アカウントの作成を防ぐ、自動化されたアクションを阻止するなど、その他にも多くの理由でクライアントを区別しようとします。アナウンスします。
難しさは、Webクライアントがデフォルトで認証されていないことと、多くの部分的なシグナルが公開されることです。したがって、ほとんどのサーバーは受信した情報に基づいてアクセス制御ロジックを適用することを決定します。単一のIPアドレスが他のIPアドレスの10倍のリクエストを行っている場合、そのIPアドレスはブロックされる可能性があります。さらに進んでいるサーバーは、このIPアドレスがVPNによって使用されていると推測できるため、複数のユーザーのトラフィックをプロキシする可能性があります。サービスは係数を適用することを決定できます。各クライアントが1秒あたり10リクエストを送信できると仮定すると、共有IPアドレスは、リクエストがドロップされる前に100 rpsを許可されます。
これは、ボット管理にとって重要な要素の1つです。サーバーが意思決定できるように、クライアントに関するより多くの情報を提供することを目的としています。この情報は本質的に不正確です。これは、クライアントはサーバーの管理下にないためです。さらに、同じ情報から、パーソナライズされた広告などの異なる目的にサーバーが使用できるフィンガープリントベクトルが作成されます。これにより、軽減ベクトルを追跡ベクトルに変換します。
大まかに見たサーバーはクライアントから次のようなシグナルを受け取っています：
パッシブクライアントシグナル：インターネット上でリクエストを行うのに必要です。クライアントは必ずIPアドレスを送信し、通常、TLSセッションを確立します。
アクティブクライアントシグナル：クライアントが任意に提供するもので、エンドユーザーには見えないことが多いです。これには、User-Agentヘッダーまたは認証資格情報が含まれます。
サーバーシグナル: リクエストを処理するエッジサーバーの地理的な位置や、リクエストを受信した現地時間など、サーバーが観測する情報。
帯域幅消費型の不正利用を制限し、上限を定めるために、オリジンにとって重要なのは、クライアントが複数のリクエストを送信できる能力と意図です。広告資金によるWebサイトの場合、オリジンは広告が実際にエンドユーザーに表示されるという確信を持つ必要があります。ブランドを維持するために、オリジンはクライアントがPDFリーダー、SVGレンダリング、仮想キーボードなどの特定のレンダリング機能を備えていることを確認したい場合があります。また、リクエストが傍受するプロキシから来ている場合、オリジンはリクエストが実際にエンドクライアントから発信されていることを確認したいと考える場合があります。
トラフィックが増大すれば、運用コストも増大します。金銭的な有無にかかわらず、クライアントが価値を生み出しなければ、サーバーにはそのコストを負担するインセンティブはありません。
オペレーターによって、この環境への対応は異なります。大規模なクローラーやプラットフォームの中には、予測可能なアクセスに起因するコストに見合うだけの価値があるものです。役に立つかもしれません。また、ブロックされることが多い、匿名性を求めている、エンドユーザーの代わりに操作しているなどの理由から、個人を特定しようとするものもあります。その結果、部分的なシグナルに基づいて不安定なバランスが保たれています。
これが、人間対ボットという枠組みが誤解を招く理由です。オリジンが気にしているのは、抽象的な人間ではなく、クライアントがサイトがサポートできる方法で行動しているかどうかです。
図4：レート制限のトリレンマ分散型、匿名、説明責任 — 両方を選択
インターネットへのアクセスを管理する方法には、分散型、匿名性、説明責任など、基本的な緊張関係があります。この2つを選んでください。
完全に分散化され、匿名性が高いということは、説明責任が問われないことを意味します。ブロックされたクライアントは、その評判に影響を与えることなく、新しいアカウントを立ち上げることができます。これは、オリジンがリソースを管理するために、より多くの投資をしなければならないことを意味しています。これがWebのデフォルトです。
分散型+説明責任を持つということは、誰もが誰であるかを知ることができ、特定のユースケースに対しては機能しますが、明確な欠点もあります。「ログインでログイン」などのOAuthメカニズムは、アカウントの登録や第三者への開示を必要とします。
匿名かつ説明責任には、ガバナンス、ルール、および施行が求められる可能性が高いです。広くデプロイされたシステムには、同じ攻撃者で両方の特性を達成するものはありません。最も近い前例はWeb PKIで、ガバナンス（CAポリシー、証明書の透明性）によりサーバーに責任を課しています。このガバナンスが破られると、結果が生じます。現在、クライアント側で同等なものは存在しません。
現在のツールは、この1番目の空間の要素に基づいて構築され、2番目の空間を攻撃します。TLSフィンガープリント、IPアドレス、robots.txtなどです。説明責任を試みますが、それは派生したフィンガープリントが安定している限り、保持されます。
着信トラフィックの処理方法を決めるWebサイトの所有者にとって、意味のある区別は必ずしもボットと人間ではありません。これは、オリジンが受信するトラフィックを理解することと、クライアントのプライバシーを保護することのニーズのバランスを取ることです。
図5：クローラーがサーバーに複数のリクエストを行う
トラフィックの中には、検索エンジンクローラー、クラウドプラットフォーム、企業インフラストラクチャなど、大量のリクエストを行う既知の運用者から来ているものもあります。そうした攻撃者は、多くの場合、プライバシーの期待は低いものです。特定可能なソースから何百万ものリクエストを行うインフラストラクチャなのです。リクエストのソースを特定する機能があるため、インフラストラクチャプロバイダーが過剰なリクエストを送信している場合や、不適切なページにアクセスしている場合に、誤判断を軽減することができます。自己識別は、私たちが提案した責任あるAIボットの原則の1つです。これらの原則に基づいて、CloudflareはRadarのURLスキャナーを運用し、クロール機能を公開しています。
このトラフィックでは、IDが機能します。より正確には、信頼できるアクセスに価値があるため、一部の運用者は属性別のリクエストを許容することができるのです。HTTPメッセージ署名を使用したWebボット認証により、操作者はリクエストに暗号化された署名をすることができます。たとえば、OpenAI、Google、Cloudflare、またはAWSなどのプラットフォームから発信されたリクエストに署名します。オリジンは、IPレンジやUser-Agent文字列を使用することなく、「このリクエストが本当にプラットフォームインフラストラクチャからのものであるか」ことを検証できます。
人間やその他のエンドユーザーは、識別可能であること以外にも、彼らのアクセスや体験の質を犠牲にすることなく匿名性を維持することを期待しています。
図6：3つの異なるブラウザがサーバーにリクエストを行います。1つは人間によって操作され、もう1つはデバイス上のアシスタントが操作し、もう1つは企業のプロキシを介してプロキシされます。
その他のトラフィックは、多くの送信元から来て、それぞれのリクエストは比較的少ないものです。これには、Webを閲覧する人間、測定を行う研究者、家庭用プロキシを使用するスクレイパー、そしてますます人間に代わって行動するAIアシスタントが含まれます。
そして、ボットと人間の区別が攻撃になりつつあります。コンサートチケットを予約するAIアシスタントと実際に手作業で予約する人間との間に大きな違いはありません。どちらも分散型です。どちらにも匿名性が必要です。いずれの場合も、オリジンは、サービスを悪用するのではなく、意図したとおりに使用したいユーザーにとっては摩擦を減らしたいと考えるでしょう。
IDは機能するIPアドレスに対する古い仮定に代えて、アカウントログイン、メールアドレス、またはハードウェアキーで証明された、特定のクライアントに関連付けられた一意で検証可能な属性セットを提供する必要があります。ただし、Webサイトにアクセスする際は、このIDを提示する必要があることを意味します。また、プライバシーも侵害します。
私たちは、IDを証明せずに、動作を証明する最新のソリューションを構築したいと考えています。
2019年以降、Cloudflare経由でWebサイトにアクセスするクライアントは、リクエストとともにプライバシートークンを送信することで、こうした動作証明を提供できるようになりました。これは、Cloudflareの早期プライバシーパスのサポートによるものです。プライバシーパスは、RFC 9576、RFC 9578で標準化されており、クライアントは、チャレンジを解決したなど、いくつかの事前チェックの結果を安定した識別子に変えることなく、発行者が支援する証明を保持することができます。以前の訪問、リクエスト、セッションとリンクできないトークンを定義します。
これは、フィンガープリンティングとは異なるモデルを提供するため、重要です。パッシブのシグナルを収集する代わりに、サーバーはクライアントにアクティブなプライバシー保護シグナルを要求することができます。
これにより、セッション確立時の摩擦が減ります。プライバシーパスは、主に プライバシーリレーサービス 向けに、Cloudflareのインフラ全体で1日あたり 数十億トークンにまで拡大しました 。
図7：RFC 9576の第3.1条に記載されたプライバシーパスと発行プロトコルの相互作用
RFCは4つの役割を強調しています。発行者は、1人または複数のアテスターを信頼して、クレデンシャル（RFCではトークン）を発行する前にいくつかのチェックを行います。クライアントはこれらの認証情報を保持し、適切なスコープ内で、いつ提示するかを決定します。オリジンは、どの発行者を信頼するか、それぞれのプレゼンテーションが何を意味するかを制御します。これは、不正利用やポリシーに関する質問を削除するのではなく、クライアントとサーバーに、それらに対処するためのプライバシーを保護する方法を提供するだけです。
このシステムはシンプルですが、限界もあります。たとえば、動的なレート制限はできません。クライアントが100個のトークンを発行され、最初のセッションまたは2回目のセッション後に多くのリソースを消費し始めた場合、以前に発行された残りのトークンを無効にする方法はありません。
さらに、リンクできない特性があるため、新しい発行者が出現するのは困難です。発行者トークンが伝えるシグナルの質に関して、オリジンが提供できるフィードバックメカニズムはありません。
最後に、発行者が提供するトークンの数と、それらが引き換えられたときにそれらのトークンを使ってできるリンクできないプレゼンテーションの数との間には1対1の関係があります。プレゼンテーションごとにトークン1つです。理想的には、クライアントが発行者に一度連絡するだけで、特定のオリジンコンテキストに焦点を当てた複数のプレゼンテーションを実行できるシステムが必要です。これは、使い捨てのトークンを繰り返し取得するのではなく、ユーザーエージェントが認証情報を保持し、その資格情報から得られた証明を提示するというものです。
私たちの目標は、オープンなプライベートレート制限エコシステムの確立を支援することです。その精神に則り、匿名レート制限認証情報（ARC）や匿名クレジットトークン（ACT）などの新しいプライバシーパスプリミティブの開発・探求を支援しています。
たとえば、CTDを使用することで、クライアントは「私がこのユーザーである」ことを明らかにしなくても、「このサービスに良い実績がある」ことを証明できます。CTは、プロトコルレベルでプレゼンテーション間のリンク解除性を維持しますが、これがここでの重要な暗号化プロパティです。RFC 9576第4.3条の共同発行者・オリジン展開モデルでも、トークンの発行と提示を直接リンクできないようにプロトコルが設計されています。これは、IPアドレス、Cookie、アカウントの状態、タイミングなどの他の層を通じた相関関係を排除するものではありません。ACTが実装するリバースフローフレームワーク内で、標準化されたVOPRFおよびBlindRSAプリミティブ を使用して、同じプロパティを提供できます。
成功するエコシステムは、オープンイシュア―のエコシステムである必要があります。実際のところ、これは誰でも認証情報を偽造できるという以上のことを意味します。オリジンは、どの発行者を信頼するかを判断できる必要があります。ユーザーエージェントは、リクエストされたものを一貫した方法で提示する必要があります。また、エコシステムには、発行者が評判を確立するため、信頼する側が低品質な発行者を信用しない方法が必要です。単一のゲートキーパーが参加をコントロールできるわけではありません。
これを機能させるには、ブラウザや他のユーザーエージェントで動作するプロトコルとクライアントAPIが必要です。展開がシンプルで、ユーザーにとって明確であり、ブラウザが不正な証明リクエストを単に表面化するだけでなく、制限できるような範囲まで狭めている必要があります。
Webサイトの所有者はすでに、新興クライアントによる混乱に反応しています。これは、大規模なスクレイピングやモデルのトレーニング、およびサイトが予期しない方法で動作するユーザーエージェントが原因の1つです。そこで、WebサイトはAIクローラーと関連ツールをブロックするための、より技術的な手段を求めています。ボットと人間の境界があいまいになるエコシステムでは、現在の対策だけでは効果が薄れるでしょう。
こういった対策が効果的でない場合、サイトは、コンテンツを閲覧するためにアカウントを要求したり、安定した識別子にアクセスを結びつけるという方向に達する可能性があります。つまり、広告でサポートされるログイン無料記事も、「月に3回の無料記事」もなくなるということです。他のコンテンツ企業は、Webから完全に移行し、データやサービスをAIベンダーに直接有料で提供したり、大規模なプラットフォームが運営する壁に囲まれた庭内でデータやサービスを提供することがあります。
こうした結果は悪いものです。誰もが、Webが提供する情報へのオープンなアクセスの恩恵を受けています。すべてのサイトがこのような選択をするわけではありません。オンラインでコンテンツを提供する理由はたくさんありますが、そのすべてが商業的であるわけではありません。しかし、それだけのサイトがそうなれば、Web上の「正常」なものが変わってしまうのです。
これは、オープンWebとは、一握りのプレイヤーに依存することなく、さまざまなクライアントがさまざまなソースから情報を収集できる環境であるため、重要です。また、さまざまな情報源があることで恩恵を受けています。情報へのアクセスが主として少数の企業を介して行われているWebでは、我々はあまりにも少数の企業にあまりにも多くの権限を与えています。その結果、匿名クライアントにとってフリクションが増えるだけでなく、出版業者がユーザーと会う方法が少なくなり、インターネットがより脆弱になります。
私たちが構築しているものを明確にする必要があります。プロパティを証明するためのインフラストラクチャが、プロパティを必要とするインフラストラクチャになる可能性があります。匿名認証情報は、その所有者について何かを証明するためのものです。たとえば、「チャレンジを解決した」、「レート制限を超えていない」などです。しかし、任意の単一属性を証明できるシステムは、他の属性も証明できるであり、その点が懸念点です。
現在、プライバシーパストークンを提示すると、「CAPTCHAを解決した」と伝える場合があります。明日は、同じシステムがまったく異なる属性を証明するかもしれません。たとえば、「デバイスが証明書がある」デバイスにのみトークンを発行すると、古いデバイスとそのユーザーを除外します。同様に、「AppleまたはGoogleのアカウントがある」などの属性を要求する場合、非主流のプラットフォームのユーザーは除外されます。
匿名証明を検証するインフラストラクチャが実現すれば、証明されるものは拡張可能です。これによってインターネットへのアクセスがゲートされないようにする必要があります。
ゲートはすでに存在します。プラットフォームには、ますますIDが必要になっています。Webサイトは、共有プロキシから来るトラフィックをブロックしています。問題は、ゲートが表示されるかどうかではなく、ユーザーが自分のプライバシーを引き続き管理できるかどうかです。
これまで述べてきたように、ボット管理ではいくつかのシグナルを共有する必要があります。匿名証明の代替は、さらに悪いものです。匿名で属性を証明する能力がなければ、すべてのゲートがフィンガープリントを必要とします。特定のブラウザからのリトライ、アカウントのリンク、VPNの使用は不要です。これらは、自分の接続がプロキシされていることを知らない人など、選択肢にない場合があります。
プライバシーを保護する認証情報は、信頼やポリシーの必要性を排除するものではありません。そうすることで、要求をより明確にし、蔓延しないものにすることができます。指紋とは異なり、証明は明示的です。ユーザーは要求されている内容を確認でき、WebブラウザやAIアシスタントなどのクライアントは同意の強制を支援することができます。
誰もがサービスを利用するインターネットの次の方法を評価するための簡単なテストがあります。誰もが世界中のどこからでも、自分のデバイス、自分のブラウザを構築し、オペレーティングシステムを使用し、Webにアクセスできるようにする方法です.その特性を保つことができず、特定のメーカーからのデバイス認証が唯一の実行可能な信号になった場合、停止すべきです。
つまり、ゲートキーパーが誰を参加できるかを決めるのではなく、オープンなイシュア―エコシステムを醸成する必要があるということです。レート制限のトリレンマでは、オープンWebでは分散化が義務付けられています。構築方法はまだ十分にはわかりませんが、発展させる必要があることはわかっています。
今までWebは概ねバランスが取れています。幸運な偶然だったものもあるかもしれませんが、避けられなかった可能性もあります。Webは、同様のリソースにアクセスするさまざまなクライアントをサポートするのに十分なオープン性を維持できたため、多くのエンドユーザーやパブリッシャーにとってうまく機能しました。
その残高が危険にさらされています。Webのプライバシー保護プリミティブは、プライバシー保護、オープン、説明責任という異なる結果を構築するための一つの試みです。必ずしも成功するわけではありません。しかし、待った方がいいのです。
追跡や参加にご興味をお持ちの方には、IETFとW3Cにて公開で行っています。私たちは、現在のWebを形作るために人々が集まった既存の場所が、未来のWebをデザインするのに最適な場所であると信じています。
インターネットはエンドユーザーのためのものであり、ユーザーがその中心に位置する必要があるのです。