Интересно, чем это всё закончится.
Плохо то, что судья и обвиняющие немного далеки от понимания интернет-технологий. И те, кто это начал, успешно пользуются ситуацией.
При добавлении дампа в кодировке utf-8 и последующей попытке его редактировать и сохранить вылезает тот же отчёт.
При аплоаде дампа, даже в кодировке utf-8 и дальнейшем редактировании и сохранении вылезает отчёт.
Отметьте в качестве плюса для Psi возможность шифрования переписки с помощью PGP. Это особенно актуально после того, как мы узнали, что аол может не просто читать, но даже «уполномочена» публиковать нашу переписку.
Как устроены обычные капчи: формируется рисунок с некими надписями, надпись на рисунке сохраняется в бд или в сессии.
Когда капчеры распознают капчу они отправляют правильный ответ, затем происходит сопоставление этого ответа допустим crc-сумме этого рисунка. Вот вам и база распознанных капч.
Количество возможных капч грубо говоря равно: длина_надписи! * число_различных_символов!.. И пусть меня простит препод за тройку по теории вероятностей)
В случае капчи с лабиринтом, юзеру нужно продвинуть квадрат в точку А.
Точка может быть названа как угодно, пусть даже так: «Ssdv#$@». Количество точек может варьироваться. К каждой точке можно привязать случайное число на этапе отсылки юзеру этой капчи. Получается, что даже если для первого юзера некий вариант капчи будет верным, то благодаря тому, что правильному варианту соответствовало случайное число, — для другого юзера решение для этой капчи будет уже неверным.
Взглянем как это будет выглядеть с точки зрения робота, который использует уже наработанную базу капчей. Что он имеет в первом случае? CRC-сумму рисунка и соответствующую строку. На основе этих данных робот может послать post-запрос.
Что робот имеет во втором случае? CRC-сумму флэшки? И что он с этим будет делать? Ему нужно послать запрос, содержащий верный ответ, но ответ не привязан постоянно к конкретному состоянию на этой капче.
Итак беспредел творится. Так еще цензуру в Сети введут.
Ненавижу диктат и тотальный контроль в любых формах.
Ну и урод.
Плохо то, что судья и обвиняющие немного далеки от понимания интернет-технологий. И те, кто это начал, успешно пользуются ситуацией.
floomby.ru/content/Xg2GLHtEdE/
data0.floomby.ru/files/share/27_3_2009/pnNRCC4ziEW3ULVQH2K6sQ.jpg
При добавлении дампа в кодировке utf-8 и последующей попытке его редактировать и сохранить вылезает тот же отчёт.
При аплоаде дампа, даже в кодировке utf-8 и дальнейшем редактировании и сохранении вылезает отчёт.
А так, вобщем-то мне понравилос :-)
Спасибо!
А отсутствие многопоточности чем-то даже хорошо. Меньше соединений будет.
Хотя в принципе, актуально всегда :-)
И бот в обломе
Когда капчеры распознают капчу они отправляют правильный ответ, затем происходит сопоставление этого ответа допустим crc-сумме этого рисунка. Вот вам и база распознанных капч.
Количество возможных капч грубо говоря равно: длина_надписи! * число_различных_символов!.. И пусть меня простит препод за тройку по теории вероятностей)
В случае капчи с лабиринтом, юзеру нужно продвинуть квадрат в точку А.
Точка может быть названа как угодно, пусть даже так: «Ssdv#$@». Количество точек может варьироваться. К каждой точке можно привязать случайное число на этапе отсылки юзеру этой капчи. Получается, что даже если для первого юзера некий вариант капчи будет верным, то благодаря тому, что правильному варианту соответствовало случайное число, — для другого юзера решение для этой капчи будет уже неверным.
Взглянем как это будет выглядеть с точки зрения робота, который использует уже наработанную базу капчей. Что он имеет в первом случае? CRC-сумму рисунка и соответствующую строку. На основе этих данных робот может послать post-запрос.
Что робот имеет во втором случае? CRC-сумму флэшки? И что он с этим будет делать? Ему нужно послать запрос, содержащий верный ответ, но ответ не привязан постоянно к конкретному состоянию на этой капче.