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.

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.

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.

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!