It’s never going to be possible to achieve 100% security and privacy, but that doesn’t mean we should all give up and use qwerty12345 as our password for everything.
It’s the same as anything: perfection can never be reached, but it’s still worth doing things well.
Fastmail views the viability of e2ee in webmail differently than Proton does. I suspect Fastmail won’t offer it until there is a better solution (an easier way to store your own keypair in the browser, or a check-summed binary that performs the in-browser encryption.)
Fastmail also doesn’t have the network effect of privacy-conscious users only wanting to email other Fastmail customers like Proton does.
Fastmail’s encryption at rest, employee access policies and TLS support are pretty good for being in the primary business of providing a solid and affordable email service that your family members will actually use.
But again, keep watching advances in browser local storage and binary execution because that’s what is going to eventually make full encryption in webmail viable for Fastmail.
Right. That’s the whole point of this discussion, I think - what the threshold for “well” is.
I was asking a locksmith about fancy safes once, and he indicated that for the majority of people they don’t need anything fancier than a relatively low-priced ($300-$400) safe. The point is to have something that deters the average thief - not something that would stop the Ocean’s 11 crew. If you have somebody coming after you with safe cracking equipment, you’re in a very small subset of users with different needs.
That’s Internet security in a nutshell. Use a password manager so you’re not reusing passwords. Then pick a good password for each service. Pay a minimal amount of attention to who you trust with your data. For the average user, that’s more than enough.
Hi. You think, they’re working on it to get some kind of full encryption available in future?
For now I think they’re going the ‘other’ direction, as their mail headers are getting more and more blown up with details you don’t need within those headers.
Let’s see - interesting time ahead I Think.
I’m trying to draw the link between the content of mail headers and encryption. Apart from the “from” and “to” addresses, all the other misc. stuff is at least theoretically encrypt-able.
It’s more of a privacy part… Nobody needs to know which mail-client I’m using for sending a mail and which version I do use for example. Written within every mail from Fastmail. As a privacy orientated provider this does not need to be the case.
The recipient of the email might not need to know what mail client you are using or what version it is, but the destination email client might need it. Every email client or service designs its emails a little differently, so email clients have to have lots and lots and lots of remediations so that they can interpret all the minor variations in email construction to render them correctly for the recipient.
Email is not, nor can it be, ever truly private. The only way would be to use a separate secure communications service like Signal.
In no way a destination client needs this info.
I know that maybe others are more secure (Proton, Signal, Threema, Matrix and so on…). But I know many providers who delete this and other headers from their mails and everything is working fine.
There simply is no need to.
You might be right on that. I’ll stand by the rest of my referenced post, however.
+1