uBlock Origin Minus: an experimental Manifest v3 compatible extension – Ghacks
Raymond Hill, the creator of the popular content blocker uBlock Origin, has published the experimental extension uBO Minus for Chromium-based browsers.
The experimental extension is based on Google’s Manifest V3 for extensions, which changes things significantly for extensions such as uBlock Origin.
From January 2023 on, Google will block extensions that rely on Manifest V2 in Chrome. There is an Enterprise-policy that extends the cut-off date to June 2023. From June 2023 onward, Manifest V2 extensions are no longer supported. Installed extensions will not run anymore and new extensions can’t be installed at all in Chrome anymore.
Google claims that Manifest V3 improves privacy by removing capabilities from extensions. Rogue extensions may use the capabilities to spy on users. A side-effect, or so it seems, is that privacy and content blocking extensions may run with limited functionality only. Google, earning most of its revenue from advertising, may benefit from this.
The experimental extension uBOMinus is compatible with Manifest V3. The minus indicates that it is not as powerful as uBlock Origin. Hill reveals that uBO Minus uses the declarativeNetRequest API exclusively, which Google introduced in Manifest V3 to replace more powerful APIs of Manifest V3.
The extension does not require any extra permissions, including the “read and change all your data on all websites” permission. The consequence of this is that certain features are not supported by it. Hill lists cosmetic filtering, scriplet injections, CSP, redirect and removeparam filters specifically.
The Chrome extension uBO Minus uses the same default filter set as uBlock Origin, but in optimized form to take into account the limitations of Manifest V3.
Chrome users who want to give uBO Minus a try may download and install it from the Chrome Web Store. New versions of uBO Minus will be released alongside the regular uBlock Origin extension for Chromium-based browsers and Firefox.
The extension has a simple interface, which highlights the number of blocked items only.
Closing Words
Chrome users who rely on content blockers may encounter major issues from January 2023 on. Some may want to check out other browsers, either those with built-in content blockers, such as Brave, Vivaldi or Opera, or Firefox, which will continue to support uBlock Origin fully.
Browsers based on Chromium face additional problems once the change lands. While it is in theory possible to alter the code to continue support for Manifest V2, or at least some of the available APIs, browser makers would have to launch their own extension repositories as the Chrome Web Store won’t host any Manifest V2 extensions anymore after January 2023.
UBO Minus is the second extension for Chromium-based browsers that relies on Manifest V3 exclusively. AdGuard released AdGuard AdBlocker MV3 recently, which does as well.
Content blocking will be different when Manifest V2 support is dropped. Some users may not notice a difference, if they rely on basic filtering only. Those who subscribe to more filter lists or use multiple privacy extensions that do filter requests, may run into the artificial limitation.
Many Chrome users are probably unaware of the announced changes at this point. Those who know about it, may want to check out other browsers that won’t be affected by the change.
Now You: what is your take on this?
In the case of Brave, do we even need uBO anymore? As an experiment I disabled uBO in Brave but have not seen/experienced a difference: ads are still blocked and page loading is more or less equal.
I haven’t used uBlock with Brave. If you set tracker and ad blocking to “aggressive”, then you should be fine. I use the noscript extension with it, because I like to control what javascript is allowed to run in the browser. Otherwise, Brave seems to have all you would need built in.
“do we even need uBO anymore?”
No. Only improved page element picking.
What we do need though, is an independent extension store, where Google’s hammer and sickle can’t reach.
Many websites have big or small breaks with the Brave Filters, I use:
– Brave Filters aggressive
– uBlock Origin
– Privacy Badger
– Decentraleyes
– additional filter lists for Brave in about:adblock
On some webpages I have to completely turn Brave Filters off, because they don’t work, if I did not have uBlock Origin, I’d have to deal with the ads there.
Brave alone is not enough to block everything, especially on Android where you can’t install extensions. There the king is still Kiwi Browser.
@Klaas Vaak
> In the case of Brave, do we even need uBO anymore?
No. Brave uses the same default lists as uBlock Origin:
https://github.com/brave/adblock-resources/blob/master/filter_lists/default.json
…and you can add your own lists on brave://settings/shields/filters . Set the filtering to aggressive and you should be good. Brave’s internal adblocker, since it is not an extension, will not be affected by Manifest V3. But uBO, as an extension, will be, and will be more impotent than it was going forward.
@Allwynd
> Decentraleyes
This has outdated CDN libraries, it is more or less abandonware now. There is a fork called LocalCDN of which the development is much more active:
https://chrome.google.com/webstore/detail/localcdn/njdfdhgcmkocbgbhcioffdbicglldapd
Just so you know.
> Privacy Badger
Both Brave’s internal adblocker and uBlock Origin should make this extension redundant.
@Iron Heart: good talking to you again 😉
> you can add your own lists on brave://settings/shields/filters
Yes, I noticed that but don’t know how to add them, that is to say, where to get the URLs from. I tried 2 but Brave said “download failed”, so I gave up.
In any case, they way I have it configured (see my reply to Anonymous) keep the ads away.
Concerning Decentraleyes and LocalCDN.
Alas, with LocalCDN in https://allestoringen.nl/ there are no info-graphs displayed. And that is pretty essential info.
With Decentraleyes everything goes OK.
@Anonymous
> With Decentraleyes everything goes OK.
Decentraleyes does not fulfill its basic function anymore, satisfactorily anyway: To replace remote CDN libraries with local copies of the same.
Decentraleyes’ libraries are outdated, this can really no longer be recommended. I see why the bug you describe could bother you though, perhaps it is a good idea to report it at the repository, so that the developer can take a look at it: https://codeberg.org/nobody/LocalCDN/issues
There is the answer from Brendan Eich: https://github.com/uBlockOrigin/uAssets/discussions/14544#discussioncomment-3490321
>uBO does more by default, and has more knobs for its users, than Brave shields has or will likely ever have….
@gwarser
> There is the answer from Brendan Eich
In the comment you linked to, he also says that they are committed to keep uBlock Origin (and uMatrix) going. You’ve knowingly omitted this, buddy. It’s an extraordinary commitment on their part because Brave users are not really in need of uBO, as the browser already ships with a capable adblocker.
@Iron Heart, Brendan Eich also said supporting Mv2 is not something they feel like doing because of how much work it will take to support it. They could technically do it, but since they are also an ad company, I very much doubt it.
> imagine using brave LMFAO
Ah yes, this already gives me the impression that I am about to read something that is both fair and well-researched. /s
> Brendan Eich also said supporting Mv2 is not something they feel like doing because of how much work it will take to support it.
We shall see. Until mid-2023 the webRequest API will just be behind an enterprise flag which they can just activate. After that, who knows. Supporting an API is not that hard to do and Google would also have to go out of their way to break code that they no longer care about (since it is gone in their version of the code).
Anyway, IMHO Eich is mistaken in trying to keep support for the WebRequest API (which is a security issue). I would just try to find the 300K rules hard limit of the new declarativeNetRequest API in the code, and lift that limit. But hey, that’s just me.
> ad company
Brave blocks all online ads without compromise. They make money via privacy-preserving local ad matching technology that they’ve come up with in an effort to create an alternative to Google’s spying business model. While Brave can technically serve ads, it is fully opt-in and not privacy-invasive. They make surplus with that? Good for them, they are fighting the problem at the root.
PS: Mozilla receives the vast majority of their annual income from Google… How is that not ad money? Wake me up when they actually throw their weight behind uBO by including it in the default installation (similar to what Brave does), in opposition to Google’s wishes. Until then, ciao.
@Klaas Vaak
I would say yes and no.
Brave adblocker is good, since last time I tested it it seems they finally let you use all the supported features in Custom filters, which will improve things. But Brave is still far from perfect, that’s why uBlock is needed.
Resources and syntaxes and all, are uBlock based, Brave even forks uBlock.
Also, Brave is still missing few little features uBlock supports, I am talking about $popup for example, which is important, but also it needs to be supported because if a filter has $popup it gets completely ignored so you don’t get to even block like the domain or something like Adguard MV3 does (Adguard MV3 seems to be missing that but blocks the domain).
There are also the procedural cosmetics but they are not important because cosmetics all they do is hide, they don’t block, which most people can’t seem to understand. But procedural cosmetics are nice to have and hopefully Brave will support them soon.
I actually use uBlock but disabled generic filters and most lists, just leaving uBlock in case something is not supported or not properly supported by Brave.
The thing is while Brave supports more scriplets from uBlock, like I tested most and they worked fine for the few tests I could get, sometimes it is really hard to find the perfect site to test them, and the testing pages ABP and uBlock and Brave has are not enough for every feature.
I actually tested Adguard MV3 and I realized how people really talk out of their butts, besides the Rules limit, Adguard supports most features Adguard MV2 does, it is still missing few ones but they even support the ones not even uBlock does because they are ABP only and then Adguard added support for them.
Compared to Vivaldi or Opera, Brave is like the best native adblocker for sure, Vivaldi or Opera don’t even let you write custom filters and they are really behind uBlock/ABP/Adguard in terms for features.
Because while many of the features are like not used everywhere, they are useful for many things.
for example aopw is the one I came up with first than anyone to stop this clipboard issue: https://www.ghacks.net/2022/08/27/websites-may-write-to-the-clipboard-in-chrome-without-user-permission/
I think vivaldi supports that, but not the other most advanced ones https://github.com/gorhill/uBlock/wiki/Resources-Library
And the list of ABP and Adguard is even greater and more advanced than that.
But anyway, it seems aopw wasn’t working as acustom filter in Brave recently but somehow now it does and I saw Brave adding it to their lists.
I tested most things even the $redirect, also recently Brave supported the $redirect-url and I think it works also in custom filters, I guess since everything else gets supported.
There was a point when I was told custom filters were different than internal lists, so that’s why custom filters couldn’t use all the features but now they do, then they are the best native adblocker, because it was already advanced but not having the ability for you to make your own rules is annoying.
Brave is faster and better than Extension API for sure, and Brave supports CNAME uncloaking making it the only Chromium browser to do that.
But Brave is where it is thanks to uBlock and Adguard and ABP and the big guys, I mean, MV3 won’t stop innovation like people think, but devs surely will need to find workarounds for many of the advanced features.
Brave adblocker is not perfect even if it supports the features though, sometimes it behaves not 100% like uBlock would, and there are some regex rules that fail because Brave doesn’t support regex 100% like uBlock I guess does.
But I mean, nothing Brave team won’t improve or fix eventually.
uBlock logger is amazing, and the element picker is really useful unlike Brave’s one which I disable with –disable-brave-extension. I usually use Devtools to create my cosmetic filters anyway, but uBlock makes it nice to test things.
So that’s why I say yes and no, until Brave doesn’t improve adblocker even more and brings the ‘cool’ and ‘normal’ features, then there will always be the need of Adguard or uBlock to fill the gap.
I think Adguard mv3 is great, but obviously missed some features and has the rules limits which might be a problem for some people who subscribe to every list in the world even if rules are duplicated or obsolete and useless. I am sure uBlock MV3 will always do well, so it is good gorhill finally bringing something to the table.
It is the future anyway, so that’s why it is good uBlock and Adguard and others exist so Brave can bring their innovations to the native adblocker.
But for now, Brave is still not 100% there, I would say like 90% there, then they can work on adding other stuff uBlock has but are really not used much just in really specific occasions like matches-css or xpath and stuff like that.
Also Brave still gets detected unlike uBlock, so I always disable shields and I still get stuff blocked because uBlock then does the job.
Brave will literally do 98% of the job anyway, even if some ignorant people say otherwise, and it is in rare moments where Brave will brake a page or something, sometimes it is not even the Adblocker that brakes anything but the fingerprinting protection or the 3p cookies being blocked (stored in the Ephemeral storage).
But I doubt people really know what they talk about, last time someone was saying how Adguard MV3 was better because it does procedural cosmetics and the person kept saying how Brave can’t ‘block’ promoted tweets, which is dumb since cosmetics just hide and don’t block anything, I would say procedurals are used rarely compared to the native browser css selectors, which always be recommended.
The best way would be for Google to stop being lazy and add at least :has or :has-text to chromium. but I guess it will always be the job of the adblockers to bring custom JS to do the job.
It’s getting there for 100% compatibility with uBlock filter list for sure but not there yet.
@Anonymous: wow, that’s quite a detailed reply. I have Brave Trackers and ad blocking set to standard, and that already seems to keep the ad noise out. I am afraid that if I set it to “aggressive” it’ll break too many sites.
I have not added any addtional filters, just added a check mark to a few in the native list.
I have also installed AdGuard MV3 (it is still experimental) to see how it goes.
Thanks for your input.
@Klaas Vaak
> I have Brave Trackers and ad blocking set to standard
You can safely set it to “aggressive” – the sole difference between “standard” and “aggressive” is that “standard” only blocks 3rd party ads and trackers, while “aggressive” also blocks 1st party ads and trackers in addition. “Aggressive” has nothing to do with “more aggressive against all JavaScript”, if this makes sense.
You’ve said above that you can’t add lists to Brave without getting a download error. I am getting my filter lists from here:
https://filterlists.com/
Click on the list you need –> blue square at the left –> then click “View” at the right side of the screen. This will lead you to the list’s URL, copy this URL and add it to Brave.
Also note my reply to @Anonymous below, I am discussing the Manifest V3 issue there, I think I am doing it fairly and from all possible angles.
Damn MV3! I can’t live online without uBO 🙁
I use Edge and Brave where I disable Shields and use uBO instead.
Internet becomes a crappy place without uBO 🙁
> uBlock Origin Minus
Good graces, the salt must be real with Raymond Hill… uBlock Origin Minus? Really? Surely this is meant to hint at the reduced capabilities, but the sheer saltiness of gorhill at Google’s decisions certainly didn’t escape me.
I think he will throw in his lot with Firefox, which will be the beginning of the end for his project. Not many people care about adblocking at all, some do and Manifest V3 could be good enough for them, and some want strong adblocking capabilities – the last group has other options outside of Firefox as well though, e.g. Brave. I don’t think Firefox will experience a high influx of users at the end of the day. If FF continues to decline, and uBO is FF-exclusive, that will also mean trouble for uBO. But this is the risk you run into as an extension developer, you are at the mercy of the browser developer and the capabilities given to you (which were not at all only used for good in case of the webRequest API really).
@Iron Heart
AFAIK mr Hill does not make money from ublock and does not accept donations. So, I guess he may continue or stop development at his own will, pretty much regardless of applicable browsers, market share or whatever. No lost money pressure – no problem.
@Iron Heart
well, he is obviously a pro-firefox person, seen by his “why ublock is better in firefox” thing, he never really supported Windows even if it is the biggest desktop OS, someone else has to upload the extension to Edge Extension store.
He is really idealist which I don’t care, I mean, it is fine for me.
I guess he just wishes he didn’t have to do this and go to MV3, Adguard supports almost all features in MV3 than MV2 so gorhill is just being negative because it is just few features that he might have trouble with.
Like logger, Adguard already talked how they will workaround to bring it back, but I am sure it is boring to have to re-do something that was already done and worked great.
But it is the future so he can’t do anything about it, Firefox supports MV3 so it is not like Adguard MV3 or this uBlock will be only for Chromium browsers. Only because Mozilla said they support Web Request API and added the “for now” or something, doesn’t mean they are willing to have it always, especially with all the money they get from Google.
I mean, they already got rid of their nice extensions in favor of webextensions because of Google.
So, Firefox will eventually remove web request API and then what? well, that means gorhill and everyone has to adapt or close the gates.
Adguard has shown how the biggest problem with MV3 will be the rules limit, not the features they can implement anyway. So I think gorhill is just being dramatic about the whole MV3, but understand he not wanting to do it and then having to re-implement stuff when he does it for free, unlike Adguard that has money to do this, must be annoying.
I wish he was a little flexible and would join Brave, making sure Brave pays him big bucks for his brain, he might not agree with Brave BAT business, maybe? I don’t even like it, but it is better than what Firefox does, Brave adblocker is heavily based on uBlock anyway but he would help to make it better for sure without google or mozilla affecting crap.
At least Brave is the only one that doesn’t have an ‘acceptance’ program for ads, which he has talked about, even Vivaldi does, kind of, because it is about the ‘partners’ which means search deals, ABP has it and Opera does too. Adguard doesn’t but they charge money for others products.
But yeah, I think he will be happy eventually being like Firefox only, which I don’t care because in some way I am sure MV3 has accelerated Brave’s adblocker development, so I hope in few more months Brave will get the features to be like 100% compatible with uBlock lists, and maybe procedural cosmetics too, I would like to see how they perform against uBlock for sure, you know Native vs API.
Right now Brave is faster for sure and uses tiny little less CPU. So I don’t care what he does as long as Brave can keep forking his work and adding it to Brave adblocker.
@Anonymous
I don’t think Raymond Hill will directly work for Brave at some point. Brave is a for-profit company* and Raymond Hill does not even accept user donations for his work on uBO. He seems to think that accepting money in any shape or form could “compromise” him, so I just don’t see him at Brave even though Brave Software is committed to adblocking – its for profit nature will prevent any kind of employer-employee relationship from happening. Anyway, currently Brave Software is working with @gorhill to try and see what can be done about Manifest V2 support:
https://old.reddit.com/r/uBlockOrigin/comments/x967w5/ubo_minus_mv3/inmq7bu/
*Note that I am not at all unhappy with their basic idea / business model – a privacy-respecting local ad matching mechanism that can serve as an alternative to Google’s business model that is based on the collection and analysis of user data on remote servers (which is what Brave is committed to block also). Adblockers, of whichever shape or form, be it Brave’s native adblocker, uBlock Origin, AdBlock Plus or what have you, are basically enabling freeloading, by taking income away from content creators. The obvious alternative here would be paywalls, but this is not something we would like to see, right? So there needs to be an alternative content creators can flock to, which is what Brave offers. They make money with that? Fine by me, they need to sustain the company after all.
Back to uBO: As I’ve already alluded to in a comment above, I think this is a mistaken approach. The webRequest API allows for all sorts of malicious activity. Despite the understandable cries of @gorhill, his extension is not THAT important when thousands upon thousands of malicious extensions use the very same API for stealing and selling user traffic data, or for directing users to malware-laden destinations. People should accept that taking this ability away is a very effective countermeasure and security improvement first and foremost. Of course you can always elusively state that “evil will find a way” (kinda reminds me of Jurassic Park), like @owl does, but identifying a browser vulnerability and writing an exploit for it is non-trivial, compared to just using an official extension API with its extensive documentation. Loopholes used by exploits are also subject to being immediately fixed by the browser developer of course, so not as attractive for malicious actors as extensions that might stay undetected for a while. I categorically don’t think you can explain away a security improvement by saying “malware will somehow find its way”, this is just as ridiculous as it sounds.
Now, of course there is a conflict of interest here that we cannot possibly ignore – Google makes money with its ad business primarily, so with change, while arguably being a security improvement, they are also neutering adblockers, which I believe was 100% intended by them as well. We also know that they won’t change course, so we need to think about how to react to it. Trying to patch the webRequest API back in could be a solution, but might be hard depending on how much Google breaks it in future updates. There is also the question of distribution, some browsers aiming to keep it don’t have their own extension store yet. Another way that would IMHO be preferable would be to lift the artificial hard rule limit of the declarativeNetRequest API, after all it should exist somewhere in the codebase, right? This should fix the biggest limitation – the number of rules a user can use.
A third possibility would be the creation of native adblockers, which is what all Chromium-based browsers aside from Chrome and Edge have done for a while now. Those could easily be as powerful as uBlock Origin given enough time. This would also move the important task of content blocking to the browser core, and remove one party to trust – the extension developer. While I do trust Raymond Hill (has had an impeccable track record so far), I do not need to look far to find parties I wouldn’t trust under any circumstances, e.g. the Eyeo GmbH and their AdBlock Plus extension, which uses a paid-for whitelists that allows some ads and trackers to go trough on purpose, in exchange for money.
While removing a party to trust is good in theory, it would also be desirable for multiple browsers to ship with built-in adblockers, so that competition will “keep things honest”, so to speak. Fully relying on Brave’s internal adblocker means fully relying on Brave Software by extension, and while I trust them as of now, competition would certainly be great to keep them committed.
One last and important point of criticism of the new declarativeNetRequest API is that moving the actual act of blocking from the extension to the browser – the extension now “hands” its rules to the browser, which does the blocking based on these rules – could enable browser-level censorship of rules. That means, if the adblocker has a rule to block Google Analytics, the extension can no longer directly enforce it – Google could overwrite this at the browser level and allow Google Analytics to run based on their own internal rules. While this is serious, we need to ask ourselves how such browser-level censorship of rules would get implemented? If (big IF) they do implement such a thing in Chromium directly, it would be easy for user-friendly Chromium-based browsers to remove this. If they create a closed source blackbox (which I hardly believe, it’s in violation of the open source licensing I believe), it too can be eliminated from the codebase. If something like this should happen, it would happen in Chrome most likely since Chrome is already closed source anyway. This, however, would mean that it is no longer the concern of other Chromium-based browsers (aside from Chrome itself of course).
I also believe you are right on the money re. Mozilla. They’ve said that they have no plans to ditch the webRequest API at this time, but when I hear phrases like “so far”, or “at this time”, or “as of now”, I get the feeling that such thing is temporary in nature. One big reason for the introduction of WebExtensions back in 2017 was to achieve 100% compatibility / parity with Chromium’s extension APIs, so that cross-browser extension development becomes easier. By leaving that path, Mozilla would put the original reasoning behind WebExtensions (and the benefits, i.e. more cross-browser extensions) into question. Not to mention that they are in close cooperation with Google and Apple in a standardization body for extension APIs, kinda of makes me question their commitment to “diverging” from what the other two are doing, you know. What you said about Mozilla’s financials are also true, they depend on Google’s ad money, and if Google threatens to withdraw funding from them in case they don’t comply, who knows what will happen then. Between Google’s millions and Raymond Hill, I am afraid Mozilla could very well give hill the end of the stick – which could be a bitter awakening for him after he goes all in on Firefox. Mozilla also has never been THAT committed to adblocking, if they had been, they would have shipped an adblocker like uBO by default, similar to what Brave does… but then, ad money, I guess. uBO being a third party extension limits its exposure to the user base because you have to specifically seek it out. Mozilla is now celebrated as the savior of adblocking, I say let’s wait and see. The meltdown will be epic should they actually go the same direction, which there absolutely is a non-zero chance of.
All in all, I am following these developments somewhat relaxed, because whatever happens to uBO, internal adblockers will continue to work and I consider Brave’s adblocker to be fairly close to the quality of uBO. I also try to give a fair and balanced(!) view of the situation here, weighing the advantages and disadvantages of these changes, and trying to discuss possible reactions to them. I am sure I will be accused of “defending Google” or “promoting Google” for saying that the change is not all bad, from a security perspective at least, but this is whatever to me. I hope people trying to understand these changes find my posts informative after all.
Ghacks Article
> From January 2023 on, Google will block extensions that rely on Manifest V2 in Chrome. There is an Enterprise-policy that extends the cut-off date to June 2023. From June 2023 onward, Manifest V2 extensions are no longer supported. Installed extensions will not run anymore and new extensions can’t be installed at all in Chrome anymore.
In fact, the application of “V2” has made many popular browser extensions (e.g., Text Legibility, and many others) unusable (or forcibly removed, even if users are still using them) on Chromium.
Even if it is a countermeasure against “malicious intent,”
FOSS (free and open-source software), and other individual developers and small businesses must bear new extra costs and troublesome work, etc., in conforming to “V3” compatibility (creating a dilemma that must be borne by those without malicious intent).
Because (Malicious intent is cunning, and workarounds are destined to be devised), many developers of free apps are hesitant to respond to “V3,” which is practically meaningless (Abandon, or Make it shareware, specialize in AMO, etc.).
If users are using browser extensions, whether they are compatible with “V3” will be an issue for many in terms of user experience, usability, and eventually “user rights”.
The mission of a “corporation” is to return profits to shareholders, and corporate value (business volume and profitability, growth potential) is its lifeblood.
Microsoft and Google are thoroughly “Re-Structuring” to increase profitability and are replacing (human) with machines.
Due to this relationship, the review of applications is not manually checked by humans, but by AI.
In the past, “unfair apps” were rampant, and as a countermeasure, (promoting mechanization) Microsoft and Google established the Extension Manifesto v2 (at the time, they bragged about a perfect API, but it was cruelly tossed aside by malicious intent), and V3 will inevitably suffer the same fate. Because malice is cunning, and “proverb: Evil never dies” then “proverb: Honesty makes fools of us all.
Extensions should be reviewed manually by humans, and Microsoft and Google have ample capital to do so, which is their natural responsibility.
It is the servant-like Google’s gofer who espouses the corporate “V3” opportunism.
@owl
> Extensions should be reviewed manually by humans, and Microsoft and Google have ample capital to do so, which is their natural responsibility.
You can’t “review” all Chromium extensions, because the Chrome Web Store or Edge Store are not the only source for them. You can install CRX files or unpacked ZIPs from third party sources as well! And just like that, your argument bursts into a thousand bubbles, unless you want an Apple-style system where you can only get your “apps” (extensions in this case) from one source – the store. Sounds very unhealthy to me.
> read and change all your data on all websites” permission
…is a security issue waiting to be fixed. The declarativeNetRequest API, minus the artificial rule limit obviously, is the saner way to do it. Why should extensions be able to directly monitor and redirect connections? This is a door wide open for all sorts of malicious activity.
“The extension does not require any extra permissions, including the “read and change all your data on all websites” permission. The consequence of this is that certain features are not supported by it. Hill lists cosmetic filtering, scriplet injections, CSP, redirect and removeparam filters specifically.”
Is this a self-inflicted restriction by the uBlock Origin developer? If so, I don’t understand why he would cripple his own extension. As far as I’m aware, the Manifest V3 version of the AdGuard browser extension doesn’t do this.
The CEO of Brave appears to imply that Brave may continue to support uBlock Origin and uMatrix for their users through the Brave “component updater”. Although, I think for Brave users, long-term they will likely just use the native content blocker built-into Brave – so an extension won’t be required.
https://news.ycombinator.com/item?id=32650154
“…You mean MV2. I’ve said we’ll keep support uBO and uMatrix uses of it, at least. This means we’d have support from the maintainers for their builds to produce extensions we can add to our component updater as optional for our users. We are discussing this now with uBO/uM maintainers.”
I appreciate Raymond Hill making the effort to create a manifest v3 version. As of right now, it falls short of the Globemallow and AdGuards manifest v3 extensions in reliability. Pages load more slowly and a surge of advertising appears. I’m hoping he’ll figure it out and Google will remove these nonsensical manifest v3 limitations in the next few months.
@IgnoredFeedback
“Google will remove these nonsensical manifest v3 limitations in the next few months.”
I’m sure an ad company will do that
You thought Google one of the most advanced Big Tech company would aim to give people and developers more freedom with their advanced technology. Instead this Manifest v3 going backward and placing more restriction, with some excuses of more privacy-effective. Since when they care about privacy? Google only care about get to know you more so as to better serve you, definitely want to know everything about you.
Put it simple:
More freedom without jeopardizing security = improvement or progression
More restriction on advanced new tech = regression with excuses
Since when the old Manifest v2 run into security concern with more freedom? Nothing is proven to be a concern.
Placing more restriction with the new tech API manifest v3 to give you more security. Since when the users of internet really care about “more security”?
Google really think anyone is stupid enough to buy into their regression going backward new tech Manifest v3.
These are very smart people in Google, very cunning and manipulative as well. Smart and manipulative always go hand-in-hand, as smart people always like to play mind game and “manifest” their mind game into reality, and they are rich and powerful enough to do so. Very egoistic. There is nothing normal people can do about this. You can only be aware of this.
They have 65% of world market share with Chrome. Most of these 65% users don’t even care. Remind me of the movie Experimenter 2015. Most people just worship and obey authority big tech like Google without knowing it.
Hows about Edge? Perhaps it can continue to support v2, because it have its own extension page.
Please click on the following link to open the newsletter signup page: Ghacks Newsletter Sign up
Ghacks is a technology news blog that was founded in 2005 by Martin Brinkmann. It has since then become one of the most popular tech news sites on the Internet with five authors and regular contributions from freelance writers.