Блокировщик рекламы на Android: тест эффективности фильтрации трафика

Поэтому тест блокировщиков рекламы на Android начинается не с итогового балла, а с понимания, какой именно слой фильтрации проверяется.

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

Архитектура мобильной фильтрации: от DNS-серверов до локальных VPN

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

Private DNS: фильтр до загрузки страницы

Начиная с Android 9 Pie система поддерживает Private DNS на базе DNS-over-TLS (DoT). Настройка находится в разделе «Сеть и интернет → Частный DNS». Там можно указать имя сервера фильтрации, например dns.adguard-dns.com. После этого DNS-запросы устройства направляются через выбранный сервис.

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

Private DNS также не обрабатывает страницу после загрузки. Сервер видит имя домена, для которого запрашивают адрес, но не HTML-разметку и не DOM-дерево. Он не может убрать пустое место, оставшееся после блокировки рекламного запроса, и не выбирает отдельный баннер среди остальных элементов сайта.

Локальный VPN: больше контроля, но не полный доступ к странице

Блокировщики вроде AdGuard для Android, Blokada и AdAway в режиме без root могут использовать локальный VPN-интерфейс. В этом случае приложение создаёт туннель внутри устройства и применяет правила к проходящим через него соединениям. Такой режим позволяет централизованно фильтровать трафик приложений и работать с наборами правил, включая списки рекламных доменов и трекеров.

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

Браузерные расширения работают с другим набором возможностей. В поддерживаемом браузере они могут применять сетевые правила к запросам и косметические правила к элементам страницы. Поэтому результат расширения нельзя напрямую приравнивать к результату Private DNS или локального VPN: инструменты стоят на разных уровнях и видят разные признаки.

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

Синтетические бенчмарки и тестовые платформы для оценки блокировки

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

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

У CheckAdBlock встречается обозначение версии v3.1.1 с датой 2023 года. Это относится к самому тестовому ресурсу, а не к версии AdGuard для Android. При сравнении приложений и тестовых платформ важно не переносить номер версии или дату с одного продукта на другой: иначе даже аккуратно записанный протокол будет содержать неверную атрибуцию.

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

На Android нет универсального аналога сочетания Ctrl+Shift+R, привычного для настольного браузера. Можно очистить данные сайта или кэш через настройки браузера, но вместе с этим иногда удаляются другие локальные данные. Альтернатива для повторных прогонов — использовать отдельный тестовый профиль или другой браузер, если он доступен. Важно применять один и тот же способ очистки во всех сравниваемых запусках.

Синтетические проверки обычно группируют по типу контента:

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

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

Ограничения сетевого уровня: почему DNS бессилен против видеорекламы

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

YouTube наглядно показывает проблему. Видеопотоки и рекламные вставки могут быть связаны с доменами *.googlevideo.com. Если заблокировать такой домен целиком, можно нарушить воспроизведение основного видео. Если оставить домен доступным, DNS-фильтр не сможет выбрать из соединения только рекламную вставку. На этом уровне у него нет признака, который позволил бы надёжно отделить рекламу от контента.

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

Сходные компромиссы возникают и в других случаях:

• Если рекламный сервер доступен по IP-адресу и приложение не обращается к DNS так, как ожидает фильтр, блокировка домена может не сработать.
• Если реклама размещена на общей инфраструктуре CDN, блокировка всего домена может затронуть полезные запросы сайта. DNS не умеет запрещать отдельный путь внутри домена.
• Если приложение встраивает рекламу через SDK, блокировка домена SDK иногда меняет поведение самого приложения. Оно может потерять рекламный блок, показать пустое место или столкнуться с ошибкой, если разработчик связал с SDK другие функции.

Сетевой тест показывает, какие запросы удалось остановить в его сценарии. Он не всегда отвечает на вопрос, исчезла ли реклама визуально. Например, заблокированный запрос может оставить на странице пустой контейнер, а незаблокированное изображение может выглядеть как часть основного контента. Здесь нужен отдельный визуальный осмотр страницы или проверка элементов в браузере.

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

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

Инструментарий проверки скриптов трекинга и косметических правил

Косметическая фильтрация скрывает элементы, которые уже присутствуют в разметке страницы или остались после остановки сетевого запроса. DNS-сервер не видит DOM и не применяет CSS-селекторы. Поэтому сравнение фильтрации трафика мобильных браузеров должно отделять проверку запросов от проверки внешнего вида страницы.

Adblock Tester полезен тем, что в нём можно рассматривать категории отдельно. Если раздел косметических правил не пройден, это не обязательно означает поломку DNS-фильтра: у него нет доступа к элементам страницы. Если проверка выполняется в браузере с расширением, результат уже зависит от поддержки расширения этим браузером, его настроек и выбранных фильтров.

Для проверки скриптов трекинга на Android удобно провести два независимых запуска:

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

2. Очистить данные тестовой страницы или открыть чистый сеанс, затем запустить платформу проверки.

3. Зафиксировать результат по категориям: сетевые запросы отдельно, косметические правила отдельно, трекеры и fingerprinting отдельно.

4. Повторить запуск с отключённым расширением, не меняя браузер и остальные условия.

5. Сравнить результаты. Разница покажет вклад расширения в этом тестовом сценарии, но не даст универсальной оценки для всех сайтов и приложений.

Такая проверка подходит, например, для браузера с расширением uBlock Origin, если используемая версия браузера поддерживает его установку. Поддержка расширений на Android зависит от конкретного браузера, поэтому нельзя считать, что инструкция для одного приложения автоматически сработает в другом.

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

Что фиксировать при каждом прогоне

Даже простой протокол помогает избежать неверных выводов. В заметке достаточно указать:

• модель устройства и версию Android, если сравнение проводится на нескольких устройствах;
• браузер и его версию;
• название тестовой платформы и дату запуска;
• активный способ фильтрации: Private DNS, локальный VPN или расширение;
• включённые списки и важные настройки блокировщика;
• способ очистки кэша и результат по отдельным категориям.

Версия приложения тоже важна, но не как магическое объяснение каждого результата. Списки и настройки могут меняться между выпусками, а тестовая страница может обновить собственные проверки. Поэтому при повторении полезно записывать версию самого блокировщика и тестовой платформы отдельно. Версию AdGuard нельзя выводить из номера версии CheckAdBlock: это разные продукты.

Оценка работы adblock на телефоне становится понятнее, если сравнивать базовую линию и фильтр по одному изменению за раз. Сначала запуск без фильтрации, затем с одним выбранным способом блокировки. Если цель состоит в проверке косметических правил, нужен браузерный инструмент, способный применять их к странице. Если проверяется фильтрация DNS, оценивают сетевые запросы, а не ожидают от неё управления DOM.

В итоге у блокировщика рекламы на Android нет единственного универсального теста. Private DNS удобен для блокировки доменов на уровне системы, локальный VPN даёт приложению-фильтру возможность работать с сетевыми соединениями, а браузерные расширения способны применять правила к содержимому страниц. Эти методы пересекаются по задачам, но не взаимозаменяемы.

Смотреть стоит не на одну итоговую цифру, а на то, какие проверки она включает и в каких условиях получена. Тогда тест покажет полезное: где фильтр справляется, где упирается в ограничения DNS, а где нужен другой уровень обработки. Для обычной блокировки рекламы на Android root-права не обязательны: Private DNS и локальные VPN-режимы работают без модификации системы. Root нужен для отдельных сценариев вроде изменения системного файла /etc/hosts или управления трафиком через iptables, но это уже другая настройка, а не необходимая часть проверки.