回答を受け入れましたが、残念ながら、当初の最悪のシナリオ、つまり、くだらないものを購入しようとするすべての人に CAPTCHA を課すというシナリオから抜け出せないと思います。簡単に説明すると、キャッシュ/Web ファームではヒットを追跡できず、回避策 (キャッシュされていない Web ビーコンの送信、統合テーブルへの書き込みなど) を講じると、ボットよりもサイトの速度が低下します。Cisco などの高価なハードウェアが高レベルで役立つ可能性はありますが、すべての人に CAPTCHA を課すという選択肢がある場合、コストを正当化するのは困難です。後でより詳細な説明を試みるとともに、将来の検索者のために整理します (ただし、これはコミュニティ ウィキなので、他の人が試してもかまいません)。
状況
これは、woot.com でのゴミ袋販売に関するものです。私は Woot Workshop の社長です。Woot Workshop は Woot の子会社で、デザイン、製品の説明、ポッドキャスト、ブログ投稿の作成、フォーラムのモデレーターを務めています。私は CSS/HTML を扱っていますが、他のテクノロジーについてはほとんど知りません。私は開発者と緊密に連携し、ここでのすべての回答 (およびこれまでに出た他の多くのアイデア) について話し合いました。
ユーザビリティは私の仕事の大きな部分を占めており、サイトをエキサイティングで楽しいものにすることが残りのほとんどの部分を占めています。以下の 3 つの目標はそこから生まれています。CAPTCHA はユーザビリティを損ない、ボットは私たちの粗悪な商品の販売から楽しさと興奮を奪います。
ボットは、ランダム クラップ セールを探して、1 秒間に何十回も当社のトップ ページにアクセスし、スクリーン スクレイピング (および/または RSS スキャン) を行っています。ボットがそれを見つけた瞬間、プログラムの第 2 段階が起動し、ログインして [I want One] をクリックし、フォームに記入して、クラップを購入します。
評価
lc: この方法を使用する stackoverflow やその他のサイトでは、試行されるタスクで認証済み (ログイン済み) のユーザーが必要になるため、ほとんどの場合、認証済みの (ログイン済みの) ユーザーを扱います。
Woot では、匿名 (ログインしていない) のユーザーがホームページを閲覧できます。言い換えると、スラムボットは認証されていない可能性があります (基本的に IP アドレス以外では追跡できません)。
そこで、IP スキャンに戻ることになりますが、これは、a) クラウド ネットワーキングとスパムボット ゾンビの時代にはほとんど役に立たず、b) 1 つの IP アドレスからアクセスする企業の数を考えると、無実のユーザーが多すぎることになります (非静的 IP ISP の問題や、これを追跡しようとするとパフォーマンスが低下する可能性があることは言うまでもありません)。
ああ、そして、人々が私たちに電話をかけるのは最悪のシナリオです。彼らからあなたに電話をかけてもらうことはできますか？
ブラッドC: Ned Batchelder の手法はなかなかクールに見えますが、サイト ネットワーク用に構築されたボットを破るためにしっかりと設計されています。問題は、ボットが特に当サイトを破るために構築されていることです。これらの手法のいくつかは、スクリプト作成者がボットを進化させてハニーポットを無視し、フォーム ID ではなく近くのラベル名をスクリーン スクレイピングし、JavaScript 対応のブラウザー コントロールを使用するようになるまでは、短期間は機能する可能性があります。
再び: 「もちろん、その宣伝がマーケティング戦略の一部である場合は別ですが。」はい、間違いなくそうです。アイテムが出現したときの驚きや、アイテムを入手できたときの興奮は、実際に手に入れるガラクタと同じくらい、あるいはそれ以上に重要なことでしょう。先着順を排除するものは、ガラクタを「勝ち取る」興奮を損なうものです。
ノヴァトラスト: そして、私は、新しいボット支配者を歓迎します。実際、サードパーティのアプリが製品情報を検索するためにサイトをスキャンできるように RSS フィードを提供していますが、メイン サイトの HTML より前ではありません。私の解釈が正しければ、あなたのソリューションは、目標 1 を完全に犠牲にして、ボットがほとんどのゴミを購入するという事実を諦めることで、目標 2 (パフォーマンスの問題) に役立ちます。あなたの回答に賛成票を投じました。最後の段落の悲観論が私には正確だと感じたからです。ここには特効薬はないようです。
残りの対応は、一般的に IP 追跡に依存していますが、これもまた役に立たない (ボットネット/ゾンビ/クラウド ネットワーキングの場合) だけでなく、有害 (同じ IP の送信先からアクセスする多くの無実のユーザーを捕まえる) であるように思われます。
他のアプローチやアイデアはありますか? 私の開発者は「CAPTCHA にしましょう」と言い続けていますが、私たちのゴミを欲しがっている実際の人間全員にとって、それほど邪魔にならない方法があることを願っています。
元の質問
たとえば、非常に高い価値があると認識されている安価な商品を販売していて、販売数量が非常に限られているとします。この商品がいつ売れるかは誰にもわかりません。そして、100 万人を超える人々が定期的にあなたの販売商品を見に来ます。
結局、スクリプト作成者やボットがプログラム的に [a] その商品をいつ販売するかを把握し、[b] 最初に購入できるようにしようとすることになります。これは 2 つの理由で厄介です。
- あなたのサイトは人間以外のユーザーによって圧迫され、すべてのユーザーの処理速度が低下しています。
- 結局、スクリプターが製品を「勝ち取る」ことになり、常連客は騙されたと感じてしまいます。
一見明白な解決策は、ユーザーが注文する前に通過しなければならないいくつかのハードルを作成することですが、これには少なくとも 3 つの問題があります。
- 人間にとっては、CAPTCHA を解読したり、猫を選んだり、数学の問題を解いたりする必要があるため、ユーザー エクスペリエンスは最悪です。
- 認識されるメリットが十分に高く、群衆が十分に大きければ、何らかのグループがあらゆる調整を回避する方法を見つけ、軍拡競争に発展します。(調整が単純なほど、これは特に当てはまります。非表示の「コメント」フォーム、フォーム要素の再配置、それらの誤ったラベル付け、非表示の「gotcha」テキストはすべて、一度は機能しますが、その後、この特定のフォームをターゲットに対抗するために変更する必要があります。)
- スクリプト作成者があなたの調整を「解決」できないとしても、彼らがあなたのフロントページを攻撃し、スクリプト作成者に手動で注文を記入するよう警告を鳴らすことは防げません。スクリプト作成者は [a] を解決することで有利になるので、注文ページに最初に到達する人間であるため、おそらく [b] で勝つでしょう。さらに、1. は依然として発生し、サーバー エラーが発生し、全員のパフォーマンスが低下します。
もう 1 つの解決策は、IP のアクセス頻度が高すぎないか監視し、ファイアウォールからブロックするか、または IP がアクセスしないようにすることです。これにより、2. を解決し、[b] を防ぐことができますが、IP のスキャンによるパフォーマンスの低下は大きく、スクリプト作成者が独自に引き起こす問題よりも 1. のような問題が多く発生する可能性があります。さらに、クラウド ネットワークやスパムボット ゾンビの可能性により、IP チェックはほとんど役に立ちません。
3 番目のアイデアは、注文フォームをしばらく (たとえば、0.5 秒) 強制的に読み込むというものですが、迅速な注文の進行が遅くなる可能性がありますが、この場合も、実際のユーザーに悪影響を与えない速度であれば、スクリプト作成者が最初に注文を処理できます。
目標
- スクリプトを使わない人間にアイテムを販売します。
- ボットによって速度が遅くならない速度でサイトを稼働させ続けます。
- 「通常の」ユーザーに、人間であることを証明するためのタスクを完了するよう要求して煩わせないでください。
ベストアンサー1
SO が CAPTCHA で行っているようなものを実装するのはどうでしょうか?
普通にサイトを使用している場合、おそらく警告が表示されることはありません。同じページを頻繁にリロードしたり、連続してコメントを投稿する速度が速すぎたり、その他の警告をトリガーする行為を行った場合は、警告をトリガーする人物が人間であることを証明してください。あなたの場合、これはおそらく同じページを頻繁にリロードしたり、ページ上のすべてのリンクを素早くたどったり、注文フォームに人間とは思えないほど速く入力したりすることになるでしょう。
チェックに x 回連続して失敗した場合 (たとえば、2 回または 3 回)、その IP にタイムアウトなどの措置を講じます。その後、タイムアウトの終了時に、再度チェックに戻します。
未登録のユーザーがサイトにアクセスしているので、IP のみを頼りにできます。必要に応じて、各ブラウザにセッションを発行して追跡できます。そしてもちろん、連続して (再) 作成されるセッションが多すぎる場合は、人間によるチェックを実行します (ボットが Cookie を削除し続ける場合に備えて)。
無実のユーザーを多く捕まえないようにするには、人間によるチェック ページに次のような免責事項を記載します。「このページは、同じ場所から匿名のユーザーが多数アクセスした場合にも表示されることがあります。これを避けるには、登録またはログインすることをお勧めします。」(文言は適宜調整してください。)
さらに、X 人のユーザーが 1 つの IP から同時に同じページを読み込む確率はどれくらいでしょうか。確率が高い場合は、ボット アラームに別のトリガー メカニズムが必要になる可能性があります。
編集: 別の選択肢としては、何度も失敗し、製品の需要に自信がある場合は、ブロックして、ブロックを解除するために直接電話をかけてもらうことです。
人間に電話をかけさせるのは愚かな手段のように思えますが、コンピューターの背後に人間がいることを確かめることになります。重要なのは、ボットでない限りほとんど発生しない条件（たとえば、チェックに連続して複数回失敗するなど）に対してのみブロックを設定することです。そうすると、電話を取るという人間によるやりとりが強制されます。
電話をかけてもらうというコメントに対して、明らかにトレードオフがあります。販売開始時に電話を 2、3 回受けるほど、ユーザーが人間であることを確認することに気を配っていますか? 製品が人間のユーザーに届くことをそれほど心配しているのであれば、この決定を下す必要があり、おそらくその過程で自分の時間を (少し) 犠牲にするでしょう。
ボットが優位に立ったり、サイトを攻撃したりしないようにしたいとお考えのようですので、電話は良い選択肢だと思います。私はあなたの製品で利益を得ていないので、こうした電話を受けることに興味はありません。ただし、その利益の一部をあなたに分配してもらえるなら、興味を持つかもしれません。これはあなたの製品なので、あなたがどの程度気にするかを決め、それに応じて実装する必要があります。
ブロックを解除する他の方法は、それほど効果的ではありません。タイムアウト (ただし、その後、サイトを再び攻撃して、これを繰り返すことができます)、長いタイムアウト (実際に製品を購入しようとしているのが人間であれば、チェックに失敗したことで罰せられ、どうしようもありません)、電子メール (ボットで簡単に実行できます)、ファックス (同じ)、または郵便 (時間がかかりすぎます) などです。
もちろん、タイムアウトが発生するたびに IP ごとにタイムアウト期間を増やすこともできます。ただし、誤って真の人間を罰しないように注意してください。