Mull / Hardened firefox security?
locked Did they state that it was unsafe?
They said:
GrapheneOS Bromite is an insecure, dead project and we recommend against using Cromite since it rolls back security and adds a bunch of questionable changes. It's also not a trustworthy project. It may be marked with a warning in the future.
Cromite makes a lot of choices that make it a subpar choice, and in my opinion, doesn't prioritize security.
Some examples of this:
- Addition of JPEG-XL, which is a lot of additional attack surface over Chromium.
- Addition of Eyeo's adblocking engine, written in C++ (memory unsafe). Eyeo is the company that bought "uBlock" (not uBlock Origin) and does "acceptable ads". Their code contains tracking that the maintainer of Cromite has to remove. Missing something there wouldn't be good. It's a very strange choice to add to the browser.
- Cromite does not support CFI. It used to, but then it broke, and instead of fixing the issue, they simply stopped using it.
- Of course, they also don't use MTE, which Vanadium does on devices supporting it.
Cromite is the successor to Bromite, a now-dead project that changed its licensing to GPLv3 and wouldn't share patches with Vanadium despite taking from it. All in all, I personally see no reason why it's so widely recommended in so called "privacy circles".
- Edited
matchboxbananasynergy they're all choices one makes when deciding in a browser to use for whatever task they choose.
I was more referring to the 'untrustworthy' label the project was designated by GraoheneOS a couple of comments ago. Its one thing having and opinion of unsatisfactory security, totally another to be deemed untrustworthy in general. I just really wanted to know why they're apparently untrustworthy as a whole.
Just to edit, I'm not arguing or making any point. I use Cromite for one aspect of my browsing and I am surprised by the designation.
mmmm Taking from Vanadium while preventing sharing code the other way is trustworthy behavior to you? The person behind Cromite was with Bromite too, although not the main person there. They can't do that anymore due to Vanadium being licensed GPLv2 now, but they do still have Vanadium patches in their browser, of course.
Being okay with groups that have been hostile to GrapheneOS numerous times in the past is also something we're unlikely to consider trustworthy, too.
matchboxbananasynergy Taking from Vanadium while preventing sharing code the other way is trustworthy behavior to you?
Was that a licensing issue?
matchboxbananasynergy Cromite does not support CFI. It used to, but then it broke, and instead of fixing the issue, they simply stopped using it.
Of course, they also don't use MTE, which Vanadium does on devices supporting it.
Tbf no Chromium browser outside of Vanadium and Mulch does that on Android
- Edited
matchboxbananasynergy Taking from Vanadium while preventing sharing code the other way is trustworthy behavior to you?
I suppose not, from the projects point of view. But from a users point of view I dont see how its particularly relevant. Trustworthy from my point of view, with regards to a browser, is whether they're looking at what I browse, or logging my location, or helping profile me. The 'underworld' of open source coding ethics aren't really my forte, and i guess if i looked that deeply, 'untrustworthy' would take on a new meaning.
But yes I get your point. Thanks for clarifying the reason as to why it should be avoided from the projects point of view.
I dont think it will stop my minimal and particular usage of Cromite.
Edit to add, I am in the habit of having separate browsers for separating things. I have worked that way for years and you cant teach old dogs new tricks. I use several browsers to achieve this. However if I could have multiple instances of vanadium and mulch, I would ditch everything else!
- Edited
mmmm They said it was not trustworthy, which I would define (in this context) to mean the developers are not trusted to make good security or privacy implementations to the cromite browser. Don't confuse that to necessarily mean unsafe. It does not meet GrapheneOS's security standards. Some reasons have been listed below...
TheGodfather Cromite makes changes which significantly reduce security, and most of their privacy changes are highly questionable.
@AlphaElwedritsch Your reply has been removed because you're citing a site full of false marketing claims and misinformation to promote a highly insecure product. Those folks are heavily involved in attacks on the GrapheneOS project through spreading misinformation about it and engaging in harassment targeting our team. Stop promoting it if you want to participate in our community.
Aside from that, GrapheneOS is not a "custom ROM". That's incorrect terminology and should not be used to refer to it.
mmmm locked They do not implement many of the features correctly and take problematic shortcuts. It leads to them having a long list of features which sound useful but which are largely reducing security and not working properly. They incorporate highly problematic third party code from Eyeo full of serious security bugs and full of invasive tracking code. Their technical decisions are not the full picture of what we were referring to though. It's quite relevant that they have no issue with plagiarism, scamming and harassment, even towards people they were taking substantial amounts of code from in the past which they then downplayed. You would be better off using Brave which despite the controversies about cryptocurrency, etc. is far more technically competent and also far more trustworthy than this.
wuseman Firejail is extremely problematic and shouldn't be recommended.
GrapheneOS Thank you. That makes a lot of sense.
GrapheneOS Their seccomp-bpf filter is not a complete sandbox and you are claiming to know their perspective when you do not.
I am referring to their positions in these threads, especially the comments of Gian-Carlo Pascutto (Mozilla):
- https://bugzilla.mozilla.org/show_bug.cgi?id=1756236
- https://bugzilla.mozilla.org/show_bug.cgi?id=1882881
GrapheneOS Flatpak packages for browsers have weaker internal sandboxing than traditional ones but you're wrong about what the differences are.
The way I understand it is that the native Firefox install has a multi-process architecture with content processes and other processes (like GPU, extension and so on). In the native version the parent process is basically unrestricted and confines the other processes, especially the important content/renderer type processes. It does this through secomp-bpf filters and unprivileged user namespaces
The latter in turn is used to set up different namespaces and chroots, depending on the process type to confine. If a process needs something from outside its own sandbox, it has to use IPC to request it. Because of the multi-process-architecture of FF, the sandbox for each process can be tailored to its process type (e.g. content process).
On the Flatpak version, it is different. Flatpak itself uses namespaces, chroots and secomp-bpf-filter for its own lax sandbox, which encompasses the app as a whole. It uses a secomp-bpf-filter for generic container types on Linux which blocks namespace and chroot creation inside of a flatpak app, because these syscalls would otherwise lead to easy escapes of flatpak's own generic sandbox. But since these syscalls are blocked, FF also can only use secomp-bpf-filters for its own processes and not chroots and namespaces anymore to confine its processes as it does on the non-flatpak version. So the namespaces and chroots around each process got replaced by a more generic flatpak sandbox encompassing the whole app. This leads to a less tailored and thus weaker sandboxing architecture, which neither protects sites, nor stored browser data, nor the system as a whole better than the native version.
Is my explanation correct? @GrapheneOS
To put it simply, there's no good reason to replace Vanadium with Cromite on GrapheneOS : you'll get the opposite of a better browser.
I tried the desktop version of Cromite on Arch but removed it because the only clear feature for me is disabling JIT and you can do that on Chromium/Chrome by disabling the V8 optimizer, also note that Cromite is almost 100% written in C++ which is a memory insecure language with a ton of attack surface. So I preferred to go back to Chromium via the official repository which works fine for me.
Xtreix also note that Cromite is almost 100% written in C++ which is a memory insecure language with a ton of attack surface. So I preferred to go back to Chromium via the official repository which works fine for me.
That's not unique to Cromite.
matchboxbananasynergy That's not unique to Cromite.
I know :)
- Edited
Xtreix my own case in particular, I'm not looking to replace Vanadium with Cromite. But I like to have;
a 'clean' browser to browse in (Vanadium)
a private browser for medical and very private searches (Tor)
a browser to remain logged into web apps in (Mulch)
a browser to shop in (Brave)
a browser to view news and forums in - not logged in or logged in with a pseudo, (Cromite until this thread appeared).
I rename these browsers according to their main occupation.
I have worked like this for years, since before I moved to Graphene. I do it mainly so I keep things separate, and I have always assumed compartmentalisation is a valid choice for security and privacy. I could well be wrong. Aside that though, it helps me keep organised and prevents me from needing to download millions of apps.
I am referring to their positions in these threads, especially the comments of Gian-Carlo Pascutto (Mozilla):
That's not really what it says there. Some of their statements about both Chromium and Firefox are also incorrect. They're clearing aiming to promote Firefox and aren't doing so honestly.
On the Flatpak version, it is different. Flatpak itself uses namespaces, chroots and secomp-bpf-filter for its own lax sandbox, which encompasses the app as a whole. It uses a secomp-bpf-filter for generic container types on Linux which blocks namespace and chroot creation inside of a flatpak app, because these syscalls would otherwise lead to easy escapes of flatpak's own generic sandbox. But since these syscalls are blocked, FF also can only use secomp-bpf-filters for its own processes and not chroots and namespaces anymore to confine its processes as it does on the non-flatpak version. So the namespaces and chroots around each process got replaced by a more generic flatpak sandbox encompassing the whole app. This leads to a less tailored and thus weaker sandboxing architecture, which neither protects sites, nor stored browser data, nor the system as a whole better than the native version.
Firefox doesn't have complete site isolation in any form, whether or not Flatpak is involved. It's also a weaker sandbox. Flatpak weakens it further. You're mixing up several different things.
- Edited
GrapheneOS Firefox doesn't have complete site isolation in any form, whether or not Flatpak is involved. It's also a weaker sandbox. Flatpak weakens it further. You're mixing up several different things.
Ok. I think this means Chromium is more secure generally?
I'm quite unsure what to use on Debian now.
- Chromium, this browser isn' t perfect and has enough flaws also
- Firefox, weaker sandbox , the rest can be configured more privacy respecting
Can we please have a Vandium for Debian Stable?