Как стать автором
Обновить

Комментарии 520

Хм, думаю разработчикам yandex метрик следует добавить параметр dontIndex в их js api
Я думаю разработчикам магазинов нужно правильно делать архитектуру проекта.
Как можно доверять пользователю только по одной ссылке? Почему забыли про куки?
Да просто разработчики наплевали на стандарты и спецификации, касающиеся разделения прав пользователей. Ответ мне напоминает стиль: «сам дурак».
Ребята, не надо отмазываться — это ошибка ваша и больше не чья. С такой архитектурой проекта только… сказал бы, но здесь и детей много.
Да какая архитектура в данных конкретных «фэйлах Яндекса» — robots.txt было бы достаточно.
Скрытый разработчик Webasyst, или бывший разработчик )))
Ну вот, прокуратура теперь будет разбираться
Опять прикрываемся robot.txt, это привязка к конкретному случаю. Я имею ввиду все проекты. Т.е. надо придерживаться норм (стандартов) безопастности, тогда не надо будет перекладывать с больной головы на здоровую. Я уверен что разработчики и сами понимают в душе, что виноваты они. Просто теперь пытаются сохранить хорошую мину при плохой игре.
Я к тому, что в данных случаях («неделя Яндекса») не нужно было привлекать гуру архитектуры или суперспецов по криптографии — пары строчек в одном файле хватило бы. Другие уязвимости остались бы, но не эта. А все уязвимости закрыть вроде невозможно — вроде как все современные методы аутентификации базируются на теории вероятности и комбинаторике, что не исключает «благоприятного» исхода при первом же испытании.
Доверять «авторизацию» по одной строке get — дилетантская ошибка, согласитесь. А взломать можно любую систему, любым алгоритмом, на крайний случай социальным (методы бывают разные — начиная от троянов секретарше, заканчивая силовыми) :)))
Не хватало только, чтобы авторизацию доверяли. Аутентификацию вот доверили и уже скандал, а прикиньте, если авторизацию? если Яндекс начнёт контент на сайте менять или сообщения пользователям рассылать? O_o
Называем вещи своими именами (назовите хоть х, как на заборе (хотя это ж не х, а забор)) — это и есть фактически частная авторизация, которую решили разработчики сделать через один get запрос.
Фактически это идентификация, а что разработчики решили на её основе проводить авторизацию…
Ну опять вы начинаете демагогию.
Пользователь получил «права», право на то, что он может проследить заказ, и только он и админы. Так как он получил какие-то права, значит он должен быть авторизирован, путь хоть временно, но авторизирован, а авторизация под собой подрузомевает, что? ;) Но уж не как по одному запросу get. Я написал про забор, как его не называй и что на нем не пиши — он забор.
>Я имею ввиду все проекты. Т.е. надо придерживаться норм (стандартов) безопастности, тогда не надо будет перекладывать с больной головы на здоровую

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

извините, я сейчас пьян, можете объяснить проще, что за зайню вы несете?

>Если бы не забывали изначально про принципы построения, то такой фигни бы не было.

да-да, а если при написании кода на сишечке не забывать про то, что на каждый malloc() должен быть свой free(), то больше половины дыр в софте вообще бы не было.

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

аутентификация гет-запосом — вынужденная мера, один из сайд-эффектов которой не был учтен. это выглядит глупо (как и большинство дыр) исключительно потому, что уже найдено.
> но мне кажется, что вы не понимаете, что такое разработка ПО
Ну да 20 лет стажа и университет по профилю, мало.
Не обижайтесь: по вашей пьяни — это вы сейчас не понимаете что несете ;)
> Как можно доверять пользователю только по одной ссылке? Почему забыли про куки?

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

вообще, я видел нескольких разработчиков 45+ лет. у всех 20 лет стажа, всё знают, цикл написать не могут и inner join от left join не отличают. но на словах-то все линусы торвальдсы, эрики липперты и гвидо ван россумы.
>вообще, я видел нескольких разработчиков 45+ лет.
Идиотов везде хватает и в 20 лет. Вы плохо думаете о разработчиках. Как раз архитектурное мышление приходит позднее.

>потому что ссылка из письма. ссылки из письма могут открываться на другом компьютере.

Причем здесь это ;)? Понятное дело могут, но в 90% открываются в том же браузере, а остальным 10% — пусть введут временный пароль (пока действует отслеживание заказа), который есть (разработчик должен об этом позаботиться) в письме.
Вы статью-то читали? ссылка принимается там, где авторизация недопустима.
применяется*
добавлю: какие здесь куки?
Можно ссылки на стандарты и спецификации, на которые наплевать разработчикам?
RFC 2616
15.1.3 Encoding Sensitive Information in URI's
Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead
Здесь же речь о формах. Подразумевается, что не стоит делать метод формы GET, если в ней передается номер кредитной карты :)
Это единственная придирка к букве текста, которую можно найти, да.
Общий же смысл написанного, заголовок и приведённые примеры говорят о передаче приватной информации в URI вообще, а не только через формы.
Так что подразумевается здесь совсем другое.
В приведенном отрывке речь идет исключительно о формах. Примеры не смотрел.
Написано же
Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties.
Да и раздел называется «Encoding Sensitive Information in URI's». Если кто-то использует HTTP на серверной стороне не прочитав описание, то ССЗБ, жаль, что страдают от этого пользователи.
Вырвано из контекста ;)

Если серьезно, на практике это работает следующим образом: аудитор смотрит логи веб-сервера и если не видит там критичных данных (обычно это действительно критичные данные, вроде номера карты, cvv кода, паспортных данных) — все окей. А попадетесь вы, скорее всего, когда будут тестировать на Broken Authentication and Session Management.
RFC 2616 не рекомендует (SHOULD NOT USE) передавать «чувствительные» данные в URI.
упс, не обновил
Также известный как robots.txt.
Достаточно сделать вывод информации о заказе, после ввода email клиента, например.
Согласен, но в данном случае мы решили сделать дополнительную идентификацию по фамилии клиента.
«Пароль» можно и в письме прислать. Тогда его совсем никто знать не будет.
Не поможет… не будем забывать на чьих серверах обрабатывается почта.
Кто сказал, что нельзя ссылки брать и из писем, раз уж они все равно парсятся для подбора релевантной рекламы.
Кто говорил что какие-либо ссылки берутся из писем??

Имеется ввиду следующее:

Ваш заказ номер 745867 успешно добавлен.
Используйте свой емаил idtyc@tufv.ru для входа и управления заказами.
Пароль для входа: 76fgtfiu7i7f6tgy (Вы можете его сменить через профиль)

примерно так…
Все гораздо-гораздо проще. Генирить номара заказов не по порядку и для просмотра статуса заказов использовать этот номер.

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

Как показывают последние скандалы — это не панацея.
Плюс не показывать завершенные заказы.

Не юзабельно — проверяю я статус заказа: «идёт», «идёт», «идёт», 404 нет такого заказа — и что мне думать?
> Как показывают последние скандалы — это не панацея.

Насколько я понимаю, последние скандалы показвают, что не разумно передавать идентификаторы пользователя в GET-параметрах. В моем случае, пользователь по ссыке из письма попадает на старницу с полем «Введите номер заказа» и post-формой.

> Не юзабельно.

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

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

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

Показывать всю приватную инфу чуваку, пришедшему по ссылке — это верх корявости.
Про пост-форму вы не упомянули, сорри.

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

My bad. :)

> Заходить смотреть не изменился ли статус заказа будет неудобно.

Ну, тут у каждого свой кейз. Сейчас, имхо, тренд на мобильные клиенты, и email-нотификации гораздо более оперативная и удобная штука. Чтобы никуда не ходить и не проверть по 10 раз изменился ли статус.

Но мой главный поинт был даже не в том. Сейчас все ругаются, одни обвиняют Яндекс, что проиндексировал через метрику, другие — владельцев магазина (robots.txt, etc). Мой поинт, что главный фейл — в том, что все эти приватные данные были доступны по ссылке (не важно насколько она супер-секретная), без какого-либо процесса аутентификации. Хоп и все! Тыкнул и читаешь.

Это и есть криворукость разработчиков движка. Как, в каком виде это реализовать — это другой вопрос. Тут можно сесть командой в переговорке и за 2 часа придумать красивое изящное решение. Или сделать несколько и давать на выбор. По-разному можно сделать. Но не так.

А яндекс на сам деле так или иначе проиндексировал _публичные_ ссылки. От того, что о них никто не знает, они публичными быть не перестают.
Это да, их фэйл. Но вот юридическую ответственность за то, что данные утекли несут всё же владельцы магазинов — пользователи пользовались их услугами и сообщали данные им, а не разработчикам. Владельцы сайтов могут попробовать обратиться к разработчикам с требованием возместить вред, включая недополученные доходы и урон деловой репутации, но сомневаюсь, что такое требование имеет судебную перспективу — наверняка «AS IS», «no warranty» и т. п.
Обычно в таких случаях просят ввести кодовое слово, может быть и ФИО. Ну нельзя чтобы без каких-либо ограничений открывалась страница с персональными данными просто при переходе по ссылке — это неправильно! Это нарушение любых понятий об ИБ.
как вариант можно сделать отправку пользователю на email ссылки с одноразовым токеном — он перешел 1 раз, авторизовался, смотрит свой заказ. если кто-то другой попробуйет перейти по той же ссылке — ему выдастся ошибка что токен уже использован.

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

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

У меня альтернативное предложение, как не сдавать роботам закрытые страницы, если нужно отдавать их без авторизации: подгружать «секретную часть» страницы ajax'ом. Роботы, по крайней мере яндекс и гугл, не запускают скрипты, поэтому такую подгрузку не увидят. И яндекс.бар не спалит.
Выход один — куки, или авторизироваться :)
>Роботы, по крайней мере яндекс и гугл, не запускают скрипты, поэтому такую подгрузку не увидят

да лаааадно, не запускают…
Неужто запускают? А я такой трюк с подгрузкой применял, страницы попали в индекс без подгружаемого блока — почему тогда?
Яндекс и гугл очень неплохо научили запускать ajax скрипты, причем сами.
У меня движок заточен под ajax запросы, но без дела я их не применяю, так вот google почему-то посчитал переменную в js var block как дополнительный параметр и сам вызвал все ссылки с этим параметром, логику я гугла конечно не понял, но у меня так вызываются ajax версии запросов, т.е. тот же url с параметром block. Откуда он это взял я так и не понял до сих пор. Но суть в том что он проиндексировал все блоки вызвав их ajax методом, даже каптчу проиндексировал :)
Мало того у меня все url вида /la-la-la (реальные сами понимаете /la/la/la так вот гугл выдрал из js переменную real_url, где я для js скриптов хранил реальныу пути и присвоил всем ссылкам такую вот фигню, соответсвенно проиндексировав их, хорошо не все я вовремя убрал переменные block и real_url. Но логику гугла до сих пор не понял. Я так понял они учат бот «инстинктивно» запускать и различать всякие там url и block, кстати на основе популярных cms.
НЛО прилетело и опубликовало эту надпись здесь
Поисковик не будет совать фамилию из кэша совать во все поля на индексируемых страницах, чтобы пройти дальше. И вообще, как уже здесь кто-то писал, это сделано чтобы защитить новых клиентов, а их фамилий ещё нет в кеше
НЛО прилетело и опубликовало эту надпись здесь
Что утекло — то утекло. Теперь нацелены силы на то, чтобы защитить новых. Со старыми будут разбираться другими методами: например, просить яндекс убрать из кеша данные
Сопутствующий вопрос — зачем на странице трекинга заказа показывать персональные данные получателя и содержимое заказа?
С этой страницы клиент может перейти к оплате заказа и получить данные об оплаты: например, распечатать счет или квитанцию. Эти действия предполагают вывод информации о клиенте и составе его заказа. Поэтому вся эти информация показывается. Это такой маленькие «личный кабинет», ограниченный всего одним заказом (так как пользователь не зарегистрирован с постоянным логином-паролем, других связанных данных у него нет — только заказ).
А еще можно показывать сокращенную фамилию и сокращенный адрес :) Как номера кредитных карт никогда не показывают на страницах полностью — наверняка уже давным-давно на грабли с утечками натыкались.
Вся ответственность, безусловно, лежит на разработчиках движка.
Дело тут не в поисковике, даже если он не должен был что-то-там индексировать. Проблема в том, что личные данные были в открытом доступе, авторизации не было предусмотрено.
Мы и не снимаем с себя ответственности. Конечно, следовало делать дополнительную идентификацию клиента (что и внедрили сегодня в виде патча), однако, стоит обратить внимание и на поведение Яндекса: на то, откуда он берет данные о таких приватных страницах и насколько легитимно их отправлять в общий индекс. На наш взгляд, эту практику необходимо менять, иначе подобные проблемы в рунете могут (и будут) происходить еще со многими сайтами и скриптами.
Не факт, что виновата Метрика. Вполне может быть виноват какой нибудь аддон|плагин к броузеру.

Но факт, что разработчики часто забывают про robots.txt. И про мета тег noindex.

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

Если сломается, то это уже будет не ваша вина. И будьте уверены Гуглу или Яндексу придется оплачивать приличные суммы если утечет приватная информация.
В действительности яндекс очень четко следует robots.txt и пока у нас нет в известности ни одного случая его нарушения. Так что действительно, попытка перекинуть все на Яндекс авторами движка как-то очень криво смотрится.

Неужели нельзя было добавить учитывающий это robots.txt в стандартную поставку? Я уверен что можно.
Неужели сейчас нельзя признать свою ошибку? Мне кажется, это тоже следовало бы сделать.
Более того, ваш скрипт мог бы отдавать:


Почему это не заложено в движке? Тоже кривая метрика виновата?
Не знаком с движком, но есть подозрение, что скрипт только выводит данные в шаблоны, созданные веб-мастерами/верстальщиками на основе шаблонизатора типа Smarty.
В таком случае помог бы robots.txt. Плюс в движке можно завести переменную, что страница приватная, по которой шаблон должен выводить этот мета-тег. Это в любом случае полезно, т.к. пользователи с барами, хромами и прочими троянами были есть и будут, и если не яндекс, так гугл, бинг или яху — все равно бы это сделал, т.к. давайте будем честными — авторы пренебрежительно относились к этой угрозе.
Если действительно используется шаблонизатор в режиме включения вывода движка в шаблон (я бы сделал так), а не наоборот, то ни один тег без явного указания в шаблоне не выведется. То есть угроза того, что данные «утекут» (будут проиндексированы честным поисковиком) мета-тегом в общем случае не устраняется — максимум в мануал можно включить рекомендацию этот тег ставить для таких страниц.
Мануал + robots.txt, не забывайте. robots.txt уже и так будет с головой, и если он будет идти в стандартной комплектации — его не забудут. Вообще не понимаю, почему это валят на вебмастера? Разве это не часть движка? В целой куче движков он идет уже готовый.
Это я просто забыл дописать, хотел, но забыл :) По-моему логическое следствие из того, что мета-тегом угроза не устраняется.
Хабрапарсер съел HTML:
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
Используйте псевдоэлементы <source></source> для предохранения блоков кода от поедения их парсером Хабрахабра.
Ошибка не в робот.txt она более глобальная, на уровне наплевательства на стандарты безопастности.
прекратите клеймить и нагнетать. проебали, пофиксили, бывает.

я вот сейчас подумал и вспомнил, что в одном проекте мы такой же способ применяли. потомучто это удобно. и ссылка там не может быть одноразовой. шо делать, повеситься?
Пофиксить! :)
Ну разработчик ошибку то не признал ;) И начинает отмазываться, а здесь не все великие программисты, начинают верить отмазкам, потом все это начинают рассказывать своим друзьям, потом ламерить и т.п. Вот к чему я.
Пусть напишет как вы сказали: мы прое… ли, бывает. Пофиксили.
Не вешаться не надо. Если вы делали проект на основе своего движка, совет: ни в коем случае не вешаться, и второй: ping-update (если интересно что это, могу написать в личку) прикрутить к движку.
Скажите пожалуйста, о каких стандартах вы говорите? Вы можете привести ссылку на какие-то материалы освещающие эти стандарты?
RFC 2616
Спасибо!
Из рекомендаций RFC по использованию протокола HTTP можно сделать два вывода:
1) В GET параметрах нельзя передавать частную и чувствительную информацию,
2) Программы которые раскрывают ссылки, которые не предназначены для публики, занимаются сливом персональных данных.

Согласны?
По-моему 2 противоречит 1. Раз нельзя в GET параметрах передавать ничего важного, значит в ссылке нет ничего важного и её можно публиковать.
В самой ссылке нет ничего важного, но на странице на которую она ведет — может быть важное. И если программа показывает содержимое страницы, не предназначенное для всех, потому что она смогла увидеть это содержимое, используя своих «жучков» — это слив. Помоему так.
А по-моему нет. То, что не предназначено для всех должно быть защищено аутентификацией и авторизацией. А раз показывается любому, знающему адрес, то эта информация считается (законом) общедоступной.
Согласно законодательству РФ:
1. К общедоступной информации относятся общеизвестные сведения и иная информация, доступ к которой не ограничен.


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

Остается вопрос — насколько это порядочно со стороны Яндекса, брать ссылки из всяких странных мест. Ведь не все знали, что их может найти поисковый бот — на сайте-то на них ссылки нет. Это похоже на то, как если бы кто-то копался в моей сумке, пока я отвернулся. Но это лично мое мнение, а не мнение общественности. А мнение общественности здесь как раз и имеет определяющее значение.
Вы ошибаетесь.
В самой ссылке есть важное.
Сама ссылка — это authentication credentials. Аналог логина и пароля.
Которые нельзя передавать ГЕТом.
> поведение Яндекса: на то, откуда он берет данные о таких приватных страницах и насколько легитимно их отправлять в общий индекс.

Чем страница /a/b/c отличается от страницы /d/e/f с точки зрения поискового бота? ничем. То, что страница /d/e/f приватная известно только вам
Что значит в открытом доступе? По сути, страница с персональными данными возвращается при предъявлении уникального хеша, известного только пользователю. Яндекс эти хэши тупо п*здит. Этот примерно то же самое, как если бы яндекс п*здил вводимые пароли и индексировал, например, почту.
Не забывайте, что это всего лишь бот. Он кушает всё, что ему дают.
О том и разговор, что адреса посещаемых сайтов, не говоря уже про передаваемые в адресной строке параметры — персональные данные. Яндекс как минимум не должен их публиковать, а по-хорошему не должен их вообще собирать. Тогда и вопроса о том, что именно нельзя индексировать не возникнет. Ещё раз, речь идёт о данных, получаемых яндексом с помощью клиентских скриптов и браузерных плагинов с компьютеров пользователей.
А каким образом бот должен понять что это персональная/приватная страница? Если она доступна простым запросом, если нет никаких метатегов, если нет информации в robots.txt?
Вопрос в том, кто скармливает ссылки боту?
Если он их находит на просторах интернета — это одно, а если он их получает из метрики, то тут пускай уж удосужится проверить ссылку на общедоступность (хотя бы просто поискав эту ссылку в своей же базе)
Если ссылки нет в базе, не значит, что она не общедоступна (инче новые ссылки в яндексе никогда не появлялись).
Вот именно. Боту дают ссылку из приватного имейла. Это нормально?
Не примерно. Как минимум общепринято («обычай делового оборота» — есть такой термин в юриспруденции), что секретные/конфиденциальные/персональные/личные/… данные не передаются в GET запросах по HTTP протоколу.
Увы, это не так. Ссылка с ключем авторизации в параметре это слишком удобно, чтобы от этого отказываться, и ее используют довольно многие (в том числе Мой Круг, кстати). Поэтому хорошо бы решить эту идеологическую проблему.
Сделать её одноразовой (МойКруг, кажется, именно так её использует)? Пока пользователь не перейдёт по ней в браузере о ней никто не узнает (кроме хакеров и индексаторов почты), а когда узнает, то смысла знать её уже не будет!
Надо посмотреть. А если пользователь захочет по ней пройтись дважды из своего письма?
В момент перехода выслать ему вторую уникальную ссылку.
Действительно, у МоегоКруга они одноразовые.

Ага, и забить ему почтовый ящик :)
В какой мемент перехода высылать вторую ссылку? В первый раз или каждый раз.
Как только одноразовая ссылка использована — высылать новую, если уж так не хочется аутентифицировать по кукам и/или паролю.
А при повторном обращении по уже использованной ссылке, что должно происходить?
Что делать, если отправленная новая ссылка не получена адресатом?
если отправленная новая ссылка не получена адресатом

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

при повторном обращении по уже использованной ссылке

выводить сообщение «ваша ссылка устарела, зайдите пожалуйста на почту и перейдите по новой».

Ну и в рамках одной сессии подразумевается что человек может кликать по «использованной» ссылке сколько влезет — она будет работать верно т.к. человек уже авторизован. Когда кончается сессия чтобы снова авторизоваться он переходит по новой ссылке.
>самыйпростой способ — телефон

Забавно, что это самы простой способ решения не только этой проблемы, но и вообще почти всех поднятых в этом топике.

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

То, что туда ходят краулеры — я сам прекрасно знаю, неоднократно наблюдал в логах своих веб-серверов — когда ссылки, которые упоминались только в почте, внезапно посещали клиенты с чудесными словами Yandex и Google в user-agent. На вопрос — попадали ли в итоге посещаемые страницы в публичный поисковый индекс — я пока ни однозначного утвердительного, ни однозначно опровергающего ответа не знаю.
Да найдены они могут быть где хочешь. Вопрос в том, что разработчики наплевали на нормы и стандарты безопасности, если бы они их соблюдали изначально, такого бы не было.
Вы уверены, что только в почте? Что пользователи (или вы) по этим ссылкам не переходили до их визита краулером?
URLы достаточно персонализированы. Пользователи — достаточно инертные работники бюджетных организаций, ходят с рабочих компьютеров в рабочее время.

Наблюдал развитие по примерно следующему сценарию:

  1. Письмо со ссылкой отправляется в ~20:00 MSD (нерабочее время рабочего дня)
  2. В ~23:00 MSD приходит робот
  3. В ~10:00 MSD следующего рабочего дня приходит легитимный пользователь — получатель этого письма и начинает свою сессию работы с системой
URL, насколько я мог проверить, в поисковый индекс так и не попал.
Это да, серьёзный повод задуматься. А почта была у одного почтовика?
Почта рассылалась автоматически из скрипта, запускаемого вечером по cron через собственный smtp-сервер. Адресатов порядка нескольких десятков, ссылки у каждого уникальные и персонализированные. Прямой корреляции типа «послал на gmail => придет Googlebot», «послал на yandex => придет Yandex» не строил, но подозреваю в первую очередь все-таки индексацию URL из почты.

Собственно, сейчас посмотрел на то, что выдает Google и Яндекс при поиске по обозначенному сайту, ситуация, прямо скажем, странная. Сайт состоит из:

  • одна страничка dashboard-style морды — доступна свободно, на ней список URL подсистем
  • n подсистем, каждая из которых закрыта авторизацией
  • открытая «публикующая» часть внутри каждой подсистемы, обеспечивающая отображение подготовленной в системе информации по ряду открытых URL — частично они рассылались упомянутым выше cronjob'ом

А интересно и странно то, что Google честно показывает для этого сайта в индексе только одну открытую морду, а Яндекс зачем-то и откуда-то заиндексировал еще 3-4 очень странных внутренних URL, причем отрубив у них query; для внешнего человека без авторизации они и так в любом случае нерабочие, но без query — они даже с авторизацией будут выдавать внутренние ошибки системы. Эти внутренние URL (особенно в таком обрезанном виде) вряд ли когда-либо пересылались через почту, зато вполне вероятно, что какой-то из пользователей имеет Яндекс.Бар.

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

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

Только куки или авторизация — это в принципе, то, основная концепция авторизации, но уж ни как не через get (а это именно в конкретном случае и была авторизация — будем называть вещи своими именами) запрос (ну просто детская ошибка).

И не надо делать вид разработчикам что они здесь не при чем, всё они знают как лоханулись, только надож хоть немного «кармы» продукта сохранить, только вот на карму хабра можно наплевать, а вот от «кармы» продукта зависит фактически жизнь компании. Поэтому и не признают, и не признают. Но для специалистов — виновник известен, рассказывайте басни дальше и другим.
Я имел в виду «условно одноразовые»: приходит пользователь с кукой — даём ему доступ один раз. Приходит без куки (или второй раз?) — даём 401 (403?) и просим пароль, высланный в том же письме, что и ссылка. Где-то в комментах расписывал подробнее.
Достаточно привязать первый запрос к ip пользователя.
Так не надо делать, на одном ip могут сидеть тысячи пользователей :) куки и еще раз куки
У меня динамический IP от нескольких мобильных провайдеров, а статический расшарен чуть ли не со всем районом (НАТ).
И как это помешает Вашей анонимности в поисковиках при получении Вами ссылки?
У яндексбота другой IP :)
Ну а если бояться сниффинга — тут поможет только SSL
При использовании мобильного провайдера я сам не смогу перейти второй раз по ссылке (айпи будет уже другой), а при использовании стационарного по ней сможет зайти любой человек с района.
Одно дело прикрывать ключиком фоточки, другое дело прикрывать, таким вот ключиком, личные данные, включая полное имя/отчество, мыло и адрес доставки!
Тот же амазон 10 раз переспросит логин пароль, пока я доберусь до смены адреса.
Я вижу как вариант для интернет-магазинов предлагать указывать не фамилию, а псевдоним. Данные сразу перестают быть персональными.
Посылку отправляют на адрес и выдают по паспорту…
Круто, а, то что любой провайдер/снифер/проксисервер/другое так же спокойно как и яндекс могут парсить эти get запросы, создателей движка не должно волновать?
Вы так говорите, что все, что находится в интернете, должно передаваться только безопасным путем. А как быть с людьми, которые работают в небезопасной Wifi и кто-то начнет собирать пароли и индексировать, что находится внутри. Или при аутентификации открытым токеном, который передается в HTTP Property. А уникально сгенерированный ключ в запросе слабая, но все-таки защищенная ссылка.

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

Ключевое слово «позволяет расшарить».
Кстати да, Гугл документы расшариваются по ссылке. (если вноват яндекс бар или другой плагин) Похоже можно пробовать искать в Яндексе и эти приватные документы.
Долгое время механизм уникального урл, известного только пользователю, де-факто являлся авторизацией. Создав Метрики, Бары и т.п., поисковые системы поломали этот механизм. Механизм, который используется везде.
Конечно, Яндекс может прикрыться законом о персональных данных и сказать — «теперь защита от нашего бота — это ваша проблема», но очевидно, что данную ситуацию Яндекс просто проворонил.
Я согласен насчет robots.txt: поисковым системам он не указ и на половину параметров в нем они просто плюют.
Вы счас это серьезно про механизм, который используется *везде*?
/me Взглянул на дату; нет, не `96-й на дворе…
Расшаривание ссылки гуглом — отдельная история, она, во-первых, передается человеку лично (по емэйлу, Im и т.д), во-вторых, предполагается, что она выдается на короткое время.
К слову, даже в древние времена де-факто авторизацией являлась Basic Auth, описанная в rfc1945.
Да, и яндекс предоставляет свой сервис бесплатно, а в условиях использования ясно сказано:
Пункт 11. Пользователь понимает и соглашается с тем, что счётчик, установленный на сайте Пользователя, собирает анонимные данные [...] и в автоматическом режиме передаёт их Яндексу [...] доступной для дальнейшего использования с помощью Сервиса как Пользователю, так и Яндексу.
Именно используется. Именно везде. В условиях, когда магазины борются за клиентов, в приоритете всегда будет максимально простой сервис.
собирает анонимные данные

«Вы счас это серьезно про» «анонимные данные»?
расскажите-ка, как робот должен отличать «анонимные» get-параметры от «неанонимных»?
Спросите об этом людей, персональные данные которых скриптами скопировали все, кому не лень.
Скопировали, потому что кто-то за этих людей (или, по некоторым данным, они же и сами) явно решил следить за этими людьми посредством счётчиков и плагинов.
Кстати, я смотрю на проблему несколько шире. Роботы роботами, а за выдачу Яндекс все-таки должен отвечать, как ни крути.
За всех говнокодеров никто ответить не в состоянии, кроме их самих. Может хоть уволят кого…
Это им удалось проигнорировать элементарные правила безопасности, robots.txt и свойство ut:'noindex' специально для метрики, куда уж тут шире смотреть?
За что увольнять-то?!
Это все местечковые «правила безопасности». Google noindex не учитывает, Яндекс начал учитывать nofollow только недавно, а завтра возьмет, и опять перестанет. Появится другая ПС — вообще на все наплюет. То, что в robots.txt учитываются не все директивы, похоже, неизвестно только вам. Т.е. robots.txt изначально учитывается частично. Все подобные меры просто смехотворны.
Да, согласен, смехотворны, но это были бы хоть какие-то попытки что-то прикрыть.
А вообще, ниже много на эту тему написано, можно толкать куку, которая бы аутентифицировала по ссылке.
Без куки был бы виден только статус заказа и список товаров, с кукой — фио, адрес, контакты, и прочее, что сейчас выставлено всем на обозрение.
Да, можно было бы сделать много чего. Только когда придумывали механизм уникального урла, никому и в голову не могло прийти, что вебмастера будут добровольно ставить на сайты троянов. :)
Вы представляете себе, сколько сайтов сейчас нужно переделывать? Т.е. сколько народу Яндекс и другие гипотетически поставили на деньги?
да кто вообще суёт в УРЛ хеши????
какой век на дворе???
Какие деньги? Три-четыре (ну всяк не больше десятка) строчки на PHP и одну колонку в БД добавить, чтобы закрыть свою безалаберность и, извиняюсь, похуизм к отношению персональным данным клиента?
Что значит троянов, не пойму? Никто не скрывал, что метрика индексирует страницы, для этого есть параметр, предотвращающий это.
Ну да, куча народу, а что делать? Или «миллионы мух не могут ошибаться»? )
Общеизвестно, что в этой стране любят заказать магазин за 15к руб., а потом жаловаться что «ниработаит», ну сами виноваты, че.
Я за 2к рублей делаю магазины с роботс.ткст.
Буду рекомендовать вас ))
Без дизайна и вёрстки, только вёрстку на движок натянуть :)
Без куки нужно просить пароль, высланный в том же письме, что и ссылка. Сам факт, что сделан заказ (а тем более список товаров) может быть неприятен клиенту, если о нём узнают третьи (особенно близкие) лица, даже если клиент почистит куки.
как не крути — эта информация была доступна всем людям в сети…
ещё чуть шире, попробуйте, поразмышлять
Вы вообще о чем?
Доступна всем, когда Яндекс сделал ее доступной всем?
До этого она была доступна только клиенту, получившему ссылку.
Почему Вы забываете о возможности просмотра «HTTP referer»???
Или этого мало???
Она была доступна до этого любому, «догадавшемуся» набрать нужный урл. Среди «догадавшихся»: правоохранительные органы, сотрудники провайдеров многих уровней, сотрудники администрации прокси-серверов, сотрудники создателей браузеров и, главное, расширений (добровольно установленных пользователем) к ним, сотрудники сайта, а также «тупым» брутфорсерам или просто людям, которым сопутствует удача. В стандарте http написано — нефиг передавать «чувствительные» данные гет-запросом — их пишут (а занчит и могут прочитать) все кому не лень!
Есть три основных понятия в данной сфере: идентификация, аутентификация и авторизация. Первое, грубо говоря, является процессом представления клиентом серверу «Я такой-то» (логин, ник, ФИО и т. п.). Второе — то же плюс доказательство, что клиент действительно «такой-то» (пароль, сертификат и т. д.). Третье — проверка сервером, что представившийся клиент (идентифицированный или аутентифицированный) имеет право на то действие, что запросил. Согласно духу и букве RFC 2616 аутенфицирующая (как и любая другая «чувствительная» ) информация не должна передаваться в GET-запросах
Authors of services which use the HTTP protocol SHOULD NOT use GET
based forms for the submission of sensitive data, because this will
cause this data to be encoded in the Request-URI. Many existing
servers, proxies, and user agents will log the request URI in some
place where it might be visible to third parties. Servers can use
POST-based form submission instead.
> данные были в открытом доступе, авторизации не было предусмотрено.

Ну, секретный URL тоже ведь можно считать своего рода паролем…
Не нужно — прочтите цитату из RFC в моём комменте выше вашего.
У Яндекса — Метрика, а у Гугля — что?
Об этом написано поста:

3. Яндекс проиндексировал именно такие страницы. Точнее, страницы, которые посещали покупатели (переходили по ссылкам из писем-уведомлений).
4. Гугл и другие поисковики проиндексировали эти же страницы уже после того, как информация об этом появилась в новостных лентах, на Хабре и стала «достоянием общественности».
Вообще-то у Google есть аналог Метрики — Гугл Аналитика. Хотя о ней речь в данном ключе ни разу не заходила, возможно, сделали ее по уму.
Скорее метрика — аналог аналитикса.
С блэкджеком и индексацией писем.
Да не писем, что вы все к письмам привязались, метрика была установлена на странице куда вела ссылка из письма, и при загрузке этой страницы вместе с загрузкой метрики, она (метрика) выдавала яндексу «ололо, меня загрузили с такого-то адреса». Письма здесь вообще не причем.
Вот только в трекинге не отображается адрес получателя и содержимое его отправления.
Суммируя: разработчики скрипта обвиняют Яндекс, Яндекс обвиняет создателей сайтов, те, кто поумнее, обвиняют оленей-веб-мастеров, веб-мастера молчат в тряпочку, прочие журналисты просто пишут «Ололошеьки Яндекс слил вашу приватную информацию».
Единственное, чего я не понимаю в данной ситуации — это что такое «Смазка с эффектом «Узкий вход».
Мы не обвиняем Яндекс — мы обращаем внимание на вопрос этичности и легитимности добавления любых адресов, которые нашел Яндекс с помощью своих сервисов, в общий публичный индекс.
а что Яндексу посадить миллион негров и азиатов и пусть они ручками каждый линк проверяют, что ли? Яндекс сделал то, что должне был сделать. Нашел ЛЮБУЮ ИНФУ, которая была в ОТКРЫТОМ доступе.
Вопрос этичности к вам, товарищи разрабы.
Так в том и дело, что в данном случае доступ НЕ открытый.
открытость в инете априори. все что не скрыто, кушается ботами.
Боты кушают все, некоторые из них подбирают пароли и создают ботнеты, пользуясь принципом, что ненадежно защитили — ваши проблемы.
Угу, Вы пошли в лес голышом, даже без трусов, по-вашему, то, что Вас искусали комары и за причинное место клещ вцепился это вина комаров и клещей? А вот и нет: нехуй нудизмом заниматься в лесу полном кровососов.
Или, ходя бы, репеллентом не помазаться (роботс.ткст не прописать нормально).
Вот, наконец, и вывод дискуссии: поисковые машины — кровососы, паразиты и хищники? Яндексов бояться — в Сеть не ходить :)

Всё таки Яндекс в данной истории стащил URL НЕ СО СТРАНИЦЫ В ИНТЕРНЕТЕ, а скриптом на странице стащил адрес страницы или яндекс.бар'ом в браузере стащил адрес посещаемой страницы. В первом случае он без ведома пользователя запущенным у пользователя скриптом стащил приватные данные, во втором — вроде как с ведома (пользователь сам установил бар), но все равно приватные.

Если Яндекс в этой истории будет оправдан, то в будущем писатели кейлоггеров будут иметь прецедент-отмазку «а нефиг было пароль на клавиатуре набирать, она в открытом доступе (моему шпиону)». Может Яндекс.Бар кроме урлов и пароли сливает? Где его исходники? И что, он потом скажет, что надо было в robots.txt написать «яндекс, не используй мой пароль»?

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

Только кейлогерам нужно будет при инсталляции «заставить» пользователя принять EULA с пунктом типа: «все нажатия клавиш передаются на сервер Авторов и могут быть использованы ими по своему усмотрению».
Да ладно, яндекс бар сплошь и рядом ставиться даже без уведомления об его установке.
Не знаю, не встречал, а когда попытался поставить, то браузер сообщил что это расширение хочет иметь доступ к данным на всех сайтах, истории и закладкам. После чего было послано.
Ага, ну-ну. «Мы шли мимо, дверь открыта была, ну подёргали, открылаксь, зашли и начали выносить всё, ну а что добру пропадать, на предметах же не было табличек „Собственность Пети“ — значит ничьё»…

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

Если этот ключевойURL был в открытом доступе — то пусть Яндекс в свою защиту приведёт URL страницы, на которой он увидел этот «открытодоступный» ключевойURL! Тогда все претензии к Яндексу снимаются, и виновными остаются авторы шопа в одиночку.
Ну никак он не мог быть только там. Прежде всего он был сгенерирован на сервере, потом был передан по открытым каналам открытым текстом, никаких мер для его сокрытия не предпринималось, что по сути означает, имхо, что данная информация не относится к информации с ограниченным доступом или конфиденциальной. А даже если относится, то согласно нормам права конфиденциальную информацию владельцев сайта (ссылка никак пользователю принадлежать не может, это владельцы сайта ему её сообщают) разгласил либо пользователь, выполнив у себя программу «Яндекс.Бар», либо сам владелец сайта, «заставив» пользователя выполнить программу «Яндекс.Метрика».
Мы не знаем, по какому каналу пришло письмо тем пользователям. Вполне возможно, что на MX оно пришло по SMTP со STARTTLS (на своём сервере вижу, что многие отправители его используют, т.к. видят анонс его поддержки в EHLO), и с большой вероятностью пользователь прочел его по httpS или imapS. Т.е. нигде от очереди исходящих на почтовом сервере шопа и до почтовой программы у пользователя открытым текстом оно не шло.

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

Более развернутая аналогия с изъятием материальных ценностей, с учетом общего тренда комментариев:

Так как в день получки, когда Петя нёс зарплату домой, у Пети при себе не было в нагрудном кармане бумажки с надписью:
жуликос.txt

на которой было бы написано:
жулики *
карманы не выворачивать /

то мы вывернули карманы и забрали всё, что упало, и, согласно общепринятым поговоркам — пропало (а раз пропало — то уже не принадлежало Пете).

А Петя сам виноват — он когда входил в переулок, читал соглашение, и принял его, соглашение висит на 4-м фонарном столбе перед переулком и пункт 5.1 его гласит:
Вошедший полностью и безоговорочно соглашается с тем, что лица, стоящие в переулке, имеют права вывернуть карманы, если нет записки с содержанием…
Не путайте ситуации, когда мы в наглую вывернули карманы пиджака на Пете (ст. 161 УК РФ, а если угрожали оружием или насилием — ст. 162 УК РФ) и когда мы вывернули карманы на пиджаке, брошенном Петей (ст. 226 ГК РФ).
Здесь именно вывернули карманы пиджака (браузера) на Пете (компьютере пользователя). Никуда этот секретный URL не падал — ни на какой открытый сайт его авторы шопа не выкладывали. Яндекс стащил его из браузера пользователя — кармана на живом Пете. Без угрозы насилием, конечно, а незаметно для него. Какая там статья для карманных воров?
Урл принадлежит владельцам сайтов. Либо они сами согласились передать его Яндексу, установив Яндекс.Метрику. Либо их клиенты передали их Яндексу, установив Яндекс.Бар.
А соглашались ли они где-нибудь явно на индексацию/публикацию этих URL'ов (частной информации, принадлежавшей владельцам сайтов, открытой ими только пользователям)? Тут противоречие и упоминаемому Вами ФЗ.
Вот-вот. Поисковики работают на правовом минном поле.
Ох. Вот представим себе: я родом из ЮАР, из какого-нибудь дикого племени. В моем племени убивать людей — не является чем-то плохим. Волею судеб, я попал в Россию. Читать вообще не умею (из дикого племени же). Соответственно, что такое УК РФ — понятия не имею, что это уголовно (щито O_o, для вождя-то?) наказуемо — так же.
Прибил я на улице табельным томагавком прохожего. Через 5 минут меня схватили полицейские, и пытаются посадить на 10 лет.
А теперь проведем аналогию с 4-м фонарным столбом — ведь то же самое, получается?
Не знание закона не освобождает от ответственности. Любые спорные моменты (применительно к данной ситуации) описаны в пользовательском соглашении. Почему же паника-то?
Хоть убейте, не понимаю.
Нет, здесь вопрос в том, что почему яндекс добавляет в индекс все страницы с метрикой, а гугл adwords — нет?
adwords и метрика разные вещи. Учите матчасть!
ок — analytics.
вообще вопрос чисто гипотетический, а как вы точно знаете что виновата метрика, что она собирает такие данные?
Ну по-моему статья как раз об этом. Паук ходит по ссылкам. Если страница unreachable пауком, то вариантов попадания немного — webmaster tools (ну или что там у яндекса) плюс скрипты трэкинга, которые сообщают адрес недостижимой страницы.
так ссылки эти нужно исключить путем nofollow и robots.txt
Все просто! Разрабы в этом случае виноваты, но все наезжают на ПС
Да как раз это не так. Во-первых, robots.txt — это рекомендация. Она не является никаким стандартом или еще что. Более того, любой может прийти и скачать этот robots.txt, провести анализ и сделать выводы, мол вот тут будут лежать вкусности.

Потом, очень интересно, что в правилах Яндекс.Метрике:
Яндекс не размещает такие записи Сессий Посещений в открытом доступе и не предоставляет такие записи Сессий посещений третьим лицам, за исключением тех, доступ которым к таким записям Пользователь предоставил самостоятельно.


Т.е. как бы странновато получается — вроде как в открытом доступе не выставлены, доступ сам не предоставлял, просто сессию записал с содержимым страницы — а тут нате — все в паблике. WTF?
Сессию он не записывал — он сам зашёл по урлу и сайт открыл (скорее попытался открыть) боту Яндекса новую сессию.
Так а урл-то он откуда взял?
Какая разница? Сессию он не размещал? Не размещал. Её запись предоставлял? Не предоставлял. Он в открытом доступе показывает адрес по которому пользователь может начать свою сессию.
Разница принципиальная. Все те секретные URL'ы, по которым прошелся Яндекс НЕ БЫЛИ в публичном доступе (или где тот сайт, откуда он их взял?).

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

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

P.S. От того, что понижением кармы вы не даете мне отвечать чаще 5 минут, моё мнение не изменится :) Приводите более убедительные аргументы.
Полностью согласен. Яндекс просто взял ПРИВАТНУЮ ссылку из адресной строки броузера (через бар или метрику).
Некоторые пишут, что аутентификация должна быть не по GET, но сие есть полный бред. В будущем никто не помешает тому же скрипту метрики слить Ваш пароль, который вы вводите в форму авторизации. По сути бар.метрика — это трояны, которые кроме выполнения своих основных функций еще и сливают приватную информацию.

В связи с этим еще весной начали переходить на Piwik для сбора статистики по своим проектам. Доверять это стороннему сервису может быть очень опасно!
Я с вами согласен. Поисковик использовал средства, которые не являются нормальными для сбора урлов. Это больше похоже на шпионаж.
Можете процитировать пункт соглашения, согласно которому вы их передаёте исключительно для подсчёта статистики?

Минусую комменты я крайне редко, если только там открытые оскорбления, а карму, кажется, никогда.
Могу: «Яндекс не размещает такие записи Сессий Посещений в открытом доступе и не предоставляет такие записи Сессий посещений третьим лицам»
Ссылка != Сессия
Ну как же — если покупатель посетил одну страницу с данными о заказе, то вся его сессия из этой ссылки и состоит. И см. ниже, там яндекс указывает, что адрес страницы (т.е. ссылка) тоже персональная информация.
Эта сессия состоит из запроса и ответа. Адрес лишь часть запроса и не может быть назван сессией целиком.
Ну тогда тем более :-) этот пункт запрещает размещение в открытом доступе не только адресов страниц, но и самих страниц :) Значит яндекс даже дважды виноват.
Яндекс страницы с сессиями не размещает, он размещает страницы, которые сам получил
Прочтите указанное соглашение еще раз. Сессией там считаются адреса страниц, посещенных пользователями. Он эти адреса добавляет в индекс, хотя пишет, что не будет.
И еще, в тексте соглашения ссылка на политику конфиденциальности, в которой к персональным данным яндекс относит в частности: «1.1.2 Данные, которые автоматически передаются Сервисам Яндекса в процессе их использования с помощью установленного на устройстве пользователя программного обеспечения, в том числе IP-адрес, информация из cookie, информация о браузере пользователя (или иной программе, с помощью которой осуществляется доступ к Сервисам), время доступа, адрес запрашиваемой страницы
Пользователь понимает и соглашается с тем, что счётчик, установленный на сайте Пользователя, собирает анонимные (без привязки к персональным данным посетителей сайта) данные о посещениях сайта Пользователя и в автоматическом режиме передаёт их Яндексу для получения обобщённой статистической информации, доступной для дальнейшего использования с помощью Сервиса как Пользователю, так и Яндексу.

Фактически это явное разрешение веб-мастером Яндексу использовать анонимные данные о посещения сайта, в том числе индексировать посещенные страницы.
Ничуть. Явно написано, что для статистики. Никакого индекса, никакой публикации не подразумевается. Под Яндексом здесь имеется в виду не поисковик, а сторона договора, т.е. мою статистику могут смотреть сотрудники яндекса и я. Всё. Никакой сдачи никуда не предусмотрено, что явно указано в политике конфиденциальности.
Как использовать статистику вы Яндекс не ограничиваете. Сотрудники Яндекса смотрят статистику и адреса из неё вбивают в «адд урл». Использование? Использование. Запрещено такое использование соглашением? Нет! Используются персональные данные? Нет! Используются данные статистики: «на сайте 100500 таких-то урлов, 500 таких-то из них посещаются часто, т. к. есть в индексе, а вот 100 000 — по одному разу, добавим-ка мы их в индекс, сделаем вебмастеру приятное, тем более они точно не секретные раз в роботс не запрещены». Соглашением это не запрещено, персональными данными не пахнет
В соглашении о конфиденциальности Яндекс отнес адрес страницы к персональным данным.
И наконец: «данные о посещениях сайта Пользователя и в автоматическом режиме передаёт их Яндексу для получения обобщённой статистической информации, доступной для дальнейшего использования с помощью Сервиса как Пользователю, так и Яндексу.»

Посетители поиска не являются ни Пользователем (вебмастером, установившим Метрику), ни Яндексом.
Яндекс использует анонимную статистику о посещениях страниц для предоставления услуг посетителям своего поиска. По-моему, он вправе это делать, в соглашении варианты использования не ограничиваются.
А о разрешении индексации посещенных страниц по-прежнему ничего. Разрешение дается только на статистику.
Вы можете запретить поисковику индексировать какие-то страницы, указав их роботс, баня по юзер-агент или айпи и т. п. Разрешения вашего для посещения общедоступного урла им не нужно — всё что не запрещено, то разрешено. А статическую базу урлов вы сами разрешили им собирать.
Метрика — не поисковик. С поисковиком отдельные отношения с другим соглашением и другими урлами — sitemap и т.п.
О, пока мы тут спорим, Яндекс уже решил исправить Метрику (приравняв её к Яндекс.Бару, который по их уверению ссылки не палит) — webmaster.ya.ru/replies.xml?item_no=11122

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

В общем, вопрос исчерпан, Яндекс исправился, магазины тоже исправляются, пользователи могут спать спокойнее :)
к тому же adwords имеет трэкинг целей, так что его тоже можно туда отнести, так как устанавливается он как раз там где достигается цель, что может быть страницой с результатом заказа и приватной инфой
Если уж сравнивать, то с Google Analitycs…
Адреса доступны публично? Все, что вы делаете доступным любому человеку, доступно и Яндексу. Ведь так? Или у вас приняты двойные стандарты?
Защитить данные пользователей — ваша забота. Сделать хороший поиск — забота Яндекса.
Вы (или админы сайтов) когда ставили метрику соглашались с лицензионным соглашением? Соглашались. Какие потом вопросы-то?
> Все, что вы делаете доступным любому человеку, доступно и Яндексу. Ведь так?

Если ЛЮБОМУ, то так. Но шоп выслал секретный URL (как если бы выслал пароль) ОДНОМУ человеку, ни на какой сайт «для всех» этот URL не помещал, а без этого никто бы его «случайно» не подобрал. Т.е. фактически никакого отличия от пароля. И Яндекс, взяв этот URL из адресной строки пользовательского браузера (а не с открытого сайта) выдал его всем.

Точно также он может стащить на пользовательском браузере (яндекс.баром) и параметры POST-запросов, и пароли. И стащит когда-нибудь, если его на первых кражах не остановить.
Что такое «секретный URL», в каком стандарте обозначено такое понятие?
URL не может быть секретным, URL не является объектом авторского права, URL не является персональными данными. Равно как и любой другой (IP, адрес дома и др.) адрес.
Исходить нужно их этих предпосылок.
Все, что прислано мне на email (и больше никуда) являются моими секретными персональными данными. Почтовый клиент тоже мог бы выдавать мои письма яндексу «для более полной индексации», однако он этого не делает. С какой стати мои URL'ы имеют какой-то пониженный приоритет в сравнении с другими словами из той же почты?

Пусть яндекс индексирует то, что его паук найдет по ссылкам на других сайтах. А то, что выдаётся Метрике — выдается только для статистики, доступной только владельцу сайта (такую же статистику он мог бы и из своих секретных логов сервера собирать), а не для индексации и публичного показа.
Еще раз — URL не может быть секретным, просто по определению. И понятия «мои URL» в RFC тоже нет.

Все методы авторизации по ссылке в письме основаны на предположении, что адрес это ссылки не знает никто, кроме получателя письма. Это предположение неверно, можно сказать — defected by design. Что в итоге и показали нам поисковики.

Впрочем при уточнениях «ссылка действует в течении X времени» и «ссылка действует только один раз» система авторизации получается достаточно надежно, но кто знает…
Вы как-то однобоко смотрите на проблему. Давайте на секуду представим, что Яндекс бы вдруг признал свою вину и резко отказался от индексации страниц, поступивших через метрику/бар. А разработчики Shop-Script не писали бы патч, закрывающий страницу заказа хотя бы на фамилию.

Мы бы тогда имели:
1) Отсутвие в выдаче Яндекса страниц с заказами в будущем
2) Знание, что есть некий урл, при переходе на который я получаю некие персональные данные.

Что остановит плохих дядек имея знание о втором пунке от написания своих ботов/пауков, которым глубоко класть как на robots.txt, так и на этику как таковую.

Вам бы понравилась такая ситуация?
1) и нечего им делать в яндексе
2) Каким образом (кроме перебора) плохие дяденьки получат этот самый «секретный» урл? Вот у яндекса таких способа целых два — бар и метрика.
По сути форма авторизации — это тот же самый секретный урл, и передана она по POST или GET для желающих получить Вашу информацию не так уж важно.
2) Прокси/снифер/открытый Wifi, можно еще пяток способов придумать, передавать личные данные пользователя в открытом виде, плохой тон, а передавать их в get запросе это вообще верх маразма.
«Прокси/снифер/открытый Wif» таким же способом может и пароль скушать, особой разницы post или get здесь нет.
Никто не говорит, что разработчик молодец. Но яндекс эту ссылку УКРАЛ и выложил в паблик.
Каким же интересно образом яндекс УКРАЛ ссылки?:) Веб мастера сами их отдали яндексу, или вы утверждаете, что по подобным ссылкам никто и никогда не вешает другие счетчики? Эти ссылки принесли яндексу на блюдечке с голубой каемочкой, а потом кричат что яндекс их украл :) Классно.

Я вообще не могу себе представить как кому то в голову пришло держать личные данные пользователей в открытом доступе, без банальных методов аундификации, хотя бы как здесь по фамилии, имени, полу, году рождения етк… это вообще не должно укладываться в голове у любого нормального итишника.
Если в соглашении явно написано о том, что все ссылки индексируется, вопросов нет. Но я такого пункта там не нашел.
А там явно написано, что она не будет индексироваться? Передача любого адреса (в том числе урла) предполагает, что по этому адресу тот, кому его передали, может спокойно обратиться: ответят-не ответят, пустят-не пустят, пошлют-не пошлют, выдадут 200 и инфу или 401/403 и предложение аутентифицироваться — дело владельца даже не адреса (адрес это чистой воды информация), а ресурса, на который этот адрес указывает.
А вот это уже довольно скользкий момент. Через прокси сервера тоже проходят кучи урлов…
В том числе и поэтому не рекомендуется передавать секретные данные в GET запросах.
Простите, а какой закон или моральный принцип нарушат держатели прокси если пройдут по любому из урлов прошедших через их прокси, без учета личностей предыдущих? Если ссылка открыта, то значит скрывать там нечего.
И если POST форма засабмичена не по https протоколу, то тоже скрывать нечего? )
Хех, если веб мастер отдает эти пост запросы на анализ в гугл/яндекс, то видимо нечего.

RFC не рекомендует передавать «чувствительные» данные через GET-формы.
Я в прошлом топике описывал метод компроментаци таких урлов через referer.
Например, вам на почту пришла секретная ссылка, по которой вы можете посмотреть список заказов. Вы заходите в список заказов и оттуда переходите на страницу какой-нибудь заказанной вами вещи. Вполне реальная ситуация, правильно?

Теперь все скрипты на этой странице (товара) знают вашу секретную ссылку через document.referer. Думаю не надо объяснять что кроме метрики часто владельцы магазинов вставляют еще разные скрипты от рекламодателей и т. д.

Кто будет гарантировать что рекламодатель не плохой дядька который купил рекламу только ради того чтобы тырить секретные урлы пользователей сервиса?
Далеко не все магазины вешают на такие страницы баннеры и прочие внешние скрипты. И если таковых нет, то сам механизм «секретной» ссылки безопасен (приведите пример компроментации, если не согласны с этим аргументом). Но скрипт на странице был и им оказалась Яндекс метрика.

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

С этим не согласен — на страницы товара и другие страницы сайта всякие баннеры вешают довольно часто.

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

Разработчики шопа тоже виноваты, конечно, но это не отменяет вины Яндекса, спалившего урлы, которые были предназначены для статистики, а не для индексации и публикации.
Да и вообще, я думаю, что будь такое в Америке, там бы уже гугл местный бы последние портки бы продавал чтобы выплаты по искам раздать
Там владельцы сайтов бы последнее продавали…
По крайней мере, «гугл местный» постарался бы избавиться от персональных данных в своей базе. Какой скандал поднялся, когда обнаружилось, что Гугл собирает данные по открытым (!) точкам вай-фая с помощью своих гугломобилей. И гугл пообещал так больше не делать и удалить собранные персональные данные.
А Яндекс может себе позволить посмеиваться — «обнаружили, что можно искать» — над глупыми людишками, у которых персональные данные оказались в публичном доступе.
Две ситуации: персональные данные в общем доступе. Два подхода: этичный и неэтичный.
Афаик, они быстро удалили из выдачи мегафоновские СМС
единственный нормальный вопрос за весь топик. сразу видно что вы детально проработали ситуацию.
специально для глубоко вдумчивых профессионалов отвечаю на ваш вопрос:
сужающие смазки -это такие которые повышают трению и способствуют сужению пилотного входа так сказать путем стимулирования оттока крови от наружнго шлюза…

и не спрашивайте откуда я это знаю.
Учтемс…
А почему вы куки какие-нибудь особые не можете класть клиенту, когда он оформляет заказ, а потом, когда приходит по get-запросу на сайт, проверять их? Конечно, он может зайти из другого браузера/компьютера, и вот тогда вы можете просить вбить пароль/фамилию/и тп. То есть в типичном случае пользователю не придется ничего вводить.

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

Если яндекс зайдет на mysexshop.com/?token=dsdskfljsdklfjlksdfjlksd&visit=/order/4222, то скрипт его не авторизует, и не редиректит на mysexshop.com/order/4222.

Но если яндекс зайдет на mysexshop.com/order/4222, то сможет ее проиндексировать.

То есть авторизация обязательно должна быть на финальной странице. А на промежуточной должно происходить нечто, что позволит отличить человека от поисковой машины (отработка js, например).
> нечто, что позволит отличить человека от поисковой машины (отработка js, например).

Или капча… у которой к всеобщему горю может снова вырасти популярность. Теперь для борьбы с поисковиками.
Пропустил ваш комментрарий. Сразу пришла та же мысль на счёт кук. C javascirpt — хорошая идея.

Разработчики Shop-script, примите во внимание.
Проще (и надёжнее) отправлять на страницу с формой из одной кнопки «Нажмите эту кнопку, если вы не поисковый робот», отправляющей POST-запрос. Их поисковики не отрабатывают, насколько мне известно.
Им ничто не запрещает их начать обрабатывать. А вот Meta robots и robots.txt — вполне проверенные решения.
В принципе им также ничто не мешает игнорировать мета и роботс…
Для чего? У Яндекса нет цели выведать какой фаллоимитатор вы купили накануне, его цель — предсотавить максимально широкий и релевантный поиск. Если страница не должна находиться в поиске, то нет резона ее туда включать.
Мне казалось цель Яндекса (как и любого ООО) — зарабатывать деньги :)
Да. Только если яндекс начнет обрабатывать все подряд, не учитывая robots.txt и прочие способы указать, что индексировать, а что нет, то его сервисами — метрикой, яндекс баром, и прочим перестанут пользоваться, и яндекс начнет эти деньги терять. И авторитет он тоже начнет терять. А он еще на IPO вышел, акции же могут падать.
Вот потому он не будет обрабатывать и пост-запросы своим баром, хотя возможность, вроде бы, есть, даже по https.
Так как он встроен в браузер, конечно есть возможность.
И кстати говоря, способов запретить считывать определенные страницы куча. Например выдавать обфусцированный код, который будет собираться JavaScript'ом, использовать капчу, делать проверки, бот это или нет. После перехода по ссылке ставить куку(бот куки не принимает и не отправляет, как я полагаю), и редиректить на страницу заказа, которая будет доступна только при наличии именно этой куки с определенным значением. Можно придумать кучу способов. Но все же самый простой — robots.txt.
А еще яндекс метрика вдруг может начать брать все содержимое страницы и отправлять постом в яндекс, мало ли? Это же JS, подгружаемый на Вашу страницу.

Просто нужно четко разделять зоны безопасности на сайте, и использовать разный подход. В общем, заботиться о своих пользователях.
Что нужно заботиться — полностью согласен. В последних событиях (неделя Яндекса не то, что на Хабре или даже в Рунете, а в масштабах страны — про фэйл Мегафона в газетах уже читал) владельцы сайтов явно не позаботились… Паранойя про чтение браузером или его сторонними расширениями данных post-запросов https сессий и передачей их куда-то на сторону — это одно, выкладывать конфиденциальные данные по публично доступной (даже ботам!) ссылке — совсем другое.
Эти данные не были публично доступны ботам, пока метрика не стащила секретный URL в пользовательском браузере.

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

Если я начну перечислять в своих robots.txt все секретные каталоги своего сервера (на всякий случай уж), то яндес-роботов это может и отвадит, зато других роботов наоборот привадит именно туда!

P.S. Есть еще один способ «сдачи» поисковикам секретных URL'ов, даже если там нет никакой метрики — рефереры. Если на секретной страничке была ссылка на другой сайт, то пользователь може туда сходить с выдачей этому сайту своего секретного урла. А если например статистика рефереров того сайта открыта, то роботы доберутся до секретной страницы и без метрики. Т.е. там должна быть зашита, даже если метрики нет (поэтому, кстати, трюк с редиректом не очень-то надежно поможет). Поэтому безусловная виновность яндекса не означает, что авторы шоп-скрипта не виновны. Они тоже виновны, но яндекс больше :)
Да в чём Яндекс виноват? В том, что «как-то» попавший к нему урл он попытался проиндексировать на общих (даже хуже — представившись конкретно собой) и сайт ему не отказал? Или в том, что урлы к нему «как-то» попали?
Вы это Руперту Мёрдоку расскажите, а то он не в курсе.
Мешает. POST-форма может совершать критичные действия — удалять что-либо и так далее. И вообще, как вы себе это представляете: пришёл бот Яндекса и накрутил голосование? Оставил комментов? Зарегистрировал аккаунт? Подписался на рассылку?
Ну вообще говоря, яндекс-бар может(?) передать ботам яндекса, а те использовать, логин и пароль с целью проиндексировать содержание личной переписки для более полного и релевантного поиска :)
Будите смеятся, yandex проидексировал у меня post форму, примитивную конечно (по сколько на странице показвать результатов), но проиндексировал. Теперь в результатах полный бред, так как он проиндексировал все параметры, вы представялете? В индексе теперь фактически одинаковые страницы с разным кол-вом результатов на странице.
Это конечно не есть хорошо. Скоро и на рассылку подпишется :)
(кстати google такой фигней не страдает, пока)
Впервые слышу о том, чтобы некий поисковый бот сабмитил формы. Возможно, кривая индексация вашего сайта — следствие тех же факторов, что привели к многочисленным утечкам, т.е. Бара либо Метрики.
Может быть :)
Я бы все же смотрел в сторону яндекс-бара… слишком мало проиндексировалось страниц для метрики, и неравномерно
Такая практика как минимум неэтична.

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

Вдруг что-нибудь в боте сломается. Или бот будет не поисковым…

Это причина, по которой вы решили не настраивать robots.txt и отдать приватные данные поисковикам без боя? ;) Хоть бы meta noindex поставили. Если robots — это элемент отчасти админозависимый, то выковыривать бы метатеги из кода вряд ли ко стал или по дороге потерял. Да и от физического расположения не зависит.
Очевидно, по-моему. Мы с вами сказали, ещё пара тысяч так же подумала.
Вы считаете, что индексировать ссылку, по которой вы пришли из письма, отправленного Вам лично по защищенному протоколу, не должно быть запрещено? — В таком случае не менее этично будет индексировать и пароли, полученные в письме (например, если Вы введете этот пароль на странице, на которой стоит некий скрипт, собирающий статистику).
Считаю это должно определяться администраторами сайтов. Запретили в роботс.ткст — запрещено, не запретили — разрешено.
Милиция не рекомендует ходить поздно вечером в одиночку по темным кварталам.
Считаю это должно определяться администраторами сайтов. Запретили в роботс.ткст — запрещено, не запретили — разрешено.
Нет, так защищать информацию нельзя. Подобная информация 100% должна быть недоступна никому без согласия владельца.

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

Если разработчик/админ прикрутил на сайт некую метрику, которая слила ссылку — виноват разработчик. Но если производитель метрики нарушил лицензионное соглашение или ввел администратора в заблуждение, то вина уже лежит на нем.
Если разработчик/владелец знал, что «секретная» ссылка передаётся (зачем — не суть) третьим лицам (фактически он сам передаёт) без явного на то согласия пользователя и эти третьи лица по этой ссылке могут получить доступ к ПДн пользователя, то виноват только разработчик/владелец, раз не заключил соглашения о конфиденциальности с теми, кому он передаёт ссылки или, хотя бы, не проинформировал их о том, что по этим ссылкам могут быть ПДн и ходить по ним или публиковать запрещено.
В том то и дело, что разработчик не знал о таком функционале метрики, а так же разработчик не несет ответственности за трояны в виде всевозможных баров, установленные на компьютере пользователя.
Разработчик не знал, что ссылка из метрики передаётся Яндексу (зачем — не суть)? По-моему должен был знать, даже если соглашение принял не читая, иначе он ХЗ кто, а не разработчик.

А далее — либо эта ссылка является персональными данными и он сам без согласия пользователя отдаёт её третьим лицам, не заключая с ними соглашения о конфиденциальности, либо не является и тогда получается, что разработчик выложил персональные данные в паблик опять-таки без согласия пользователя. А если с согласия (где-то мелким шрифтом в оферте магазина это написано) то вообще сканадл на ровном месте.
Ни поисковый бот, ни метрика понятия не имеют ни о каком письме и не знают, что ссылка была получена в оном, равно как не имеют никакого доступа ни к паролями ни к какой-либо другой информации в этом почтовом сообщении. Они только знают, что пользователь X зашел на страницу Y, которая не запрещена к индексированию и, в рамках пользовательского соглашения, которое установивший метрику должен соблюдать, не содержит коммерческой тайны.
После слива МегаФона прошла целая неделя. Неужели этого срока недостаточно для того, чтобы подумать «Хм, а у моего могут вскрыться подобные дыры?», ответить себе утвердительно, сделать патч и разослать его клиентам?
У моего софта, дурак, у софта. Перечитывай комментарии перед тем, как отправлять.
Господа разработчики, у вас же наверняка есть кое-какая статистика. Так вот вопрос: какой % людей переходит по ссылке с уникальным хэшем из другого браузера, а не в котором сделал заказ? Мне какжется этот % будет не большой. Так почему не привязыть хэш к кукам? А если таки пользователь вошёл через другой браузер, то да — предлагать ввести фамилию для подтверждения.

Спрашивается, почему это не было сделано изначально? И зачем сейчас предлагать всем клиентам вводить фамилию?
Кстати, лично я считаю, что указание обязательным для заполнения поля Имя, Фамилия снижает конверсию интенет-магазина. Может на несколько процентов, но снижает. Есть люди, которые не хотят светить свою фамилию, и правильнее делать один инпут «Представьтесь, пожалуйста» — а там человек сам решает, указать только имя или имя и фамилию.
При доставке по почте иначе никак.
А на безымянный «а/я номер такой-то» посылку не доставят? Как же, блин, теперь покупать запретные плоды? :)
При получении паспорт (или доверенность с паспортом) точно придётся предъявлять.
Нельзя к кукам :(. Люди пользуются компьютерами с работы, у друзей или просто несколькими компами и т.п.
Даже если проблема в метрике — почему страницы не были закрыты от поисковиков? Мета-теги религия не позволяет использовать? Да и robots.txt не просто так придуман же. Так что проблема именно в разработчиках, а не в поисковиках.
Огласите пожалуйста имя гения, который после такого факапа с индексацией приватных данных предложил
Оперативное решение мы сделали следующее: прикрутили авторизацию пользователя по фамилии. Если пользователь перешел по ссылке из письма-уведомления о заказе, то сначала мы у него спрашиваем фамилию, и только если он ее ввел правильно, показываем информацию о заказе.


Это частный случай.
Хотя да, я с Вами согласен, временное решение глупо выглядит.
:)

Если у вас уже есть вся информация о заказе, полученная из кеша, то нет никакого смысла вводить фамилию — ведь вы увидите то же самое.
Спалённых уже не спасти, они о новых думают. На странице изначально не будет никаких данных, а только вопрос «ваша фамилия, гражданин», яндекс её не знает и дальше воровать не пойдет, соответственно ничего кроме вопроса в индекс не попадёт. Но туда будут ломиться спец-роботы, которые натаскали урлов про «твоё фамилиё» из яндекса, и далее атакой по словарю фамилий будет доиндексировать яндексовые недоработки. А может и яндекс наловчится подбирать — в борьбе за полную индексацию. Список фамилий — открытая информация, чо!
Главное фамилию GET-запросом не передавать=)
Феерично! Это не оперативное, а скорее оголтелое решение.
ну это заготовка на будущее как я понимаю, чтобы при следующем «факапе» контент не проиндексировался, думаю на странице с заказом и так есть вся остальная конф. информация, так что иного решения видимо и не существует
Я так понимаю, что смысл был в защите новых записей, старые все равно уже скомпроментированны. Соответственно они не проиндексированы и фамилии не известны.
robots.txt
robots.txt
robots.txt
robots.txt
Кроме поисковиков есть еще и счетчики, которым robots.txt не указ…
Счётчики сливают информацию о существовании урла поисковикам. А robots.txt не даёт эти адреса индексировать.
Кстати, к robots.txt — это не только полезно, но и весело.
Имеются ввиду счетчики рейтингов, которые могут в открытом доступе дать информацию о посещаемых на сайте страницах.
Я думаю, сравнивать счётчик, где, целенаправленно копая, могут найти ваши секретные урлы (как, интересно? я даже не знаю, как это сделать с открытой метрокой сайта, может lj позволяет?), и появление закрытой информации о клиентах в поисковике с дневной аудиторией 12 миллионов посетителей совсем некорректно.

Всё-таки одно дело не соблюсти баланс между удобностью доступа к информации пользователем и сложностью её получения злоумышленником, и совсем другое — в следствие банального раздолбайства оставить эту информацию в открытом доступе.
Де-факто это информация не закрыта. То, что адрес не обнародован не значит, что информация не обнародована тоже.
В абстрактном случа или данном случае? Адрес с хешем, без хеша информации о заказе не получить — если адрес закрыт, закрыта и информация. Мой Круг года четыре авторизирует пользователей по ссылкам в своих письмах. Вы когда-нибудь слышали об утечке приватных данных типа личной переписки из Моего Круга? А о массовом взломе аккаунтов? Я — нет.
В любом. URI, согласно RFC 2616, по умолчанию считается доступным третьим лицам. Точка.
У моего круга, как я сегодня выяснил, ссылки одноразовые.
А у меня linkscanner avg :)))
Многие антивирусы имеют такие модули, которые проверяют ссылки перед «загрузкой» пользователя. Представили? ;) Т.е. перед тем как зайдет пользователь, зайдет антивирус и сбросит счетчик. И пользователь уже не попадет на нужную страницу.
Это я к тому, что это опять ошибка программеров, нельзя так делать. куки, куки и еще раз куки. Нет куки — регистрация и авторизация.
Программер круга, наступает на грабли.
Все таки страничку с никому неизвестным адресом нельзя считать обнародованной. И мой визит на секретную страничку тоже не «народует» её. Эдак можно до чего угодно договориться. Пароль на мой MySQL тоже не обнародован. Предупреждаю: если яндекс стащит откуда-нибудь мой пароль, то не читайте мои таблички :) Или, если хакер стащил мой пароль, а я не забанил чужие IP в конфиге MySQL, то тоже я виноват, а хакер белый и пушистый сидит в открытом интернете и ищет незапертые двери?
>PHP-редирект
Это вы так переадресацию путём Location заголовка и указания соответствующего статуса HTTP ответа обзываете?
нет, видимо, страницу с ссылкой и кнопкой «продолжить», которая берёт get, кладёт его в put и сабмитит.
куда кладёт? :) в post может?
Пардон, в post.
Да, а ещё поисковики обычно поддерживают meta в заголовке для управления индексированием.
Верно. Только пока что Яндекс не особо акцентирует внимание на этом у пользователей метрики (если виновата все же метрика). Это раз. Два: какие будут предложения насчет 100 млрд (или сколько их там) уже существующих страниц? Перепроверять их на соответствие новым интересам яндекса? Ок, не ставить метрику на свои сайты. А если они завтра они начнут собирать урлы баром?
Они уже собирают. И не известно, чем больше собрали
Вообще-то акцентирует. Я всё это знал ещё когда был махровым нубом, сидел на модеме 14400 по баксу в час и юзал какие-то халявные хостинги для мелких страничек.

С тех пор информации стало больше. Прочитать проблема?

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

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

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

4. про автобаны это все отвлеченная риторика. ответ по существу см. в первых трех пунктах.

5. чего так дерзко? ;)
При чём тут метрика? Я про robots.txt и запрет индексирования тех страниц, которые не подлежат публичному просмотру, включая /cgi-bin директорию сервера.

Люди, которые делают сайты без настройки robots.txt, содержащие хоть какие-то приватные данные, просто профнепригодны.
а люди который открывают персональные данные на сайте и защищают их robots.txt???
смех :)
По крайней мере они могут оправдаться перед судом, что сделали достаточно для того, чтобы ПДн их посетителей не попали в поисковые системы.
Достаточно — это когда не показывают то что нельзя тому кому нельзя, не кажется так??
Получается то, что администрация прикрылись слегка кодом и говорят что виновны все кроме них — как это называется????
Ежели один человек собрал, то другой завсегда разобрать cможет

Даже того факта, что информацию знает лишь один человек и никаким материальным линиям или носителям она не передавалась недостаточно для сохранения её в тайне — см. «терморектальный криптоанализ» и т. п.
Конечно, почему бы на шутку не спустить все проблемы разработки и отношений
Не существует априори достаточных мер безопасности, исключающих доступ к информации третьим лицам. Это аксиома информационной безопасности.
Не совсем так. Аутоидентификация по get'у — это, конечно, глупо и криво, но не смертельно — если аутоидентификация происходит, why not?

А вот игноририрование того, что возможна индексация этих данных — это уже фатальная ошибка.

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

Я про техническую часть. Есть общепринятая практика контроля работы crawler'ов, которую даже wget в рекурсивном режиме поддерживает. И её игнорируют, то есть помещают сайт с некорректной конфигурацией в публичный доступ.
Что такое «аутоидентификация» в мире ИТ? Погуглил — только про писхолгию нашёл.
в мире ойти — это осознавший себя ИИ.

осознал и забивая на роботстхт пошел искать чертеже шогоки, коды доступа ядерне рокет и текст колыбельной.
:)
www.duke.edu/~rob/kerberos/authvauth.html
Ctrl+F и «authoi» ничего не дал…
Кто ж знал, что гет запросы будут тырится и попадать в ПС. Это совершенно новый прецендент, который заставляет теперь по другому относится к секреткам в урл :(.
Те, кто читал RFC 2616 от 1999 года :) Там такие «совершенно новые прецеденты» описаны.
ну значит 95% вебмастеров не читали. ибо практика распространенная. Думаю вы что-то путаете.
У меня есть один вопрос. В правилах яндекс.бара и метрики прописано, что все посещаемые url будут добавляться в индекс?
Если прописано — то сами себе злобные буратины.
У яндекса в лицензии ппрописано:
company.yandex.ru/legal/termsofuse/
4.2. Яндекс индексирует открытую часть интернета — те страницы, которые доступны при переходе по ссылке, без ввода логина и пароля, и индексирование которых не запрещено в robots.txt соответствующего сайта. Претензии по поводу наличия в поисковой базе страниц, являющихся открытыми в этом смысле, не принимаются.


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

В сочетании с пунктом про «открытые» страницы получается что содержимое этой страницы также «открытое».
Параметры в GET запросе и есть «логин и пароль». Они ничем не отличаются от переданных методом POST, только что в адресной строке не видно.
Прочитайте RFC 2616
Подскажите, что я должен от туда узнать?
Поисковик не будет индексировть post Запрос, как минимум он точно не попадет в приватную часть.
Разницу между урлом и телом запроса.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А если у меня не «логин и пароль», а «емейл и пароль», то это уже не считается?
А если у меня не «логин и пароль», а «code и hash»?
Да и вообще, если я не закрыл дверь на ключ, это не значит, что каждый имеет право заходить и есть сосиски из моего холодильника.
Есть очевидный и достаточно простой способ решения проблемы, на стороне метрики. Добавлять только урлы, посещенные 2мя или более уникальными посетителями за определенный период. И волки сыты, и овцы целы. Вообще, как бы то ни было, индексировать страницы без внешних ссылок это смелый шаг. Если продолжать эту практику можно еще много интересного найти.
Например мешать нормальной работе поискового бота установив яндекс тулбар и выдумывая несуществующие ссылки, которые не возвращают http код ошибки. Боту видимо придется по всем ним перейти, что либо увеличит нагрузку на сайт от яндекс бота, либо просто нарушит обычную очередность индексации.
Не поможет — активные пользователи подобных онлайн-сервисов потому ими и пользуются, что имеют стабильный доступ к ресурсам сети: из дома, с работы, с мобильника, игровой консоли и т.п.
С точки зрения стороннего робота — это всё разные посетители.
А при чем тут активные пользователи?

1. Во всех кейсах которые привели к сливу данных (Мегафон, интим-магазин) ссылка именно что прокликивается один раз. Что на сайте мегафона, что в интим-магазине. Там не то, что один уникальный посетитель, там единственный хит на страницу проходит.

2. Лимит можно поднять до 3-4 уников.
При том, что «пассивные пользователи», считают что SMS'ку можно отправить только с телефона :-)

Уменьшить количество сливов (с каждого сайта) на порядок и решить проблему — это далеко не одно и то же.
Это не уменьшение количества сливов на порядок (кстати порядок это очень плохая оценка. три порядка более реальная). Это принципиальное решение проблемы всех приватных страниц «для одного пользователя». Без перевода стрелок на robots.txt и фраз «сами виноваты», просто и по существу.

Говнобурления происходят не из-за теоретически возможной индексации, а из-за ряда конкретных проблемных сайтов. Для каждого из которых этот метод будет работать. Опять таки: нужно понимать, что есть некая критическая масса слитых данных, после которой начинаются говнобурления в прессе. Один-два урла, проскочивших через фильтры, не вызывают резонанса. Вызывает резонанс 8к слитых смс.
Может, некоторые параметры передавать ещё и в Cookie, чтобы те, у кого не тот компьютер, где осуществлялся заказ, почти не могли достигнуть этой страницы?
НЛО прилетело и опубликовало эту надпись здесь
Передача «секретных» данных в URI ещё более некорректный.

Имхо, оптимально (баланс между юзабельностью и секурностью) было бы так — делаю заказ, ввожу мыло и получаю письмо:
Спасибо, тра-ля-ля

Состояние Вашего заказа вы можете посмотреть по ссылке example.com/order
Если Вы воспользуетесь другим компьютером (или браузером), то нужно будет ввести пароль s17T#Jgj7$tgh
Если Вы не хотите, чтобы другие пользователи этого компьютера могли увидеть Ваш заказ (включая Ваше ФИО, адрес и т. п.) и его состояние, то перейдите по ссылке example.com/clear_order_cookie — но тогда по вышеуказанной ссылке вам нужно будет ввести вышеуказанный пароль.

Сервер пишет куку (пускай хэш от пароля с солью, или просто в сессию, чтоб не множить сущности), при получении /order её проверяет, если не установлена или некорректна, то просит ввести пароль. И волки сыты (юзабельность почти не нарушается по сравнению с «секретным» урлом — слабо представляю, что ссылку с, например, md5 хэшем кто-то на бумажку записывал, скорее в почту зайдут), и зайцы целы и растут (секурность явно выше).
Я вам предлагаю включать в инсталлятор движка файл robots.txt, уже настроенный на директорию, в которой складируются эти самые карточки клиентов. Т.е. такая защита от дурака получается.
Как быстродействующее лекарство (АКА кривой костыль) информацию по ссылке можно отдавать клиенту через JSON по таймауту.

1. Создаём DIV со значениями width=screen.width и height=screen.height и текстом типа «Подождите, обрабатываются данные вашего заказа»
2. JS определяет USER AGENT. Если оный не ботовый и значения width height не нулевые, то мы скорее всего имеем дело с человеком.
3. Держим паузу в пару секунд, после чего загружаем зашифрованные JSON данные заказа. Расшифровываем и пишем в ранее созданный el.

По идее, такое решение не должно индексироваться поисковиками (контент), хотя это и не решает проблему индексации самой ссылки. Возможно, отбить желание у поисковика можно ещё и таким образом:

1. URL у всех страниц одинаковый, разный только хэш (www.supershop.nah/orderstatus#1h42b21c)
2. В Head прописываем rel canonical для склейки одинаковых страниц
3. JS-ом грузим 1h42b21c.json
НЛО прилетело и опубликовало эту надпись здесь
Ну нагородить-то можно много, если рассматривать ситуацию как задачку по ненормальному программированию. Например, можно поставить миникапчу, которая не будет и пользователя напрягать и боты отсеет.

Показываем четыре картинки: утку, автомобиль, ножницы и вилку. Просим пользователя выбрать утку. Профит! :)
Мне кажется это будет просто очередным временным препятствием. Ведь раньше и ссылки с уникальным тоукеном считались вполне вменяемой защитой. А ваш метод будет действовать до того момента, пока роботы не начнут напрямую эмулировать браузер и обрабатывать javascript, AJAX контент, ну и передавать не нулевые height/width.
А вот это уже тогда будет прямым нарушением со стороны поисковых систем, так же как если они начнут индексировать содержимое игнорируя указания robots.txt.
Нарушением чего?
User-Agent можно проверить на сервере и спокойно ответить 4xx, никого не мучая таймаутами. Все поисковые роботы честно представляются поисковыми роботами.
Не все. Именно поэтому мы для себя и придумывали этот велосипед с определением screen.width/height и манипуляции с DOM.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А при чем тут кука? У меня, к примеру, 4 браузера в активном использовании.
Разве согласно ФЗ «О персональных данных» не устанавливает обязательство добросовестно хранить и предотвращать несанкционированное распространение личной информации пользователей?

Содержимое заказов, а уж тем более контактные данные клиентов не должны быть доступны извне, никоим образом. Предотвратить это просто — отправлять на почту пароль. Это «маленькое неудобство» спасет и пользователей, и владельца, и удовлетворит требованиям закона


Неубедительно. Отличается ли с технической точки зрения наличие «авторизационного» хеша в урле от наличия авторизационной куки? Нет. Должен ли владелец сайта отвечать за получение персональных данных третьими лицами, которое было вызвано наличием на компьютере пользователя некоторого спайваре? Нет. Так что ФЗ здесь вообще не при чем. Если кто и должен ответить за нарушение ФЗ, так это Яндекс.
Насчет спайваре: ну да, это относится к случаю ябара. В случае установки метрики, согласно п. 8 оферты, виноват будет сам вебмастер. То есть мне ситуация представляется как

— «На, попробуй, это круто. Попробуй, на, надо просто код поставить.»
чуть позже
— … у моих пользователей ПД собрали и опубликовали, а теперь меня судят…
— Что, оферту не читал? Да ладно! Почитай. Ты нам теперь еще и денег должен.

Утрирую, но смысл я думаю понятен. Если бы ситуация возникла в штатах с гуглом, вонь была бы на весь мир, и виноват был бы именно гугл. У нас как обычно лох тот, кто не прочитал внимательно оферту, независимо от того, что там написано.
Не достаточно читать оферту, надо ее еще и акцептовать.
Вывод — удалить нахер яндекс метрику, а если пользователь не удалит яндекс бар, виноват будет сам :). Долой официальный спайвер!
Если кто и должен ответить за нарушение ФЗ, так это Яндекс.

Вот уж никак не Яндекс. С точки зрения ФЗ-152 за сохранность ПДн клиента отвечает сайт их получивший (магазин и/или процессинг платежной системы) — это сайт делает ПДн клиента общедоступными без его согласия (а если с согласия, то и вообще разговор ни о чём).
Ниже отписался, что первый коммент относится к ябару, но не относится к метрике. Для ябара описанное мной верно. Магазин или процессинг не могут отвечать за то, что у пользователя установлено спайваре, фиксирующее посещаемые им страницы. Другое дело, что в ПС ябара наверняка есть пункт отказа от ответственности перед пользователем. Что еще хуже, поскольку вебмастера на ябар не могут повлиять вообще (метрику по крайней мере можно не ставить).
Магазин или процессинг должны отвечать за то, что персональные данные клиентов стали общедоступными без явно выраженного письменного согласия клиента. Есть у этих магазинов в их офертах/публичных договорах, что передача «секретной» ссылки третьим лицам в любой форме является согласием на обнародование их персональных данных, переданных до этого магазину? Сомневаюсь. А вот в офертах многих сайтов с аутентификацией по логину/паролю такие пункты есть. Подстраховались даже на случай если бар/метрики начнут (по соглашению с пользователем, конечно :) ) сливать в поисковые системы пост-запросы, а те начнут их индексировать именно пост запросами.

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

Или на поисковые системы закон не распространяется? В смысле — скупщик краденного не вор? Тогда надо еще отдельный закон для поисковиков придумать, иначе от ФЗ-152 будут отмазываться «я не получал информацию от пользователей, я её только индексировал, как поисковик».
Придумали уже
3. В случае, если распространение определенной информации ограничивается или запрещается федеральными законами, гражданско-правовую ответственность за распространение такой информации не несет лицо, оказывающее услуги:
1) либо по передаче информации, предоставленной другим лицом, при условии ее передачи без изменений и исправлений;
2) либо по хранению информации и обеспечению доступа к ней при условии, что это лицо не могло знать о незаконности распространения информации.
НЛО прилетело и опубликовало эту надпись здесь
Чуть-чуть не так, хранитель данных отвечает за сохранность тех данных, которые у него хранятся. Кстати, это логично, не находите? ;)
НЛО прилетело и опубликовало эту надпись здесь
Включая индекс Яндекса.
Мне кажется или в пользовательском соглашении Яндекс.Метрики вполне конкретно написано, что они могут собирать адреса страниц в автоматическом режиме, и не могут определять есть ли там конфиденциальные данные, вследствие чего, обязанность закрывать страницы ложится на автора сайта.
Где-то в районе пункта 8 пользовательского соглашения.
Казалось бы причём тут авторы магазина :)
Именно так. Авторы движка непосредственно тут ни при чём.
После того, как заказ оформлен, покупателю по электронной почте отправляется уведомление о заказе, в котором есть прямая ссылка на страницу с подробной информацией о заказе, его статусе, возможности оплатить заказ и посмотреть историю его обработки.
Так как заказ оформлен незарегистрированным пользователем, то эта страница открывается по ссылке из письма-уведомления (в ссылке аутентификация происходит по хешу, в которой все параметры передаются, естественно, в GET-запросе). У пользователя никакой пароль не запрашивается, так как пароля в данном контексте нет.
Требовать обязательную регистрацию для оформления заказа в интернет-магазине, согласитесь, совершенно неудобно для покупателя, а показать ему страницу с историей выполнения заказа необходимо.
простите, а что мешало по умолчанию раздавать ваш магазин с прописанными robots.txt по умолчанию? ведь в вашем магазине get строка фиксированная для оформления заказов и т.п… прикрыть их по умолчанию не составляло труда!
Почему все обсуждают только robots.txt?
По моему, самое правильное решение — на страницах заказа использовать тег <META NAME="ROBOTS"...>. В соседней теме уже выяснили, что этот тег используется Гуглом в Пикасе и Ютубе, и их приватные альбомы/видео не индексируются.
Проверил, на страницах заказов www.sexyz.ru его не было до патча и нет сейчас.
Собственно функция у них (мета-тега и роботс.ткст) одна и обрабатываются одинаково(?).
В случае с Ютубом ссылки на открытые и закрытые видео выглядят одинаково, так что robots.txt здесь не поможет, только <META NAME="ROBOTS" CONTENT="NOINDEX, FOLLOW">.
А что, ссылки должны выглядеть по разному в зависимости от наличия какого-то файла в корне сайта, на который они ведут? Насколько я знаю, выглядеть по разному могут в зависимости от того посещена ссылка или нет. И только.
Я имел в виду формат ссылок.
Независимо от доступности видео ссылка выглядит так: httр://www.youtube.com/watch?v=<VIDEO_ID>
Для таких ссылок нельзя написать правило для robots.txt, которое запрещало бы индексировать unlisted видео.
Если бы доступное только по ссылке видео имело URL вида httр://www.youtube.com/p/watch?v=<VIDEO_ID>, то в robots.txt можно было бы добавить строки:
Disallow: /p/
Извиняюсь, нашёл выше неоднократное упоминание meta noindex.
Но всё равно, надо не только robots.txt форсить, но и meta тег.
Вы не находите противоречия в том, что работают теги или нет — нужно выяснять опытным путем?
Нет, проверку, что тег работает, надо было выполнять мне, так как я под веб ничего не разрабатываю. А веб-разработчики должны им пользоваться и знать о его действии.
По ссылке выше написано, что это сдандарт де-факто. Также, например, в справке Яндекса, написано, что тег обрабатывается.
Сегодня обрабатывается, завтра нет. Справку можно переписать. Кто обязал Яндекс его обрабатывать?
Кто обязал Яндекс, Гугл, Биндг или меня не обрабатывать урлы, индексация которых закрыта в роботс.ткст, данные, которые передаются постом или по https?
Что должен был сделать Shop Script чтобы избежать такого инцидента?
1) robots.txt
2) мета-теги <meta name="robots" content="noindex" />
3) чтоб от плохих роботов застраховаться, ставьте капчу на страницу с приватной информацией.

А что должен делать яндекс? Не передавать из метрики и бара данные об URL? Ну не бар/метрика так что-нибудь другое выдаст. логи веб-сервера случайно в доступ попадут или какая-нибудь система статистики типа awstats будет неприкрытая… Какой-нибудь глючный прокси, HTTP-реферер. Да куча вариантов.
Правило тут классическое действует — security through obscurity — шифрование основанное на сокрытии алгоритма шифрования не работает.
Пароль основанный на сокрытии пароля не работает? ))
Господа веб-мастеры, объясните, пожалуйста, мне, недалёкому, зачем на общедоступную страницу («секретный» урл- не аргумент) вешать всяческие метрики, аналитики и счётчики? Заказ сделан (смс отправлена), конверсия достигнута (правильное выражение?) — что там ещё анализировать? Пользуется клиент веб-интерфейсом к почте или из почтовой программы переходит? Нафига? Востребована эта информационная страница или нет? По (почти) самым простым логам сервера можно выяснить. Вот зачем она там?
Никто же не расставляет счетчики выборочно. Все ставят в хедер-футер да и все.
Вот именно… А потом жалуются на «неэтичные действия» создателей счётчиков.
А разве у MoiKrug.ru ссылки не одноразовые? Перешёл из письма по ссылке второй раз — вводи пароль.
Почему бы не поставить дополнительную аутентификацию в магазине только на второй заход?
НЛО прилетело и опубликовало эту надпись здесь
В интернет-магазине на базе Shop-Script можно оформить заказ без обязательной регистрации. То есть без ввода логина и пароля.

Не припомню крупных успешных интернет-магазинов с возможностью такой халтуры. Зачем давать покупателю такую возможность?
И ещё один неоднозначный момент во всей этой истории. Если в случае обычных магазинов ПДн были, наверное К3, то в случае секс-шопов есть предположение о ПДн К1. В таком случае отсутствие авторизации выглядит как преступление.
Ненавижу магазины с обязательной регистрацией, порой даже требующие избыточные сведения, никак не относящиеся к заказу. У пользователя должна быть возможность сделать «одноразовый» заказ без регистрации.
Не закупаетесь в amazon, bhphotovideo, dealextreme, ebay и т.д.?
Не могу сказать, что они запрашивают избыточную информацию. Зато ни яндекс ни гугл не кэширует там состояние заказов.
Более того, отсутствие регистрации — маркетинговое упущение для магазина. Не говоря уже о безопасности.
Я пользуюсь amazon, dealextreme, ebay и другими сервисами на постоянной основе и понимаю необходимость регистрации.
Но ситуация совсем иная, когда я хочу купить «неоригинальный картридж для принтера за 700 рублей» один раз в жизни в малоизвестном мне магазине (адрес сайта которого я очень скоро забуду, а через пару лет есть большая вероятность, что магазин вообще исчезнет или сменит свою cms и потеряет в результате всю информацию о своих пользователях) и я точно знаю, что в обозримом будущем я ничего покупать больше не буду.
Регистрация накладывает целый ряд проблем: это дополнительное время, нужен дополнительный «треш-пароль», нужно заходить на ящик, подтверждать свою почту, получать потом оттуда спам, указывать дату своего рождения, например, да и ее зачем-то иногда требуют. Я обычно ввожу 1 января 1975 года, но зачем она? И все ради чего? Ради покупки электронной книги за 17 рублей? Я вижу это себе так: купить -> метод оплаты -> мерчант -> сайт со ссылкой на скачивание (письмо на почту с подтверждением об обработке заказа в случае покупки картриджа для принтера)
А про магазины бытовой техники (например) я вообще молчу, вариант покупки без звонка по телефону выглядит крайне утопичным.
Ну что я вам могу сказать. Доверяете личные данные трэш-магазинам — страдайте.
Конечно должна, и вся информация о заказе должна просто отправляться на почту. Зачем ее выдавать на сайте, не совсем понятно.
Статус заказа?
так же отправлять на почту?
по запросу или автоматически при смене статуса заказа. (см. Ozon)
На мой взгляд то, что поисковики сами себе дали право индексировать всё, что не запрещено в robots.txt, и теперь считают это право чуть ли не аксиомой, — это несколько некорректно. И ситуацию надо постепенно менять на «индексировать можно только то, что явно разрешено».
Так как того что разрешено явно больше, на подавляющем большинстве сайтов, чем запрещено — то ленивые разработчики начнут разрешать индексировать все, звездочкой там, или какой синтаксис придумают. Например meta index. Вставил в шаблон шапки meta index, и используй шаблон на всем сайте. Панацеи нет.

Есть инструмент(поисковик), есть инструкция как им управлять в пределах своего сайта. Это реалии.

Если не получается дать гарантию надежности сервиса, зачем его делать, и потом оправдываться и обвинять поисковик, который давно описал свои принципы работы и обо всем предупредил? Да, политика, терять клиентов не хочется, и хочется выйти чистым из воды.
НЛО прилетело и опубликовало эту надпись здесь
Насколько я помню, Мегафон официально признал косяк за собой. Но и учитывая что Мегафон крупная компания, яндекс по их просьбе вроде бы довольно быстро убрал всю выдачу.
Законы, лицензионные соглашения разве не пишутся таким образом, чтобы была возможность перевода стрелок? :)
НЛО прилетело и опубликовало эту надпись здесь
Это будет нарушением основных принципов Интернета вообще и HTTP в частности — ошибки 401 и 403 не вчера придумали, и это не какие-то там 449 или 456.
Вы хотите защищать информацию предоставленную Вам через «ошибки сервера», робот.тхт и потом обвинять поисковик в утечках информации ))))))))))))))))))))))
НЛО прилетело и опубликовало эту надпись здесь
Это теперь там запрос фамилии, а раньше не было.
Мы являемся разработчиками автоваза. Это не наша вина, что автомобили ВАЗ ломаются. Возможно причина в том, что владелец самостоятельно был в автосервисе и установил себе дополнительно автомагнитолу.
НЛО прилетело и опубликовало эту надпись здесь
… и конституцию принять такую, чтобы не как сейчас уголовный кодекс чего делать нельзя, а наоборот — перечень того что делать можно, а по-другому нельзя. Верно?
НЛО прилетело и опубликовало эту надпись здесь
Разместив информацию в Интернете и не позаботившись об аутентификации и авторизации доступа к ней, вы, имхо, дали явное согласие на ознакомление с нею неопределенного круга лиц…
НЛО прилетело и опубликовало эту надпись здесь
Пускай не тяжёлую (логин/пароль например), а облегченную (куки и мыло).

Ваши изменения, по-моему, нарушают основные принципы веба. Да robots.txt, имхо, не может считаться средством безопасности, это средство сообщить поисковику «тут ничего интересного нет, не трать свои ресурсы зря»
> Такая практика как минимум неэтична.
Я бы даже сказал преступно.
По какой статье УК РФ?
очевидные вещи про POST уже написали
а как вам такой вариант:
личные данные, кот. желательно не индексировать, показывать в IFRAME?
интуиция подсказывает, что поисковые роботы не индексируют содержание ифреймов. Плюс к тому загрузив ифрейм с другого домена/субдомена можно предотвратить доступ к этой информации.
нужно писать нормальные и защищенные движки, а не защищаться IFRAME или ROBOTS.TXT ))))
думаю кроме общедоступных поисковиков думаю есть много внутренних/индивидуальных, если понимаете о чем я…
да конечно, надо учить народ жить по правилам и объяснять зачем все эти неудобства
вот наступит резко будущее и мы сможем идентифицировать человека без лишних телодвижений…
и тогда здравствуй «большой брат»

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

Не так. Я бы очень сомневался, если бы они были получены лишь по урлу.
А еще Яндекс виноват в том, что создал робота, нарушающего первый закон робототехники.
1. подобную информацию собирает и пользуется не одна метрика (хотя здесь её успех), владельцы счётчиков, баннеров… а так же производители браузеров и плагинов к ним.
2. судя по доброй части комментариев большинство так и не поняла НЕЛЬЗЯ ДАВАТЬ ДОСТУП К ЗАКРЫТОЙ ИНФОРМАЦИИ ПО ПРЯМОЙ ССЫЛКЕ. можно делать одноразовые ссылки и пароль для повторного входа.
3. Нельзя размещать js с чужого сайта в закрытой области своего проекта, неужели думаете что считают и несут финансовые затраты за так?
Если не трудно, разъясните, пожалуйста, почему же таки НЕЛЬЗЯ ДАВАТЬ ДОСТУП К ЗАКРЫТОЙ ИНФОРМАЦИИ ПО ПРЯМОЙ ССЫЛКЕ?
Нет, ну в самом деле. Непонятно. Вот прямо для тупоголовых, если не трудно, объясните, а?

Потому что для защиты используется более современные и более защищенные методы (перечисление и методы думаю не актуально перечислять)…
Это вполне нормально и не настолько затратно чтобы отказываться!
Вы не видели ссылок на социальные сети тех, кто покупал товары или отсылал СМС??? Если поищите, то в соседних темах их достаточно. Так вот советую обратиться к ним и спросить «почему же нельзя передавать прямые ссылки для доступа к персональной информации человека».
Пользоваться навесными замками нельзя, потому что существуют более современные врезные замки. Это не настолько затратно, чтобы отказываться.
Спасибо за бесполезный ответ.
О каких навесных замках речь?????
Тот кто называет себя Банком или кто говорит что будет тщательно хранить ценные вещи и просто подпирает дверь палкой — по меньшей мере очень много возомнил себе или о себе…
И не за что ))
15.1.3 Encoding Sensitive Information in URI's

Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead

Читали этот документ? Или не получилось прийти к выводу, что это относится не только к «GET based forms», но и к любым URI, «because this will cause this data to be encoded in the Request-URI».
Вот, кстати, за этот отрывок безоговорочное СПАСИБО! Заставило задуматься…
POST-based, конечно, тоже не панацея, но тем не менее…
Да, на минуточку:
www.urikor.net/eng_course/lsn021.html
SHOULD NOT переводится как «не следует» (то есть рекомендательная форма), получается что этот фрагмент документа имеет статус рекомендации, повода для размышления.
RFC вообще никого ни к чему не обязывает. Это лишь рекомендованные «правила игры». Кстати, как и ГОСТы и ISO — на них могут ссылаться обязывающие документы (необязательно непосредственно, что называется «подзаконные акты») или вы сами можете ссылаться на них, что ваш продукт (или процесс его производства) им соответствует, возможно с ссылкой на мнения третьих лиц («сертификат», «свидетельство о соответствии» и т. п.).
надеюсь, вы шутили или нигилист любящий поспорить.

в пункте 1, который был перед пунктом 2, я ясно описал, что информация о посещённых адресах не остаётся тайной
Кто сказал, что нельзя? Можно.

Но надо следить за тем, что именно показывается. Закрытая информация доступная по открытой ссылке должна исключать ее неправомерное использование.

Например, можно сделать страницы, коорые будут показывать пин-коды к кредитным картам (в конце концов это просто ифры). Но при этом там не должно быть номера карты и других реквизитов.

Легальный пользователь знает номер своей карты и может использовать информацию о пин-коде, нелегальный — нет.
Как я понимаю, если обязать поисковые системы индексировать только достижимые из открытого интернета страницы — проблему можно решить. Это было бы правильно с точки зрения этики.
Хороший стартап получится: поисковик по запрещенным урлам из robots.txt. Будет пользоваться огромной популярностью пока лидеры рынка поиска будут доказывать свое право индексировать все что доступно.
мне кажется, с точки зрения этики нужно обязать поисковые системы индексировать только те страницы, которые явным образом указал владелец сайта. Тот же robots.txt, только наоборот. Вот по тем ссылкам, которые указаны в этом файле — индексируй, остальные — нельзя! По умолчанию — ничего нельзя! Презумпция виновности.
Потому что без этого принципа все встает с ног на голову (как мы сейчас и наблюдаем). Создавая сайт (даже с простым содержанием, без каких-то секретных страниц) мы, оказывается, должны беспокоиться о том, как будут с этим сайтом обращаться поисковые роботы! Да кто они такие, что о себе возомнили?
Создают сами себе «правила пользования», а наши правила, которые мы пишем на своих сайтах, они хоть во что-то ставят?
(читать с долей иронии, но на самом деле этот гнев праведный)

Те страницы, которые нужно индексировать находятся в файле сайтмап.хмл…
Те что случайно или намеренно попались поисковику, но не допускаются для индексации указываются в робот.тхт
собственно, в этом и подвох. Те страницы, которые случайно или намеренно попались поисковику, но отсутствуют в файле сайтмап — не должны индексироваться, если это правило (или закон?) принять, многих проблем можно было бы избежать. По крайней мере, с этической стороны это было бы правильнее.
сайтмап.хмл как и робот.тхт могу отсутствовать на сайте, это зависит он нужд…
Защищать нужно данные с эстетической стороны…
С эстетической? или с этической? %)))
На самом деле вся проблема в том, что действия поисковых систем никем не регулируются, кроме их же собственных правил. И этими правилами они подчиняют себе действия веб-мастеров. Что не есть правильно, хотя бы потому что «не мы для них, а они для нас».
Кто сказал, что яндекс-бот должен следовать правилам robots.txt? Хотим — следуем, хотим — едем по встречке.
Найдена ошибка — возьми пирожок с полочки…
Если будете писать программы возможно будете понимать и эстетическую сторону написания кода
Пока, насколько я знаю, популярные поисковые системы не нарушают своих неписанных правил: «может быть включим в индекс то, что ваш сайт выдал по GET-запросу без кук, исполнения скриптов и с честным User-Agent»
Давайте будем честными по отношению к себе в первую очередь.
Нет в выдаче — не значит, что нет в индексе, ведь так?
Так, но это чистой воды конспирология.
Действия поисковых систем регулируются, в первую очередь законами о свободе сбора информации (в случае нашей страны, записанными в Конституцию). Если это отменить, у вас возникнет куча проблем (например, вы сами не сможете по умолчанию прочитать этот пост с комментами).
пожалуйста, статьи Конституции или номера законов в студию
Конституция, Статья 29, в частности, пункт 4.
Где открытый интернет начинается? С чего индексацию начинать?
С заявления от владельца сайта на имя владельца яндекса: «прошу проиндексировать мой сайт, список страниц для индексации размещен в файле sitemap.txt». Что-то типа этого. %)))
Правда, сразу предвижу возможности для разгула коррупции (чтобы далеко за примером не ходить, тот же яндекс, как он создает яндекс-каталог: этого проиндексирую, у этого деньги возьму, а этого вообще пошлю). Это, конечно, шаг в сторону, противоположную светлому коммунистическому будущему.
А также EULA c пользователями: «обязуюсь не передавать ссылки третьим лицам, готов нести кару вплоть до расстрела» :)
Точно! Мелким шрифтом, внизу, серым цветом на белом фоне ))
Плохому танцору — я мешают
Ну казалось бы, почему бы по ссылке не вести на страницу с формой (с одной кнопкой),
там показывать (ну или не показывать) капчу на первый заход, затем сажать куку и выдавать данные только по POST-запросу
Тоже неплохая идея :)
Вывод — robot.txt — ни при чем. Виноват кто? ;)
А пока же участникам этой мелодрамы грозит уголовное преследование по статье 138. А это, напомню, до 3 лет лишения свободы.

Кого же посадят?
* Разработчиков магазина?
* Сисадминов?
* Кого нибудь из Яндекса?
* Или того кто выложил первую серию этой мелодрамы?
В правоохранительных органах считают, что личные данные были выложены в Интернет намеренно. "Очевидно, это делалось специально, кто-то писал скрипты, чтобы достать эти данные из «Яндекса». С какой целью это было сделано — пока не ясно, но вызывает некоторые подозрения тот факт, что это произошло накануне подписания президентом РФ поправок к закону «О персональных данных»

О_о
По идее владельцев и/или админов ресурсов. Разгласили они.
RailwayTicket тоже применил военную хитрость и стал просить мыло или телефон. Только толку, если в Яндексе есть волшебная кнопка «копия».
Аналогично и про остальное.
Яндекс еще пару раз пройдет по ссылке и удалит из кэш. Далее все пойдет нормально.
В лохматом 2000году, я делал сайт и авторизацию оставил на последний момент. И что вы думаете произошло? Google.ru прошел по всем ссылкам в админке и удалил мне сайт.
Теперь я знаю. Первым делом в любом проекте это Авторизация.
А Google использует POST-запросы?
Вроде есть негласное правило, что данные не должны менятся в результате GET-запросов.
у меня с GET все было) ну первый раз делал, простите.
Для первого раза простительно :)
Сам я похожие ошибки совершал.
Оперативное решение мы сделали следующее: прикрутили авторизацию пользователя по фамилии

я надеюсь вы это сделали не GET Запросом?
Простите, а нафига скрипт метрики на странице с заказом?

Я понимаю что его впихнули тупо автоматом во все страницы, но фэйл именно в этом. Это все равно что установить RAdmin а потом причитать, что он поворовал инфу с компьютера.
Скрипт метрики на странице с заказом для тогр чтобы посчитать конверсию. Собственно это основное, зачем вообще нужна метрика бизнесу.
Конверсию можно посчитать по количеству выполненных заказов. Метрика тут — как гвозди микроскопом.
Поясню: данные метрики нужны тем, кто занимается интернет-маркетингом. Это может быть отдельное подразделение или подрядчик («Внешний Администратор»). Часто информация о фактически выполненных заказах им недоступна.
Поясню и я: коль скоро метрика может привести к утечке данных со страницы (а это было понятно и до последних скандалов) — этот инструмент не годится для работы со страницами, содержащими персональные данные.
вы совершенно правы
«Использование файла robots.txt добровольно. Стандарт был принят консорциумом W3C 30 января 1994 года в списке рассылки robots-request@nexor.co.uk и с тех пор используется большинством известных поисковых машин.» (из вики)

нет никакого RFC или иного обязательства использовать robots.txt так что вина вебмастера тут менее одной третьей.
Не соглашусь. Кто тогда виноват? Поисковик? А если даже «рекомендованного» файла нет — как он узнает, индексировать или нет — мысли прочитает?!

Причем Яндекс-то как раз сделал все, что возможно в этой ситуации — проверил даже то, что не обязательно (robots.txt). Так что по факту — виноват разработчик. Делаешь приватную страницу — думай, правда ли она приватна. Именно поэтому есть понятие специалиста по безопасности. А сейчас любой хочет писать свой магазин, прикручивая CMS-решения или самопальные скрипты — спрос на это есть и пофиг, что знаний и опыта нет.

Внимание! Я сейчас никоим образом (даже намеками) не собираюсь обижать команду разработчиков или ставить под сомнение их квалификацию — ошибиться может каждый и за один прокол я бы точно не стал всех вешать на месте. Однако, по большому счету, виноваты они.
RFС, таки, есть, от 96 года — только что IETF не включила его в свой список (потому что это касается нетикета, а не технологии), а W3C упоминает вскользь. RFC — это неформальные стандарты, всего лишь фиксация правил делового оборота, принятого в интернете.
Имхо самым правильным было бы добавлять в индекс только страницы с
. Кому нужна индексация позаботятся.

Скрипт метрики на странице с заказом вполне себе ок (аналитика же), а вот публикация данных полученных метрикой не ок.
meta name="robots" content="index"
Я просто оставлю это здесь
image
Что было и что осталось, Вы вообще о чём?

Вашу картинку пришлось разглядывать с лупой, вот результат:

image
Всё ведь предельно просто. И любой оптимизатор или вебовый программист всё понял.
Картинка как бы намекает на негодование на тему «кривой индексации» даже самого сайта шоп-скрипт.ру
ВНЕЗАПНО

image

Правда только в том, что не любой оптимизатор и вебовый программист является профессионалом в своей области.
С утверждением согласен.
По поводу картинки =) Интернет это не сферическая система в вакууме… В нём постоянно всё меняется. На текущий момент 513 в гугле.

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

Оптимизатор не должен отвечать за работу быдлокодера. А тут вообще коробочный продукт… такой косяк с индексацией непростителен.
В поиске всегда выводилась фамилия получателя и ограничивать на тот момент по фамилии было довольно глупо, пока в индексе поисковика были данные страницы.
Хм, а если существует один единый файлик для роботов robots.txt, то почему бы не сделать единый get параметр, тот же robots=1 (или более уникальный), который бы устанавливал, что данный конкретный урл не следует индексировать.
Понятно, что это очень глобальное и неполное решение проблемы (например, в случае, если поисковые роботы будут игнорировать этот параметр или робот вообще будет не поисковым...), но всё же.
Шоу продолжается!
www.google.ru/search?q=allintitle%3A+%D0%B4%D0%BB%D1%8F+%D1%81%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%BE%D0%B3%D0%BE+%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F+site%3Agov.ru&rls=com.microsoft:ru:IE-ContextMenu&ie=UTF-8&oe=UTF-8&sourceid=ie7&rlz=1I7ADBF_ru&redir_esc=&ei=H74vTr-hL47JswbvjvEc
Надеюсь, теперь власть обратит внимание на все стороны-участники инцидента.
Есть такое понятие, как одноразовый пароль (токен).
А ссылки на приват могли утечь как угодно, например, их просто могли разместить конкуренты где-нибудь.
Почему что-то мешает привязывать сессии к IP, мне не понятно.
Привязка сессии к IP — это для другого бизнес-процесса. В этом же процессе человек мог посмотреть трэкинг с рабочего компа, потом с телефона и т.д.
Например, мой опыт отслеживания IP посетителей на одном из проектов выявил ненулевое количество адресов типа 192.168.*, 10.*, 127.0.0.1…
Смену IP в течение сеанса тоже наблюдал.
В этом случае я скорее буду против Яндекса т.к. они использовали Яндекс.Метрика (предназначенный для сбора статистики, и, соответственно, рекламируемый как инструмент для сбора статистики) для сбора URL-ов, о чем никому не говорил.
В соглашении говорится «Пользователь понимает и соглашается с тем, что счётчик, установленный на сайте Пользователя, собирает анонимные (без привязки к персональным данным посетителей сайта) данные о посещениях сайта Пользователя и в автоматическом режиме передаёт их Яндексу для получения обобщённой статистической информации, доступной для дальнейшего использования с помощью Сервиса как Пользователю, так и Яндексу.». Здесь не говорится что данные будут использоваться для индексации поисковым роботом.
Да, но URI (также, как, например, ваш ник) — это не «анонимные данные», а публичные идентификаторы. Факты, например, что пользователь с определённым IP посетил определённый URI Яндекс и не публиковал.
URI публичный, но Яндекс, как и все поисковики, говорят что страница может попасть в индекс если где-то ПУБЛИЧНО есть на нее ссылка, либо сам вебмастер засабмитил ссылку в поисковик. Ссылка в почте не является публичным местом. Да и в данном случае ссылку они оттуда не берут, берут они ее используя Яндекс.Метрика о чем никому не говорят и чего не должны делать. Верно?

Стоит еще вспомнить что сам Яндекс дает ссылку по которой можно залогиниться в МойКруг не вводя никаких логинов и паролей. Это тоже можно считать публичным?
Пользователь (или вебмастер за него) соглашается с отправкой данных статистики посещений тех или иных урлов -> формируется статистика в виде пар (url, количество) -> яндекс проходит краулером по статистике, посещая url`ы.

> Стоит еще вспомнить что сам Яндекс дает ссылку по которой можно залогиниться в МойКруг не вводя никаких логинов и паролей. Это тоже можно считать публичным?

Угу. Правда (я сейчас проверил), эта ссылка сработает только в одном браузере, и они честно предупреждают об автологине в письме.
Когда же люди поймут, что Security through obscurity не работает?

Отправляете ссылку на приватную информацию? Генерируйте credentials для доступа к ней!
Надеюсь яндекс не научиться собирать куки и потом ходить по ним по сайтам, авторизовавшись. Или собирать и потом повторять ввод post параметров.
А вот это уже было бы противозаконно. То что делает яндекс сейчас в рамках закона.
Кстати, я придумал отличное решение, которое в своё время мне подсказало ковыряние форума на vBulletin.

У поисковых краулеров в 99% случаев есть собственный User-Agent и по нему можно идентифицировать, что данную страничку посетил поисковой робот и никто иной. Далее на страничке Статус заказа вставляется простейшая инструкция, которая если данный User-Agent принадлежит какому-то краулеру, выводит пустую страничку.

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

Автор, подумайте над таким патчем также. А вообще я вам писал в комментах, используйте Cookies и восстановление Cookies по e-mail, если не хотите отказываться от покупки без реги.
Хитрый яндекс в редких случаях представляется обычным браузером :)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Прочитал статью. Молодцы что выступили, но на этом плюсы вам заканчиваются.

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

Резюме — это в чистом виде ваш просчет, исправляйте немедленно.
Полностью согласен, разве что с поправкой: есть магазины дающие URL к статусу заказа без авторизации, при этом доступна информация только о статусе и составе заказа, полностью обезличена (не заказчика, не адреса).
Вспоминаю рекламный слоган: Яндекс — найдется все!
Да тут по-моему все виноваты, и яндекс со своей жадностью и своей метрикой, семь пядей во лбу не нужно чтобы догадаться что не все ссылки предназначены для публичного использования, де-факто, не смотря на увещевания RFC 2616 и т.п., и индексация через руки — это индексация исключительно тех страниц, на которые дана ссылка.
И веб-мастера со своей недальновидностью, приватная страница должна быть максимально приватной, даже любое изображение подгруженное со стороннего источника обнаруживает адрес приватной страницы через тот-же REFERER, не говоря уже о сторонних скриптах… да и какая к черту аналитика на такого рода страницах? Проверять хорошо-ли они проиндексировались? :)
Ну и конечно общепринятая порочная практика выдавать приватные данные по ключу в GET-параметре, если раньше это было больше из области научной фантастики, дескать кто-то выдернет адрес из прокси, то сейчас благодаря наличию всяких яндекс-баров — никто не уйдет обиженным :)
НЛО прилетело и опубликовало эту надпись здесь