Chrome was also found to be secretly downloading binary blobs for execution, we should not be trusting Chrome's sandboxing exclusively to protect us from the in

Chrome was also found to be secretly downloading binary blobs for execution, we should not be trusting Chrome's sandboxing exclusively to protect us from the internet, we can't even trust Chrome itself. [0] In-browser sandboxing is more for attempting to isolate tabs from accessing one another's state. It can't be relied upon exclusively for protecting the larger host from the browser itself. One should really put the entire browser in a sandbox where it can only access data and functionality necessary for its operation. Nothing more. How one achieves that, what tools is at their disposal, is greatly OS-dependent and that's the core of my point. On Linux systems, the out-of-box configuration for most distros is to just run the browser on the host with no sandboxing. It's not sufficient. Flatpak is one of the active efforts to fix this. If you run firefox or chrome from a flatpak, it will be run in isolation, and accessing external host resources will be done in a controlled fashion via portals or explicitly enumerated mounts in the manifest. As mentioned elsewhere, I used firejail in the past but now prefer systemd-nspawn containers, often ephemeral ones that are spun up and thrown away per browser session. [0] https://www.theregister.co.uk/2015/06/17/debian_chromium_hubbub/ https://www.theregister.co.uk/2015/06/17/debian_chromium_hub...