Яндекс.Утечка

Был бы идейный – опубликовал бы сразу.

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

Ну и не известно насколько дата на файлах аутентична.

Известно, что она не аутентична, сам «хакер» написал, что данные от июля 2022.

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

вот и вопрос, почему все свои отказались, а с вопросом и ответ

Это давно было? Я слышал разговоры про начало разработки этого сервиса году в 14-м. Что значит отказались? Как ты себе представляешь: все бросают текущие проекты и переключаются на внутренний поиск?
Короче, какие-то у тебя надуманные аргументы. Обычно так и происходит: появляется новая задача — под нее набирают людей. Особенно, если есть бюджет.

У идейного могло от чего-то именно сейчас пригореть.

Ну или действительно искал покупателей, тоже вполне может быть.

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

Печально все это.

Это не очень нормально для консалтинговых компаний (проекты сильно изолированы), но обычное дело для продуктовых компаний. Потому что проекты часто тесно связанны. Например, твой проект дергает какой-то внутренний сервис - здорово иметь возможность посмотреть его исходники, а не только документацию (особенно когда он падает/отвечает что-то не то). Используешь какую-то внутреннюю либу - здорово иметь возможность глянуть как её используют в соседнем проекте. Короче, важно для обмена знаниями о внутренних велосипедах (а в яндексе велосипедов over9000). Посмотреть код бывает быстрее, чем отвлекать коллег.

Монорепы, моногорода, монолитные сервисы, монолитное ядро – Keep It Messy Stupid.

и это относительно актуальный срез текущего состояния этих сервисов.

А вот этого мы не узнаем, пока не будет новых утечек.

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

Никогда такого не было!!111

На опеннете пишут, что там есть файлы вида 20220729_add_alternative_tin_and_update_tin_type_in_clients_options.migr.yaml

Думаю, что какой-нибудь слив Яндекс.Еды/СДЭК гораздо хуже.

Потому что данные ценннее кода, как бы программисты не хотели верить в обратное. 90% почти любого веб-сервиса - тупые CRUD. Большинство всяких сложных алгоритмов сидит в учебниках и научных публикациях, а то и в общедоступных либах.

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

Думаю, что какой-нибудь слив Яндекс.Еды/СДЭК гораздо хуже.

От утечки БД Яндекс.Еды пострадали только пользователи, на сам Яндекс это никакого влияния не оказало.

Пока яндекс монополист - ему вообще ничего не страшно, ни утечки данных, ни утечки кода

Да ладно. А как же репутационные потери?

Нет никаких репутационных потерь. Стали меньше пользоваться? Нет. Уменьшилось количество поставщиков/партнеров? Нет.

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

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

Дату среза будем обсуждать?

Я полагаю кто-то сделал дамп в оную дату, просто чтобы был, может техдир, и он где-то лежал, а теперь утек.

Яндекс.Утечка (комментарий)

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

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

Или нигде нет ничего новее мая?

Ну может быть потом еще пулл делали пару раз.

Хотя бы и потому, что в другой компании сразу спросят: «А почему вы писали свой велосипед, а не развернули условный Solr?»

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

Да нет там ничего такого в исходниках уникального, чего было бы интересно конкурентам. Разбираться во всём этом дольше, чем придумать самому. Максимум упростит поиск дырок.

У винды тоже исходники утекали, помогло кому-то?

у разработчиков есть доступ не только к своему проекту, но и к большому количеству других проектов компании.

Монорепозиторий называется (хотят тут утёк как раз не он, т.к. там не git). Увы, приходится выбирать – безопасность или эффективность. Если бы такого доступа не было, то 10-минутное «посмотреть что у них там в коде» превращается в недельную переписку.

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

мы предлагаем заниматься разработкой поиска по интранету

Видимо, таки взяли специалиста, он поискал по интранету и НАШЕЛ.

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

установка именно этой даты указывает на мотивацию

Или не указывает, а пытается повести по ложному следу.

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

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

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

Ну ты не сможешь про него ничего рассказать на следующем собеседовании по соображениям безопасности, которые в NDA. Проект не закроют, но и на развитие денег не дадут. А поскольку денег проект не приносит, а только жрет ресурсы, которых всегда нехватает, то им будут всегда недовольны, потому что ищет не то и не все и неудобно и пр.пр.пр. Потенциально из него можно было бы сделать проект на продажу наружу, но тут непонятна ЦА. Короче, мрак, а не проект.

Или не указывает. Мне кажется это наиболее вероятным.

Мы в любом случае тут играем в Шерлока, потому что данных слишком мало. Что действительно важно — попытаться определить вектор угрозы и устранить его на своём предприятии, if any. И с этой точки зрения любая сформулированная теория хороша.

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

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

В такой компании NDA может быть очень ограничительным, ты же видишь весь код…

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

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

Неожиданный и резкий опенсорс

Обопенсорсились

В NDA обычно все достаточно размыто. Но даже если проанализировать что нам доступно публично, то все говорит о том, что кроме формулы ранжирования секретов особых да и нет. Я говорю о том, что весь Инет забит статьями/видео от сотрудников Yandex/Google/Facebook/YouNameIt про их внутреннюю кухню.
Да и то, КМК, формулу и прочую кухню поиска хранят в тайне чтобы, условно, сайты/рекламу пользователи не накручивали.

Из вот прямо такого вспомнил доклад от киевского разработчика Яндекса про новый Кинопоиск (который потом пользователи загнобили и его даже откатили), там была куча внутренней кухни, по типу как они использовали Монгу (даже делали на ней распределенные блокировки), как поиск по фильмам работал, исправление опечаток. Никому такие «секреты» не интересны.

На опеннете любопытный комент от анонима 2.162

По большому секрету: в MSK только одна контора занимается (сертифицирована) «внешним хранением» кассет с холодными бэкапами, и уже несколько лет, как она на 100% принадлежит «заокеанским партнёрам». Так что, кто его знает, откуда происходят утечки старых бэкапов...

Монорепозиторий называется (хотят тут утёк как раз не он, т.к. там не git). Увы, приходится выбирать – безопасность или эффективность.

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

Хотя не, с DVCS такая петрушка не прокатит, наверное.

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

И да, т.к. зависимости между либами идут без учёта иерархии, то без полного доступа к исходникам не узнаешь – сломал ты что-то у других или нет. А видеть сразу всё, что сломал – это киллерфича монорепы, атомарный рефакторинг без версионирования.

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

Да, ладно, там у них походу машина времени засветилась в исходниках с некоторыми датами будущих событий =)

https://habr.com/ru/news/t/712888/#comment_25156268

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

Хотя не, с DVCS такая петрушка не прокатит, наверное.

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

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

https://habr.com/ru/news/t/712992/#comment_25157764

Есть интересные примеры отчётов, где они парсят с apple/google сторов параметры чужих приложений, потом ищут их в данных appmetrica и собирают стату по пользователям этих приложений.

Используешь AppMetrica в своём приложении - знай что твои события будут доступны на их внутренней кухне, и как перейдёшь достаточный уровень dau - они запилят конкурента, выкупах тебя или выкинут из поисковой выдачи.

Ну то есть поняли да, собирают чужую пользовательскую базу

К слову о нужности телеметрии.

Что все про даты файлов то? После git clone любого проекта там будут даты конкретных файлов, когда их закоммитили и запушили, и прочие аттрибуты. Если есть там .git, то просто глянуть «git log» коммитов и не гадать.

да же это теперь можно отмечать :)

Тээк, щас заценим!

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

а в файлах есть записи от 20 мая 2022 года.

В одном из файлов есть created at 2022-07-25