Has anyone been using the v3 compatible version of uBlock Origin? Have you noticed much of a difference? From what I read there isn't supposed to be much of a difference?
replies(8):
There's no difference whatsoever.
And it's not surprising because on my iOS device I've been using similarly architected content blockers since 2015. There's no issue with declarative ad blocking.
Of course this differs with the kind of sites you visit. So you need to try it on your own. I can believe that perhaps for some people this is a downgrade, but don't automatically assume uBlock Origin Lite won't work well for you.
Also, keep in mind advertisers are not unaware of all this movement. You don't think they'll try new tactics once they know everyone using chrome is now hobbled to solely static lists? That cloaking (or other approaches) won't then become really popular?
[1] https://adguard.com/en/blog/adguard-browser-extension-mv3-re...
That's going away now. Now mostly everyone is vulnerable with the only recourse being pretty technical stuff, not just downloading a very popular plugin.
So advertisers will now be free to get more aggressive without much downside.
Edit: I do get that this sounds like conspiracy theory. But it really matches the Google boiling frogs approach. Removing the blocking onBeforeRequest, as one of the very first things in the manifest v3 spec was not a coincidence.
iOS I'll give you, but macOS can in fact run ex. Firefox.
> finally matching the security and the privacy in that regard.
"Matching" inferior security+privacy is not a good thing. The only way this is an improvement if you think the blockers are malicious; otherwise a useful tool in the users interest has been made less powerful.
MV3 has a measly 30000 static rule limit. These rules are included with the extension and cannot be updated dynamically. And a 5000 dynamic rules limit. [2]
EDIT: Chrome now has a 300000 shared pool for static rules for extensions that go over their 30000 limit. And a 30000 dynamic rule limit [3].
[1] https://adguard.com/en/blog/adguard-for-safari-1-11.html
[2] https://adguard.com/en/blog/adguard-mv3-beta.html
[3] https://developer.chrome.com/docs/extensions/develop/concept...
Really?
Because I find adblockers on iOS are nowhere near as good - they let far more ads through, and they leave far more sites broken so I have to disable the ad blocker for the site to work.
"Based on input from the extension community, we also increased the number of rulesets for declarativeNetRequest, allowing extensions to bundle up to 330,000 static rules and dynamically add a further 30,000." https://blog.chromium.org/2024/05/manifest-v2-phase-out-begi....
Still sucks that the rules are static though. AdGuard devised a method to diff ruleset changes with the built in rules to generate dynamic rules between extension updates. So, I guess it works.
[1] https://developer.chrome.com/docs/extensions/develop/concept...
https://helpcenter.getadblock.com/hc/en-us/articles/97384768...
https://www.wired.com/story/fake-chrome-extensions-malware/
This has been never ending.
Extensions and in turn MV2 blockers can easily be malicious.
https://usa.kaspersky.com/blog/dangerous-chrome-extensions-8...
Look at how many in Kaspersky’s list are advertised as ad blockers. The majority of users aren’t tech savvy like HN.
Twitter and YouTube ads are blocked.
The drawback? It isn’t free.
By my count 5, 6 if we include "Autoskip for Youtube", out of 34. That might be an argument for dropping extensions, but I don't think it's an argument for breaking ad blockers.
> I do get that this sounds like conspiracy theory.
> … was not a coincidence.
Could it be that it was coincidence? Do you have a solution for reducing extension malware without removing onBeforeRequest?
The Firefox version of uBlock Origin Lite was pulled due to unsatisfactory audit process: https://news.ycombinator.com/item?id=41707418
Those extensions used the same API that ad blockers used, but for malicious purposes.
So, you would support removing that API? Well, that’s what they did for MV3 and implemented an API just for ad blocking.
Yet you can still inject js right into the page. You just can't stop a page that was going to load from loading. They could have taken away the onBeforeRequest redirect capability and left just the onBeforeRequest cancel capability.
Not sure I've heard of any spyware/malware depending on just that cancel capability.
Besides, webRequest implementation in Chromium is a terrible collection of hacks on hacks. It is a good example how not to design or implement API. I will not be surprised if the removal of the API comes from a simple desire to remove that embarrassing code.
https://developer.chrome.com/blog/crx-scripting-api#breaking...
https://news.ycombinator.com/item?id=41812416
If you are really privacy conscientious, ad blocking extensions should be able to exist without any access to web requests now.
The main thing I missed was the ability to block arbitrary elements with the zapper. I use this for more than just ads, so losing it is a real loss in functionality. Otherwise it worked fine.
Removing the onBeforeRequest redirect didn't add much security either, since you can just ask for permission B instead of permission A and just inject code. Though, ad blockers don't need that anyway.
It’s insane to want extensions to snoop on all your requests in an attempt at more privacy.
It is a permission that could be used by a malicious extension to snoop, but that is far from the only use. Wanting the permission != wanting snooping.
So make one that isn't incompetent? That's not really a counterargument to the general idea.
Sounds like an obvious chance to flag the extension for further review, and probably a warning on the user side.
> So, you would support removing that API?
Of course not; that's throwing out the baby with the bath water. This brings us back to the "further review" thing; there's plenty of precedent for a platform having API surface that only a smaller subset of apps/extensions are allowed to use, because the features it exposes are legitimately needed for some things but it could be abused so it gets flagged and you have to write a detailed explanation for why your thing really needs this permission and then the reviewers can look at it particularly closely.
> Well, that’s what they did for MV3 and implemented an API just for ad blocking.
And then for bonus points they hobbled it so that it couldn't be used to make as good of ad blockers, which is why the whole thing is not okay.
Never leaving your subscriptions (never using the algorithm recommended feed) is not a solution because of second-hand toxicity, e.g. political posts in meme subreddits in an election year.
If anyone knows of a solution that works in Manifest V3 I'd love to hear it!
Browsers are selected by users, they should have no obligation to show ads.
Brave is the only one doing this right AFAIK.
Almost all the problems with tracking and buying and selling user profiles would end if browsers just didn't show ads.
AdGuard AdBlocker (MV3 Beta): https://chromewebstore.google.com/detail/adguard-adblocker-m...
Copy and pasting the ublock custom filters into AdGuard seems to work.