Разработчики браузера Chrome попытались (https://blog.chromium.org/2019/06/web-request-and-declarativ...) обосновать (https://security.googleblog.com/2019/06/improving-security-a...) прекращение поддержки блокирующего режима работы API webRequest, позволяющего менять принимаемый контент на лету и активно применяемого в дополнениях для блокирования рекламы,
защиты от вредоносного ПО, фишинга, шпионящей за пользователями активности, родительского контроля и обеспечения приватности.
Мотивы Google:
- Блокирующий режим работы API webRequest (https://developer.chrome.com/extensions/webRequest) приводит к большому потреблению ресурсов.
При использовании данного API браузер вначале отправляет дополнению все содержащиеся в сетевом запросе данные, дополнение анализирует их и возвращает для дальнейшей обработки в браузере изменённый вариант или выдаёт инструкции по блокировке. При этом основные задержки возникают не на стадии обработки трафика дополнением, а из-за накладных расходов на координацию выполнения дополнения. В частности, подобные манипуляции требуют запуска для дополнения отдельного процесса, а также применения IPC для взаимодействия с этим процессом и механизмов сериализации данных;
- Дополнение полностью контролирует весь трафик на низком уровне, что открывает обширные возможности для злоупотреблений и нарушений приватности. По статистике Google в 42% всех выявленных вредоносных дополнений применялся API webRequest. Отмечается, что ежемесячно в каталоге Chrome Web Store блокируются попытки размещения в среднем 1800 вредоносных дополнений. К сожалению рецензирование не позволяет отлавливать все без исключения вредоносные дополнения, поэтому для усиления защиты было решено ограничить дополнения на уровне API. Основная идея в том, чтобы предоставлять дополнениям доступ не ко всему трафику, а только к тем данным, которые необходимы для реализации задуманной функциональности. В частности, для блокировки контента не обязательно предоставлять дополнению полный доступ ко всем конфиденциальным данным пользователя;
- Предложенный на замену декларативный API declarativeNetRequest (https://developers.chrome.com/extensions/declarativeNetRequest) берёт на себя всю работу по высокопроизводительной фильтрации контента и лишь требует от дополнений загрузки правил фильтрации. Дополнение при этом не может вмешиваться в трафик и приватные данные пользователя остаются неприкосновенны;
- Google учёт многие замечания в отношении недостаточной функциональности API declarativeNetRequest и расширил лимит на число правил фильтрации с изначально предложенных 30 тысяч до 150 тысяч, а также добавлен возможности для динамического изменения и добавления правил, удаления и замены HTTP-заголовков (Referer, Cookie, Set-Cookie) и параметров запросов;
- Для предприятий оставлена возможность использования блокирующего режима работы API webRequest, так как политику применения дополнений определяет администратор, который понимает особенности инфраструктуры и осознаёт риски. Например, указанный API может применяться на предприятиях для учёта потоков трафика сотрудников и интеграции с внутренними системами;
- Целью Google является не ущемление и подавление дополнений для блокирования рекламы, а предоставление возможности создания более безопасных и производительных блокировщиков рекламы;
- Нежелание оставить блокирующий режим работы API webRequest наряду с новым declarativeNetRequest объясняется желанием ограничить доступ дополнений к конфиденциальным данным. Если оставить API webRequest как есть, то большинство дополнений не будут использовать более безопасный declarativeNetRequest, так как обычно при выборе между безопасностью и функциональностью основная масса разработчиков выберет функциональность.
Возражения (https://docs.google.com/document/d/1sKZFojq_fUusrebKsyNHfRk_...) разработчиков (https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss...) дополнений (https://docs.google.com/viewer?a=v&pid=forums&srcid=MTc1Mjc4...):
- Проведённые разработчиками дополнений тесты (https://www.opennet.ru/opennews/art.shtml?num=50169) показывают ничтожное на общем фоне влияние применения блокирующего режима работы API webRequest;
- Нецелесообразно полностью прекращать поддержку API, активно используемого в дополнениях. Вместо удаления можно добавить отдельное разрешение и жёстко контролировать адекватность его применения в дополнениях, что позволило бы избавить авторов многих популярных дополнений от полной переработки из продуктов и избежать урезания функциональности;
- Для снижения накладных расходов можно не удалять API, а переделать на основе механизма Promise, по аналогии с реализацией webRequest в Firefox;
- Предложенная альтернатива declarativeNetRequest не покрывает всех потребностей разработчиков дополнений для блокирования рекламы и обеспечения безопасности/приватности, так как не позволяет полностью контролировать сетевые запросы, не позволяет использовать собственные алгоритмы фильтрации и не даёт возможность использовать сложные правила, перекрывающие друг друга в зависимости от условий;
- Забота о приватности надумана, так как работающий в режиме только для чтения неблокирующий режим API webRequest оставлен и по-прежнему позволяет вредоносным дополнениям контролировать весь трафик, но не даёт возможность на лету вмешиваться в него (изменить содержимое, поставить свою рекламу, запустить майнеры и анализировать содержимое форм ввода можно и после окончания загрузки).
URL: https://blog.chromium.org/2019/06/web-request-and-declarativ...
Новость: https://www.opennet.ru/opennews/art.shtml?num=50868
