30
スクリプト作成者によるWebサイトの非難
OverаэтотвопросестьответынаStack Overflowнарусском：Какустроитьловушкудляхакера、илидостойнаиотбии 私は答えを受け入れましたが、悲しいことに、私たちは最初の最悪のシナリオである、誰もががらくたを購入しようとするCAPTCHAに留まっていると思います。簡単な説明：キャッシング/ Webファームではヒットを追跡することができません。回避策（キャッシュされていないWebビーコンの送信、統合テーブルへの書き込みなど）により、ボットよりもサイトの速度が低下します。高レベルで役立つCiscoなどの高価なハードウェアが存在する可能性がありますが、すべてをキャプチャすることが代替手段である場合、コストを正当化することは困難です。後でもっと詳しく説明し、将来の検索者のためにこれを整理します（コミュニティウィキなので他の人も試してみてください）。 状況 これは、woot.comでのバッグの売り上げについてです。私は、Wottの子会社であるWoot Workshopの社長です。Wootの子会社であり、デザイン、製品の説明、ポッドキャスト、ブログの投稿、フォーラムのモデレートを行っています。私はCSS / HTMLを使用しており、他のテクノロジーにほとんど慣れていません。私は開発者と緊密に連携し、ここでのすべての答え（および私たちが持っている他の多くのアイデア）について話し合いました。 ユーザビリティは私の仕事の大部分を占めており、サイトをエキサイティングで楽しいものにすることは残りのほとんどです。ここで、以下の3つの目標が導き出されます。CAPTCHAはユーザビリティを損ない、ボットは私たちのがらくたの売上から楽しさと興奮を盗みます。 ボットは、ランダムクラップセールのために、フロントページを数十回、2番目のスクリーンスクレイピング（および/またはRSSのスキャン）で叩いています。彼らがそれを見た瞬間、それはプログラムの第2ステージをトリガーし、ログインし、I oneをクリックしてフォームに記入し、がらくたを購入します。 評価 lc：この方法を使用するstackoverflowおよびその他のサイトでは、試行されたタスクがそれを必要とするため、ほとんどの場合、認証（ログイン）ユーザーを処理します。 Wootでは、匿名の（ログに記録されていない）ユーザーがホームページを表示できます。つまり、スラミングボットは認証されない（そしてIPアドレスを除いて本質的に追跡できない）可能性があります。 したがって、IPのスキャンに戻ります。これは、a）クラウドネットワーキングとスパムボットゾンビのこの時代ではほとんど役に立たないこと、b）1つのIPアドレスから来るビジネスの数を考えると、あまりにも多くの無実をキャッチしていることです（非静的IP ISPおよびこれを追跡しようとする潜在的なパフォーマンスヒット）。 ああ、そして人々に電話をかけてもらうのは、最悪のシナリオです。彼らにあなたを呼んでもらえますか？ BradC：Ned Batchelderのメソッドは見た目はかっこいいですが、サイトのネットワーク用に構築されたボットを打ち負かすためにかなりしっかりと設計されています。私たちの問題は、ボットが私たちのサイトを打ち負かすために特別に構築されていることです。これらのメソッドの一部は、スクリプト作成者がボットを進化させてハニーポットを無視し、フォームIDの代わりに近くのラベル名をスクリーンスクレイピングし、JavaScript対応のブラウザコントロールを使用するまで、短時間動作する可能性があります。 lc：「もちろん、誇大広告がマーケティングスキームの一部でない限り」はい、そうです。アイテムがいつ出現するのかという驚きと、なんとかアイテムを手に入れられた場合の興奮は、実際に得られるがらくたと同じかそれ以上に重要です。先着/先着順を排除するものは、がらくたを「勝つ」ことのスリルに有害です。 novatrust：そして、私は、新しいボット支配者を歓迎します。実際にRSSフィードを提供して、サードパーティのアプリがサイトをスキャンして製品情報を取得できるようにしますが、メインサイトのHTMLの前にはできません。私がそれを正しく解釈している場合、あなたのソリューションは、目標1を完全に犠牲にし、ボットががらくたのほとんどを購入するという事実を辞任することによって、目標2（パフォーマンスの問題）を助けます。あなたの最後の段落の悲観論は私には正確だと感じているので、私はあなたの回答に賛成票を投じました。ここには特効薬はないようです。 残りの応答は一般にIP追跡に依存しますが、これもやはり（ボットネット/ゾンビ/クラウドネットワーキングでは）役に立たないと思われ、有害（同じIP宛先から来た多くの無実を捕まえる）のようです。 他のアプローチ/アイデア？私の開発者は「CAPTCHAをやってみよう」と言い続けますが、私たちががらくたを欲している実際の人間すべてにとって、それほど邪魔にならない方法があることを望んでいます。 元の質問 知覚価値が非常に高く、非常に限られた量の何かを安く販売しているとしましょう。このアイテムをいつ販売するかは、正確にはわかりません。100万人を超える人々が、あなたが何を売っているかを定期的に訪れます。 プログラムでスクリプト作成者やボットが[a]そのアイテムをいつ販売するかを把握し、[b]それらが最初に購入したことを確認します。これには2つの理由があります。 あなたのサイトは非人間によって非難され、すべての人のすべてを遅くしています。 スクリプト作成者は最終的に製品を「勝ち取り」、常連客に騙されたと感じさせます。 一見明白な解決策は、ユーザーが注文する前にジャンプするためのいくつかのフープを作成することですが、これには少なくとも3つの問題があります。 CAPTCHAを解読したり、猫を選んだり、数学の問題を解いたりする必要があるため、ユーザーエクスペリエンスは人間にとってはうんざりです。 知覚された利益が十分に高く、群集が十分に大きい場合、一部のグループは微調整を回避し、軍拡競争につながります。（これは、微調整がより簡単であるほど特に当てはまります。非表示の「コメント」フォーム、フォーム要素の再配置、それらの誤ったラベル付け、非表示の「ゴッチャ」テキストはすべて一度機能し、この特定のフォームをターゲットに戦うために変更する必要があります。） スクリプト作成者が微調整を「解決」できない場合でも、フロントページを非難したり、スクリプト作成者が手動で注文を完了するようにアラームを鳴らしたりすることはできません。彼らが[a]を解くことで利点を得たとしても、注文ページに到達する最初の人間になるので、彼らはおそらく[b]を勝ち取るでしょう。さらに、1。が引き続き発生し、サーバーエラーが発生し、全員のパフォーマンスが低下します。 別の解決策は、頻繁にヒットするIPを監視するか、ファイアウォールからIPをブロックするか、またはその他の方法で注文できないようにすることです。これは2.を解決して[b]を防ぐことができますが、IPのスキャンによるパフォーマンスヒットは巨大であり、スクリプト作成者が単独で引き起こしているよりも1.のようなより多くの問題を引き起こす可能性があります。さらに、クラウドネットワーキングとスパムボットゾンビの可能性があるため、IPチェックはほとんど役に立ちません。 3番目のアイデアは、注文フォームをしばらく（たとえば、0.5秒）ロードすることを強制することで、迅速な注文の進行を遅くする可能性がありますが、やはり、スクリプト作成者は、実際のユーザー。 ゴール 非スクリプトの人間にアイテムを販売します。 ボットによって減速されない速度でサイトを実行し続けます。 「通常の」ユーザーが人間であることを証明するために完了するタスクを煩わせないでください。