FYI @codinghorror, команда Chrome по-прежнему ничего не сделала.
Ситуация с Chrome остаётся нерабочей. Мы можем легко исправить это, заменив наш ханипот для защиты от спама на механизм доказательства работы.
Закрываем ещё на 2 месяца.
Команда Chrome, похоже, очень хочет исправить это, но нужны логи здесь:
https://bugs.chromium.org/p/chromium/issues/detail?id=987293
Завтра я посмотрю, смогу ли собрать их. Если кто-то сделает это раньше меня, вы — мой герой, пометьте этот пост.
РЕДАКТИРОВАНИЕ … отправил им логи.
@codinghorror Это заходит в тупик в Google. Они утверждают, что такое поведение предусмотрено, и у них нет способа точно определить, виден ли textarea или нет.
Общий ответ здесь: «Боту тривиально обойти это, так в чём смысл». У меня нет конкретного ответа, я скорее согласен с ними: ловушка-хонепот выглядит довольно глупо, и я легко могу заменить её чем-то другим, чтобы убедиться, что при регистрации учётной записи пользователь хотя бы выполняет JavaScript.
Я уже потратил на это столько времени, и чувствую, что борюсь с ветряными мельницами. Мне просто хочется внедрить исправление и двигаться дальше.
Хорошо, но я хочу, чтобы это была довольно сложная проверка работы. Есть ли готовый код, который мы можем использовать?
Да, я смогу что-то собрать, это определённо будет лучше нашей текущей системы. Наша текущая система «proof of work» — это «развернуть строку».
Я потратил слишком много времени на размышления об этой проблеме, поэтому решил, что пора поставить точку:
Согласно этому коммиту, автор темы здесь «исправлен»:
Исправление довольно сложное и состояло из двух частей, которые я с радостью реализовал.
-
Я значительно ужесточил логику для honeypot (ловушки) и challenge (задачи).
-
Я добавил обходное решение только на стороне клиента для ошибки Chrome в автозаполнении. Я доволен этим, так как это никак не меняет протокол на стороне сервера.
Ранее мы использовали одну и ту же случайную строку для honeypot и challenge при всех регистрациях аккаунтов на сайте. Это делало создание скриптов для регистрации аккаунтов тривиальным, так как достаточно было один раз зафиксировать значение.
Новая реализация предоставляет каждому пользователю уникальную строку для проверки, привязанную к хранилищу куки (в нашем защищённом хранилище сессий). Эта строка истекает через час.
Это означает, что при автоматизации таких действий вы вынуждены регулярно делать запросы для получения новых задач и honeypot между запросами, и просто массово создавать аккаунты уже не получится.
Обходное решение в пункте 2 заключается в том, чтобы убрать INPUT, который сбивает Chrome с толку, и заменить его на INPUT типа text, который не вызывает путаницы.
В целом, я не считаю, что пункт (2) облегчает работу «общего» бота, зарегистрированного на неизвестных сайтах. Для начала боту потребуется использовать Chrome WebDriver, проанализировать весь наш Ember и следовать очень специфичному сценарию. Этот барьер очень низок и ничтожен по сравнению с новыми ротационными задачами для каждого пользователя.
Что касается добавления доказательства работы (proof of work), я хотел бы немного подождать. Не потому, что это сложно реализовать, а скорее потому, что не хочу заниматься поиском самого быстрого алгоритма SHA1, чтобы затем отправлять его клиенту по требованию.
Оставлю эту тему открытой ещё некоторое время, чтобы люди могли подтвердить, что моё исправление решает проблему. Закрою её через неделю.