Little then I guess 
but that implies it already existed, so what’s the appeal for more varying sandboxing today?
Better sandboxing = better security
Bad or no sandboxing = sites can read stuff from other sites, and they can do that silently without you knowing at all
I’m pretty observant 
I’ve done banking and crypto too no problem; theoreticals haven’t gotten me yet
Related thread: Security problems with Flatpak Browsers (Firefox, Chromium), bubblejail, seccomp, user namespaces - #8 by alexmanninger
As i said and always say
Not happening doesn’t mean it won’t happen
Sure you could run internet explorer in wine and do your stuff there if possible, does it justify the usage of an insecure browser?
At least don’t recommend people a less secure alternative
I argue common-sense™ is better security than relying on magic; but there’s also enough OSs still entertaining that for me not to be that concerned about one trying to force slower magicks Free-choice is cool 
Having common sense doesn’t mean we shouldn’t use insecure alternatives
Otherwise i would’ve used internet explorer and not go to a fishy websites
Firefox is included by-default and isn’t insecure. And I’d argue Firefox’s defaults for handling multi-process and sandboxing is pretty secure.
I was even fine on IE7 XP/Vista-days
Absolute-security might be possible air-gapped. Otherwise, adding layers doesn’t provide absolute-protection. Even running a browser 3-layers-deep in virtual machines on Tails through Tor through a VPN can’t guarantee immunity from theoretical.
The deeper you go, the brighter you glow.
1 Like
Firefox is included by-default and isn’t insecure
[It’s]( GitHub - RKNF404/chromium-hardening-guide: Harden chromium (somewhat) ) [not]( Firefox and Chromium | Madaidan's Insecurities )
Being included doesn’t mean it’s secure
And I’d argue Firefox’s defaults for handling multi-process and sandboxing is pretty secure.
So secure that it’s weaker on linux, and MISSING on android
Also idk how to do hyprlinks here ;-;
Prove it
Someone else’s bulk-thesis =/= real-world or realistic end-user usage. Use Firefox on Fedora, and somehow put it in a scenario where theoretical default less-security would allow an exploit to legitimately happen. If that doesn’t happen under proposed scenarios with “additional” protection, then it might be a realistic concern.
The proof is there there is no relation between inclusion by default and being secure, especially after i shown you firefox security problem
The same logic will say thay sudo is secure despite being SUID binary which is no securely designed
1 Like
The problem is that this also includes the syscalls that are required to create the namespaces and chroots. So if you block them at Firejail/Bubblewrap/Flatpak level, the browser running in them can no longer use them to build the sandbox structure as intended. However, if you do not block them, the additional sandbox is not of much use, as there are known escapes for the namespaces and chroots…
flatpak is effective in the process and disk sandbox. but, somehow, it seems to reduce the rendering process sandbox, the most important one in chromium. the objective of chromium is to reduce the possibilities for websites, in the event of security holes, to tamper with the user’s browsing, or to steal it. this is why it is important that the sandbox remain as defined by the chromium security team, or improve it.
From what it seems to me, but mind you, it seems to me, flatpak is fine for isolating applications that do not have a sandbox of their own, but perhaps not suitable for use in more sophisticated applications.
1756236 - Figure out how to chroot/use namespace isolation in flatpak.
Firefox’s situation is arguably worse because it often fails “silently” rather than using a workaround like Zypak. Blocks User Namespaces entirely (visible in about:support). This disables the chroot and privilege separation layers of the internal sandbox.
Trivalent from Secureblue is a chromium follows Vanadium (GrapheneOS) mentality. Because it is native, it does not use Zypak, so it keeps the full Chromium internal sandbox. Secureblue then wraps this native process in a strict SELinux policy and forces it to use hardened_malloc.
If you are on other distro, prefer native browsers and avoid flatpak chromium (they rely on Zypak) and especially Firefox flatpak (explicitly disables user namespaces).
Comparing native browsers, chromium is clearly recognized to have better:
- Site isolation against the less granular Fission
- Service sandboxing, expecially in the network service sandbox.
- Really more robust user namespaces usage
- Stricter seccomp Filters
It’s not about how much it’s working
But rather about how WELL it works
Those stuff in your screenshot means nothing if those high levels are weak
1 Like