I see plenty of folks in here lamenting this release at all - in the hopes that the lack of it will push folks to Firefox. It won't. Those who care about this are already on Firefox, and frankly - Firefox isn't going to be the answer here (to be clear, this is opinion).
I'm also not thrilled at manifest v3, although for very different reasons than the adblocking limitations - I do lots of extension development, and I think the service worker approach taken is a bad mistake, forcing a distributed consensus model onto extensions without understanding the limitations that model imposes given how often extensions span multiple js contexts (across tabs/frames/content_scripts/windows/etc).
Frankly - the environment is also still riddled with bugs... everything from docs that are wrong, to serious issues like a service worker not activating on simple, basic, required events (like chrome.action.onClicked, which is literally about as basic as it gets for extensions).
Overall - my first impression of the manifest v3 upgrade was fairly neutral (it's not really solving any of my pain points, and it requires a lot of changes to support - but it seemed functional). My opinion after porting several large extension projects to the space is... bad. It's a bad set of changes as implemented in chromium right now.
I was fully in the Google world prior to gorhill's posts on manifest v3
as a direct result the only thing I have left is a pixel phone, which will be going with the new iPhone
(and in the meantime my entire family has been 'helpfully' migrated too)
I may be up the extreme end of the distribution, but this sort of grassroots push is what dethroned IE, and the resultant loss of control of the web eliminated Microsoft's near total influence over the computing industry
Not to burst your bubble but if you are leaving the Android ecosystem because of Chrome manifest v3 I definitely urge you to see what you're getting yourself into. Not only does Apple enforce that you use their browser engine, it also abuses this position to disable features that they keep enabled on desktop Safari where users have an actual browser engine choice. Also, Safari imposes limitations on extensions that aren't all that different from manifest v3.
I spent years hoping for Apple to see the light, allow other browser engines, AT LEAST give us proper WebM and Opus support. Yet, today, it is no sooner to happening. I finally got fed up and switched back to Android where I grabbed Fennec F-Droid, installed uBlock Origin and finally had a decent mobile browser.
> I spent years hoping for Apple to see the light, allow other browser engines
as soon as apple tried to remove flash, they've shown their hand tbh. While it was generally considered good, the ideology behind removal of flash is the same ideology for their policy to not allow other browser engines.
Strong disagree here. Flash represented a proprietary takeover of web standards. It was bad technology with a bad license and had bad consequences. Apple’s ideology resulted in a pure gain for the open web.
Apple’s dictatorial control over browser engines on iOS represents, somewhat ironically, the last significant defense in the cause of browser engine diversity. While Apple’s motives might be less pure here, the outcomes are no less of a win for the open web.
The outcomes are definitely less of a win for the open web in many cases. It is astounding that I have to deal with Apple proponents unironically trying to argue that WebM and Opus are bad things.
Of course Safari on iOS supports Opus, but it just doesn't support it in any standard container... which is one of the most pointless things I can think of.
Wikimedia doesn't care. They just load a polyfill with WebAssembly-compiled codecs for VP8/9/AV1/Opus/etc. and do it on CPU. The net effect is that iPhone users get a worse Wikipedia experience for basically no reason.
I don't disagree that support for open codecs should be more of a priority for Apple/Safari/WebKit. But you're missing the bigger picture. The web should be resilient to clients which don't support all of the latest features. It shouldn't be necessary to be using a bleeding edge version of Google Chrome (or its clones) in order to have a first class web browsing experience.
While one might complain about the inconvenience of supporting the few gaps in Safari on iOS, this complaint is actually of having to support people who don't (or can't) run the latest software because they (for example) haven't chosen to pay money to upgrade their computing device to something which supports Windows 10 or a recent release of MacOS.
The fact that Safari on iOS isn't bleeding edge is actually an under-appreciated gift to people who choose to/are forced to run older software. It's one of the last vectors forcing lazy web developers (i.e. most web developers) to continue taking browser diversity seriously.
Came to mention that you don't need a rooted Android to run uBlock Origin, SponsorBlock, Enhancer for YouTube, Augmented Steam, Decentraleyes, I Don't Care About Cookies, Violentmonkey, or Darkreader... you just need FF Nightly:
Note one thing, if your collection name contains spaces, you need to use the hyphenated version - basically the url segment that is in the collection's url when viewing it in the browser. That's not said in the article and it wasted some time for me.
Adobe very poorly maintained it, it had constant security issues, it was poorly coded, and was abused as an ad platform.
When Linux moved to amd64 / 64bit exes, it took them years to port it from 32bit to 64bit. Why? The codebase was a mess, and they put one dude on it, and his complaints leaked all over the place (I'm sorry it's taking me so long, but this codebase is a mess of spaghetti, I'm having to re-write the whole thing, etc)..
As with everything Adobe buys, their only goal was to ride it into the ground. It is a testament to how popular flash was, that they even updated it at all, ever!
Apple/Jobs may have had fiscal reasons for this move, but it was a great benefit for all regardless.
I had no idea it was this bad behind the curtain. My association with Flash is positive, though entirely for the animation culture it engendered and not the problems like these. I wonder whether Director/Shockwave was any better?
Also, mad respect to the developers at http://ruffle.rs, who are having to do it _again_! Maybe they have a chance to implement the Flash runtime cleanly.
Heck yes. This shouldn't even be a controversial statement. Flash was famous for its seemingly perpetual conga line of serious security vulnerabilities. It laughed at the browser security model. The web is a much, much, much, much, much better place because it was forced to die.
Flash was a kind of devious problem in the same way as IE was and Chrome is:
Those who depended on it got benefits while messing up the lives for everyone else.
To be fair to IE and its modern replacement Chrome, if you develop and test mostly on IE and Chrome you can make things cross browser if you put effort into it, something you couldn't with Flash.
Getting rid of Flash - whatever the reasons was - was a huge gift to the web and by extension people like me who develop on and for an open web.
It’s worth noting that from Safari 14.1 on macOS 11.3 and from Safari 16 on all macOS they do support WebM fully. (Source: https://caniuse.com/webm.) Still not on iOS, and still no Opus outside of CAF packaging, but one can continue to hope.
This isn't reasonable. Today on iPhone, even if you pay $100/year to be able to run unsigned code, you can't get a copy of Firefox running, because nobody maintains the port. That kind of crippling grasp on the ecosystem is difficult to tolerate, and simply nothing compared to what's going on with Google.
Today with Pixel phones, you can secure boot third party OSes without even voiding your warranty. You can unlock the bootloader. Even if this ever were to go away, Android still has multiple ecosystems and you can sideload apps as long as your OEM doesn't disable this, and Google doesn't.
Apple isn't getting more consumer friendly. iOS is less private than ever, not more, and Apple seems intent on making it worse; they dropped the needless CSAM debacle, but that doesn't mean it should be ignored. Apple has made their position clear: an iPhone is not your phone. It's Apple's phone. You may borrow it on their terms. The law may say otherwise, but Apple thwarts your attempts to work around it.
Android is imperfect; it's definitely not good for privacy if you use stock ROMs, it's behind on security in many fronts, and Play Store lock-in has definitely put a damper on innovation. That having been said, though, at the end of the day, Google gives you options that lets you take control over the device. The future of being able to control your own devices is unclear with remote attestation once again on the horizon, but being able to control what software runs on your device to a decent degree is absolutely an important feature for me, especially after hoping and praying that Apple would eventually fix the problems I had with iOS. But they were not bugs to Apple, they were features, and Apple knows if people could run their own code, those features wouldn't work very well.
That left a bad taste in my mouth. Until it's fixed, I don't think I can consider phones that Apple sells today as serious options as they are a different class of device to Android phones the way that a game console is a different class of device to a typical laptop.
Reading your comment, my final thought was that essentially if you want to maintain another computer, similar to your desktop, buy an Android phone. Research and install your ROM of choice, route it and install the programs you want, and you are responsible to make sure it all works.
If you don’t want yet another computer to maintain consuming hours of your time, buy an iPhone.
I do use Android for my streaming set top boxes, because of that flexibility. Devices like the Fire TV are flexible, like having an energy efficient and much more affordable version of a PC. But for my phone, for such an essential device that just has to work, it’s too much to ask out of me.
You aren't wrong in a technical sense but the amount of effort to make it work is really overstated here. It shouldn't take more than a few hours tops for everything you are describing, not including the time spent choosing the phone of course.
You have to compare it to the time lost with iOS as well, whether it's from missing apps/features or salary hours spent on the Apple ecosystem because of the lock-in.
Your second paragraph is a bit of a stretch in my humble opinion. Missing apps and features, on iOS? I see. And salary hours?
I was a long time android phone user. I used Cyanogenmod, which became Lineage. I was kind of left in a lurch once CM dropped support from my phone. Then I was using some truly obscure software. It doesn’t feel comfortable to use with banking apps.
There used to be a good handful of distinct advantages for Android on phones. But today if anything important is missing, it’s more likely be missing on Android. Outside of someone who really wants FF with UBO. For example, if you buy a Sonos sound bar and want to use the room adjustment software, it only exists on iOS. Sonos can’t guarantee the quality of the microphone used to enable the software for Android.
In regards to your first point, yes it may only take an hour or two if you know what you’re doing or have done it before. But most users are not going to be doing all of that on their phone.
For me, I found that chasing secure and up-to-date software on android ended up being like duplicating my desktop PC. And I say that as someone who is an Android fan. Just for certain use cases. And by no means a partisan in this whole debate. It’s really just my experience as a software developer that has spent five years or more on each platform.
I quite like the Samsung phones. If I went back, I would pick up one of those. I really like the Dex feature and the USB-C is mandatory. But there’s not much that personally draws me in from the points that you mentioned, the time and technical investment, any missing features or lock in.
If you don't mind the way the Pixel device works out of the box, then obviously it's basically on par with an iPhone in terms of ease of use and setup. They trade blows obviously, but I'd call the experience comparable. I can switch between iPhone and Pixel with absolutely no confusion.
But if you do mind the way it works, you don't necessarily have to throw out the baby with the bathwater. Sometimes, you can get the changes you want without having to do a whole lot of work. If all you want to do is sideload an APK, like the F-Droid store for example, it's some straight-forward taps. The system even guides you into it, no blatant dark patterns in my view of it. This is honestly pretty good, maybe even nicer than the modern macOS defaults!
That will get you Fennec F-Droid and uBlock Origin very easily and quickly. No developer mode. No confusing dark pattern UX. No $100/yr payments. No flashing ROMs, no rooting, nothing. Just tapping the screen a bit. Keep in mind that Android also has the intents system so many default things can be changed, not just browser or e-mail client; pretty much any action that can open a third-party app can be supported by another third-party app.
If you want to go deeper, you might root your device, install something like Xposed, or at least modify system APKs. It's not all that bad, although obviously the tradeoffs start to hit here: Safetynet no longer passes unless you bypass it somehow, OTA updates might undo some of your modifications, etc. But, it's still pretty powerful for not all that much work. Guides and tools are usually made so that moderate power users can do it. Plenty of kids do it for sure.
And finally, if you want full control over everything, you can install third-party ROMs like GrapheneOS. Honestly, sometimes this is even easier than rooting, but it does come with some downsides still (I don't believe SafetyNet would pass on most third party ROMs, although miraculously, Pixel devices do support Secure Boot with third party ROMs, which I honestly feel was a very unexpected improvement of recent years.)
Are Android phones generally less usable? I don't know. My whole family has always used Android phones and it seems fine. I do think the ecosystem of Android phones is a little weak right now, but at least we finally have CPUs that aren't so damn weak; that was one major score in favor of iPhone that was really hard to argue. They're probably still not all that close in the benchmarks, but it doesn't mater; the subjective experience is better. Android phones can finally drive high-refresh-rate displays very smoothly, and Firefox no longer feels like trying to browse the internet on a Pentium II. What I will say is that Apple has more advanced features for casual users provided that you stick to their ecosystem, but the "stick to their ecosystem" part is a hard sell for some of those features.
Which part isn't resonable? I was proposing a thought experiment in understanding motivation and the version of the future these companies are building towards.
The reason why is because on iPhone, I can only hope and pray for things to get better, which I have been doing for three years; there aren't really any options if you don't like the intentional limitations of the iPhone. With the Pixel phone, I have options today and indefinitely, regardless of the motivations of Google. Comparing Google's motivations vs Apple's motivations is missing the bigger picture.
It's not a panacea, but it's about as close as they come.
It makes no sense to assume how companies will act in the far out future, as companies are not people and their motivations shift with management, investors, and markets. You can at best look at the motivation as an explanation of the short to medium term. Long-term, the company might be in entirely different hands. Look at Sun. Apply your strategy to Sun as of a few years before they went under and chunks were bought by Oracle. Sun's motivations meant very little in the end, only what they actually did (such as open sourcing things) survived.
SDM 845 devices, Especially OP6/6T and Xiaomi Poco F1 has changed the landscape for PostmarketOS(Still is not for everyone though).
Firefox/Fennec F-Droid is indeed great (Especially since UBO is supported), But unfortunately in Android almost every enthusiast project involves privilege escalation and in this case F-Droid auto update apps requires one too.
Apple offers a Content Blocking API which is leveraged by most apps and similar to mv3.
Most of these apps (now) also include a JavaScript extension to block the harder ads (eg youtube). This a recent development that apple seems to encourage.
Some apps also offer network-level adblocking by using a local VPN server, which allows for blocking in apps.
Firefox for Android used to implement scroll coasting in a way that felt very different from Chrome and native Android apps. I just gave it a try now and it seems like they've fixed it, scrolling feels native now.
I just retested in case they fixed it and no [1]. The easiest way to tell it's non-native scroll is that Android has this effect when you reach the top or bottom that it "stretches" the content. You can try it everywhere (even inside Firefox settings menu) and it will work like that, except for the actual webpage in Firefox.
Another difference in the scroll is that it has much higher friction (deceleration) in Firefox than native Android.
[1] Firefox 103.2.0 on a Samsung S20 with latest updates.
Little late, but for the record, your first issue reeks of a Samsung-specific bug. My Pixel 2 running LineageOS stretches the same in the [phone] settings app as it does in the [Firefox] settings page. Samsung has always had weird quirks in the way their skinned Android runs, and AFAICT, were the absolute worst for causing app developer headaches in the earlier Android days. I would be shocked if they've gotten dramatically better since.
I'm sure the settings page does - but because Samsung implements APIs a little differently, and this has caused devs issues in the past, I'm assuming the browser with a smaller dev team may have missed this quirk at first glance. Other Chrome-based browsers probably don't have this issue - Chrome's team is very well-funded, and forks likely benefit from Google doing the edge-case testing.
Maybe Firefox is doing something weird, but I've got a coworker with that same phone - so at the very least I can compare my Pixel to his Samsung, and see who threw standards out the window.
I'm not the GP but I've noticed since the switch over to "New" Android Firefox (Fenix or whatever?) scroll events aren't handled properly. That is, dragging your finger around on the screen works, but any other source (keyboard, for example) does nothing. Maybe that's what they were referring to; maybe they have a different issue.
Check out https://www.bromite.org/, it's a android chromium fork with adblocking built in like brave but without the crypto stuff. Also has support for userscripts!
I find Firefox on Android to completely unusable for many of the sites I visit because it doesn't support the Google Translate plugin for some completely idiotic reason. I can only use it on sites that are in English. For everything else, I have to use Chrome.
I have Firefox Nightly, and it still shows the same small handful of extensions as regular Firefox. Is there some secret menu I have to go to or something? Honestly, this is ridiculous, and it's pretty obvious that Mozilla simply does not want us using any other extensions. They have no right to complain when I use Chrome instead. I need translation just to survive and pay my bills.
To be clear: it is a willful choice by Mozilla to fully protect Android users but to leave iOS users in the turmoil of a constant stream of invasive and malicious ads. I specifically took my parents off of Firefox for this express reason. Brave has a built-in adblocker, as do many other iOS browsers.
And it is not like Mozilla isn’t aware, I believe there are 2-3 open issues on Bugzilla, years old, that have just been left to wither.
Isn't there some rule that any browser on iOS must use the native Safari engine? So if iOS Safari doesn't support something, there's no way for Firefox to add that support. It's basically just a skin.
Yes, but like I said, many other 3rd-party browsers have perfectly fine built-in adblockers.
Hell, you can install Firefox Focus (which is a ‘private mode only’ browser) and that does have built-in adblocking. More perversely, you can use it as a content blocker for Safari.
(No, other browsers using Safari’s engine do not inherit the content blocking)
I repeat: Mozilla is willfully choosing not to protect iOS Firefox users from ads. Plain and simple.
I know it's Safari under the hood, but Brave on iOS is great.
I do hope that Apple decides to / is forced to allow real 3rd party browsers at some point, though. I also hope that a decent Linux phone becomes a realistic alternative.
I'll check back in 10 years to see if either of those materializes.
LineageOS was good back when it first formed from CyanogenMod but then had a patch of issues with call quality and reliability which forced me off it. Hopefully that’s all long resolved, I would otherwise switch back but I reply to much on my phone for work.
I think that what dethroned IE is that using your monopoly to maintain a moat of bugs only works for so long. If the browser is going to continue to be developed, eventually you're going to have to fix the bugs. By then, they were competing with Chrome, which was not bug-ridden and also backed by a juggernaut.
The grassroots push that dethroned Microsoft's browser was Google's browser (aided by Firefox's suicide.)
This comment is perhaps the most accurate take on the fall of IE.
Firefox dethroned IE not because it was "MuH fReE oPeN sOuRcE sOfTwArE" or "MuH nEtScApE", it was because Firefox was superior to IE in performance and feature set. It was better than IE at being practical and enabling users to do things they needed or wanted to do.
Shortly after, Chrome rolled around and it was superior in performance (RAM hogginess aside) and feature set (for Joe Average, not necessarily power users) to Firefox and dethroned the dethroner.
Firefox will not be a dethroner again, because Firefox is not superior to Chrome. In fact, it's inferior to Chrome: It's been a third-rate Chrome ripoff for at least the last 10 years. None of the Chromium forks will dethrone Chrome either, because they are also third-rate Chrome ripoffs by their very nature.
It is conceivable that some browser superior to Chrome will eventually come out and dethrone it, but that's probably still a long ways away and I would argue the challenge of dethroning Chrome is several orders of magnitudes harder than dethroning IE ever was.
Which is probably why Google is pushing for so many web extensions - to make sure that they stay ahead of everyone else and you need billions just to catch up.
Unfortunately it seems Firefox is falling into the trap and is desparately trying to chase Chrome instead of focusing on significant user experience innovations to distinguish themselves from Chrome, especially ones that Google is unwilling to add to Chrome.
At least for me, Chrome was always faster than Firefox, though this always came at a substantial cost in RAM demands among other computer resources. This difference in speed has only become more and more apparent over the years as more and more websites have gotten bloated with reams of JavaShit and HTML5 nonsense.
I'm also of the impression that Mozilla and Google's respective marketing ultimately had a very minor impact on overall adoption. The key driver behind Firefox and subsequently Chrome's mainstream adoption was initial uptake by power users who then spread it to the commons by word of mouth. The latter is arguably still ongoing, seeing as OS-default browsers like Edge (let alone third-party browsers like Firefox) still can't even hope to compete with Chrome.
> I see plenty of folks in here lamenting this release at all - in the hopes that the lack of it will push folks to Firefox. It won't. Those who care about this are already on Firefox
Huh? I'm going to switch to Firefox the second uBlock Origin stops working on Chrome. Otherwise I'll continue to use Chrome because it's a better browser (for me). I don't think I'm some rare minority here.
In practical terms I haven't seen any ads on Chrome so the blocking experience seems good enough. If you care about privacy Firefox definitely seems better.
I don't think you are either, but like the rest of that group , I expect that you'll keep using Chrome anyway. Because it's not like uBO will stop working, it'll just be a bit worse.
I dunno. The new version does not strongly affect end users (according to the devs) but there is a psychological barrier around switching from the full version to the minus version, which I think will cause me to switch to Firefox.
Even if the new version works now, Google are clearly going to tighten the vice over the next few years.
Hmm, I guess it depends on what this will look like long-term, but I'd expect that regular uBO will be "upgraded" to this version when MV2 is deprecated in Chrome for good, possibly including the name change (if allowed by Google).
Edit: ah, looking at gorhill's comments it looks like this is not intended to be the MV3 version of uBO, but just one that has minimal permissions. Then I guess uBO will migrate in its own time.
Ultimately it'll come down to the experience - if uBlock stops blocking some percentage of ads (because it's impossible under the extension), or triggers ad-blocker-blocker type stuff, I would be very quickly be moving to Firefox!
Either way, very thankful to the developers and community for making our web browsing experience so much better.
The MV3 bugs are stupid ridiculous. Like, I'm gonna open a long-lived communications channel, but it'll be destroyed when the service worker shuts down in an arbitrary n<5 minutes. Okie doke. Clients love to hear it.
The comments on that bug are depressing as well. I generally am involved in much more niche development communities - is this kind of disrespectful back and forth the standard these days?
People are kinda bitter about this. You can design around it, but it makes a lot of things way bigger jobs than they should be. I was just explaining my way around this one today. You port from v2 to v3 and all of a sudden it's basically a rewrite to make everything datum serializable and every function re-entrant because you never know when chrome is going kill your process.
At this point, it's just the way it is now with Google. They promised Crostini for kaby lake chromebooks (I think; maybe another chip) for like 3 years in a row. A thousand comments on there. People are just frustrated.
Oh, I understand the bitterness around Manifest and a lot of it is justifiable.
I was referring to the two developers (both seemingly not Google/Chromium affiliated) arguing about a workaround involving an “injectable tab” and taking pot shots at one another’s comprehension and ability.
> if they were suddenly deprived of good adblocking on Chrome.
Ok - but that won't happen (at least not yet, given the m3 api available, who knows what google will do long term).
The majority of users won't genuinely notice any difference between an adblocker running on m3 vs m2, and plenty of companies are going to make them.
My point is that despite the push back from the UBO dev (and I sort of agree - this does limit some capabilities, although not nearly as much as he claims) M3 is absolutely not going to kill the adblocker extensions available in chrome.
It just makes them... slightly minus. Which is why I think the name is a good call. I don't approve of the direction google is going, but this is not the deal breaker for any sort of public audience - it's just a talking point among the tech literate.
"The majority of users won't genuinely notice any difference between an adblocker running on m3 vs m2"
I think that'll be true for a short time. But once the advertisers figure out that ad blockers have been crippled on the most popular browser...
They'll figure out how to take advantage of that.
Once Chrome takes away the ability to do live heuristics, and leaves you with just a static-ish blacklist, it's pretty easy to get around the ad blocker.
Since adblocking on Safari (both Mac and iOS) is mostly done by Content Blocker API that's like manifestV3. Many mobile users already in such situation. People still fine with current adblockers on iOS.
Yes. But soon, all adblockers will have roughly the same abilities or lack thereof. That's when it's worth the effort to render them all useless. Risk/reward and all.
But you can already work around adblockers by just serving ads directly from your own servers.
Frankly - you can also move to a service that implements adblocking at a different layer (I've seen an explosion of dns based adblockers as a service, likely inspired by the likes of pi-hole). Those services are using roughly the same feature set that's still available in m3.
The big dealbreaker (imo) was the inability to configure rules at runtime, and the requirement that they be declared in the manifest - and that never actually happened (you can dynamically configure them with https://developer.chrome.com/docs/extensions/reference/decla...)
>But you can already work around adblockers by just serving ads directly from your own servers
The available heuristics in UBO can block those with many different techniques today, especially for a short list of very popular sites. I assume many of them stop working with MV3.
I'm aware of the DNS based adblockers, what I'm saying is that the advertisers might take action on all of them once the best option is hobbled. Then it's worth doing something that will break almost all the adblockers. One effort that puts everything to rest.
The only real limitation in m3 is the lack of blocking a network request on its way out to inspect it (you absolutely can block it - and the second time it's made you can block it after inspecting the first instance, but you can't inspect then block). To be clear - that's still a loss, but it's just not on the same scale as the type of loss that was originally worried about when Google first announced m3 without a way to update blocklists dynamically.
At the time - they were intending blocked URLs to be placed into the manifest file directly, which can't be updated without a full update to the extension in the webstores (2 to 3 days for chrome, couple of minutes for Firefox after first review).
That's a real pain, since you couldn't do something like heuristically determine that a request was serving an ad and then block it the next time it comes around.
But you can, now (and again - it's not as nice as it was, but it's still there).
There are still some limitations that are a pain to juggle (max size of the blocklist, max number of dynamic rules) that do make life a bit harder, but those I can genuinely see compelling reasons for adding - every comparison the browser is making against a blocklist for each outbound url is adding overhead on TTFB for the user - I think their caps are too low still, but at least I have a technically compelling reason to understand why the limitation was added (something other than - Google wants to unblock ads).
Basically - I'm telling you, as a subject matter expert in this space: Most users will not notice a difference. Some very discerning users, and some technical users might, but a lot of those folks are already off the Chrome train anyways.
> what I'm saying is that the advertisers might take action on all of them once the best option is hobbled. Then it's worth doing something that will break almost all the adblockers. One effort that puts everything to rest.
What? What power do you think advertisers have here that will suddenly undo the foundational hierarchy of the internet? DNS ad blockers literally aren't going anywhere anytime soon, and I agree with the general thrust of "If Google destroys ad blockers - users will leave", I just don't think they've done that with m3.
Your idea results in a glorious day for Mozilla Firefox indeed. But I think you have to look even further down the line, assuming your future does play out as you described. And then all you have to look at is what we have today with Brave. Building in their own ad blockers that don’t rely on MV3 at all. Chromium-based browsers like it will have a market of their own.
Off topic, but since you seem experienced at this, do you recommend any resources for extension development for someone that's beginning from scratch with no experience in this area?
I was frustrated with the lack of resources, so I'm publishing a book on it: "Building Browser Extensions". Available later this year. https://www.buildingbrowserextensions.com/
Wladimir Palant (original creator Adblock Plus and nowadays doing security work with a focus on browser extensions) has recently started a blog series on browser extension security: https://palant.info/2022/08/10/anatomy-of-a-basic-extension/
100%. Firefox murdered XUL extensions, a then-thriving ecosystem, and the mobile version's addon support is still very lacking, years later. If the moaning from this haven't stopped them, uBO's lack of mv3 version certainly won't.
I switched to FF a few months after I started hearing about this change coming down the pipe. It was totally fine and easy. I haven't had any issues because of it outside of one weird old website not working perfectly. And I still have Chrome installed so I just used it for a minute in that one case in the last year-ish.
Maybe some of us are sick of Firefox fans taking this moralizing tone that we're somehow "damaging the cause" by simply speaking our mind when we disagree with your assessment. That doesn't make me a google shill, nor cynical. Just tired of the nonsense.
To steelman their argument, I'd say Google has grown so large and so controlling that literally anything that can provide a viable alternative should be cherished. Even if it's entity that is under questionable leadership like Mozilla.
Please don't tell people to refrain from posting their analysis here, especially when their point is both clear and very logical.
It would be better and much more productive if you would explain why you think that Firefox has a bright path ahead given all we know about it's management, strategy, corporate practices, and frankly raw figures about new installs / usage over the past 5 years.
It sounds simple enough but it's not so easy actually. I found myself spending some time doing it, and there were enough annoyances to abandon switching to firefox.
I really want to like it, it just doesn't click for me. There is just no practical incentive at the moment to switch (for me), just the more idealistic ones about privacy and so on.
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)
It's also an interesting magnet for traditional media - imagine if CNN ran a lede "Ad blockers. You may use them, you may not, but Google is on the warpath against them. Here's the developer of the popular uBlock Origin Minus describing why his software suddenly has that odd name."
Sadly, this is likely not to happen, as every newsroom relies on online ad clicks for a revenue stream...
Tangent but let's stop referring to it as a mere ad blocker, it's a content blocker - it's even a very useful and impactful accessibility tool in that capacity.
ADHD sucks and I have a lot to thank to these types of tools for acting as my "crutches" that allowed me get where I am today.
I’d just like to interject for a moment. What you’re refering to as an ad blocker, is in fact, a content/ad blocker, or as I’ve recently taken to calling it, a content plus ad blocker. Ad blockers are not an extension unto themselves, but rather another downloadable block list for a fully functioning user agent made useful by the extension, browser chrome, and vital web engine components comprising a full user agent content customization system, which, in this case, can be customized using the ABP blocklist syntax.
Many computer users run a modified version of a content blocker every day, without realizing it. Through a peculiar turn of events, the version of the content blocker which is widely used today is often called an ad blocker, and many of its users are not aware that it is basically a generic content blocker with a particularly popular block list preloaded.
Sorry, what? How are youtube ads hurting neurodivergent people in a way they don't hurt 'normal' people? If you can't handle youtube ads, don't go to youtube.
YouTube ads directly try to game the users attention. This is distinct from regular advertising (billboards et al) because your engagement directly and quickly affects what ads are served to you.
People who have particular sensitivity to attention changes ('attention deficit' might be a term for it, but there are other ways it can manifest) are going to be affected disproportionately by this, even if they don't disproportionately make up the revenue of the platform.
Because of the increased sensitivity, the disruption also has the potential to affect the neurodivergent user more destructively than the neurotypical one.
You can make the case that 'if you can't handle YouTube ads, don't go on YouTube', but then that runs counter to a lot of YouTube's content marketing and brand image. So if you take that stance, you then have to necessarily question the motives behind their other choices.
> This is distinct from regular advertising (billboards et al) because your engagement directly and quickly affects what ads are served to you.
This is exactly the same as TV and radio ads have been for decades now. Which ad is served is not at all relevant.
> You can make the case that 'if you can't handle YouTube ads, don't go on YouTube', but then that runs counter to a lot of YouTube's content marketing and brand image. So if you take that stance, you then have to necessarily question the motives behind their other choices.
Take some damned personal responsibility. If something is causing you distress, stop doing it. Whether it's cigarettes, alcohol or youtube, it doesn't matter.
>This is exactly the same as TV and radio ads have been for decades now. Which ad is served is not at all relevant
I'm sorry but that's just incorrect, and on top of that, you've fixated on the wrong point. The form does affect the impact on the users heavily, and can be observed by how long a given user spends looking at an ad vs how long a television ad holds someone's attention (if you doubt this, feel free to conduct an A/B test and find out for yourself). And the point I was making was that the way the ads are designed and delivered has a feedback loop MUCH more rapid than TV and radio ads, and the algorithms exploit that. Don't argue with a strawman.
>Take some damned personal responsibility. If something is causing you distress, stop doing it. Whether it's cigarettes, alcohol or youtube, it doesn't matter.
I'm not taking responsibility for anyone, sorry. I'm talking about a group of people, not myself. Regardless, this component of your reply was just plain silly. Please don't try to talk to people like that.
I think uBlock Origin providing a manifest-v3 compatible extension would be a net negative for the community. As it will help more people accept the status-quo and accept a mediocre state of ad blocking, instead of switching to Firefox
If uBlock doesn't provide a compatible extension or if their extension is worse than possible I'd likely just switch to the best alternative which will pop-up. I imagine most users will do the same.
Adblocking means little if the actual browser is terrible to use. Between proper adblocking and a shitty browser, or a shitty adblocker and a shitty-but-still-usable browser I will take the latter because ultimately I have shit that needs to get done.
Until recently, Firefox was an inferior browser, at least on macOS where it did a bad job of fitting native UI conventions, had a much less secure sandbox than Chrome, and was also behind in performance. Seems like things have improved on all of those fronts, so perhaps it's time to take another look. (That said, I've only ever used Chrome as a secondary browser for certain sites – my current primary one is Orion – so I have less incentive to experiment.)
I've had multiple (typically but not always google) sites not work as well with firefox, as well as minor things like more captchas. I also don't want to worry and keep checking if my subpar performance on a site is because Google, a lazy dev or a lib didn't optimize for FF. Further, I just have a bunch of settings, extensions, saved password, history etc. already setup in Chrome.
A pragmatic reason for me: Firefox has been lagging a lot on my Windows machines for months, and I couldn’t figure out the problem. Tried extensive googling, even tried debugging it in the developer profiler to see if anything’s strange.
I’ve now given up, and switched to Chrome without regrets. I still miss Tree Style Tabs, but the sluggishness isn’t really worh it.
I’ll start using Firefox again until they fix this issue and realign their funding towards actual better engineering & performance instead spending on vanity “activist” projects.
What community? "People who use chrome"? Because that community couldn't care less about which version of manifest is the current version, and what its restrictions are. If they did, they'd already not be using Chrome anymore.
At this point I consider being permission-less the limiting
factor: 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.
That naming convention is an absolute stroke of genius. Not enough to get sued, but enough to convey to millions that they are using an intentionally crippled product.
Is there a plan to make the existing Chrome extension update to this (somewhat neutered) version automatically when the time comes for v2 deprecation (which appears to be in January 2023 for non-enterprise Chrome users)? I ask because I have provided my elderly relatives with Chromebooks and if the built-in adblocker is going to stop working I'll need to remote desktop to their machines (which requires a fairly-complicated-for-them dance with generating one-time codes) in order to install this other version when it's released...
(I personally use Firefox but I didn't want to give them a regular Windows laptop because they'd have to re-learn far too many things -- the old laptops were Windows XP -- and ChromeOS is both harder to break and easier to recover.)
Which, as far as I can tell, is exactly what the removal was designed to do—nothing about MV3 impacts cosmetic filtering in any way, and it seems to have been removed by the developer purely out of a sense of stubborn pique.
Judging by their comments now, the point is to show that the stated reasons for crippling MV3 are invalid - because the technology that allows for cosmetic filtering undermines those goals. However, if you do care about those goals, you can use Minus, which applies further restrictions in line with the stated reasons.
The Chromium - a thing on which Google Chrome is based - is open source. I imagine someone could make a version of it where you'd get most of the Google Chrome features but be able to give elevated access to certain extensions like ad-blockers to the network and requests.
I tested this against AdGuard MV3 on Edge, and while I will wait for 1.0 releases of both, so far, AdGuard MV3 is trouncing uBO Minus.
It's doing cosmetic filtering, uBO is not. Neither seem to be slowing down the browser in a noticeable way. Eager to see 1.0 benchmark results.
You also get some options to adjust in AdGuard. uBO Minus (hell of a name), nothing.
I would suggest to the author of uBlock Origin to change attitudes towards the MV3 extension as even Mozilla said MV2 was sticking around "for now".
This work is inevitable. Other options would be to partner with a browser like Brave to take over their adblocking development, or, create a system-wide blocking solution. Microsoft may be worth engaging with as they have no native adblocker, but given gorhill's clear purism about profits and Microsoft that doesn't seem likely. Someone else has to publish uBlock Origin for him on the Edge Add-ons store.
Still a bit exciting, as even Mozilla will turn off MV2 at a point. No reason to resist this. Once the uBlock Origin guys figure this out, we'll get a good race between it and AdGuard. So far, AdGuard is the clear winner.
How many people use adblockers? Is there any chance manifest v3 will lead to enough users abandoning Googles Chrome to build a community around an open alternative, like we did when we abandoned IE for Firefox all those years ago?
> Is there any chance manifest v3 will lead to enough users abandoning Googles Chrome […]
No. Google Chrome is pretty much in the same position as Internet Explorer used to be. It's the default browser in the most popular mobile OS and the first thing people install on their PC (or get it installed by someone else). Mozilla can barely play catch-up with all the complex web standards pushed by Goog&co., to say nothing about adding killer features that could bring enough users back from Chrome.
Modern web browsers are rapidly approaching the YouTube territory. That is, becoming a technology so complex that only a multibillion-dollar conglomerate can really maintain it without losing money.
It seems the actual number is 43% of those surveyed use an ad blocking tool at least once a month, so a lot of those may only have their ad blocker installed on their PC, plus the bias that comes from only having the answers of those who responded to the survey
Still that’s a fairly overwhelming number of people who feel strongly enough about the topic to install a plug-in. I’m sure there’s a portion of ‘no’ responses that are not aware of what adblockers are or do
I'm using Firefox with moderately aggressive ad blocking and privacy settings. Almost everything works, and the few breakages that I encounter are usually due to the blocking/privacy settings (i.e. they'd happen the same on Chrome if I configured it similarly).
The only thing I actually have to start Chrome for is (ironically) Microsoft Teams.
What does it even mean to use an ad blocking tool "at least once a month"? Like... do people have an ad blocker installed, but disabled most of the time, and just enable it temporarily when they come across a site with particularly egregious ads? That seems... an unlikely use model?
Yeah that's good scare mongering but I dont buy it. I betcha most of that stuff is megacorporate bloat that can be extricated without hindering the average users experience.
Mozilla, unfortunately, is dead. Like Firefox did from Netscape before it during the dark times of the IE ubiquity, when people claimed what you claim now, a new browser that supports true freedom must rise from Firefox's ashes to begin the cycle once again.
43% is huge. Firefox had significantly less when it won hearts and minds.
> Mozilla can barely play catch-up with all the complex web standards pushed by Goog&co.
To be fair they also spend a lot of resources on dreaming up their own shit tier solutions. Like the time Google proposed federated learning of cohorts, which was universally shot down by critics. Mozilla saw that as a sign and jumped into bed with Meta to create their own version of it. Because who could think about user privacy without immediately thinking of Meta?
It is almost as if Mozillas leadership wants to prove that Mozilla is a waste of money.
Adblockers are an existential threat to Google. If any appreciable percentage of the population started using a browser that allowed adblockers, Google (and Facebook, and Twitter, and Reddit, and...) would do everything within their power to block that browser from all the web properties they control (this is not an exaggeration: everything within their power, because the alternative is the death of their entire business model and the end of the company). Even if you can play cat-and-mouse games to get around the adblocker-blocking, the inconvenience of that alone would be enough to shift most non-power-users back onto Chrome.
> If any appreciable percentage of the population started using a browser that allowed adblockers, Google (and Facebook, and Twitter, and Reddit, and...) would do everything within their power to block that browser from all the web properties they control (this is not an exaggeration: everything within their power, because the alternative is the death of their entire business model and the end of the company)
Even easier, they would just sabotage their own web versions (like reddit with mobile.reddit.com) to force people to use the app versions where tracking/ads is harder to block.
The web is the best platform for us, the users, and the way to go - good sandbox, transparent, customizable. We should fight tooth and nail to preserve it.
Adblockers might be an existential threat to Google, but MV3 won't change anything for Google. Google AdSense ads will almost certainly still get blocked, they're not hard to block/ obfuscated.
I really doubt this will change anything for Google with regards to ads. At most you can argue that this is "step 1" in a larger plan to eventually bypass these adblockers or something, which I'll totally buy, but V3 has gotten better at blocking ads over time, not worse.
> V3 has gotten better at blocking ads over time, not worse.
That may be true, but it's still significantly limited compared to MV2. And at the current rate, that is unlikely to change by the time Manifest V2 support is removed.
What's important is that MV3 adblocker developers no longer have full control over how they're allowed to modify pages. Given how adversarial the relationship between adblockers and websites is, that lack of control will be exploited almost immediately.
Yeah, so I'm against V3 mostly because I think that the pros of developers having power outweigh the cons of potential malicious extensions. I personally would have preferred rethinking a few other areas first:
1. Auditability - both in terms of the code and the behaviors
2. Improved permissions - could we have split WebRequest up?
3. Improved performance - could we have leveraged new APIs, like the declarative API, for improved performance? What about compiling to wasm? Or new APIs?
4. Capabilities/ Sandboxing - Within an extension could we slice out capabilities?
5. Improved UX around permissions. Surfacing the permissions and performance implications of extensions would be worth exploring and aided by any ability to slice up permissions more.
Chrome could even create 'sanctioned' extensions that wouldn't trigger scary popups in order to make it that much clearer when something is scary - something like "if you publish your extension such that it is digitally signed, you use 2FA or whatever, you have good standing with us, blah blah blah, we will waive that popup". IIRC Firefox did this to lower their review burden, NoScript was one of the ones on the list I think, but that would have been many years ago and I don't know if it has changed since.
That said, I don't think V3 is the end of the world. I would have preferred the other options, and I bet some people at Google explored them too and know much more about why they are/aren't viable, but I'm OK with V3. I don't really think that Google Adsense is driving this decision at all nor do I expect it to benefit them, at least not in the short/medium term.
Great suggestions. The "third party buys popular extension and quietly adds malware" approach is also a huge attack vector. There really ought to be some way to prevent an extension from updating until you've had a chance to review and approve that change, especially if it requests a lot of sensitive permissions.
Well, even today, if the attacker modifies the permissions it will require a re-acknowledgement. Google can also do things there, like if the extension is tied to a key (as it should be), tell developers that they are required to not provide that key to anyone else, even if they sell / transfer ownership of the extension. Instead, the new owner should register a new key, which can trigger review/ scrutiny.
Key + 2FA means the attacker has to have code execution on a developer's machine in order to publish an update (via the local session token, which you should make short lived). And Google could require a FIDO2 token if you want to bypass the "alert users that this thing uses lots of permissions".
There's a lot of stuff I'd be working on to avoid having to remove developer power.
edit: K I've been rate limited by HN so I can no longer reply for today, but them's my thoughts.
From Google's point of view, they generally use "How many people are running adblockers" as just another quality signal on whether the ads are actually working as intended. Google doesn't really care if a little under half the users on the web block them.
Google will be able to use a variety of ad delivery methods that are not yet blockable with the filtering API they will now also fully control in Chrome.
Google AdSsense has always been able to bypass adblockers, as other advertisers have worked to do. At least in the "they could if they tried", they obviously have the technical prowess. But they haven't because that would be a scandal and invite scrutiny that they likely want to avoid - they own a massive part of the market without resorting to such things, it's not yet in their interest to do that.
So yes, as I said, maybe this is step 1 in a longer term plan to completely remove adblockers. Maybe one day so many people will rely on adblockers that Google is forced to take a drastic measure.
I personally don't expect that to be the case any time soon, but that's really not based on much.
We've been living in a golden age for some time now. We browse the clean, crisp web for free and the ignorant "plebs" pay our way by living in an ad-riddled nightmare.
They would have to be pretty stealth and smooth to pull this off because that kind of behavior would attract even more scrutiny from regulators. They don't operate in a vacuum.
If adblockers can afford to pay for ads, that means they have a business model, and the one and only adblocker business model is "pay to play", where companies pay adblockers to allow their ads through.
Nagware/scareware (pushing subscriptions on users, possibly with misleading claims) is also a business model I've seen used.
I honestly don't mind the "pay to play" model. It's a way to establish a healthy ad ecosystem. Ad blockers define what they consider acceptable, and collect money. They have an incentive to find a reasonable balance: The less restrictive they are, the more money they make, but the second they go over the line, users will jump to another ad blocker that's more restrictive.
I've intentionally and knowingly tolerated the "acceptable ads" from ABP until they started allowing the Outbrain/Taboola chumboxes. (There even were two versions of those, the normal one full of bright colors, tits and disgusting disease images, and a slightly toned down one for the "acceptable ads" users!)
Since those ads rely on making you psychologically uncomfortable (feeling like you're missing out) unless you engage with their worthless, misleading and unsatisfactory clickbait content, they're 100% unacceptable to me, and ABP lost a user.
If uBlock Origin offered an ad whitelist that only allows ad networks that a) serve only their own JavaScript, no third party crap b) only serve static text and re-encoded static, non-animated images c) have some meaningfully enforced editorial standards, d) have some privacy oversight and follow tracking opt-outs, I would definitely give it a chance. I don't mind supporting web sites and content creators, and I don't mind seeing relevant ads (which can usually be targeted based on the content I'm looking at just fine).
I do mind having my fan try to reach escape velocity due to crappy JS, getting served malware and exploits, random "this site is trying to play DRM protected video" popups indicating that something is trying to do fingerprinting, 300 different companies getting my browsing data and 20 of them executing code in my browser (code that they haven't written themselves but have been handed by an intermediary of an intermediary), and last but not least graphic images of diseased body parts. Solve these problems, and I won't need to use an ad blocker. Don't solve these problems, and I will put protecting myself over your revenue.
I also mind having to constantly explain to my parents why the new cool product or shop they saw an ad for is an utter scam, and how exactly they'll lose money if they fall for it. I also mind having to constantly scrape crapware and malware from my friends' and relatives' computers, _including Chromebooks_. As long as ads lead to that, I have no choice but to deploy ad blockers.
> If uBlock Origin offered an ad whitelist that only allows ad networks that a) serve only their own JavaScript, no third party crap
Wait, why would an acceptable ad network have JavaScript at all? Maybe a minimal, pre-approved bit of JS to help the network understand where the ad is being placed, but even that is questionable.
Frankly, I consider it somewhere between bizarre and obviously wrong for any serious website that needs to follow HIPPA, PCI, or any other reasonable security standard to allow un-audited third party JS at all.
The question is: how many people will miss manifest v2 options.
I'm using adblocker written by myself. It's pretty primitive, it uses declarative blocking by URLs and optionally inserts some CSS and JS to selected websites. So far I was able to solve all my ads issues with this approach.
I'm a little surprised Google hasn't seen more pushback from enterprise. I'd expect the weirdest uses of broad permissions to be on intranets, where the inherent risks of such breadth can be mitigated by controlling the accessed data itself. I'm comparing the situation to one of the things that kept Flash on life support for so long: it had been used to build key internal and external tools for fortune-500 companies that they needed time to replace.
That Google hasn't seen such pushback suggests to me that corps writing their own extensions for internal use never caught on like Flash did.
It really depends on the platform and target audience.
For example for a website I manage that targets PC gamers, 80-90% desktop users use adblockers.
On mobile however the majority settles for chrome (which intentionally doesn't support extensions to avoid adblockers), therefore most mobile users don't have adblockers.
The moment I need to deicide between installing UBO Minus or making Firefox my default browser is the moment I make Firefox my default browser. Browsing the internet without a fully functioning uBlock Origin is a nightmare.
First time in a while running Firefox on Mac, and I'm happy to report it finally supports bounce scrolling! In general scrolling is very smooth and performance seems excellent.
Nope, not here. No bouncing, maybe due to 'no animation settings' in display.
Also, scrolling feels different. Different speed, different acceleration.
Something must be wrong on your machine. On my Mac Mini and Air (m1) Firefox scrolling is extremely smooth and feels much more native than Chrome. Overscrolling has worked great since they revamped the engine, even in nested scroll views!
Firefox's scrolling engine is so good, CSS scroll snapping feel more native than Safari's implementation (with chrome feeling the least native - too little friction and takes too long to stop moving on large scroll snap areas) [1].
> Nope, not here. No bouncing, maybe due to 'no animation settings' in display
Where's that setting?
> Different speed, different acceleration.
Huh, interesting! Are you mouse or trackpad? I'm comparing side-by-side on trackpad and I can't detect any difference. If I flick the trackpad at the same speed they will both land roughly in the same place on the page, and the variation, as near as I can tell, is because of variations in my flick speed.
In both Safari and Firefox I find it basically effortless to scroll exactly where I want to. (This was emphatically not true for me in previous versions of Firefox.) Feels totally natural. Though maybe there is a difference I'm just not sensitive enough to detect!
FWIW, I'm on Firefox 104.0.2, macOS 12.5.1, MB Pro / M1 Max.
(Spark, which is a supposedly-native email app, somehow has weirder feeling scrolling to me than Firefox.)
Huh, yeah, turning on "Reduce motion" does indeed disable bounce scroll in Firefox. Definitely a strange choice on their part! (It doesn't affect it in other apps.)
> I changed my system settings, as I don’t like the default speed and acceleration
I see, that could make sense, if Safari was honoring those changes and Firefox wasn't, in some way. I've got mostly stock settings (slightly bumped up speed and three-finger drag) and it feels spot-on.
> Huh, yeah, turning on "Reduce motion" does indeed disable bounce scroll in Firefox. Definitely a strange choice on their part! (It doesn't affect it in other apps.
The current safari bounce effect bounced ALL fixed elements when you bounce the page body. And by copy that. It basically make youtube(or probably any similierly designed website) unusable for anyone have motion sickness. Because the most part of UI is fixed. And hense it is part of "Reduce motion" setting.
Side notes: Safari agreed that bouncing fixed elements is a bug after Firefox implemented it. So this effect will probably be reverted later.
Interesting. OK, so I think two things here, if I understand you correctly:
– Bounce effect IS disorienting for some people in some contexts. Hence the decision to disable it in line w/ "Reduce motion" pref.
– On YouTube, Safari bounce-scrolls the whole page, whereas Firefox just bounce-scrolls the scrollable part. I agree the Firefox behavior seems better here (and it sounds like Safari might adopt it).
It's not a choice.. It's just people trying re-implement "native" behavior.
Doesn't work. Just use native components.
Firefox never felt native. Typography is different from my system settings, window color is different, mouse behavior different, scrolling behavior is different, spacebar to scroll jumps, zoom is weird.. actual size is 125%. So I always have to zoom out a few times to get to 100%, and it doesn't remember those settings.
The only reason I use firefox sometimes is because I can use different profiles as tabs in the same window. For those pesky apps without multi-account / account-member-user schema.
I used to love firefox 15+ years ago.. when I was still on windows, and IE was really bad, but switched to chrome the moment it came out.
It's gotta be a choice, right?, since they're enabling or disabling the bounce scroll based on the pref. If it was just system-agnostic the pref wouldn't make a difference.
My understanding is all of the browsers contain a lot of custom widgets. Like, Safari is not drawing text using NSTextView or whatever.
Looking at Firefox and Safari side-by-side they look pretttty similar to me. Some very slight text rendering differences, and Firefox is maybe a touch less smooth to scroll than Safari. The bounce-scroll is a little bit more stiff.
I recorded a video if you want to see what I'm seeing:
There are so many different widget implementations out there now, maybe I'm just losing my sense of what "native" is. But the scroll physics feel right to me, the text looks right, the text selection and input and shortcuts all work...native enough for me!
Firefox still isn't a suitable Chrome replacement. Chrome may be beaconing half your browsing data back to Mountain View quietly in the background, but Firefox shoves its monetization strategy right in your face every time you open a new tab (Pocket, VPN ads, etc). Firefox is also drastically more complex in the UI and menus, and is missing a lot of UX niceties in the window and address bar itself (extra clicks to search all open tabs comes to mind). Mozilla has no one to blame but Mozilla for where Firefox isn't in terms of market share.
Search all open tabs in Firefox: prefix your search with "% " (percent followed by a space).
Or don't, and it'll probably be in the list of suggested results anyway.
(Unless you're using container tabs, in which case it'll only search open tabs in the current container, which is sometimes good but usually a nuisance.)
I much prefer Firefox's address bar search heuristics over Chrome's, but it definitely depends on your usage patterns. Firefox is very good at suggesting relevant things from my history, to the extent that I will gasp actually close tabs now and rely on search to rediscover them, rather than forever accumulating open tabs that I might want to get back to.
I see plenty of folks in here lamenting this release at all - in the hopes that the lack of it will push folks to Firefox. It won't. Those who care about this are already on Firefox, and frankly - Firefox isn't going to be the answer here (to be clear, this is opinion).
I'm also not thrilled at manifest v3, although for very different reasons than the adblocking limitations - I do lots of extension development, and I think the service worker approach taken is a bad mistake, forcing a distributed consensus model onto extensions without understanding the limitations that model imposes given how often extensions span multiple js contexts (across tabs/frames/content_scripts/windows/etc).
Frankly - the environment is also still riddled with bugs... everything from docs that are wrong, to serious issues like a service worker not activating on simple, basic, required events (like chrome.action.onClicked, which is literally about as basic as it gets for extensions).
Overall - my first impression of the manifest v3 upgrade was fairly neutral (it's not really solving any of my pain points, and it requires a lot of changes to support - but it seemed functional). My opinion after porting several large extension projects to the space is... bad. It's a bad set of changes as implemented in chromium right now.