I beg to differ.

  $ firejail ./bin

Even the very limited default profile hides things like ~/.ssh and makes the rest read-only (with the exception of ~/.cache and such).

That doesn’t invalidate what I said. It requires going well out of your way (as do other sandboxing arrangements—I never said they didn’t exist), and it’s not a very good sandbox without a fair bit of work. (So maybe you’re blocked from trashing the home directory, but stealing all your passwords and login cookies was always more lucrative than vandalism, so making the rest read-only is small comfort.)

I have no desire to engage in one of those 50 levels deep nested arguments, so this is my last message, but you literally said:

> or makes it at all easy to achieve

firejail makes this trivial. You won't be able to steal anything of interest. Making an easy to use sandbox for desktop applications is the main goal of the project. You could have tried it out before arguing against it in what feels like bad faith.

  $ firejail bash
  -- snip --
  
  $ ls ~/.mozilla
  ls: cannot open directory '/home/foo/.mozilla': Permission denied
  
  $ ls ~/.ssh
  ls: cannot open directory '/home/foo/.ssh': Permission denied
  
  $ ls -lh passwords.kdbx
  -r-------- 1 nobody nobody 0 May 29 14:53 passwords.kdbx

And so on. (The last one is my real password database and it definitely isn't 0 bytes in size.)

I haven’t ever used Firejail, but I know a little about it. I understand that Firejail depends on you configuring things for each app, with a mixture of whitelisting and blacklisting. That’s untenable unless the default profile is safe. You said its default profile just makes the home directory read-only; I took that at face value (since I have no interest in installing it to check). If what you said was correct, then I presume that either you must have changed the default profile, or Bash is using a different profile?