That's a useful list, thanks. It's also saddening: almost all of those items are in the "it's hard to implement" category. I get that free software development

That's a useful list, thanks. It's also saddening: almost all of those items are in the "it's hard to implement" category. I get that free software development is hard and self-directed, but it still bums me out that people are willing to toss the baby out with the bathwater. A couple of those points seem plain wrong/misleading, though: > Programs now have to deal with malicious applications capable of managing mountpoints giving fake results via the filesystem. If malicious code has privileges to change the pseudo-device paths for /dev/zero and /dev/random on your system you can easily be compromised regardless. Such code could sniff your network traffic, put junk data into any file (or socket descriptor, since it could probably also install a tap) your program used, and likely also debug/inspect/halt/alter the runtime behavior of the victim process(es). > You can't let the program go into a chroot jail if it needs to read the kernel's magic filesystem. This is technically true, but I think it would be possible to develop a convention or standard for chrooted programs that resulted in certain "capabilities" (e.g. "can it use procfs? which parts? how about /dev/zero?") being present in standard locations inside the jail. It is more implementation/standardization work, though, so this isn't a criticism--more of a regret.