Интересный подход, но сломают при направленной атаке очень быстро. Практически все варианты искажений очень хорошо выделяются при обработке простейшей маской выделения контура (за исключением, пожалуй, картинки с желтыми наклонными полосками - но там я и сам едва разглядел место, где надо кликнуть).
Проблема в том, что такая CAPTCHA не зависит от специфических человеческих знаний - для того, чтобы её разгадать, не надо знать, что такое "машина" или "калькулятор", а всего лишь углядеть область на картинке, отличающуюся по структуре. Это очень легко автоматизировать.
Очень, очень нехороший подход. Ликвидация последствий ошибкок пользователей, вызванных этими самыми "сучками", может выливаться во вполне конкретные деньги.
Я в свое время прошел через ту же ситуацию - десяток мегабайт г*внокода на FoxPro 2.6 со свалкой DBF-файлов общего объема гигабайт под 50 (правда у меня хватило самоконтроля не бросаться это переписывать с нуля) + порядка сотни разбросанных по области неквалифицированных пользователей в ~50 организациях с огромной текучкой кадров. Обстановку совершенно не улучшали постоянные кофликты из-за ошибок пользователей, за которые на организации накладывали штрафы / денежные вычеты. Так вот, после пары месяцев работы над интерфейсом (информационные сообщения, более адекватный порядок обхода полей, горячие клавиши и тому подобное) количество записей, содержащих ошибки, сократилось на два порядка: с нескольких десятков тысяч до нескольких сотен (из ~200 тысяч ежемесячно).
Важно отметить, что до начала правок интерфейса пользователи уже работали с программой в течение примерно полугода, так что уменьшение количества ошибок "привыканием" к программе объяснить трудно.
У меня, честно говоря, слова "ревизия" и "разница ревизий" сассоциировались с контролем версий / diff. Только теперь понял, что вы предложили то же самое...
Как вариант, можно было бы хранить на клиенте "watermark" - например, время или идентификатор последнего отображенного сообщения. При после - возвращать только более новые комментарии со ссылками на родительские; распихивать по дереву клиентскими скриптами.
Фактически на сервер на страничке ничего не отправляется, так что смысла большого в этом примере нет. Если бы данные отправлялись, то после анализа кода можно было бы легко - порядка часа работы - вычленить саму функцию отправки и сделать специализированного бота. От "типовых" ботов такой подход может и помочь (как и масса других, более простых для конечного пользователя), от целенаправленной атаки - нет.
Я имел в виду - разве не дадут ту же функциональность с точки зрения пользователя?
Просто в заметке комбинация "оффлайновый софт + онлайновый сервис" рассматривается как что-то кардинально новое.
Проблема в том, что такая CAPTCHA не зависит от специфических человеческих знаний - для того, чтобы её разгадать, не надо знать, что такое "машина" или "калькулятор", а всего лишь углядеть область на картинке, отличающуюся по структуре. Это очень легко автоматизировать.
Я в свое время прошел через ту же ситуацию - десяток мегабайт г*внокода на FoxPro 2.6 со свалкой DBF-файлов общего объема гигабайт под 50 (правда у меня хватило самоконтроля не бросаться это переписывать с нуля) + порядка сотни разбросанных по области неквалифицированных пользователей в ~50 организациях с огромной текучкой кадров. Обстановку совершенно не улучшали постоянные кофликты из-за ошибок пользователей, за которые на организации накладывали штрафы / денежные вычеты. Так вот, после пары месяцев работы над интерфейсом (информационные сообщения, более адекватный порядок обхода полей, горячие клавиши и тому подобное) количество записей, содержащих ошибки, сократилось на два порядка: с нескольких десятков тысяч до нескольких сотен (из ~200 тысяч ежемесячно).
Важно отметить, что до начала правок интерфейса пользователи уже работали с программой в течение примерно полугода, так что уменьшение количества ошибок "привыканием" к программе объяснить трудно.
Просто в заметке комбинация "оффлайновый софт + онлайновый сервис" рассматривается как что-то кардинально новое.