Just so I understand correctly: This version removes *all* of the features that read or modify a user's data, so as to abide by the ""stated intent"" of MV3, rather than taking full advantage of all of the actual MV3 APIs? For example, this commit removes the "scriplet injection" and cosmetic filtering features, which AFAIK work perfectly fine on MV3?
if broad "read/modify data" permission is to be used, than there is not much point for an MV3 version over MV2, just use the MV2 version if you want to benefit all the features which can't be implemented without broad "read/modify data" permission.
Huh? But ... the "read/modify data" permission isn't getting removed by MV3? I don't understand how this follows. This is like saying "Google implemented all of the same things we could do in MV2 in MV3, so we went ahead and removed all of the features anyway". I don't see any way to interpret this as anything except cutting off your own nose to spite the face of Google. It certainly doesn't seem to be a good faith attempt to reproduce the features of uBlock within the new technical framework of MV3.
Considering this is stated in ManifestV3's announcement and that no APIs have been made for it:
> Beginning in Manifest V3, we will disallow extensions from using remotely-hosted code. This will require that all code executed by the extension be present in the extension’s package uploaded to the webstore. Server communication (potentially changing extension behavior) will still be allowed. This will help us better review the extensions uploaded, and keep our users safe. We will leverage a minimum required CSP to help enforce this (though it will not be 100% unpreventable, and we will require policy and manual review enforcement as well).
Scriptlet injection is as good as dead.
> and cosmetic filtering features,
Cosmetic filtering can only happen by making a service worker, that will turn on five seconds after the page has loaded.
> the "read/modify data" permission isn't getting removed by MV3?
No, but Google will heavily restrict any extension using this permission, and make the requirements to be published on their extension store so draconian that an ad blocking extension (which directly threatens their business model) has no chance of ever being accepted.
So, no, Google, as usual when they implement a new API, does half assed shit, breaks compatibility, forces everyone to follow on their bad decisions before deprecating it later. Going all in on MV3 is just bringing yourself to the slaughter, and MV3 should be laughed off by any serious extension developer.
One interesting consequence of this is that Google's own javascript api client will no longer work with MV3 and there are apparently no plans to ever make it work.
So effectively this means extensions on MV3 can't easily access Google apis, which is quite unfortunate since Chrome extensions in particular made Google authentication super straightforward (piggybacking off of chrome's built-in google authentication). If someone knows a better way I'd love to hear it.
I believe the reason that the current incarnation of the javascript library won't work is because it modifies the dom to add script tags to fetch and run the api library (or components of it), which is specifically what MV3 will disallow AFAIK.
MV3 nukes pretty much every third party js in existence.
If the lack of a DOM doesn't do it, the extremely spartan service worker environment will take it out. Did they use XHR? SW only supports fetch. Did they use the window global? Don't have one of those either.
It's the stone ages right now. If you want to integrate with a third party in MV3 you are building a fetch wrapper around their raw HTTP API. Google thinks this is production ready
> Considering this is stated in ManifestV3's announcement and that no APIs have been made for it
I'll admit—when I first made this comment, I assumed (based on the initial manifest v3 draft) that this change only affected privileged context execution, and did not affect execution in the "main world", outside of privileged extension contexts. That said, APIs HAVE been made for it, and it would still be possible to do this using the dynamic addContentScript feature, even though I'd imagine it's a very low priority change to implement for the uBlock team (how many rules even use scriptlets?). But this is only a very small part of the features that Gorhill removed from the extension
> Cosmetic filtering can only happen by making a service worker, that will turn on five seconds after the page has loaded.
What? Content scripts still exist. Scriptlets may be harder to implement, but there's absolutely no reason cosmetic filtering should be.
> No, but Google will heavily restrict any extension using this permission, and make the requirements to be published on their extension store so draconian that an ad blocking extension (which directly threatens their business model) has no chance of ever being accepted.
Source? Have they said that they're going to do this to uBlock origin? They've said time and time again that making sure ad blocking extensions continue to work is one of their highest priority goals with MV3.
Also, the DNR changes absolutely do not make a meaningful impact on Google's business model—Google's ads are very, very easy to block, and you could do it with a one-line chrome extension. The vast majority of complexity in ad blockers is required for other ads that live outside of Google's ecosystem. If you really believed that Google was making their MV3 changes based on their business goals for their ads team (a pretty ludicrous idea when you think about how big Google is and how far separated the ads department and extensions teams are), then the inescapable conclusion is that Google should be supporting ad blockers themselves, to hurt the smaller companies that threaten their monopoly by trying to work around ad blockers.
"Source" he asks as the perpetually incompetent and straight up evil Chrome team deletes powerful APIs with no good replacement that just so happen to be the exact ones that blocks Google's extensive data collection and tracking.
Feel free to be in denial about why those crippled APIs have come to be.
See that's just completely wrong. Google Ads are trivial to block with declarativeNetRequest. They're as plain jane simple as it gets. If any ad company will benefit, it'll be the exotic ones that are more difficult to block.
> the "read/modify data" permission isn't getting removed by MV3?
The stated reason for the removal of the blocking webRequest API was to avoid broad permissions to read/modify data on all websites in the name of privacy/security.
What would be the point of still requiring those broad permissions while losing features and the ability to innovate on extension-side matching algorithms beyond what the declarativeNetRequest API allows?
The point is to show that if you respect the stated reasons for the declarativeNetRequest API deprecating the blocking webRequest API, that is what you get.
You seem to be confirming nightpool's comment. That this is an intentionally-limited release.
I think that's fine. It's good to have an adblocker that uses minimal permissions. But it seems like people will use this to argue that MV3 is less capable than it really is. Maybe UBO Plus (MV3) will come later that enables those feature.
I understand that, but it seems like the most frequently-used features (eg. cosmetic filtering) are possible in MV3. So a version with those features included would still offer value.
Correct me if I'm wrong, but it seems most of the missing capabilities are power user features - even by HN standards.
It's of course your discretion if that's something you wish to work on. I think a Minus and Plus version (or "Regular" if you prefer) offer a nice option for users to choose between. But I understand if the development overhead of managing two versions cannot be justified.
> What would be the point of still requiring those broad permissions while losing features and the ability to innovate on extension-side matching algorithms
The point would be to have those features, obviously? Cosmetic filtering is extremely important, there was never any possibility that MV3 was going to remove it, and you just removed it yourself for absolutely no reason.
I'm sorry, but if you're just removing features from your extension to make a "point" about "respecting stated reasons" then I don't think people should take what you say about it seriously. This might be an art project or a political protest, but people shouldn't confuse it for an actual attempt at extension development. You're taking a single reason that they gave, two years ago, and pretending like it should dictate every single thing you should do with your extension, out of some weird form of stubbornness and bloody-mindedness.
I clearly stated the reason: to avoid having to require broad "read/modify data on all websites" permission. I purposefully decided to create a permission-less version of uBO for people who would rather not grant broad "read/modify data on all websites".
> You're taking a single reason that they gave, two years ago
The current documentation regarding the purpose of declarativeNetRequest API deprecating the blocking webRequest API[1]:
> Using this declarative approach dramatically reduces the need for persistent host permissions.
My goal is to create a permission-less version of uBO and this is what I did. I am sure this could appeal to some people out there, as many over time have echoed that broad permissions to "read/modify data on all websites" is scary -- it's a recurring comment for those who support Chromium's deprecation of the blocking webRequest API in favor of the declarativeNetRequest API.
So this is a content blocker for those people. For those who can't live without cosmetic filtering and all the other goodies, there are other options out there.
I don't understand what you perceive this negatively.
I use cosmetic filtering a lot on Firefox Android. I routinely remove all the sticky-ish headers and footers from sites I visit often, because they are distracting, sometimes move, appear and disappear and uselessly take away space and distract me. Some popups too, even on Firefox desktop.
I'm sure that there are other extensions doing that (Stylish? but the element picker of uBlock origin is extremely quick to use) however Firefox allows only very few extensions to run on Android. They are moving to v3 too [1] so I'm worried that I'm going to lose that feature on my phone or that it's going to become so inconvenient to use that I won't hide annoying elements as much as I do (lazyness, other things to do, etc.)
I'm more than happy to give "read/modify data on all websites" permission to a trusted extension. I hope that you'll keep maintaining the current permission-full version of uBlock Origin too.
Does this mean that you're planning to migrate "regular" all-website-data uBO to MV3 at some point as well, with the caveat that some features won't work on Chrome?
Using this declarative approach dramatically reduces the need for persistent host permissions
Reduces != eliminate. Obviously, for some features, like adblockerblocker unblockers and cosmetic filtering, you still need persistent host permissions. Nobody has ever disputed that. The fact that DNR can remove persistent host permission for some ad blockers doesn't mean that it needs to remove them for all ad blockers. Also, you're taking that statement out of context: the documentation lists *three* separate reasons for DNR: privacy, performance, and compatibility with service workers. This reduces both the time it takes to process a network request (no need to serialize it to background page and then execute filter list matching in slow javascript) and the memory footprint of the browser (no need to keep an entire DOM background page loaded). It's clear that the performance goals here are at least as important as the security goals, if not more important, and they both go hand in hand.
I don't understand what you perceive this negatively.
By calling this the "MV3" version of uBlock, you're implying that MV3 has limited uBlock to these features and these features only, when nothing could be further form the truth. It's simply a form of misinformation to label this as the "MV3" version of uBlock. That's why I'm reacting to it negatively—it's hard not to see this as a continuation of your frustration with Chromium development team, and an attempt to paint MV3 in a bad light by purposefully releasing a crippled version of the extension. Users are going to see this extension, see that it's named "MV3", and then blame Google for the lack of features. It's just the same as lying to your users.
I initially punished a comment disagreeing with you, but after thinking about it more, I agree. Google's clearly signalled that they don't want Adblockers to use "read/write data on all websites"; just like Apple did, Chrome's whole idea with Manifest v3 was to make that go away. Frankly, with the genuinely malicious extensions people keep installing, probably for the best. Furthermore having uBlock Origin "continue to behave as normal" will confuse users and make them think uBO is still blocking everything users expect it to (i.e. tracking), which can surely endanger some users.
Google's clearly signalled that they don't want Adblockers to use "read/write data on all websites"
Where have they "clearly signaled this"? Gorhil even disproves this in his own comment: he links to an ad blocker in the Chrome webstore that uses MV3 and has been approved, even though it uses the "Read/write data on all websites" permission.
> To give users greater visibility and control over how extensions use and share their data, we’re moving to an extensions model that makes more permissions optional and allows users to withhold sensitive permissions at install time. Long-term, extension developers should expect users to opt in or out of permissions at any time.
> For extensions that currently require passive access to web activity, we’re introducing and continuing to iterate on new functionality that allows developers to deliver these use cases while preserving user privacy. For example, our new declarativeNetRequest API is designed to be a privacy-preserving method for extensions to block network requests without needing access to sensitive data.
> The declarativeNetRequest API is an example of how Chrome is working to enable extensions, including ad blockers, to continue delivering their core functionality without requiring the extension to have access to potentially sensitive user data. This will allow many of the powerful extensions in our ecosystem to continue to provide a seamless user experience while still respecting user privacy.
Basically, Chrome is hoping to use the same psychological effect as Apple's "Ad Tracking Transparency" (the opt-in screen for cross-app tracking) to make people opt-in for "read/write data on all sites" permission, to try to transition the amount of adblockers with that permission from 100% (currently) to ~20% (the amount of people who opt-in to tracking on iOS) by scaring users about extension permissions.
Unsourced comments that cite unsourced comments... this is exactly how FUD spreads.
I agree that it's clear that Google wants to reduce the amount of extensions that users opt in to having access to their entire web browsing data. I don't think that's a psychological trick: I think it's very clear that most users don't understand that every single extension they install might have these permissions, and instead just click past the generic permissions dialogue that Google shows.
I don't think that that translates to "Google's clearly signalled that they don't want Adblockers to use "read/write data on all websites"". What Google has clearly signaled is that they want users to be able to opt in to using this permission for the extensions that are most important to them, and that they want extensions to gracefully degrade when those permissions are not available. For most users, that's going to be ad blockers: basic features work without full site access, and advanced features are available with more site access. That seems like a good thing to me, not a reason to rip those advanced features out all together.
You are conflating a "present/absent" question of this permission with Google's stated intent. The key modifier here is broad "read/modify data" permission. If an extension attempts to assert that permission across a user's entire traffic, the extension will not be permitted in the store. Google's been very clear on this and it's already caused problems for other extensions.
Furthmore the webRequest API has been nerfed to the point that it cannot block requests any more, only track them. The replacement declarativeNetRequest API is not flexible enough to serve uBlock Origin's needs.
> If an extension attempts to assert that permission across a user's entire traffic, the extension will not be permitted in the store. Google's been very clear on this and it's already caused problems for other extensions.
Do you have a source for this? Have other ad blocking extensions been removed from the store? I find it very hard to believe that Google would block uBlock over something so clearly and obviously required for its functioning when they've said over and over again that making sure ad blocking extensions continue to work is a high priority for them.
> The replacement declarativeNetRequest API is not flexible enough to serve uBlock Origin's needs.
Well, the stats from the commit in question clearly disagree with you—of 22,245 rules, only 145 use unsupported regexes. How is DNR "not flexible" enough here?
I can't provide a source for Google axing a too-invasive extension, because they've never been straightforward about it. My favorite excuse was that the extension's description was "too detailed."
DNR does not allow uBO's _Block media elements larger than [x] KB_[1].
DNR does not allow to know which network request was blocked by what rule. To do so requires the `declarativeNetRequestFeedback` permission, which is available only on locally unpacked extensions, for debugging purpose. This prevents porting to MV3 uBO's overview panel[2], including the "advanced user" version to set firewall-like rules[3], and uBO's logger[4].
Furthermore, the filter-matching algorithm of DNR does not match the filter-matching algorithm of uBO regarding redirection. In uBO, redirect filters do not compete with block filters, they are looked-up after a network request has been blocked. With DNR, redirect rules competes with block rules, such that uBO's `redirect-rule=` filters can't be ported.
I do think there's a bit of sour grapes. You can only use the MV2 version until January. After that the main point to using the MV3 extension will be that it exists.
I sort of like the idea of UBO Minus, regardless of whether they do a full MV3 version of UBO later. It's more private than UBO could ever be. If it's enough, it's actually quite a nice extension.
Methinks a competitor ad blocker leaning into MV3 and claiming the 'first MV3 ad blocker' title last week was a glass of cold water for UBO devs. MV3 is happening, and usershare is at risk.
But, in addition to all that, I also think the main objective of MV3 is to hamstring ad blockers. Very very elegantly hamstring ad blockers.
My impression from way back in the uMatrix days was that marketshare is not a concern for gorhill and that the u* family are a labor of love to improve the internet for everyone.
A dilemma as old as art, isn't it? Will you stay true to your most profound convictions, even if it consigns your work to obscurity? Or will you compromise, gaining more attention and influence, but for a lesser artifact?
We wouldn't be having this conversation if uBlock was a Firefox-only extension. It would have no momentum and no traction, barely any feedback, and nobody would care what gorhill had to say about improving the internet.
I do keep using uMatrix. Its matrix UI is a nearly perfect. I also use uBlock Origin and I can't understand how to achieve the same results with the mini-matrix in its UI. ++ -- ??? It lacks the columns that explain what you're blocking or allowing. I read the documentation more than once and I still don't understand how to use it. Maybe I lack the incentive because uMatrix still works and it's so much better at that.
Agreed, what takes seconds now (click square or row, click to reload, repeat until it works well enough) would be going to take minutes, possibly large fractions of an hour. A two orders of magnitude change for the worse means that it's unusable. It's not life and death, where one adapts no matter what.
>click square or row, click to reload, repeat until it works well enough
Don't guess. uBO comes with a dashboard just like uM did that shows you exactly what's being blocked. It's usually very obvious what important script is being blocked whose domain you need to allow, what PUA symbols font is being blocked, etc.
>take minutes, possibly large fractions of an hour
Switching to the other window where you have the uBO list open and copy-pasting a line takes about as long as clicking the uM browser button, eyeballing the table and finding the right cell to click.
Your initial setup is going to take long. After that you'll a) get better at it, and b) you won't need to update it as often. I started doing this two years ago and these days I edit less than 2 lines per month on average. My list has rules for ~80 domains and is ~400 lines long, not counting whitespace and comments.
In any case, I'm not trying to convince you. I keep seeing people thinking that uBO can't do things that uM can, so I post that link to let them know that it can do those things except for cookies. Whether you want to use that info, or you think it's not worth it and you want to keep using uM, is something you decide for yourself.
My point is that the uM UI is obvious and I never understood how the uBO overview works. This should be telling something about UX design (or the amount of time that people can put into these projects, after all they have a life like everybody else.)
Today I learned that the GUI is read only and I have to write rules by hand. I'm a fan of command line and textual configuration files, except the few cases where a complex configuration GUI is quicker to use. uM is a great example of such cases.
> Your initial setup is going to take long
So I'll postpone it to when uM won't work anymore :-)
But actually reading again the guide at https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-qu... it seems that it can be done with a mouse. It didn't work for me because of ctrl ctrl doesn't work (I'm resisting fingerprinting on Firefox) and filterAuthorMode was False.
I think I can create allow rules with a mouse now. Unfortunately it seems that they allow everything from that site. For granular control I'm back to writing rules.
By the way, it seems that the ++ and -- in the overview are a kind of histogram. The numbers as in uM are much more informative and they won't puzzle people like me. I thought they were targets for clicking or to allow / block the site. We're back to my initial assessment of the two UXes.
Anyway, both uBO and uM are really useful so I won't complain too much. I'll keep using uM as long as it works because it's easier to use. I'll switch to that functionality of uBo when there won't be other alternatives. I remember that I switched to uM from NoScript because of some changes there. I couldn't do anymore what I was used to do. I read years ago that maybe they fixed that, so I could check how it works but not now.
I was already using uBo for adblocking and content filtering.
> I started doing this two years ago and these days I edit less than 2 lines per month on average.
I visit more new domains that need adjustment per week than you apparently do per month. That’s what I meant, it’s probably okay if you rarely need it. The issues start if you frequently do.
I also often experiment which blocked domain is making issues, sometimes requiring 4-5 rounds till I have it set up the way I want it to.
Yeah, it depends on your browsing habits. The domains in my list are the ones I visit reguarly.
For one-offs like HN submissions or search results or whatever, I either deal with the default level of broken-ness of the site, or I use a different browser that has a less strict uBO ruleset and is configured to delete cache, history, etc on exit.
Google is an ad company. The logical strategy is embrace extend extinguish ad blocking. If your extension is getting attacked and stripped of functionality minimal investment in keeping it working likely to continue to work the longest is logical
Many people have responded to this argument across many different threads, but just to reiterate: this is just the exact opposite of true. Google's ads are very, very easy to block, and you could do it with a one-line chrome extension. The vast majority of complexity in ad blockers is required for other ads that live outside of Google's ecosystem. If you really believed that Google was making their MV3 changes based on their business goals for their ads team (a pretty ludicrous idea when you think about how big Google is and how far separated the ads department and extensions teams are), then the inescapable conclusion is that Google should be supporting ad blockers themselves, to hurt the smaller companies that threaten their monopoly by trying to work around ad blockers.
MV3 has zero privacy benefits as it doesn't stop the same extensions from snooping but it does force substantial limitations like not having a separate list separated from the extension itself and an artificial limitation on the size of its blocklist. It is not expected that mv3 immediately destroys all ad blocking but if you look at the fact that google already makes such impossible on mobile you can surmise that it is a likely step towards eliminating all adblocking in the future. Especially since they have so obviously lied to everyone about the motivation for the change.
The end game is adblocking that blocks "unacceptable" ads in the name of protecting you from content that is offensive, adult, malware, or experience destroyingly bad while allowing in offensive google ads. In the name of not getting sued select partners will be allowed to prove they apply the same standards and will be allowed to access your eyeballs.
Feel free to revisit this in 3-5 years when I'm obviously right.
Implementing what amounts to ad blocking in your browser which all extensions must necessarily be mere lists of what to block rather than complex programs that examine and modify data IS the embrace.
Extending it would involve either implementing acceptable ads functionality that was optional.
Extinguish is making it mandatory in order to be listed on the chrome web store and allowing the browser to transmit some certification that it doesn't have an extension installed that would modify data in transit to ensure "security" making it hard to use the modern web with a browser that didn't transmit such.
Locally installing extensions is only for development so that any such modification will effectively break such a seal and make it impossible for you to view $SOME_RANDOM_GOOGLE_ADS_USING_SITE which will complain your browser is insecure and refuse to work kind of like sites presently block adblockers but with browser support making it much harder to avoid.
Maybe I am missing something here. But google is a well-known pull-the-rug-from-under-you type company, with a long proven track record of doing just that. Don't use undocumented, not officially supported anything from them. ever. Don't use apis that go against their stated goals. They WILL remove them. Unless MV3 has officially committed to a changed changed scope to allow this, it is irrelevant if it incidentally works.
I'm talking about features that the Chrome team has explicitly said time and time again will continue to work, like content scripts and user styles (cosmetic filters), and which MV3 never threatened in the first place. It would be ludicrous to consider these "undocumented". It's hard for me to see any other reason for gorhill to remove these features from the MV3 version of the extension except out of some perverse inclination to twist around the meaning of the Chrome team's words to support the conclusion that he obviously wants to find (that Chrome is trying to kill ad-blockers)—when in fact the *stated goals* of the extension team have always been the exact opposite (to provide APIs and extension points that allow ad blockers to continue to work)
