Что такое браузерный фингерпринтинг?Как сайты отслеживают вас без cookies

Вы можете удалить все cookies, сменить IP на новый и открыть окно инкогнито, а сайт всё равно распознает вас при следующем запросе. Именно так работает браузерный фингерпринтинг. Вместо того чтобы хранить идентификатор на вашем устройстве, сайт выводит его из того, как ваша машина отвечает на сотни небольших вопросов: какой браузер вы используете, как ваш GPU рисует кривую, как ваш аудиостек округляет число, как сформировано ваше TLS-рукопожатие. Достаточно скомбинировать эти ответы, и вы получите значение, стабильное от сессии к сессии и практически уникальное.

Для инженеров, занимающихся скрапингом, это защита, которой безразличен ваш прокси. Ротация IP решает одну проблему и оставляет фингерпринтинг нетронутым, именно поэтому «чистый» резидентный IP всё равно может вернуть вам страницу блокировки. В этой статье объясняется, что такое фингерпринт на самом деле, из каких сигналов он состоит, почему их комбинация идентифицирует вас и что важнее всего для скрапинга: как сохранить согласованность фингерпринта, чтобы IP и браузер совпадали между собой.

Что такое браузерный фингерпринт

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

Ключевая ментальная модель: фингерпринт не сохраняется и выводится заново, тогда как cookie хранится. Cookie, это токен, который сайт разместил на вашей машине, поэтому его удаление разрывает связь. Фингерпринт вычисляется заново из вашего оборудования и программного обеспечения при каждом посещении, поэтому на вашей стороне нечего удалять. Именно это единственное различие объясняет, почему фингерпринтинг переживает три вещи, к которым большинство людей прибегает для сохранения анонимности:

• Очистка cookies. Нет сохранённого токена для удаления; идентификатор вычисляется заново.
• Смена IP. IP, лишь один сигнал среди многих, и большинство сигналов поступают из браузера, а не из сети.
• Режим инкогнито или приватный режим. Приватные окна блокируют историю и cookies, но всё равно раскрывают те же экран, шрифты, GPU и TLS-стек, поэтому фингерпринт почти не меняется.

Сигналы, из которых состоит фингерпринт

Фингерпринт, это не одно значение, а стек сигналов, собранных на разных уровнях. Одни поступают в самом запросе, другие считываются JavaScript после загрузки страницы, а один устанавливается ещё до выполнения какого-либо кода. Понимание того, на каком уровне находится каждый сигнал, позволяет впоследствии рассуждать о согласованности.

Сигналы уровня запроса

Самые дешёвые сигналы поступают прямо из HTTP-запроса, ещё до выполнения единой строки JavaScript:

• User-Agent и заголовки. Браузер и версия, которые вы указываете, плюс точный набор и порядок заголовков в запросе. Реальные браузеры отправляют согласованный, предсказуемый набор заголовков; простой HTTP-клиент обычно отправляет меньше заголовков в другом порядке, что легко выдаёт себя.
• Accept-Language и часовой пояс. Языки, которые рекламирует ваш браузер, и через JavaScript, часовой пояс вашей системы. IP дата-центра в США в сочетании с московским часовым поясом и вьетнамским языковым заголовком, явное несоответствие.
• Экран и глубина цвета. Разрешение, доступная площадь экрана, соотношение пикселей устройства и глубина цвета. Распространённые значения разделяют миллионы людей; нестандартные сужают круг очень быстро.

Сигналы, требующие JavaScript-рендеринга

Для их получения требуется реальный движок рендеринга. Простой HTTP-клиент вообще не может их сгенерировать, и их отсутствие само по себе является сигналом.

• Шрифты. Набор шрифтов, установленных в вашей системе, определяемый путём измерения рендеринга тестовых строк. Комбинация удивительно информативна.
• Canvas-фингерпринтинг. Страница рисует текст и фигуры на невидимый HTML5-canvas, а затем считывает пиксели обратно. Ваша специфическая комбинация GPU, драйверов, сглаживания и растеризации шрифтов производит крошечные различия на уровне устройства, и хеширование пиксельных данных даёт стабильную подпись.
• Аудио-фингерпринтинг. Web Audio API генерирует тон через осциллятор и компрессор, а затем считывает полученный буфер. Точный вывод с плавающей точкой зависит от вашего аудиостека и оборудования, поэтому производное значение согласованно на вашей машине и отличается на разных устройствах.
• WebGL и GPU. WebGL API сообщает строки рендерера и производителя, а также то, как он рисует 3D-сцены, раскрывая GPU и драйвер за браузером.

Canvas-считывание достаточно мало, чтобы показать его. Страница никогда не отображает этот canvas; она рисует на нём за кадром и сериализует результат:

const canvas = document.createElement("canvas")
const ctx = canvas.getContext("2d")

ctx.textBaseline = "top"
ctx.font = "14px Arial"
ctx.fillText("Crawlbase fingerprint \u{1F4A1}", 2, 2)

// Same code, different pixels per GPU/driver/font stack.
const signature = canvas.toDataURL()
const fp = hash(signature)

Сигнал, который большинство клиентов воспроизводит неверно: TLS / JA3

Рукопожатие происходит до HTTP, до JavaScript, до чего-либо, что вы контролируете в коде. Когда ваш клиент открывает TLS-соединение, он отправляет Client Hello, содержащий перечень поддерживаемых наборов шифров, расширений и эллиптических кривых в определённом порядке. Эта форма согласована для данной клиентской библиотеки и версии, и её хеширование даёт JA3-фингерпринт. Рукопожатие Chrome выглядит как Chrome; библиотека Python requests выглядит как Python.

Именно этот уровень останавливает большинство парсеров, и никакая строка User-Agent не может это исправить. Вы можете установить все заголовки так, чтобы заявить, что вы Safari на iPhone, но если ваше TLS-рукопожатие соответствует HTTP-библиотеке Python на Linux, два уровня расходятся, и защитник, сравнивающий их, немедленно видит ложь. Рукопожатие устанавливается вашим сетевым стеком, а не заголовками, поэтому его спуфинг означает изменение самого клиента.

Почему комбинация идентифицирует вас

Ни один отдельный сигнал не является уникальным. Миллионы людей используют одну и ту же версию браузера при разрешении 1920x1080. Сила заключается в комбинации: сложите вместе свой браузер, ОС, шрифты, часовой пояс, хеш canvas, хеш аудио, рендерер WebGL и форму TLS, и совокупное значение становится настолько редким, что выделяет именно вас. Исследования реального трафика помещают идентификацию устройства где-то в диапазоне 90–99%, и эти цифры следует рассматривать как наблюдаемые показатели из конкретных наборов данных, а не как гарантию того, что каждый браузер уникально идентифицируем.

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

Как фингерпринтинг блокирует парсеры

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

Вот ловушка. Вы покупаете ротирующие резидентные IP, устанавливаете убедительный User-Agent и всё равно получаете блокировку. Ротация IP выполнила свою работу, но фингерпринтинг никогда не смотрел на IP изолированно. Он смотрел на всю картину, и картина была противоречивой:

• Постоянный фингерпринт за ротирующими IP. Если каждый запрос разделяет один хеш canvas и одну TLS-подпись, пока IP меняется каждый раз, у вас одно «устройство», телепортирующееся по всему миру. Этот паттерн сам по себе является флагом.
• Внутренне противоречивые уровни. TLS-подпись дата-центра Linux, заявляющая через User-Agent, что она является Safari на iPhone. iOS Safari не производит такое рукопожатие и не работает на таком оборудовании. Противоречие, это улика.
• Отсутствующие сигналы, которые всегда есть у реального браузера. Нет canvas, нет WebGL, нет аудио-контекста, скудный набор заголовков. Реальный браузер производит всё это; простой HTTP-клиент не производит ничего из этого, и разрыв очевиден.

Поэтому правило не «ротируйте интенсивнее». Правило, согласованность на всех уровнях. Происхождение IP, заголовки, TLS-рукопожатие и сигналы, требующие JavaScript-рендеринга, должны описывать одного правдоподобного человека на одном правдоподобном устройстве. Это та же проблема согласованности, что стоит за обходом Cloudflare и уклонением от обнаружения ботов, и большая часть причины, по которой парсеры сталкиваются с CAPTCHA при скрапинге: вызов нередко срабатывает из-за несогласованного фингерпринта, а не из-за IP в отдельности.

Что реально с этим делать

У вас есть три реалистичных пути, и они по-разному сочетают усилия и контроль.

• Запустите реальный или headless-браузер с рендерингом. Настоящий браузерный движок производит реальные сигналы canvas, WebGL, аудио и шрифтов, а его TLS-рукопожатие соответствует его User-Agent, потому что это одно и то же программное обеспечение. Это закрывает разрыв «отсутствующих сигналов» и разрыв «TLS не соответствует браузеру» за один шаг. Стоимость, скорость и ресурсы: рендеринг значительно тяжелее, чем простой запрос.
• Используйте антидетект-браузер. Эти инструменты дают каждой сессии намеренно созданный, внутренне согласованный профиль, варьируя сигналы вместе, чтобы уровни оставались правдоподобными. Полезно для небольших, сессионно-насыщенных работ; управление многими согласованными профилями в масштабе, отдельная задача.
• Используйте управляемое решение. Сервис, который поддерживает весь фингерпринт согласованным за вас, представляя правдоподобный браузер и сочетая его с совпадающим IP, чтобы вы направляли на один эндпоинт, а не поддерживали весь стек самостоятельно.

Будьте честны с собой насчёт второго по привлекательности варианта: создание согласованного фингерпринта вручную с помощью простых HTTP-запросов. Это реализуемо в принципе, но это сложно и хрупко. Вам нужно привести TLS-рукопожатие в соответствие с заявленным браузером, отправить точный набор и порядок заголовков, которые отправляет реальный браузер, и поддерживать всё это в синхронизации по мере изменения версий браузеров и эволюции методов обнаружения. Одно устаревшее значение, и уровни снова расходятся. Для большинства команд бремя поддержки перевешивает экономию, именно поэтому рендеринг или управляемый уровень обычно побеждают. Если вы хотите более широкое руководство, смотрите как парсить сайты без блокировок.

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

Часто задаваемые вопросы

Что такое браузерный фингерпринтинг?

Браузерный фингерпринтинг, техника, которая строит уникальный идентификатор для вашего устройства из конфигурации и поведения, раскрываемого вашим браузером, таких как ваш User-Agent, экран, установленные шрифты, GPU, аудиостек и TLS-рукопожатие. Комбинация этих сигналов хешируется в значение, которое, как правило, остаётся одинаковым между посещениями. На вашем устройстве ничего не хранится, поскольку идентификатор повторно вычисляется из вашего окружения каждый раз.

Чем фингерпринт отличается от cookie?

Cookie, это токен, который сайт хранит на вашей машине, поэтому его удаление разрывает связь. Фингерпринт выводится заново, измеряется свежо из вашего оборудования и программного обеспечения при каждом посещении, поэтому на вашей стороне нечего удалять. Вот почему фингерпринтинг переживает очистку cookies, смену IP и использование режима приватного просмотра.

Могу ли я избежать фингерпринтинга, очистив cookies или используя инкогнито?

Нет. Эти действия удаляют сохранённые данные, но фингерпринт не хранится; он повторно вычисляется из таких сигналов, как ваш экран, шрифты, GPU и TLS-стек, которые режим инкогнито не меняет. Приватные окна скрывают историю и cookies, но раскрывают те же характеристики устройства, поэтому фингерпринт почти не меняется.

Почему мой парсер блокируется даже при ротирующих прокси?

Потому что фингерпринтинг не смотрит на IP изолированно. Если каждый запрос несёт один и тот же хеш canvas и TLS-подпись, пока IP ротируется, вы выглядите как одно устройство, телепортирующееся по всему миру. Если ваше TLS-рукопожатие указывает на Python на Linux, пока User-Agent заявляет Safari на iPhone, уровни противоречат друг другу. Любой паттерн помечается независимо от того, насколько чист IP.

Что такое TLS или JA3-фингерпринтинг?

Когда ваш клиент открывает HTTPS-соединение, TLS Client Hello перечисляет поддерживаемые наборы шифров, расширения и кривые в определённом порядке. Хеширование этой формы даёт JA3-фингерпринт, характерный для клиентской библиотеки и версии. Он устанавливается вашим сетевым стеком, а не вашими заголовками, поэтому нередко разоблачает парсер, User-Agent которого заявляет браузер, которым он не является.

Как лучше всего парсить в обход фингерпринтинга?

Поддерживайте фингерпринт согласованным на каждом уровне. Запустите реальный или headless-браузер, чтобы отрендеренные сигналы и TLS-рукопожатие действительно соответствовали заявляемому браузеру, или используйте управляемый уровень, который сочетает правдоподобный фингерпринт с совпадающим IP реального пользователя. Ручное создание согласованного фингерпринта с помощью простых HTTP-запросов возможно, но сложно поддерживать по мере эволюции браузеров и методов обнаружения.

TA

Thomas Adewale

Технический писатель · Crawlbase

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