web-dev-qa-db-ja.com

CAPTCHAシステムが正確なのはいつですか?

これは非常に広範な質問であることは理解していますが、CAPTCHAを追加することがサイトの必須要件になる時期を正確に把握しようとしています。多くのクライアントから、CAPTCHAを自分のサイトに追加するように求められ、すべてのクライアントが必要とするわけではないようです。ただし、このトピックについては、私が思っているほど雄弁であるとは限りません。応答に次のような質問への回答が含まれていると役立つ場合があります。

  • どのような種類のWebサイトにCAPTCHAが絶対に必要ですか?
  • CAPTCHAの使用を検討する必要があるが、必ずしもそれらを必ずしも採用する必要のないWebサイトの種類は何ですか?
  • そのような障壁を持つことへの動機はほとんどないので、どんな種類のウェブサイトがCATCHAなしで行くべきですか?
9
robinhoode

CAPTCHAは、オンラインのボットがサイトにサインアップしたり、サイトに投稿したりできる場所に適しています。

Wikipedia は言うCAPTCHAは、乱用またはリソースの消費のために、自動ソフトウェアが特定のシステムのサービス品質を低下させるアクションを実行しないようにするために使用されます。 [...] CAPTCHAは、宣伝、嫌がらせ、破壊行為の結果であるかにかかわらず、ブログ、フォーラム、Wikiへの自動投稿を最小限に抑えるためにも使用されます。

質問への対応:

  • 自動投稿によって嫌がらせを受けているサイト。
  • 自動投稿に対して脆弱ですが、キャプチャ以外の方法でそれらを回避するサイト。
  • キャプチャ以外の方法での自動投稿に対して脆弱ではない、または効果的に回避されているサイト。
8
JOG

どのような種類のWebサイトにCAPTCHAが絶対に必要ですか?ウェブサイトがボットの犠牲になるという確固たる証拠があり、CAPTCHAのようにユーザーエクスペリエンスを低下させない他の方法でこの問題に対処できない場合を除いて、ありません。

他の意味

  • 銀行口座を検討してください。ハッキングを防ぐ1つの方法は、CAPTCHAをログオンフォームに追加することです。 UXの観点から見ると、これは惨事です。間違ったCAPTCHAを入力したとしましょう。次に、12文字の長さのパスワードを再入力する必要があります。かなり迷惑です。

    CAPTCHAを使用する代わりに、Webサイトは、失敗した試行の回数を同じIP /同じアカウントから1時間あたり3回に制限したり、適切な監査を使用してハッキングの試行を追跡したりできます。

  • Stack ExchangeのWebサイトを検討してください。質問をしたり、回答を投稿したり、何かにコメントしたりするたびに、これらのWebサイトからキャプチャを入力するように求められたら、私は腹を立てます。しかし、私が最もよく使用する一部のStack Exchange Webサイトでは、CAPTCHAが表示されないという十分な評判があり、新しいユーザーでさえすべての投稿ではなく、場合によってはCAPTCHAしか表示しません。

    一般に、CAPTCHAを何度も入力するように求めないでください。ユーザーが5分前に人間であることがわかった場合、これがまだ人間である可能性があります。

  • 技術力を使ってボットを見つけましょう。人間はページを開くことができません。0.1秒で長いメッセージを入力してください。送信します。ユーザーが非常に速い場合は、その投稿を破棄し、ゆっくりと時間をかけて、数秒後にもう一度投稿するように依頼します。

  • あなたのコミュニティを使用してください。 Stack Exchangeサイトの威力は、人間として来て、広告などを投稿できることです。最も頻繁にアクセスするサイトでは、モデレーターが削除するよりも、十分な評判のあるユーザーが質問にすぐにフラグを付けて終了します。

    Webサイトで、新しいユーザーからの新しいメッセージに3人の古いユーザーがフラグを付けている場合は、自分でさらに確認するまで非表示にします。 1人のユーザーがWebサイトに1万件を超えるコメントを投稿したというフラグが立てられている場合は、他の2つのフラグを待たずに、このメッセージを直接非表示にします。

覚えておいてください:CAPTCHA(またはそれほど邪魔にならないCAPTCHA)がなく、スパムがない(Stack Exchangeは完璧な例です)のWebサイトはたくさんあります。彼らがそれを行うことができれば、あなたはできる。

7

あらゆるサイトのCAPTCHAの実装を検討してください...

  • ログインしていてトラフィックが多い、またはトラフィックが多いと予想されるサイトにアクセスする人が多いほど、誰かがサイトをめちゃくちゃにしたくなる可能性が高くなります。
  • 大量のWebサーバーの処理能力またはリソースを必要とするWeb操作の場合。これらの呼び出しを繰り返し行うボットは問題になる可能性があります
  • お金を含みます。
  • 評判システムを含む。お金ではありませんが、一部のユーザーが特定のサイトに費やす時間を考えると、近いです。
  • それを利用する既知の理由があるグループに到達します。サイトがホットなトピックを中心に展開している場合、そこを通過するトラフィックの量は問題ではない可能性があります。人々はあなたのサイトのようなサイトを積極的に探し求めているかもしれません。

サイトにCAPTCHAが必要であると判断した場合、ここではまだ言及していない使用方法の提案をいくつか示します。

  • アカウント作成中。
  • X回のログイン試行が失敗した後のログイン中。
  • 前回のログインが失敗した場合は、CAPTCHAのみが正しくない場合にユーザーが情報を再入力する必要がないようにします。
  • サーバーに大きな負荷をかける操作の前。
1
kraftydevil

「いつそれがいいアイデアか」-UXの観点からは決して。 「それにもかかわらず、いつ使用するのが有効なのか」-ボットではなく、人間がデータを入力することの重要性によって、重要なUXダウサイドが正当化される場合。

あなたの質問は実際には間違っています。問題は、CAPTCHAをいつ使用すべきかということではなく、問題は、このサイトの重要な問題は何かということです。優れたUXであれば、ユーザーやデータの正当性であれば、CAPTCHAは1つの選択肢ですが、ソリューションと問題の性質によっては他にも選択肢があります。 1つの特定のソリューションに焦点を合わせるのは間違ったアプローチです。CAPTCHAに期待することをユーザーに尋ねるユーザーに対応する方がよいでしょう。そして、彼らが実際に抱えている問題ではなく、実際に抱えている問題を解決します。

1

ユーザーエクスペリエンスの観点から見ると、ひどく歪んだテキストキャプチャよりも人間に優しいCAPTCHAへのアプローチがあります。ユーザーが特定の写真をクリックする必要がある場所や、2つのオブジェクトがどのオブジェクトに属しているかを特定する必要がある小さなゲームを解決する場所などを目にしました。これらの種類のキャプチャは、ユーザーエクスペリエンスの向上に役立つと思います。

1
weowe

ユーザーがアクセスするすべてのサイトのリストを作成し、CAPTCHAの入力を楽しんでください。

数分差し上げます。

できた?

あなたのリストにはアイテムが無いと思います。

そう、純粋なUXの観点からは、ユーザーにCAPTCHASを処理させることは常に悪い考えです。

他のテクノロジーや管理者を介して自動投稿を制御できないために必要な場合があり、その場合、それは必要な悪として受け入れられます。

0
DA01

簡単にさせてください。ある時点で、誰か/何かが関係のないデータ(コメント、偽のユーザーアカウント、破損したファイルなど)でスパム/フラッディングを試みると思われる場合は、CAPTCHAを実装する必要があります。

私にとっては、遅かれ早かれ「攻撃」を受けることがわかっているアプリを作成しています。そのため、サインアップページにキャプチャシステムを追加するだけで、リスクを軽減できます。

0
w0rldart

絶対に!

なぜ、その人が本当に本人であることをコンピュータに確認する必要があるのですか。はい、CAPTCHAが必要とされる技術的な理由は完全にわかりますが、それらは悪いUXです。

Googleアナリティクスチームのこの動画を見て、キャプチャと人のやり取りを確認してください(1:02マークにあります)。

Googleアナリティクスインリアルライフ-オンラインチェックアウト

0