Live data from Hacker News

Email cannot be encrypted at rest

migadu.com

21–30 of 35 posts

Re: Email cannot be encrypted at rest

#21
post #7

Earlier quoted context omitted.

The title is throwing off how we’re reading the article. It’s really about why they, an email provider, can’t meaningfully encrypt email at rest. FTA: >If you are interested in real encryption, please use end-to-end encryption tools such as GPG or fetch locally all your messages periodically and encrypt them yourself. I would say their standard for being ‘encrypted at rest’ is including a requirement that they are un…

> please use end-to-end encryption tools such as GPG or fetch locally all your messages periodically and encrypt them yourself This is good advice but it just isn't going to happen in practice unless gmail makes it the default for everyone. WhatsApp added support for the Signal protocol and made it the default for all users, now the whole world is communicating with end-to-end encryption.

The whole world is using "end-to-end encryption" using keys facebook has. Lucky us

Re: Email cannot be encrypted at rest

#22
> We refuse to sell quackery.

This phrase appears multiple times. Wherever it appears, they are wrong. So I love this set of pages. It tells me these are not people to be trusted. They have deep, fundamental misunderstandings of the things they "cannot" provide.

Sometimes, they are mistaking the practical (and useful) for the theoretically perfect. They don't do X because it isn't theoretically perfect, and they can't seem to imagine a way to do it other than the strawman trivial (and bad) way they set up for a smackdown.

Sometimes, they are confusing different issues. Like in this case, what encryption at rest even is, and what it achieves. Or how they seemingly misunderstand ASPs.

I think they are actually probably reasonable tech-wise, and the presentation just needs some help (or some topics not discussed at all). It feels like a Swiss caricature though -- we are always right, if you disagree go away. We only want competent customers. (Where competent == agree that we are correct.) Spoken with a calm air of superiority of course. But maybe what comes off as user hostile to my sensibilities is perfectly cordial to a Swiss person. It would be ok if they weren't actually wrong on the security topics.

I especially enjoy:

No feature parity

We really do not care what service X offers and will not try to match them

Re: Email cannot be encrypted at rest

#23

> We refuse to sell quackery. This phrase appears multiple times. Wherever it appears, they are wrong. So I love this set of pages. It tells me these are not people to be trusted. They have deep, fundamental misunderstandings of the things they "cannot" provide. Sometimes, they are mistaking the practical (and useful) for the theoretically perfect. They don't do X because it isn't theoretically perfect, and they can'…

Hi, dejan from Migadu here. Thank you for your comment. We are happy to correct ourselves, but your comment does not prove us wrong to the reader.

I would appreciate to hear the technical reasons why we are wrong on security topics, and less of personal sensibilities. This will contribute to the discussion better and potentially to the email ecosystem :)

Re: Email cannot be encrypted at rest

#24
post #7
post #2

> at rest So we're talking about after it's received and processed by a server. > Email is built on top of plain text protocols and messages flow in plain text. If you encrypt, you cannot scan for spam or viruses... But you can? Just scan and process before encrypting. > ...index messages for searching This indeed is a problem. Encrypting emails individually makes search difficult. Why not just encrypt entire hard dr…

The title is throwing off how we’re reading the article. It’s really about why they, an email provider, can’t meaningfully encrypt email at rest. FTA: >If you are interested in real encryption, please use end-to-end encryption tools such as GPG or fetch locally all your messages periodically and encrypt them yourself. I would say their standard for being ‘encrypted at rest’ is including a requirement that they are un…

This is really a bad title to our Pro/Cons page, but in principle the takeaway here should be - email is not perfect and we chose some compromises (unless you use hey.com, they "fixed" email ;). That is why you are reading this as a Con to our service, not a Pro.

Indeed, for us, encryption at rest is only meaningful if we cannot access the mails either. However, that is nowhere on the horizon for email. There is a technical way to achieve that, but at a great cost of usability.

Encrypting the disks themselves is trivial and is on our roadmap, but it is nowhere as important as some providers tend to boast. That is why we say "quackery." It is just a "nice-to-have", but in every-day security it matters just as much keeping your car keys in a sealed jar all the time, carrying the jar in your pocket =)

Our data is stripped among multiple disks in RAID10 (obviously), that by itself ensures very little importance to a single disk. Not to mention that if a disk is dead, one would have to find it, identify it belongs to specific user and recover it. This is more likely:

https://xkcd.com/538/

Processes inside of the data center are way more important than an extra layer of encryption for a hollywood heist.

In our so far experience, the biggest threat to users' data are the users themselves. Forgetting passwords, accidentally deleting mails, running malware, choosing weak passwords...

It is interesting that we have never seen this issue raised for Outlook, Gmail, Zoho, Yahoo, AOL and other large providers, who never did or will encrypt at rest.

With hosted services there has to be a chain of trust. We trust our providers (ISP, data centers etc), and our users trust us as a provider.

Furthermore email is generally being observed wrongly today [IMHO]. Email message is a equivalent of an open envelope, a postcard. The only way to security is end-to-end encryption. This way, the need to trust the provider is removed. We could say openly we do have encryption at rest, but that claim cannot be proven by anyone. Same way as Whatsapp says they are E2EE but being a closed protocol, we still have to trust Whatsapp they are telling the truth.

As a provider you have to choose what is worth implementing and what not, what realistically benefits users and what not. Military grade security is silly for email in our opinion. If that is requirement, one should probably not be using email at all. Use Whatsapp :D

Jokes aside, we just try to keep a sane approach to security and not take absolutist stand, all or nothing. It is always a compromise between usability for the user, maintenability for the sys admin and cost. We are not on the expensive side meaning we have to take sane compromises.

If you are willing to pay a premium for absolute security, we can of course do that for you, but we know no one will be willing to pay, and those that do, we probably do not want to have such users, based on our experience from @protonmail users using Migadu. There is tutanota for that purpose btw.

Email was not meant to do many of the things we today try to use it for. It is much more complex than majority will even know and appreciate unless they become providers themselves.

Re: Email cannot be encrypted at rest

#26
post #7

Earlier quoted context omitted.

The title is throwing off how we’re reading the article. It’s really about why they, an email provider, can’t meaningfully encrypt email at rest. FTA: >If you are interested in real encryption, please use end-to-end encryption tools such as GPG or fetch locally all your messages periodically and encrypt them yourself. I would say their standard for being ‘encrypted at rest’ is including a requirement that they are un…

> please use end-to-end encryption tools such as GPG or fetch locally all your messages periodically and encrypt them yourself This is good advice but it just isn't going to happen in practice unless gmail makes it the default for everyone. WhatsApp added support for the Signal protocol and made it the default for all users, now the whole world is communicating with end-to-end encryption.

If gmail did end-to-end encryption, how exactly would they scan your data for their ad purposes?

That would be the end of free gmail.

Re: Email cannot be encrypted at rest

#27
post #23

> We refuse to sell quackery. This phrase appears multiple times. Wherever it appears, they are wrong. So I love this set of pages. It tells me these are not people to be trusted. They have deep, fundamental misunderstandings of the things they "cannot" provide. Sometimes, they are mistaking the practical (and useful) for the theoretically perfect. They don't do X because it isn't theoretically perfect, and they can'…

Hi, dejan from Migadu here. Thank you for your comment. We are happy to correct ourselves, but your comment does not prove us wrong to the reader. I would appreciate to hear the technical reasons why we are wrong on security topics, and less of personal sensibilities. This will contribute to the discussion better and potentially to the email ecosystem :)

To quote your other comment:

> [...] email can be encrypted at rest. We just chose not to do it at the very moment due to the very little added benefit we see in our overall setup.

claiming that everyone who chooses differently is selling quackery is not a good look. The same way I could claim you are selling quackery because you refuse to implement an additional security-in-depth layer.

Re: Email cannot be encrypted at rest

#28
post #27
post #23

Earlier quoted context omitted.

Hi, dejan from Migadu here. Thank you for your comment. We are happy to correct ourselves, but your comment does not prove us wrong to the reader. I would appreciate to hear the technical reasons why we are wrong on security topics, and less of personal sensibilities. This will contribute to the discussion better and potentially to the email ecosystem :)

To quote your other comment: > [...] email can be encrypted at rest. We just chose not to do it at the very moment due to the very little added benefit we see in our overall setup. claiming that everyone who chooses differently is selling quackery is not a good look. The same way I could claim you are selling quackery because you refuse to implement an additional security-in-depth layer.

>claiming that everyone who chooses differently is selling quackery

We never say that anywhere, but thank you for the heads up.

> The same way I could claim you are selling quackery because you refuse to implement an additional security-in-depth layer.

Indeed, you have all the rights to say so, but we both enjoy the liberties to differ on what "security-in-depth" is.

Re: Email cannot be encrypted at rest

#29
post #28
post #27

Earlier quoted context omitted.

To quote your other comment: > [...] email can be encrypted at rest. We just chose not to do it at the very moment due to the very little added benefit we see in our overall setup. claiming that everyone who chooses differently is selling quackery is not a good look. The same way I could claim you are selling quackery because you refuse to implement an additional security-in-depth layer.

>claiming that everyone who chooses differently is selling quackery We never say that anywhere, but thank you for the heads up. > The same way I could claim you are selling quackery because you refuse to implement an additional security-in-depth layer. Indeed, you have all the rights to say so, but we both enjoy the liberties to differ on what "security-in-depth" is.

> We never say that anywhere, but thank you for the heads up.

Well, it reads that way, and you asked for feedback.

Re: Email cannot be encrypted at rest

#30
post #29
post #28

Earlier quoted context omitted.

>claiming that everyone who chooses differently is selling quackery We never say that anywhere, but thank you for the heads up. > The same way I could claim you are selling quackery because you refuse to implement an additional security-in-depth layer. Indeed, you have all the rights to say so, but we both enjoy the liberties to differ on what "security-in-depth" is.

> We never say that anywhere, but thank you for the heads up. Well, it reads that way, and you asked for feedback.

Thank you, appreciated that! I think the "quackery" part reads as too arrogant. Was not intention and I will make sure we get that rewritten.

Same paragraph has a mixture of E2EE and Encryption at rest topics which may confuse users. We'll separate that.

Post reply on HN