There's also Brave and Kiwi browser if they disable/limit this api in their extensions there's no stopping Chromium-based browsers from implementing them natively outside of extensions.

Isn't Firefox like much better in terms of the technical side of things i.e. faster, uses fewer resources, has better code inspection tools etc?

Could you explain more about your dislike of Firefox's leadership?

I actually don't switch to Firefox because I'm on i3. I fell in love with surf-like browsing, and am able to somewhat get the same result with chrome in --app mode. There is however no way (to my knowledge) to get tab-less full-window browsing in Firefox.

Do we know that Brave will continue to be immune to this?

The headline is “changes to Chromium,” on which Brave is built...

Your reply resounded with me a little. I agree with the person you replied to, I don't like the UI/UX.

I think it's the 'second level' of UI stuff - menu's behind buttons, settings pages, things like that. I think Chrome does a good job balancing 'advanced user' and 'basic user' stuff. Firefox feels a little too 'dumbed down' for me.

I'm honestly trying hard to put a fine point on it, but it a lot of it just feels 'off'. I'd love a very minimal-design, maximum function look into it.

Firefox doesn't deal with touchscreen and touchpad gestures very well. Take, for instance, the two-finger pinch-zoom-in gesture. Chrom(ium), Opera, Edge, Safari etc. all smoothly and instantaneously magnify the area where the mouse is. Firefox, on the other hand, reflows the entire page with each zoom (as the other browsers do when you do a ctrl +/- zoom), which is inconsistent with how we're used to interacting with touchscreen devices, in addition to being quite laggy on a reasonably modern laptop and tending to undershoot or overshoot the desired zoom level. This zoom behavior is also a lot less useful for looking at a particular item on the page, since the reflow-zoom doesn't seem to depend on mouse position on any way (so any element not at the center of the screen will no longer be visible past a certain zoom level, no matter where you put the mouse pointer when zooming in), which makes using it a lot more frustrating on smaller monitors.

The lack of smooth zoom support has been a known deficiency in FF for the last seven years (https://bugzilla.mozilla.org/show_bug.cgi?id=789906) and has yet to be addressed.

On macbooks for me just the act of running firefox makes the CPU go crazy and the fan turn on. Multiple different years.

On the surface they're quite similar, I agree. I won't pretend that Firefox has some whole separate UX decision process that's ruining it for me. It is, like all decisions between similar products, a matter of my own pet nit.

I dislike Firefox's zooming behavior. I have to zoom into websites because I have poor vision. Chrome's zoom behavior has been extremely natural for me, and easy to adjust to. When I used Firefox I attempted to use 'vanilla' as well as an extension that aimed to improve the zooming behavior by separating scale of text from scale of other elements, etc.

I was unable to find a solution that worked for me. I hated using the extension, which itself had a pretty bad UX, and I couldn't get preferences to save properly for individual webpages.

I can't use a browser with poor zooming behavior, I rely on it too much. As I write this I am zoomed in 250% in Chrome, for example.

Those pet-bugs or pet-nits are, in my opinion, the huge thing that keeps people from moving (alongside the perceived friction of moving data over). I wouldn't read too much into mine.

> I also just compared how both browsers displayed HN main page. Slight differences in color of orange and font weight, but only noticeable if comparing both directly (and besides devs, who does that?).

So on the color thing, one of our designers noticed and I looked into it. Turned out to be an open bug report for Chrome(ium? I forget) where it's using the wrong color profile for css, and resulted in images not matching borders and backgrounds.

Linux, when you have a dark desktop theme, Firefox changes the default and background colors of websites to match, often resulting in black text on black background.

It's infuriating, and the devs say they wont fix it because they expect websites to stop using custom color schemes and respect user desktop themes instead.

So you're getting down voted, but I totally agree. I too used to disable javascript using NoScript every where until it was a site that I was okay with. I played the game of only allowing javascript from the same domain, and then looking at the remaining scripts the site wanted to request. CDNs for jQuery, FontAwesome, etc, started to get whitelisted. Anything else, nope. If the site didn't work after that, then the tab was closed. After allowing NoScript to run javascript, I would then lean on uBlock to block the trackers etc that were loaded by anything I missed. It's amazing how difficult surfing the web like this was.

Maybe if you won’t ever convert, they should simply stop wasting time serving you anything? YouTube isn’t a charity.

They do (well partly), but with network level blocking you end up with broken DOM elements (like images, videos, etc.) The good think about the browser extensions is that they clean up the DOM and in many cases you wouldn't even know if the pages had ads.

Then there's also Javascript trickery loaded with the page that do hostile things if ad servers aren't reachable, and extensions know how to detect and replace them.

I think the closer the blocker is to the user, the higher the fidelity of the blocking.

A browser extension has access to the actual requests, while all a network level blocker has is the Server header of a TLS packet at best, just an IP with SNI encryption at worst. That's why PiHole works as a DNS proxy by only properly responding to non-blacklisted hosts with a proper DNS response, but even this might be useless in some cases due to "domain fronting".

uBlock (and AdBlock Plus) can access and prune/block individual DOM elements, and even has a built-in tool (the eye dropper icon) to select and block them. I think they call it "cosmetic filters". It's also available in the right-click context menu under "Block element".

I don't know exactly how it works under the hood, though. If I block a div with text in it, I know the div is still downloaded, just not displayed. I don't know what happens in more complicated cases, like if I block a div that contains an img tag. I think it's smart enough to prune the img tag before the browser downloads it, but IDK for sure.

I vaguely recall Privoxy having some kind of content filtering, but when I tried it, it wasn't html/css/javascript aware, and only did regex based replacement.

A PiHole only sees the DNS request, which works fine if ads are served from a separate hostname like ads.mydomain.com. But if they're served from the same sub-domain and simply have a different URL (ie, mydomain.com/ads/[...]), then the PiHole won't block it. uBlock/ABP will, because they can filter on entire URLs, not just the domain.

> No ads ever except for YouTube ads lately due to google’s changes to how they serve ads from the same servers they provide services on.

Thats what I meant by network level blocking doesn't work very well. Using uBlock Origin, I don't see YouTube ads.

Of course, but my concern is that DoH makes it easier for apps (Chrome, etc) to handle their own DNS queries internally rather than relying on the device's network libraries.

MiTM intercepting HTTP(s) traffic on my Android devices is really difficult due to certificate pinning. The only way to quantify how many unexpected requests apps are making was to watch DNS traffic. If, one day, these apps just make a single DNS request to Google's DoH host then encrypt all their traffic from there onwards, I'd have no insight into what's going on in my own device.

True, and has ad-blocking built in, so presumably this is an area of focus for them.