>I don't want FireFox or Chrome reading ~/.ssh or ~/.gnupg or any other directories in my home that it has no business reading.

Both browsers already do this for the processes that are exposed to the internet. The software shown here additionally does it for the entire browser (with the caveat wrt uploading/downloading that I explained, and maybe some more gotchas that aren't immediately obvious).

(You may understand this nuance, but I wanted to point it out, as it's literally what the browser sandboxes do)

> Maybe one day we'll have web browsers that don't have any C code. Nothing against C. It's a great systems language, but I'd rather my web browser not use it.

Both Firefox and Chrome are primarily written in C++, not C. They do use C libraries though including libc.

Flatpak's sandbox is pretty weak and there are many subtle loopholes that allow for trivial escapes. Relying on it as a security measure is not a great idea.

An example of such a thing, that is related to this thread, is the X11 socket being accessible even when the directory it appears to be contained in isn't bind mounted into the flakpak sandbox's mount namespace. This is because regular file system permissions do not apply to abstract sockets (which X11 can and does listen with).

I think unsharing the network namespace would fix this, and configuring X11 to not listen with any abstract sockets might be possible, but this is just one of many examples of trivial sandbox escapes that most people would never even consider.

The best bet to isolate untrusted software is to run it under a different UID (less safe) or inside of a VM (probably very safe).

> xdg-desktop-portal makes things even better: app can only access files that you explicitly choose when prompted - kinda like on iOS.

Ho-hum. I can understand the appeal of that idea, but in practice quite a few file formats and applications rely on implicit and/or file-format-specific relationships between multiple files. I.e. I as the user pick one file for opening, but in order to successfully carry out that task, the program actually needs to access quite a few more additional files based on the initially opened file.

None of the sandboxing approaches I've seen so far has a really great story for that usecase.

AFAIK Android and Windows don't offer anything in that regard, no idea about Flatpak, and Apple at least seems to handle related files with differing file extensions, like movie.mp4 and movie.srt, but would still break down for more complex file formats where related/associated files don't share the same file name sans extension.

Plus it means you always have to go through the official OS file dialogues and can't e.g. just manually edit a path directly in the app's UI if that would be more convenient…

And where are all the valuable files stored like family pictures, other browsers’ cache, ssh keys etc.? In the same user’s home dir, so in practice most desktop apps do have uncontrolled access to everything on the harddrive as per the now quite old xkcd comic ( https://xkcd.com/1200/ ).

Ideally, a “shadow” Download folder would be accessible to the process, and its content would be mirrored one-way into the real Downloads folder. Upload should display a file chooser dialog which runs in an entirely different process, and the chosen files should be in effect copied to the process’s file handles list.

That sounds interesting. There must be apps that do require full access (like a finder alternative), so I wonder if you can know to trust an app to be isolated just by looking at it.

flatpak does this on Linux. There is an official-from Mozilla flatpak available for Firefox.