Рубрика: Фсем Фтыкать!

yahoo открывает API

via Alex Moskalyuk
Яху открыл для разработчиков программистскую платформу (?:)) под названием BOSS (Build your Own Search Service)

Поисковый отдел Yahoo! сегодня открыл свой индекс. Теперь пользователи платформы BOSS (Build Your Own Search Service) смогут отсылать поисковые запросы Yahoo!, получать назад результаты из индекса, самостоятельно производить ранжирование поисковых результатов, самостоятельно оформлять странуцы результатов поиска. Единственным условием является отображение рекламы Yahoo! Publisher Network на страницах с результатами, компания даже не лимитирует количество запросов.

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

Русский поиск от Яху, конечно, говно, но ведь не только по русски можно искать 🙂 Хорошо, что можно самостоятельно ранжировать результаты – кажется, Яндекс.ХМЛ такое запрещал. Опять-же, число запросов неограничено.

Приведены штук пять примеров использования поиска.

Слава роботам 🙂

Правильные апдейты Яндекса

Сделал более правильную пробивалку текстовых апдейтов Яндекса: http://tools.promosite.ru/, которая показывает апы и даты, за которые страницы были выложены.

Почему это – правильные апдейты?

Сейчас все пользуются апометром Иванова и SergoZD. Он работает так: берет выдачу Яндекса по максимально широкому запросу (ru|com|info…) с абракадаброй для пробивки кеша, отсортированную по дате. Возможно, еще rd=0 добавляют и еще что-нибудь. Когда в этой выдаче появляется сайт с “новой” датой, считают это апдейтом.

Проблемки возникают следующие. Во-первых, частенько возникают мифические “доапы” (или “перед-апы”). Во-вторых, “Cамая поздняя дата в БД” слишком уж большая бывает – ну нет таких новых документов в обычной базе! Ну нет и все. Вот например: “ап” 25.03.2008 марта, а поздняя дата 22.03.2008.

Отчего это все происходит?

Сначала палю тему. 🙂

В хелпе Яндекса есть оператор date=”YYYYMMDD”, причем есть очень давно. Описан так: “Поиск производится только по страницам, дата которых удовлетворяет заданному условию.”  Дата в данном случае есть HTTP-заголовок Last-modified, убедимся в этом дальше.

Но многие документы отдают неправильный Last-modified, например, если поискать дату в будущем (сейчас 26 марта): date=”20080425″, найдем несколько сайтов. Например, страница на afisha.webrostov.ru – сохраненка не быстророботная. Проверим ее http-хедеры через какой-нибудь сервис – и легко увидим искомую строчку Last-Modified: Mon, 24 Apr 2008 23:00:00 GMT… Ну, дата идет следующим днем – ладно.

Итак, last-modified может неправильно отдаваться. И как раз поэтому в выдаче Яндекса могут быть документы, которые проиндексированы во время Х, а Яндексу кажется, что дата у них позже. В общем, если поискать этим оператором по ближайшему прошлому – быстророботные страницы там будут, но и страницы основного робота – тоже.

Я все думал – откуда в апометре Иванова и SergoZD такая точность даты? Я так думаю, что либо скриптом лезется на “новую” страницу и дергается Last-Modified, либо Яндекс.ХМЛ такую информацию дает, но берет он ее оттуда же. Логично?

Поэтому в алгорим с сортировкой по дате могут закрадываться ошибки именно в виде “случайных” попаданий сайтов, которые кажутся новыми, а проиндексированы давно. Может, подкрутили что-нибудь, и релевантность по запросу “ru” у сайта увеличилась. 🙂 Ну и, конечно, дополнительные обновления есть – число найденных документов по дате колеблется во времени. Не важно, почему.

Только выплыл дополнительно, может, один сайтик, который и попался скрипту, а делается вывод о мегаапдейте. Которого 99% юзеров не заметят, зато заметят 99% сеошников. Вот например: “замечен” апдейт 25.03.2008 04:01:06, которого не было, несколько доапов от 19.03.2008, которых тоже не было (разница в несколько минут = это один и тот же апдейт).

К счастью, большинство сайтов с датой настроены правильно. Итак, как работает мой апометр.

Он перебирает запросы вида date=”YYYYMMDD” от сегодня в прошлое. Пока индексированное в эту дату не выложено – находится порядка 100 говносайтов. А когда при следующей пробивке число сайтов возрастает до 30-50 тысяч, значит, выложили – апдейт, типа. Текстовый апдейт. Заодно бонус: можно точно знать, документы за какие даты выложены, а какие – нет.

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

Подписка на RSS

XSS (или не xss?) уязвимости

Навеяно этой темой форума searchengines.ru (и еще одной, где о знакомых упоминается :)).
Не знаю уж, называется ли это xss-уязвимостью, или не называется, но. Приведен пример, в котором в поиске спец. строки она вставляется в тайтл, а если туда засунуть теги (закрывающий тег тайтл, например, и хеад, и дальше ссылку), то будет ссылка с выдуманной страницы. Иногда запрос вставляется просто в текст страницы. Если есть проверка на <и> – то можно использовать UTF-7 (но не всегда: когда вставка идет в тайтл и указание кодировки идет далеко) В общем, люди вставили через поиск свои ссылки, которые качают клиентов.

Ту тему почистили, примеры:

1. Ищем в Яндексе $title(+a href http) и идем на 5-6 страницу. Видим кучу страниц, в урлах которых хтмл-код, типа http://www.cci.ru/showall.asp?t_id=1&query=%22%3E%3Ca+href%3Dhttp%3A%2F%2Finterfaks%2Ekiev%2Eua%2F%3E%E0%F0%E5%ED%E4%E0+%EA%EE%F2%F2%E5%E4%E6%E0+%ED%E0+%ED%EE%E2%FB%E9+%E3%EE%E4%3C%2Fa%3E%3Ca+alt%3D%22&page=33 . При вставке в текст страницы они дают ссылки на "клиента". Только осталось их качнуть с доноров.

2. Среди этих сайтов я нашел и сайт, который когда-то делал и продвигал – ultraslim.ru. Ссылки с него люди получают через поиск: $title(+a href http) на сайте: ultraslim.ru . Коллекция из 160 украинских (в основном!) сайтов – акцепторов. В общем, получить тИЦ 90-140 реально за счет этого метода…

3. Похожая вещь на сайте cottage.ru: #url="www.cottage.ru/search/index.php?q=*"– аж 415 проиндексированных страниц с поиском 🙂 http://www.yandex.ru/yandsearch?text=%23url%3D%22www.cottage.ru%2Fsearch%2Findex.php%3Fq%3D*%22&stype=www

4. Можно найти "заказчиков" – сайты, с которых "качаются" доноры. Надо думать, что они связаны с заказчиками… Если на странице
[убрано по просьбе beroot”> ссылка "источник" выгладит как http://www.aurore-nissan.ru/search/search.html?searchString=%22%3E%3Ca+href%3D%22http%3A%2F%2Fallautoalarm.ru%2F%22%3E%F3%F1%F2%E0%ED%EE%E2%EA%E0+%F1%E8%E3%ED%E0%EB%E8%E7%E0%F6%E8%E9%3C%2Fa%3E%3Ca+alt%3D%22 – просто качают люди доноров…

5. Реально существует около 200 известных сайтов с дырками: [убрано по просьбе beroot] – 194 сайта… Пройтись по всем и собрать коллекцию уязвимых сайтов 🙂 [убрано по просьбе beroot] Тут – 110 сайтов и т.д.

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

Литература:
http://hack-expo.void.ru/groups/antichat/html/rutxtutf7.html
http://www.securitylab.ru/analytics/274302.php
http://barushev.net/archive/2005/wordpress-xss.html
http://www.dsec.ru/about/articles/web_xss/

Линкспам мастдай! Берите скрипт!

Написал конфирмер для защиты форм от роботов. Бесплатно! Берите! 🙂
Описание задесь: http://promosite.ru/services/confirmer.php
Пример работы: http://promosite.ru/services/confirmer/form.php
Скачать: http://promosite.ru/services/confirmer/confirmer.zip
Требуется возможность работы PHP с графикой, а именно функции imagecreatefromgif, imagegif.
***
Это бесплатный комплект скриптов на PHP, который позволяет на любую форму установить проверку юзера на человечность. Особенность конфирмера: НЕ НУЖНО использовать сессии при работе! Картинки не генерятся индивидуально для пользователей, но защита вполне достаточная.

Комплект состоит из:
1. файл confirmer_pic.php, который генерит картинку с нужным числом псевдослучайных символов, меняющихся раз в минуту
2. файл confirmer_include.php, который знает алгоритм генерации картинки и проверяет введенную строчку на правильность. Должен находиться в той же директории, что и (1).
3. файл form.php, пример использования кода. Он инклюдит confirmer_include.php и получает результат проверки в виде переменной $confirmer_result (=0,1) и показывает картинку счетчика $confirmer_pic. Должен находиться в той же директории, что и (1,2), т.к. вызов картинки идет из той же директории. Вы можете это исправить сами.
4. директории с графической подложкой и GIF-картинками буковок. Эта директория прописана в файле confirmer_pic.php, вообще ее желательно прятать от чужих глаз. Все картинки можно менять на свои! Вы можете создать свой конфирмер, использовать свои картинки.
Картинка генерится на основе номера минуты, зашифрованного функцией crypt() с параметром $confirmer_salt. Эта строка (фактически: пароль) должна быть одинаковой в скриптах confirmer_pic.php и confirmer_include.php – иначе ничего не получится.
Пароль $confirmer_salt снаружи можно подобрать… 🙂 но это очень-очень долго :).
В параметре $confirmer_num файла confirmer_include.php задается число буковок, которые надо вводить юзеру в поле.
Картинка валидна в течение $confirmer_min минут после ее создания. Просто скрипт confirmer_include.php проверяет все значения, соотвествующие прошедшим минутам.

Работает конфирмер просто:
1. В начале скрипта form.php вы инклюдите confirmer_include.php.
2. Если запрос пришел методом GET, он выставляет переменную $confirmer_pic, которая содержит html-код: картинку с пояснением.
3. Если запрос пришел методом POST, он выставляет переменную $confirmer_result, которая равна 1, если юзер ввел правильный код, или 0, если неправильный (в этом случае он устанавливает $confirmer_pic и просит повторить ввод). Анализируете эти данные и делаете свои дела.

Рамблер – миллиард документов и поиск

Влад Шабанов на своем блоге в “планете” сказал, что у Рамблера миллиард документов в индексе. (via sevson)
Причем дал ссылку такую: ${universe}
Интересный оператор. 🙂 Вроде в хелпе такого нет.
Кстати, полез в хелп по операторам Рамблера – с удивлением обнаружил, что описан “клей” Рамблера, сообщение о котором давалось давным-давно в “рамблер-группах”:

Оператор && (логическое И)

Два запроса, соединенные оператором &&, образуют сложный запрос, которому удовлетворяют только те документы, которые одновременно удовлетворяют обоим этим запросам. Иными словами, по запросу собака && кошка найдутся только те документы, которые содержат и слово “собака”, и слово “кошка”.

Между тем, как мы все понимаем, слово “собака” и слово “кошка” на найденной странице могут находиться в самых разнообразных местах, как рядом – в одном предложении, так и в разных предложениях, и даже разных статьях. Для того, чтобы дать понять поисковой машине, что слова должны находиться близко друг к другу, Вы можете использовать модифицированное И – &, для управления им служат регулирующие операторы > и <. Чтобы расстояние между словами в результате поиска было меньше заданного по умолчанию, можно использовать конструкцию &< или &<<, чем больше регулирующих операторов, тем сильнее Вы уменьшаете расстояние. Чтобы увеличить исходное расстояние, нужно применить обратный оператор: &> или &>>.

Оператор && не имеет степеней регулировки и является оператором И, при котором в запрос попадают даже самые далеко отстоящие друг от друга слова.

Там же, в блоге Шабанова, есть повторное описание оператора &&& – поиск по сайту:

Все никак не мог придумать жизненный пример для оператора ‘&&&’ (логическое И в пределах сайта)
Изначально оператор затеян был для борьбы со спамом, а вот “гражданского” назначения как-то не видно было.
А пример вот какой: хочу я купить кучку всякой техники для кухни, причем желательно все в одном, максимум, двух магазинах. Чтоб не бегать, не оплачивать по 10 раз доставку и т. д. Есть у меня конкретные названия моделей (зашел в М-Видео, выбрал и списал). Найти каждую из них в отдельности — запросто, по 100 магазинов. Но в первом попавшемся по запросу со стиралкой нет холодильника и т. д.
Искать надо так:
candy aquamatic 800t &&& LG MH 6384 &&& zanussi ZK630 LX

– прикололо “гражданское применение”. Типа делайте выводы, как борются со спамом (любители цепей Маркова :)).
В общем, фсем фтыкать!

Относительная конкурентность запросов / фсем фтыкать!

Некоторое время назад мы встречались с тов. Gutorin (привет!) по разным вопросам, и от него же я узнал русским языком о том, что думает тов. Миныч, он же ikozlov на форуме searchengines.ru.
Ну, на форуме он изъяснялся не очень ясно, но лично сэр Gutorin рассказал, а потом и сам Миныч опубликовал (я не собирался вперед него, что вы!).
Вот на это – фсем фтыкать!
Короче, идея проста: мы ищем в Яндексе запрос типа фаллос|кондиционер, при этом предполагается, что эти термины не встречаются в документах вместе. А если встречаются, пересечения можно вычистить запросом фаллос && кондиционер.
Затем мы смотрим на то, что дает колдунщик Яндекса, и начинаем менять веса слов, забивая переколдованный запрос со своими весами. В результате мы получаем некоторые хитрые данные, которые позволяют нам ОЦЕНИТЬ релевантность (общую: текстовую и ссылочную) разных сайтов и даже в некоторых единицах (с некоторой точностью) относительно какого-то сайта, выдающегося, например, первым по запросу фаллос.
Т.е., релевантность каждого сайта из верха выдачи по кондиционер можноо отранжировать в цифрах относительно первого (например) сайта по запросу фаллос.
***
Миныч, правда, как обычно, у себя выразился неясно. Ну, я не виноват. Если что, пост могу убрать. 🙂

Яндекс – новое описание языка и интервью…

1.
Эх, давно я не перечитывал правила языка запросов Яндекса – ан глядь: они уже на новом месте и выглядят по-новому. Раньше, вроде, на статическом урле все находилось…
В новом описании языка: во-первых, появился оператор rhost, который некоторое время был недокументированным, появился найденный мной 🙂 оператор domain (правда, пример там странный приведён, с расстоянием, но именно так он используется в reqtext), по-русски написано про параметр мягкости:

(запрос из нескольких слов)//N, где N — число от 0 до 100.
При расчете релевантности документа могут быть сочтены релевантными пассажи, где есть только часть слов запроса, тем меньшая, чем больше N (по умолчанию N=6). В результатах поиска такие документы помечены как «нестрогое соответствие». Подробнее см. раздел «”Фильтрация” по кворуму» в статье «Некоторые аспекты полнотекстового поиска и ранжирования в Яндекс».

Ну и еще добавлен оператор cat для поиска по категории или региону (“пацанский” оператор, для своих:)) и оператор date, тоже забавного вида (снова непонятно, что значит “Поиск производится только по страницам, дата которых удовлетворяет заданному условию” – “дата которых”??)
2.
Ну и остальное – Александр Быков о Персональном поиске Яндекса – интервью, данное К. Рощупкину. Что за ППЯ – не знаю, кто такой Быков – тоже. Но зато там есть ссылка на новые правила запросов. 🙂

отчеты по гранту Яндекса опубликованы

Почему-то узнавать об этом пришлось из блога Яндекса! :madd:
Мое вот: Е.А. Трофименко. Оптимизация расчета ссылочной популярности и учета ее при ранжировании результатов поиска. Надо бы его в хтмл-виде выложить.
Вот здесь список отчетов: http://company.yandex.ru/grant/list.xml
Как говорится, фсем фтыкать. 🙂

Яндекс – новый алгоритм.

По сообщению в блоге Cherny (ну и в блоге Яндекса источник) говорят, что:

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

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

— Александр Авдонкин, программист отдела разработки поисковых сервисов

-Фсем медитировать! 🙂
Точность поиска – в основном имеется в виду сужение результатов за счет выпихивания “не очень релевантных” позиций из выдачи (вниз, вероятно, а не совсем выкидывание). Наверное.
А вот “Документы, посвященные именно теме запроса” – это интересно. Я всегда считал, что “именно теме” могут, скорее, быть посвящены сайты, а не документы… Оговорился человек? Или они тему каждому документу приписывают? (с точки зрения программиста – или накладно по ресурсам, или какое-нибудь говно в результате выйдет – типа списка в N “характерных” для документа кейвордов).
А насчет

по названиям компаний наверху чаще встречаются сайты этих компаний, а не их партнеров

-не обойтись без изменений алгоритмов ссылочного ранжирования… Вот тебе и тема. Хотя, может, они просто вес слов в тайтле увеличили? 😀
…
А программисты отдела разработки самостоятельные пошли. 🙂 Интересно, они у Воложа испрашивают согласия на публикацию в блоге Яндекса? Или у Сегаловича? 🙂

domain: “новый” оператор Яндекса?

Я довольно давно увидел, что при поиске по Яндекс-каталогу урла система автоматически превращает его в url=”домен.ru*”. Что-то мне чудится, что там и оператор domain=”” мелькал…
Итак, в общем поиске работает оператор domain=”string”, который показывает все сайты с этой подстрокой в имени домена (и третьего, и второго, и первого, и нулевого! уровня). Работает на точное соотвествие одной из частей доменного имени, без чисел.
Также работает звездочка:
domain=”search*” – по любым совпадениям.
Работает и domain=”ru”, и domain=”root”. 🙂
Как нашел: смотрел reqtext на странице поиска строки “XML-вид каталога Яндекса” по сайту blog.promosite.ru. А reqtext такой:
((“XML::45433 вид::2105 каталога::1451 Яндекса::76938”)//6 <<(domain="promosite"::39515:0 &/(1 1) domain="ru"::39515:0 &/(1 1) domain="root"::39515:0):0) Еще и какие-то цифры через двоеточие два раза вместо одного...