Wow, talking about swift replies. You are on fire! 
It’s worth mentioning here, that users who want to protect the contents of their Mailpile folder are can enable all the local storage encryption options. That’s what they’re for! Hostile local apps can still vandalize by deleting files, but the encryption should protect the data from all sorts of theft.
Totally. Mailpile sets a sane and awesome baseline with options like this. And it shows that while security and privacy are two different aspects, they can integrate nicely and smoothly.
The trade-off, which is why not all the encryption is enabled by default, is reliability. Encrypted files are much more vulnerable to data corruption, and key loss is a real concern.
That makes much sense. I’ll be sure to take that thought/remark into account with writing any docs. I have moved my Mailpile instance across a few machines in the past, just making an exact copy of the Mailpile data folder has helped tremendously. Mailpile does have its own tools for backups, I know 
Regarding the browser itself, traditional user-account based security works well in this case - since Mailpile’s UI a web server, it’s perfectly feasible to have Mailpile running under a separate Unix (or Windows) account, or in a VPS, or a container - even on separate hardware from the browser. Such hardening approaches are probably easier to reason about and implement than a browser sandbox. More security for less complexity is a winning combination.
True that! And if Mailpile runs stable and smooth on a Raspberry Pi, that makes up some neat setup with segmentation and seperation applied. But, I rather write it out in a sidenote, because I think we shouldn’t assume every user has the means to get or have a second system. Even with machines we consider cheap, that is more our society. Remain inclusive 
