Force stopped listing что это такое
Эксперимент в Яндексе. Как идентифицировать взломщика с помощью машинного обучения
На серверах Яндекса хранится много нужной и важной для людей информации, поэтому нам необходимо надёжно защищать данные наших пользователей. В этой статье мы хотим рассказать вам о наших исследованиях, в которых мы изучаем, как отличить владельца аккаунта от злоумышленника. Причем даже тогда, когда оба имеют логин и пароль от учетной записи. Мы разработали метод, который основан на анализе поведенческих характеристик пользователей. Он использует машинное обучение и позволяет отличать поведение настоящего владельца аккаунта от злоумышленника по ряду характеристик.
Такой анализ базируется на математической статистике и изучении данных об использовании сервисов Яндекса. Поведенческих характеристик недостаточно, чтобы однозначно идентифицировать пользователя и заменить тем самым использование пароля, но это позволяет определить взлом уже после авторизации. Таким образом, украденный пароль от почты не даст прикидываться её настоящим владельцем. Это по-настоящему важный шаг, который позволит по-другому взглянуть на системы безопасности в интернете и решить такие сложные задачи, как определение настоящего владельца аккаунта, а также момента и характера взлома.
Принято полагать, что способы распознавания человека появились относительно недавно, но на самом деле история различных методов идентификации уходит своими корнями в Средние века. Известно, что в древнем Китае на рубеже 14-15 веков уже догадались использовать отпечатки пальцев. Правда, применяли этот метод ограниченно — купцы таким образом подписывали торговые соглашения. В конце 19 века уникальность папиллярных линий легла в основу дактилоскопии, основоположником которой стал Уильям Гершель. Именно он выдвинул теорию о том, что рисунок ладонных поверхностей человека не меняется в течение всей его жизни.
Дактилоскопическая карта Гершеля
С развитием информационных технологий появились различные системы распознавания пользователя. В большинстве своем эти методы созданы, чтобы человек мог контролировать доступ в какую-то систему, но на самом деле область идентификации и аутентификации пользователей значительно шире.
Ученые всего мира бьются над проблемой идентификации людей по различным признакам. Есть разные модели и теории: от самых популярных, где для распознавания используются уже упомянутые отпечатки пальце, радужная оболочка глаз, голос, до новых и спорных, в которых учитываются движения мышки, клавиатурный «почерк» и поведение на сайте. Яндекс тоже активно занимается изучением существующих моделей и созданием новых. Мы находимся в самом начале пути, но уже достигли некоторых успехов, поэтому хотим вам немного рассказать о наших экспериментах.
Над алгоритмами защиты ящиков от взлома, спама и вредоносной деятельности, которая может нанести ущерб пользователю, мы работаем постоянно. Те методы контроля доступа, которые уже существуют, затрудняют злоумышленникам проникновение в почтовый ящик, но, увы, не решают проблему взлома полностью. Узким местом остается использование пароля, который может быть потерян, украден, перехвачен или подобран. Например, перехват пароля может произойти, если вы используете пароль от Яндекса на других сервисах, где не поддерживается безопасное соединение.
Мы задумались: «А возможно ли отличить взломщика от настоящего владельца аккаунта, если оба авторизуются одним и тем же паролем?» Оказалось, что да. Наши исследования показали, что поведение владельца почтового ящика всегда отличается от того, как ведет себя взломщик.
Вообще из поведения пользователя в почте можно выделить ряд характеристик: время входа, обычное месторасположение, количество авторизаций, используемых устройств и др. Есть операции, которые не характерны для конкретного человека. Например, удаление прочитанных писем, стирание папок, отправка рассылок. У человека может сложиться определенное поведение при работе с разными типами писем: прочтение писем от людей, удаление рассылок, игнорирование писем из социальных сетей. Кроме того, существуют и такие привычки как «читает цепочку непрочитанных писем снизу вверх», «авторизуется и идет сначала в Почту, потом — в Диск и уже следом — в Новости» и так далее. Такие паттерны поведения могут быть вычислены для многих наших сервисов. Из совокупности этих факторов и складывается профиль пользователя, который не дает полного представления о самом пользователе, но позволяет отличить факт взлома аккаунта от нормальной авторизации. Конечно, этот подход не может быть эффективным без использования машинного обучения. С его помощью определяется набор факторов, которые влияют на профиль, и границы для определения взлома.
Суть этого метода очень проста: каждый имеет привычки, свойственные только ему, начиная с режима работы и отдыха, продолжая местами, в которых человек бывает, и количеством устройств, которыми он пользуется. Например, кто-то всегда проверяет почту из дома и работы, использует два устройства, никогда не удаляет прочитанные письма и не рассылает спам. Он использует почту в дневные часы и никогда не проверяет почту ночью. А кто-то в течение месяца часто бывает в командировках и периодически читает почту из разных стран. У этих пользователей будут различные паттерны поведения, на основе которых можно построить индивидуальный профиль и сравнивать с ним каждый новый заход в почту.
Вот так выглядят профили двух разных людей. На красном графике показан профиль обычного не взломанного пользователя. Видно, что всё достаточно равномерно, и при этом нет резких скачков параметров. Синий график иллюстрирует поведение подозрительного аккаунта: все показатели сильно скачут, прослеживается хаотичное обращение к ресурсу. Это дает возможность предположить факт несанкционированного доступа.
А на этом графике изображено изменение профиля в момент взлома. В синей области видно, что показатели находятся в норме, в то время как в красной зоне уже прослеживаются значительные колебания. Кроме того, отчетливо видны даты, в которые это произошло, что может значительно упростить поиск места взлома.
Такой подход может обезопасить пользователей от кражи паролей и сессионных кук и позволит детектировать взлом даже после авторизации в аккаунте.
Мы пока не готовы говорить о запуске полностью работающей системы определения взлома. Еще не все детали пазла собраны — потребуется время, чтобы в полной мере оценить и научиться использовать преимущества данных технологий. Но их эффективность очевидна уже сейчас: использование машинного обучения в системах защиты информации способно сильно повысить безопасность хранимых данных. Так что мы продолжим работу в этом направлении.
Проверка эксперимента force_stopped_listing
Помогите пожалуйста. Не понимаю, что надо сделать.
Предусловие: Пользователь авторизован. Открыта папка Входящие. (Яндекс.Почта)
Открыта консоль разработчика в браузере.
Шаг 1: Включить эксперимент force_stopped_listing. Обновить страницу.
Ожидание: В консоли нет ошибок.
Шаг 2: Совершить переходы между папками.
Ожидание: Зависаний нет. Артефакты не появляются. В консоли нет ошибок.
Ошибки могут быть, это нормально.
Но я не понимаю даже как включить эксперимент.
Я что то пробовал у меня получилось вот это.
Моделирование эксперимента
Есть задача: Человек стреляет по мишени до r-го попадания. Вероятность попадания равна p. \xi —.
Моделирование эксперимента
Здравствуйте. Помогите, пожалуйста, смоделировать эксперимент по 1000 подбрасывниям монеты и.
Результаты секретного эксперимента
ПОМОГИТЕ, ПОЖАЛУЙСТА, РЕШИТЬ Ограничение времени 1 секунда Ограничение памяти 64Mb.
Результаты секретного эксперимента
Помогите пожалуйста решить! Вот условия задачи: Ваши друзья провели совершенно секретный.
читай инструкцию внимательнее )
я так понял. что тут этот вариант
Пример 3:
Вы выполняете тестирование мобильной почты
Первый шаг кейса понятен и пройден, во втором содержится непонятная информация, из-
за которой вы его не можете пройти. Попытки поискать информацию в интернете и в
инструкции к заданию ни к чему не привели.
Порядок ответов на вопросы будет следующий:
•
«Все шаги кейса пройдены?» — нет;
•
«Удалось выполнить хотя бы один шаг?» — да;
•
«Один или несколько шагов некорректны?» — да.
После этого в поле Комментарий необходимо описать, в чем именно заключается
некорректность кейса, например:
В кейсе содержится непонятный термин «деплой qloud-ext». Попытки найти ответ
оказались безуспешны, необходимо уточнить, что это такое и где искать.
Эксперименты в Яндекс.Директе: запускаем первый А/Б-тест
Менеджер проектов по контекстной рекламе в WebCanape Артем Артемов рассказал, как настроить эксперимент в Директе с помощью Яндекс.Аудиторий и проанализировать его работу.
Не бывает одного правильного способа настроить объявление. Делать ставку на единственный вариант настроек, текст, аудиторию — провальная стратегия. Для успеха рекламной кампании необходимо экспериментировать. В незапамятные времена (в прошлом году) мы все тестировали различные сеты настроек вручную, теперь же в Яндекс.Директе появился инструмент, который позволяет автоматизировать процесс A/Б-тестирования. Называется этот волшебный инструмент «Эксперименты».
Когда вы запускаете тест, система случайным образом разделяет аудиторию на сегменты. Количество и размер сегментов вы определяете самостоятельно. При этом выборки могут быть разными — можно установить размер каждой группы от 1% до 99%, чтобы в сумме получилось 100%. Сейчас «Эксперименты» доступны по запросу, и подключают их за пару дней.
Экспериментировать на старте новой кампании обязательно. Мы же запустили этот инструмент на старом проекте с небольшим бюджетом — чтобы попробовать и дальше использовать его на других проектах. Рассказываем, что из этого вышло.
Клиент: «Займ Гарант» — компания выдает микрозаймы физическим лицам.
Регион: Республика Хакасия.
Бюджет: 15 000 рублей (на рекламу в месяц).
Проблема: мы крутим рекламу с 06:00 до 24:00, но в этом промежутке есть временные периоды, которые не приносят конверсии, расходуя бюджет без отдачи. До запуска «Экспериментов» нам приходилось ковыряться в Метрике и разбираться, есть ли эффект от ночных показов. Вручную мы выявили, что крутить рекламу по ночам неэффективно, а теперь задача состоит в том, чтобы определить в диапазоне с 6 до 24 часов периоды, когда реклама не дает желаемых результатов, и перераспределить бюджет.
Решение: подключили «Эксперименты», чтобы провести A/Б-тестирование на день и вечер. Новый новый инструмент Директа упрощает анализ.
Вводная информация о проекте
Мы сотрудничаем с компанией «Займ-Гарант» c 2015 года. За годы работы мы провели всевозможные виды оптимизации. Проект рекламируется по 150 фразам и получает около 300 переходов из рекламы в месяц при средней цене клика 52,47 рубля. Семантическое ядро не требует большого бюджета, потому что трафик по ключевым словам в регионе не такой большой.
Подключение инструмента «Эксперименты» в аккаунте
Инструмент сравнительно новый, поэтому в нашем аккаунте он подключен не был. Чтобы получить к нему доступ, нужно связаться с менеджером Яндекса или оставить заявку на подключение инструмента через форму в разделе «Контекстная реклама». Сейчас сплит-тестирование подключается в экспериментальном режиме для каждого клиента отдельно, на агентском аккаунте подключить инструмент пока нельзя.
В заявке надо обязательно указать логин, домен клиента и примерный план эксперимента (это такая формальность, что можно особенно ничего не расписывать — мы просто написали, что хотим протестировать новый инструмент). Такая заявка попадет к менеджеру, и он откроет доступ к новому инструменту. Но не сразу. Пару дней придется подождать. После подключения в Яндекс.Аудиториях появится вкладка «Эксперименты». С ней мы и будем работать.
Настройка экспериментов
Прежде чем приступить к настройке, продумайте гипотезу, которую будете проверять с помощью сплит-тестов. Кто-то скажет, что гипотезы ограничиваются лишь вашей фантазией, но лучше все-таки отталкиваться от реальной проблемы. Например, наша гипотеза была в том, что в конкретное время суток одно и то же объявление будет приносить больше конверсий, чем в другое. Чтобы ее проверить и выяснить, когда все-таки лучше крутить рекламу микрофинансовой организации, мы решили сравнить эффективность объявлений в разные временные периоды:
Чтобы отключить период с 00:00 до 06:00, нам пришлось потратить время на анализ данных в Метрике. Теперь же, после завершения эксперимента, всю информацию можно будет увидеть в одном отчете.
Первым делом необходимо создать новый эксперимент: придумываем ему название, выбираем счетчик и делим на сегменты (на два и больше).
Важно! Сегменты Экспериментов и сегменты Метрики — это не одно и то же. Это разные сегменты, не связанные между собой.
Нажимаем «Создать эксперимент». Доступ настраивать не нужно, потому что мы все делаем не в агентстком аккаунте. Инструмент пока не подключают в аккаунтах агентств.
Эксперимент для A/Б-тестирования готов и выглядит так:
Если нажать на кнопку «Результаты», откроется Яндекс.Метрика с новым отчетом, в котором подсчет сегментов будет по всем кампаниям. Мы же будем проводить тестирование в рамках одной поисковой кампании, а смотреть результат будет удобнее в Мастере отчетов Яндекс.Директа.
Подготовка кампании для эксперимента и запуск
Для эксперимента взяли рекламную кампанию на поиске. Перед подключением настроенных сегментов необходимо сделать две копии исходной кампании (по количеству тестовых сегментов).
На скриншоте видны исходная кампания и две ее копии с пометками — в нашем случае добавлены названия сегментов.
Дальше нужно установить все необходимые настройки для кампаний исходя из определенных нами условий для сегментов. То есть мы настраиваем в каждой кампании нужный временной таргетинг: для сегмента A выставляем время с 06:00 до 15:00.
Важно! Временной таргетинг не может охватывать меньше 40 часов в рабочие дни.
Когда таргетинги установлены, листаем настройки вниз, пока не увидим раздел «Эксперименты». В нем выбираем нужный эксперимент и сегмент:
Остальные настройки оставляем прежними. Не забудьте сохранить.
Для другой кампании повторяем ту же последовательность действий, но уже используем сегмент B с другим временным таргетингом.
Перед запуском новых кампаний нужно установить в настройках исходной РК дату завершения — день, в который планируется запустить две новые кампании. Ну а в новых кампаниях необходимо установить дату запуска. Для чистоты эксперимента важно, чтобы новые кампании были запущены в один день. На скриншоте выше видно, что исходная кампания завершилась 24 июня 2019 года, и в этот же день запущены две ее копии с экспериментальными сегментами.
Анализ результатов в Мастере отчетов
Мы покрутили объявления три недели, после чего решили посмотреть результаты. За это время должна накопиться статистика, достаточная, чтобы делать выводы об эффективности рекламной кампании.
Чтобы посмотреть результаты, выбираем кампании, в которых проводили A/Б-тестирование и смотрим. Нужно построить отчет во вкладке «Мастер отчетов». Для этого указываем следующие значения:
Затем отмечаем параметры, которые будем сравнивать.
Ниже отмечаем условие фильтрации «Эксперименты» и выбираем нужный эксперимент (если у вас их несколько).
Кампания с сегментом A (время показа — с 06:00 до 15:00) ушла в серьезный отрыв:
При всем этом ставки в обеих кампаниях одинаковые и запущены они были в одно и то же время.
Неограниченные возможности для Экспериментов
Эксперименты от Яндекса — простой в освоении инструмент, позволяющий формировать удобные для анализа отчеты. Раньше при проведении сплит-тестов, чтобы узнать результаты, приходилось перелопачивать всю Метрику, а теперь можно сформировать один отчет, и в нем будут отражены все важные данные по нужным кампаниям.
Удобно, что Эксперименты универсальны. Можно построить любую гипотезу и проверить ее на A/Б-тестах. Здесь удобно сравнивать медийные кампании, разные медиапланы, кампании в РСЯ и на поиске, автоматические стратегии и ручные (если нужно протестировать три стратегии, то потребуется настроить три сегмента) и прочее.
Мы работали с кампаниями на поиске и проверяли эффективность в зависимости от разных временных таргетингов. За три с лишним недели мы накопили достаточно статистики, чтобы понять, в каком сегменте показатели интереснее, и перенаправить бюджеты на более эффективную кампанию. Сейчас, протестировав «Эксперименты» на небольшом проекте, мы запускаем инструмент на крупных клиентах с бюджетом от 100 000 рублей.
Как сэкономить память на вкладках браузера, но не потерять их содержимое. Опыт команды Яндекс.Браузера
Когда браузерам не хватает памяти, они выгружают из нее наиболее старые вкладки. Это раздражает, потому что клик по такой вкладке приводит к принудительной перезагрузке страницы. Сегодня мы расскажем читателям Хабра о том, как команда Яндекс.Браузера решает эту проблему с помощью технологии Hibernate.
Браузеры, основанные на Chromium, создают по процессу на каждую вкладку. У этого подхода множество достоинств. Это и безопасность (изоляция сайтов друг от друга), и стабильность (падение одного процесса не тянет за собой весь браузер), и ускорение работы на современных процессорах с большим количеством ядер. Но есть и минус – более высокое потребление оперативной памяти, чем при использовании одного процесса на всё. Если бы браузеры ничего с этим не делали, то их пользователи постоянно видели бы что-то подобное:
В проекте Chromium борются с потреблением памяти фоновыми вкладками с помощью очистки различных кэшей. Речь не про тот кэш, в котором хранятся картинки загруженных страниц. С ним проблем нет – он живет на жестком диске. В современном браузере много другой закэшированной информации, которая хранится в оперативной памяти.
Также в Chromium уже достаточно давно работают над тем, чтобы останавливать JS-таймеры в фоновых вкладках. Иначе очистка кэшей теряет смысл, т.к. активности в фоновых вкладках их восстанавливают. Считается, что если сайты хотят работать в фоне, то нужно использовать service worker, а не таймеры.
Если эти меры не помогают, то остается только одно – выгрузить из памяти весь процесс рендеринга вкладки. Открытый сайт просто перестает существовать. Если переключиться на вкладку, то начнется загрузка из сети. Если во вкладке было видео на паузе, то оно начнет проигрываться с начала. Если на странице заполнялась форма, то введенная информация может быть утеряна. Если во вкладке работало тяжелое JS-приложение, то понадобится запустить его заново.
Проблема выгрузки вкладок особенно неприятна при отсутствии доступа к сети. Отложили вкладку с Хабром для чтения на борту самолета? Будьте готовы, что полезная статья превратится в тыкву.
Разработчики браузеров понимают, что эта крайняя мера вызывает раздражение у пользователей (достаточно обратиться к поиску, чтобы оценить масштабы), поэтому применяют ее в последний момент. В этот момент компьютер уже тормозит из-за нехватки памяти, пользователи это замечают и ищут альтернативные способы решения проблемы, поэтому, к примеру, у расширения The Great Suspender более 1,4 млн пользователей.
Люди хотят, чтобы браузеры и память экономили, и тормозить при этом не начинали. Для этого вкладки нужно выгружать не в последний момент, а чуть раньше. А для этого нужно перестать терять содержимое вкладок, т.е. сделать процесс экономии незаметным. Но на чем тогда экономить? Круг замкнулся. Но решение нашлось.
Hibernate в Яндекс.Браузере
Многие читатели Хабра уже могли догадаться, что очистить память, но сохранить состояние вкладки вполне возможно, если предварительно выгрузить состояние на жесткий диск. Если по клику восстановить вкладку с жесткого диска, то пользователь не заметит ничего.
Наша команда участвует в разработке проекта Chromium, куда отправляет значительные оптимизирующие правки и новые возможности. Ещё в 2015 году мы обсуждали с коллегами из проекта идею сохранения состояния вкладок на жесткий диск и даже успели внести ряд доработок, но это направление в Chromium решили заморозить. Мы решили иначе и продолжили разработку в Яндекс.Браузере. На это ушло больше времени, чем планировали, но это того стоило. Чуть ниже мы расскажем о технической начинке технологии Hibernate, а пока начнем с общей логики.
Несколько раз в минуту Яндекс.Браузер проверяет количество доступной памяти, и если ее меньше, чем пороговое значение в 600 мегабайт, то в дело вступает Hibernate. Всё начинается с того, что Браузер находит наиболее старую (по использованию) фоновую вкладку. Кстати, в среднем у пользователя открыто 7 вкладок, но у 5% их более 30.
Выгружать из памяти любую старую вкладку нельзя – можно сломать что-то действительно важное. Например, воспроизведение музыки или общение в веб-мессенджере. Таких исключений сейчас 28. Если вкладка не подошла хотя бы по одному из них, то Браузер переходит к проверке следующей.
Если найдена вкладка, которая удовлетворяет требованиям, то начинается процесс ее сохранения.
Сохранение и восстановление вкладок в Hibernate
Любую страницу можно условно разделить на две большие части, связанные с движками V8 (JS) и Blink (HTML/DOM). Рассмотрим небольшой пример:
У нас есть некоторое DOM-дерево и небольшой скрипт, который просто добавляет div в body. С точки зрения Blink, эта страница выглядит примерно так:
Давайте посмотрим на связь между Blink и V8 на примере HTMLBodyElement:
Можно заметить, что Blink и V8 имеют разные представления одних и тех же сущностей и тесно связаны друг с другом. Так мы пришли к первоначальной идее – сохранять полное состояние V8, а для Blink хранить лишь HTML-атрибуты в виде текста. Но это было ошибкой, потому что мы потеряли те состояния DOM-объектов, которые хранились не в атрибутах. А еще потеряли состояния, которые хранились не в DOM. Решением этой проблемы было полное сохранение Blink. Но не всё так просто.
Для начала нужно собрать информацию об объектах Blink. Поэтому в момент сохранения V8 мы не только останавливаем JS и делаем его слепок, но и собираем в памяти ссылки на DOM-объекты и прочие вспомогательные объекты, доступные для JS. Мы также проходим по всем объектам, до которых можно дотянуться из объектов Document – корневых элементов каждого фрейма страницы. Так мы собираем информацию обо всем, что важно сохранить. Остается самое сложное – научиться сохранять.
Если посчитать все классы Blink, которые представляют DOM-дерево, а также разные HTML5 API (например, canvas, media, geolocation), то получим тысячи классов. Практически невозможно написать руками логику сохранения всех классов. Но хуже всего то, что даже если так сделать, то это будет невозможно поддерживать, потому что мы регулярно подливаем новые версии Chromium, которые вносят неожиданные изменения в любой класс.
Наш Браузер для всех платформ собирается с помощью clang. Чтобы решить задачу сохранения классов Blink, мы создали плагин для clang, который строит AST (абстрактное синтаксическое дерево) для классов. Например, вот этот код:
Превращается в такой XML:
Дальше другие написанные нами скрипты генерируют из этой информации код на C++ для сохранения и восстановления классов, который и попадает в сборку Яндекс.Браузера.
Всего у нас генерируется код примерно для 1000 классов Blink. Например, мы научились сохранять такой сложный класс как Canvas. В него можно рисовать из JS-кода, задавать множество свойств, устанавливать параметры кисточек для рисования и так далее. Мы сохраняем все эти свойства, параметры и саму картинку.
После успешного шифрования и сохранения всех данных на жесткий диск процесс вкладки выгружается из памяти до тех пор, пока пользователь не вернется на эту вкладку. В интерфейсе, как и раньше, она никак не выделяется.
Восстановление вкладки происходит не мгновенно, но существенно быстрее, чем при загрузке из сети. Тем не менее мы пошли на хитрый ход, чтобы не раздражать пользователей вспышками белого экрана. Мы показываем скриншот страницы, созданный на этапе сохранения. Это помогает сгладить переход. В остальном процесс восстановления похож на обычную навигацию с той лишь разницей, что Браузер не делает сетевой запрос. Он воссоздает структуру фреймов и DOM-деревья в них, а затем подменяет состояние V8.
Записали видео с наглядной демонстрацией того, как Hibernate выгружает и восстанавливает по клику вкладки с сохранением прогресса в JS-игре, введенного в формах текста и положения видео:
Итоги
В ближайшее время технология Hibernate станет доступна всем пользователям Яндекс.Браузера для Windows. Мы также планируем начать экспериментировать с ней в альфа-версии для Android. С ее помощью Браузер экономит память более эффективно, чем раньше. К примеру, у пользователей с большим числом открытых вкладок Hibernate в среднем экономит более 330 мегабайт памяти и не теряет при этом информацию во вкладках, которая остается доступна в один клик при любом состоянии сети. Мы понимаем, что вебмастерам было бы полезно учитывать выгрузку фоновых вкладок, поэтому планируем поддержать Page Lifecycle API.
Hibernate – не единственное наше решение, направленное на экономию ресурсов. Мы не первый год работаем над тем, чтобы Браузер адаптировался под имеющиеся в системе ресурсы. К примеру, на слабых устройствах Браузер переходит в упрощенный режим, а при отключении ноутбука от источника питания – снижает энергопотребление. Экономия ресурсов – большая и сложная история, к которой мы еще обязательно вернемся на Хабре.