Автор uBlock Origin и uMatrix Реймонд Хилл обновил памятку, почему расширение uBlock Origin наиболее эффективно работает в браузере Firefox. Некоторые технические детали относятся не только к uBO, но и к другим блокировщикам рекламы.
Реймонд Хилл называет несколько основных факторов: более эффективное вскрытие маскировки CNAME, HTML-фильтрация, поддержка WebAssembly, более корректная процедура запуска браузера, сжатие LZ4 и надёжно отключённый префетчинг ресурсов. Всё это есть в Firefox, но отсутствует или глючит в браузерах на основе Chromium.
Вскрытие CNAME
Вскрытие CNAME (CNAME uncloaking) — это возможность распознавать сторонние серверы, которые маскируются под родной домен. Проверка выполняется путём проверки записи CNAME (Canonical Name).
Каноническое имя — это тип записи DNS, которая привязывает псевдоним к действительному (каноническому) доменному имени. Запись CNAME хранится в настройках DNS домена в виде пары значений.
Записи CNAME обычно используются для привязки поддомена к домену, на котором размещён контент этого поддомена. Но злоумышленники могут использовать эту техническую возможность для обхода блокировки, когда автоматически блокируются все ресурсы, загружаемые со сторонних доменов. То есть для обмана блокировщиков рекламы. Это очень распространённая практика.
Естественно, блокировщики рекламы стараются распознать мошенников, проверяя запись CNAME для каждого домена. Независимое тестирование показывает, что связка uBlock Origin и Firefox эффективнее всего справляется с этой операцией, по сравнению с другими связками блокировщик+браузер.
Тёмно-зелёным и красным отмечен uBO до и после того, как получил возможность вскрывать записи CNAME в Firefox. Источник: «Описание трекинга на основе маскировки CNAME» на сайте Азиатско-Тихоокеанского сетевого информационного центра, август 2020
HTML-фильтрация
HTML-фильтрация — возможность фильтровать тело ответа HTML до того, как оно проанализировано браузером.
Например, это позволяет удалить определённые теги в HTML-документах. В других браузерах отсутствует механизм надёжно провести такую процедуру. Дело в том, что для этой функции требуется программный интерфейс WebRequest.filterResponseData(), который в настоящее время доступен только в Firefox.
Запуск браузера
При запуске Firefox ждёт готовности, пока uBO будет полностью готов к работе, прежде чем запускать сетевые запросы в уже открытых вкладках. Это не относится к браузерам на основе Chromium. В них вредоносные трекеры и реклама могут попасть в уже открытые вкладки, в то время как они правильно отфильтруются в Firefox. Надёжная блокировка при запуске браузера особенно важна для тех, кто по умолчанию использует режим блокировки сторонних ресурсов и/или JavaScript.
Префетчинг
Префетчинг по умолчанию отключён в uBO, а также надёжно отключён в Firefox, в то время как в браузерах на базе Chromium это не так. Браузеры на базе Chromium дают веб-сайтам приоритет над пользовательскими настройками для префетчинга. Подробнее см. документацию uBlock Origin и обсуждение в баг-трекере Chromium.
WebAssembly
Версия uBO в Firefox в качестве основного метода фильтрации использует чрезвычайно быстрый и эффективный код WebAssembly. Это не относится к браузерам на базе Chromium, поскольку для этого потребуется дополнительное разрешение в манифесте расширения, которое может вызвать трения при публикации расширения в каталоге Chrome.
Более подробно см. обсуждение в репозитории WebAssembly.
Сжатие данных
Firefox-версия uBO использует сжатие LZ4 для хранения исходных списков фильтров, скомпилированных списков и снапшотов памяти на диске.
Сжатие LZ4 требует наличия IndexedDB, что проблематично с браузерами на базе Chromium в режиме инкогнито — там инстансы IndexedDB всегда сбрасываются, в результате чего uBO всегда запускается неэффективно и с устаревшими списками фильтров. Инстанс IndexedDB необходим, поскольку он поддерживает хранение данных в блобах, что недоступно в browser.storage.local API.
Это основные причины, почему uBlock Origin лучше работает в Firefox, чем в браузерах на основе Chromium.
На правах рекламы
Серверы с возможностью установить браузер или любых других задач на базе новейших процессоров AMD EPYC. Создавайте собственную конфигурацию виртуального сервера в пару кликов на любой операционной системе!
kahi4
Иными словами, в фаирфоксе этот плагин может внутри webassembly сделать что угодно на каком угодно этапе с чем ему угодно? (В том числе за счёт ошибки (слишком тяжелая регулярная строка например) убить всю производительность браузера)?
selivanov_pavel
Это всё прекрасно могут плагины и без webassembly.
DirectoriX
Некоторое время назад нашёл проблему в официальном плагине Selenium IDE для Chrome: если открыта стартовая страница — это расширение загружает одно ядро процессора на 100%. Уж не знаю, используют они WebAssembly или нет, но косямбы реальны.
А в Firefox такой проблемы не обнаружилось.
kahi4
Безусловно, но проанализировать код пусть и на обфусцированном, но всё же JS проще чем разобраться в коде веб ассемблера.
selivanov_pavel
uBlock Origin — open source, там можно посмотреть откуда что берётся и без обфускации.
kahi4
Стандартный вопрос: где гарантия что то, что оказалось в магазине приложений собрано именно из того же кода, что лежит на гитхабе?
P.s. С собственной сборкой то понятно
selivanov_pavel
Судя по https://github.com/gorhill/uBlock/blob/master/.github/workflows/main.yml, там сборка скриптом в контейнере, так что должно воспроизвестись, разницы в окружении сборки не будет. Если не воспроизведётся — писать issue.
kahi4
Хорошо.
Вы можете верифицировать конкретную версию, однако хром обновляет расширения скрытно, а раз у разработчиков есть ключ, он может залить какую-то зловредную версию ручками, у вас автоматом обновится версия на зловредную. Ведь никогда такого не случалось, когда злоумышленник получал несанкционированный доступ к ключам.
Понятное дело что риск и в хроме и в фаирфоксе, но в webassembler сложнее находить подобные уязвимости на этапе принятия в стор. Впрочем логика работает только если приложения вообще хоть как-то ревьюатся перед принятием, в противном случае разницы нет.