Google today reached the final milestone in a browser-extension transition that has been years in the making, all remaining Manifest V2 extensions were removed from the Chrome Web Store.
First, I don’t care if they agree with me or not. It is an open source project. They said from they never intended to try to make a 1:1 extension with UBO. They clearly lay out the positives of MV3 as well, and the scripts permission feature is a relatively new addition. You or anyone can contribute or fork it you want to add something.
I have spent enough time working on MV3 to know Chromium has solved a lot of the challenges. If you want to have a technical discussion about the APIs and differences or how you might do something with MV3, then let’s have the discussion. I never tried to claim MV3 is perfect.
I just have little patience for essentially non-technical cultists who go around spreading misinformation while acting like they know way more than they do. Prove it then… 99% of people like you never actually want to have a real technical discussion, because you spread your opinions based on feelings and not facts.
Prove it then… 99% of people like you never actually want to have a real technical discussion, because you spread your opinions based on feelings and not facts.
This is extremely funny that you’re trying to insult me, based on your feelings and not facts.
My only participation in this thread was that UBO Lite creator disagrees with you, which he publicly stated, but you felt… Offended? (No idea) - and decided to insult me rather than to deal with facts.
This is extremely funny that you’re trying to insult me, based on your feelings and not facts.
My only participation in this thread was that UBO Lite creator disagrees with you, which he publicly stated, but you felt… Offended? (No idea) - and decided to insult me rather than to deal with facts.
There is a word for people like you.
Troll.
Citing gorhill’s disclaimer that uBOL isn’t a 1:1 clone of uBO doesn’t prove Chrome is “ad-infested”—it conflates advanced power-user filtering with everyday ad blocking. Many limitation were Firefox-exclusive APIs that Chrome MV2 never supported in the first place.
Under the hood, standard filter lists compile directly into native C++ evaluation via declarativeNetRequest, while cosmetic element hiding and anti-adblock defusers run through the scripting and userScripts APIs. Furthermore, synchronous webRequestBlocking is still built into the Chromium engine for policy installs. Pointing out the architectural reality of how these APIs actually execute isn’t trolling; it’s addressing technical mechanics rather than hyperbole.
I‘m a semi-technical user, I don‘t want a technical discussion, I want facts I‘m able to understand. If you‘d be knowledgeable, you should be able to explain it. You didn‘t, tho. You used a lot of words, but said nothing. Why should your arrogant, but empty yapping do anything for me?
You can’t claim to be “semi-technical” while simultaneously refusing to look at technical facts and dismissing platform mechanics as “empty yapping.” How a browser engine executes extensions is inherently technical. Claiming you want facts while ignoring the architecture just means you’d rather stick with an emotional narrative than understand how the software actually works.
Chrome MV2 never supported some features people claim were lost: Features like in-flight response body rewriting and pre-socket IP filtering were Firefox-exclusive APIs (filterResponseData). Chrome MV2 never had them, so MV3 did not take them away.
webRequestBlocking is not dead in MV3. Google did not delete the synchronous blocking engine from Chromium. It requires installing via policy now. If an extension is provisioned via local policy, full programmatic webRequestBlocking runs in MV3 just as it did in MV2.
Everyday ad blocking works normally. For standard Web Store installs, uBlock Origin Lite compiles the standard filter lists (EasyList, EasyPrivacy, uBO filters) into native browser rules. Banners, trackers, and video ads are blocked.
The original claim was that “Chrome users don’t know what an ad-free web looks like.” That is provably false. If you want to understand the issue as a “semi-technical” user, you have to separate actual browser engine mechanics from internet hyperbole.
Literally, the creator of UBO Lite disagrees with you.
Why are you like this?
Too much corporate propaganda
First, I don’t care if they agree with me or not. It is an open source project. They said from they never intended to try to make a 1:1 extension with UBO. They clearly lay out the positives of MV3 as well, and the scripts permission feature is a relatively new addition. You or anyone can contribute or fork it you want to add something.
I have spent enough time working on MV3 to know Chromium has solved a lot of the challenges. If you want to have a technical discussion about the APIs and differences or how you might do something with MV3, then let’s have the discussion. I never tried to claim MV3 is perfect.
I just have little patience for essentially non-technical cultists who go around spreading misinformation while acting like they know way more than they do. Prove it then… 99% of people like you never actually want to have a real technical discussion, because you spread your opinions based on feelings and not facts.
This is extremely funny that you’re trying to insult me, based on your feelings and not facts.
My only participation in this thread was that UBO Lite creator disagrees with you, which he publicly stated, but you felt… Offended? (No idea) - and decided to insult me rather than to deal with facts.
There is a word for people like you.
Troll.
Citing gorhill’s disclaimer that uBOL isn’t a 1:1 clone of uBO doesn’t prove Chrome is “ad-infested”—it conflates advanced power-user filtering with everyday ad blocking. Many limitation were Firefox-exclusive APIs that Chrome MV2 never supported in the first place.
Under the hood, standard filter lists compile directly into native C++ evaluation via
declarativeNetRequest, while cosmetic element hiding and anti-adblock defusers run through thescriptinganduserScriptsAPIs. Furthermore, synchronouswebRequestBlockingis still built into the Chromium engine for policy installs. Pointing out the architectural reality of how these APIs actually execute isn’t trolling; it’s addressing technical mechanics rather than hyperbole.Cool. Except that you didn’t do that before. You’re doing that now, after the fact.
I‘m a semi-technical user, I don‘t want a technical discussion, I want facts I‘m able to understand. If you‘d be knowledgeable, you should be able to explain it. You didn‘t, tho. You used a lot of words, but said nothing. Why should your arrogant, but empty yapping do anything for me?
You can’t claim to be “semi-technical” while simultaneously refusing to look at technical facts and dismissing platform mechanics as “empty yapping.” How a browser engine executes extensions is inherently technical. Claiming you want facts while ignoring the architecture just means you’d rather stick with an emotional narrative than understand how the software actually works.
Chrome MV2 never supported some features people claim were lost: Features like in-flight response body rewriting and pre-socket IP filtering were Firefox-exclusive APIs (filterResponseData). Chrome MV2 never had them, so MV3 did not take them away.
webRequestBlocking is not dead in MV3. Google did not delete the synchronous blocking engine from Chromium. It requires installing via policy now. If an extension is provisioned via local policy, full programmatic webRequestBlocking runs in MV3 just as it did in MV2.
Everyday ad blocking works normally. For standard Web Store installs, uBlock Origin Lite compiles the standard filter lists (EasyList, EasyPrivacy, uBO filters) into native browser rules. Banners, trackers, and video ads are blocked.
The original claim was that “Chrome users don’t know what an ad-free web looks like.” That is provably false. If you want to understand the issue as a “semi-technical” user, you have to separate actual browser engine mechanics from internet hyperbole.