Как работают браузерные фингерпринты: полный разбор параметров

Фингерпринтинг vs другие методы отслеживания

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

HTTP-cookie

Наиболее известный способ распознавания пользователей — сохранение уникального идентификатора в браузере (в cookie-файле) и его чтение при каждом визите. Недостаток — пользователь может очистить куки, и тогда сайт потеряет связь с ранее выданным ID. Кроме того, в режиме инкогнито или при блокировке сторонних куки браузером этот метод не работает. Современные браузеры и расширения предлагают все больше средств для блокировки или автоудаления куки, что снижает эффективность подхода. Фингерпринтинг же не требует хранения данных на стороне клиента, поэтому работает даже при отключенных куки и в приватном режиме — достаточно того, чтобы сам браузер предоставил нужные сведения о системе.

LocalStorage, SessionStorage и другие веб-хранилища

Аналогично куки эти технологии сохраняют данные локально в браузере. Скрипты могут читать их при повторных визитах. Однако пользователь может очистить вручную и их, плюс хранилища изолированы по доменам. Сессионное хранилище (SessionStorage) и вовсе живет только в рамках одной вкладки/сессии. 

Есть еще Evercookie — технология, пытающаяся сделать «неудаляемые» куки за счет дублирования идентификатора во всех доступных хранилищах (HTTP cookie, Flash LSO, Silverlight Isolated Storage, IndexedDB и т. д.), а также с помощью кэша и других уловок. Но и Evercookie не всесилен — например, он бесполезен в режиме инкогнито, где данные на диск не сохраняются. Фингерпринтинг же ничего не сохраняет на устройстве, собирая информацию заново при каждом визите, поэтому его сложнее пресечь механизмами очистки.

ETag-трекинг

Не самый распространенный, но существующий метод использования кэша HTTP для идентификации. При первом запросе сервер отдает ресурс (например, один пиксель) с уникальным заголовком ETag. Браузер сохраняет его в кэш. При повторном запросе того же URL браузер автоматически пришлет серверу If-None-Match с ранее полученным ETag. Таким образом, сервер узнает, что это тот же посетитель, по совпадению ETag, даже если куки стерты. Это пассивный способ трекинга, не требующий JavaScript, — идентификатор хранится внутри механизма кэширования. ETag-трекинг трудно обнаружить, он переживает очистку куки (нужно чистить кэш) и срабатывает даже без JS. Однако и с ним успешно справляются при необходимости (отключение кэша, промежуточные прокси, вырезающие ETag-заголовки).

CNAME-cloaking

Прием маскировки стороннего трекера под домен первого уровня сайта с помощью DNS-записи CNAME. Например, скрипт вместо загрузки с tracker.thirdparty.com загружается с субдомена вида tracker.​mysite.​com, который через CNAME на DNS-уровне указывает на сервер трекера. Браузер считает такой запрос как запрос, сделанный с основного ресурса, и блокировщики рекламы/трекеров не распознают в нем сторонний домен — cookies такого трекера тоже рассматриваются как куки с основного ресурса. CNAME-подмена позволяет даже обходить ограничения браузера Сафари — Intelligent Tracking Prevention и подобных механизмов. В контексте фингерпринтинга этот метод важен тем, что дает возможность стороннему скрипту собрать отпечаток и установить куки как будто от имени сайта. По сути, CNAME-cloaking — способ скрыть третью сторону, тогда как фингерпринтинг — способ обойтись вообще без хранимых идентификаторов. В связке они могут усилить слежку (трекер маскируется под сайт и получает максимум данных о пользователе, включая отпечаток, не будучи заблокированным).

Фингерпринтинг

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

Параметры, составляющие отпечаток браузера

Отпечаток формируется из десятков мелких атрибутов, которые в совокупности дают уникальную комбинацию. Часть из них передается автоматически при каждом HTTP-запросе (пассивные признаки), а часть снимается на стороне клиента с помощью JavaScript и Web API (активные признаки).

Пассивные параметры (HTTP-заголовки и соединение)

IP-адрес 

Адрес вашего устройства в сети, определяемый из каждого входящего запроса. Может указывать на геолокацию (страну/город по WHOIS или GeoIP) и принадлежность к организации/провайдеру. Хотя IP часто не уникален (многие пользователи сидят за публичным адресом одного провайдера) и может динамически меняться, он включается в отпечаток как базовый идентификатор сети. Более того, если WebRTC доступен, скрипт может выполнить STUN-запрос и получить ваши реальные IP-адреса. IP сам по себе не постоянен, но в сочетании с другими признаками повышает вероятность уникальности. 

User-Agent

Строка данных пользователя, передаваемая в заголовке User-Agent каждым браузером. Содержит информацию о названии браузера, его версии, движке, версии операционной системы, разрядности, иногда — модели устройства. Пример: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36. Анализ юзерагента позволяет отличить, условно, Chrome на Windows от Safari на iOS и т. д. — то есть сузить круг до семейства браузера и платформы. 

Уникальность UA: хотя юзерагент формируется из ограниченного набора версий, сочетание операционной системы и браузера зачастую редкое. Например, не самый свежий браузер на специфической операционной системе выдаст уникальный юзерагент. В отпечаток также могут попадать нестандартные заголовки, которые добавляют расширения. По ним сайты могут определить, какие плагины или фреймворки у вас установлены. В целом же юзерагент легко подменить. Поэтому полагаться только на него нельзя, и он служит лишь одним из полей отпечатка.

Заголовки Accept и другие характеристики протокола

При каждом запросе браузер отправляет набор заголовков: поддерживаемые форматы (Accept, Accept-Language, Accept-Encoding), реферер, флаги кэширования и др. Комбинация этих заголовков тоже весьма показательна. Например, порядок и содержание полей Accept-Language и Accept-Charset могут отличаться между локалями операционной системы. Наличие Accept-Encoding: br говорит о поддержке Brotli и косвенно об относительно современном браузере. Сам порядок перечисления заголовков и агентов конкретным браузером тоже можно использовать как сигнатуру. Порядок HTTP-заголовков также часто уникален для движка браузера. 

Признаки на уровне HTTP считаются пассивными — они предоставляются браузером автоматически. Без участия JS сервер может узнать тип устройства (по UA), предпочитаемые языки (Accept-Language), тип контента, который понимает клиент (например, поддержка WebP в Accept выдает Blink-движок) и пр. Все эти мелочи включаются в модель отпечатка.

Часовой пояс (Timezone)

Хотя часовой пояс пользователя можно определить активным способом (через JS), приблизительно его можно вывести и по заголовкам. Например, заголовок Date в HTTP или время в логах сервера можно сопоставить с временем запроса на стороне клиента (если, к примеру, виден заголовок If-Modified-Since от браузера). Однако чаще Timezone получают уже на клиенте. Тем не менее смещение времени (GMT±X) включается как часть отпечатка, потому что отличается у пользователей из разных регионов и не меняется у одного пользователя со временем (если он не путешествует или не изменяет настройку вручную).

Индикация поддерживаемых технологий

Некоторые заголовки или черты соединения могут указывать на возможности браузера. Например, DNT (Do-Not-Track) — если пользователь включил «Не отслеживать», DNT: 1 станет частью отпечатка (парадоксально, но этот флаг сам по себе способен вас выделить, так как мало у кого включен). Еще пример: заголовок Upgrade-Insecure-Requests: 1 отправляется большинством современных браузеров при первом переходе на HTTPS — его отсутствие могло бы выдать необычный клиент. Эти тонкие нюансы редко идут отдельными полями отпечатка, но могут учитываться комплексно.

Активные параметры (JavaScript и Web API)

Разрешение экрана и цветовая глубина

Доступны через объекты window.screen. Свойства screen.width/height возвращают текущее разрешение экрана (иногда с учетом масштаба дисплея), а screen.colorDepth — глубину цвета (как правило, 24 или 32 бита). Эти параметры очень часто включаются в отпечаток, так как имеют много вариаций: размер экрана у всех разный. На десктопах окно браузера особенно редко совпадает с максимальным разрешением, но фингерпринт обычно берет именно наибольшее доступное разрешение пользователя, что отражает размер его монитора. Например, 1920×1080×24 (Full HD, 24-битный цвет) — один вариант, 1366×768×24 — другой и т. д. Каждый размер экрана с определенной глубиной может сузить группу устройств. А если пользователь изменит размер мониторного разрешения или подключит новый монитор — отпечаток изменится.

Языковые настройки

В браузере есть сразу несколько связанных настроек: язык интерфейса/ОС, язык предпочтительный для отображения страниц, формат локали для дат/чисел. JS может получить, например, navigator.language (или navigator.languages для списка) — значение вроде “ru-RU” или “en-US”. Оно, как правило, совпадает с тем, что отправлено серверу в заголовке Accept-Language. Локаль влияет и на формат функций вроде Date.toString() (названия месяца на русском или английском и т. п.), что тоже можно использовать для фингерпринтинга.

Как влияет на уникальность: сочетание языков и регионов достаточно вариативно. Например, русский пользователь может иметь locale ru-RU, а может uk-UA (если ОС на украинском) или вообще en-US (если интерфейс англоязычный, но он все равно русский). Эти нюансы добавляют несколько бит энтропии. Количество уникальных комбинаций языковых настроек растет с каждым годом, но в целом язык — скорее, один из важных атрибутов, чем суперуникальный признак: много людей используют популярные локали. Однако в сочетании с другими параметрами язык помогает отличить Chrome/Windows с русским языком от Chrome/Windows с немецким языком — что уже формирует два разных профиля.

Часовой пояс (через JS)

Более точный способ определить часовой пояс пользователя — вызвать в JS new Date().getTimezoneOffset(). Это возвращает смещение локального времени от UTC в минутах. Например, GMT+3 даст смещение в 180 минут. Также можно получить строковое название часового пояса через Intl API. Этот параметр практически всегда включается в отпечаток, поскольку он стабилен для устройства и различается по географии. Два пользователя с одинаковыми остальными параметрами, но разными часовыми поясами — уже разные отпечатки. 

Особенность: некоторые продвинутые фингерпринтеры отслеживают изменение часового пояса — это может сигнализировать, что это тот же браузер, но у него изменился контекст (например, если пользователь уехал в другой часовой пояс или сменил настройки часов). Однако в рамках простого отпечатка обычно используется текущее значение смещения.

Информация о платформе и CPU

Объект navigator дает ряд свойств, связанных с платформой устройства:

• navigator.platform — строка с обозначением ОС/архитектуры, например Win32, Linux x86_64, iPhone и пр. Ранее это был довольно показательный параметр (отличал, например, 32-битную Windows от 64-битной), но современные браузеры из соображений приватности могут возвращать усеченные или унифицированные значения. Если параметр доступен, он включается в отпечаток.
  
  

• navigator.hardwareConcurrency — число логических CPU-потоков (ядер) на устройстве. Например, 8 (что может соответствовать 4 физическим ядрам с Hyper-Threading). Это дает дополнительную вариативность: мобильные девайсы часто имеют 4 или 8, десктопы — 4, 8, 12, 16 и более ядер. Не каждый браузер сообщает точное значение, но в обычных условиях этот параметр собирается. Необычное количество потоков (например, 6 или 10) может сразу выделить устройство из массы.
  
  

• navigator.deviceMemory — приблизительный объем RAM в гигабайтах (целое число). Округляется до 0,25 (четверть) у Chrome. Например, 8 GB — deviceMemory = 8. Этот сигнал поддерживается не во всех браузерах. Но там, где есть, он тоже участвует: объем RAM достаточно редко равен целому числу — вариативность снижает совпадения.
  
  

• navigator.oscpu — строка с операционной системой (Firefox-only API). В современных версиях Firefox на Windows возвращает что-то вроде Windows NT 10.0; Win64; x64. Но этот параметр редко используется, так как он дублирует информацию из UA.
  
  

• navigator.webdriver — булево значение, указывающее, запущен ли браузер автоматизацией (WebDriver). Если оно true, сайт понимает, что перед ним бот, и может либо менять поведение, либо учитывать это в отпечатке. Для fingerprinting это, скорее, не параметр «уникализации», а способ детектировать автоматизацию. Тем не менее наличие navigator.webdriver=true однозначно выделяет клиента (обычные пользователи имеют false), поэтому косвенно это тоже часть отпечатка.

Включенность и статус Cookie/Storage

Скрипты могут проверить, разрешены ли в браузере куки (navigator.cookieEnabled). Если пользователь отключил их, это отличает его от основной массы (почти все держат куки включенными) и добавляет уникальности.

Список плагинов браузера

Через navigator.plugins можно получить перечень установленных плагинов NPAPI: Acrobat Reader, Flash, Silverlight и пр., включая их версии (navigator.plugins[i].name/version), несмотря на то, что NPAPI-плагины практически ушли (Flash и Java отключены или удалены из современных браузеров). В Chrome navigator.plugins теперь содержит только встроенный PDF Viewer. В Firefox — тоже нет ничего лишнего. Тем не менее сам API еще существует, и некоторые браузеры могут там что-нибудь выдавать. В отпечатке могут учитываться как названия плагинов, так и их количество. Если список пуст — это тоже сигнал (например, у Firefox в Tor-mode он пустой, а у обычного Firefox может быть встроенный OpenH264-плагин). В целом роль плагинов как фактора снижается, теперь растет роль расширений.

Наличие установленных расширений

В идеале сайты не должны знать, какие у пользователя стоят расширения, но на практике косвенно выявить некоторые расширения можно. AdBlock или Adblock Plus можно обнаружить по блокировке ими определенных запросов или появлению специфических DOM-элементов. Сайты могут специально пытаться загрузить ресурс с известным URL, который AdBlock фильтрует, и если он не загрузился — вероятно, стоит блокировщик. 

Другой пример: расширения могут добавлять особые объекты в window (например, расширение React Developer Tools добавляет __REACT_DEVTOOLS_GLOBAL_HOOK__), и скрипт на странице, найдя такой объект, распознает наличие данного расширения. Через десятки мелких проверок можно собрать «слепок» среды браузера. Количество расширений иногда можно приблизительно оценить по времени отклика браузера. Каждое подключенное расширение может замедлять обработку страницы. В любом случае наличие популярных блокировщиков, менеджеров паролей, специальных расширений — все это частично обнаруживается и повышает уникальность профиля.

Список установленных шрифтов

Один из наиболее вариативных параметров. Набор шрифтов в системе пользователя зависит от операционной системы, установленных приложений (Microsoft Office добавляет свои шрифты, Adobe свои и т. д.), от языка системы (китайские иероглифические шрифты обычно не стоят у европейских пользователей). Как же веб-страница может узнать, какие шрифты у вас есть? В прошлом для этого использовали Flash (метод EnumerateFonts), но без него остались чисто браузерные хаки:

• Через CSS+JS: создается скрытый элемент, в стиле прописывается несколько шрифтов в fallback. Если первый шрифт не установлен, текст будет отрисован вторым и элемент займет другую ширину/высоту. JS может измерить размеры элемента и таким образом понять, какой шрифт реально применился. Перебрав список из сотен популярных шрифтов, можно выяснить, какие из них присутствуют в системе. Этот способ довольно затратный по времени, поэтому чаще используют следующий метод.
  
  

• Через Canvas: нарисовав текст специфичным шрифтом на canvas и сравнив полученный растр по пикселям, можно определить, установлен шрифт или нет. В принципе, это частный случай для Canvas Fingerprinting, о нем ниже.

Число возможных комбинаций набора шрифтов огромно, потому что людей с точно одинаковым перечнем шрифтов не так много, особенно между разными версиями ОС. Наличие редкого шрифта (предположим, у вас установлены специфические шрифты для дизайна) сразу делает отпечаток уникальным. Поэтому данные о шрифтах очень ценны для фингерпринта. Сбор шрифтов — операция не мгновенная, поэтому некоторые скрипты могут кэшировать результат отпечатка.

Canvas Fingerprinting

Это хорошо известный метод, использующий HTML5-элемент <canvas> для получения уникальных особенностей рендеринга графики. Суть в том, что браузер рисует на виртуальном холсте некий контент (чаще текст с определенным шрифтом и цветами, иногда дополнительно геометрические фигуры), после чего скрипт вызывает canvas.toDataURL() — то есть получает битмап-изображение того, что отрисовано. Изображение представляется в виде строки (base64), которую затем можно хешировать и получить итоговый Canvas-отпечаток. 

Почему он уникален? Потому что мелкие отличия в системе — используемые алгоритмы сглаживания шрифтов, версия графических драйверов, платформа (Linux vs Windows) — приводят к едва заметным различиям на итоговой картинке. Обычно рисуют текстовую фразу, включающую разнообразные символы (буквы разных форм, спецсимволы) для максимального влияния сглаживания. Также могут нарисовать цветные прямоугольники, применить легкую трансформацию или тень, чтобы задействовать графические функции. В результате у разных устройств получаются разные изображения при одинаковом коде рисования. Сам по себе Canvas-отпечаток может меняться — после обновления драйверов GPU или при переходе с встроенной графики на дискретную. Но в сочетании с WebGL он крайне ценен.

WebGL-фингерпринт

WebGL — это API для рендеринга 3D-графики в браузере (по сути, доступ к возможностям OpenGL/ES). Он предоставляет два важных рода данных для фингерпринтинга:

Прямые идентификаторы GPU

Расширение WEBGL_debug_renderer_info позволяет получить через WebGL-контекст строки UNMASKED_VENDOR_WEBGL и UNMASKED_RENDERER_WEBGL — в них обычно указаны производитель и модель графического адаптера (Intel Inc., Intel Iris Plus Graphics 640 или NVIDIA Corporation, GeForce GTX 1070). Эти значения фактически сообщают, какая видеокарта у пользователя, вплоть до модели. В стандартном режиме большинство браузеров это разрешают (кроме Tor). Модель GPU сразу дает массу энтропии: даже если у двух людей одинаковая операционная система и браузер, но один с Intel HD Graphics, а другой с RTX 3080 — их отпечатки разделятся.

Набор WebGL-констант и возможности

Даже без прямого имени GPU, WebGL-контекст хранит кучу параметров, зависящих от драйвера и железа: максимальное количество текстурных юнитов, предельные размеры геометрии, поддержки теней, сглаживания и прочие числовые константы. Скрипт может последовательно вызвать gl.getParameter(...) для разных констант и собирать результаты. К примеру, MAX_VERTEX_UNIFORM_VECTORS может быть 4 096 на одной карте и 1 024 на другой и т. д. Формируется длинный вектор чисел — своеобразный профиль графической подсистемы. Такой профиль часто уникален для устройства и не совпадает даже между похожими моделями GPU.

Кроме того, WebGL можно использовать как Canvas — то есть нарисовать сложную 3D-сцену и получить ее растровое изображение. Такой подход способен выявить еще более тонкие различия (например, в реализации шейдеров). В практических реализациях FingerprintJS и др. обычно ограничиваются чтением UNMASKED_RENDERER (т. к. это проще и надежнее), но некоторые скрипты могут дополнительно хешировать рендер 3D-фигуры для устойчивости. WebGL-данные увеличивают уникальность отпечатка особенно на мобильных устройствах: например, если раньше было сложно отличить iPhone друг от друга (все имели одинаковый Canvas из-за одинаковых GPU), но теперь можно получить версию iPhone по GPU, если WebGL включен. В сумме с Canvas WebGL дает мощный источник энтропии, поэтому браузеры в режиме повышенной приватности стараются эти данные скрывать или подменять.

AudioContext Fingerprinting

Еще один изощренный современный метод — использование Web Audio API для получения уникального аудиоотпечатка устройства. Работа основана на том, что генерация и обработка звука в разных системах имеет микроскопические различия (из-за реализации библиотек, использования SIMD-инструкций, погрешностей плавающей запятой и т. п.). Практика показывает, что значения AudioContext-отпечатка заметно различаются между браузерами, у каждого сочетания «браузер+ОС+железо» свой результат, но он детерминирован (пока браузер или OS существенно не обновятся). Добавление аудиофингерпринта еще больше повышает устойчивость идентификации: даже если Canvas и WebGL у двух устройств вдруг совпадут, есть шанс, что аудио их различит.

Медиаустройства и датчики 

На этапе фингерпринтинга скрипт может собрать информацию об окружающем оборудовании:

• Через navigator.mediaDevices.enumerateDevices() можно получить список медиадевайсов (камер, микрофонов) пользователя. Браузер обычно возвращает ограниченные данные. Например, две камеры и микрофон без указания имен и идентификаторов, если не дано разрешение. Тем не менее количество устройств уже может выступать признаком.
  
  

• API типа Battery Status (заряд батареи) когда-то были доступны и тоже использовались для фингерпринтинга. Уровень заряда и время до полной разрядки давали уникальные комбинации. Из-за того что это позволяло генерить слишком точный отпечаток (вопрос приватности), такие API сейчас либо урезаны, либо требуют разрешения.
  
  

• Датчики (Orientation, Motion): наличие тех или иных сенсоров и формат выдачи данных тоже могут отличаться между устройствами (например, частота обновления гироскопа). Это довольно экзотичные сигналы, но в теории могут дополнять отпечаток.

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

Все вышеперечисленные активные и пассивные атрибуты образуют набор характеристик браузера и системы. На практике скрипты собирают от 10 до 30 параметров и формируют из них структуру (например, объект или массив строк), которая затем преобразуется в хеш. Многие библиотеки используют для хеширования быстрые алгоритмы вроде MurmurHash — чтобы получить компактный идентификатор из, скажем, 500 байт данных атрибутов. В результате получается строка (a3f6e9b12d4...), которую уже можно хранить на сервере как ID устройства.

Методы защиты от браузерного фингерпринтинга

Современные браузеры внедряют против фингерпринтинга определенные меры. Например, Tor Browser: он стремится сделать всех пользователей одинаковыми (одинаковый User-Agent, окно фиксированного размера, единый набор шрифтов, отключены Canvas и AudioContext и т. д.), даже при запуске браузера всплывает предупреждение — не разворачивайте окно на всю ширину, если хотите остаться анонимным. 

В Firefox есть настройка privacy.resistFingerprinting, включающая похожий подход усреднения значений. Браузер Brave по умолчанию блокирует сторонние трекеры и подмешивает шум в API. Существуют расширения (CanvasBlocker, Privacy Badger и др.), которые точечно ломают работу скриптов слежения. Однако ни один метод не дает 100%-й гарантии — слишком много параметров открыто браузером. 

В качестве ответа на запрос пользователей в анонимности появились антидетект-браузеры (Octo Browser, MultiLogin, Dolphin Anty и др.), которые позволяют эмулировать чужие отпечатки, создавая десятки «виртуальных» личностей с разными параметрами для маркетинга или арбитража трафика. 

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

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