Это действительно даёт хороший список кандидатов, например, пользователь gkond писал, что
Нашел свой е-мейл в дампе. Пароль, которой рядом с ним указан автоматически сгенерировал мне сервис paygr.com, в далеком мае 2011 года.
при этом «paygr» встречается 11 раз в списке "+" gmail (доступном, например, тут). Это индикатор, что их база могла быть скомпрометирована. Но представьте, если им об этом заявить, то они скажут в ответ, что пользователи подхватили вирус и он украл эту комбинацию логин-пароль из браузера (или расскажут другую версию про фишинг или перехват трафика пользователей) и это как-то нужно опровергнуть или показать маловероятность этого сценария.
Смысл поста во многом в том, чтобы проверить гипотезу — является ли выложенная база смесью разных коллекцией (или источник один) и оценить качество базы. Во многом похоже, что это подборка из кучи разных мест. Скорее всего она включает в себя дампы разных ресурсов и, в принципе, не представляющая собой никакой угрозы. Поэтому логичным был бы вопрос: кто и зачем это выложил?
Если я отсортирую аккаунты по доменам и выложу в сеть — эти данные станут сенсацией? =)
Не знаю, а это можно заранее и наверняка предсказать? (Ну кроме случая с iCloud.)
В определенных кругах ходят непроверенные слухи, что в этой выборке есть слитые базы ряда ресурсов, но тут, к сожалению, уже придется нетехническими средствами анализировать ситуацию.
Пока слабо себе представляю, какие я смогу предоставить доказательства, что ресурс Х был слит, кроме показаний условного Васи. Было бы здорово придумать некоторый технический метод проверки, что база определенного ресурса была слита.
То есть пароля там нет? Если так, то для стороннего наблюдателя ваш телефон выглядит, как пароль, так как у базы нет никаких метаданных (это CSV с сепаратором в виде ":" и даже без имен столбцов).
Никогда не было заходов на почту с других компьютеров? Заходов через публичный WI-FI? Пароль старый? В смысле, он был установлен недавно или не менялся вот уже много лет? Этот пароль больше нигде с почтой вместе не использовался?
Кросс-чек с невалидными паролями? Как одна из версий возможно, но она не объясняет всех данных — ручная или даже автоматическая валидация паролей явно не проводилась для существенной части базы.
Прослушка трафика — опция безусловно, но как бы это объяснило невалидные пароли? Пустые адреса? Собирали всё подряд и не проверяли, что подходит? Но прослушка сразу четырех провайдеров почты — это довольно сильное утверждение, у меня нет никаких доказательств в подтверждение. Есть идеи, как это можно технически проверить?
А выложенные базы вполне возможно были захламлены умышленно.
Это какая-то теория заговора, попытка объяснить неподходящие под гипотезу данные злым умыслом. Довольно долго бегал по данным, не похоже чтобы кто-то специально сидел и вставлял всякую чушь: она очень разнообразная и в неплохих количествах; еще и измеряемые метрики заранее нужно было бы знать. Еще по части данных мне удалось узнать, что это валидные пароли — но они устарели (почтовые сервисы иногда выдают для них специальные ошибки).
Написание статей в полную рабочую смену, 40 часов в неделю?
Имелось ввиду чистого рабочего времени для написания, у меня часто сбор данных занимает несколько суток (и более), но я учитываю (оценочно) сколько у меня уйдет времени на написание статьи (не то чтобы их много кому-то писал) и говорю цену с учетом затрат. (Хотя и так пишу только тем, кто мне импонирует, и за очень скромные деньги.)
Вообще, мне самой справедливой кажется схема: базовая ставка + бонус.
Базовая ставка из расчета сложности статьи и затраченного времени, если нужно 5-7 часов для работы над статьёй, то базовая ставка должна отражать эту нагрузку.
Бонус, например 30-50% от базовой ставки, получается, если статья набрала N плюсов и\или K просмотров, или по каким-то другим обговоренным параметрам.
Сделал поиск локальным, N-top user-based filtering. Т.е. сначала определяем neighbourhood пользователя, например 15 самых схожих. Потом делаем всё тоже самое только для этого локального подпространства.
Если сделать поиск глобальным, то самая примитивная регуляризация т.е. деление на np приводит к отвратительным результатам.
Упрощенно говоря, у нас есть один пользователь похожий на нас на 0.5 и он рекомендует статью Неведомая хрень и еще десять пользователей рекомендующих статью Хабр всё еще торт, в том числе два пользователя похожих на нас аж на 0.9 (супер высокий показатель), и еще 8 похожих на нас на 0.01.
Тогда для первой статьи Неведомая хрень: 0.5 / 1 ==> ранг 0.5
Для второй Хабр всё еще торт: ( 0.9 + 0.9 + 0.01*8 )/10 ==> ранг 0.19
Т.е. получается, что «далёкие» пользователи создают шум при регуляризации оценки.
при этом «paygr» встречается 11 раз в списке "+" gmail (доступном, например, тут). Это индикатор, что их база могла быть скомпрометирована. Но представьте, если им об этом заявить, то они скажут в ответ, что пользователи подхватили вирус и он украл эту комбинацию логин-пароль из браузера (или расскажут другую версию про фишинг или перехват трафика пользователей) и это как-то нужно опровергнуть или показать маловероятность этого сценария.
Не знаю, а это можно заранее и наверняка предсказать? (Ну кроме случая с iCloud.)
Пока слабо себе представляю, какие я смогу предоставить доказательства, что ресурс Х был слит, кроме показаний условного Васи. Было бы здорово придумать некоторый технический метод проверки, что база определенного ресурса была слита.
Прослушка трафика — опция безусловно, но как бы это объяснило невалидные пароли? Пустые адреса? Собирали всё подряд и не проверяли, что подходит? Но прослушка сразу четырех провайдеров почты — это довольно сильное утверждение, у меня нет никаких доказательств в подтверждение. Есть идеи, как это можно технически проверить?
Это какая-то теория заговора, попытка объяснить неподходящие под гипотезу данные злым умыслом. Довольно долго бегал по данным, не похоже чтобы кто-то специально сидел и вставлял всякую чушь: она очень разнообразная и в неплохих количествах; еще и измеряемые метрики заранее нужно было бы знать. Еще по части данных мне удалось узнать, что это валидные пароли — но они устарели (почтовые сервисы иногда выдают для них специальные ошибки).
xakep.ru/news/mail-gmail-leak/
habrahabr.ru/post/236283/
www.habr-analytics.com/
Написание статей в полную рабочую смену, 40 часов в неделю?
Имелось ввиду чистого рабочего времени для написания, у меня часто сбор данных занимает несколько суток (и более), но я учитываю (оценочно) сколько у меня уйдет времени на написание статьи (не то чтобы их много кому-то писал) и говорю цену с учетом затрат. (Хотя и так пишу только тем, кто мне импонирует, и за очень скромные деньги.)
Базовая ставка из расчета сложности статьи и затраченного времени, если нужно 5-7 часов для работы над статьёй, то базовая ставка должна отражать эту нагрузку.
Бонус, например 30-50% от базовой ставки, получается, если статья набрала N плюсов и\или K просмотров, или по каким-то другим обговоренным параметрам.
Если сделать поиск глобальным, то самая примитивная регуляризация т.е. деление на np приводит к отвратительным результатам.
Упрощенно говоря, у нас есть один пользователь похожий на нас на 0.5 и он рекомендует статью Неведомая хрень и еще десять пользователей рекомендующих статью Хабр всё еще торт, в том числе два пользователя похожих на нас аж на 0.9 (супер высокий показатель), и еще 8 похожих на нас на 0.01.
Тогда для первой статьи Неведомая хрень: 0.5 / 1 ==> ранг 0.5
Для второй Хабр всё еще торт: ( 0.9 + 0.9 + 0.01*8 )/10 ==> ранг 0.19
Т.е. получается, что «далёкие» пользователи создают шум при регуляризации оценки.