Новая серия занимательного поиска: утечка паспортных данных

В выдаче поисковых систем, в том числе Google и «Яндекс», можно обнаружить заполненные бланки электронных билетов на поезда Российских железных дорог.

В поисковики попала информация о пассажирах, заказавших билеты через сервисы онлайн-бронирования TuTu.ru и Railwayticket.ru.

На страницах с заголовком «Бланк электронного билета» указываются ФИО пассажира, купившего билет, и лиц, которые следуют вместе с ним, последние цифры номеров их паспортов, пункт отправления и пункт назначения, номер поезда и номер места, а также даты поездки.

Источник

Комментарий Roem.ru: можно лишь похвалить предусмотрительность РЖД, скрывающего за маской полные номера паспортов. Зная их можно было бы лишать пассажиров билетов, распечатывая их через терминалы.

При этом РЖД никого не лечит пожеланиями правильного применения robots.txt

Лучшие комментарии

Добавить 84 комментария

  • Ответить
    Роман Иванов Яндекс, а также ljsear.ch по выходным

    Если что-то закрыто файломrobots.txt, то оно не индексируется. Если проиндексировано, то robots.txt только появился и данные из поиска очень скоро пропадут.

  • Ответить

    они недавно поменяли robots.txt, видимо, после публикации новостей. возможно, когда робот инднексировал, там этого еще не было. HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Accept-Ranges: bytes ETag: W/"67−1311683900000″ Last-Modified: Tue, 26 Jul 2011 12:38:20 GMT Content-Type: text/plain Content-Length: 67 Date: Tue, 26 Jul 2011 17:13:34 GMT Connection: close

  • Ответить

    Компании-то к РЖД отношений, кроме агентских, не имеют, а вот то, в каком виде они получили данные билетов — к РЖД имеет самое прямое отношение

  • Ответить
    small_matter Андрей Винокуров

    Присоединюсь к сторонникам конспирологической версии наката на Яндекс. Как-то чересчур активно впрягаются роскомнадзоры, прокуратуры, Онищенко вот пока не хватает. Детское порно 2.0.

  • Ответить

    tutu.ru жжет: «Все эти страницы были защищены специальным протоколом https. Они существовали 30 минут, после чего немедленно уничтожались.» роботу кагбы достаточно и меньшего времени, а https’ом, без авторизации, только ленивый пользоваться не умеет

  • Ответить
    Альтер Эго

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

  • Ответить
    Юрий Синодов Основатель Roem.ru, sinodov.com

    kukutz, прокомментируешь, почему какие-то SMS Яндекс срыл в течение двух часов? а билеты «Аэроэкспресса» в открытом доступе уже часов пять при существующем robots.txt? При этом билеты одноразовые, покупателям может быть причинён прямой материальный ущерб

  • Ответить
    Роман Иванов Яндекс, а также ljsear.ch по выходным

    Я не в поиске работаю, так что прокомментирую что знаю: 1. Смс полностью исчезли из выдачи примерно через 10 часов, а не через два 2. Мы усиленно работаем над резким сокращением срока между обнаружением нового robots.txt на некотором сайте и автоматическим приведением результатов поиска в соответствие с ним

  • Ответить
    Альтер Эго

    Источник — Роем, кстати. ;) Этот комментарий появился раньше новости на Ленте. Нет, Psycho, тот комментарий в 16:17 появился на роеме. А в рунете заметили как минимум на пару часов раньше, например, [url=http://forumbgz.ru/showthreaded.php?Cat=&Board=Common&Number=10328730&page=&src=&fullview=&sb=&o=&vc=1]вот коммент в 14:20 про утечку жд-билетов[/url]

  • Ответить
    jet

    Я не понимаю чего на вебмастеров набросились, robots.txt это не инструмент защиты данных, это инструмент для SEO. Для защиты данных используются пароли, куки, SSL, и в том числе уникальные URL с секретным хэшем в них. В случаях, когда для юзабилити юзера не производится регистрация на сайте (сейчас это практически стандарт для магазинов — возможность купить без регистрации), уникальный URL, присланный на емейл, это практический единственный способ авторизации для просмотра статуса заказа. Когда Яндекс пеняет сайтам на robots.txt, это тоже самое, как если бы они взяли пароль от личного кабинета в магазине, присланный на яндекс почту, зашли бы с этим паролем и проиндексировали личный кабинет. А потом сказали — мы не виноваты, там не было robots.txt. Это не преувеличение, заход по уникальным ссылкам, в теле которой хэш для авторизации, это равнозначно вводу пароля. То есть robots.txt это вообще дело десятая, главный вопрос почему вообще Яндекс перехватывает и использует чужие пароли (в виде уникальных урлов). Кстати насчет Гугла — на Хабре писали, что они проиндексировали приватные данные только после того как они вылились в паблик через Яндекс.

  • Ответить
    jet

    Я не понимаю чего на вебмастеров набросились, robots.txt это не инструмент защиты данных, это инструмент для SEO. Для защиты данных используются пароли, куки, SSL, и в том числе уникальные URL с секретным хэшем в них. В случаях, когда для юзабилити юзера не производится регистрация на сайте (сейчас это практически стандарт для магазинов — возможность купить без регистрации), уникальный URL, присланный на емейл, это практический единственный способ авторизации для просмотра статуса заказа. Когда Яндекс пеняет сайтам на robots.txt, это тоже самое, как если бы они взяли пароль от личного кабинета в магазине, присланный на яндекс почту, зашли бы с этим паролем и проиндексировали личный кабинет. А потом сказали — мы не виноваты, там не было robots.txt. Это не преувеличение, заход по уникальным ссылкам, в теле которой хэш для авторизации, это равнозначно вводу пароля. То есть robots.txt это вообще дело десятое, главный вопрос почему вообще Яндекс перехватывает и использует чужие пароли (в виде уникальных урлов). Кстати насчет Гугла — на Хабре писали, что они проиндексировали приватные данные только после того как они вылились в паблик через Яндекс.

  • Ответить

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

  • Ответить
    jet

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

  • Ответить
    Альтер Эго

    jet, robots.txt это не инструмент для SEO, это общепринятый стандарт, протокол общения сайта с роботами (и не только ботами поисковиков). Приличные роботы его поддерживают. Понятия хеш для авторизации в урле нет. Есть понятие URL вообще. Если есть URL, заведомо доступный, значит он может быть проиндексирован. Если ты не хочешь, чтобы содержание было общедоступным — сделай что-нибудь для этого. Позволю себе аналогию: Вы оставляете лист бумаги с напечатанным на нем паролем к банковской ячейке в неприметном месте на шумной улице. Robots.txt это повешенный поверх этого листа еще один лист, на котором указано, что содержимое листа с паролем читать нельзя. Но чтобы никто гарантированно не смог узнать пароль от вашей банковской ячейки — распечатывать его, а тем более где-то вывешивать нельзя.

  • Ответить
    jet

    > jet, robots.txt это не инструмент для SEO, это общепринятый стандарт, протокол общения сайта с роботами согласен, но это не инструмент защиты, поэтому пенять на его отсутствие в данном контексте бесмысленно, тут первопричина в том, что пароль украли > Есть понятие URL вообще. и есть понятие параметров урлов и в этих параметрах могут быть секретные данные, вплоть до текста смс из GET форм, как это было например тут http://roem.ru/2011/07/18/addednews31690/?c#message98096 > Если есть URL, заведомо доступный, значит он может быть проиндексирован. урлы, которые тут обсуждают, не были заведомо доступными, они были заведомо уникальными и секретными > Вы оставляете лист бумаги с напечатанным на нем паролем к банковской ячейке в неприметном месте на шумной улице аналогия не подходит — проиндексированные урлы нигде не выставлялись

  • Ответить

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

  • Ответить

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

  • Ответить
    jet

    > И ключам в url давно пора туда же. от снифинга ни один способ защиты не поможет, даже на SSL сессии есть атака типа MIM, а более лучшего способа для авторизации без регистрации, чем переход по секретному урлу из присланного письма, пока не придумали (можно вводить код в POST форме, но тут юзабилити гораздо хуже)

  • Ответить
    jet

    > jet, а вообще, почитали бы вы RFC. Содержимое url считается совершенно открытой информацией какой номер этого конкретного RFC, где написано что GET параметры это публичная информация? например GET формы полностью соотвествуют стандарту, а вы не можете сказать что данные любых форм это заведомо совершенно открытая информация, там может быть и текст письма, что априори приватно, а про перехват GET параметров на прокси, через реферреры, итп не надо — это и есть снифинг и им взламывается любая защита, относительная легкость взлома не является оправданием для него

  • Ответить

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

  • Ответить

    > даже на SSL сессии есть атака типа MIM Да ну?! киньте ссылку на эксплоит, пригодится. Вы плохо знаете матчасть, сниффер (пассивный) не поможет вам вскрыть нормальную современную защиту. Если у вас есть возможность маршрутизировать пакеты, шансов побольше, но и от этого вполне реально защищаться на современных протоколах. > Прелестное оправдание действиям Яндекса Яндексу не надо оправдывать свои действия — вы забываете, что вебмастера, это клиенты Яндекса. Всех, кто не хочет пользоваться его услугами, он с удовольствием выкинет из индекса, ссылка известна. Где очередь? А если уж вебмастера желают пользоваться его услугами, причем бесплатно, то Яндекс может устанавливать правила.

  • Ответить

    > вас забанили на Гугле? http://www.monkey.org/~dugsong/dsniff/ Гугл это хорошо, но вы бы хоть на дату посмотрели, я уж не говорю прочитать и попробовать. Это давно не работает, с тех пор, как браузеры стали выдавать предупреждения на self-signed сертификаты.

  • Ответить
    jet

    > Это давно не работает, с тех пор, как браузеры стали выдавать предупреждения на self-signed сертификаты ой да не вопрос http://www.securitylab.ru/analytics/365717.php но это уже оффтопик, главное атаки MIM на SSL существуют, а 100% гарантии успешности я не обещал, но этого достаточно, чтобы показать, что и SSL не панацея

  • Ответить

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

  • Ответить
    jet

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

  • Ответить

    Ну не было ж, не было никакого взлома. Вроде, выяснили уже — сам вебмастер налепил Метрику, метрика сообщила Яндекс-роботу «новая страница», Яндекс-робот радостно пришел и проиндексировал. И кто тут виноват, кроме вебмастера «а я не знал, что так будет&#« Вы сейча»всем как штатовские юристы выступаете: там был случай, когда на каком-то сайте в url типа xxx.com/2011/06/27/index.html какой-то студент поменял дату на будущую и вытащил какую-то «неопубликованную» информацию, которая там ждала своей очереди на главную страницу. Тоже пытались пришить взлом, только не помню чем дело кончилось.

  • Ответить
    jet

    > метрика сообщила Яндекс-роботу «новая страница» метрика сообщила url с паролем для авторизации (хэшем) для доступа к личным данным > Яндекс-робот радостно пришел и проиндексировал. И кто тут виноват, кроме вебмастера «а я не знал, что так будет…" робот воспользовался паролем и зашел в личные данные в принципе это то же самое как парсить пароли из яндекс почты и заходить в личные кабинеты юзеров и индексировать их, наверняка в половине из них не стоят robots.txt, значит можно

  • Ответить

    ОК, если вы настаиваете: «Вебмастер установил на свой вебсайт Яндекс.Метрику так, что она сообщала пароль для доступа личным данным третьим лицам (Яндексу)» Как ни поверни, веб-мастер виноват. А Яндекс, при всем желании, догадаться что эта ссылка с «паролем» и что ведет она не на рецепт борща, а на страницу с личными данными никак не мог. Не знаю, что вы имеете ввиду под «парсить пароли из яндекс почты», но любая система, в которой откуда-то кто-то посторонний (и даже не посторонний) может добыть пароль к ней, должна быть выкинута на помойку.

  • Ответить

    Кстати, должен сказать спасибо — в результате наших препирательств, я наткнулся на очень интересный доклад с Black Hat DC 2009 по поводу борьбы с SSL http://thoughtcrime.org/software/sslstrip/ (нет, SSL не взломали). Вот это — высший пилотаж, а вы все про «секретные данные в GET запросе».

  • Ответить

    >А Яндекс, при всем желании, догадаться что эта ссылка с «паролем» и что ведет она не на рецепт борща, а на страницу с личными данными никак не мог. Может догадаться. Достаточно индексировать только то, на что можно попасть по ссылке с другой проиндексированной страницы. Лучше бы интернет нормально индексировали, чем извращаться с метрикой. У моего русскоязычного сайта в поиске яндекса 5к страниц, а в гугле 300к. И такая ситуация уже давно. Контент хороший, никакого жульничества. Надо наверное метрику поставить и все страницы прокликать!

  • Ответить

    > У моего русскоязычного сайта в поиске яндекса 5к страниц, а в гугле 300к. Из чистого любопытства — а Google.Analytics у вас стоит? Ну и да, чем плакать, сделайте себе sitemap, закиньте его в Яндекс и живите счастливо.

  • Ответить

    >Из чистого любопытства — а Google.Analytics у вас стоит? >Ну и да, чем плакать, сделайте себе sitemap, закиньте его в Яндекс и живите счастливо. Аналитикс стоит. Сайтмепы давно есть. Я не плачу, для меня этот сайт хобби. Просто интересный факт.

  • Ответить
    Альтер Эго

    > Вот так надо закрывать сайт от Яндекса. там неверный код, инсайдеры говорят, что для правильной защиты надо писать «fuck off» и далее по тексту и еще продублировать этот код три раза в robots.txt > У моего русскоязычного сайта в поиске яндекса 5к страниц, а в гугле 300к аналогично, после полугода работы сайта 3k vs 40k, контент уникальный, Платон говорит, что санкций нет, метрика и аналитикс не стоят

  • Ответить

    Ну, а реально-то страниц на сайте сколько? в сайтмэпе? Кстати, простой use case для Метрики/Аналитикс — если навигация на сайте сделана через форму с селектами («выберите категорию продукта», «выберите продукт»), да еще и с javascript-наворотами до кучи, то роботу довольно трудно будет куда-нибудь на этом сайте попасть (роботы формы вообще заполняют?) без помощи механизма, который бы «сдавал» ему урл просматриваемых страниц — т.е. либо Метрика, либо сайтмэп сгенерированный из логов. Нет на эти страницы «внешних ссылок», хотя попасть туда вполне можно.

  • Ответить

    Коллеги, я, наверное, дурак (со слов Грея получается, что точно дурак), но объясните. Я использую авторизацию на основе сессий PHP. И как-то имею в виду тех пользователей, у которых отключены куки. Допустим, у меня несколько тыщ страниц профайлов пользователей, бОльшая часть которых закрыта их владельцами от всеобщего просмотра, остальные не против, чтобы их находили в поиковиках. То есть если Яндексу узнает url моего сайта с? PHPSESSID=…, Яндекс спокойно содержимое расскажет всем-всем, так? А защититься мне предлагает, прописав в роботс.тхт запрет на тысячи url-ов типа /user/id, ибо запретить весь /user/ я не могу? Там, в Яндексе, наверное кто-то слегка стукнулся головой при рождении

  • Ответить

    Нужно запрещать к индексации сессии. Через Disallow или Clean Param. Причём это нужно не только для безопасности, но и в принципе для нормальной индексации сайта — страницы сессий «замусоривают» индекс дублями.

  • Ответить

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

  • Ответить

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

  • Ответить

    именно корректен, ибо в описанной ситуации «Яндекс будет делать то, что хочет он», означает — «пользователь мне показал, я покажу всем, ничего личного, просто бизнес». ровно то же самое, что поснифить, за тем исключением, что пользователь сам «пароль» (хэш) показал Яндексу.

  • Ответить

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

  • Ответить

    Валь, я понимаю, что ты не технарь, но просто пойми: в ситуации, когда у пользователя отключены куки, нет другого способа не заставлять его (пользователя) на каждой странице вводить логин/пароль, кроме как сгенерировать уникальный ключ, открывающий для доступа этому пользователю те страницы, которые ему можно смотреть, и передавать его в url-е. Это как бы факт. То, что Яндекс ради своей прибыли этим пользуется, говоря «так вы от меня закройте, я не буду смотреть» — это, мягко говоря, некомильфо. > уже подали запрос в прокуратуру вроде бы для тебя не должно быть аргументом, если в этой стране силовые наехали на кого-то, значит, этот кто-то гарантированно виноват? > Надеюсь, подобных тредов по поводу твоих сайтов не будет. вот я тоже надеюсь, да только если бы не было подобных тредов про другие сайты, вполне возможно, что и про мои бы появились, ибо я не СЕОшник, и знать не знал, что Яндекс нагло киздит пароли доступа.

  • Ответить

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

  • Ответить

    Василий, сейчас как «не технарь» рассуждаешь именно ты. Помнится мне, что куки отключены у минимального количества юзеров, да и отключение кук — это личный выбор пользователя, на который он идёт, понимая, что будет испытывать проблемы на куче сайтов, которые их используют. > ибо я не СЕОшник, и знать не знал, что Яндекс нагло киздит пароли доступа Как я уже писал на нашей странице в ФБ: «История с утечками всевозможных данных как бы подчёркивает, что SEO-специалист — это не просто «некто, загаживающий поисковые системы», но и человек, от которого может зависесть безопасность хранимых на сайте данных».

  • Ответить

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

  • Ответить
    jet

    > То, что Яндекс ради своей прибыли этим пользуется, говоря «так вы от меня закройте, я не буду смотреть» — это, мягко говоря, некомильфо. Это не то, что некомильфо, это Яндекс де факто занимается взломом — пользуется паролями, которые ему случайно удалось узнать. Как я уже писал, авторизация по GET параметрам это вполне обычное дело и соотвествует стандартам и юридически нет никакой разницы своровать обычный логин и пароль и зайти в чужой аккаунт по ним или своровать секретный урл для авторизации. Robots.txt тут вообще дело десятое. Просто они пока сами еще не поняли, что делают. Пока мыслят логикой робота — увидел ссылку и зашел. Это как — зашел в магазин, вижу товар без ценника, положил в карман и ушел, а что такого-то?

  • Ответить

    Фраза Яндекса «необходимо запретить поисковым роботам индексировать страницы сайтов с информацией, которая не должна стать публичной. Для этого существует файл robots.txt.» в контексте данной ситуации говорит о как минимум недалекости того, кто занимает такую позицию. robots.txt — не для защиты от несанкционированного доступа, а для подачи команд роботам, но. Если веб-мастер явно не приглашал к себе никаких роботов, он не обязан ими командовать, обязаны командовать создатели робота — командовать правильно, законно, и по возможности — этично. Они этого не делают не потому, что правы, а потому, что веб-мастеру мелкой е-лавки с ними не справиться.

  • Ответить
    Альтер Эго

    > Я использую авторизацию на основе сессий PHP. И что, разве не проверяется IP-адрес? Он должен быть тем же, для которого создавалась сессия.

  • Ответить

    Это Вас кто-то обманул. НЕ должен. Другое дело, что поскольку кругом ворье, лучше уж попросить такого невезучего пользователя перелогиниваться по нескольку раз.

  • Ответить

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

  • Ответить

    И для сессии хранить нужно не один айпи, а все, которые подверждены логиновм/паролем, Чтобы пользователь после перехода с адреса, А на адрес Б, а потом с Б на, А снова не перелогинивался. Это, правда, не спасет от наглости поисковака, который запалит урл вида login: password@domain, но, к счастью, такие адреса почти не появляются.

  • Ответить
    jet

    > и, кста, да, это решение это сработает только для сессий, а есть еще быстрая авторизация по ссылке в письме, отправка данных GET форм, итп

  • Ответить

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

  • Ответить

    PHPSESSIONID в GET запросе, да еще и с длинными сессиями не привязанными к IP — это бесконечное зло. Я сам об это спотыкался в 2001 году, когда пользователи фигачили в форум ссылки на страницы вместе со своими PHPSESSIONID и дальше читатели развлекались в меру фантазии. Давайте посмотрим с другой стороны: пользователь у которого отключены куки, он их по какой причине отключил? наверное, заботится о безопасности своей информации? зачем же вы ему предлагаете ЕЩЕ МЕНЕЕ безопасный способ авторизации.

  • Ответить

    Кстати, Яндекс может поступить радикально — нет robots.txt, сайт не индексируется, вообще. Файлики у всех появятся с удивительной скоростью

  • Ответить
    Юрий Синодов Основатель Roem.ru, sinodov.com

    «Яндекс» рассматривает наличие быстрого поиска и большей полноты индекса как конкурентное преимущество. Решение с неиндексацией сайтов с отсутствующим robots.txt его ни разу не устроит, оно несбалансировано. «Яндекс» потеряет намного больше чем приобретет.

  • Ответить

    Прочёл тред, ужаснулся. Неужели не ясно, что из-за криворуких сайтодельцов пострадали нормальные парни, у которых и роботс прямой, и заказы под логинами, и сайты хорошие, и метрика стоит ровно. Это же был самый быстрый сайт-мэп для новых урлов… А что теперь будет? ЗЫ: Юра, хотел зарегится наконец, но здесь http://roem.ru/profile/ ссылка сюда http://roem.ru/profile/index.php?register=yes отдала 404… к разговору…

  • Ответить

    «Яндекс» рассматривает наличие быстрого поиска и большей полноты индекса как конкурентное преимущество. Я предлагаю на время забыть о взаимных обвинениях во всех текущих срач-темах и подойти к вопросу более конструктивно. Яндекс хочет получать важные урлы быстро. Это нормальное желание, тем более, что такие урлы собирают его сервисы, Бар и Метрика. В тоже время неоднократно предлагался вариант с фильтрацией этих урлов, т.е. урл попадает в индекс (или в быстроиндекс, не важно), если на него стоят ссылки с проиндексированных ранее страниц. Почему нельзя совместить эти два подхода? Определить, есть ли на новый урл ссылка вполне реально на лету, т.к. известно, откуда на документ перешли. Если донор уже в индексе и ссылка есть, значит и новый урл можно в индекс засовывать. Если документ-донор не определить, он не в индексе или ссылки на нем нет, то и документ-акцептор в индексе пока не нужен, хотя клики на него копить вполне можно. При совмещении этих подходов ухудшается полнота. Ну да, вот только какая? Полнота сворованных урлов с хеш-паролем — теряется, но она в индексе поисковика и не нужна. Это наоборот хорошо. В одной из срач-веток приводили недавний американский пример, когда страница с финансовым отчетом должна была появиться в строго определенное время, но была сделана заранее, просто на нее не было ссылок. Там страницу вытащили по логике урла, в нашем случае — она бы попала в поиск самостоятельно, и явно раньше нужного срока, т.к. это была полноценная страница со всеми счетчиками и ее просматривала куча народа внутри конторы. И понятно, что в роботсе она не закрыта, т.к. находилась в разделе для индексированных страниц. Такие страницы для полноты тоже не нужны, это вроде должно быть очевидно. Или кому-то не? Кто-нибудь может привести примеры документов, на которые нет ссылок, но они важны для полноты? Да, и еще конечно желательно, чтобы вебмастер хотел видеть их в индексе. Если таких примеров нет, то причем вообще роботс.тхт? Ну и еще можно заметить, что счетчики и модули систем статистики стоят на сайтах не первый день и всегда были на страницах, запароленных хешем. Однако никто их никогда не палил, ни одна система статистики. Пока «внезапно» кое-кто не решил поменять правила игры.

  • Ответить

    Дело же не только в полноте, но и в актуальности. Если мариновать новость до тех пор, пока робот найдет на нее ссылку с какой-то другой страницы, эта новость уже будет никму не нужна.

  • Ответить

    > Кто-нибудь может привести примеры документов, на которые нет ссылок, но они важны для полноты? Я уже где-то приводил вариант: делаем навигацию по сайту из формы с select’ами — один селект «категория», второй селект «подкатегория», третий «страница» — и кнопка «go». Форма отправляется GET, все классно работает, но нет ни одной входящей ссылки на внутренние страницы. Вы можете возразить, кто ж так делает? Хочешь, чтобы тебя индексировали, не делай так! На что есть два ответа — во-первых, такая навигация была придумана очень давно, примерно тогда же, когда и хэш в урле; во-вторых, ответ «хочешь, чтобы тебя индексировали, не делай так!» ничем не отличается от «не хочешь, чтобы тебя индексировали, не делай так!», а как выше справедливо заметил Синодов, полнота — это конкурентное преимущество поиска, поэтому он будет бороться за то, чтобы индексировать все, что возможно (Гугл вон даже javascript парсит, вроде бы; Яндекс, наверное, тоже) и ему просто не выгоден первый вариант, как и не-индексирование сайтов без роботс.тхт Вторым сценарием должны быть страницы с динамическим обновлением через ajax; там запросы за новым контентом есть, могут быть уникальные урлы для каждого нового контента, а вот ссылок обычно нет. Но это более сложный случай — может быть кто-то знает, как поисковики (Яндекс) сейчас разбираются с ними?

  • Ответить

    Дело же не только в полноте, но и в актуальности. Если мариновать новость до тех пор, пока робот найдет на нее ссылку с какой-то другой страницы, эта новость уже будет никму не нужна. Ну давай разберем актуальность. Только учтем тот факт, что Яндекс активно отмазывается от передачи урлов через Бар. Т.е. их передает только Метрика. И ты хочешь сказать, что на сайте с Метрикой может оказаться некий актуальный и уже публичный документ, на который 100500 раз кликали, но ни разу не перешли по ссылке с этого же сайта (после чего ссылка легко находится)? Как это может случиться? И ты уверен, что этот документ уже публичный? Вы можете возразить, кто ж так делает? Я не только могу, но и возражу. Такие урлы системам статистики были известны всегда. В том числе системам статистики поисковиков, почти у всех они есть. Но в таком количестве никогда не попадали в индекс. Т.е. либо эти данные не передавались в поиск, либо передавались, но хорошо фильтровались. Но «внезапно» ситуация изменилась. Таких документов в сети много — результаты поиска по сайту, всякие калькуляторы и пр. На полноту индекса они не особо влияют, имхо. Сайтов же, сделанных так, как вы описали — практически нет, т.к. они бы не попали в индексы поисковиков.

  • Ответить

    А зачем, интересно, Яндекс отмазывается от передачи урлов Баром? Ведь передавать адреса в Яндекс — Бар, конечно (!) передаёт. За счёт этого делается фоновый запрос в поиск по блогам и работает функция-кнопка Бара «отзывов о странице». С комиксным пузырём такая, в правой колонке функций она: http://bar.yandex.ru/firefox/functionality.xml Невозможно отмазываться от передачи. Но можно «отмазаться» от включения переданных урлов в индексы.

  • Ответить

    Яндекс пишет только о том, что Бар не передает адреса в поисковик: «Особо хотим отметить, что посещение пользователем страницы с помощью браузера с установленным Яндекс.Баром не приводило и не приводит к ее индексации.» (http://webmaster.ya.ru/replies.xml?item_no=11122) И нигде не пишет очевидную неправду, что Бар вообще не передает адресов. Было бы странно, если бы писал, это же проверяется за минуту.

  • Ответить

    Видимо я как-то не совсем однозначно выразился… Имелось ввиду, что урлы из Бара не передаются в краулер поисковика для поиска новых документов с их последующей индексацией. Именно от этого открещиваются в Яндексе. Проверить это сложно, если оно и было, то скорее всего успели зачистить. Поэтому пока что вариант единственный — поверить в то, что это на самом деле так. Урлы и все данные по ним из Бара в поиск безусловно передаются и активно используются в ранжировании. Это важная и нужная информация, от ее использования выигрывают все, и юзеры, и поиск.

  • Ответить

    пока в этом треде не столько срач, сколько диалог, хочу еще момент обозначить: > Нужно запрещать к индексации сессии. Через Disallow или Clean Param. > Причём это нужно не только для безопасности, но и в принципе для нормальной индексации сайта В ситуации, когда мне, владельцу сайта, мало важен бизнес Яндекса, я ничего не должен. Я не должен управлять их роботами, это они должны. Должны не пакостить мне, заходя на мой сайт. И если ребятам, на которых по переводу стрелок из Яндекса наезжает Роскомнадзор, хватит воли и чутка средств, возможно. да, всего лишь возможно. они смогут доказать, что это роботы (их создатели) вламываются на их сайты. То, что это бизнес создателей роботов — конечно, не аргумент. По крайней мере, теоретически я в таком случае могу продать Гуглу свой маленький бизнес по отстрелу велосипедистов на Толстого. А че, не ездите там на велосипедах.