“UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3
github.com
github.com
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.
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?
If you're relatively familiar with web development in general - you can just peruse the APIs that are available for extensions
Chromium based: https://developer.chrome.com/docs/extensions/reference/
Or for Firefox: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
Then hit the MDN "My first extension page" to get a mostly functional manifest file: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
Get familiar with `about:debugging` in firefox, and `chrome://extensions` in chrome - you'll need them to load your test extensions.
Finally - It's very worth it to read and understand the "core concepts" as outlined here, starting with the content_scripts: https://developer.chrome.com/docs/extensions/mv3/content_scr...
And check out the companion extension: https://www.buildingbrowserextensions.com/b2x
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.
uBlock Origin already blocks a lot better on Firefox than on Chrome.
https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
Even if the new version works now, Google are clearly going to tighten the vice over the next few years.
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.
Either way, very thankful to the developers and community for making our web browsing experience so much better.
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
(plus my phone is falling apart, and I don't want to give Google another penny after their manifest v3 behaviour)
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.
I also use a Pixel phone, though I use LineageOS so I feel less tied to Google
On android I use either Brave or Samsung Browser.
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.
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.
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.
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.
There are browsers for iOS with really good ad and tracker blocking. I use Orion, whose blockers are based on uBlock.
I forgo the on-device ad-blocking and use DNS blocking. It's a decent catch-all for most things I'm worried about.
NextDNS is one of the better hosted DNS blocklists, IMO
Kind of. See the setup section: https://www.quippd.com/writing/2022/01/26/most-wanted-add-on...
The grassroots push that dethroned Microsoft's browser was Google's browser (aided by Firefox's suicide.)
Originally, it was tabbed browsing, which Opera and Mozilla had ~5 years before IE. Yes, Microsoft sucked that much in those days.
With Chrome, it was an embedded PDF viewer and V8 performance.
So essentially, mostly people don't switch browsers unless there's a very good reason to do so.
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.
Anyway, if google started pushing firefox the way it does and has pushed chrome, I think that number would start moving pretty fast.
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.
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.
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.
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.
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.
https://www.ghacks.net/2020/10/01/you-can-now-install-any-ad...
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.
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.
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.
Was it really?
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.
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.
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.
That thought experiment will help extrapolate the far-out future for both companies and the version of the future they are building towards.
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.
It's not a panacea, but it's about as close as they come.
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 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.
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.
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.
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.
Just to note, There's a full-desktop Firefox available with mobile layout in PostmarketOS for Linux Phones. Here's the device I drive daily[1].
[1] https://wiki.postmarketos.org/wiki/Xiaomi_Poco_F1_(xiaomi-be...
Full-fat Firefox felt surprisingly usable on Pinephone under Phosh though.
Even then: Fennec F-Droid is a compelling choice. It has a pretty good mobile experience.
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.
I switched from the Safari on MacOS for just the same reason even though I lost things like ApplePay etc.
I am not giving up on uBlock. The web is too bloated and unusable for me without it.
I don't think that's true. Many, many more people would care immensely 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.
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.
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...)
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.
Most of them will not.
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.
Ad companies will never allow this because it makes click fraud very easy.
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.
https://bugs.chromium.org/p/chromium/issues/detail?id=115225...
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.
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 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.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.
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?
As for the other, here you go: https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss...
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.
* * *
[1] https://github.com/gorhill/uBlock/wiki/Per-site-switches#no-...
[2] https://github.com/gorhill/uBlock/wiki/Quick-guide:-popup-us...
[3] https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-qu...
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.
See https://github.com/google/google-api-javascript-client/issue...
Chromium bug marked WONTFIX: https://bugs.chromium.org/p/chromium/issues/detail?id=116445...
Updated readme: https://github.com/google/google-api-javascript-client/blob/...
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.
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
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.
Feel free to be in denial about why those crippled APIs have come to be.
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.
The logical strategy is to extinguish. They never embraced or extended it.
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.
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.
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.
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.
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.
* * *
[1] https://developer.chrome.com/docs/extensions/mv3/intro/mv3-o...
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.https://blog.chromium.org/2020/12/manifest-v3-now-available-...
> 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.
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.
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.
[1] https://blog.mozilla.org/addons/2021/05/27/manifest-v3-updat...
> have decided to […] continue maintaining support for blocking webRequest
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 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.
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.
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.
You've reached an incorrect conclusion.
>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.
Your link is about dynamic filters. My comments are not.
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.
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.
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.
if gorhill simply refused to release UBO for manifest V3 then someone would, and release something similar without the negative branding
(plus eyeo crapware "ad blocking" extensions would gain market share)
this way the users are being reminded that on Google's platform you're getting an inferior blocker
Sadly, this is likely not to happen, as every newsroom relies on online ad clicks for a revenue stream...
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.
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.
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 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.
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.
Get rid of that wheelchair, just walk like a normal person!
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.
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.
Practicality cares not for ideology.
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.
(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.)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
About 43 %, according to [1].
> 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.
Even to install on Android Firefox it took more effort than I expected.
The only thing I actually have to start Chrome for is (ironically) Microsoft Teams.
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.
42.7% of internet users worldwide (16-64 years old) use ad blocking tools at least once a month.
That framing sets of multiple mental alarm bells.EDIT: it looks like the source is HootSuite may have a conflict of interest, as they seem to focus on social media advertising campaigns.
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.
So... thanks Google I guess ?
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.
I hope it doesn't affect FF users, and uBlock Origin will continue to function same as it always has.
Fresh info regarding mv3 & FF:
https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi...
This is why I became a tech person. Incredibly inspiring.
While still using the best engine out there, chromium.
"We will continue to support Manifest v2 to the extent that we can"
"Brave's adblocker (Brave Shields) is not an extension, and is natively implemented. So, it will be totally unaffected."
Source: https://www.reddit.com/r/brave_browser/comments/rdab12/how_w...
Brave's built-in native adblocker also definitely won't be affected, as it doesn't use any webextension APIs at all.
[1]: https://github.com/uBlockOrigin/uAssets/discussions/14544#di...
https://github.com/brave/adblock-rust
I'm pretty sure it's also faster than any adblock extension like uBlock.
Still doesn't feel native at all.
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.)
I’m on M1. Just updated FF from the menu.
I’m using the trackpad, but again, I changed my system settings, as I don’t like the default speed and acceleration.
> 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.
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.
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:
https://www.youtube.com/watch?v=-lkAy0O5EDs
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!
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.
– 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).
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].
[1] https://ppg.report/41.876,-87.624 for example of CSS scroll snapping that performs best on Firefox on Mac
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.
> Mozilla has no one to blame but Mozilla for where Firefox isn't in terms of market share.
I think you should read up on how Chrome was/is advertised, how is pushed to users and what marketing channels and resources Google has.