Hacker News new | past | comments | ask | show | jobs | submit login
Choose your browser carefully (2021) (unixsheikh.com)
43 points by pabs3 on Jan 23, 2022 | hide | past | favorite | 36 comments



I have mixed feelings on this.

While I agree with the author on many points, this feels like letting perfect be the enemy of better.

Does Firefox have problems? Of course, 100%. Is it much much better than Chrome? Yes.

Let's focus first on the fights that can be won. It's hard enough to get people to switch off of Chrome to Firefox, lets not try to push them to something they've mever even heard of.


I don't like Google, but Chrome is a better browser - especially if you're frontend dev. I'd love for Firefox to be better but it's way slower and its developer console is no match for Chrome's.


Strictly from a frontend dev perspective, sure, also just because popularity alone - but why would you not have a separate personal and development browser? I definitely wouldn't want to mix the two - various comfort extensions mingle with DOM and rendering, and reverse I also don't need analytics/dev extensions clutter/slow down non-dev reading experience.


I vouched for you as I don't think you should be down voted for having an option as a developer.

I don't know why others are disagreeing (I assume this is why they down vote), but I am not fond of your statement because it hits a sore spot for me with web devs and users: you like it because it's convenient for you as a web dev. Chrome is anything but better for me as a user.

I've written something like this before but my frustration with web dev and websites in general is that my understanding is that web devs have an unrealistic expectation for how users use their sites and optimize for a use pattern that doesn't match reality.

I might spend a few minutes on any sight for any given day; typically I'm on a Mac so of course I want safari for the battery life benefits. When I encounter a site that is using some chrome only API or tooling and no longer works, I have a decision to make: do I really want to install another browser to view something I might not even look at more than a few minutes just because the site uses a call only chrome supports? Or do I just want to skip it?

So far, the second option has been my choice every time as I just have not found a site that warrants a dedicated browser to view.

For devs the decision is for their convenience, and because web dev doesn't explain its decision, I just have to live with the consequences. This means that a site that works perfectly fine one day,even sometimes a few minutes ago, suddenly stops working because of a behind the scenes change and I have no idea what the issue is, why a change was made, and for who's benefit.

I am not aiming this post at you specifically, it's just such a perspective I find is unique to web dev and to software with rolling updates, but even the latter has release notes. Web dev is weirdly accountable to none of it's audience, and even worse, many web devs choose to argue against the users choice in browser instead of responding and fixing the issues with specific browsers. I'm not even talking about Fringe browsers, just the major ones (FF, safari,Chrome). Even mobile FF gets broken on some sites that try to use chrome only optimizations

Chrome for users is NOT a guaranteed best option. It lacks battery optimizations on most machines, it doesn't support ublock origin, it is incredibly invasive.

The main frustration i have is that if a site does optimize for chrome, it forces a decision that for me is always the same result: will I install chrome just for this site and give up the benefits of other browsers/pay the Google privacy price?

For me that answer is "No", with gusto.

Again this isn't targeted at you, but I really want to ensure web devs see the user side here and the choice they're asking users to make when they optimize for chrome without considering the experience of other browsers.


I'm struck by your use of the phrase chrome only API. As a safari user, that's a term that comes to you naturally.

As a web developer, I feel like there aren't that many chrome only APIs, but there are a lot of web standards safari doesn't support.

I wonder if our two categorisations have a large intersection.


There is definitely many Chrome-only features. Vendor prefixing before standardization is quite common in CSS land. And each browser makes a choice whether to implement certain JS APIs.

Moreover, Chrome is pushing many new APIs faster than any other vendors can implement. Due to governance changes over the past 20 years at W3C, Google and other user-hostile industry behemoths now more or less control W3C and can push many new specs to be "standardized". But not all APIs are created equal: for example Firefox dropped Battery API support because its only usecase was user tracking, so you can essentially say Battery API is Chrome-only despite being being a standard.

Also, although slightly unrelated, as a long-time Firefox user, i know that for some obscure reasons some websites don't work in Firefox, and that Google apps sites are known to act slower when presented with a Firefox user agent. I'm also old enough to remember that when Chrome came out (oh, i miss you pre-Chrome web) Google *paid* website operators to include Chrome advertisement and to make their demos only work via Chrome (once again, via user-agent filtering not via actual features of Chrome that would not be available on other browsers).


I can appreciate that, but my counter is simple:

It worked before, and I have no idea why changes need to be made that aren't universally supported; as a user there is no benefit for me that I'm aware of, and no site to my knowledge deigns to tell me otherwise

That's my point; it worked, then it didn't, and the argument is "get a different browser" (usually they say better). But the question is why did this change need to happen in the first place? Why do I need to change when it's clear that the functionality __IS__ possible with my browser.

It's not about what my browser of choice does or does not support, it's that I'm being told I need to change browsers for functionality that worked perfectly before, and I have no idea why, and instead of being told why, I'm told how awful my browser of choice is despite the benefits it has that I use it for.

I'm sure there's a reason for such changes, or at least I hope there is. But I've never seen a site that ever explained __why__ this was such an essential change that breaking compatibility was an acceptable cost; I'm just told my browser sucks, which isn't compelling.

Edit: to add, I want to stress that it's not a choice for users between browsers that support certain developer features and web features; it's a choice between which browser you spend the majority of your time in for __all__ sites at all times.

When 99.9% of the sites you use daily or weekly work without issue and just one you visit decides to make a breaking change to do the same thing that worked before, it's a very hard sell for me to accept that the browser I'm using is in the wrong. I balancey choice against the benefits my browser of choice does give, the costs of installing another browser, and how much time I really spend on the given site. I know I'm a minority in that I don't use chrome, but the entire issue is unrelated to that; it's about making breaking changes and not explaining any good reason for it, and instead just blaming the browser. If there was even some explanation, at least we could have a discussion on the value of the change.

But missing that, I just see "it worked, not it doesn't, and the functionality is the same. What is the benefit for me as a user?"


> I feel like there aren't that many chrome only APIs, but there are a lot of web standards safari doesn't support.

It may be a de jure standard, but that doesn't sound like a de facto standard.


I agree with you on everything you wrote, thanks for taking time to explain it.

The situation is not great, it's true that for regular users Chrome is basically spyware and battery drain.

I've been waiting for Mozilla to create a better webdev console (or even copy Chrome's) and I'd move instantly.

I do use more than just Chrome (ungoogled Chromium, Edge, Firefox) and I also experience the "regular user" problem when a site is fine in Chrome but not in Firefox so I'm split between two worlds as well, and believe me - I feel your frustration.


You're very welcome. Vouching again as I have no idea why you got down voted.

I really do feel bad that your post was a vaulting point for me to rant, but I do get why a developer would want such things.

I'm not a web dev, so for me, it's just about the user experience and privacy (which as the article shows, no major browser does well out of box).

I'm not Meaning to be hostile towards web dev, but for my company's product, we try to be very transparent about breaking changes. Most software is. Linus even was specific about "don't break userspace".

Thus it's a sore spot for me that web dev bucks the trend here and the answer as to "why" is really not clear for me. Rolling update software is equally guilty here but at least you usually get patch notes...it's still bad in my opinion, but at least you get some idea what's going on.


Funny enough I have to reach for Firefox when debugging some frontends because Chrome devtools don't always keep the payload. FF does.


Ugh, yes. Firefox's dev console is such a pain.

Not only is it painfully slow compared to Chromium, but it sometimes will break on "phantom" breakpoints which cannot be seen or removed, which completely roadblock further work until the browser is restarted.


What's better about chrome's console?


Falkon hasn't been updated in nearly three years, and I really hope this doesn't mean it has been abandoned, because it's one of the few "just a browser"s left. It's not a "service", it doesn't call home, it's... just a browser, and it's a real shame that it is not the default for most Linux distros.


Falkon is not a top browser so of course it's not going to be the default choice for Linux or any other operating system.

Linux users today are using the same apps people use on Windows or Mac OS. We just have so much more choice and much less annoyances. For example, our operating system is silent in the background doing its job.

There is a stillness and a quiet quality to Linux that the other operating systems don't have at all.


None of the things you mention should have any bearing on a distro choosing its default browser.

If you want "stillness", whatever the hell that is, a browser that does not come bundled with a cloud service seems like a winner.


Regarding "Ungoogled-Chromium":

> "The binaries are provided by anyone who are willing to build and submit them. This means that authenticity cannot be guaranteed and there is always a risk that the binaries may have been tampered with"

This does not seem (entirely?) correct, builds seem automated: https://github.com/Eloston/ungoogled-chromium#automated-or-m...


I didn't read the article thoroughly, and parts of it I only skimmed, but I kind of get the feeling that, for some of the issues he addresses, the author's great conviction might be a bit stronger than his actual arguments or information.

For example, with regard to Mozilla's use of Cloudflare's DNS over HTTPS and their agreement regarding logging and privacy, he writes:

> Anyone who has worked with DNS servers knows what goes into such logs and in order for Cloudflare to keep their promise they need to: Delete the DNS requests information, but at the same time somehow still keep "anonymized" logs of the total number of requests, a list of all domain names requested, a so-called "sample" of complete DNS queries along with date and time.

I don't see how those are contradictory (except possibly for the last one, depending on what "complete" means). I don't know how DNS logs are stored but it should be entirely possible to first aggregate information and then get rid of the logs. Some other information might be harder to maintain an aggregate of after getting rid of the source data, but it's often more or less possible, and total counts of whatever should be trivial.

I'm not saying he's wrong; I'm just saying I get the feeling he might not have quite as strong a case for some of the many issues he brings up as his aggressive tone makes it sound.


What about Safari? Yes it's closed, and right now has a pretty severe bug related to IndexedDB and sandboxing. Webdevs (or is it a concerted effort in disguise?) complain about Safari not being the most aggressive in terms of JS API support, but this is a good thing in terms of privacy isn't it? The deal being that Apple, unlike others, has no stake in "telemetry" aka privacy invasion.


Safari doesn't even meet the most basic requirement for a web browser: Support for uBlock Origin. If Apple cared about privacy, they would support uBO.


I'm using uBO with FF right now, and have used and enjoyed FF mobile with uBO back when I was using Android, but the issue being discussed here isn't ad blocking but privacy.


Ublock origin is about privacy, not just ads.


Privacy violations on the internet are almost always related to AdTech.


To run Safari, you need to use a closed/"untrustworthy" OS. That automatically disqualifies it from the basic criteria laid out by TFA.

> I will also not be looking at browsers that only work on Microsoft Windows or macOS, even if they are Open Source. Both Microsoft Windows and macOS are highly controversial and completely untrustworthy operating systems.


If you use a Mac, Safari is absolutely the right choice. But for all other platforms, it's simply not available.

(It was briefly available for Windows, in an apparent quirk of history, but was discontinued in 2012.)


Apple has no stake in telemetry that you know of



Good point, I had forgotten about that!

And obviously they collect data and essentially make a pinky promise they are not using it.


Recently I’ve had time to look at this myself properly. Just like the author, it seems that a modified Firefox is the best compromise. It comes with its own hassles, though... Remembering what one changed, manually installing extensions, and what not. Rinse and repeat for every new install.

What I’ve ended up with, which I can highly recommend for anyone who’s not satisfied with just Firefox or ungoogled-chromium, is to make a self-compiled bundle with all customizations prepared out-of-the-box. I am certain I’ve already effectively saved time through this.

This is a lot more natural if you’re using a distro where this is normal and there are already build setups provided (Arch/NixOS/Gentoo) or you’re already used to this.

A great starting point for those on Arch is to clone this AUR PKGBUILD [0] (which also documents and sidesteps the somewhat daunting setting up of a proper FF dev environment) and customize it accordingly. At minimum you probably want to change the search engine and bundled extensions. You could even self-host the fxa stack and switch over from accounts.mozilla.org if you want sync capabilities without leaking data to third parties.

I went as far as self-building and self-hosting all my add-ons as well (which just requires a place to put the XPI files), removing any in-extension calling home and banners, changing some icons to fall in line with my color scheme etc.

You could do the same with in googled-chromium if that’s your preference. In either case, both u-c and Librewolf are patch sets on top of upstream chromium/FF, so staying up to date with security updates shouldn’t be an issue.

[0]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=fired...


For an article supposedly about protecting your privacy, it's very weird to see the author's opposition to DoH. The only evidence given are the "Criticism" section of the wiki article on DoH (which no longer exists, apparently), some blog post and a Reddit comment with few convincing arguments (no, pointing fingers at SNI and the like isn't gonna cut it).

DoH has issues but is overall a net positive and step in the right direction, and you have the freedom to set the DoH server to whichever you think is less evil, but to go as far as to block it is just strange.


I agree DoH has strong benefits. However, should your web browser (or any specific app for that matter) have its own resolution settings? What about split-horizon DNS on your LAN? What about cache/latency when your uplink to CloudFlare is really bad (as in many so-called developing countries)?

I'd be much less concerned if Firefox gave users an explicit choice about this: "Your Internet provider may be censoring/monitoring domain names. Would you like to keep it, or use a slower secure tunnel to one organization in the list below? Note that local-network services may break due to using an alternative."

Defaulting to CloudFlare is a joke. Just like telemetry has not helped Firefox improve in significant ways from my perspective as a user. Just like using Google Analytics on Mozilla websites was always hypocritical. Just like integrating more cloud services (Pocket, Sync, VPN) into Firefox without worrying about how to make it practical to selfhost is helping the web move in a bad direction.

I have much respect for Mozilla devs, but being run by corporate executives not the community has definitely killed Mozilla's mission. I'd be much more inclined nowadays to trust a non-profit where each employee has equal pay, team management is done or elected by the team and overall governance is left to the community. I just don't know of any browser vendor that suits the bill.


Mozilla has a special agreement with Cloudflare to resolve DNS queries without logging anything, so that's not an argument against Firefox


Did you read the article? Or do you dispute its points?

> Anyone who has worked with DNS servers knows what goes into such logs and in order for Cloudflare to keep their promise they need to: Delete the DNS requests information, but at the same time somehow still keep "anonymized" logs of the total number of requests, a list of all domain names requested, a so-called "sample" of complete DNS queries along with date and time.


Maybe true but how can you audit this?


> People are being mislead by the empty promises of privacy. Brave not only also "phones home" but as soon as you fire up the browser it starts contacting Amazon.

And suddenly forgot about the proofs.


It is an extremely thorough walk through of a lot of browsers. But in reality it is only very very very few browser users that has the skill and patience to follow all these very good advices. So I think a better way was to go in the same direction as with GDPR where you should give consent to being tracked. And if you had not - the tracking company should be fined. Some of the fine should be rewarded to the user. This would have the effect of possessing user data could be very expansive and a thread to the company.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: