Przyznajmy sobie, poza wąskim gronem zainteresowanych, wojny przeglądarek obchodzą niewielu. Przez lata nikt nie zwracał większej uwagi na cementowanie przez Google monopolu, czy inne praktyki, za które zresztą korporacja niejednokrotnie karana była przez UE. Ale problem zmian w rozszerzeniach blokujących reklamy to osobna sprawa, która dotyka i angażuje większość użytkowników przeglądarek, nawet tych niezaawansowanych.
Ostatni etap tej – nie bójmy się tego słowa – batalii o manifest rozszerzeń Chromium opisywaliśmy wczoraj. Google nie w jednym, lecz w dwóch publikacjach, próbuje przekonywać miliony, że porzucenie webRequest API ma służyć nie umacnianiu władzy korporacji nad tym, co oglądają internauci, lecz… ich bezpieczeństwu. Ta argumentacja nie przekonuje jednak wielu, a przeciwni (w mniej lub bardziej otwarty sposób) planowanym zmianom w manifeście rozszerzeń są nawet twórcy przeglądarek bazujących na Chromium.
Zobacz też: Google chce zablokować uBlocka Origin w Chromium. Czas na zmianę przeglądarki?
Dziś docierają do nas nowe informacje na temat zmian w rozszerzeniach blokujących reklamy w Chromium. W kodzie źródłowym przeglądarki znaleziono bowiem commit, który wskazuje, że Google pracuje nad… własnym rozszerzeniem blokującym reklamy. Rozwijany ma być także konwerter filtrów wykorzystywanych przez najpopularniejsze dziś rozszerzenia blokujące na reguły, które obsługiwane będzie za pomocą nowego declarativeNetRequest API.
Czy zatem Google ma zamiar nie tylko utrzeć nosa (jak eufemistycznie można nazwać groźbę całkowitej eliminacji) rozszerzeniom takim jak uBlock czy Ghostery, ale jeszcze zaproponować zamiennik? Niekoniecznie. Wygląda na to, że opracowywane przez Google rozszerzenie nie zostanie upublicznione. Ma jedynie stanowić modelowy przykład wyższości declarativeNetRequest API nad webRequest API, zamknąć usta krytykom, którzy uważają, że zmiany w manifeście rozszerzeń Chromium są motywowane wyłącznie biznesowo.
Zobacz też: Efektywne blokowanie reklam w Google Chrome tylko dla użytkowników biznesowych
Warto bowiem przypomnieć, że jeszcze przed uruchomieniem narracji o rzekomych niebezpieczeństwach niesionych przez webRequest API, Google posiłkowało się argumentem wydajności. Rozszerzenia blokujące treści reklamowe za pośrednictwem declarativeNetRequest API miały być szybsze niż dodatki przedstawiane jako ociężałe i przestarzałe w związku z używaniem webRequest API. Wiele wskazuje, że Google nigdy nie wypuści swojego blokera poza obręb wewnętrznych testów, może on jednak dostarczyć danych przydatnych w toczonej batalii.
