Google продолжает настаивать на ограничении API, востребованного в блокировщиках рекламы
В продолжение январской новости.
Симеон Винцент (Simeon Vincent), отвечающий в команде Chrome за взаимодействие с разработчиками дополнений (занимает должность Extensions Developer Advocate), прокомментировал текущую позицию Google в отношении третьей редакции манифеста Chrome, нарушающей работу многих дополнений для блокирования нежелательного контента и обеспечения безопасности. Компания не намерена отказываться от первоначального плана по прекращению поддержки блокирующего режима работы API webRequest, позволяющего менять принимаемый контент на лету. Исключение будет сделано лишь для редакции Chrome для предприятий (Chrome for Enterprise), в которых поддержка API webRequest будет сохранена в прежнем виде.
Для обычных пользователей Chrome API webRequest будет ограничен режимом только для чтения. На замену API webRequest для фильтрации контента предложен декларативный API declarativeNetRequest, который покрывает лишь ограниченную часть возможностей, используемых в современных блокировщиках рекламы. По сути вместо собственных обработчиков, имеющих полный доступ к сетевым запросам, предлагается готовый универсальный встроенный движок для фильтрации, собственными силами обрабатывающий правила блокировки. Например, API declarativeNetRequest не позволяет использовать собственные алгоритмы фильтрации и не даёт возможность создавать сложные правила, перекрывающие друг друга в зависимости от условий.
Разработчики дополнений для блокировки рекламы совместно подготовили список замечаний, в котором перечислили недостатки API declarativeNetRequest. Google согласился со многими замечаниями и дополнил API declarativeNetRequest. В частности, добавлена поддержка динамического изменения и добавления правил, обеспечена возможность удаления HTTP-заголовков, но только находящихся в белом списке (Referer, Cookie, Set-Cookie). В планах реализация поддержки добавления и замены HTTP-заголовков (например, для подстановки Set-Cookie и директив CSP) и возможность удаления и замены параметров запросов.
Предварительный вариант третьей версии манифеста, который определяет перечень возможностей и ресурсов, предоставляемых дополнениям Chrome, планируется в ближайшие месяцы применить для тестирования в экспериментальных сборках Chrome Canary.
При этом остаётся не совсем понятной мотивация запрета изменения принимаемого контента через API webRequest. Заявления, что блокирующий режим API webRequest негативно сказывается на производительности, так как перед выводом страницы браузер ожидает полного завершения работы обработчика дополнения, не выдерживают критики. Ранее проведённые тесты производительности дополнений для блокирования рекламы показали, что вносимая ими задержка ничтожна. В среднем применение блокировщика замедляет выполнение запроса лишь на доли миллисекунд, что пренебрежимо мало на общем фоне.
Второй аргумент, связанный с желанием защитить пользователей от неконтролируемого доступа дополнений к контенту, также не выглядит убедительным, так как вместо удаления давно сложившейся и распространённой в легитимных дополнениях функциональности можно было добавить новый тип полномочий и предоставить пользователю конечный выбор, устанавливать дополнение, имеющего полный доступ к сетевым запросам или нет. Кроме того, Google оставил поддержку использования API webRequest в режиме только для чтения, позволяющем выполнять полный мониторинг трафика, но не вмешиваться в него на низком уровне. Изменять же содержимое загруженных web-страниц дополнения могут через другие API (например, вредоносные дополнения как и раньше могут поставлять свою рекламу, запускать майнеры и анализировать содержимое форм ввода).
Рэймонд Хилл (Raymond Hill), автор систем блокирования нежелательного контента uBlock Origin и uMatrix, достаточно жестко прокомментировал ответ представителя Google и намекнул на демагогию и закулисные игры, в которых Google под видом благой возможности пытается продвинуть свои бизнес-интересы в области интернет-рекламы, получить контроль за механизмами её фильтрации и оправдать эти действия в глазах широкой публики.
Убедительных доводов в необходимости прекращения широко распространённого и востребованного среди разработчиков дополнений API он так и не получил. По мнению Рэймонда падение производительности не является доводом, так как страницы загружаются медленно из-за своей раздутости, а не из-за использования блокирующего режима webRequest в корректно реализованных дополнениях. Если бы Google волновала действительно производительность, они бы переделали webRequest на основе механизма Promise, по аналогии с реализацией webRequest в Firefox.
По мнению Рэймонда стратегия Google заключается в определении оптимального баланса между расширением пользовательской базы Chrome и ущербом бизнесу, наносимому из-за использования блокировщиков контента. На первом этапе экспансии Chrome компания Google вынуждена была мириться с блокировщиками рекламы, как одними из самых востребованных среди пользователей дополнений. Но после того, как Chrome занял доминирующие позиции, компания попыталась сместить баланс в свою пользу и получить контроль над блокировкой, начав продвигать инициативу по встраиванию в Chrome функции блокирования неприемлемой рекламы. API webRequest мешает данной цели, так как сейчас контроль над блокировкой контента находится в руках разработчиков сторонних блокировщиков рекламы.
P.S. Firefox не может считаться панацеей, т.к. в нынешнее время использует схожий механизм дополнений, а также Mozilla получает крупное финансирование от Google. Поэтому переход Firefox на схожий manifest v3 - это только вопрос времени.
Что-то никого не смущало, когда православно-австралийский Ad Muncher стал бесплатным. Вот только потом они свернулись.
После такой фигни я уже не удивился, тому что часть пользователей рунета приняла как должное блокировки от РКН, даже не попытавшись научиться их обходить.
Не испытываю абсолютно никаких проблем. Не вижу в клиенте никакой рекламы.
И это не считая того, что у лисы меньше десяти процентов рынка и стабильное снижение.
Кроме того, гугл не раз ловили на подлянках, которые он устраивал лисе. То ютуб в ней очень медленно открывается, то ещё что-нибудь такое. Вот и будет выбор, или сиди в хроме, смотри рекламу и наслаждайся нормальной работой сайтов, или сиди в лисе, блокируй рекламу и наслаждайся плохой работой.
Ну на самом деле мне было интересно узнать о факте таких вот заморочек браузерных войн. Ничего этот факт мне не даёт, но интересно. Я ещё помню те времена, когда сайты затачивались IE6 only.
Т.е. блокировка рекламы в Опере с большой вероятностью происходит также через API webRequest, который планируется перевести в режим ридонли. У меня нет уверенности, что у Оперы хватит сил поддерживать webRequest и все связанное с ним в движке, когда Google начнет это все постепенно выпиливать.
По AdBlock Plus, советую удалить этот malware, который принадлежит рекламной корпорации и имеет договора и финансирование от того же Google.
Brave — веб-обозреватель на основе веб-браузера Chromium на движке Blink
Если Brave это сделает, мы все обрадуемся и будем знать, куда перейти. Но уверенности в этом я что-то не испытываю.
Brave же вроде вклинила резалку прям во внутрь потрохов Chromium, а не как расширение, если не ошибаюсь.
Исключение будет сделано лишь для редакции Chrome для предприятий (Chrome for Enterprise), в которых поддержка API webRequest будет сохранена в прежнем виде.
Наверняка все альтернативные браузеры на хромиуме будут использовать эту версию как основу.
Google Chrome - проприетарный браузер с закрытым исходным кодом на основе Chromium.
Google Chrome for Enterprise - догадайся. Можно ли делать альтернативные браузеры, основываясь на этой версии?
Есть отдельные энтузиасты, которые пилят форки фаерфокса, например. Но это пиликанье не способно угнаться за основной веткой, не то что стать вровень с остальными игроками рынка браузеров. А гнаться приходится годами. Каждый новый выпуск браузера.
любой опенсорс проект имеет своей целью привлечение контрибуторов, поэтому постоянно работают над упрощением билда и доками, чтобы любой школьник мог в теории контрибутить
тот же waterfox один студент пилит и даже две ветки поддерживает
самое затратное это тестирование на разных платформах и железе, но хром это далеко не линукс
В рамках конференции @Scale, Rachel Potvin озвучила число линий кода хранящихся в едином репозитории компаниии - 2 миллиарда.
Как оказалось, Piper (cистема управления версиями, созданная Google), управляет 85 терабайтами данных кода, в котором 25 000 разработчиков модифицируют примерно 250 000 файлов и 15 миллионов строк кода каждую неделю.
Причём, датированный 2015 годом, т.е. сейчас ситуация ещё запущенней. Хотя это и не про хром, а про все проекты гугла.
Аналогичный запрос про фаерфокс даёт такой результат:
Firefox Quantum в цифрах
Целый год заняли у разработчиков создание и тестирование новой версии браузера;
75 342 файлов было изменено;
4 888 199 строк кода было добавлено;
6 886 199 строк кода было изменено;
6 тысяч аддонов доступно в магазине Mozilla;
Исправлено 369 ошибок, приводивших к снижению производительности системы;
Более 700 человек работало над созданием новой версии браузера;
Существует 265 252 859 191 742 656 903 069 040 640 000 новых способов кастомизации браузера из коробки.
Ты точно уверен, что студент, который пилит waterfox, полноценно перепиливает весь движок, а не просто вставляет его в обвязку из своего кода?
Просто я иногда сталкиваюсь с людьми и фактами о серьёзных программных продуктах, например, читаю блог одного из разработчиков pgsql. И в силу этого имею представление о колоссальных масштабах, абсолютно неподъёмных для одного человека. Он, этот разработчик, регулярно упоминает, сколько платформ им приходится поддерживать и какие трудности при этом возникают. Это при том, что у них пока меньше миллиона строк кода.
Про количество кода в браузерах тоже где-то встречал, но всё что помню — сопоставимо с кодом операционок. Может, раза в два-три меньше, но и только-то.
О, вот ещё нашёл статью о проверке кода хромиума PVS-Studio (инструмент для анализа кода). Статья от 2011 года:
С точки зрения программиста Chromium - это решение (solution), состоящее из 473 проектов. Общий объем исходного кода на языке C/C++ составляет около 460 мегабайт. Количество строк посчитать затрудняюсь.
В эти 460 мегабайт входит большое количество различных библиотек. Если их отделить, то останется около 155 мегабайт. Существенно меньше, но всё равно много. Тем более всё относительно. Многие из этих библиотек сделаны разработчиками Chromium в рамках задачи создания Chromium. Хотя такие библиотеки живут сами по себе, их можно вполне отнести к самому браузеру.
Ты всё ещё считаешь, что браузер довольно просто форкнуть и поддерживать ветку, в случае если ведущие производители уведут код куда-то не туда, например, напихают в него анальных зондов и анально же отгородят?
количество строк кода нихуя абсолютно не значит
ты вообще представляешь что такое мерж?
Ну ладно, это ещё относительно просто, а вот сделать полноценный форк и хоть чуть-чуть изменить его не в ту сторону, в которую идёт оригинал, а потом регулярно синхронизировать исходники — это вообще пиздец.
Я посмотрю ещё, сколько продержатся всякие василиски, которые как фаерфокс, только на xul. Как скоро они начнут отставать с поддержкой стандартов и т.д..
я и сам удивляюсь как ватерфокс еще держится
Сейчас JavaScript отключи - и всё, большей части интернета как не бывало. А уж без web 2.0, html5, css3. Будет просто нефункциональная мешанина из поехавшей разметки.
И анимация тут совсем ни при чём. Тут дело в базовой структуре и логике сайта, которые не поддерживаются в старых браузерах.
Во-вторых, за последние 2-3 года html, css и js значительно расширились. ПО, в разработке которого я участвую, в FF ниже 55 версии уже не работает. Вы с ним вряд ли столкнетесь, но не думаю, что моя контора оригинальна в таком подходе к версиям браузеров.
Имеются ли какие либо юзабельные альтернативы чтоб потихоньку перелезать пока не потребовалось делать это срочно?
Посмотрим ещё, как с этой гуглоподляной будет Адгвард справляться, пока я лично им доволен. Правда ставить в систему сертификат для него малясь не секурно, MitM все дела, но как бы всякие uBlock'и тоже не образец приватности. Опять же, для тех, кому только потестить навсегда, на Рутрекере давно валяется крякнутая версия.
Кстати, а кроме Gecko и Blink ща какие то ещё движки есть? Мультиплатформенные, ясен пень.
Например, поэтому или поэтому (на русском).
Google построила свой бизнес на рекламе. При этому она собирает много данных, чтобы более эффективно
впендюривать всякую хуйнюпоказывать её. Я не считаю, что это хорошая идея - пользоваться браузером от такой компании, для который ты потребитель и денежный мешок.Временами до 750 доходило
Механизм расширений был сделан не как в Chrome, а как было задано по общему стандарту по целому ряду причин. На хабре несколько раз поднималась эта тема, где шарящие люди расписали что да как, и почему в целом переход на текущую систему расширений был скорее хорошей идеей, чем плохой.
Рекомендую почитать про shadow dom v0. Великолепный устаревший API, который активно используется ютубом и поддерживается только в хроме.
Финансирование подразумевает что гугл вкладывает деньги в развитие мозиллы. На деле же мозилла продает гуглу услугу по выставлению гугла поисковиком по умолчанию. Как точно так же до этого продавала такую же услугу Yahoo. Так что последует мозилла по стопам гугла или нет явно зависит не от этого.