Базовые принципы анонимности при работе с рекламными сетями

👾 Команда koya.ads снова на связи!

📑 Тему анонимности обсуждают много, но почти всегда сваливают в одну кучу с кибербезопасностью. Это разные задачи, и путаница между ними недопустима.

Кибербезопасность защищает вашу машину и ваши данные от чужого доступа. Анонимность скрывает, кто вы. Антивирус вас не анонимизирует, VPN не защищает от вредоносного ПО, и одно не заменяет другое.

Отсюда главный тезис: поднять VPN и вырезать телеметрию из Windows – это не анонимность. Это только первый шаг, а дальше него обычно не идут.

Сегодня разберём, из чего задача состоит целиком, какие готовые решения есть на рынке, как выглядит собранный сетап целиком и на чём люди спотыкаются чаще всего.

🎯 От чего защищаемся

Прежде чем сравнивать решения, нужно понять, кто вас вообще видит. Наблюдателей три, и знают они разное.

Провайдер видит, что вы подключились, когда и сколько трафика прогнали. Содержимое закрыто TLS, но список доменов он собирает через DNS – и это полная карта того, куда вы ходите и как часто.

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

Целевой сайт видит адрес, с которого вы пришли, и отпечаток браузера. Реальный адрес ему недоступен, зато отпечаток связывает ваши визиты между собой без всяких IP.

Ключевая мысль, из которой растёт всё остальное: один слой закрывает одного наблюдателя и оставляет остальных. VPN прячет вас от провайдера и открывает провайдеру VPN. Tor прячет от провайдера и от сайта, но выдаёт себя выходным узлом из публичного списка.

• Поэтому слоёв несколько, и у каждого своя работа. Именно по этим осям дальше и сравниваем.

💻 Готовые решения на рынке

Собирать всё руками не обязательно – существуют дистрибутивы, где анонимность встроена в архитектуру. Разберём, что живо в 2026 году.

Whonix – две виртуальные машины: Gateway гонит весь трафик через Tor, Workstation работает и физически не знает своего реального адреса. Утечка невозможна архитектурно: рабочая машина просто не имеет другого пути наружу. Минус – нужен гипервизор и ресурсы под две системы сразу.

Kicksecure – та же команда, но без Tor. Это про харденинг системы, а не про анонимность, и разработчики говорят об этом прямо: Kicksecure не даёт тех гарантий, что Whonix. Whonix, по сути, и есть Kicksecure плюс принудительный Tor плюс разделение на две машины.

Qubes OS – изоляция всего от всего через отдельные виртуальные машины под каждую задачу. Умеет работать в связке с Whonix. Минус – самый высокий порог входа и требования к железу.

Tails – система с флешки, не оставляющая следов после перезагрузки. Весь трафик принудительно в Tor. Минусов для такой работы два, и оба решающие: ничего не сохраняется между сессиями и под капотом Linux, то есть привычный рабочий софт либо ставится через костыли, либо не ставится вовсе.

Parrot OS Security – обычный Linux с набором инструментов, Tor опционален. Не форсирует ничего, значит и не защищает по умолчанию.

Kodachi – живой проект, свежая версия вышла в феврале 2026. И вот здесь стоит остановиться, потому что случай показательный.

Независимый аудит 2021 года нашёл в нём утечку IPv6 мимо VPN и отправку аппаратного идентификатора машины на сторонние узлы. Аудита переписанной девятой версии нет – то есть нельзя сказать ни что это починено, ни что нет.

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

Septor – мёртв. Последний релиз в январе 2022 года, каталоги дистрибутивов держат его в статусе «неактивен». Упоминаем, потому что он до сих пор попадается в подборках «лучших анонимных ОС».

🧅 Отдельно про Tails и VPN

Вопрос всплывает постоянно, разберём точно. Официальная позиция проекта – Tails с VPN не работает. Поднять всё-таки можно, но возни много, и это правда.

Проблема глубже трудозатрат. Каждый обходной путь ломает одну из двух опор Tails: либо принудительную маршрутизацию в Tor, либо амнезию. А главное – ни один из способов не даёт VPN после Tor. У Tails просто нет второй точки в цепочке, как у Whonix с его разделением на Gateway и Workstation.

А нужен именно VPN после Tor – тот слой, который закрывает выходной узел от целевого сайта. Без него вы приходите в кабинет с адреса из публичного списка.

• Это и есть структурный ответ, почему в примере ниже Whonix, а не Tails.

📋 Сводка

Система	Tor принудительно	Обычный софт	Порог входа	Статус
Whonix	да, архитектурно	да	средний	жив
Kicksecure	нет	да	средний	жив
Qubes OS	опционально	Linux-версии	высокий	жив
Tails	да	без сохранения	средний	жив
Parrot OS	нет	да	средний	жив
Kodachi	да	да	низкий	жив, вопросы к доверию
Septor	да	да	низкий	мёртв с 2022

И общая черта всех семи: ни один не запускает нативный Windows-софт – все построены на Linux. Для рабочей машины это решающее ограничение, и оно объясняет, почему в примере ниже гибрид, а не готовый дистрибутив целиком.

🧱 Пример сетапа

Схема слоями, снаружи внутрь:

интернет → Fortinet → MikroTik (WireGuard)

             → Windows-хост (VPN)

               → VirtualBox → Whonix-Gateway (Tor)

                 → Windows-виртуалка (VPN)

Fortinet стоит периметром, MikroTik за ним, и на нём поднят WireGuard – он появился в RouterOS начиная с версии 7.1. Дальше Windows-хост со своим VPN, в нём VirtualBox, в нём Whonix-Gateway, и уже за ним рабочая виртуалка – тоже Windows, со своим третьим VPN.

Внутри виртуалки обычная Windows, а не экзотика. Именно поэтому весь рабочий софт запускается без проблем, и это главное преимущество перед готовыми дистрибутивами.

Кстати, связка «Whonix-Gateway плюс рабочая система не из комплекта Whonix» – не самодеятельность. Это документированный у Whonix сценарий, и разработчики честно помечают его как поддерживаемый сообществом, а не ими, с прямо названным риском. Знать об этом стоит заранее.

Преимущества:

• Весь софт работает. Внутри обычная Windows – вопрос «а есть ли клиент под эту ОС» не возникает вообще
• Настройка посильная. Разобраться надо, но это не проект на месяц: с нуля такая схема поднимается за пару часов
• Туннель поднят раньше, чем загрузилась ОС. Он на роутере, а роутер уже в сети, когда машина только начинает грузиться
• Три VPN, и все от разных провайдеров. Именно «разных» здесь ключевое слово: один и тот же провайдер в двух слоях склеивает их между собой. Механику разберём в ошибках

Недостатки:

• Скорость около 20 Мбит/с
• Периодически нужно перезапускать мосты Tor: конкретный мост отваливается, и это нормальная эксплуатационная рутина

💻 Базовые правила работы

Слои – это половина дела. Вторая половина в том, что где живёт.

Всё, что связано с работой, живёт только в виртуалке. Chrome – там же: он завязан на экосистему Google, и на личной машине ему делать нечего.

На хосте – LibreWolf или Brave – с uBlock Origin, NoScript и подобным набором. Оба с открытым исходным кодом, и здесь сразу оговорка, потому что довод про открытость обычно понимают неправильно.

Открытость сама по себе ничего не решает. Firefox открыт. Chromium открыт. Закрыты как раз фирменные сборки поверх них – Chrome и Edge. Так что LibreWolf открыт ровно настолько же, насколько обычный Firefox, а Brave – голый Chromium. Разница не в лицензии, а в том, с какими настройками сборка приезжает из коробки.

LibreWolf – это пересобранный Firefox, который едет за апстримом с отставанием в пару дней. Из коробки выключены телеметрия, отчёты о сбоях и Safe Browsing. И отдельно ценное для нашей темы: он выключает механизм, из-за которого стоковый Firefox в ряде регионов сам включает DNS-over-HTTPS со сторонним резолвером – то есть уводит запросы не туда, куда вы настроили в системе.

• Если ставите обычный Firefox – этот пункт проверяйте первым. В LibreWolf он уже закрыт.

Brave построен на Chromium, и делать вид, что это не так, глупо – движок тот же Blink. Из него вырезаны привязка к аккаунту Google, синхронизация и новые рекламные API. Но своя телеметрия у Brave есть, отключаемая, а Safe Browsing остался – просто ходит через серверы Brave, а не напрямую к Google.

Что до расхожих страшилок про Chromium – большую часть можно смело отбросить. Телеметрия Chrome отключается штатным тумблером, а по фоновому шуму в простое браузеры сопоставимы: и Chrome, и Firefox раз в полчаса стучатся в Safe Browsing к Google. Единственный железный довод против фирменных сборок – Edge, где обязательную диагностику обычный пользователь не отключит вообще, только политикой на управляемом устройстве.

Разница между этими двумя вариантами тоже есть. У LibreWolf глубже ручной контроль: about:config даёт прямой доступ к сотням сетевых параметров, без реестра и групповых политик. У Brave такого нет.

И честная оговорка, которая касается тезиса всей статьи. Оба браузера усиливают защиту от отпечатка, а мы весь текст твердим, что усиление делает вас реже. Это правда, и сами проекты это признают: LibreWolf прямо пишет, что правка его настроек создаёт «подмножество пользователей, которые выделяются», а Brave в 2024 году убрал строгий режим защиты отпечатка ровно потому, что им пользовалось меньше половины процента людей – и это само по себе стало меткой.

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

Здесь блокировщики уместны: хост – это ваша личная территория, а не рабочий профиль, и типовой отпечаток ему не нужен.

Диск хоста зашифрован. На нём стоит VeraCrypt. К сетевой анонимности это отношения не имеет – зато если машина попадёт в чужие руки выключенной, её содержимое останется недоступным. Рабочие данные, ключи и конфиги туннелей лежат именно там.

Разделение по назначению, а точнее – по личности. Рабочее в рабочей машине, личное в другой. Один заход в личную почту из рабочего профиля склеивает всё содержимое этого профиля с вами – навсегда и задним числом.

🔧 Какие службы Windows отключаем

Здесь нужна оговорка, которая определяет весь раздел: Windows чистят ради снижения фонового трафика, а не ради отпечатка. Это разные задачи, и решаются они на разных слоях. Почему так – в блоке про ошибки, там это самый дорогой пункт.

Телеметрия. Служба DiagTrack и политика AllowTelemetry в реестре.

Проверка «есть ли интернет». Windows при каждом изменении сетевого интерфейса дёргает msftconnecttest.com – причём обычным HTTP, не HTTPS. Это происходит и в момент, когда туннель ещё поднимается. Отключается через EnableActiveProbing, но Microsoft предупреждает, что от этой пробы зависят другие компоненты – размен осознанный.

Синхронизация времени. NTP уходит по UDP при каждом старте, то есть до того, как поднялся VPN внутри системы. Заворачиваем в туннель или берём время от гипервизора.

Служба геолокации. На десктопе без GPS координаты берутся по видимым точкам доступа Wi-Fi – и это канал, который не зависит от VPN вообще. Никакой туннель не меняет того, какие сети видит адаптер. В виртуалке проблема снимается: виртуальная машина Wi-Fi не видит.

Windows Update и Defender выключаем. Оба стучат наружу, оба лишние на машине, весь смысл которой в контроле исходящего трафика.

Здесь важная практическая деталь: пока включена Tamper Protection, поддерживаемого способа отключить Defender скриптом не существует – только тумблер в интерфейсе руками.

Учётная запись – только локальная. Летом 2026 года у этого правила появился свежий аргумент: Microsoft описала в судебных документах Global Device ID – сквозной идентификатор установки Windows.

Само поле есть в документации Microsoft, а вот как оно выдаётся, компания не раскрывает. Механику восстановили независимые исследователи: по их разбору идентификатор привязан ко входу в учётную запись Microsoft, и галочками приватности его не убрать.

• Практический вывод от недосказанности не страдает: не входите в учётную запись Microsoft на рабочей машине.

Чего не трогать. Служба BFE – на ней держится фаервол, VPN и IPsec, то есть ровно то, ради чего всё строилось. RPC и DCOM тянут за собой половину системы. Служба буфера обмена отвечает только за историю и синхронизацию, обычное копирование работает и без неё – но её регулярно сносят «на всякий случай».

🪜 Порядок сборки

Разворачивать лучше снаружи внутрь – так каждый следующий слой проверяется на уже рабочем предыдущем.

1. Роутер. Поднимаем WireGuard, настраиваем kill switch правилом фаервола, заводим IPv6 в туннель. Проверяем: гасим туннель и смотрим, уходит ли хоть один пакет мимо
2. Хост. Ставим систему, шифруем диск VeraCrypt, чистим, поднимаем свой VPN. Проверяем выходной адрес
3. VirtualBox и Whonix-Gateway. Импортируем готовый образ, проверяем, что Tor поднялся
4. Рабочая виртуалка. Ставим Windows с нуля, а не клоном. Интернет заводим в неё через Whonix-Gateway и сразу проверяем, что трафик реально идёт через Tor. Дальше чистим систему и поднимаем третий VPN
5. Профили в антидетекте. Только после того, как все предыдущие слои проверены по отдельности

Про четвёртый пункт отдельно: ВМ разворачиваем с нуля, а не клонируем из снапшота. Клон уносит с собой машинные идентификаторы, серийники и SID – и два «разных» профиля на двух «разных» машинах оказываются для площадки одной машиной.

Guest Additions не ставим, общие папки не используем. Первое добавляет в систему ключ реестра, три службы и два процесса с прямым упоминанием VirtualBox. Второе не только детектится, но и работает каналом склейки: один каталог на несколько профилей связывает их надёжнее любого отпечатка.

🖥 Альтернатива: работа на удалённом сервере через RDP

Схема на слуху: арендовать сервер с Windows, подключаться к нему через Tor и работать уже там. Выглядит проще, поэтому разберём её отдельно. Не советуем, и вот две причины.

Первая – задержка, и она решает. Медианная задержка onion-соединения по замерам самого проекта Tor – от 320 до 740 мс в зависимости от точки. Microsoft относит RDP-сессию к худшей категории качества уже при 300 мс на кадр, причём сеть там только одно слагаемое из четырёх. То есть работа начинается за худшим порогом вендора протокола и до него уже не возвращается.

Ускорить нельзя принципиально: быстрый транспорт RDP работает по UDP, а Tor UDP не переносит вообще. Остаётся TCP-режим, который сам Microsoft описывает как путь совместимости, а не производительности.

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

• Итого вы платите деньгами и скоростью за то, чтобы отдать контроль над машиной постороннему юрлицу. Локальная виртуалка в этом сравнении строго лучше.

⚠️ Ошибки, которые дорого стоят

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

🚨 check-gateway – это не kill switch

Самая частая ошибка на роутере. check-gateway живёт в разделе маршрутов и предназначен для переключения между провайдерами – то есть решает задачу, обратную нужной: он старается не потерять связность.

Механика по документации MikroTik: проверка раз в 10 секунд, таймаут 10 секунд, и нужно два таймаута подряд, чтобы шлюз считался недоступным. Итого от падения туннеля до реакции проходит 20-30 секунд.

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

Как правильно: kill switch делается правилом фаервола, а не маршрутом. В цепочке forward дропаем всё, что пришло из локальной сети и уходит не в туннельный интерфейс. Срабатывает на первом же пакете.

Два подвоха, на которых спотыкаются уже при настройке правила. Первый: если выше по цепочке стоит типовое разрешение для установленных соединений, они продолжат литься мимо туннеля – правило должно стоять выше. Второй: трафик самого роутера идёт в цепочку output, и правилом в forward он не закрывается.

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

🌐 IPv6 – утечка не при сбое, а всегда

Разберём чуть подробнее, потому что здесь неверна сама интуиция.

В RouterOS фильтр IPv6 – отдельное меню, и правила для IPv4 на него не действуют. То есть kill switch, написанный для IPv4, для IPv6 просто не существует.

Но главное не это. По стандарту RFC 6724 система предпочитает IPv6 – приоритет 40 против 35 у IPv4. Значит: провайдер раздал вам IPv6, у сайта есть AAAA-запись, и трафик уходит по IPv6 мимо туннеля, поднятого на 0.0.0.0/0.

Это происходит не при аварии. Это происходит в штатном режиме, каждый раз, на всех крупных сайтах – у Google, Cloudflare и остальных AAAA есть давно.

• Если у вас включён IPv6 и не заведён в туннель, вы, скорее всего, вообще никогда не ходили через этот туннель на те сайты, ради которых его поднимали.

Как правильно: либо выключить IPv6 целиком – и на роутере, и в системе, – либо завести в туннель. В примере выше он заведён в туннель: в конфигурации пира прописан IPv6-диапазон, а фильтрация продублирована в отдельном меню. Полумеры вроде «снял галочку на сетевой карте» не работают.

Проверяем: curl -6 и curl -4 к сервису, показывающему адрес. Ответы должны либо совпадать, либо IPv6 не должен отвечать вовсе.

🔗 Один VPN в двух местах

Здесь механика тонкая, поэтому по шагам. В схеме два плеча.

До Tor провайдер VPN видит ваш реальный адрес и факт подключения, но не видит, куда вы идёте. После Tor провайдер VPN видит все ваши назначения – кабинеты, лендинги, платёжки, – но не видит реального адреса, перед ним выходной узел.

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

Злого умысла для этого не нужно – достаточно одного запроса к нему.

• Сетап с одним провайдером в двух местах хуже чистого Tor: в чистом Tor такого участника нет вообще, а здесь вы его создали сами, сэкономив на втором аккаунте.

Отдельно: разные аккаунты у одного провайдера тоже склеиваются, если сессии стартуют синхронно каждый день. И оплата с одной карты склеивает их без всяких логов.

🧪 Верить конфигу вместо проверки

В Whonix работает stream isolation – приложения разведены по разным цепочкам Tor через собственные порты. Побочный эффект документирован самими разработчиками: предустановленный софт, включая браузер, по умолчанию игнорирует VPN, поднятый внутри рабочей машины.

Почему: приложение ходит не через системный сетевой стек, а напрямую в свой порт Tor. VPN меняет системную маршрутизацию – а приложение её не использует. Конфиг выглядит идеально, интерфейс поднят, маршрут правильный, браузер идёт мимо.

Хорошая новость рядом: в Whonix трафик не может обойти Tor, даже если VPN настроен неверно. Худший исход – деградация до чистого Tor, а не утечка реального адреса.

Проверяем: открыть check.torproject.org в рабочем браузере и сравнить адрес с тем, что отдаёт curl из терминала той же машины. Разные адреса означают, что у вас два разных пути наружу.

🧂 Чем чище машина, тем она заметнее

Звучит как парадокс, но механика простая: наблюдателю нужны не «плохие» значения, а редкие. Вырезали половину шрифтов – набор стал редким. Отключили WebRTC – редкость. Снесли WebGL – ещё редкость. Каждая галочка «для приватности» делает вас уникальнее.

Разработчики Tor Browser называют правильную стратегию одним словом – однообразие. Не рандомизация и не зачистка, а слиться с толпой. Там же сказано: подменять параметры частично бесполезно, наблюдателю хватит тех, что остались нетронутыми.

Антифрод не ищет плохие значения. Он ищет редкие сочетания.

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

• Поэтому Windows чистят ради трафика, а не ради отпечатка. Отпечаток лечится на другом слое.

📌 Что ещё ломает сетап

Две ошибки, которые встречаются реже, но стоят так же дорого.

• WebRTC мимо прокси. Настройки прокси работают для HTTP, а WebRTC шлёт запросы к STUN напрямую с интерфейса – и отдаёт странице ваш реальный адрес. Проверять в каждом профиле отдельно. В антидетекте использовать подмену, а не отключение: полное отключение само по себе редкость
• DNS мимо туннеля. Три канала: локальный резолв при socks5 вместо socks5h, DoH браузера по 443 порту, который не поймать блокировкой 53-го, и системный резолвер для не-браузерных приложений

🔐 Свой VPN и выбор протокола

Отдельный подпункт, потому что вопрос задают чаще остальных: почему на коммерческом VPN сыпятся капчи.

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

Рабочий путь – взять чистый хост и поднять VPN самому. Но честно: это обнуляет счётчик репутации, а не выводит из категории. Диапазоны хостеров тоже известны, и есть задокументированные случаи блокировок их подсетей. На практике всё упирается в качество конкретного адреса: если IP хоста уже в чёрных списках, капчи будут лететь ровно так же.

Про протоколы коротко:

• • WireGuard – быстрый, простой, держит соединение отлично. Опознаётся по сигнатуре, поэтому там, где фильтруют, не проходит. Отдельная деталь: в конфигурации сохраняется последний адрес пира
  • OpenVPN – медленнее и старше, зато гибче. Опознаётся тоже. Если ставите его на роутер – проверьте шифр: дефолты клиента в RouterOS слабые, там blowfish128 и sha1

• Обфусцированные варианты – маскируют трафик под обычный HTTPS. Нужны там, где протокол режут на уровне провайдера или страны. Платите скоростью и сложностью настройки

🎭 Octo Browser: возвращаем отпечаток к обычному

Всё предыдущее закрывало сеть. С отпечатком вышло наоборот: вычищенная Windows, виртуализация, нестандартный набор параметров – каждый слой анонимности сделал машину чуть более редкой. А редкость, как разобрали выше, и есть то, по чему связывают.

Теми же средствами это не лечится: чем больше вырезаешь, тем заметнее становишься.

Нужен слой, который вернёт машине типовой вид – не «чистый», а обычный, как у миллиона других пользователей. Это и делает антидетект-браузер.

Мы работаем с Octo Browser. Остановились на нём по трём причинам: удобный в ежедневной работе, один из лидеров рынка – а значит, под него есть готовые решения и живое комьюнити, – и быстрая поддержка.

Купить Octo Browser со скидкой 30% для новых пользователей можно по промокоду CPARUPARTNER30

Как настраиваем профили. Логика простая: то, что видно всем и сразу, оставляем типовым, а остальное подгоняем под реальную машину.

Типовыми держим три параметра:

• Операционную систему и её версию
• Разрешение экрана
• Язык – везде английский

Всё остальное – ядра, память, видеокарта – выставляем под ту машину, на которой профиль реально запущен. Профиль не должен спорить сам с собой.

Гео и таймзону руками не трогаем, они подтягиваются из прокси. Время система отдаёт отдельно от адреса: немецкий прокси и московские часы – это уже не «странность», а прямое противоречие.

Прокси у каждого профиля свой. Адрес – такой же идентификатор, как отпечаток. Прокси, побывавший под одним профилем, приносит его историю следующему.

🔍 Где проверять профиль

Сервисов много, и они отвечают на два разных вопроса. Смешивать их – главная ошибка при проверке.

Одни считают, насколько вы редкий: AmIUnique, Cover Your Tracks. Сравнивают ваш отпечаток со своей базой и выдают уникальность в битах.

Другие ищут следы подмены: CreepJS, fv.pro, Pixelscan в режиме проверки на бота. Они сверяют один и тот же параметр, полученный разными путями – из главного потока, из фонового процесса, из фрейма, – и на расхождении делают вывод, что здесь соврали.

Про первую группу есть важная поправка. Их выборка самоотобрана: туда ходят люди, специально интересующиеся приватностью. Отсюда завышение – по академическим замерам на обычном крупном сайте уникальных отпечатков 35,7%, а в базах этих сервисов – 89-94%.

• Поэтому «вы уникальны среди N браузеров» на таких сервисах – это уникальность среди параноиков, а не среди обычных пользователей площадки. Гнаться за нулём бессмысленно, его не бывает. А вот ноль обнаруженных подмен – достижимая и правильная цель.

Порядок проверки – от грубого к тонкому, потому что ошибка на раннем шаге обесценивает все последующие:

1. Адрес. Смотрим ASN и тип подключения, а не страну – страна совпадает почти всегда, а выдаёт принадлежность к хостинговому диапазону
2. Утечки канала. DNS и WebRTC. Все резолверы должны принадлежать одному провайдеру, и он должен соответствовать прокси. Публичный адрес из WebRTC обязан совпадать с адресом прокси
3. Согласованность. Пояс, язык, таймзона против гео. Самая частая и самая дешёвая в устранении причина провала
4. Слой ниже JavaScript. Про него знают немногие, а он показателен: BrowserLeaks умеет показать отпечаток TLS, QUIC, параметры TCP и структуру HTTP/2. Всё это формируется сетевым стеком, а не скриптами на странице – и если версия оттуда спорит с той, что заявлена в User-Agent, расхождение видно без единой строчки JavaScript
5. Подсистемы отпечатка. Canvas, WebGL, шрифты, аудио. Смотрим не на хэш, а на правдоподобие: соответствует ли видеокарта заявленной системе, разумно ли число шрифтов, не выглядит ли набор слишком чистым
6. Следы подмены. CreepJS, fv.pro. Критерий готовности – ноль расхождений
7. Уникальность – последним и по желанию. Не чтобы снизить процент, а чтобы найти аномально редкие значения

И предупреждение напоследок. CreepJS запускайте только с официального адреса – автор помечает все зеркала как вредоносные, а гуглится проект так, что попасть на клон легко.

❗ Заключение

Анонимность не включается одной галочкой . Это набор слоёв, где каждый закрывает своего наблюдателя, а ошибка в одном обесценивает остальные.

И у неё нет состояния «готово». Методы детекта меняются с каждым обновлением браузера, адреса и выходные узлы попадают в списки, мосты отваливаются, а то, что работало полгода назад, сегодня уже подсвечивает вас. Сетап нужно перепроверять – после обновлений, после смены провайдера, просто регулярно. Настроить один раз и забыть не выйдет ни у кого.

И последнее. Всё описанное – пример рабочей схемы, а не эталон: она собрана под конкретные задачи, и грабли в ней собраны на конкретных ошибках. У вас другое железо, другие бюджеты и другие площадки, так что часть выводов вы наверняка перепишете под себя. Это нормально и правильно.