参考までに、@codinghorror さん、Chrome チームは依然として何もしませんでした。
Chrome での状況は未だに壊れたままです。スパム保護用のホニープットを何らかのプルーフ・オブ・ワークに置き換えることで、簡単に修正できます。
2 ヶ月間クローズします。
Chrome チームはこれを修正することに熱心なようですが、以下のログが必要です:
https://bugs.chromium.org/p/chromium/issues/detail?id=987293
明日、私が収集できるか確認します。もし私より先に収集される方がいれば、あなたは私のヒーローです。この投稿にフラグを立ててください。
編集… ログを送信しました。
@codinghorror Googleではこの問題が堂々巡りになっています。彼らはこの動作は設計意図によるものであり、textareaが可視かどうかを正確に検出する方法がないと言っています。
一般的な反応は「ボットがこれを回避するのは容易だから、意味があるのか」というものです。私も特に反論できません。むしろ彼らの意見に同意します。ハニーポットは少しばかげており、ユーザーがアカウント登録時に少なくともJavaScriptを実行していることを確認するために、簡単に別の方法に置き換えることができます。
私はこれですでに多くの時間を費やしてしまい、風車に挑むような気分です。ただ修正を適用して、この件を終わらせたいと思っています。
いいえ、でも複雑なプルーフ・オブ・ワークにしたいです。既存のコードを流用することはできますか？
はい、何か作成できます。現在のシステムより確実に良くなるでしょう。現在の「プルーフ・オブ・ワーク（proof of work）」システムは「文字列を逆転させる」というものです。
この問題について考えすぎて時間を浪費してしまったので、もう決着をつけることにしました。
このコミットにより、元の投稿者（OP）の問題は「解決」されました。
この修正は少々複雑で、私が嬉しく思える 2 つの部分を含んでいます。
-
ハニープットとチャレンジのロジックを大幅に強化しました。
-
Chrome の自動入力に関するバグに対するクライアントサイド限定の回避策を追加しました。サーバー側のプロトコルを変更しないため、これで問題ないと確信しています。
以前は、サイト内のすべてのアカウント登録で同じハニープットとチャレンジのランダム文字列を再利用していました。そのため、値を一度ハードコードするだけで、アカウント作成のスクリプト化が極めて容易でした。
新しい実装では、各ユーザーに固有の文字列を割り当て、それをクッキーストア（当社の安全なセッションストアに紐付け）で検証するようにしました。この文字列は 1 時間後に期限切れになります。
つまり、スクリプトでこの処理を行う場合、リクエスト間で常に新しいチャレンジやハニープットを取得する呼び出しを定期的に行う必要があり、アカウントをただ押し通すことはできなくなります。
2 の回避策は、Chrome が混乱している INPUT をシャッフルして、混乱しない type="text" の INPUT に置き換えるだけです。
全体として、(2) は「汎用的」に記述されたボットが未知のサイトでアカウントを登録することを容易にするものではないと考えています。まず、ボットは Chrome Web Driver を使用し、すべての Ember コードを解析し、非常に特定のフローに従う必要があります。この障壁は非常に低く、新しいユーザーごとのローテートするチャレンジに比べれば取るに足らないものです。
プルーフ・オブ・ワークの追加については、少し待ってから行いたいと思います。構築が特に難しいからではなく、最速の SHA1 アルゴリズムを探して、それをクライアントにオンデマンドで送信したくないからです。
この問題は、人々が私の修正が問題を解決していることを確認できるよう、しばらくオープンにしておきます。1 週間後にクローズします。