Предстоящий Манифест V3 для расширений Google Chrome изменит принцип работы блокировщиков рекламы в Chrome. Правильный ли это путь для блокировщиков рекламы и Google?
Гугл Хром это самый популярный кроссплатформенный веб-браузер, доступный на рынке прямо сейчас, претендует на 62,7% глобальной доли использования браузера до мая 2019 года: Safari от Apple занимал второе место с 15,89%, а Firefox от Mozilla — 5,07%. Из-за своей львиной доли малейшие изменения, которые Google Chrome предпринимает для своей платформы, в конечном итоге затрагивают миллионы пользователей по всему миру. Поэтому, когда Google объявил о следующей версии манифеста расширений в виде манифеста V3 для расширений Google Chrome, мы знали, что нас ждали большие изменения, особенно когда выяснилось, что Google встраивает API-интерфейс блокировки контента в Chrome. сам.
Что такое Манифест V3?
Если вы активный пользователь Chrome, вы, несомненно, используете несколько расширений. Расширения — это небольшие программы, которые настраивают возможности просмотра с помощью
API, которые предоставляет браузер, что позволяет пользователям адаптировать функциональность и поведение в соответствии со своими индивидуальными потребностями и предпочтениями. Эти расширения распространяются в основном через Интернет-магазин Chrome, который содержит более 180 000 расширений.С в конце прошлого годаGoogle работает над «Манифестом V3», набором предлагаемых изменений в платформе расширений Chrome, которые можно классифицировать как «критические изменения». Как документ общественного обсуждения Манифеста V3 Как утверждается, версия манифеста расширения представляет собой механизм ограничения определенных возможностей определенным классом расширений. Эти ограничения могут иметь форму минимальной или максимальной версии. Ограничение минимальной версии позволяет новым API или возможностям быть доступными только для новых расширений. в то время как ограничение максимальной версии манифеста позволяет постепенно устарел.
Проще говоря, новая версия манифеста позволяет Chrome ограничить API и функции этой новой версией манифеста. чтобы заставить разработчиков расширений перейти от некоторых старых API из-за их негативного воздействия на пользователя. опыт. Реализация расширения в Manifest V3 теоретически должна обеспечить более сильные гарантии с точки зрения безопасности, конфиденциальности и производительности.
Хотя в Манифесте V3 представлен широкий спектр изменений, наиболее спорное изменение связано с решением Google ограничить возможности блокировки, присутствующие в существующей версии. chrome.webRequest API (и сосредоточить API на наблюдении, а не на блокировке), а затем представить эти возможности блокировки через новый chrome.declarativeNetRequest API. Это конкретное изменение имеет разожгло сообщество поскольку в конечном итоге он нацелен на механизм блокировки рекламы известного расширения для блокировки рекламы, uБлок Происхождение, и напрямую влияет на более чем 10 миллионов пользователей.
Прежде чем рассмотреть этот вопрос, давайте посмотрим, как веб-запрос API сравнивается с декларативныйNetRequest API.
API веб-запросов и API декларативных сетевых запросов
Настоящее
Официальное описание Web Request описывает API следующим образом:
Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight.
С помощью веб-запроса Chrome отправляет все данные в сетевом запросе к прослушивающему их расширению. Затем расширение имеет возможность оценить запрос и указать Chrome, что делать с запросом: разрешить его, заблокировать или отправить с некоторыми изменениями.
Следуйте последовательности событий, чтобы понять, что происходит, когда расширения используют API веб-запросов. Когда пользователь с установленным расширением веб-запроса нажимает на ссылку, Chrome сообщает расширению, что запрос данных был сделан до того, как запрос достигнет сервера. На этом этапе расширение может изменить запрос. Затем сервер отвечает, но ответ снова проходит через расширение, и расширение может определять, нужно ли изменить ответ. Затем Chrome, наконец, отображает страницу, и пользователь может просмотреть результат своего клика.
Когда Chrome сдает все данные в сетевом запросерасширения, использующие API веб-запросов, имеют доступ для чтения и изменения всего, что пользователь делает в Интернете. Таким образом, хотя блокировщики контента, такие как uBlock Origin, разумно используют потенциал этого API, Google утверждает, что другие расширения со злыми намерениями злоупотребляли ими, чтобы получить доступ к личным данным пользователей. информация. По данным Google, с января 2018 года 42% вредоносных расширений используют API веб-запросов. Google также утверждает, что API в качестве блокирующей версии требует «значительных затрат на производительность». Для этого требуется постоянный и зачастую длительный процесс, который принципиально несовместим с «ленивым» процессом. процессы.
В Манифесте V3 Google предлагает ограничить этот API в форме блокировки. В качестве альтернативы Google предоставляет API декларативного сетевого запроса.
Будущее
Официальное описание Declarative Net Request описывает API следующим образом:
The chrome.declarativeNetRequest API is used to block or modify network requests by specifying declarative rules.
Благодаря декларативному сетевому запросу Chrome не нужно отправлять всю информацию о запросе прослушивающему расширению. Вместо этого расширение регистрирует в Chrome правила, которые заранее сообщают браузеру, что делать, если обнаружены определенные типы запросов.
Расширение заранее определяет свои правила. Затем запрос пользователя сопоставляется с этим правилом браузером (а не расширением), и действие также выполняется браузером, после чего страница отображается. Google отмечает, что это позволяет им обеспечить эффективность, поскольку они могут контролировать алгоритм, определяющий результат, и могут предотвращать или отключать неэффективные правила. Это также дает конечным пользователям лучшие гарантии конфиденциальности, поскольку детали сетевого запроса не раскрываются расширению. Поскольку постоянные и длительные процессы больше не нужны (поскольку правила прописываются заранее), Google утверждает, что этот подход также обеспечивает повышение производительности, что сделает расширения значительно более жизнеспособными в условиях ограниченных ресурсов. платформы.
Декларативный сетевой запрос будет доступен как для Манифеста V2 (текущий), так и для Манифеста V3, но это будет основной способ, с помощью которого Google позволит изменять сетевые запросы в Манифесте V3.
Споры
Кажется, что изменения Google имеют смысл, пока вы не услышите другую сторону истории, в основном о блокировщиках рекламы. Эта конкретная миграция API рассматривается как способ Google уничтожить блокировщики рекламы, поскольку она фундаментально меняет способ работы одного из самых популярных блокировщиков рекламы. Это связано с «теорией», согласно которой Google заинтересован в этом изменении больше с точки зрения бизнеса, чем с точки зрения безопасности пользователей. В конце концов, доходы Google в значительной степени зависят от рекламы, а блокировщики рекламы воспринимаются как прямая угроза для клиентов Google на этом фронте, как выяснилось в ходе Подача Alphabet формы 10-K SEC за 2018 год (с помощью Регистр):
Новые и существующие технологии могут повлиять на нашу способность настраивать рекламу и/или блокировать рекламу в Интернете, что нанесет вред нашему бизнесу.
Были разработаны технологии, которые усложняют настраиваемую рекламу или вообще блокируют ее показ, а некоторые поставщики онлайн-сервисов имеют интегрированные технологии, которые потенциально могут ухудшить основные функции сторонних цифровых сервисов. реклама. Большую часть наших доходов Google составляют комиссии, выплачиваемые нам в связи с показом рекламы в Интернете. В результате такие технологии и инструменты могут отрицательно повлиять на наши операционные результаты.
Гуглу пришлось опубликовать заявление для решения этой проблемы, подтвердив свою позицию о том, что это изменение отвечает интересам конфиденциальности пользователей, а не является прямой атакой на блокировщиков рекламы:
Мы не препятствуем разработке блокировщиков рекламы и не запрещаем пользователям блокировать рекламу. Вместо этого мы хотим помочь разработчикам, в том числе блокировщикам контента, писать расширения таким образом, чтобы защитить конфиденциальность пользователей.
Необходимо упомянуть два самых популярных блокировщика рекламы, доступных в Google Chrome: uБлок Происхождение и Adblock Plus, оба из которых используют разные подходы для достижения одного и того же результата блокировки контента. uBlock Origin в значительной степени полагается на API веб-запросов, и на протяжении многих лет сообщество отдавало предпочтение этому расширению. Adblock Plus и другие расширения для блокировки контента также полагаются на блокирующую часть веб-запроса, поэтому изменения в этом API в конечном итоге повлияют на большинство блокировщиков контента, по крайней мере, в некоторой степени.
Попытка Google отказаться от поддержки Web Request по сути убьет uBlock Origin в его нынешнем формате, что действительно затронет многих пользователей. Пока пользователи, не лояльные (и не желающие беспокоиться о том, как достигается блокировка рекламы), будут искать альтернативные решения, имеющие свои недостатки, это станет невозможным. для лоялистов и энтузиастов разработать новые конструкции механизмов фильтрации, чтобы обойти различные методы, которые в конечном итоге придумают веб-сайты для борьбы с блокировщиками рекламы в этом конкретном API.
Декларативный сетевой запрос также предлагался как довольно ограниченный механизм фильтрации, поскольку он был изначально планировалось иметь ограничение в 30 000 правил статической фильтрации для каждого расширения (правила, которые объявляются во время установки); и ограничение в 5000 правил для правил динамической фильтрации для каждого расширения (правила, которые можно добавить после установки). Любые лишние правила будут игнорироваться, что является некоторой проблемой, поскольку сам EasyList для Adblock Plus имеет 70 000 правил, а uBlock Origin можно настроить для работы с более чем 100 000 правил. После первоначальной реакции сообщества, Гугл ответил пообещав изменить лимит статических правил с 30 000 правил на расширение до глобального максимума в 150 000 правил. Побочным эффектом этого является то, что пользователи не могут использовать другие сценарии с большим количеством правил в сочетании с блокировщиком рекламы, поэтому пользователям придется манипулировать своими предпочтениями.
Помимо ограниченного предела фильтрации, декларативный сетевой запрос может перенаправлять только на статические URL-адреса, поэтому сопоставление с образцом не поддерживается. uBlock Origin в значительной степени полагается на сопоставление шаблонов, и разработчик расширения заявили, что переоборудовать невозможно. алгоритм сопоставления его расширения для удовлетворения требований API. API также потребует полного обновления расширения, чтобы просто обновить список фильтров, что было бы слишком частым действием, учитывая частота обновления этих списков фильтров. Конечно, эти обновления также будут зависеть от критериев и процессов проверки расширений Google.
С другой стороны, Google всегда придерживался позиции, согласно которой ее намерение отказаться от веб-запросов исходит из с точки зрения безопасности, поскольку API веб-запросов в его нынешнем виде слишком мощный и оставляет очень широкое пространство для злоупотреблять. Это злоупотребление не является чисто теоретическим: Google упомянул, что 42% вредоносных расширений злоупотребляют этим API. Apple Safari API блокировки контента был разработан как Declarative Net Request по тем же причинам, поскольку у мошеннического разработчика меньше возможностей для использования. В случае ослабленного веб-запроса сетевые запросы по-прежнему будут доступны для наблюдения, но для них потребуются разрешения на соответствующих хостах. В Манифесте V3 разрешения хоста также существенно изменяются, и их больше нельзя предоставлять в полном объеме во время установки.
Google также использовал накладные расходы на производительность в качестве мотивации для перехода. Оценка сетевых запросов происходит в потоке JavaScript расширения, что может отрицательно сказаться на производительности. В качестве опровержения разработчик uBlock Origin упоминает, что его расширение не влечет за собой каких-либо существенных потерь производительности даже если необходимо применить до 140 000 статических фильтров. Утверждается, что понесенные затраты легко окупаются за счет ресурсов, которые не могут быть загружены с удаленных серверов и, следовательно, не обработаны браузером.
Несмотря на то, что Google не использует эту аргументацию, можно привести один аргумент против Web Request в пользу эффективности блокировки рекламы. При использовании веб-запроса, если расширение не отвечает вовремя (из-за задержки или сбоя), запрос на сетевую обработку явно разрешается, что позволяет рекламе проходить через блокировщик рекламы. С другой стороны, декларативный сетевой запрос не страдает от этого недостатка. Вместо этого реклама будет проходить, если она не попадет в статические правила, и это будет происходить чаще, чем нет.
Заключение
Из приведенных выше объяснений становится ясно, что Declarative Net Request не является функциональным клоном 1:1 для блокировки. возможности API веб-запросов, и разработчики расширений обязательно будут недовольны, когда их тяжелая работа будет затруднена такие изменения. Но рассуждения Google также имеют вес: веб-запрос слишком мощный инструмент, и его возможности необходимо увеличить. ограничивается более широкими интересами сообщества пользователей (которое включает в себя как обычных пользователей, так и энтузиасты).
Переход к декларативному сетевому запросу также мог бы стать положительным пиар-ходом — в конце концов, Google добавляет в Chrome встроенный API-интерфейс блокировки контента! Но поскольку новый API имеет свои собственные серьезные ограничения, сообщество справедливо рассматривает это как подрезание крыльев. В идеальном мире Google следовало бы изучить работу блокировщиков рекламы, таких как uBlock Origin, прежде чем предлагать новый API. В нынешнем виде новый API может использовать дальнейшее смягчение ограничений правил, чтобы приспособиться к сценариям, когда пользователи захотят использовать два расширения с большим количеством фильтров.
В соответствии с Регистр, первые сборки с изменениями Manifest V3 будут доступны с июля 2019 года. Мы надеемся, что Google учтет отзывы, полученные от сообщества разработчиков расширений, в этих сборках.
Особая благодарность главному редактору XDA Мишаалу Рахману за его вклад и помощь!
Изменить: в статье неправильно приравнивается работа Adblock Plus к работе Declarative Net Request API. В статью были внесены соответствующие изменения. На Adblock Plus также повлияет удаление возможностей блокировки API веб-запросов.