Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trading Security for Privacy With Firefox #52

Open
Bazza-63 opened this issue Sep 24, 2024 · 2 comments
Open

Trading Security for Privacy With Firefox #52

Bazza-63 opened this issue Sep 24, 2024 · 2 comments

Comments

@Bazza-63
Copy link

Firefox has poor security, even "hardened" Firefox has far to many attack vectors. You should probably put a disclaimer that if you're using Firefox you're trading security for privacy (which Chromium browsers can match anyway).

Have a read of this:
[https://madaidans-insecurities.github.io/firefox-chromium.html]

Also turn on CRlite in Firefox as OCSP will leak your connections.

@avoidthehack
Copy link
Owner

Hey, thanks for opening an issue.

You should probably put a disclaimer that if you're using Firefox you're trading security for privacy (which Chromium browsers can match anyway).

The table is not meant for that type of analysis.

With that said, even though I have open bias towards Gecko (not necessarily Firefox of itself), that source seems a little bit dated. I just want to highlight a couple of things.

For example, Win32k, x11, and untrusted font blocking issues have been fixed for at least a year or two. Fission addressed a lot of the documented sandboxing issues Gecko/Firefox had, though because of the sandboxing model difference (especially on Android), it is still weak on Android in particular. There, I would recommend against using Firefox or any Gecko-based browser.

But not here, as the table isn't really meant for that.

The JIT section confuses me. V8 (Chromium) is routinely exploited in the wild to leverage memory exploits.

The rewrites of certain components in Rust in Gecko/Firefox shouldn't be downplayed. Sure, Firefox isn't completely written in Rust but Rust is more memory safe than C++ and of the components that have been rewritten in Rust, they seem to carry their weight in mitigating potential vulnerabilities in the source. (Your source even links to Mozilla's Oxidation page in the argument about Rust, which kind of undermines their own point made in the section about memory safety. But again, it seems dated, so perhaps they haven't updated it.)

Google has admitted most of their security vulnerabilities derive from memory bugs. This tracks with the known exploited vulnerabilities (use-after-free, buffer overflow, out-of-bounds reading/writing) in Chromium found in the wild. But even because of this, I wouldn't go around saying "Chromium is insecure-by-design."

In the end, what I am trying to say that the analysis of using Firefox does not necessarily equal "less security" over Chromium. Are there things Chromium does better? Sure. Are there things Gecko does better? Sure.

Overall, that page seems to cite a lot of attack vectors that just aren't that common or observed in the real-world. This doesn't invalidate them, but it's important to keep threat model in mind.

If the downsides of any browser really break your threat model of give you that much concern - even if adhering to good security hygiene like not clicking on unsolicited links/downloading suspicious files, keeping your software updated, etc - then you may want to consider other methods such as using Tor (with good opsec) or using a VM to browse the internet.

If not these, then disabling JavaScript (because this is where many exploit attempts of the browser begin) - but that makes the web unusable for many people.

Firefox you're trading security for privacy (which Chromium browsers can match anyway).

Not necessarily true. Base Chromium's source code is heavily integrated with Google's infrastructure and requires extensive modification to "remove," unlike Firefox. Sure, Firefox comes with telemetry (and recently, PPA) enabled... but it can be disabled "easily" (typically poking around in the advanced about:config settings) Look at the arkenfox project.

A lot of this integration cannot be simply disabled by toggling controls in Chromium; it generally requires modifying the source code to either disable/modify certain options or features. Most Chromium browser forks are still heavily integrated with Google's infrastructure.

The only exceptions I am aware of that either manage to disable Google-dependent services/components are Brave, Microsoft Edge, and the Ungoogled Chromium project. This is all while integrating security fixes from upstream and addressing any regressions.

@Bazza-63
Copy link
Author

Bazza-63 commented Dec 9, 2024

I think Cromite for Windows has google services disabled

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants