@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.

          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):

          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.

                      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.

                          TheGodfather

                          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.

                              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?

                                  mmmm It seems like a complicated way to try and accomplish something that isn't very clear.

                                  Vanadium does the job just fine for normal browsing, forums, news and shopping, I can't see what kind of extra protection you get by using multiple browsers. The browser is strongly sandboxed and Vanadium gets all the security and privacy enhancements offered by GOS by default.

                                  If you're using Tor for more privacy, I'd recommend at least the desktop version, even if it's far from perfect. The mobile version has the same major weaknesses as Firefox when it comes to security and privacy.

                                  Compartmentalization with different VMs or physical machines is useful for certain tasks, but using several browsers on the same system for different types of browsing is what I'd call a headache.

                                      Xtreix I thought I mentioned it helped me stay organised, its far from complicated.

                                          mmmm Well, it's still an impractical way of doing it from my point of view and I'm not sure what it adds, but if it's good for you, I guess it's OK.

                                          • mmmm replied to this.

                                              Xtreix I wasn't asking your permission, but thanks for the validation.

                                              Its easier if I tap 'news' on my home screen and get a browser which has all the news articles I was reading open in tabs, and all my favourite sites saved, but nothing else. Its like a dedicated news app but without all the data collection and with the versatility of a full browser.

                                              Its better to tap on 'shopping' on my home screen - and find all the places I like right there, without a load of tabs of random stuff getting in the way.

                                              In Vanadium I can open any link and do any browsing I want and I just delete all data everyday, and its fine because I dont have to worry about losing anything I was actually meaning to keep, or logging out when I didn't want to.
                                              Etc etc.

                                              And tor, I know the limitations. But I simply browse to what I want to find out or research and then close it down. I dont use it too much on my phone though, I have a Qubes machine for browsing tor properly.

                                              Anyway, each to their own.

                                                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.

                                                Would you mind elaborating on this further please?

                                                I thought that there was indeed site isolation on the desktop version of Firefox (or Mullvad Browser, which is what I use), and that this only applied to the mobile version? I know that there's a fixed number of site processes and that two sites can potentially share the same sandbox, is this what you're referring to with "weaker sandbox"?

                                                How does Flatpak weaken security further? Do you mean the lack of nested user namespaces in the bubblewrap sandbox? If so, does this have a major impact?

                                                Thanks!

                                                    upstage4186 I thought that there was indeed site isolation on the desktop version of Firefox (or Mullvad Browser, which is what I use), and that this only applied to the mobile version? I know that there's a fixed number of site processes and that two sites can potentially share the same sandbox, is this what you're referring to with "weaker sandbox"?

                                                    You can find some information here from the team at DivestOS. GrapheneOS said complete site isolation which I assume refers to Fission probably not being a particularly powerful implementation of site isolation (as I believe I've heard somewhere).

                                                      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

                                                      I didn't say otherwise.

                                                      GrapheneOS You're mixing up several different things.

                                                      Which things?

                                                      Since questions about FF's sandbox and site isolation on different platforms come up often and needing to reply to it many times over years on different communication channels, maybe it would make sense to write a blog post or something on the homepage and actually explain why that is, so it can simply be linked to and people would actually get a chance to understand, instead of having to deal with generic short statements, which readers just have to believe. Even though it would mean initial effort, it might save time in the long run.