На одном подконтрольном мне сайте появилась подозрительная приписка. Прямо на главной странице. Некий код на JavaScript, зашифрованный по самые фигурные скобки. Ну, думаю, бывает. Почистил, успокоился. Через часок решил проверить - как оно там? А «оно» снова на месте! Вот ведь упорная зараза, и где только сидит? Удалил, призадумался. Копию сохранил на себе диск, проверил антивирусом. Trojan-clicker.js.agent.h. Описания в Интернете не водится. Что ж, будем использовать народную медицину.

Что нам известно? Другими файлами эта зараза побрезговала. А это, если подумать, существенно упрощает дело. Достаточно сделать копию файла index.php под названием, допустим, ya_ne_ya_i_script_ne_moi.php. И применим старую добрую мантру mod_rewrite в .htaccess: RewriteRule index.php ya_ne_ya_i_script_ne_moi.php. Вуаля! Осталось подождать час...

Спустя час эта гадость снова вписалась в index.php. А выдаваемый сервером вместо него ya_ne_ya_i_script_ne_moi.php остался цел и невредим. В общем, все довольны: вирус думает, что он сделал, что хотел, а посетители больше не рискуют получить от сайта какую-то гадость.

 

Вспомнил забавный случай. При разработке «Весны-2006» оказалось, что получить программным путем уровень громкости от WinAMP штатными средствами невозможно. То есть совсем. А мне необходимо было ползунок громкости в плагине синхронизировать с громкостью самого плеера. Перерыл весь SDK к WinAMP, думал упустил где-то. Нет, действительно - никак. Остальное - что угодно: получить имя проигрываемого файла, его длительность, нажата ли кнопочка shuffle или repeat, нажать любую кнопку WinAMP'а... А получить, какая у него сейчас громкость - ни в какую. Пол-инета перерыл, пока нашел недокументированный способ:

Volume:=-666;
SoundVolume:=SendMessage(HWNDWinamp, WM_USER, Volume, IPC_SETVOLUME);

То есть сначала программно выставить громкость в -666 (естественно, она не выставится), а в «ответ» получить реальную громкость. Причем я специально проверял: с другими значениями Volume такого эффекта нет.
Вот это надо было так приколоться, а? Шутники...

 

Напряженные рабочие будни накладывают отпечаток на мои записи. Сегодня снова расскажу о своем самосовершенствании в программировании. Кому знакома абревиатура «PHP»? Буду с вами делиться опытом. Чисто случайно узнал о функции ImageCopyResampled. Знающие - не морщите нос, бывает и такое. Всю жизнь пользоваться хрестоматийным ImageCopyResized для создания «ноготков» картинок, удивляться плохому качеству и узнать, что оказывается, есть менее используемая, но более качественная функция - это как глоток холодного пива в жару! Вкусно до дрожи в коленках. Для сравнения привожу пример:

Исходное изображение
ImageCopyResized 14 647 байт	ImageCopyResampled 11 804 байт

Результат, что говорится, налицо. Более чистое и компактное в плане занимаемого места на диске изображение.

 

Недавно я написал о том, как красиво вставлять в комментарии и записи играющую в WinAMP музыку. Там про картинку с дрыгающейся колонкой было. С сегодняшнего дня это неправда. В смысле, вставлять по-прежнему можно, и это будет красиво. Но есть одно «но»: теперь сайтом случайно выдается то изображение колонок, то изображение наушничков. В принципе, с потребительской точки зрения это все. Могу только сказать, что ассортимент «иконок» будет пополняться, можете предлагать свои варианты, я еще буду писать об этом. Тем же, кто охоч до забавных технологий - расскажу, как это реализовано.

Во-первых, с помощью mod_rewrite в .htaccess перенаправляем запрос с np.gif на np.php: «RewriteRule np.gif np.php»

Во-вторых, в np.php происходит следующее:

PHP:

$a=mt_rand(1,2);
$f=file_get_contents("np".$a.".gif");
header("Content-type: image/gif");
header("Content-Transfer-Encoding: binary");
header("Content-Length: ".strlen($f));
header("Content-Disposition: inline; filename=\"np.gif\"");
header("Expires: 0");
header("Cache-Control: no-cache, must-revalidate");
header("Pragma: no-cache");
echo $f;

Вот и весь фокус.

 

Все помнят бородатый анекдот?

Два англичанина в поезде. Поезд проезжает мимо пасущегося стада коров. Один англичанин говорит:
- Интересно, сколько здесь пасется коров?
- Пятьдесят восемь голов.
- Как вы догадались?
- Очень просто - сосчитал количество ног и разделил на четыре...

Так вот, смотрите что пришло мне в голову: несмотря на такой, казалось бы, нерациональный подход, этот алгоритм обладает повышенной отказоустойчивостью. То есть: считая коров по головам, есть вероятность ошибиться, и полученную цифру можно перепроверить только повторным пересчетом. Считая по ногам и получая число, не кратное 4 (предполагается, что среди коров инвалидов нет), мы можем сразу сказать, что допущена ошибка.

Так что посмеявшись над анекдотом, можно попробовать извлечь из него какую-нибудь идею. В каждой шутке есть доля шутки...

 

Статья была написана для HostInfo.ru.

Думаю, мало кто поспорит, что блоги (в частности, сервис LiveJournal) стабильно обосновались в нашей жизни как (как минимум) довольно удобный способ узнать, что нового происходит в жизни друзей и знакомых. Еще интересно бывает следить за блогами незнакомых, но пишущих интересные статьи людей. Не стоит забывать и сообщества, коих великое множество. Таким образом, довольно приличное количество людей начинают свой день (или, напротив, завершают его) просмотром так называемой «френдленты», в которой к одной колонке сводятся все записи из интересующих журналов. Некоторые даже специально заводят аккаунты, которыми пользуются исключительно для того, чтобы одной страницей читать все новости. И нет-нет да и проскакивает мысль: «А как удобно было бы читать вот тот вот сайт в этой же френдленте». Действительно, есть огромное количество сайтов-блогов, ведущихся по тому же принципу, что и на LiveJournal, но на собственном хостинге. Если у вас подобный блог, почему не сделать синхронизацию, чтобы при изменениях на сайте автоматически изменялось его «зеркало» в LiveJournal?

В принципе, например, если ваш блог построен на CMS WordPress, то можно взять готовый плагин, синхронизирующий записи с сайта с аккаунтом в LiveJournal. Но это типовое решение, и в данной статье мы рассмотрим процесс чуть глубже, на уровне интерфейсов LiveJournal.

Будем считать, что процесс добавления новостей на свой собственный сайт вы наладили, и сосредоточимся на дублировании этих записей непосредственно в «Живой журнал». Собственно, для добавления записи у нас масса возможностей: через SMS, через Jabber, электронную почту. Однако нас интересуют два более гибких интерфейса: Flat- и XML-RPC-протоколы.

Flat Client/Server Protocol Flat Client/Server Protocol представляет собой обработку обычных POST-запросов. Например, страница, содержащая такую форму, может быть использована для добавления сообщений в любой дневник:

<form accept-charset="UTF-8" method="post" name="postform" action="http://www.livejournal.com/interface/flat"> <input type=hidden name=mode value="postevent"> <input type=hidden name=user value="username"> <input type=hidden name=password value="password"> <input type=hidden name=auth_method value="clear"> <input type=text name=year value="2007"> <input type=text name=mon value="05"> <input type=text name=day value="31"> <input type=text name=hour value="17"> <input type=text name=min value="0"> <input type=text name=subject value="тема"><br /><br /> <textarea name=event>сообщение</textarea><br /><br /> <input type=button value="Ok" onclick="postform.submit()"><br /> </form><br />

Естественно, в поля user и password вписываются логин и пароль журнала, в который, собственно, мы хотим добавить запись. В ответ на эту форму сервер (если данные учетной записи верны) выдаст ответ подобного вида:

anum 192 itemid 7 success OK url http://user.livejournal.com/1984.html

Значение success, равное «OK», говорит о том, что сообщение успешно добавлено в журнал. В случае неудачи этот параметр будет равен FAIL. Параметр anum, судя по документации, предназначен для вычисления публичного itemid записи. На самом же деле я так и не встретил ситуации, когда бы этот параметр пригодился. Параметр itemid содержит номер записи в данном дневнике, и его можно, например, запомнить в базе – он может понадобиться для редактирования записи. Последний параметр – url – содержит прямую ссылку на запись.

Вуаля, треть нашей задачи мы осуществили: теперь при добавлении новости на сайт эта же новость без труда дублируется в «ЖЖ». Две оставшиеся трети проблемы решаются следующим образом:

<form accept-charset="UTF-8" method="post" name="postform" action="http://www.livejournal.com/interface/flat"> <input type=hidden name=mode value="editevent"> <input type=hidden name=itemid value="7"> <input type=hidden name=ver value="1"> <input type=hidden name=user value="username"> <input type=hidden name=password value="password"> <input type=hidden name=mode value="editevent"> <input type=hidden name=auth_method value="clear"> <input type=text name=year value="2007"> <input type=text name=mon value="05"> <input type=text name=day value="31"> <input type=text name=hour value="17"> <input type=text name=min value="0"> <input type=text name=subject value="тема"><br /><br /> <textarea name=event>сообщение</textarea><br /><br /> <input type=button value="Ok" onclick="postform.submit()"> </form>

Эта форма отличается от первой рассмотренной только второй и третьей строками. Параметр mode мы установили равным editevent и ввели параметр itemid, который содержит номер редактируемой записи в LiveJournal. Причем если поле event будет пустым, сообщение будет стерто.

XML-RPC Interface
Но Flat-интерфейс все-таки не очень удобен. Более гибким и мощным инструментом является XML-RPC-интерфейс. Для реализации работы с этим интерфейсом на PHP я выбрал библиотеку XML-RPC for PHP. Вот пример функции для добавления сообщения в журнал:

function post_LJ($year,$month,$day,$hour,$minute,$subject,$event) { $lj_userid="user"; $lj_passwd="password"; $client=new xmlrpc_client("/interface/xmlrpc", "www.livejournal.com", 80); $params = new xmlrpcval( array( 'username' => new xmlrpcval($lj_userid,'string'), 'password' => new xmlrpcval($lj_passwd,'string'), 'ver' => new xmlrpcval('1','string'), 'lineendings' => new xmlrpcval('pc','string'), 'event' => new xmlrpcval($event,'string'), 'subject' => new xmlrpcval($subject,'string'), 'year' => new xmlrpcval($year,'int'), 'mon' => new xmlrpcval($month,'int'), 'day' => new xmlrpcval($day,'int'), 'hour' => new xmlrpcval($hour,'int'), 'min' => new xmlrpcval($minute,'int')),'struct' ); $msg = new xmlrpcmsg('LJ.XMLRPC.postevent'); $msg->addparam($params); $client->setDebug(0); $result = $client->send($msg); if ($result->faultCode() != 0) { print "Ошибка: " . $result->faultString(); } else { printf("Сообщение добавлено"); }; };

Если рассматривать процедуру вкратце, то мы сначала формируем XML-запрос, а затем отсылаем его серверу на обработку. В ответ мы получаем тоже XML-файл, но уже с результатами. Мы можем получить и распечатать любую запись из дневника:

function view_LJ($itemid) { $lj_userid="user"; $lj_passwd="password"; $client=new xmlrpc_client("/interface/xmlrpc", "www.livejournal.com", 80); $params = new xmlrpcval( array( 'username' => new xmlrpcval($lj_userid,'string'), 'password' => new xmlrpcval($lj_passwd,'string'), 'ver' => new xmlrpcval('1','string'), 'lineendings' => new xmlrpcval('pc','string'), 'selecttype' => new xmlrpcval('one','string'), 'itemid' => new xmlrpcval('itemid','string'), 'year' => new xmlrpcval($year,'int'), 'month' => new xmlrpcval($month,'int'), 'day' => new xmlrpcval($day,'int')),'struct' ); $msg = new xmlrpcmsg('LJ.XMLRPC.getevents'); $msg->addparam($params); $client->setDebug(0); $result = $client->send($msg); if ($result->faultCode() != 0) { print "Ошибка: ".$result->faultString(); return; }; $v=$result->value(); $events=$v->structMem('events'); $event = $events->arrayMem(0); $itemid_xml=$event->structMem('itemid'); $eventtime_xml=$event->structMem('eventtime'); $subject_xml=$event->structMem('subject'); $event_xml=$event->structMem('event'); $itemid=$itemid_xml->scalarVal(); $subject=$subject_xml->scalarVal(); $eventtime=$eventtime_xml->scalarVal(); $event=$event_xml->scalarVal(); printf("$eventtime<br /><br />"); printf("$subject<br /><br />"); printf("$event<br />"); };

То есть при большом желании можно не хранить записи на сайте, а получать их в момент формирования страницы со своего «ЖЖ»-аккаунта.

Редактирование и удаление записей производится по аналогии с примером, приведенном для Flat-интерфейса:

function post_LJ($itemid,$year,$month,$day,$hour,$minute,$title,$message) { $lj_userid="user"; $lj_passwd="password"; $client=new xmlrpc_client("/interface/xmlrpc", "www.livejournal.com", 80); $params = new xmlrpcval( array( 'username' => new xmlrpcval($lj_userid,'string'), 'password' => new xmlrpcval($lj_passwd,'string'), 'ver' => new xmlrpcval('1','string'), 'itemid' => new xmlrpcval($itemid,'int'), 'event' => new xmlrpcval($message,'string'), 'lineendings' => new xmlrpcval('pc','string'), 'subject' => new xmlrpcval($title,'string'), 'year' => new xmlrpcval($year,'int'), 'mon' => new xmlrpcval($month,'int'), 'day' => new xmlrpcval($day,'int'), 'hour' => new xmlrpcval($hour,'int'), 'min' => new xmlrpcval($minute,'int')),'struct' ); $msg = new xmlrpcmsg('LJ.XMLRPC.editevent'); $msg->addparam($params); $client->setDebug(0); $result = $client->send($msg); if ($result->faultCode() != 0) { print "Couldn't process request: ".$result->faultString(); return; }; };

Таким образом можно реализовывать довольно интересные комбинации. Например, вы можете вести дневник на LiveJournal и вкраплять в ленту записей новости своего сайта. Или, напротив, разбавлять новости на главной странице записями из своего «ЖЖ». Также можно не ограничиваться одним аккаунтом, а, допустим, если у вас музыкальная группа, то на странице сайта можно собрать до кучи записи из «ЖЖ»-аккаунтов всех участников. В общем, возможности ограничиваются исключительно вашей фантазией и производительностью сервера.


28 июня 2007

Опубликовано на HostInfo.ru 29 июня 2007.

 

Статья была написана для HostInfo.ru.

Часто ли вам приходится сталкиваться с работой CAPTCHA-систем? Это такие системы скриптов, задающие загадки и генерирующие трудночитаемые картинки с цифрами, буквами и прочим безобразием, и сверяющие потом то, что вы ввели, с эталоном. В частности, таким образом сайты обороняются от автоматизированной рассылки рекламы по форумам и гостевым, отделяя добропорядочных пользователей от спам-программ. Считается, что автоматический тест Тьюринга крайне осложняет жизнь спам-программам, поэтому CAPTCHA сейчас используется довольно широко, заставляя вглядываться в напрочь зашумленные надписи, гадая, что на этот раз имеется в виду - единичка или латинская строчная «эл».

Но на всякий хитрый «картинкогенератор» рано или поздно находится своя управа, и правильный ответ найдется: либо перебором, либо разбором механизма генерации картинок, либо еще через какое-нибудь «заднее крыльцо». И преграда для автоспамеров становится лишь раздражением для посетителя ресурса. Ухватываете суть проблемы? В погоне за спамоустойчивостью удобство пользователя как-то само собой отошло на второй план. Лично мне не особо по душе лозунг «это для вашей же безопасности», поэтому сегодня я поделюсь с вами устройством более дружелюбного для пользователя механизма.

Для начала давайте немного поразмышляем: в чем отличие программы от настоящего, живого человека?

Проследим поведение обычного пользователя. Человек открывает страницу с формой для добавления какой-либо записи(в гостевой, на форуме и так далее), видит поля (для простоты возьмем самые распространенные) «Имя», «E-mail», «Сообщение». Он вводит в эти поля информацию и нажимает кнопку «Отправить». И все, сообщение появляется там, где пользователь и планировал его добавление(в гостевой, на форуме и так далее).

Что делает спам-программа? Она загружает страницу, определяет, какие механизмы защиты использованы, и делает свое черное дело. Главное отличие программы от человека в том, что она воспринимает страницы как последовательность букв, слов, строк - среди слов она по заранее заданному алгоритму может найти ссылку на заветное «добавить комментарий», пройти по ней и вписать пару фраз рекламы и ссылки в соответствующие поля, так же аккуратно найти на странице кнопку отсылки сообщения и эмулировать ее нажатие. Причем многие программы автоматически находят пригодные для «гнездования» сайты и добавляют их в свою базу - для повторной «кладки».

Итак, поскольку мы задались целью не проверять пользователя на распознавание цветов, цифр и навыки извлечения логарифмов, становится очевидно, что наша основная борьба развернется внутри кода страницы - который пользователю по большому счету глубоко безразличен, а для программы является основным материалом для работы.

Способов внутристраничной борьбы придумано немало, по большей части они уже все известны и помогают от совсем уж примитивных программ. Но в нашем деле лишними меры быть не могут, так что сначала вкратце пройдемся по «обязательному минимуму».

Ограничение по частоте сообщений.
Самый простой инструмент. Необходимо следить, чтобы с одного и того же IP не было по десятку сообщений в минуту - ясно, что вряд ли человек с такой частотой будет высказывать какие-то умные мысли. Этот прием, конечно, толком не избавляет от спама, но сокращает его поток. Главное тут - правильно подобрать интервал: и большой плохо, и короткий нехорошо. По собственному опыту минуты три - в самый раз.

Блокирование сообщений по ключевым словам.
Тоже довольно простой фильтр: не пропускаются до публикации сообщения, имеющие среди текста слова, которых точно не будет содержать «добропорядочный» текст. Заодно можно отфильтровывать не только рекламу, но и мат.

Замена символов «двойниками».
Случайная замена на странице букв на схожие по написанию символы (для человека все равно, а для разбора и поиска по шаблону - помеха). При этом в ссылках, ведущих на добавление комментариев или на регистрацию, буквы меняются на схожие по написанию, но имеющие другой код. Например, русские «а», «о», «р» на английские «a», «o» и «p» соответственно. Это немного усложняет поиск потенциальных сайтов-жертв.

Изменение имен полей ввода.
Многие программы ищут в странице поля ввода со стандартными именами: «name», «user», «nick», «email», «mail» и так далее. Чтобы доставить программе некоторое неудобство, лучше называть поля как-нибудь нестандартно. Например, «kndfjero».

Замена надписей картинками с текстом.
Если реализован предыдущий шаг, то есть шанс, что программа не сдастся, не найдя привычных имен полей, а попытается проанализировать находящиеся рядом надписи, пытаясь выяснить, к чему какое поле относится. Смена поясняющих надписей на картинки с текстом сильно усложняет эту задачу в плане решения на программном уровне, а уж пиктограммы и вовсе делают ее практически невыполнимой. Визуально, с точки зрения пользователя, на странице ничего не меняется: какая ему разница, как набран текст на сайте, картинкой или текстом? С другой стороны, достаточно спамеру-человеку один раз посетить такую страницу и «врукопашную» посмотреть что где - и все, программе уже задан шаблон для этой страницы, она «знает», куда что писать и куда нажимать для отправки.

Встраивание «полей-приманок».
Раз программа ищет поля «name», «message» и тому подобные, почему бы не «обрадовать» ее этими полями? Это сделать довольно просто, например так:

Имя: <input type=text name=name style="visibility: hidden; width: 1px;" value=""> <input type=text name=nlconpiqo value=""> E-mail: <input type=text name=email style="visibility: hidden; width: 1px;" value=""> <input type=text name=ummsklcqu value="">

При отображении такие поля не видны, а программа их находит и обрабатывает. От особенно «умных« программ «visibility: hidden» прячется в CSS:

<style type="text/css"> input.foul { visibility: hidden; width: 1px; height: 1px; } </style> ... Имя: <input type=text name=name class=foul value=""> <input type=text name=nlconpiqo value=""> E-mail: <input type=text name=email class=foul value=""> <input type=text name=ummsklcqu value="">

Построение формы с помощью JavaScript.
Этот метод делает анализ формы еще более сложным: программе необходимо найти и выполнить код JavaScript, чтобы получить форму, которую следует заполнить:

<div id=mform> Включите, пожалуйста, поддержку JavaScript в браузере </div> ... <script language=javascript> myform=document.getElementById("mform"); mystr="<form method=\"post\" name=\"som"; mystr=mystr+"eform\" action=\"somescript.php\">И"; mystr=mystr+"мя: <input type=text name=ni"; mystr=mystr+"ck value=\"\"><br>E-ma"; mystr=mystr+"il: <input type=text name=ema"; mystr=mystr+"il value=\"\"><br>Сообщение: <texta"; mystr=mystr+"rea cols=35 rows=8 name=ms"; mystr=mystr+"g></textarea><br><input type=bu"; mystr=mystr+"tton value=\"отправить\" onclick=\"somef"; mystr=mystr+"orm.submit()\"><br></form>"; myform.innerHTML=mystr; </script>

Наличие механизмов обучения и делает автоспамеров особенно «въедливыми»: один раз программе показали, как надо действовать при данной ситуации, она запомнила, и все - разгребай, хозяин, спам на форуме. Значит, надо сделать так, чтобы страница каждый раз была разной, верно?

Отлично, тогда переходим к следующим, более изощренным методам.

Генерирование случайных имен полей ввода.
Это просто усовершенствованный метод изменения имен полей ввода: имена изменяются не один раз (при написании скрипта), а при каждом вызове страницы. Тут есть одна тонкость: поскольку имена раздаются динамически, надо как-то известить получающий данные скрипт, какая переменная за что отвечает. Например, ввести дополнительное скрытое поле, в которое записать шифровку, в которой указать, какие поля обрабатываются:

<form method="post" name="jdfjvb" action="somescript.php"> Имя: <input type=text name=nlconpiqo value=""> E-mail: <input type=text name=ummsklcqu value=""> Сообщение: <textarea cols=35 rows=8 name=thtqnrnee></textarea> <input type=button value="отправить" onclick="jdfjvb.submit()"> <input type=hidden name=temp value="piqonlconbnhrshelcquummskrneethtqn"> </form>

В somescript.php происходит «разбор» переменной-шифровки temp с именами и выуживание из переданных данных нужной информации:

$war = decrypt_string($temp); $name = trim($_POST[$war[0]]); $email = trim($_POST[$war[1]]); $message = trim($_POST[$war[2]]);

Функция decrypt_string отвечает за расшифровку переданных данных и не ограничена ничем, кроме вашей фантазии. Алгоритм шифрования можно в любой момент изменить, например, если спамер просто использует единожды загруженную страницу для отправки повторных сообщений.

Генерирование принимающего скрипта.
Усложняем предыдущий случай: кроме случайных имен будем создавать на диске и принимающий скрипт:

<form method="post" name="jdfjvb" action="shebnhr.php"> Имя: <input type=text name=nlconpiqo value=""> E-mail: <input type=text name=ummsklcqu value=""> Сообщение: <textarea cols=35 rows=8 name=thtqnrnee></textarea> <input type=button value="отправить" onclick="jdfjvb.submit()"> <input type=hidden name=temp value="piqonlconbnhrshelcquummskrneethtqn"> </form>

На диске, соответственно, создается shebnhr.php - на этот раз введенные данные отправятся на обработку этому файлу. Таким образом, можно иногда менять поля «Имя», «E-mail» и «Сообщение» местами, (что нанесет ущерб удобству пользователя не в пример меньше, чем корявые буквы на рисунке, но окончательно собьет с толку программу), менять механизм шифрования «на лету» - ведь принимающая часть генерируется специально под данные имена полей, под данную форму. Переданная запись сохраняется в гостевой, а после принимающий скрипт стирает сам себя. Соответственно, использовать для отправки данных вторично невозможно чисто физически: файла, к которому обращались в первый раз, давно нет. Конечно, не знаю, насколько оправдано применение решения для сайта в 3000 уникальных посетителей и 600-700 сообщений в день, ибо получается нагрузка на жесткий диск из-за создания и стирания файлов.

Обработка по билетам.
Вместо формирования индивидуального принимающего скрипта для каждой попытки добавления комментария можно использовать своеобразные кодовые билеты: в форме среди прочих полей указывается скрытое поле с уникальным билетом, кодовой строкой, которая также внесена в базу билетов. После добавления комментария билет удаляется из базы, и повторная отправка данных не пройдет - билет уже отработал, его нет в базе.

Увы, против спамеров, вбивающих обявления вручную, противоядий вовсе нет (кроме, разве что, фильтрования сообщений по содержимому). С другой стороны, целью этой статьи не было выведение универсального оружия против спама. Целью было показать, что тест Тьюринга - не панацея, а иногда - только причина раздражения. И что в большинстве случаев можно запросто обойтись без него, не заставляя пользователя делать лишние операции. Достаточно только хотя бы немного изменить, придать индивидуальности файлам - из-за одного-единственного сайта переделывать ориентированную на типовые решения и распространенные CMS спам-программу никто не будет.


Опубликовано на HostInfo.ru.