# bubblewrap_that_browser: safer than both native and flatpak version of browsers? **URL:** https://discuss.privacyguides.net/t/bubblewrap-that-browser-safer-than-both-native-and-flatpak-version-of-browsers/40351 **Category:** Questions **Created:** 2026-08-31T13:17:46Z **Posts:** 12 ## Post 1 by @Lune — 2026-08-31T13:17:46Z The way I see it with browsers in linux is that you have a trade-off to make: install the native version from distro’s repositories and if an attacker escapes browsers sandboxing (for which there has been some recent bugs discovered) it could gain same permissions as the user. or install the flatpak version that adds an outer layer to protect your home but it also weakens browsers own internal sandboxing, which might just be a net negative. That led me to discovering [GitHub - backdoorsecurity/bubblewrap\_that\_browser: A comprehensive bubblewrap sandbox built for brave, chromium and firefox. · GitHub](https://github.com/backdoorsecurity/bubblewrap_that_browser) . as of now a 0 star repository made 2 weeks ago that uses bubblewrap and seccomp filters to add an outer layer of protection without messing with the browser internal sandboxing. Any downsides to this approach or can we claim it is a net positive in terms of security? --- ## Post 2 by @Cyber-Typhoon — 2026-08-31T14:38:48Z To answer your question directly: while bubblewrap is a great tool, wrapping a native browser in a custom `bwrap` setup is generally not recommended, it often ends up being a net negative or neutral for browser security. Here is why: 1. Interference with Internal Sandboxing: Chrome, Brave, and Firefox rely on unprivileged user namespaces and custom `seccomp-bpf` filters to isolate individual renderer tabs and GPU processes. Nesting user namespaces via an outer bwrap container frequently breaks or forces the browser to degrade its internal sandbox. 2. Seccomp Conflicts & Maintenance: Browser update cycles frequently change system call patterns. Unmaintained custom seccomp filters can easily break features (DRM, VA-API, WebGL) or force users to relax rules, inadvertently introducing security holes. The recommended right now (things may change, there are some work happening to improve this on Flatpaks): MAC (Mandatory Access Control), **AppArmor** or **SELinux** are generally preferred for native browsers because: - They restrict what file paths, IPC, or network capabilities the browser process can access on your host. - They operate out-of-band without interfering with the browser’s ability to create its own internal namespaces or seccomp filters. If you want a native browser setup, the recommended path is using the distro package alongside a strict AppArmor/SELinux profile. If you want maximum isolation, containerizing/virtualizing at a higher layer (e.g., Qubes OS or dedicated disposable VMs) is far more effective than layering namespace wrappers on top of each other. --- ## Post 3 by @hydride — 2026-08-31T15:24:37Z Or use WebKit in flatpak > **[Install Web on Linux | Flathub](https://flathub.org/en/apps/org.gnome.Epiphany)** > > Browse the web --- ## Post 4 by @sha123 — 2026-08-31T15:29:03Z WebKit in Flatpak sounds worse. --- ## Post 5 by @sha123 — 2026-08-31T15:31:40Z Did you read what was written in that repo? It does not interfere with the browser’s own sandbox. --- ## Post 6 by @Cyber-Typhoon — 2026-08-31T15:54:49Z I didn’t, good call. I assumed they went the standard route. I guess, the only pitfall that I can identify is maintenance burden. Because browser rendering engines update frequently, maintaining custom BPF seccomp filters requires staying on top of upstream changes to ensure future updates don’t break features or cause subtle fallbacks. --- ## Post 7 by @Lune — 2026-08-31T16:05:09Z The problem with sandobxing that operates in kernel/root is that a flaw in the sandbox might lead to root escalation where not sandboxing it would’ve reduced the blast radius. both firejail and apparmor(and snaps even more) had instances of that happening. that is why I like bubblewrap a lot more Have been reading the source code since morning here, the seccomp filters seem very generic and things a browser should never touch anyway. the code seems well thought. --- ## Post 8 by @hydride — 2026-08-31T16:24:52Z WebKitGTK shares many of the same features of regular WebKit, sans some stuff that are iOS/macOS/Apple specific. It is the only browser to support proper sandboxing in Flatpak but said sandboxing is notably weaker than native (non-Flatpak) Chromium. --- ## Post 9 by @sha123 — 2026-08-31T16:47:55Z > [@hydride](#): > > It is the only browser to support proper sandboxing in Flatpak but said sandboxing is notably weaker than native (non-Flatpak) Chromium. Since it is weaker anyway, why mention WebKit in the first place? --- ## Post 10 by @sha123 — 2026-08-31T16:58:16Z > [@Lune](#): > > The problem with sandobxing that operates in kernel/root is that a flaw in the sandbox might lead to root escalation where not sandboxing it would’ve reduced the blast radius. both firejail and apparmor(and snaps even more) had instances of that happening. The benefits of using these tools often outweighs the rare occasions, where they can be used to escalate privileges. Even in cases where these bugs occur, they are often only exploitable from outside the sandbox, by unsandboxed processes. --- ## Post 11 by @Lune — 2026-08-31T17:10:16Z what sorts of benefits are we talking about? benefit with bubblewrap+seccomp filters seem that it has no down side. nothing weakened and no extra attack surface. if it fails then we are back to native browsers --- ## Post 12 by @sha123 — 2026-09-01T09:36:39Z There are some things you can’t do or can’t do well with bubblewrap, eg. firewalling, domain transitions, domain to domain communication rules and rules with wildcards.