Хакер #305. Многошаговые SQL-инъекции
Разработчики Google собираются внести ряд изменений работу Chrome Extensions, из-за чего могут пострадать блокировщики контента (в частности, uBlock Origin и uMatrix). Дело в том, что возможности и ограничения для расширений определяются манифестом, который в настоящее время представлен в виде версии 2.
Сейчас разработчики уже готовят третью версию манифеста, где, согласно нынешней версии документа, планируют ограничить работу webRequest API, что может оказаться критически важно для функционирования блокировщиков. Вместо webRequest блокировщикам будет предложено использовать declarativeNetRequest. Разумеется, улучшения направлены на повышение безопасности и производительности.
Разработчик расширений uBlock Origin и uMatrix Реймонд Хил (Raymond Hill) предупреждает, что отказ от webRequest станет «смертью» для его блокировщиков, тогда как uBlock Origin насчитывает свыше 10 000 000 пользователей.
«Если этот (весьма ограниченный) API declarativeNetRequest станет единственным способом, как блокировщиков контента могут исполнять свою работу, по сути это означает, что два блокировщика, работу которых я поддерживал долгие годы, uBlock Origin и uMatrix, более не смогут существовать», — пишет Хилл на странице баг-трекинга манифеста.
В сущности, проблема заключается в том, что webRequest API позволяет расширениям не просто блокировать рекламный контент на страницах, но и перехватывать сетевые запросы, чтобы иметь возможность блокировать, модифицировать и перенаправлять их. По мнению разработчиков Google, это слишком сильно сказывается на скорости загрузки страниц, поэтому в будущем webRequest API будет разрешено только читать запросы, но не вмешиваться.
В свою очередь, declarativeNetRequest позволяет Chrome (а не самому расширению) решать, как поступать с сетевыми запросами, устраняя при этом «узкое место» и повышая безопасность. Разработчики Google уверены, что использование declarativeNetRequest API будет лучше для приватности пользователей, ведь так расширения более не смогут читать сетевые запросы, сделанные от лица пользователя.
Хилл выражает опасение, что эти перемены могут сказаться и на другой функциональности, к примеру, откажут блокирование медиаэлементов, превышающих заданный размер, и отключение исполнения JavaScript через инжекты Content-Security-Policy директив. Хуже того, по его словам, declarativeNetRequest предлагает разработчикам единственную имплементацию фильтровочного движка, к тому же ограниченную лишь 30 000 фильтров, что не выдерживает сравнения даже с EasyList.
Девелопер убежден, что в текущем виде манифест третьей версии попросту лишит пользователей контроля над контентом. Изменения могли бы быть неплохими, если бы вся экосистема Google с его рекламодателями и издателями по умолчанию вызывала бы больше доверия, чем решения сторонних разработчиков. Однако если проблемы наблюдаются в самой экосистеме, пользователи могут захотеть прибегнуть к помощи сторонних решений для фильтрации сетевых запросов, невзирая даже на тот факт, что это может мешать корректной работе веб-страниц.
