Вашият рекламоблокър спря да работи преди тринадесет месеца. Chrome 138 го изключи през юли 2025 г. На 31 август Google премахна последното копие от магазина. Edge, Brave, Opera и Vivaldi използват същия енджин.

На 31 август 2026 г. Google премахна последните разширения, базирани на Manifest V2, от Chrome Web Store. uBlock Origin беше сред тях. Вече инсталирано копие запазва файловете си и продължава да работи, но няма да получава повече актуализации и не може да бъде инсталирано отново от магазина.

Тази дата не е началото на процеса, нито момента, в който бяха нанесени основните щети. Google публикува собствен времеви график за спирането на поддръжката, който разкрива цялостната история:

  • Януари 2022 г.: Магазинът спира да приема нови публични разширения с Manifest V2.
  • 3 юни 2024 г.: Предупредителни банери се появяват в Beta, Dev и Canary версиите, а MV2 разширенията губят значката „Featured“.
  • 9 октомври 2024 г.: Chrome започва да изключва MV2 разширенията в стабилния си канал, оставяйки опция потребителите да ги включат отново.
  • 31 март 2025 г.: Разширенията са изключени по подразбиране във всички канали.
  • 24 юли 2025 г.: Chrome 138 премахва възможността за повторното им включване.
  • 31 август 2026 г.: Останалото съдържание е окончателно премахнато от магазина.

24 юли 2025 г. е денят, в който всичко приключи. Времевият график на Google посочва ясно: с Chrome 138 за всички потребители във всички канали разширенията с Manifest V2 са деактивирани, а възможността за повторното им включване е премахната. Браузърът направи това автоматично, без да иска разрешение. На 31 август просто беше премахнато последното копие от витрината – тринадесет месеца след като функционалността вече беше спряла за потребителите.

За да разберем защо един рекламоблокър не може просто да бъде пренаписан спрямо новите правила, трябва да разгледаме какво отне Manifest V3. Един рекламоблокър прави едно основно нещо – той стои между уеб страницата и интернет и за всеки файл, който страницата иска да зареди (изображение, скрипт или проследяващ пиксел), той решава дали този файл изобщо да бъде изтеглен. Къде се намира той в тази верига и колко има право да вижда е решение на самия браузър. Това разрешение се наричаше webRequest в продължение на години.

В своя блокиращ вид webRequest поставяше разширението на първо място във веригата. Мрежовата заявка, която браузърът се канеше да направи, преминаваше през собствения код на разширението преди каквото и да било да напусне устройството. Разширението прочиташе заявката, проверяваше закъде е насочена, анализираше заглавните части на отговора (response headers) и след това вземаше решение: да я допусне, да я отмени, да я пренасочи или да я промени. Логиката се намираше вътре в разширението и можеше да бъде толкова сложна, колкото я беше направил нейният автор.

Manifest V3 премахва това място във веригата. На негово място идва declarativeNetRequest. Разширението вече не вижда заявките. То предоставя на Chrome списък с правила предварително, а Chrome извършва съпоставянето самостоятелно. Документацията на Google представя това като подобрение на поверителността, тъй като разширението променя заявките, без да ги прихваща или да чете съдържанието им. В конфигурационния файл (manifest) на разширението разликата изглежда малка.

Решението за блокиране, което преди беше ред код, изпълняван от разширението, сега е запис в списък, обработван от Chrome. А правилата, които Chrome обработва вместо вас, са правила, които Chrome трябва да брои. И точно тук блокиращите съдържание приложения срещат сериозно ограничение.

Числата идват от собствената документация на API на Chrome. Едно разширение може да активира до 50 статични набора от правила едновременно от общо 100 включени, да поддържа 30 000 динамични правила (от които 5 000 от т.нар. „несигурен“ тип) и 5 000 сесийни правила. В допълнение до 1 000 правила могат да използват регулярни изрази (regular expressions), които се броят отделно за статичния набор и за динамичните/сесийните правила. Тези числа изглеждат щедри, докато не ги съпоставите с реален филтриращ списък.

Chrome гарантира на дадено разширение 30 000 статични правила. Всичко над това се взема от глобален ресурс, споделян с останалите разширения в същия браузър, така че наличното зависи от това какво друго имате инсталирано. Собствената документация за MV3 на uBlock Origin определя този общ лимит на Chromium на 330 000.

Второ ограничение няма нищо общо с броенето. declarativeNetRequest се прилага само за заявки, които достигат до мрежовия стек. Отговор, предоставен от service worker или извлечен от CacheStorage, никога не стига дотам, така че никое правило не го засяга.

Броенето е само половината от проблема, тъй като филтриращият списък на блокъра не е просто плосък списък с домейни. Голяма част от него съдържа условия и точно тези условия не оцеляват при прехода към правило в Chrome. Четири опции за филтриране от собствения синтаксис на uBlock Origin показваха това:

Първите две се отнасят до това кой изпраща заявката. Стандартното съпоставяне за първа страна (first-party) и трета страна (third-party) работи на ниво основен домейн, така че всичко под example.com се счита за една и съща страна. strict1p и strict3p сравняват пълното име на хоста (hostname), което позволява на блокъра да улови проследяващ елемент, разположен на субдомейн на сайта, който посещавате. Третата опция създава директива за пренасочване без прикачен блокиращ филтър, така че заявката само се замени за h