В течение прошлого года мы активно участвовали в обсуждениях с поставщиками нескольких расширений для блокировки контента о способах улучшения платформы расширений MV3. На основе этих обсуждений, многие из которых проходили в группе сообщества WebExtensions ( WECG ) в сотрудничестве с другими браузерами, нам удалось внести значительные улучшения.
Больше статических наборов правил
Наборы правил фильтрации обычно группируются в списки. Например, более общий список может содержать правила, применимые ко всем пользователям, в то время как более конкретный список может скрывать контент, привязанный к конкретному местоположению, который хотят заблокировать только некоторые пользователи. До недавнего времени мы позволяли каждому расширению предлагать пользователям на выбор 50 списков (или «статических наборов правил») и одновременно включать 10 из них. В ходе обсуждений с сообществом разработчики расширений предоставили убедительные доказательства того, что это слишком мало для определенных случаев использования. Изучив производительность API в Chrome с учетом этих обсуждений, мы теперь разрешаем одновременное включение до 50 API. (Примечательно, что это значительно превышает лимит в 20, запрошенный WECG.) Мы также допускаем в общей сложности 100 наборов правил. Это доступно в Chrome 120, а увеличение ограничений поддерживается как Firefox, так и Safari, которые оба предоставили ранние предложения по этому предложению.
Более динамичные правила
Большинство правил являются «статическими» и поставляются с каждым обновлением расширения. Однако для поддержки более частых обновлений и пользовательских правил расширения также могут добавлять правила динамически, без необходимости их разработчикам загружать новую версию расширения в Интернет-магазин Chrome.
Когда расширение может динамически изменять запросы способами, которые не были проверены во время проверки в Интернет-магазине Chrome, это подвергает пользователей риску фишинга или кражи данных. Например, правило перенаправления может быть неправильно использовано для внедрения партнерских ссылок без согласия.
Следовательно, мы разрешили расширениям добавлять до 5000 правил, что поощряло экономное использование этой функции и облегчало нам обнаружение злоупотреблений.
Однако разработчики расширений, включая AdGuard и Adblock Plus, провели собственный анализ и поделились данными о том, что более высокий лимит позволит использовать более актуальные правила, а пользователям с большим количеством пользовательских списков перейти на Manifest V3. Фактически, AdGuard сообщил, что каждую неделю в популярные списки вносится более 2600 изменений, а из пяти процентов пользователей, использующих списки пользовательских фильтров, каждый четвертый из этих пользователей имеет в общей сложности более 5000 динамических правил для всех ( источник) . ). AdGuard отметил это как серьезную проблему при переносе своего расширения на Manifest V3, и мы услышали аналогичные отзывы от других блокировщиков контента.
Мы определили, что некоторые правила фильтрации, например правила с действием block или allow , гораздо безопаснее и с меньшей вероятностью могут быть злоупотреблены. Они также составляют подавляющее большинство правил фильтрации рекламы. Основываясь на этом, я разработал и поделился предложением в группе сообщества веб-расширений по определению набора правил, которые, по нашему мнению, имеют меньший риск и допускают до 30 000 таких правил. Мы по-прежнему сохраняем верхний предел, чтобы избежать снижения производительности.
Это предложение было поддержано группой сообщества веб-расширений, поэтому мы реализовали его. Начиная с Chrome 121, более высокий предел в 30 000 правил применяется к безопасным правилам DNR, которые мы определяем как правила с block , allow , allowAllRequests upgradeScheme .
Согласно данным, предоставленным AdGuard, от 98 до 99 процентов их правил должны получить выгоду от этого более высокого лимита. Все остальные правила по-прежнему поддерживаются и могут быть добавлены в пределах существующего ограничения.
Это доступно в Chrome как константа MAX_NUMBER_OF_DYNAMIC_RULES . Ограничение правил для всех других правил динамических сетевых запросов остается на уровне 5000.
Уменьшен размер набора правил.
В Chrome 118 мы изменили значение по умолчанию для поля isUrlFilterCaseSensitive на false на основе отзывов сообщества. Это поле определяет, является ли правило фильтрации по URL-адресу чувствительным к регистру, и мы узнали, что большинство разработчиков использовали другое значение по умолчанию в своих расширениях. Следовательно, значение пришлось устанавливать много раз. Внеся это изменение, разработчики смогут добиться значительного уменьшения размера своих наборов правил.
Что дальше?
Мы стремимся продолжать инвестировать в API declarativeNetRequest, чтобы поддерживать как можно больше вариантов использования, и надеемся на продолжение работы с сообществом. В частности, мы хотели бы поблагодарить членов WECG за их участие, в том числе AdGuard за то, что они поделились значительным объемом данных, которые способствовали этой работе, а также всех поставщиков браузеров, которые принимали активное участие в разработке этого API.
Мы продолжим пересматривать существующие ограничения, чтобы при необходимости вносить коррективы. Чтобы поддержать это, мы планируем в ближайшем будущем поделиться некоторыми данными, которые мы собрали в рамках этой работы. Кроме того, мы работаем над добавлением дополнительных возможностей, таких как возможность сопоставления с заголовками ответов, что является частым запросом, который мы видели в расширениях для просмотра PDF-файлов. В любом случае мы продолжим сообщать о нашей работе и регулярно использовать группу сообщества веб-расширений как место для обсуждения идей и согласования того, что мы хотели бы рассмотреть дальше.