Инструменты session replay вроде FullStory и Hotjar записывают мышь, клавиатуру и скроллинг. Как это работает, как обнаружить и как снизить риск.
Да — всё больше сайтов используют скрипты session replay, которые незаметно фиксируют движения мыши, нажатия клавиш, тапы и скроллинг, чтобы кто-то на стороне сайта мог позже посмотреть видеоподобное воспроизведение вашего визита. Инструменты этой категории, прежде всего FullStory и Hotjar, продаются как аналитика для UX-исследований, но по умолчанию они логируют гораздо больше, чем клики и просмотры страниц: они способны почти полностью восстановить всё, что вы делали на странице, иногда включая текст, введённый в поля, которые сайт вовсе не планировал раскрывать.
Ключевые выводы
- Скрипты session replay (FullStory, Hotjar и аналогичные инструменты) записывают движения мыши, нажатия клавиш, тапы, скроллинг и изменения DOM, чтобы воссоздать «воспроизведение» вашего визита.
- Они работают, подключая обработчики к событиям ввода, мыши и скролла и отслеживая мутации DOM — те же браузерные API, которые доступны любой странице, только направленные на слежку, а не на функциональность.
- В большинстве реализаций запись включена по умолчанию (opt-out), а не требует согласия (opt-in): сайты должны сами скрывать чувствительные поля, и аудиты неоднократно показывали, что такое маскирование неполно.
- Часто можно заметить session replay, проверив загруженные скрипты и сетевые запросы страницы на предмет известных доменов поставщиков, либо заметив подозрительно частый служебный трафик при каждом нажатии клавиши.
- Блокировщики контента, расширения для блокировки скриптов и отключение JavaScript для незнакомых сайтов снижают риск; единой универсальной кнопки отказа, работающей везде, не существует.
Что именно фиксирует session replay
Скрипт session replay не просто считает просмотры страниц — он строит запись. В зависимости от настройки он может фиксировать:
- Движения мыши и клики — точный путь курсора, включая наведения на элементы, по которым вы никогда не кликали
- Нажатия клавиш и ввод в формы — символы, набранные в текстовых полях, иногда ещё до отправки формы
- Скроллинг и изменения области просмотра — насколько далеко вы прокрутили, как долго задерживались и что было видно на экране в каждый момент
- Изменения DOM — появление, исчезновение или изменение элементов по мере взаимодействия со страницей, что позволяет инструменту покадрово воссоздать визуальное состояние страницы
Вместе эти сигналы позволяют аналитику (или автоматизированной панели) прокручивать временную шкалу и наблюдать за вашей сессией почти так же, как вы её пережили, — вплоть до движений курсора.
Как работают инструменты уровня FullStory и Hotjar
Поставщики session replay поставляют небольшой фрагмент JavaScript, который сайт добавляет на каждую страницу — так же, как добавляют Google Analytics. После загрузки скрипт подключает обработчики к стандартным браузерным событиям (mousemove, keydown, scroll, input) и следит за изменениями DOM с помощью API вроде MutationObserver. Для этого не требуется никаких особых разрешений браузера — это та же событийная модель, на которую уже опирается любая интерактивная веб-страница, только настроенная на логирование, а не на реализацию функции.
Захваченные события пакетно отправляются на серверы поставщика, где собираются в прокручиваемое «воспроизведение» — по сути, видео, синтезированное из сырых данных о взаимодействии, а не из реальных пикселей. Большинство поставщиков предоставляют API маскирования, позволяющий сайту помечать отдельные поля (например, номер кредитной карты) как «не записывать», но такое маскирование нужно применять целенаправленно, поле за полем, тому, кто интегрирует скрипт. Согласно исследованию EFF о корпоративных технологиях слежки, инструменты session replay неоднократно оказывались источником утечки данных, которые маскирование должно было защищать — включая медицинскую информацию, номера кредитных карт и пароли — потому что фильтрация чувствительных полей «тонкая, кропотливая и трудоёмкая» работа, и сайты часто делают её неправильно или вовсе пропускают.
Как обнаружить скрипты session replay на странице
Чтобы заметить большинство интеграций session replay, специальные инструменты не нужны — достаточно знать, куда смотреть.
- Проверьте источники скриптов страницы. Откройте инструменты разработчика в браузере, перейдите на вкладку Network и перезагрузите страницу. Ищите запросы к известным доменам session replay (FullStory обычно загружается с
fullstory.com, Hotjar — сhotjar.comилиstatic.hotjar.com). Тег скрипта, указывающий на один из таких доменов, — сильный сигнал. - Следите за сетевым трафиком при каждом нажатии клавиши или движении. Скрипты session replay часто пакетно отправляют небольшие POST-запросы по мере вашего взаимодействия со страницей. Если вы видите постоянный поток исходящих запросов при каждом движении мыши или наборе текста, это согласуется с записью session replay, тогда как обычная аналитика обычно отправляет один запрос за просмотр страницы.
- Проверьте глобальные переменные. Многие скрипты session replay добавляют в
windowузнаваемый объект (например, пространство имён конкретного поставщика). Введя в консоли ожидаемую глобальную переменную поставщика после загрузки страницы, можно подтвердить наличие библиотеки. - Посмотрите исходный код страницы на предмет скрипта-загрузчика. Как и большинство сторонних скриптов, загрузчики session replay обычно вставляются небольшим встроенным блоком
<script>в начале страницы — его видно в «Просмотре кода страницы» ещё до того, как что-либо отрендерилось.
Ни одна из этих проверок сама по себе не безупречна — сайт может разместить скрипт на своём домене или переименовать его, чтобы усложнить обнаружение, — но вместе они выявляют подавляющее большинство реальных внедрений, поскольку большинство сайтов используют скрипт поставщика практически без изменений.
Риск для приватности и способы снижения
Основной риск не в том, что session replay существует как технология — многие законные UX-исследования на неё опираются, — а в том, что запись по умолчанию включена (opt-out), а не требует согласия (opt-in), и вся ответственность за корректную защиту чувствительных данных лежит на том, кто настраивает скрипт. Поле формы, которое разработчик забыл замаскировать, менеджер паролей, автозаполнивший поле до того, как сработало правило маскирования, или сотрудник поддержки, прокручивающий запись и случайно видящий номер кредитной карты, набранный с опечаткой и затем исправленный, — всё это реальные, а не гипотетические сценарии сбоя.
Несколько практических шагов снижают вашу подверженность риску:
- Используйте блокировщик контента. Большинство блокировщиков рекламы и трекеров уже включают в свои списки фильтров домены основных поставщиков session replay, блокируя скрипт до того, как он успеет подключить какие-либо обработчики.
- Отключайте JavaScript для сайтов, которым не доверяете, где это практично, — у session replay нет резервного пути без него, поскольку он полностью зависит от выполнения клиентского скрипта.
- Будьте внимательны на формах с чувствительными данными. Если поведение сайта (предпросмотр ввода в реальном времени, необычные задержки) наводит на мысль, что кто-то наблюдает за вводом в реальном времени, избегайте набора значений, которые вы не хотели бы сохранять дословно.
- Проверьте собственную подверженность. Проверка расширений и скриптов браузера BrowserInsight помогает выявить активные скрипты и надстройки, работающие в вашей сессии, а наш гид по приватности расширений браузера рассматривает параллельный риск — то, как расширения читают те же данные, но с другой стороны.
Подводя итог
Session replay — хороший пример того, как функция браузера, работающая точно так, как задумано, всё равно порождает реальную проблему приватности: обработчики mousemove или MutationObserver сами по себе не злонамеренны, но будучи направлены на немаскированные поля форм и переданные третьей стороне, в совокупности дают запись вашей сессии, на которую вы никогда явно не соглашались. Это перекликается с другими техниками автоматизированного сбора данных из нашего руководства по техникам обнаружения ботов — оба подхода опираются на оценку или логирование обычных браузерных сигналов, просто с очень разными целями.
Часто задаваемые вопросы
Session replay — это то же самое, что запись экрана?
Не совсем. Session replay не захватывает настоящее видео или пиксели — он логирует дискретные события (позицию мыши, нажатия клавиш, изменения DOM) и восстанавливает визуальное воспроизведение из этих данных постфактум. Результат выглядит как запись экрана, но настоящий видеофайл на вашем устройстве никогда не создаётся.
Могут ли скрипты session replay увидеть мой пароль?
Не должны, если сайт правильно замаскировал поля пароля — большинство поставщиков по умолчанию исключают поля с type="password". Риск в других чувствительных полях (номера соцстрахования, номера карт, медицинские детали, введённые в свободные текстовые поля), которые разработчики сайта забыли замаскировать, — независимые аудиты обнаруживают это чаще, чем поставщики рассчитывают.
Обязан ли я соглашаться на отслеживание session replay?
Универсального способа отказа не существует, поскольку это реализуется на уровне отдельного сайта, а не через браузерный стандарт вроде Do Not Track. Блокировщик контента, фильтрующий известные домены поставщиков, — самый надёжный способ предотвратить это для каждого сайта по отдельности; законы о приватности в некоторых юрисдикциях также требуют раскрывать это в баннерах согласия, хотя строгость применения сильно различается.
Чем session replay отличается от обычной веб-аналитики?
Стандартная аналитика (просмотры страниц, количество кликов, агрегированные воронки) фиксирует что произошло в сводной форме. Session replay записывает как это произошло на уровне отдельных событий мыши и клавиатуры, а затем позволяет кому-то просмотреть воспроизведение сессии конкретного посетителя — гораздо более детализированную и легче идентифицирующую форму сбора данных.
