Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

First, FF is less secure than Chromium-based browsers so not sure what you meant there. Just have a look at the results of the various browser hacking competitions. This has been a consistent result for decades. FF security out of the box has also been inferior to Chrome’s. In some cases it’s been more readily exploited than Safari, which is saying something.

And as for customisation, that’s actually been eroded over the past 3-5 years in FF compared to, say, 10 or 15 years ago. For example, I can remember a time when the interface itself had the option (a checkbox) that miniaturised the icons of the entire search bar UI - this has been gone for years and there is now no way to change that without installing an entire theme. Now every user is stuck with the same general interface/UI spacing.

I’ve used FF since maybe 2008 and in my experience it’s never been worse than it is now in terms of performance, its interface customisability, and its benefits vs its largest competitor. If I end up using it as my primary browser it will be because of Google’s insanity with adblockers, not because FF itself is a good alternative (indeed it’s just that FF is the ONLY alternative).



> FF security out of the box has also been inferior to Chrome’s.

Privacy with Firefox out of the box isn't that much better than Chrome’s either, but what sets Firefox apart is that it can be very effectively hardened. At work I deal with all kinds of compromised and malicious websites and nothing beats Firefox once you've got it locked down.

> I’ve used FF since maybe 2008 and in my experience it’s never been worse than it is now in terms of performance, its interface customisability, and its benefits vs its largest competitor.

It's gotten more difficult to customize firefox over the years for sure, but what competitor offers better interface customizability? What can you customize in Chrome that you can't in firefox? What's chrome's equivalent to userChrome.css? Check out https://old.reddit.com/r/FirefoxCSS/ for examples of what you can accomplish.


You are absolutely correct that Firefox is more customisable than Chrome, but my point wasn’t to compare the two on that front, but to make the point that the original comment - which spoke of FF’s ‘commitment’ to ‘customisability’ - is nonsensical. That commitment may have been a real thing a decade ago, but it hasn’t been around for awhile.


I do wish they'd lean into it a bit more these days. Updates tend to break a lot things for people who have taken the time to set things up how they like them. I know that can't always be avoided, but it'd be good if they tried and kept the ability to make such customizations in mind as they add new features.


You can’t leave it at that. What do you do to lock down FF?


We've got a document that outlines easily over 100 changes in about:config that need to be changed and locked (new ones are being added all the time), Nearly everything with a URL gets pulled out of the settings. Pocket is disabled, default plugins and the extensions that get installed for you automatically like screenshots@mozilla.org.xpi and pictureinpicture@mozilla.org.xpi get deleted, and we add noscript/ublock origin

The idea is to reduce attack surface as much as possible, and disable features like searching/calculating from the address bar, service workers, wasm, prefetch, webgl, redirects, the PDF reader (no files ever just auto-download or open in anything by default), Firefox View, webrtc, network prediction, the social API, reader mode, there's some stuff about certificates, TLS and SSL etc.

There's also a section for preventing fingerprinting, disabling telemetry/reporting/safebrowsing, all the stuff here: https://support.mozilla.org/en-US/kb/how-stop-firefox-making... and to keep changes from being made so no auto-updates, and experiments/normandy/shield studies are disabled.

There are a bunch of guides to harden firefox online, and ours seems to be some combination of several of them. The Tor browser guys do some great work keeping an eye on some of the changes that get made.

In the end basically no active content of any kind is allowed by default. Some sites don't work at all with this stuff turned off or removed and it's a bit too locked down for day to day use but I'm surprised and how often things work well enough to get what you need at least. For example, an article might load just fine, but site navigation will be broken which isn't really an issue if you just wanted to read the article.

Most of the sites that will get you infected just by visiting them require JS, so disabling that alone helps a ton. For something you know is really evil it's often best to just download and analyze the site offline, but for poking around even in highly questionable places it's pretty nice.


Thanks for the reply!


Chromium is the only browser that has security and privacy nightmares including Web USB [1], Web Bluetooth [2], and the Battery Status API [3].

I'd rather stick with Safari or Firefox.

[1]: https://caniuse.com/webusb

[2]: https://caniuse.com/web-bluetooth

[3]: https://caniuse.com/battery-status


You just quoted 3 purely hypothetical exploitable features vs, say, Chrome consistently being the last browser standing at PWN2OWN over the past 10+ years (and Firefox is usually the first to fall). I’ll take real world practical protection over theoretical attack surfaces every time.


Chrome serves you up on a platter to Google and advertisers while admittedly being pretty good at protecting you from everybody else.


Advertising has nothing to do with security exploits.

Clearly we’re talking about browser exploits in this particular line of comments, not privacy, and with exploits so defined Chrome is far superior to FF.

Most people here who use a Chrome based browser would almost certainly use a Chromium derivative anyway, like Brave.


> Clearly we’re talking about browser exploits in this particular line of comments, not privacy

You could've re-read the thread before posting such an obviously false comment.

Here's the first mention of privacy and security in this thread:

> I think firefox focusing on performance, customization, and security/privacy is smart.

I also heavily disagree with your view that spyware has nothing to do with security, and your extremely narrow view of what counts as security exploits. The Chromium specific APIs are riddled with security issues as I mentioned in my other reply.


Hence why I said 'this particular line OF COMMENTS' and not 'this thread'.

Security and privacy are not the same thing, nor are they directly related. Lack of privacy can literally be designed into a secure system, which is one way of describing how Chrome works. It doesn't really matter how you choose to esoterically define the words if everybody else's meaning is different.

When people talk about Chrome being secure, they're talking about the browser's resistance to being compromised by a third party. It's that simple. Nobody cares that you have some esoteric view whereby Google's inherent lack of privacy protections, wherein Google is able to collect information about the user through their browsing habits, is also part of the browser. That is a matter of privacy, not security, and Google very clearly sets out all the ways it collects information about the user in its various policies. Security relates to whether third parties - using the browser architecture itself as a conduit - are able to compromise the browser in such a way as to obtain or manipulate user information, data, or elements of how the user interacts with the system, in a way that is not approved by the user and about which he is likely unaware. Every user of Chrome agrees to Google's collection and use of certain data, and ergo such data collection does not involve security issues whatsoever. That you might disagree with Google's privacy policies is not to the point. Note that if the aggregated user data were to be surreptitiously accessed by a third party, this WOULD be a security issue - but that isn't what we're talking about, is it?

If talking about security, Chromium has been the most secure browser for at least a decade. Safari and Firefox are significantly worse at security than Chromium browsers are. That's not really debatable - just go look at results of the various hacking contests, look at the number of active exploits and how long they are in the wild and unpatched, etc.

On privacy, Firefox is undoubtedly better, although Mozilla has had snafus over the years. Mozilla also literally makes something like 99% of its revenues through agreements it has with Google search, so go figure.

One final note - as has been the case for at least 15 years now, Firefox with uBlock Origin and NoScript and a few other addons are probably the most secure you can get, albeit at significant cost to usability and convenience. When discussing security I think it's inherent that people are discussing the vanilla, out of the box install of a browser. Having said that, I currently use Brave and find it to be the best mix of features of Chrome without the rest of the Google privacy problems; despite being a very long time Firefox user, it just isn't good enough these days, although if Google succeeds in killing adblockers in Chrome I'll have to move to Firefox regardless.

Good day.


You're literally the only person in this thread trying limit the conversation to browser exploits. So your choice of wording doesn't make it any more true.

> Note that if the aggregated user data were to be surreptitiously accessed by a third party, this WOULD be a security issue - but that isn't what we're talking about, is it?

But we are talking about third parties gaining access? The mentioned Web APIs are intended for use by third parties. It's not even aggregated user data, but individual ones.


It's not "purely hypothetical." It's reckless and irresponsible of you to spread misinformation like that based on wishful thinking.

WebUSB made it possible to work around Yubikey phishing protection [1]. WebMIDI allows websites to overwrite device firmware, which is a dangerous capability that could result in a sandbox escape [2]. Granting a website WebNFC permissions makes it possible to read TOTP tokens stored on Yubikeys at any point later on [3], which is worrying because ordinary users can't possibly deduce that from permission prompts. Battery Status API was heavily abused for fingerprinting by the time it was removed from Firefox [4]. I'm amazed that you dismissed that as a "hypothetical" concern, because if anything, it's the legitimate uses of the API that was hypothetical [5]. Uber used it to "inflate Uber prices for desperate users with low batteries." [5] [6].

But one don't even need theses examples to see how bad theses APIs are. Hardware are mostly designed to work with local applications. To expose them to websites is a fundamentally flawed idea. Google justifies them by adding permission prompts each time a problem emerges, but users can't possibly be expected to be fully aware of the consequences of allowing raw hardware access to websites with mere dialogs that they blindly click through.

And oh I wish there were only 3 bad APIs like you hinted. There are more than that. WebMIDI, WebNFC, WebSerial, WebHID, Generic Sensor API, File System Access, Low-level Sockets API, Network Information API, and the list goes on.

These aren't isolated examples. It's part of a broader pattern where Google ships an anti-feature, asks for "feedback" which means nothing because "devs already depend on it," and "standardizes" it despite opposition from the remaining browser vendors [7] [8].

I’ll judge browser security based on a broad set of examples rather than a cherry-picked one every time.

[1]: https://www.wired.com/story/chrome-yubikey-phishing-webusb/

[2]: https://github.com/mozilla/standards-positions/issues/58

[3]: https://github.com/mozilla/standards-positions/issues/238

[4]: https://www.cs.princeton.edu/~arvindn/publications/battery-s...

[5]: https://groups.google.com/g/mozilla.dev.platform/c/5U8NHoUY-...

[6]: http://www.forbes.com/sites/amitchowdhry/2016/05/25/uber-low...

[7]: https://github.com/mozilla/standards-positions/issues/459

[8]: https://twitter.com/rich_harris/status/1220412711768666114


If a particular feature is controlled by a permissions prompt, saying that 'users can't be expected to be fully aware of' the consequences of a particular permission edit has, once again, nothing to do with security as everybody in the world besides yourself understands that term. Criticise their UI team, perhaps, but such a problem has nothing to do with security - indeed the 'feature' might be working exactly as intended, notwithstanding the (in your view) unclear wording obscuring it.

At this point I can only assume that your conflating of security and privacy is pathological, and I very much doubt that we can have a fruitful discussion about this.


Take WebMIDI, for example. A website using it would show the following permission prompt in Chrome:

    example.com wants to

    Control and reprogram your MIDI devices (SysEx)

    [Block] [Allow]
According to you, everyone should understand that term to mean example.com can access their device to overwrite the firmware of a MIDI device, turn it into a keyboard, and take full control of the computer. It's feature working as intended and no security issues are involved.

I am so glad both Apple and Mozilla doesn't subscribe to you or Google's definition of "security." These gaping security holes can cause so much damage, and to see these as "features working as intended" shows how disconnected you are with actual users. Even the infamous ActiveX would not have security issues if we redefined security under your terms. A browser should never ever include capabilities for full system compromise as one of its features. No permission prompt should ever let that happen.

You also need to consider the inherent danger of exposing hardware to websites when considering whether permission prompts are adequate. Again, hardware aren't designed with the expectation that they'll be exposed to websites. Browser vendors can't possibly be aware of the security implications of doing so for every device out there either. That was one of the core arguments of my previous reply and I wish you hadn't omitted that. Unfortunately, my point about the permission prompt was taken out of context and spun into a "pathological" view that "everybody in the world besides myself" would laugh at.

Lastly, you might want to actually look at the examples I posted. Some of them don't or didn't involve permission prompts and enabled attack by third parties. Which I believe to be a security issue even under your terms.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: