Earlier quoted context omitted.
Yes, you can consider all processes running under the same user as able to peek at each other's data. This is the point of running under the same uid: sharing data.One uid should be considered one security domain, with any separators inside it being guardrails, not brick walls. If you want to prevent other processes from peeking into your process, run it under a different uid. Again. that's the point. A bunch of good…
I think this part of Unix is exceedingly problematic. I want to be able to run program that don't have the ability to do anything that I, personally, can do. Ideally this would be doable without nasty kludges or root's help. Linux has some ways to accomplish this, for example: - seccomp. It can be done quite securely, but running general purpose software in seccomp is not necessarily a good way to prevent it from act…
Namespaces, to my mind, are a huge help, starting from trivial chroot and nsenter, all the way to bubblewrap [2] and containers (rootless, of course).
Also, with a properly prepared disk image, and the OS state frozen when everything heavyweight has started already, you can spawn a full-blown VM in well under a second, and run a questionable binary in it.
It would be fun to have "domains" within a user account, with their own views of the file system, network, process tree, etc, and an easy way to interactively run programs in different domains. Again, it's pretty doable; whoever creates an ergonomic product to do it, will win! (Well, not really, because most developers sadly run macOS, which lacks all these niceties, but has its own mechanisms, not very accessible to the user.)