Что случилось с Пользовательскими фильтрами и Фильтром быстрых исправлений: особенности политики MV3
“Где Пользовательские фильтры? И что случилось с Фильтром быстрых исправлений?”
Чтобы соответствовать строгой политике Chrome в отношении удалённого выполнения кода в рамках Manifest V3, нам пришлось принять несколько сложных решений. Пользовательские фильтры временно недоступны, а Фильтр быстрых исправлений удалён насовсем.
Почему так? Дело в том, что политика Chrome запрещает внедрять скрипты или удалённо размещённый код. Хотя цели у этой политики благие, формулировка её настолько широка, что даже правила блокировки рекламы могут попасть под её ограничения — и, к сожалению, Пользовательские фильтры и Фильтр быстрых исправлений попали под них.
Почему это проблема
Прежде всего, Фильтр быстрых исправлений появился только из-за ограничений MV3.
В MV3-расширении все фильтры AdGuard встроены, то есть обновления фильтров возможны только вместе с полным обновлением расширения, с прохождением проверки в магазине Chrome. Проверка может затянуться, и это довольно критично: если популярный сайт сломается, то пользователям придётся ждать новую версию, где эта проблема решена, вплоть до нескольких дней.
В MV2-раширении на такой случай мы внедрили дифференциальное обновление: мы быстро выпускаем новые фильтры, не обновляя всё расширение. Но в MV3-расширении так не получится, и Фильтр быстрых исправлений был нашим способом оперативно обновлять фильтры.
Несмотря на все наши усилия сохранить этот фильтр (историю нашей мучительной борьбы за него можно прочитать ниже), политика Chrome всё-таки вынудила нас полностью удалить его. И это только одна потеря.
Другая потеря — это Пользовательские фильтры, которыми пришлось пожертвовать из-за той же политики удалённого выполнения кода.
Пользовательские фильтры позволяют добавлять сторонние фильтры через URL. Тысячи волонтёров поддерживают эти фильтры, они необходимы для развития экосистемы блокировки рекламы — именно благодаря Пользовательским фильтры люди могут настраивать фильтрацию, тестировать и распространять эти фильтры. А включать просто любые фильтры в наши «готовые» фильтры мы не можем, да это и не должно быть необходимо.
Отсутствие Пользовательских фильтров — это не просто неудобство для пользователей; мы стараемся сделать всё, чтобы расширение оставалось эффективным для них. Однако, как мы уже говорили в одном из наших многочисленных постов, посвящённых MV3, «настоящими жертвами этого перехода являются разработчики фильтров». Потеря Пользовательских фильтров — это удар по сообществу, которое поддерживает мир блокировки рекламы.
Как мы её решаем
Нам предстоит глобальная переработка того, как применяются правила фильтрации AdGuard, и мы рассчитываем сохранить функциональность расширения, строго следуя политике Chrome. Вот что мы делаем:
Чтобы вернуть Пользовательские фильтры, мы будем использовать API
userScripts. Этот API позволяет регистрировать скрипты в соответствии с политикой MV3.Но есть нюанс: чтобы добавлять фильтры, пользователям придётся сделать дополнительный шаг, включив режим разработчика. Мы понимаем, что это может стать препятствием для менее подкованных пользователей. Поэтому, как только мы выпустим версию с пользовательскими фильтрами, мы обязательно добавим инструкцию, как его включить и добавить фильтры.
Поскольку Фильтр быстрых исправлений больше не может существовать в своём первоначальном виде, мы переходим на ускоренный процесс проверки в Chrome (Skip Review). Так мы сможем чаще обновлять фильтры, не дожидаясь полной проверки. Однако у этого метода есть некоторые ограничения: он применяется только к изменениям в группах DNR правил и только тех, котоые классифицируются как безопасные.
Скоро у нас будет два типа обновлений: ускоренные, которые будут происходить автоматически каждые несколько часов, и полные — с проверкой в интернет-магазине Chrome.
Путь даже к этому неидеальному решению был долгим и выматывающим. Ниже — хронология всех наших попыток сделать так, чтобы расширение соответствовало политике Chrome, но при этом эффективно блокировало рекламу и позволяло пользователям настраивать фильтрацию так, как им хочется.
Хронология борьбы
- Первый отказ: удалённое выполнение скрипта
Сначала наше расширение отклонили в магазине Chrome из-за того, что мы внедряем скрипты с помощью тегов <script>. Мы действительно использовали механизм, при котором расширение извлекало скрипты из правил и применяло их к странице через тег <script>. Для MV3-расширений требования политики Content Security Policy более строгие, чем для MV2, и мы не можем просто внедрять правила со скриптами, что сильно ограничивает доступные разработчикам инструменты для изменения содержимого страницы. Поэтому в некоторых случаях мы прибегали к использованию <script>. Это и стало проблемой.
Что мы сделали:
Мы преобразовали правила скриптов в локальные функции JavaScript, хранящиеся в расширении. Также мы добавили проверки, чтобы убедиться, что правила не содержат тегов <script> и что скрипты являются частью встроенных правил, прежде чем применять их.
Но мы оставили исключения для Пользовательских правил, Пользовательских фильтров и Фильтра быстрых исправлений, которые по-прежнему использовали <script> для внедрения правил.
Версию с этими изменениями одобрили. А потом отклонили.
- Второй отказ: загрузка Фильтра быстрых исправлений
На этот раз Chrome интерпретировал механизм загрузки Фильтра быстрых исправлений из удалённого источника как нарушение политики удалённого выполнения.
Что мы сделали:
Мы добавили подробные комментарии, объясняющие назначение Фильтра быстрых исправлений, и пояснили, что он разработан для устранения ограничений MV3 и не нарушает политики.
Этого оказалось недостаточно, чтобы пройти проверку в Chrome. Так мы получили…
- Третий и четвёртый отказы: весь код Фильтра быстрых исправлений
Чтобы удовлетворить требования Chrome, мы полностью удалили Фильтр быстрых исправлений и повторно отправили расширение на проверку. Получив отказ, мы связались с поддержкой и отправили версию, которая полностью запрещала загрузку кода и метаданных Фильтра быстрых исправлений. И эту версию первоначально одобрили, но...
- Пятый отказ: скриплеты и параметры
Chrome отметил использование скриптлетов — встроенных функций JavaScript — как нарушение политики удалённого выполнения, поскольку они могут выполняться с разным набором параметров.
Что мы сделали:
Мы захардкодили все скриптлеты непосредственно в расширении. Теперь механизм расширения проверяет, соответствует ли правило предварительно встроенной категории фильтра (например, Блокировка рекламы или Безопасность). Если совпадение есть, правило применяется, а если нет — отклоняется.
Также мы вернули Фильтр быстрых исправлений в ограниченном виде, но без выполнения на основе <script>.
Несмотря на все изменения, расширение всё равно было отклонено.
Это больше, чем AdGuard
Конечно, мы найдём выход из сложившейся ситуации — нам не впервой преодолевать трудности. Но эта ситуация касается не только AdGuard: политика Chrome затрагивает все блокировщики рекламы и все расширения.
Разработчикам нужны более чёткие руководства и бо́льшая прозрачность от интернет-магазина Chrome. Мы надеемся, что эта ситуация послужит толчком к разговору о балансе между безопасностью и функциональностью — это поможет и разработчикам, и пользователям.
