Email cannot be encrypted at rest • Hacker News Board

Re: Email cannot be encrypted at rest

#31

Post by dejan » Sat, Oct 24, 2020, 12:39 PM UTC

compsciphd wrote: post #19

paper I had an idea for that was mostly done by an undergrad (now a professor) https://www.acsac.org/2007/papers/161.pdf --- The increasing centralization of networked services places users' data at considerable risk. For example, many users store their email on remote servers rather than on their own client machine. Doing so allows users to gain the benefit of regular backups and remote access, but it also places a…

Thank you for posting this. Interesting!

But in this case, if user were to forget password, the data would be lost, would it not?

Re: Email cannot be encrypted at rest

#32

Post by bblough » Sat, Oct 24, 2020, 2:42 PM UTC

dejan wrote: post #30

detaro wrote: post #29

Earlier quoted context omitted.

> 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.

While I agree with the other comments about the implications of your "quackery" phrasing, I want to chime in and say that overall, I really appreciate that you wrote that page.

I think it's unusual to see a company basically say "here's why you might not want to use our product". The ones that do often come across as "here are our issues, but here's why they don't really matter and you should use us anyway". While some parts of the page do maybe seem to do a little of the latter (the "quackery" sections are a good example), the overall tone I get is "here is why we might not be a good fit for you", and I find that rather refreshing.

I'm sure some people will see your "take it or leave it" approach as user-hostile. And perhaps on some level it is. But in my opinion, it's far less user-hostile than hiding those choices/limitations in order to get signups, with the user then finding out about them later and having buyer's remorse.

So kudos for being up-front about it.

Re: Email cannot be encrypted at rest

#33

Post by detaro » Sat, Oct 24, 2020, 3:05 PM UTC

bblough wrote: post #32

dejan wrote: post #30

Earlier quoted context omitted.

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.

While I agree with the other comments about the implications of your "quackery" phrasing, I want to chime in and say that overall, I really appreciate that you wrote that page. I think it's unusual to see a company basically say "here's why you might not want to use our product". The ones that do often come across as "here are our issues, but here's why they don't really matter and you should use us anyway". While so…

thanks for calling that out, and despite my criticism upthread I have to fully agree with this - the wording can be improved but this kind of documentation is great to have!

Re: Email cannot be encrypted at rest

#34

Post by compsciphd » Sun, Oct 25, 2020, 4:48 PM UTC

dejan wrote: post #31

compsciphd wrote: post #19

paper I had an idea for that was mostly done by an undergrad (now a professor) https://www.acsac.org/2007/papers/161.pdf --- The increasing centralization of networked services places users' data at considerable risk. For example, many users store their email on remote servers rather than on their own client machine. Doing so allows users to gain the benefit of regular backups and remote access, but it also places a…

Thank you for posting this. Interesting! But in this case, if user were to forget password, the data would be lost, would it not?

I mean, if I ran my own server and forgot the password to it, the data could be lost as well....

Re: Email cannot be encrypted at rest

#35

Post by jiveturkey » Tue, Oct 27, 2020, 12:51 AM UTC

dejan wrote: post #23

jiveturkey wrote: post #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'…

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 :)

Thanks for being so attentive. You just went up 10 points in my book. Still, I can't imagine what your customer service would be like. "It was your fault you didn't have another copy of your emails. delete+purge working as intended." Please, you don't need to respond to that specifically. I just intend it as a contrived example of what I might expect based on your product page. I hope you can understand why someone might feel this way.

I don't have gobs of time but I will at least talk quickly about the 2 specific points since I did raise them and you are kindly enough to want the feedback.

Encryption at rest is not quackery. It protects against theft of physical media. It protects against loss of data when decommissioning media. This happens all the time, in unexpected uncontrolled ways, both when under your direct control and when run in the cloud. No, it does not protect against in-use theft nor the situations you describe. That doesn't make it quackery. It is not encoding; the keys do not need to be stored on the disk being encrypted. (That of course is worthless.)

ASPs are valuable for the same reason oauth is valuable. When you have an account that controls very many services/apps, and you want a specific loss to be limited in scope, you will use an ASP. If you login to mail on 5 machines, and you can detect which one gave up a password, it can be useful. 2FA oauth can be very useful for similar reasons, even if after the authorization it is 1FA afterwards. The implementation of ASPs by Google may be deficient in that they weren't actually limited in scope for a very long time (maybe they still aren't, if they even have them anymore?) but the general concept of the ASP is really like a "out of band" oauth. In your case, I imagine you provide email service only. ASPs would have very limited or no utility for you. oauth grants might be valuable (for 2FA reasons), but I haven't looked at your service to be sure.

How many people could actually be asking for ASPs at all? Just leave this off the page altogether. It screams that you are criticizing some other service, rather than extolling the virtues of your own. It's a bad look.