Проверка отпечатка браузера: Тест Canvas, WebGL, AudioContext и уникальности

Deep Fingerprint & Environment Assessment

Тест отпечатка браузера

Browser fingerprinting creates a unique device ID by collecting hardware, font, and graphics rendering features.

SHA-256 Hash Checking...
Tamper Status
Проверка...
Bot Detection
Проверка...
WebRTC Leak
Проверка...
Uniqueness Score
Проверка...

Hardware & Environment

Checking...

                            

Graphics & Rendering

Checking...

                            

Browser & Security

Checking...

                            

Advanced Micro-Fingerprints

Checking...

                            

Network & WebRTC

Checking...

                            

Capabilities & API Probes

Checking...

                            

Сводка оценки цифрового отпечатка

Проверка...
Проверка...
Межуровневый анализ сетевого стека

Объедините уникальность Canvas/WebGL в браузере с серверными отпечатками TCP/TLS/QUIC для полной оценки рисков отслеживания.

Проверить сетевой отпечаток →

Часто задаваемые вопросы о цифровом отпечатке браузера (Fingerprint)

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

Изменение только строки User-Agent не скрывает браузер, а наоборот, создает явные «межслойные противоречия», которые легко фиксируются продвинутыми антифрод-системами: во-первых, конфликт между прикладным и транспортным уровнями — если в Windows изменить UA на iPhone Safari, HTTP-заголовки заявляют об устройстве Apple, но пакеты TCP SYN демонстрируют сигнатуру ядра Windows (отсутствие опции TS, порядок MSS, NOP, WS, NOP, NOP, SACK_PERM), что прямо противоречит каноническому 8-элементному порядку опций Apple. Во-вторых, протокольные инварианты HTTP/3 и HTTP/2 — движки Chromium, WebKit и Gecko обладают неизменными особенностями, такими как сопоставление однонаправленных потоков HTTP/3 (Chromium: 2:control,10:encoder против WebKit: 2:control,6:encoder) и порядок псевдозаголовков HTTP/2 (Chromium: m,a,s,p против не-Chromium: m,s,a,p). Подмена поверхностного заголовка мгновенно вскрывает несоответствие с нижним сетевым уровнем.

💡 Подробности сигнатуры вашего транспортного уровня представлены в Анализе анонимности прокси.

Антидетект-браузеры модифицируют Chromium или внедряют JS-хуки для переопределения свойств navigator, добавления шума в отрисовку Canvas/WebGL и подмены разрешения экрана и аудиоконтекста. Однако современные системы защиты легко фиксируют аномалии: во-первых, следы модификации прототипов и нативных функций — JS-перехватчики нарушают стандартное поведение Function.prototype.toString, дескрипторов свойств или цепочки прототипов. Во-вторых, инварианты GPU и шейдеров — добавление шума меняет хэш изображения, но точность вычислений с плавающей запятой физического GPU и особенности растеризации остаются неизменными, а сам алгоритмический шум образует характерный паттерн. В-третьих, неизменный сетевой стек ОС — большинство инструментов работают только на уровне JS, оставляя характеристики TCP/TLS хостовой системы открытыми и противоречивыми.

Нет, не защищает. Режим инкогнито создан исключительно для того, чтобы на локальном устройстве не сохранялись история просмотров, куки и данные форм после закрытия окна; он не предназначен для предотвращения удаленной идентификации сайтами. Снятие цифрового отпечатка выполняется через JavaScript, опрашивающий параметры физического оборудования и движка рендеринга (производительность GPU, точность WebGL-шейдеров, установленные шрифты, отклик аудиоосциллятора, количество ядер процессора, глубину цвета и др.). Поскольку физическое «железо», драйверы и движок браузера в режиме инкогнито не меняются, хэш отпечатка, вычисляемый удаленным сервером, полностью совпадает с обычным режимом.

Это не ложное срабатывание, а фундаментальное техническое правило платформы iOS: во-первых, правила Apple App Store — Apple обязывает все сторонние браузеры для iOS/iPadOS (включая Chrome, Edge, Firefox, Opera) использовать исключительно системный движок WebKit / WKWebView, запрещая движки Chromium Blink или Gecko. Во-вторых, проверка на уровне сетевых протоколов — Chrome для iOS (CriOS) при установке HTTP/3 соединения отправляет структуру однонаправленных потоков, характерную именно для WebKit (2:control,6:encoder), а не Chromium (2:control,10:encoder). Таким образом, Chrome на iOS является оболочкой над WebKit, и определение его как WebKit технически безупречно.

Да, но с четкими условиями и строгими ограничениями, и это принципиально отличается от «аутентификации личности». Восстановление идентификатора на нашем сайте использует четырехслойную модель весов: 1) Слой аппаратных привязок (модель GPU, базовая задержка аудио, количество медиаустройств); 2) Системный высокоэнтропийный слой (список установленных шрифтов, пакеты синтеза речи); 3) Браузерный изменчивый слой (хэш рендеринга Canvas, хэш вычислений AudioContext); 4) Слой среды отображения (разрешение экрана, часовой пояс). После агрегации всех четырех слоев для признания существующего профиля необходимо одновременное выполнение двух условий: превышение порога общего балла и совпадение хотя бы одного высокоэнтропийного ключевого признака (шрифты, голоса речи, Canvas или Audio). Второе условие введено намеренно: общедоступные низкоэнтропийные атрибуты (модель GPU, часовой пояс, разрешение экрана) массово повторяются на однотипных устройствах и ни в каких комбинациях не могут формировать профиль; в ранних версиях без этого шлюза незнакомое устройство могло быть ошибочно объединено с чужим. Кроме того, слой аппаратных привязок действует по принципу права вето: несовпадение логических ядер CPU, разница оперативной памяти свыше 4GB, расхождение базовой задержки звуковой карты более чем на 0.005 секунды или различие максимального числа точек касания немедленно дисквалифицируют кандидата без подсчета баллов.

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

Оба относятся к «системным высокоэнтропийным признакам», не требуют никаких разрешений и работают абсолютно бесшумно. Отпечаток AudioContext: в OfflineAudioContext осциллятор (Oscillator) подключается к динамическому компрессору (DynamicsCompressor) для автономного рендеринга аудиосигнала, после чего считываются значения с плавающей запятой и вычисляется хэш. Одна и та же аудиосхема дает микроскопические различия в младших битах в разных реализациях браузеров, математических библиотеках и аппаратных блоках с плавающей запятой без воспроизведения звука. Рядом с ним, но полностью независимо, находится AudioContext.baseLatency: это значение отражает размер выходного буфера звуковой карты, определяемый аудиодрайвером и оборудованием; мы используем его как аппаратную привязку (разница свыше 0.005 секунды исключает совпадение), а не как хэш идентификатора. Отпечаток перечисления шрифтов: последовательно измеряет ширину и высоту тестовой строки при рендеринге шрифтов из списка-кандидата; несовпадение с резервным шрифтом подтверждает его наличие. Набор шрифтов зависит от установленного ПО (Office, пакеты Adobe, средства разработки, методы ввода), поэтому список шрифтов обычно является самым индивидуализирующим признаком среди всех данных.

💡 Разница в стабильности обусловлена причинами изменений: хэши Canvas и Audio меняются при обновлении версии браузера (стек рендеринга и математические модули постоянно эволюционируют), тогда как шрифты меняются только при установке или удалении программ — именно поэтому у них наивысший вес.

MSS (Maximum Segment Size) — это максимальный размер полезной нагрузки TCP-сегмента, объявляемый при рукопожатии TCP. Наш сервер считывает его прямо из вашего пакета SYN без установки клиентских программ. Добавление накладных расходов заголовков IP и TCP восстанавливает MTU канала: плюс 40 байт для IPv4, плюс 60 байт для IPv6. Типичные значения имеют четкое техническое значение: 1500 — стандартный Ethernet или прямое подключение облачного сервера; 1492 — подключение PPPoE (домашний интернет DSL / FTTH), где заголовок PPPoE занимает 8 байт; меньше или равно 1420 указывает на инкапсуляцию дополнительным протоколом, типично для VPN-туннелей WireGuard / Tailscale или проксирования через CDN.

⚠ Главный принцип: MSS описывает сетевой канал, а не устройство. Оно показывает лишь наличие инкапсуляции на маршруте и само по себе не доказывает использование прокси (у домашнего PPPoE тоже не 1500). Настоящую диагностическую ценность представляют противоречия: когда заявленная прикладным уровнем локация систематически не совпадает со свойствами канала (например, заявляется прямое местное подключение, а MSS стабильно находится в диапазоне туннеля). Подробнее см. в разделе Анализ анонимности прокси.

Это ошибка, к которой мы относимся строже всего (ложное объединение), и против нее выстроены три рубежа защиты — срабатывание любого из них блокирует совпадение. Первый — жесткая изоляция корзин: кандидаты группируются строго по платформе ОС и ядру браузера без межгруппового сопоставления. Два разных браузера на одной машине с одинаковым «железом» никогда не сольются в один профиль. Второй — аппаратное право вето: число логических ядер CPU, объем оперативной памяти (допуск 4GB), базовая задержка аудио (допуск 0.005 секунды) и максимальное количество точек касания при наличии данных на обеих сторонах и выходе за допуск сразу отсекают кандидата до этапа подсчета баллов. Третий — допуск по ключевым признакам: даже при высоком балле совпадение не признается, если не совпал ни один высокоэнтропийный ключевой признак (шрифты, голоса, Canvas, Audio) — это предотвращает накопление баллов группой общедоступных низкоэнтропийных свойств.

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