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

Мотивы Google:

• Блокирующий режим работы API webRequest приводит к большому потреблению ресурсов. При использовании данного API браузер вначале отправляет дополнению все содержащиеся в сетевом запросе данные, дополнение анализирует их и возвращает для дальнейшей обработки в браузере изменённый вариант или выдаёт инструкции по блокировке. При этом основные задержки возникают не на стадии обработки трафика дополнением, а из-за накладных расходов на координацию выполнения дополнения. В частности, подобные манипуляции требуют запуска для дополнения отдельного процесса, а также применения IPC для взаимодействия с этим процессом и механизмов сериализации данных;
• Дополнение полностью контролирует весь трафик на низком уровне, что открывает обширные возможности для злоупотреблений и нарушений приватности. По статистике Google в 42% всех выявленных вредоносных дополнений применялся API webRequest. Отмечается, что ежемесячно в каталоге Chrome Web Store блокируются попытки размещения в среднем 1800 вредоносных дополнений. К сожалению рецензирование не позволяет отлавливать все без исключения вредоносные дополнения, поэтому для усиления защиты было решено ограничить дополнения на уровне API. Основная идея в том, чтобы предоставлять дополнениям доступ не ко всему трафику, а только к тем данным, которые необходимы для реализации задуманной функциональности. В частности, для блокировки контента не обязательно предоставлять дополнению полный доступ ко всем конфиденциальным данным пользователя;
• Предложенный на замену декларативный API declarativeNetRequest берёт на себя всю работу по высокопроизводительной фильтрации контента и лишь требует от дополнений загрузки правил фильтрации. Дополнение при этом не может вмешиваться в трафик и приватные данные пользователя остаются неприкосновенны;
• Google учёл многие замечания в отношении недостаточной функциональности API declarativeNetRequest и расширил лимит на число правил фильтрации с изначально предложенных 30 тысяч на каждое расширение до глобального максимума в 150 тысяч, а также добавил возможности для динамического изменения и добавления правил, удаления и замены HTTP-заголовков (Referer, Cookie, Set-Cookie) и параметров запросов;
• Для предприятий оставлена возможность использования блокирующего режима работы API webRequest, так как политику применения дополнений определяет администратор, который понимает особенности инфраструктуры и осознаёт риски. Например, указанный API может применяться на предприятиях для учёта потоков трафика сотрудников и интеграции с внутренними системами;
• Целью Google является не ущемление и подавление дополнений для блокирования рекламы, а предоставление возможности создания более безопасных и производительных блокировщиков рекламы;
• Нежелание оставить блокирующий режим работы API webRequest наряду с новым declarativeNetRequest объясняется желанием ограничить доступ дополнений к конфиденциальным данным. Если оставить API webRequest как есть, то большинство дополнений не будут использовать более безопасный declarativeNetRequest, так как обычно при выборе между безопасностью и функциональностью основная масса разработчиков выберет функциональность.

Возражения разработчиков дополнений:

• Проведённые разработчиками дополнений тесты показывают ничтожное на общем фоне влияние на производительность дополнений для блокирования рекламы (при тестировании сравнивалась производительность различных дополнений, но без учёта накладных расходов на работу дополнительного процесса, координирующего выполнение обработчиков в блокирующем режиме API webRequest);
• Нецелесообразно полностью прекращать поддержку API, активно используемого в дополнениях. Вместо удаления можно добавить отдельное разрешение и жёстко контролировать адекватность его применения в дополнениях, что позволило бы избавить авторов многих популярных дополнений от полной переработки их продуктов и избежать урезания функциональности;
• Для снижения накладных расходов можно не удалять API, а переделать на основе механизма Promise, по аналогии с реализацией webRequest в Firefox;
• Предложенная альтернатива declarativeNetRequest не покрывает всех потребностей разработчиков дополнений для блокирования рекламы и обеспечения безопасности/приватности, так как не предоставляет полного контроля за сетевыми запросами, не позволяет использовать собственные алгоритмы фильтрации и не даёт возможность использовать сложные правила, перекрывающие друг друга в зависимости от условий;
• При текущем состоянии API declarativeNetRequest невозможно воссоздать в неизменном виде имеющуюся функциональность дополнений uBlock Origin и uMatrix, а также делает бессмысленным дальнейшую разработку порта NoScript для Chrome;
• Забота о приватности надумана, так как работающий в режиме только для чтения неблокирующий режим API webRequest оставлен и по-прежнему позволяет вредоносным дополнениям контролировать весь трафик, но не даёт возможность на лету вмешиваться в него (изменить содержимое, поставить свою рекламу, запустить майнеры и анализировать содержимое форм ввода можно и после окончания загрузки страницы);
• Разработчики браузеров Brave, Opera и Vivaldi, построенных на движке Chromium, намерены оставить в своих продуктах поддержку блокирующего режима работы webRequest.