One of the paradoxes I struggle with in my work, is the conflict between crypto and reliability.
Crypto is important. But it is very binary in nature - either the stars align and you can decrypt, or it fails and there's no recovery. With that kind of binary, reliability suffers. This is inevitable.
As an example, most of the Mastodon downtime I've experienced has been related to minor SSL certificate blunders.
I feel like most of the #InfoSec community wilfully ignores this dynamic.
As an example of the encrypt-or-not struggle in #Mailpile: currently the recommended settings encrypt all sorts of local files, including the search index, settings and downloaded e-mail.
I'm pretty confident that the settings and search index need encrypting.
But the e-mail itself? There I'm not as sure.
If the Mailpile master key gets lost or corrupt, losing all the mail is a very high price to pay. It's also a significant barrier for folks who decide to switch to another client later.
@jankoekepan Exactly. There are arguments to be made on both sides.
@HerraBRE Or a deeper strategy rooted in disaster recovery theory: consider the corruption of data a disaster. Where are your backups, how fresh are they, and how quickly can you restore them?
@jankoekepan That's where this is headed. But implementing a solid backup story without bothering the user is... a fair bit of work.
The tool is intended for non-technical users. I can't reasonably expect them all to have disaster recovery plans.
@HerraBRE This is true. However, if they're going to turn to you when it breaks, you need the disaster recovery plan. On the other hand if they're supposed to maintain it themselves, you need to be prepared to educate them.
@jankoekepan I don't have faith in my ability to educate people. I have more faith in my ability to write software with relatively sane defaults. ๐
... the knee jerk reaction here is to punt and let the user decide.
But most users lack the technical background to make a good decision here.
So not only do the defaults matter a great deal, but just making some options available in the user interface at all may be a bad idea.
I don't want my software to be a foot-gun. Which is a surprisingly high bar sometimes!
@HerraBRE this is an interesting one - i'm in the middle of some decisions about mail software, and i'm basically ruling out anything that's going to lock me into a storage model i can't port to different software later on (or use with tools like notmuch).
of course i have no idea how to balance my priorities for that against other concerns like "getting all your mail stolen".
@brennen Yep. There's no easy answer here. The defaults WILL end up being wrong for someone, I'm just not sure how to choose who gets the short straw.
@trevdev @brennen I'm currently leaning in the other direction: try really hard to make sure backups of the master key exist and provide tools for decrypting in case users want to migrate later.
But I change my mind every few days on whether that's the right way to go.
I may end up disabling the decryption by default until I have confidence that the above mechanisms (key backups, migration tools) are working.
I dunno! I dunno!
I'll toss a coin in the end.
@HerraBRE @trevdev i guess my main request as a potential user would boil down to: make sure a migration pathway is more than theoretical and routinely tested.
i've learned a lot of wariness about getting my stuff in and out of systems that aren't built around some common, widely-supported format / datastore.
@HerraBRE Too bad you can't implement something like Keybases' KBFS APIs to store a backup of unencrypted email in the KBFS file system so users get a disaster recovery plan. Unencrypted emails get encrypted to the KBFS and protected in-transit and at-rest.
@gme I do actually plan to (optionally) upload encrypted backups of everything to the user's IMAP.
I love the irony of deleting everything from GMail and then filling it back up with encrypted blobs. MUAHAHAHA.
But that will take time to implement. I have a lot of plans. I'm not going to block shipping to a wider audience for this... so the defaults matter now.
@HerraBRE I wouldn't be surprised if that's not against Gmail's TOS though.
@gme I haven't checked.
A bit like how they don't read patents... ๐
@HerraBRE Traditionally, I think clients keep encrypted mail and decrypt on access. One advantage is that you don't need extra protection on backups. Yeah, losing the private key or passphrase means the mail is lost in return.
But maybe that's more of a holdover from shared machines where you might have had to protect your stored mail from other users.
@HerraBRE
When you just want to protect the mail in transport from casual eavesdroppers, storing encrypted mail on your own system is an overkill.
Worrying about intelligence services or criminal organisations? Oh well... Sometimes I think that maybe the wide adoption of encryption is hampered by extreme use cases and the hassles associated with them...
@galaxis You misunderstand. I am talking about storing ALL the downloaded e-mail in encrypted containers.
Almost no mail clients do that.
Leaving PGP or S/MIME encryption intact when storing the mail is the common practice you are referring to. It also has its own set of pros and cons, but this thread could go on for weeks if we open that can of worms. ๐
@galaxis The threat protected against, when storing the e-mail in encrypted containers, is mainly that of having the hardware stolen.
This is not a particularly rare event, when it comes to things like shiny Macbooks or other places people are likely to run a mail client.
And yes, I know I could just expect the user to use FDE. But I have no idea how common that is in the Real World, outside my little bubble of infosec aware geeks.
@HerraBRE Unless FDE is enabled by default, most people will not use it. And even then it's easy to mess up by the user (weak passwords, or passwordless login anyway). Biometry might help a little (people are getting used to that from their mobile devices), but has other downsides.
There's reasons why Apple and Google are so successful with their devices coupled to hosted services - they do solve most of the obvious backup and security problems that real world users have. At a cost.
@HerraBRE secure transit vs. encryption at rest are also very different, in terms of usability and common threat models. Use of HTTPS requires almost nothing of users, and mitigates well-known widely-used attacks on confidentiality and integrity by various network parties.
Encrypting backup hard drives (or other long-term storage) is a much weightier risk of lost access and requires user to manage long-term keys, and protects against certain types of mostly in-person theft.
@HerraBRE You can't just encrypt individual mails that were sent with encryption?
@HerraBRE make it optional?
@webmind This sort of thing has to be optional. The question is: what should the defaults be?
@HerraBRE Conversely, there's a question about the cost of having all the email compromised. (Ask Hillary Clinton about this one. Or a few oil executives.)