Что деятели Рунета думают о поиске персональных данных

Сертифицирование ПО для веба нужно. Ясно же. Но это на грани невозможного. Это тоже ясно. Яснее же всего то, что самый большой профит будет у Битрикса. Аминь.

да нет, далеко не битрикс будет давать «сертифицированое» ПО

ну что вы так защищаете яндекс — яндекс, к которому попали персональные данные — это третье лицо. разрешений на передачу ему персональных данных пользователи сайтов не подписывали же? значит яндекс попадает под 152фз, к нему можно написать заявление на отзыв согласия на обработку пд и тогда он должен пд подчистить, и тем более обеспечить их удаление из своей базы — но так ведь он он еще и распространяет неправомерно полученные пд (у яндекса нет согласия на обработку пд от лиц, пд которых он индексирует — обрабатывает, хранит — поищите в яндексе номера паспортов, адреса фио — они там есть) и кстати яндекс до сих пор не зарегистрировался как оператор пд (http://pd.rsoc.ru/operators-registry/operators-list/ ) =)

Да, ведь автоматизированная обработка пд выходит когда яндекс автоматически все собирает, и номера паспортов, и адреса и прочее…

Извините, аьтерэга, но про пд 152фз — это никак. Это все равно, что винить владельца дома за наклеенные объявления без его ведома. В соседнем топике все уже перетерли. Я лучше поделюсь своими выводами: 1. Поисковикам стоит подумать о чистоте получаемых ссылок для индекса. Основная проблема может быть в тулбарах или других инструментах, где ссылки могут публичные, так и приватные, и разделить их невозможно со 100% уверенностью. К Метрике это не относится. Но мне кажется, они об этом думают и не раз. Возможно, публичная позиция недостаточна разжевана и не так ласкова? 2. Ответственность лежит на вебмастерах/программистах. Они должны моделировать все варианты негативного развития событий и готовить меры по избежанию подобных сценариев. Технически: ставить чужой контент (метрики, счетчики и даже картинки) на страницы с приватными данными — большая глупость. Да и вообще использовать чужие счетчики для обсчета статистики — это недорогое занятие самообманом и мучение для клиентов. С реферами тоже можно бороться. Для параноидальных вариантов — ну шлите одноразовые пин-коды на мобильные или почту — теле2 в пример. Раз ставят клиенты счетчики — так разнесите шаблоны, сюда зя, сюда низя. И robots.txt тоже, ну вдруг ссылка все же стала известна поисковику — он не станет ее смотреть, хотя бы. Вы же профессиналы программисты? Или лишь только про-ё-коммерс? Возможностей обезопаситься — масса — не использовано ничего. 3. Причина непрофессинализма — в быстром росте рынка. Как только рынок стабилизируется (леть через дцать) и пройдут прыщи у разработчиков, то придет качество и понимание как оно работает. Постоянный поток новых кодеров, низкие зарплатные ставки не смогут поднять средний уровень профессионализма. А лицензии только могут сделать рынок неконкурентным и коррумпированным. Можно подумать, что у известных разработчиков дырок не было. С другой стороны — ну снесет с рынка 80-100-1000 e-shop’ов — будет урок другим — IT — не в паровозики играть. Ньюансы стоят дорого. Чем дальше тем дороже. Взрослеет IT. 4. Может пора все-таки начать в практику вводить ответственность разработчиков перед клиентами? так чтобы убытки и моральный ущерб покрывались хоть в какой-то степени? может тогда, у экономистов появятся больше резонов заботится о надежности продукта для пользователя и инвестировать в безопасность? Можно и страховать свою ответственность. Только не как обязательное, а как конкурентное преимущество. А пока ответственность понесут владельцы магазинов и смс-центров. Я думаю, пункт AS-IS надо удалить из EULA. Мы же защищаем права правообладателей. Надо защищать и интересы лицензиатов. Их больше и они кормят эту индустрию и оплачивают все ее капризы.

Пока клиенты (владельцы магазинов и других компаний) не осознают, что нормальный сайт или интернет-магазин не может стоить 10-20 тыс. рублей, ситуация не изменится. За нормальную качественную разработку нужно платить нормальные деньги. Это понимают все участники рынка, но не клиенты. Поэтому и разрабатывает им интернет-магазины и сайты хороший мальчик, сын главного бухгалтера Марь Иванны, который и не слышал никогда про эти загадочные robots.txt и noindex’ы. С Мегафоном, конечно, ситуация иная. И это «звоночек» для всех разработчиков, что нужно ответственнее относиться к персональным (личным) данным и информации, которая потенциально может попасть в индекс поисковиков.

> Сертифицирование ПО для веба нужно. Ясно же. Ой, блин, только не это. Потому что > лицензии только могут сделать рынок неконкурентным и коррумпированным Сертифицированное ПО нужно платежным системам (ЯД, Paypal, Assist и т.д. ), всей остальной e-commerce нужно как можно меньше знать о своих клиентах. Доставка в электронном виде? вообще ничего знать не надо. Почтой? почтовый адрес доставки, контактный телефон по желанию, точка. Все остальные транзакции (претензии, отзыв) — по идентификатору заказа (который делаем хэшем с солью и с PGP подписью). А то сейчас, если хочешь какие-то услуги за деньги оказывать, то (по закону) пожалуйте договор, а там и ФИО, и паспортные данные, и все это надо хранить — а кому это надо? Да, такой порядок скорее всего потребует внесения изменений в ГК; так это их надо вносить, а не закон о лизензировании ПО писать или ужесточать закон о персональных данных (который и так совершенно безумный).

>> что нормальный сайт или интернет-магазин не может стоить 10-20 тыс. рублей, То то Win Про стоит — 7К, а люди все не понимают кому надо разницу между 200К-7К заносить. Вы расскажите чтоль.

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

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

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

соль кк раз в том, что мы можете передавать такие коды где угодно, кроме GET запросов, это напрямую указано в RFC (или как оно там называется)

> URL с уникальным хэшем это один из способов авторизации эх… а ROT13 — это один из способов шифрования. Что, действительно требует разъяснять разницу между куками и кодом в url?

> это напрямую указано в RFC в каком? > Что, действительно требует разъяснять разницу между куками и кодом в url? вы знаете лучший способ авторизации без регистрации? (куки для проверки статуса заказа не катят — заказ мог быть сделан с другого компа или браузера)

> 2. Ответственность лежит на вебмастерах/программистах. Они должны моделировать все варианты негативного развития событий и готовить меры по избежанию подобных сценариев. Дружище, тут по факту выходит, что пара-тройка уважаемых напичкала сеть троянами, которые считывают приватную информацию и какбе предъявила людям такой ультиматум: Если вы не напишете некую последовательность символов там, где мы вам укажем, вся ваша приватная инфа будет слита в паблик. Здесь я не понимаю, почему вебмастер обязан следовать наглым требованиям кучки уважаемых. Почему вебмастер должен отвечать своей свободой только за то, что он не желает или не умеет выполнять требования каких-то частных контор. Не хочет или не умеет создавать или править некий файл, который от него незаконно требуют наглецы. Мое мнение, что такие требования группы лиц ничем не отличаются от требований предъявляемых террористами.

> вы знаете лучший способ авторизации без регистрации? Есть два случая — у клиента есть доступ к почте, у клиента нет доступа к почте. В первом случае, вы просто высылаете ему статус заказа на почту, никуда ходить для проверки не надо. Во втором случае лучше всего сработают куки, но если вам обязательно хочется, чтобы клиент мог поменять устройство — покажите ему код заказа картинкой, а потом сделайте форму для доступа. На крайний случай, если вы абсолютно настаиваете, чтобы это была ссылка в почте, сделайте доступ по такой ссылке одноразовым, присылая после каждого входа апдейт с новым кодом. И это все из головы — наверняка, придумано еще масса вариантов. >> это напрямую указано в RFC >в каком? Вас забанили не только в Яндексе, но и в Google? Только в этот раз: rfc2616 (HTTP1.1), в котором указано, что GET запросы должны кэшироваться, если не указано обратного, а POST — НЕ должны, если не указаны обратного.

> Здесь я не понимаю, почему вебмастер обязан следовать наглым требованиям кучки уважаемых :))) Этот пассаж особенно классно смотрится в разрезе того, что весь интернет — это не более, чем договоренность «кучки уважаемых». Ситуация строго обратная — в интернете вам никто ничего не гарантирует, даже robots.txt. Если вебмастер не хочет, чтобы его информация попала не туда, куда следует, он должен позаботится об этом сам. Не захотел/не смог — может и в тюрьму сесть (хотя вряд ли, конечно).

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

> Только в этот раз: rfc2616 (HTTP1.1), в котором указано, что GET запросы должны кэшироваться, если не указано обратного, а POST — НЕ должны, если не указаны обратного. Это вы вообще к чему? причем тут кэширование на стороне сервера или прокси? вы говорили, что в RFC якобы написано, что GET параметры публичны и не секретны Поведение протокола для кэширования GET и POST запроса по умолчанию (и тот и другой можно как кэшировать так и не кэшировать, если прямо указать) вообще никак не соотносится с утверждением, что этот запрос является публичным и что через GET параметры нельзя передавать приватную информацию. Это очевидно уже из факта прописывания в стандарте GET форм.

Причем здесь robot.txt? Это действительно всего лишь рекомендация. Вебмастер может (и должен) быть наказан за то, что выложил персональные данные на страницы, которые мало того, что доступны без знания пароля, так еще и благодаря его же усилиям (кто на эту страницу Яндекс.Метрику поставил?) попали в индекс. Т.е. вебмастер сначала вывалил данные на доступные страницы, потом послал ссылки на эти страницы третьим лицам (Яндексу, не считая многочисленных прокси по пути), да еще и даже таблички «Не смотреть» (т.е. файла robots.txt) не вывесил. Я уж не говорю про то, что по закону обмен этими данными явно должен идти под TSL/SSL — об этом-то не сложно догадаться?

> Это очевидно уже из факта прописывания в стандарте GET форм. Каким именно боком?!

> Каким именно боком?! вот почитайте http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#submit-format там указано единственное различие для применения GET и POST форм — The «get» method should be used when the form is idempotent (i.e., causes no side-effects). Many database searches have no visible side-effects and make ideal applications for the «get» method. If the service associated with the processing of a form causes side effects (for example, if the form modifies a database or subscription to a service), the «post» method should be used. И не слова про то, что GET формы публичны И кстати, вы так и не показали, где в RFC сказано, что в параметрах GET запросов нельзя передавать секретные данные. Этого там нет?

> Вебмастер может (и должен) быть наказан за то, что Вебмастер не может отвечать за то, что его секретный урл, скажем сгенеренный с мд5, подсмотрели с помощью бара или браузера. Ровно так же он не должен быть в ответе за то, что, скажем гугл аналитикс считал пароль вбитый юзером с клавы.

2 umkalive Скорее всего, URL ставшие известными поисковым системам через toolbar — не попадают в индекс. И пока никем не доказано обратное. Как только Вы своих логах увидите посещение посторонних по «секретным» URL, известных только toolbar’у — сразу пишите, нет, КРИЧИТЕ здесь. Полагаю, в Яндексе думают прежде, чем сделают. Подобные действия затрагивающие приватность, в любых компаниях, дорожащих своей репутацией, обсуждаются неоднократно. Наверно, Гуглу до сих пор снятся его wifi сниферы. Пока, существующие факты демонстрируют жуткую неграмотность вебмастеров/программистов «пострадавших» сайтов. Расставить счетчики сервиса статистики на приватные страницы — это же насколько надо не понимать механизма работы сетевых сервисов и возможных последствий?

> Crio: > Только в этот раз: rfc2616 (HTTP1.1), в котором указано, что GET запросы должны кэшироваться, если не указано обратного, а POST — НЕ должны, если не указаны обратного. Да, и в этом RFC тоже указано на основное отличие GET и POST — первый тип запросов безопасен в плане изменения данных и может выполнятся много раз подряд с тем же результатом, второй тип предназначен для модификации данных. Именно этим объясняется различие в стратегии кэширования. А вовсе не тем, что POST якобы предназначен для секретных данных.

Петр, из соседней ветки ссылка: http://forum.searchengines.ru/showpost.php?p=9239428&postcount=623 Я не проверял, но верю. Ибо.

> Расставить счетчики сервиса статистики на приватные страницы — это же насколько надо не понимать механизма работы сетевых сервисов и возможных последствий? Просто они излишне доверились Яндексу, который раньше не занимался индексированием приватных ссылок, и не ожидали от него такой «подставы» Кстати, ребята с sms.prm.ru писали, что у них не стояла метрика, а урлы Яндекс собрал через виджет. Тут вообще нет слов. Особенно доставляет, что вся приватная инфа была только в URL — на сайте ничего не хранилось. Это даже индексацией нельзя назвать, тут просто взяли и снифингом получили приватные данные.

jet: А где в RFC указано, что по этому протоколу МОЖНО передавать секретные данные и кто-то будет заботиться о их секретности? HTTP1.1+html в голом виде вообще не предназначены для передачи приватных/секретных данных. Точка. Для этого есть TSL/SSL. Но уж если вы настаиваете, то постарайтесь в рамках протокола сделать так, чтобы ваши данные не осели везде, где только можно. Не используйте запрос, который будет кэшироваться вместе своей секретной страницей будет наа фиг знает каком количестве фиг знает чьих проксей на фиг знает какой срок.

2 umkalive > из соседней ветки ссылка: > http://forum.searchengines.ru/showpos…tcount=623 Посмотрел несколько сайтов из списка по этой ссылке — везде есть чужой контент в различных комбинациях. Стоит любому вебмастеру сайта ссылка, на который поставлена с этой «секретной» страницы, держать свою статистику переходов в открытом доступе, как до этой страницы дойдут пауки. Это же очевидно, разве нет? жмем ctrl-u digisat: yandex direct, куча внешних ссылок и чужого контента. zavidovofest: лишь google-analytics. Время заказа: 07.06.2011 22:57:00 — что было позавчера и месяц назад — не знаю, за почти два месяца коллекция счетчиков на этой странице могла поменяться. nogtishop: LiveInternet counter и куча всего другого. netoptika: (О! пропатчились — есть запрос фамилии почему-то ввожу «Юрова» — и все показывают) mc.yandex.ru/metrika/… стоит Вы уж посмотрите сами, чтобы это… мы время не тратили зря. Про яндекс.бар они сами написали — яндекс.бар ссылки в индекс не передает. Пока что, я им верю. А что было неделю назад — поздно уже проверять. Я же говорю, надо доказать факт слива ссылок в поисковый индекс из тулбаров или других компонент броузеров. Пока ни одного серьезного исследования на эту тему я не видел. Да, сами ссылки сливаются, но пауки по ним не приходят. Я верю только своему access.log

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

2 umkalive 4ppc.ru: http://www.kmindex.ru/ref-x.asp?idn=80849&report=2#1 эпично. http://www.kmindex.ru/ref-x.asp?host-…report=2#1 Каждый покупатель ( у которого сработает счетчик ) попадет в историю! Помоему, годится как слоган. Слоган отдается бесплатно про-ё-коммерсам. я даже не знаю, что добавить? Что «dlyanachalas» (Академик) — гонит чушь? Это понятно.

Петр, Спасибо, за доброжелательный настрой и за то, что не поленились потыкать самостоятельно. > Я же говорю, надо доказать факт слива ссылок в поисковый индекс из тулбаров или других компонент броузеров. Я думаю, что теперь за этим делом проследят. И это уже неплохо. Теперь по существу вопроса: Как вы думаете, можно ли лишить вебмастера свободы за то, что он не желает настраивать роботс.тхт так, как от него требует, скажем, ООО «Гугл», или, например, моя контора с LTD на конце?

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

> в принципе да Тогда у моего LTD куча требований. )))

Поздравляю!

umkalive, предлагаю поразмыслить над вопросом: какие законы нарушает и какой ответственности подлежит оператор робота, который игнорирует файл robots.txt

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

Друзья, я полагаю, что вы не станете спорить с тем, что Яндекс должен был предупредить вебмастеров, что использование продуктов Яндекса не предполагает использование вебмастером метода гет для шифрования приватной инфы. То, что такого предупреждения не было — есть косяк как с юридической так и с человеческой точки зрения. И еще: Я не спорю, что те вебмастера, что попали под раздачу — балбесы. Но также надо помнить, что мы ответственны за тех кого приручили. ))

> Яндекс-Бар это вредоносное программное обеспечение, которое перехватывает информацию сайтов, которые посещает пользователь равно как и Google chrome, да?

Лучше всего Хром с Яндекс-баром. :)