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

Достаточно любопытный факт: менеджеры Google реально очень скучные. И им правда нравится выглядеть именно так (по крайней мере пока их PR-коллеги находятся рядом). Они не разговаривают о конкурентах. Они не делают прогнозов о развитии индустрии. И они не говорят конкретно кто над чем работает внутри Google. Просто-напросто они фокусируются на совершенствовании своих продуктов, особенно в направлении удобства использования пользователями, разве этого не достаточно?

Возможно Jack Menzel, старший продукт-менеджер, лучше всего это выразил, когда пошутил о «неблагодарности» работы над веб-поиском в Google: «Вы демонстрируете [новую функцию поиска] людям, а они говорят: ‘Да, вроде она работает, ну и что?’» (Как быстро все мы забываем, каково это было искать информацию в Интернете всего несколько лет назад.) Что ж, без дальнейших предисловий, перейдем к основным моментам, связанным с различными аспектами работы Google.

По мотивам статьи на xconomy.com, автор Gregory T. Huang.

Поиск в реальном времени

Google активно работает над максимально оперативным обновлением результатов поиска по сети Интернет, в том числе и по социальным медиа вроде Twitter или Facebook, практически так же быстро, как такая информация и публикуется.

Menzel, бывший сотрудник Microsoft, который изучал компьютерное ремесло в University of Washington, возглавляет продуктовую группу на данном фронте. Он говорит, что компания Google работала над ускорением процесса индексации и ранжирования на протяжении уже многих лет: когда-то данные обновлялись раз в месяц, потом обновление стало ежедневным, чтобы поспевать за блогами и новостными сайтами. В течении прошлого года Twitter стал популярен и, как следствие, появилась достаточно критичная потребность в обновлении информации за считанные секунды или в крайнем случае минуты. «Мы двигались по направлению к тому, чтобы становиться все быстрее и быстрее, на протяжении уже достаточно длительного периода времени», говорит Menzel. «Данная траектория развития была выбрана уже давно. Каждый шаг в данном направлении приводит к все новым и новым проблемам и трудностям. Мы верим, что именно получение доступа к свежей информации является одним из ключевых факторов, являющихся залогом успеха Google.» (В число остальных факторов, относящихся к самому поиску, входят такие показатели как релевантность, быстрота получения результата и полнота контента.)

Menzel считает, что самой сложной задачей является не просто быстродействие, а релевантность результатов потребностям пользователей (возможно, кто-то привык называть этот показатель словом «пертинентность»). «Это очень, очень непросто собирать свежий короткоживущий контент и ранжировать его рядом с, скажем, статьями из New York Times или просто постами из блогов.» Стоит заметить, что когда контент появился буквально только что, обычно на него еще практически никто не успел сослаться, а значит Google не может полноценно использовать PageRank, их классическую технологию.

Вместо этого, они «тяжело опираются на все то, что они выявили в течении последних 10 лет», говорит Menzel. Это включает в себя, например, способы отбрасывания контента, который скорее всего является иррелевантным или спамом, в более общем случае.  Помимо этого он упоминал «совершенно новые сигналы», скажем «новые языковые модели», которые позволяют понять какие обновления являются релевантыми, а какие — просто горстка никому не нужных данных от какого-нибудь ученого-океанографа, или методы определения насколько тот или иной создатель контента авторитетен в своей области.

Говоря о будущем, Menzel повторил то, что казалось бы на сегодняшний день говорят все о поиске: еще рано. «На самом деле мы лишь начали работать над данной задачей и у нас все еще очень долгий путь впереди». Он надеется, что в течении 5 лет Google сделает поиск намного более персонализированным, чем он есть сегодня. Например, Google будет знать что ты увлекаешься футболом, но привык называть его не «soccer», а «football», то есть помимо прочего поисковая система должна понимать кем является каждый ее конкретный пользователь, как и с кем он связан, кем он является в реальной жизни, где находится, и, тем самым, помогать ему организовывать всю информацию вокруг него.

«Поиск — все еще очень далекая от решения проблема,» — говорит Menzel.  »Существует еще масса вещей, которые очень не просто найти в Интернете.»

Локальный поиск

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

Carter Maslan, директор продуктового менеджмента в области локального поиска в Google, называет эту область «организацией мировой информации географически» , или созданием быстрого и простого гида по «гео-Интернету». Самым сложным моментом в данном вопросе по его мнению является отображение всех этих различных способов выражения пользовательского запроса на очень большой массив локализированных данных, а также возвращение правильного ответа на полученный запрос в минимальные сроки.

Maslan, еще один экс-сотрудник Microsoft, говорит, что Google обрабатывает большое количество поисковых запросов для анализа того, как люди предпочитают искать локальную информацию, и как с географической точки зрения создаются ссылки на различные вещи. По его мнению конечная цель заключается в том, чтобы сделать поиск и обнаружение мест рядом с собой практически не требующим от пользователя каких-либо усилий. Наиболее знакомые сценарии, это помощь в ориентировании в новом окружении, скажем после приземления в аэропорту, или поиск баров во время ночной прогулки по пригородам Нью-Йорка.

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

Maslan считает, что основной отличительной чертой Google в области локального поиска является «открытость для всех источников», что достаточно сложно с технической точки зрения. Это включает в себя пребывание в состоянии «активной глобальности», а не просто в индексировании информации о ключевых станциях метро. «Масштаб, с которым Google работает с картографическими и гео-кодированными данными, в совокупности с пониманием принципов работы Интернета является ключем для успешной работы в данной области».

Возможно в скором будущем мы увидим вещи вроде карт и списков компаний или мест от Google в еще большем количестве мест и языков по всему миру, с еще более точной информацией, чутко реагирующей на локальные события вроде открытия, закрытия или перемещения предприятий и организаций. «Мы четко понимаем, какие именно вещи у нас получаются лучше всего» — говорит Maslan. «У нас есть небольшие команды из людей, фанатично настроенных на реализацию их наиболее правильным образом».

Облачные вычисления

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

Ken Norton, старший продукт-менеджер Google (а также выпускник Boston University и бывший предприниматель), поведал о Google Apps и стратегии компании в области облачных вычислений. Команда Norton’а работает конкретно над Google Calendar, но Google Apps также включают в себя и другие продукты, такие как Gmail, Google Talk, Google Docs и Google Sites. “Сеть выигрывает на том, как приложения будут потребляться” — он сказал.

Ключевым преимуществом Google на данном фронте является масштаб и инфраструктура. «У нас есть настолько много серверов и датацентров по всему миру, что мы можем содержать их достаточно дешево и эффективно» — говорит Norton. Это преимущество оказывает влияние и на индивидуальные устройства, так как оно «открывает новые возможности» для потребителей, возможность использовать веб-приложения с любого типа устройств, будь то смартфон, нетбук или обычный полноразмерный ноутбук.

Работа Google в области облачных вычислений сфокусирована на двух уровнях: на первом располагаются готовые программные продукты вроде Google Apps, направленные на прямое потребление конечными пользователями (как индивидуальными, так и корпоративными); второй же уровень занимает App Engine, «облачная» платформа, предназначенная для использования разработчиками программного обеспечения для эффективного построения их собственных веб-продуктов.

Относительно прогнозов на следующий год на фронте облачных вычислений, Norton сказал, что «мы постоянно совершенствуемся». В 2009 году было запущенно более 100 основных новых функциональных возможностей в Google Apps — таких вещей, как видео чат в GTalk или Gmail offline. Он считает, что Google «продолжит делать акцент на коммуникационных предложениях». Помимо развития Gmail и Calendar, это включает в себя доведение до ума Google Docs и придание более завершенного вида набору их возможностей. Norton говорит, что Google также ищет возможности по расширению своих предложений в области коллаборации, в том числе в виде продуктов для крупного бизнеса, совместимыми с различными системами обеспечения безопасности для аутентификации.

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

Освобождение данных

Последнее время в компании все больше внимания уделяется предоставлению пользователям легко экспортировать их данные из продуктов Google, таких как Blogger, Google Maps, Google Docs, Chrome и App Engine (пользовательские данные разработчиков). На первый взгляд это может показаться очередным капризом PR-менеджеров, но на самом деле за этим фактом стоит более глубокая и интересная инновационная стратегия.

Brian Fitzpatrick, ветеран opensource разработок, возглавляет двухлетний проект от офисов Google в Чикаго. Основная идея заключается в оказании помощи пользователям, если они хотят получить свои файлы и другие данные из облака Google, чтобы у них была возможность перейти на какую-то другую систему, если они захотят. «Большинство людей не думает о возможности экспорта данных до тех пор пока не станет слишком поздно» — говорит Fitzpatrick. «Мы надеемся, что если вы прекратите использование одного нашего продукта сегодня, то у вас будет возможность попробовать другой продукт завтра.»

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

Что ж, теперь у нас есть эта возможность. Google считает, что эта открытость с точки зрения пользовательских данных, заставит компанию работать более старательно для удержания пользовательской базы. Fitzpatrick не знает других компаний, которые бы открыто заявляли об инициативе создания подобных возможностей для своих пользователей.

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

Реализуется этот микроформат с помощью атрибута rel тэга <a>, возможные варианты значения (имеется возможность их комбинировать):

Как не трудно заметить, практически все возможные варианты отношений могут быть описаны одним из значений или их комбинацией. Наш пример из начала этого поста с использованием XFN выглядел бы: <a href="www.site.ru" rel="friend met">Сайт моего друга</a>

Помимо этого есть еще один маленький нюанс, необходимый для того, чтобы browser’ы и поисковые системы знали, что данная страница оффциально поддерживает этот микроформат, для этого необходимо указать следующий атрибут тэгу <head>:

<head profile="http://gmpg.org/xfn/11">

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

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

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

Как известно, наукой, посвященной теории и практике сокрытия данных, является криптография (из греческого: κρυπτός — скрытый и γράφω — писать). Несмотря на свою историю, насчитывающую не одну тысячу лет, эта наука и в современном мире нашла множество применений.  С применением этой науки возможно решение самых разнообразных проблем, но основной задачей, с которой призвана справляться современная криптография является как раз относительно безопасная передача данных через ненадежное пространство.

Для максимального приближения реальных каналов связи к идеальному, необходимо выделить основные цели, к которым необходимо стремиться, в нашем случае их две:

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

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

Залогом уверенности в том, что передача данных безопасна, является наличие чего-либо что знает или может сделать получатель, но не знает или не может сделать. Использование этой формы асимметрии и является основой для большинства современных методов шифрования информации. Этот объект, обуславливающий возникновение асимметрии, принято называть словом ключ. Формально говоря ключ является одним из параметров шифрования, определяющим каким именно образом были преобразованы данные заранее известным алгоритмом. Основная классификация алгоритмов шифрования основывается на том, кто изначально владеет ключом, принято разделять их на алгоритмы с симметричным (т.е. секретным) и асимметричным (т.е. публичным) ключами.

Алгоритмы с симметричным ключом

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

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

Приватность в этом случае достигается за счет того, что даже зная алгоритм и перехватив передаваемое сообщение восстановление исходного текста без ключа невозможно. Но в некоторых случаях даже не имея возможности точно расшифровать сообщения, злоумышленник может с некоторой ненулевой вероятностью предположить содержимое исходного сообщения, основываясь на длине передаваемого сообщения (вполне очевидно, что в большинстве случаев длина сообщения и длина исходного текста — величины зависимые). Но такая вероятность чаще всего ничтожно мала, но если злоумышленник знает что-либо о структуре исходного сообщения и о том что оно собой представляет, этот факт может позволить ему предполагать с более высоким шансом на успех.

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

Алгоритмы с асимметричным ключом

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

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

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

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

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

В качестве заключения…

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

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

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

О процессе создания такого канала я и хочу Вам рассказать.

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

Прежде всего стоит сказать, что RSS является методом, основанным на XML и предназначенным для оперативного распространения новостей и контента сайта как среди потенциальных читателей, так и среди других сайтов.

Как следствие, на RSS распространяются все правила написания XML-документов, с которыми имеет смысл ознакомиться перед тем, как продолжить чтение этой записи. Помимо них, для RSS существует отдельный стандарт и соответственно набор не менее простых правил.

В качестве примера можно использовать любой понравившийся канал, например мой. Для того, чтобы увидеть сам текст документа, необходимо нажать правой кнопкой мыши на открытый в браузере документ и выбрать пункт, называющийся как-нибудь вроде "Просмотр исходного кода страницы" или "View Page Source".

По сравнению с XML, RSS-документ должен обладать четко определенной структурой:

1. За стандартным XML-заголовком открывается корневой элемент, содержащий указание версии RSS:

   (не забываем его закрывать в конце документа)

2. В корневой элементе должен должен содержаться ровно один элемент <channel>, символизирующий наш канал
3. Внутри <channel> обязательно должны содержаться три элемента:
   • <title> — заголовок канала
   • <link> — ссылка на сам сайт
   • <description> — описание канала
4. Помимо них он должен содержать один или несколько элементов <item>, которые будут обозначать одну конкретную новость, запись, пост, статью, заметку, не важно какое из этих слов больше подходит к каждому конкретному случаю — суть от этого не меняется.
5. Элементы между парой тэгов <item>, как ни странно, тоже должны в себя включать в себя волшебно-обязательные элементы, разница лишь в значении, которое им придается:
   • <title> — заголовок новости-записи-поста-статьи-заметки
   • <link> — ссылка на нее же, обычно на страницу внутри сайта
   • <description> — собственно говоря сам текст

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

Дочерние элементы <channel>

Дочерние элементы <item>

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

Good vs Evil

Большая часть "хороших" spider‘ов используется лишь для сбора информации о сайте и следуют пожеланиям владельцев сайтов, оставленных ими в специальном файле под названием robots.txt, либо внутри HTML-разметки с помощью специально предназначенных для этого тэгов (этот механизм выходит за рамки данного повествования, так что позволю себе его пропустить, оставив как тему для отдельного разговора).

Но даже сбор информации во время автоматизированного путешествия программы по сайтам можно использовать в корыстных целях — на многих сайтах люди размещают свою контактную информацию для тех или иных целей, и некоторые сайты эту информацию "публикуют". Spider, настроенный на сбор контактной информации (в основном адресов электронной почты и номеров ICQ и прочих служб обмена сообщениями) может в очень сжатые сроки насобирать длинный список адресов, пригодный, например, для рассылки нежелательной рекламы, в простонародье называемой спам. Избежать попадания своей контактной информации в такие списки относительно просто — достаточно лишь следить за тем, чтобы она либо не публиковалась, либо была защищена любым из простейших способов защиты от такого рода программ, начиная от банального требования регистрации для просмотра контактных данных пользователей, заканчивая выводом адресов через изображения или шифрование посредством JavaScript.

Среди прочих функций, которые может выполнять такого рода программа, одной из наиболее часто используемых является возможность заполнения такой неотъемлемой составляющей практически любого сайта, как формы. Имея возможность заполнения существенно большего количества форм в единицу времени, чем человек, такие программы служат основным источником спама в гостевых книгах, форумах и блогах. Еще одним из возможных применений автоматического заполнения форм является регистрация на множестве интернет-ресурсов с целью получения какой-либо выгоды, например регистрация сайтов в каталогах. Помимо этого crawler перемещается по сайту с относительно высокой скоростью, что резко увеличивает нагрузку на сервер, особенно при недостаточно оптимизированном движке сайта и/или недостатке ресурсов сервера, выделяемых на выполнение скриптов сайта.

Защита форм от автоматического заполнения

Наверняка многие из вас раньше слышали термин CAPTCHA, но боялись спросить: что же он значит? Как не трудно догадаться этот термин является аббревиатурой . Расшифровывается она как "Completely Automated Public Turing test to tell Computers and Humans Apart". Для меня до сих пор остается загадкой по какому принципу выбирались слова для составления этой аббревиатуры, наверное тупо случайным образом . Смысл этой фразы в переводе на русский можно передать как "полностью автоматический способ отличить человека от компьютера". Конечно же имеется ввиду не внешние различия, а особенности их поведения на просторах сети Интернет. В роли "компьютера" в данном случае как раз выступают программы, о которых шла речь в самом начале. Эта технология позволяет владельцам сайтов, желающих исключить (по крайней мере чисто теоретически, на практике же — минимизировать) посещение своего ресурса "плохими" "компьютерами", крайне затруднить их использование.

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

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

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