FYI I've been a fulltime security professional for 20 years. My advice is based on what I actually do when your bank hires me to test their security, how I can actually hack your accounts.
> No, the problem is, you try to seperate, what seems important and confidential to you. And there is the mistake.
> Because it requires you to think about what's confidential all the time. ...
> reading some private e-mails won't hurt now, because if they are left in the cache in your firefox profile
I never said "encrypt one file at a time". I said encrypt YOUR files separate from your (soon to be ex-) wife's files. That includes /home/allo/.cache/mozilla/firefox/
Obviously you might *also* separately encrypt your most important files, such as a password manager datastore, a second time. But no you don't have to think about what to encrypt, all of your personal files are encrypted, including your browser cache.
> Why would you encrypt /home and not /? Is there any reason preventing / encryption? No. ...
> So you install your system, make a checkmark at "full encryption"
That SEEMS like a good idea, if your understanding of encryption is checking a box. As one of the guys who implements what happens when you check that box, I think maybe we should remove that checkbox so it doesn't mislead you. It LOOKS like it makes your system secure, right? Unfortunately, it mostly just makes your system slower. I can still see your ECB penguin. :)
There are both practical and technical problems with full-disk as opposed to per-user. The biggest practical problem is easily summarized as:
Do you want your files to be accessible to your soon to be ex- wife?
Generally, no, users should not have access to another user's files. When your visiting step-brother asks to borrow your laptop, he should not be handed an unencrypted copy of all of your personal and business files.
There is also a fundamental technical problem with full-disk encryption such that full-disk can either either be weak, or ridiculously slow, in most cases. It has to do with what are called "cipher modes". ECB is reasonably fast, but provides little security. CBC is secure, but modifying one sector requires updating every sector on the disk which follows it (meaning it takes a few minutes to save 1KB). Other modes are in between the two. We think that we *might* have that problem beat with a new approach, but I don't trust it yet.
> If you need to decide what ends up in your backup, you may forget something important. If you backup everything, you will have everything and cannot forget something important. The same applies for encryption.
That's absolutely true for backup, definitely. The only backup systems I recommend backup the whole damn machine. The system I designed makes *bootable* backups, that can be booted in-place as virtual machines. For encrypting and otherwise securing confidential data, there's a fundamental conflict between availability vs confidentiality and integrity. You may want to make your mp3 files openly available on your network, so you can play them with any device in the building. You might even store them in the cloud, easily accessible over the internet. You should NOT make your most confidential data readily accessible to every device on your network, including your IP camera and other cheap IoT devices with a thousand vulnerabilities each. If you're serious about security, you DO need to think about which items should be easily accessible to everyone in the company/house and which should be locked down tight.
I'll give you an extreme example of identifying the most confidential data and a very common example of failing to do so. The Coca-Cola company has perhaps a million documents that shouldn't be published on their web site, documents for employees only. Only their 146,000 employees have access to those documents, because they have some protection. (And probably anyone who cares to look can findleaked copies online). Coca-Cola also has the secret recipe for Coke. The secret recipe can't be found on Google only because Coca-Cola properly identified their most critical assets and protects them accordingly. The secret recipe isn't protected in the same way that the campus wifi password is protected. Coca-Cola has done it right.
On the other hand, it's common for web forums and similar software to treat each user's user name and password as confidential information. The security of these forums assumes that a bad guy doesn't know the target's username or password. They then expose the username via a search function or something similar. So it's a "secret" in that you assume that bad guy doesn't know it, but then it's not so secret when you display it on their list of posts. I pointed this out to the developers of two such systems and they didn't quite "get it". One understood a couple years laterb when there was a rash of attacks exploiting this problem. The second understood when I demonstrated that I could log in as admin. It *is* important to be clear on which data is public, which is "not shared", and which is secret.